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

[Ivan Sergio Borgonovo]

On Wed, 17 Oct 2007 19:52:33 +0200
Wim Leers <work at wimleers.com> wrote:

> My Money CCK field module [1] already supports portions of the  
> desired functionality:
> 1) You can choose whatever currency you want to store your amount
> in. 2) You can choose the digit group separator and the decimal
> separator. 3) Two formatters are offered: currency code
> before/after the amount.

I gave a look at the code. I think something a bit more generalised
could gain more acceptance. I'm thinking about position of the sign
and relaying on a more general number format.
People may not want to follow ISO but just output their stuff
accordingly to traditions.

> It's not a Drupal core solution, but it is a solution.

I'm not expecting to get into core. I just would like to make my
solution easier to maintain.
If people would start to build up modules that wrap currency/float
format function we may end up in making i18n easier.
Same for float/large numbers.

I'm not aware of how many modules output something that's not simple
integers (and even large integers may have to be formatted...) but it
looks like a must have feature.

I think that a reasonably general solution can be found and people
could tune it in a setting page as they would do with the date format
in php.
There are 2 currencies that are a bit tricky to format (non decimal
ones) the rest is just a matter of providing a date alike string that
could tell where to put sign and currency symbol.
Number format could be inherited by the number formatting format.
I'm not aware of any other strangeness other than grouping by
hundreds other than thousands and using different char as separator
for decimals/"thousands".

As for currencies just 2 currencies can't be expressed in a
meaningful way other than in their "native" format.

Others can be "adapted".

What I mean is that Italian expect to read
€ 1.234,56
as well as
$ 1.234,56
while US people expect to read
€ 1,234.56
and
$ 1,234.56

If we want to be really tough we could provide 3 number format for
each language:
- standard
- scientific
- accounting

This would make this stuff pretty general and when modules will have
to output numbers they will have the correct format in most of the
cases.

In *many circumstances* people won't tolerate that numbers/currencies
don't get displayed in their local format.
Editing all the contrib modules to retro-fit them to support
localisation of format may be a PITA.
If people think that their output doesn't have to be "localised" they
could avoid to wrap their output with these functions as I think they
are already doing when there is no purpose for using t().

Something that provide this base functionality is due. Gluing it
together with i18n shouldn't be a problem.
Function naming/signature and how much it has to be general will
decide its acceptance.

I'm still open to advices.

thanks

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