Jarrett Billingsley wrote:
On Mon, Mar 2, 2009 at 1:52 PM, Georg Wrede <[email protected]> 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
