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

[Larry Garfield]

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.  

In practice, of course, just like there's a DateTime::W3C formatting constant 
a fully-featured Currency Value Object would have a Currency::USD formatting 
constant that would be used for 80% of all use cases for the US dollar.

> You're not "mutating" one currency in another. You're just expressing
> a currency in the "locale" format.

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

> 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?  Who ensures 
that it's always restricted to two decimal points, and 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.  

-- 
Larry Garfield			AIM: LOLG42
larry at garfieldtech.com		ICQ: 6817012

"If nature has made any one thing less susceptible than all others of 
exclusive property, it is the action of the thinking power called an idea, 
which an individual may exclusively possess as long as he keeps it to 
himself; but the moment it is divulged, it forces itself into the possession 
of every one, and the receiver cannot dispossess himself of it."  -- Thomas 
Jefferson