std.locale

[Michel Fortin]

On 2009-03-02 23:27:49 -0500, Andrei Alexandrescu 
<SeeWebsiteForEmail at 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.fortin at michelf.com
http://michelf.com/