std.locale

[Andrei Alexandrescu]

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