On Thu, 11 Oct 2007 18:17:15 +0200 "Gábor Hojtsy" <gabor@hojtsy.hu> wrote:
There are of course more things to set per language. This is why i18n module makes the site settings translatable. For example, there are three different date formats (short, mid, long) supported by Drupal, so each language would need a setting for all three.
OK... then somewhere based on Reyero's work I could add date format variables, float format variables etc...
What is the difference here between string localization and interface language? What's a string localization?
dates, float, I couldn't find a better name.
and use functions like
function drupal_number_format($number,$locale=null) { if(!$locale) { if(isset($user->string_locale)) { $locale=$user->string_locale; } else { $locale=locale_criteria($user->language,$node->language); } return number_format($number,$locale->number_format($locale)); }
where $locale->number_format[1] should return the string set into the admin/settings/locale for the proper locale.
Well, this code looks very messy. You call $locale->number_format
It is indeed ;)
like a function, but then use it like an array, but say it returns something. Also locale_criteria seems to be undefined (you did not
locale->number_format will be a localised variable of i18n (i18n_variables). locale_criteria should be a function that chose which locale apply to date, float, currency if user didn't make a choice based on other "locale" parameters (as $user->language and current content language). I do see a path that doesn't require me to solve the problem now and it looks reasonably slick... I just have to add to my module (the one not related to localisation) functions like this: i18n_number_format($float,$decimals=null,$language=null) { return number_format($float,$decimals,",","."); } for the Italian part I'm developing... then install i18n and build a module that will provide an interface to set the format for the most common things for each supported language, move all the functions in the new module and make them aware of the localised variable and the $user->language. locale_criteria could be retro-fitted even later... after all I just need to provide localised versions for dates, currencies and floats. I wouldn't have to change many functions... and the interface of the functions will remain stable. Then I could add validation of strings to pass to the php functions and have an install script that fill the most common format for the most common languages. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it