std.locale

[Georg Wrede]

Andrei Alexandrescu wrote:
> 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.

Maybe a quick skim doesn't let the issues sink in. :-)

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

My ex wife has this GPS thing in her car. Very nice. But once on the 
road, it's too much hassle to type in a street address. And you're 
always in a hurry, so you don't have time to type it in before driving, 
while you're stuffing the kids in the car.

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

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

Gnome and KDE are both GUIs designed by "foreigners". i18n has been a 
*top priority* from the outset. Start a default project, and you have 
i18n "inbuilt" in your app.

And still, my default clock applet only lets me choose between 12 and 24 
hour clock, but the date is always "Mon Mar 2", and I can't get it to 
"020309", which I want. Or change it at all.

And while there are simply excellent provisions for having all your app 
strings in the local language, hardly any application actually has more 
than a couple language choices.

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

Nobody will use it. (People buy all these expensive workout machines 
they see on TV, and they never use them after two weeks.) i18n support 
is more than having your arrays print in peculiar ways overseas.

Ideally, you would translate the UI to several languages, take in 
consideration some cultural differences, and then have the library muck 
your strings and variables into the "local" representation.

Won't happen in a non-GUI program.

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

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.

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

No, it's because they will only implement the parts that they're 
interested in. That's pretty easy to do for a big project. (If there 
will be one for a non-GUI purpose.)

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

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?

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.

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.

> My initial desire is to be able to customize the array separators in
> writeln.

One might want to print arrays in different ways, even in the same 
program. Why not let the programmer customise the array printing the 
same as he does with integers and floats? Just a little addition to the 
syntax?

Or why not just have a print function that takes an array and a format? 
Arrays are different enough to not comfortably fit into writefln 
semantics anyway. Clean and practical, in a practical language.

Whatever you do, don't mix this with any internationalisation, please.