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

Larry Garfield larry at garfieldtech.com
Sun Oct 21 17:27:14 UTC 2007

On Sunday 21 October 2007, Ivan Sergio Borgonovo wrote:

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

I think I see the disconnect here.  You're talking about a site admin level.  
I'm speaking strictly of a general code-level currency mechanism.  The actual 
format string that would be passed in, yes, would come from variable_get() or 
something like that so that it's the same site-wide, just like were we to use 
DateTime in Drupal 7 (which I highly encourage) we would not, presumably, 
have every module author calling ->format() with their own string.

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

That's where good use of design patterns helps you keep the system smart but 
decoupled. ;-)  (It is relevant that a given field is a date field or a SSN 
field; it's not relevant to every single function that touches that 
structure, however.)

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

Again, it seems we're addressing different problems.  You're after a float 
version of the date() (or format_date()) function with site-wide defaults.  
I'm talking about currency as its own value entity independent of the 
administrative settings, on top of which defaults could be built.

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 

More information about the development mailing list