std.locale

[Andrei Alexandrescu]

Sooner or later that will need to be defined. I know next to nothing 
about locales. (I know I dislike the design C++ uses.)

I was thinking of a design along the following lines. There are RFCs 
dedicated to locale nomenclature:

http://tools.ietf.org/html/rfc4646 for language names
http://www.unicode.org/cldr/ for various locale names

So we know the basic names we want to follow, which is one less burden. 
Then what I want to do is to define a hierarchical string table that 
fills the appropriate names.

This is in opposition to defining an actual class hierarchy that mimics 
the localization table. I think a hierarchical string table is better 
because it allows simple extensibility.

The type stored by each slot of a locale is:

Algebraic!(
     int,
     string,
     Variant delegate(Variant),
     This[string]);

meaning that a locale could store one of these types. (What else should 
go in there?)

The access pattern goes like:

// Get the date display pattern
auto pat = myLocale.get("calendars", "calendar=default",
     "dateFormats", "dateFormatLength=medium", "pattern");

This will return an Algebraic with a string in it. The string looks like 
e.g. "yyyy-MM-dd".

The access is rather verbose because the corresponding locale names tree 
is equally (actually more) verbose, see 
http://unicode.org/Public/cldr/1.6.1/core.zip. But the flexibility and 
the standards-compliance are there. We may add later some convenience 
functions for frequently-used stuff such as dates, times, and numbers.

Extension is obvious:

myLocale.put("my-category", "my-slot", "whatever");

Getting later the stuff in "my-category", "my-slot" will return a string 
Algebraic containing "whatever".

There will be a global reference to a Locale class, e.g. defaultLocale. 
By default the reference will be null, implying the C locale should be 
in effect. Applications can assign to it as they find fit, and also pass 
around multiple locale variables.

So I wanted to gather some good ideas about locale design. Is a 
string-and-Algebraic design good for all uses? What kind of locale 
functionality does it not capture? I must have missed a ton of details, 
so if you don't understand what I mean by the above, it must be me.



Andrei