Georg Wrede wrote:
Andrei Alexandrescu wrote:
An excellent string hierarchy without the entire rest of i18n, is
only going to look like a Ferrari with a Trabant engine. Which is
worse than nothing at all.
I don't understand this. What is the rest of i18n?
i18n stands for internationalisation. The word was too long to type.
Ah, or you meant the rest? That is, if there is this shiny repository
right inside the language for storing these i18n preferences, then that
does oblige us to have writefln, regexp, sort, and other stuff to
recognise those values, right? Otherwise people will ask how come we
have a car but no engine. And that is a job bigger than it looks like.
But not doing it fully will have people feel D is less good than if we
never had the repository at all!
Oh, and who wants writefln, regexp, sort, and the others to become
slower? Hands up.
They will only be slower, by necessity, for people who want them
localized, not for anyone else.
Well my understanding is that the guys who wrote those RFCs and
whatnot spent time figuring out the right abstractions. Why not use them?
Because we don't have infinite time. Urgent, much asked for,
technologically imperative, and other stuff should be done instead.
There are both mundane and interesting tasks. Nice-to-haves come later.
This is a misunderstanding. I am talking about a few dozens of lines of
code that capitalize on Algebraic to structure the locale space. For
starters I just want to e.g. allow people to configure how they
stringize and print stuff from D. Hardcoding that kind of stuff, or the
strings thrown in exceptions, does not sound too good.
I just don't see where the big problem is. I'm talking about a blessed
hierarchical hashtable to begin with.
The big problem is, SOMEONE will have to tell your XML table what
values the user wants. Where is this knowledge stored in a way that
every D app can get to it? And how do you force the user to populate the
XMl table with his choices to begin with?
You see, we're not communicating. I sent this link:
http://www.unicode.org/cldr/
Did you look at it? It is essentially a database of locale information
in a highly structured format. All I want is to define a structure
expressive enough to gobble the part of that database that is of
interest. The Phobos documentation will say, we just adopt their schema.
If users don't want to load any, then fine - everything is just like today.
What I'm saying is, it's debatable whether this stuff belongs to "the
programming language itself" at all. Rather, it should be an external
library, provided by someone else than us. It belongs to SourceForge or
Dsource, not here.
http://www.unicode.org/cldr/
We just need to load it if there is such a need.
And definitely all this should be deferred to not 2.0, but to 2.5 or
preferrably 3.0. If by that time we have seen that there actually is any
use for such a thing, then we can decide whether to outsource it to
anybody interested, or to actually try to make it part of the language.
I'm not saying it's impossible to do, or to do well. But I am saying it
is *way* too insignificant to deserve any attention at this time.
You and I have completely different understandings of the level of
effort needed. It's not like I don't have anything to do. :o)
Let me try again: I don't want to define locale support. I want to
provide the basics for people to roll it out themselves.
Andrei
