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

[Ivan Sergio Borgonovo]

On Mon, 22 Oct 2007 08:12:05 -0400
Earnie Boyd <earnie at users.sourceforge.net> wrote:

> Quoting Ivan Sergio Borgonovo <mail at webthatworks.it>:

> > 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.

> This comes down to user options of representations.  The user
> selects the format for floating point and the format for currency.

I'd add this at a later stage and I think since you can keep
signature consistent, it doesn't represent a problem.
Language at the beginning will provide the format, later they will
provide the default for the format.

> The two have separate formats because non-currency floating point
> is likely to have different representation.  The hardest part is

Just curious... are there float that don't share with currency
separators and grouping?
Anyway man 5 locale is a good place where to look at to provide a
quite general formatting function.

> knowing which format to use when representing the data to the user;
> i.e. is this number representing currency or non-currency.

the application will know. If you're passing to a formatting string
something you should know what it is.
I'm not aware of any facility that let eg. theme('table' decide how
to format stuff accordingly to the content type.

> When it comes to accounting systems, floating numbers should be
> avoided and all data should be stored and processed as integers to
> avoid rounding issues while processing.  Only at the time of

right... so any currency formatting function should take int as
argument.

doesn't PHP really offer anything out-of-the-box?
nearly-out-of-the-box? not-to-far-from-out-of-the-box? ;)

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