Hi, 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( 'date_format_short', 'date_format_medium', 'date_format_long', 'date_first_day', // '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, variable_get('numeric_format_dec_point','.'), variable_get('numeric_format_thousands_sep',',')); } i18n_currency_format($number, $symbol='') { $tmp=i18n_number_format(abs($number), variable_get('currency_decimal',2) ); if($number<0) { $sign="-"; } $tmp=str_replace('d',$tmp, variable_get('currency_format','sd c'): $tmp=str_replace('c',$simbol,$tmp); $tmp=str_replace('s',$sign,$tmp); 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? thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it