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

[Larry Garfield]

On Fri, 19 Oct 2007 12:22:22 +0200, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:

> #tech
>
> I think this kind of support should be available independently from
> i18n for mono-language sites and I gave some example on how it could
> be used even without i18n support but if no sign of
> acceptance/suggestions come out I'm going to write it as if it
> was part of i18n with function names in their own "namespace".
> Starting with the right foot and giving them a more "corish" name
> would make it easier to be included in module development.
>
> If no suggestions for better acceptance comes out shortly I'll start
> to write an interface for setting up this stuff and the functions.
> If someone is aware of some more strangeness of float/currency
> formatting let me know.
>
> Suggestions for the formatting string for currency are also welcome.
> Especially a way to specify character that shouldn't be outputted in
> case the number is positive.
>
> Is there anything more than:
> general
> scientific
> accounting
> notation for float/currency.
> I'd think that accounting rules are rather specific to each country
> and accounting modules would be specific for a country and let the
> developer take care of the problem independently of the
> interface/language.
> As well as I'll keep scientific notation in US format.
> Anyway in spite of adding one parameter to format_number I could just
> write format_scientific and format_??? later to avoid messing up with
> signatures and over planning.
>
> At this moment I'm aware of people using different char for grouping
> and different size of grouping (eg. 1 23 45 to write what US people
> would write as 12,345).
> Providing support for such formatting is a bit more overhead cos you
> can't use directly php format_number.
> Can anybody confirm that there are some places where they group
> differently? Is anyone scared about the extra overhead of an if
> clause if grouping is != 3 so that most common case could be
> optimised with format_number and everything else use a custom
> function?
> Is it worth to support this cases?
> Still they can be supported later without changing the signatures of
> the functions.
>
> BTW I'm already using i18n and custom date format for each language
> and it works like a charm
>
>
> thx
>
>
> [1] as a matter of fact Drupal is providing one of the best framework
> for internationalisation I'm aware of. It doesn't mean it can't be
> improved.
>
> --
> Ivan Sergio Borgonovo
> http://www.webthatworks.it

I've been pondering this, and I think currency has a lot of parallels to time management.

Consider the PHP 5.2 DateTime object.  It stores the timestamp internally somehow, but you can't get to it.  A time unit can be formatted, or mutated to another timezone object.  Those operations are completely orthogonal.  The timezone mutator rules also change quite regularly, thanks to national governments that can't make up their minds.  Neither of those is usefully related to language or locality.

Currency is similar.  It can be formatted in a number of ways (with/without decimal, with comma-dot or dot-comma separation, with spaces separation, with currency symbol, with currency abbreviation, etc.) or mutated from one currency (timezone) to another.  The currency mutation rules also change rapidly.  Neither format nor mutation is reliably related to language or locality.

Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-)

--Larry Garfield