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

[Ivan Sergio Borgonovo]

On Sat, 20 Oct 2007 11:02:34 -0500
Larry Garfield <larry at garfieldtech.com> wrote:

> On Friday 19 October 2007, Ivan Sergio Borgonovo wrote:
> > On Fri, 19 Oct 2007 11:20:27 -0500
> >
> > Larry Garfield <larry at garfieldtech.com> wrote:
> > > 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). :-)

> > Pardon my ignorance, do you have the patience to explain?
> > but... you're putting all this responsibility on the site
> > administrator that would specify a string to format it.

> Correct, because there is no definitive "Pounds Sterling are always
> always always displayed in this format" rules.  Different
> clients/use-cases will want it done differently.

> In 2 years, I'm not sure if I've ever had 2 clients ask for their
> dates to be displayed in the same format... and they're all in the
> Midwestern US! :-) While currency doesn't have as much variation,
> from earlier on this thread it certainly looks like there's a fair
> bit.  

So, since they will have a "format string" in the admin panel they
will format stuff as they wish, even the same format for all the
languages.
Sure enough you could have in the same site:
- float for bathing
- float for summer
- float for fun
- ...

but this won't block people from taking advantage of a localised
float/currency etc... all over one language section of a web site.
99.9% of sites will need coherent format across a language section
and not 99.9% of the web sites will like to have US format as only
choice.

> No, I'm making a distinction between mutating (which involves
> exchange rates, which fluctuate hourly) and formatting (which is a
> string representation of whatever the current decimal is in some
> format or another).  Yes, mutating is probably not a task for

as you said they are orthogonal.
The application programmer will provide the "number" as it has to be
(already rounded, with the correct exchange ratio bla bla bla), the
administrator will provide has it has to be formatted for every
language/localisation).
The application programmer won't have to code for *every*
localisation most of the time... and if it has to... he could.

> core.  In fact I thing this whole set of functionality belongs in a
> Money API module of some sort (there's that TLA again! <g>).  I am
> primarily drawing parallels between the complexities of currency
> and the complexities of time.

> > Maybe we should express locale in a more complex way: language +
> > "localisation" so that English may be Canadian, UK or US... with
> > some system to avoid content duplication

> If I'm a stock broker, then my location/timezone is New York, my
> language is Spanish (if I'm an immigrant), and I want money
> displayed in 18 different currencies using international
> abbreviations (EUR, USD, etc.)  Binding the format to a locality or
> language is going to fail at dozens of edge cases.  

The signature of the localisation function take the "symbol" as a
parameter. You're providing a way to format the currency, not to
compute it.
The site will be displayed in Spanish, with Spanish format of
currency. If "Spanish" means some of the Latin American countries
that may have a different format for currencies... let it be...
As since the symbol is passed as a parameter you'll have something
like:
1,234.56 EUR
1,234,56 USD
or
EUR 1.234,56
USD 1.234,56
or
1 234,56 EUR
1 234,56 USD

I find it unreasonable to write in the same page:
1,234.56 USD
1 234,56 EUR

And in that case you're not dealing with localisation, you're just
mixing up everything, you may have your reasons but I'm thinking of a
facility that will let module writer "localise" their module if they
*can* be localised... if they can't they will deal with it.
Anyway the format functions will support a "language" parameter that
will override the current user language.
At this moment module writer can just display things in US format
*or* write their own format functions for the language they are
willing to support even if *most* of the time you're just willing to
write
1,234.56 EUR
vs
1.234,56 EUR

> > Are you referring to exchange rate? That will be an issue of the
> > application programmer.
> > I'm not interested in an object to store currency... currency will
> > appear magically in a variable (task of the app. programmer) 

> Variable of what type?  With what properties?  String or double?

It is up to the application programmer to provide the correct number
already rounded. I'd pass integers + the # of decimals.

> Who ensures that it's always restricted to two decimal points, and

Passed to the format function.
My fault, I put the number of decimal in the wrong place.
It shouldn't be in the administrative interface rather in the format
function:
format_currency($number, $decimal, $symbol, $language=null)

I'd limit the scope of this stuff just to *format*.
Like PHP number_format but that add symbol and sign position.

> based on which rounding scheme (there are several, actually)?
> There's a lot of logic here that can/should be encapsulated and
> generalized.  That's exactly what Value Objects are good for.  (I
> don't mean object on the level of Node or User or other Assets.
> I'm talking about more general OO concepts.)

> > and they 
> > have to be formatted accordingly to the locale (maybe a wider
> > concept than what locale is now).

> My current locale settings have little bearing on the type of money
> I am dealing with.

> > I'd put date/currency/whatever object out of drupal. 

> Then you're just guessing about how to format float numbers, which
> is an inherently 

> > I think it's not 
> > the task of a CMS to "understand" content unless you're obliged
> > too. So why should you provide a currency object?

> ... How is it not a CMS's job to understand content?  Drupal knows
> a huge amount about its content right now.  

By necessity not by will I hope. The more knowledge you spread in a
system the more you make it interdependent and entangled.

What I mean is that drupal should know as less as possible about what
dates, currency and float are and *why* they have to be formatted in
some way (eg. parenthesis vs. sign etc...) this should be up to the
site administrator, to provide the right format string and to the
application programmer, even rounding is not a task drupal should be
aware of, nor exchange rates and timezones; or at least it may
provide the information to the application programmer, but it
shouldn't know how and why it is used.

I'm not proposing a catch them all solution and I think this facility
won't get into the way of people. But at this moment every module
writer that would like to "localise" float, currency and date
format, should read the language variable, write a function that chose
a format *for every language he want to support* (not every language
the site *actually* support, but really a function aware of every
language he want like to support).
The net result is:
- no one is willing to get into this mess so no module is localised
- if any is localised there will be a lot of duplication of code
- everyone will provide his own format for float in French so that
pages will display float differently accordingly to the module writer
idea of what the French format is, if French format is supported at
all by the module writer that maybe decided to support just Malay and
Bergamasco.
- site administrators/builders won't have control on the format

Surely a module writer may have HIS reasons to have HIS idea of what
is French format and HOW to deal with currencies... but these
facilities won't stop him, that is actually dealing with a special
case and should be aware of what he is doing, to provide HIS OWN
solution to HIS OWN problem.
If demand for special format will be high enough you could add:
- scientific float
- accounting currency
- etc...
People writing modules will know what will happen to their
currency/float if they wrap them with the formatting functions.
If they think it doesn't work for them they could avoid it.

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