std.locale

[Georg Wrede]

Andrei Alexandrescu wrote:
> Jarrett Billingsley wrote:
>> On Mon, Mar 2, 2009 at 1:52 PM, Georg Wrede <georg.wrede at iki.fi> wrote:
>>> My take:
>>>
>>>  * This is still a moving target
>>>  * Using this is a major hassle for the programmer
>>>  * With D2 itelf a moving target, nobody is going to invest enough 
>>> time in
>>> this to actually use it for something worthwhile in the next 6 to 12 
>>> months
>>> anyway
>>>  * This is more application level stuff than language level stuff
>>>  * Doing this now will steal time from you, Walter, and many of us, both
>>> directly, and indirectly by leaching bandwidth in the newsgroup -- 
>>> time that
>>> should be spent on more urgent or more important things, or even
>>> documentation
>>>  * If it's so easy to do, then why not do it a week before the 
>>> release of
>>> final D2
>>
>> I agree entirely.  Localization and internationalization seem like
>> things that should be at a much higher level than a standard library.
>> Everyone's going to want to do it differently.  Providing a thin,
>> cross-platform wrapper over what the OS exposes is fine, but creating
>> a proper i18n/l10n framework is a huge project in and of itself (I
>> think the 140MB Java package makes that abundantly clear).
> 
> I must be missing something huge because I keep on misunderestimating 
> (sic :o)) the scope of this project.

I agree. :-)

> Let me try to state my point again: I don't want to provide 
> locale-specific strings, collation orders, date, time, and number 
> formatters, or class hierarchies that do all of the above. Zip. Nada. 
> Zilch.
> 
> I want to put together a string-based hierarchical string table that 
> allows depositing ALL OF THE ABOVE in it, without initially putting 
> ANYTHING in it. What's nice is that others have already defined the keys 
> and the possible values used by that table.

One of the problems is, people start expecting something if they find 
this string repository. They'd expect some of the work you said you 
don't provide, done. And if the table isn't even *prepopulated*, then 
people really feel stranded. It doesn't help much to state in the docs 
"if you need to fill it goto http://whatever, and hope the format hasn't 
changed".

Besides, on that site, what exactly should be downloaded is unobvious 
enough that the new user will probably not bother. Nor the normal app 
programmer.

> Possibly you are missing one or more of the following points:
> 
> 1) The existence of a hierarchical nomenclature for localization;

With a hammer in hand, everything looks like a nail. With a swiss army 
knife in your hand, nothing in the house is safe.

> 2) The existence of a large database containing localized values for 
> said nomenclature;

So where will this be stored? In a .dmdrc directory in the user's home? 
One per system? Or every app stores it in a .ini file? Is this per app 
or common to all user's apps?

And when it's updated (by who?), will all his own settings vanish? Or is 
there a mechanism (or does he have to invent one?) for reattaching his 
own settings after the update?

> 2) The power of Algebraic, which allows depositing data, functions, and 
> subtables alike in a uniform format.

Seriously however, Algebraic does sound cool! No question.