std.locale

[Andrei Alexandrescu]

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.

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.

Possibly you are missing one or more of the following points:

1) The existence of a hierarchical nomenclature for localization;

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

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

> I'd much rather see a rewritten std.stream and proper Unicode support
> in std.string (support for types other than string, functions for
> indexing and slicing on character boundaries) before this.

That, incidentally, is more complicated :o).


Andrei