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

[Ivan Sergio Borgonovo]

On Mon, 22 Oct 2007 12:32:29 -0500
Larry Garfield <larry at garfieldtech.com> wrote:

> > Anyway I can't find a place in drupal for such a beast. (OK, I
> > may be wrong... but then tell me...).

> The most obvious to me: Instead of users selecting a timezone
> offset, they select their location from the built-in Olson
> database.  We then use DateTime and DateTimeZone to translate the
> base time we store into $users timezone.  It's more accurate than
> just an int offset, and handles Daylight Savings time for us as
> well.

> $date = new DateTime('@'. $node->created);
> $date->setTimeZone(new DateTimeZone($user->timezone));
> echo $date->format(...);  // This probably gets wrapped in
> format_date() or something that understands Drupal's "short" and
> "long" dates.

OK once they set it... it will "follow them". Got it, thx.

> > Once you ask... well you don't need the Olson bag with you.
> > Computations with dates should be a language task not drupal task.

> Dates have absolutely nothing to do with language.  I'm setting up
> a Drupal site now for a community site that is run in American
> English, but has people from 12 timezones, probably more if you
> consider that Indiana and Arizona are not in their "normal"
> timezones because of Daylight Savings, and similar world weirdness.

Format of time. And didn't we agree that timezone and format where
orthogonal?

> > I've the same feeling with currencies.

> As has been stated, currency has nothing to do with language,
> either.  There's a dozen Spanish speaking countries in the Americas
> alone that have different currency formatting rules.  

You've to guess at some point... language is a good starting I think.
Then they can tune it.
Somehow you should have a rough idea of your audience... maybe the
default currency format for Spanish in Latin America may be the same
as US. If you expect to have your main Spanish audience from Latin
America, you may set the currency format accordingly.
I feel it's better than just default to US format everywhere with
every language.
I'd like to build a path to add pieces a bit at a time and have
something that won't mess with further improvements.
Then you could delegate the choice of the default "locale" to
"smarter" functions (eg. GeoIP, GeoIP + Language, Language +
aruspices...).

> >> Well since I only started talking about it 2 days ago, not that I
> >> know of. :-) Really, I was just throwing out an alternative
> >> approach to take that would offer more long-term flexibility for
> >> currency handling.

> > Unless you take in Zend stuff I see no way to exploit all the info
> > you generally have in locale and locale settings are shared across
> > threads in the same process.

> Huh?  PHP on the web is not threaded.  What Zend stuff are you

It looks as on IIS it is multi-threaded. I can't swear on it.

> talking about?  I don't even know what you're talking about. :-)

http://www.nabble.com/Zend_Currency:-toCurrency-cutting-off-numbers--t4603219s16154.html
http://framework.zend.com/

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