[development] code proposal: localization of currency, ...

[Ivan Sergio Borgonovo]

On Mon, 22 Oct 2007 09:46:02 +0200
Hans Salvisberg <drupal at salvisberg.com> wrote:

> What might be useful for many sites is an API with an options page
> that lets the site administrator freely define THE currency format
> for the site (completely independent of lanugage!). He'd still only
> have one, but at least he'd have the one he selected. That would be
> a big step forward.

If you think that there aren't multi-language sites yes.

> Don't try to be smart. Software that tries to be smart and to guess
> the user's wishes (based on the author's less than perfect view of
> the world) is absolutely maddening!

I'm not trying to be smart, I'm trying to add freedom to chose.
A) if your site is not multi-language administrators will have one
place where to specify at their will what should be the formats
B) if you've a multi-language site administrators will be able to
specify many formats. The fact that language and localisation are one
thing for drupal is another problem, because if you're dealing with 2
localisations that share the same language but not the same string
format you'll have to "duplicate" content.
But this happens just if you are using i18n since without i18n there
is not such a thing as content<->language association and you don't
have multiple places where you can set locale format info...

Now... let's see how we can go forward and add "localisation" to
"translation" for multi-language sites.

Let's see localisation as 2 orthogonal components:
- translation
- string format

Actually the fact that some localisation share the format part is
accidental.

How do you expect default to be set?
I think a good place to set a default localisation is "language".
A correctly guessed language will eventually put people on the right
path to adjust their localisation.
It may be wrong... but is better than being wrong and having one
choice.

If you want to go further... you should let people chose their format.

So signature of the functions should be changed to something like:

outerfuncname(param, ... $format_override) inspite of $language.
If someone is actually willing to change the default/selected
format... then let it be.
Internally the function first will chose the default associated to
the language, later when we will provide a user based choice... the
first choice will be whatever selected by the user, second choice
would be the language default.

I think that $format_override is anyway a too long list of
parameters... outerfuncname should just be used to chose the format
accordingly to language or user choice when ready and we could offer
an innerfuncname for actually doing the work to module developer
since I didn't see anything in PHP that is more sophisticated than
number_format and setlocale is not thread safe.


-- 
Ivan Sergio Borgonovo
http://www.webthatworks.it