Michel Fortin wrote:
On 2009-03-02 01:04:47 -0500, Andrei Alexandrescu
<seewebsiteforem...@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
