std.locale

[Michel Fortin]

On 2009-03-02 01:04:47 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at erdani.org> said:

> Good idea. But before we do so, I was hoping I'd pick the brains of 
> people who have used locales in other languages and understand the 
> burning points. Somehow, however, I'm doing a lousy job at eliciting 
> contributions from people on this newsgroup (guess I'd be a lousy 
> salesman). I tried a couple of times and all I got was a few new 
> keyword proposals and a few new syntax proposals :o). What am I doing 
> wrong?

I think there are three aspects to localization. One is date and number 
formating. Another is offering a facility for translating all the 
messages an application can give. And the last one is the configuration 
part, where you know which format to use.

The only problem I've seen addressed by you right now is the 
configuration part; I believe it's the wrong end to start with.

We should start by defining how to perform the tasks I enumerated 
above: translating date and number formats, selecting strings for a 
given language. After that we can figure out how to pass the proper 
default configuration around. And then you're done.

For date and number formatting, I like very much the NSDateFormatter 
and NSNumberFormatter approach in Cocoa for instance: you have a base 
class to format dates, another for numbers; you can easily create your 
own subclass if you want, and there's a way to get the default 
formatter instance.

This is extensible, because if you wanted to go further, you could add 
formatter classes for various units (length, mass...), or anything else.

Translating strings is a little harder because 1) strings are 
application-defined, 2) strings are often not available in the user's 
prefered language, adding the need for a fallback mecanism, and 3) 
different applications will want to to store those strings in different 
ways. Perhaps we could define a base class for getting translated 
strings, then allow the program to use whatever subclass it wants.

Notice how I'm not using the word "locale" to talk about these things. 
"Locale" is a concept too abstract to be able to do something good with 
it. Since you could only define it using Algebraic type and a loosely 
defined tree of strings, that seems to confirm my view. Call the module 
std.locale if you want, but keep in mind that the most important task 
at hand is facilitating localization, not defining what constitutes a 
locale, that can wait.

-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/