std.locale

[Andrei Alexandrescu]

Georg Wrede wrote:
> Andrei Alexandrescu wrote:
>> Sooner or later that will need to be defined. I know next to nothing 
>> about locales. (I know I dislike the design C++ uses.)
> 
> 
> D uses Utf-8, and that is *good enough*!
> 
> This lets my programs "understand" Finnish, and doesn't give me undue 
> headaches.
> 
> 
> Seriously tending to locale issues would be an *endless swamp*. Just for 
> this, I looked up something suitable to read:
> 
> http://www.manpagez.com/man/1/perllocale/
> 
> It may even be that you would find the time, but think about Walter and 
> us, please. There *really are* other things to do.

I don't find that scary at all. It's quite what I expected. We should 
phase it in, after we do a good design. Also I don't plan to sit down 
and write locale definition files, I want to parse the XML in that 
locale repository I referred to.

> 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?

> Besides, there's more to this than just designing the perfect, or even a 
> good locale system in a language. *Somebody should actually use it*.
> 
> Now, the non-English programmer, what does he really want? He wants to 
> be able to type stuff into his program in his native character set. D 
> already does that, by way of Utf-8.
> 
> What else? Well, it is conceivable that he wants his program to print 
> dates and times the way it's done over there. He simply writes the 
> program "by hand" so it does dates and times like he wants. Even if 
> there was a locale thing in the language, he wouldn't bother with the 
> hassle. And he couldn't care less about Urdu.

If we come up with a good design, then they will be compelled to use it. 
Applications meant to be used across multiple countries have fumbled 
with locale support because there's no good support in most languages. 
So then why not offer a compelling support in D?

> The hypothetical Ambitious Programmer might want to use locale. He could 
> then have the dates and times (and currencies, etc.) follow the country. 
> Now, that might sound commendable, but in practice it *crumbles*.
> He can't possibly know how to deal with languages that are written 
> backwards, languages where several characters make one letter, exotic 
> ways of writing dates, etc.

Well my understanding is that the guys who wrote those RFCs and whatnot 
spent time figuring out the right abstractions. Why not use them?

> So, his fancy i18n project is doomed to be, at most, as usable as the 
> "normal" D program. Probably less, since his decisions will actually 
> worsen the user experience -- for users in another culture.
> 
> 
> And, any project big enough to tackle this, will implement its own 
> locale handling anyway. I'm sorry to say.

They will implement their own because the language doesn't offer an 
extensible framework that they can build on.

> Yes, locales are nice and all.
> For D 3.5 that is.
> Honestly.

I just don't see where the big problem is. I'm talking about a blessed 
hierarchical hashtable to begin with. My initial desire is to be able to 
customize the array separators in writeln.


Andrei