[development] [VERY LONG] localization of currency, float, dates accordingly to language chosen

Gábor Hojtsy gabor at hojtsy.hu
Thu Oct 11 16:17:15 UTC 2007

On 10/11/07, Ivan Sergio Borgonovo <mail at webthatworks.it> wrote:
> > Hint: we did not do any taxonomy translation in Drupal 6, so they
> > are neither coupled or not.
> uh reading your thesis I thought you had implemented a sort of t()
> for taxonomy.

Well, my thesis is not a good reference on what is implemented in
Drupal 6. As I have explained, it was part of the work done for Drupal
6, but it is not authoritative to know what is excatly in Drupal 6.

> That's another module... doing something absolutely different from
> localisation but I need a bit of localisation right now (dates, float
> etc...) It would be nice if I could switch to drupal 6 smoothly.

There is no date or float localization built into Drupal 6. Date
localization will be done in contributed modules. There is no standard
way to print float numbers in Drupal, so it is harder to solve in
contributed modules.

> I could go straight to some hack functions in this module doing
> something completely different from i18n and just write 2 functions
> that take some variable defined in admin/settings and the user
> selected language for interface and format string accordingly.

Why would a user select format strings herself (ie. each user of your
site independently)? And a different interface locale?

> If these functions could be integrated in the future of drupal 6
> framework it would be better.

Drupal 6 is in bug fix mode, which means that we concentrate on fixing
bugs. New features go to Drupal 7 now.

> Ths is my rough idea:
> You provide a couple of cfg more in admin/settings/locale
> date format: "Y-m-d" float:... on each language line

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.

> Then you could add in each user profile
> user/1/edit
> Interface language:
> language:
> X
> Y
> Z
> follow content
> string localisation:
> X
> Y
> Z
> follow content
> follow interface

What is the difference here between string localization and interface
language? What's a string localization?

> 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 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
explain it). Understanding this would also require understanding what
string locale means.

> OK... you've read my rough proposal... any idea about how to make it
> Drupal 6 friendly/portable?

- Think about more settings. Doing solutions for dates and floats
might be interesting in itself, but there are other things to
localize, like currencies, the first day of week and so on. So
basically lots of settings need to be localizable in Drupal itself.
You can certainly solve your problems with some hacks, but they might
not be extensible.
- Think in a contributed module and Drupal 7. Drupal 6 will not be
improved in this direction, because it is too late for this now.
People are welcome to implement cool stuff in contributed modules, and
when Drupal 7 opens, it will accept feature patches from developers.


More information about the development mailing list