On 2009-03-02 23:27:49 -0500, Andrei Alexandrescu
<seewebsiteforem...@erdani.org> said:
Georg Wrede wrote:
[snip]
Well I guess what I'll do is take the path of least resistance -
nothing. Looks like locales are rather unpopular...
Sad.
Seriously, I think if D could have locales as a standard feature it'd
be great. Supporting various locales is often a must when you deploy an
application, and when libraries try to do it differently you find
yourself in a mess.
One thing I dislike in your approach is that you're designing the
underlying data storage system before considering the API we're going
to use. What we need the most is a standard API for localizing the
display and input of data, and I somewhat fail to see how storing all
the localization parameters in an Algebraic solves this problem.
I mean, let's say you want to output a localized message, perhaps we
could do this:
writefln("Hello number %f", 123456.44);
writefln(localize("Hello number %f"), 123456.44); // default locale
Locale fr = locale("fr");
writefln(localize("Hello number %f", fr), 123456.44);
and expect this output:
Hello number 123456.44
Hello number 123,456.44
Bonjour numéro 123 456,44
?
That'd be an interesting feature. But as of yet I have no idea how
we're supposed to use all that locale information you want to keep in
your algebraic type; you haven't provided much examples like the one
above where all you want is to format a string and a number. Perhaps
it's clear in your head, but to me it's vague. Exposing all this locale
data is useless if it isn't supported by the library's functions.
What I wrote above could work that way: localize(...) returns a
FormattedString!(...) struct template containing a string and a
templated function "format" for formatting its arguments. writefln
being a templated function, it'll call toString on its first argument
and check if it provide a "format" function, and if it does it passes
all the other arguments through it before output.
The "localize" function could be overloaded to accept various types of
locales. Including, but not limited to, your Algebraic locale data.
The downside of this approach is that it requires functions accepting a
locale or a localized formatted string to be templates.
--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/
