[development] code proposal: localization of currency, float, dates accordingly to language chosen

Ivan Sergio Borgonovo mail at webthatworks.it
Tue Oct 16 20:38:11 UTC 2007


I'm in the process to really develop something that could be useful
and I'd like it integrates well in i18n and core.
Code is definitively trivial. Putting it in the right place with the
placet of core and i18n developers may not be.

General idea is
- add some field in $conf['i18n_variables'] (core dev don't run
away... more later)
$conf['i18n_variables'] = array(
//      'number_format_dec_point',
//      'number_format_thousands_sep',
//      'currency_format',
//      'currency_decimal',

- push some more fields in admin/settings/date-time to provide
currency and float (and maybe other format localisation).
Page title is not appropriate but it looks as the best place.
This may require some coordination with drupal core (why shouldn't a
non multilingual website miss custom float format?[1])
Anyway if stuff comes into the way this variable may have their
separate place in a new admin page.

- write functions like:

i18n_number_format($number,$decimal=0) {
	return number_format($number,$decimal,

i18n_currency_format($number, $symbol='') {
	if($number<0) { $sign="-"; }
		variable_get('currency_format','sd c'):
	return $tmp;

I know some countries don't group thousands but hundreds. Writing a
more complex function shouldn't be a problem. Any other variations?

I wouldn't put $symbol in i18n_variables since you may output
different currencies in the same site/table...

format_date is already there in core...[1]

[1] style would suggest to cut the i18n prefix and put general helper
function in the same place as format_date
I used the *_format just to mimic the php functions but if they get
into core format_* looks a natural choice.

If this stuff has a chance to get into system.inc (or anywhere else
into core) it will work even without the i18n module as it does with
format_date. If i18n is installed, it will work better.

Just reaching an agreement on functions names and signatures would
help to add the features smoothly, step by step...

format_date can be chosen on a per user base. This makes everything a
bit more foggy... but I wouldn't see as mandatory to have the same
feature for currency_format etc...
What was the rationale of having format_date on a per user base?

comments? suggestions? RTFM? RTSL?


Ivan Sergio Borgonovo

More information about the development mailing list