std.locale

[Andrei Alexandrescu]

Michel Fortin wrote:
> 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.

Sounds like a good start.

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

Well I was thinking of passing the buck around. Instead of std.locale 
defining a hierarchy for formatting numbers and dates, it provides a 
means for user code to plant a routine in the locale object that knows 
how to format numbers and dates. Of course, with time default localized 
routine implementations will show up (hopefully contributed to by 
people), but the basic mechanism is simple - there exists a locale table 
that allows you to store a delegate in it.

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

This I want to avoid, at least for the time being. I want to define a 
table that can contain strings, integers, delegates, and other 
sub-tables. This is it. The path to extensibility will not be Phobos 
defining new classes to format various things. This could go on forever. 
Phobos will use the table consistently, and users who do want to format 
various things will simply plant their delegates in the table.

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

There's no need for classes and subclasses. It's all data. Why should we 
replace data with code? Data is easier.

Consider some code in phobos that must throw an exception:

throw Exception("File `%s' not found, system error is %s.",
     filename, errnomsg);

The localized version will look like this:

auto format = "File `%s' not found, system error is %s.";
auto localFormat = currentLocale ? currentLocale.peek(format) : null;
if (!localFormat) localFormat = format;
throw Exception(localFormat, filename, errnomsg);

What happens is that the default format string _is_ the key for looking 
up the localized strings. If there's no value for that string, the 
default format string is in vigor. Note that on the default path, 
currentLocale is null so there is hardly any inefficiency.

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

How should I call it?


Andrei