localization of currency, float, dates accordingly to language chosen
Is there a site-wide facility (core or module 5.2) to output formatted currency, float and dates accordingly to the language chosen by the user? Anything that could be integrated with i18n or localizer[1]? If I had to provide site-wide functions that just read user or session cfg for language and apply proper formatting where is the best place to put them? [1] any other choice? thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
The Money CCK field module[1] supports custom decimal and digit group separators, as well as any currency. AFAIK, that's the closest you can get. Obviously, it's still a static setting and doesn't offer language dependencies, so it doesn't really meet your requirements. [1] http://drupal.org/project/money Wim Leers ~ http://wimleers.com/work On Oct 10, 2007, at 11:02 , Ivan Sergio Borgonovo wrote:
Is there a site-wide facility (core or module 5.2) to output formatted currency, float and dates accordingly to the language chosen by the user?
Anything that could be integrated with i18n or localizer[1]?
If I had to provide site-wide functions that just read user or session cfg for language and apply proper formatting where is the best place to put them?
[1] any other choice?
thx
-- Ivan Sergio Borgonovo http://www.webthatworks.it
On 10/10/07, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
Is there a site-wide facility (core or module 5.2) to output formatted currency, float and dates accordingly to the language chosen by the user?
Anything that could be integrated with i18n or localizer[1]?
If I had to provide site-wide functions that just read user or session cfg for language and apply proper formatting where is the best place to put them?
[1] any other choice?
- currencies are easy if the module in question has that in t(), like t('@symbol @amount') can be translated to '@symbol@amount' or '@amount@symbol', although I am not sure you mean this by currencies - float numbers are printed with number_format(), or they should be at least, which does not support different formatting based on languages. Feel free to suggest new functionality to do this, which can be tested in real life scenarios in D6 and integrated to D7. - date formats are Drupal settings and as such are translatable with the settings translations features of i18n and localizer Gabor
2007/10/10, Gábor Hojtsy <gabor@hojtsy.hu>:
- float numbers are printed with number_format(), or they should be at least, which does not support different formatting based on languages. Feel free to suggest new functionality to do this, which can be tested in real life scenarios in D6 and integrated to D7.
If anyone picks this up, ping me and I'll be sure to aid however I can! Also, for whomever picks it up, I once brought this subject up in connection with the translation of LiveJournal, which in turn resulted in some intelligence gathering on the subject, which should be reusable: http://lj-translate.livejournal.com/lj_translate/120222.html http://lj-translate.livejournal.com/lj_translate/120573.html -- Frederik 'Freso' S. Olesen <http://freso.dk/>
On Wed, 10 Oct 2007 22:32:17 +0200 "Frederik 'Freso' S. Olesen" <freso.dk@gmail.com> wrote:
http://lj-translate.livejournal.com/lj_translate/120222.html http://lj-translate.livejournal.com/lj_translate/120573.html
Both took me to a 404. I was curious to know if I just was going to send a lot of bullshit to the list and someone already found a lot of pitfalls in my approach or not... Long email waiting into the pipe... -- Ivan Sergio Borgonovo http://www.webthatworks.it
2007/10/11, Ivan Sergio Borgonovo <mail@webthatworks.it>: <zap - links to a wee bit of discussion on the topic of float number formatting on LiveJournal>
Both took me to a 404.
D'oh. They should, of course, be http://lj-translate.livejournal.com/120222.html http://lj-translate.livejournal.com/120573.html Sorry 'bout that. :/ -- Frederik 'Freso' S. Olesen <http://freso.dk/>
On Wed, 10 Oct 2007 16:29:19 +0200 "Gábor Hojtsy" <gabor@hojtsy.hu> wrote:
- currencies are easy if the module in question has that in t(), like t('@symbol @amount') can be translated to '@symbol@amount' or '@amount@symbol', although I am not sure you mean this by currencies
I've to dig more into t(). I'll see if I can bend it to my needs but the following paragraph doesn't give me too much hope.
- float numbers are printed with number_format(), or they should be at least, which does not support different formatting based on languages. Feel free to suggest new functionality to do this, which can be tested in real life scenarios in D6 and integrated to D7. - date formats are Drupal settings and as such are translatable with the settings translations features of i18n and localizer
uh you gave me the chance to pontificate... why should I miss it? ;) Ready for a full Encyclic? I've used i18n in the past (4.7?) and I had mixed feelings. I've read about localizer and I like some of its feature and some of the idea of the author, mainly: different language version of the same web site should be very lightly coupled. First I'd say there are 3 kind of users of a cms: readers, editors and programmers. I'd sum up what I expect: - currency, dates, float in the localised format (measures too? maybe later lbs to Kg??? why not?) - avoiding duplication of code ( t() + the former should be enough ) - building bridges between content in different languages (more on this later) - SEO ( people won't actually remember urls (nearly sure) and rarely they will read them (less sure) ) Having a multi-language site means: - avoiding code duplication [ t() + localised numbers/dates ] - help people switch language I don't think editors need (may have) to much help (more on this later) Avoiding code duplication helps programmers. Helping people to switch language is useful just for people that know more than one language. I think people switch because they find something in one language and they would like to know if there is more/different content on the same topic in another language. The switch may be from mother tongue to foreign language or the opposite or from any foreign language. You're Italian, you know French, you look on a search engine in French (cos you know the topic is *very French*, then you see there is Italian content etc...). You land on Italian content then you see there is more material in English and you'd like to switch... They look for the same stuff they were looking... just in another language... you've to provide bridges between similar or when possible same content across languages. Based on my experience different versions of a web site may grow up with completely different speed, have slightly different content etc... so the coupling should be very light. So I took care of programmers and readers. Now a brief parenthesis on editors. If editors ignore their site is multi-language... each version will take it's way so it won't actually be a multi-language site, you just have to provide facilities to programmers and content will be so lightly coupled there won't be any automatic way to help people switch between different languages. If editors will be conscious the site is multi-language they are the one who will need the facilities to build bridges between languages. OK... let's get a bit more technical and provide some details. First let me court the category I belong to. Programmers don't provide content... they provide the interface. Interface has few content to be translated. Programmers don't have to be distracted by translations while coding. I think providing functions that format the usual things accordingly to the language set could be something that can be introduced smoothly. People will just have to surround stuff with those functions. If they do, they will have localised output, if they don't they will have what they were having in the past. As you'd expect for t() vs. simple strings. Everything including modules can be updated gradually. t() is perfect as it is and I'd consider t() just for the interface and not for the content. ids are too hard to remember. t('this_is_the_id_of_a_sentence_that_was_shorter_than_the_id') Maybe one transparent addition to t() could be to change the "base" language, so that people could input something like t('frase','it'), so that programmers could concentrate on coding and not thinking in something that's not their mother language. I understand the extra cost of adding indexes to the translation table but maybe some programmers may appreciate it. I'm not among them... but maybe some may appreciate it. I need localised formatting shortly and I'm willing to write it. To me it looks a no-brainer if I knew: 1) where to put it to be sure to make those functions available everywhere 2) which variable should be chosen to decide which language is set for the session. I'd do it kosher. If it is not clear where to put this stuff, fortunately the code where I need this stuff is well defined and I can write some terrible hack without too much shame in the module I'm just writing for other purposes. To be clear about the second point there is content and there is interface: people may want to have interface in their language and read content in others. If no specific choice is made by the reader how you decide which interface you should use is a bit tricky but I think is just a matter of "taste". At first landing time you could chose: 1) according to the browser cfg 2) according to the language of the content but what if the user switch language? Should you change the interface and the content, just the content and keep the interface in sync with the browser cfg... Anyway you've to provide a clear path to the user to switch the interface let them know they can switch content and interface independently. I would pair interface (menu etc...) and number, currency... localisation. Differentiating between localisation of currency, dates, float and interface is very flexible but I think could be even confusing. So a function that localise dates, float etc... should take as an argument a function that decide accordingly to browser settings, setup of user profile and a policy defined through settings in the admin interface which format should be used. In the admin panel it should be possible to add languages and add format strings for dates, float etc... Content language shouldn't be a "variable" as content should be lightly coupled. Content language should be similar to the root of a taxonomy, language facilities should just help people to move between different taxonomies/languages. People should be helped to land on the "right" language and then be helped to stay focused (filter by language) on the content of that language till they want it (it.site.com, en.site.com, site.com, site.it, browser setting etc... + collapse taxonomies). There are stuff that actually aren't categorised so "language" shouldn't actually be the root of different taxonomy, you may have important content that you didn't have the chance to translate and you want to show it to everyone too. You assign a language or a jolly to every node and a language or a jolly to a vocabulary then you build bridges between taxonomies and nodes. So language should be a propriety of vocabularies and nodes and there should be a jolly language. Jolly language should be a "not filtered language". Let's see what I'd expect when people switch language. First there should be a language selector block. People could surf nodes or taxonomies. When they switch... they should land on the most similar content in the different language. You could have a one to one mapping between nodes or you could slide to the nearest bridge editors built between taxonomies. As if you had 2 different trees, you could decide to make a one to one mapping between leaves and branches or you could link just some branches of the 2 taxonomies... The algorithm should go down towards the root till it find a bridge and cross it. So if there is not perfect match the user will be taken to the most similar content available. Let's come to the editors... Editors have 3 tasks: - writing nodes - building the taxonomies - building bridges between taxonomies Oversimplifying you may have people responsible for just one or more tasks and different access right. So it is important to decouple as much as possible these activities with a look at performances too. I think localised URLs have lower priority but they are a strategical decision and may be a PITA. I don't think people remember URLs, they may remember http://www.mysite.com/blog or http://www.mysite.com/gallery but once you get in things like http://www.mysite.com/literature/modern/italian/war/biographies/ I doubt people can really remember such things... But there is a but... a) search engines do read URLs to rank pages b) some people do read URLs to rank pages for high ranking content language and URL language should match. URL automatic translation has no sense as there is no sense in automatic taxonomy translation. i18n module used a cheap trick to build a bridge between nodes: same url with language prefix. No DB access and a 404 if nothing there. You could build a custom 404 to redirect the user to some related material in the other language... etc... With URL translation you have to add a DB access. From the editor point of view there is no difference... or maybe... a new system may even be better, maybe the new i18n already implement something similar. Editors that are aware of working in a multi-language site with previous i18n system had to know the url of the going-to-be-translated article and put it into the path alias... so there won't be any extra cost in finding the original article and add a button and a drop-down to "add a translation", just to add a link between the 2 nodes. Engineering the DB structure to provide an efficient way to store this link shouldn't be terribly hard. Taxonomy could be filled automatically as the best match reaching the nearest bridge between the 2 taxonomies. This system should provide a way to add such link not just at creation time. A good interface for linking 2 nodes may be a bit more tricky. Similarly there should be a way to link different branches of taxonomies. Not all branches should be linked... you could build a one 2 one match or taxonomies may grow up semi-independently... An algorithm should go down the tree till it finds a bridge to cross and present the content on the other tree. Editors should edit menu too... but menus aren't taxonomies... they may contain taxonomies but they not. Menu may be different in different languages (maybe some services aren't provided in all the language... Again... I'd have localised menus merged with a jolly menu and taxonomies. In a multi-language site tools for mass editing of taxonomies may come handy... language version tend to diverge, then you try to make them converge once more and you may have to move branches of taxonomy around... but this is "independent" from "core" localisation functions. Localised menu will be "hand written" and have an assigned language. Jolly menu may use t(). And taxonomy menu will use the same rules as taxonomies. Menus, with the exception of taxonomy menus aren't so large you can't deal with them manually. Cherry on top would be to signal if there are one to one matches for nodes so you'll know if switching language will take you to the same content or just to the most similar content. At the interface level that could be made highlighting the flags of the switching block if there is matching content in those languages. But once you've a function to inform you there is matching content... everyone could build up his interface of choice I see media duplication just as a problem of node interface. If people can chose if uploading to the server or choose from the server there shouldn't be any problem of media duplication across different languages unless they have to be different media. oh... and someone more knowledgeable should take into account RTL language too... I've no idea of the problems involved in such kind of localisation. I wrote few pages in Simplified Chinese in a multi-language website and I didn't have any problem, so Chinese at least as an exotic language for us European doesn't seem to be an issue. I didn't test localisation function for dates and currency. I didn't have the need for them. I remember HKLUG uses drupal too and it uses i18n module. They helped me to install Chinese localised Linux for my wife and they suggested me a great Linux router mmm more than 6 years ago I think. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 10/11/07, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I've used i18n in the past (4.7?) and I had mixed feelings.
I have read all your email through in the hopes that I will be able to reply, but I would sit here all morning, through to lunch to reply to all your points (two hours to lunch now), so let me give you some pointers instead. It is a good idea to look what is the actual state before throwing (good!) ideas around about how things should be done, and how simple are those actually. I'd suggest you check out the latest i18n and localizer modules (for Drupal 5) as well as the stock Drupal 6 development version which in itself solves lots of problems, including URL aliasing, specific domain names per language, browser language identification and so on. Download Drupal 6-dev here: http://drupal.org/node/97368
First I'd say there are 3 kind of users of a cms: readers, editors and programmers.
I'd sum up what I expect:
Well, yes, there are some specific expectations you have which root in what specific form of multilanguage site *you* are thinking about. There are obviously other and sometimes conflicting needs as well, depending on whether you build a blog, a brochure site, a community site, a social networking website or the online version of a newspaper, and you also need to take into account whether you have internal staff to translate your content, or you employ translation firms, and in the end how much of your site would be translated. Some sites have strict workflows for translations (ie. it is not possible to publish some text until it is available in a few official languages), while others grow more organically, and news items posted from around the world are matched together as translations of each other by some human. To cater for these types of sites, we need wholly different interfaces optimized for the specific tasks. It is quite hard to solve these problems for all the types of sites involved, so Drupal tries to provide a framework, in which site implementors can tailor their solutions to the specific needs. I tried to touch on some of these models (but not close to all of those) in my thesis, which was part of the effort in building up the multilanguage support in Drupal 6: http://hojtsy.hu/files/GaborHojtsyThesis.pdf
oh... and someone more knowledgeable should take into account RTL language too... I've no idea of the problems involved in such kind of localisation.
Well, let me point you again to our latest Drupal version (still in bugfixing), and because we look for improvements to develop from that point, continue any discussion there. Drupal 6 is definitely not a complete multilanguage suite yet, and although it does implement lots of things from which you explained, it leaves room for contributed modules to implement the others. Gabor
On Thu, 11 Oct 2007 10:48:09 +0200 "Gábor Hojtsy" <gabor@hojtsy.hu> wrote:
On 10/11/07, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
I've used i18n in the past (4.7?) and I had mixed feelings.
I have read all your email through in the hopes that I will be able to reply, but I would sit here all morning, through to lunch to reply to all your points (two hours to lunch now), so let me give
Thanks for your interest.
you some pointers instead. It is a good idea to look what is the actual state before throwing (good!) ideas around about how things should be done, and how simple are those actually. I'd suggest you
Your thesis was enlightening about all the new features and solutions and current status. After reading your email and your thesis I still have some critique but I'll follow your suggestion and find the time to install Drupal 6. My general feeling is that translations and taxonomies are too highly coupled... I won't comment further without some more knowledge on my part of the current status, but I think you got an idea about what I mean from my previous email. Reading your thesis I got more conscious about why translations looks so coupled but well we both have a lot of stuff to digest and I'll wait better moments to get into details. I ask you just a bit of patience more for my rudeness but at this time my module is agnostic of the drupal version and non Italian content still have to be thought... but I need a smooth path to have localised strings (dates, float, currency...). Any help on this? I read in your thesis: "Local functionality By implementing a custom install profile, I distributed the Hungar- ian interface translation with local functionality for Hungarian date format support and features for common hosts, beginning with Drupal 5.1 [38]." Just dates? what about float? is this stuff already ready and hidden somewhere in the source of 5.2? thanks a lot, great work. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 10/11/07, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
My general feeling is that translations and taxonomies are too highly coupled... I won't comment further without some more knowledge on my part of the current status, but I think you got an idea about what I mean from my previous email.
Hint: we did not do any taxonomy translation in Drupal 6, so they are neither coupled or not.
I ask you just a bit of patience more for my rudeness but at this time my module is agnostic of the drupal version and non Italian content still have to be thought... but I need a smooth path to have localised strings (dates, float, currency...). Any help on this?
From what you explained, your module might solve all Drupal i18n problems, so it is probably too complex for me to look at. Although I have not seen any from that, so it is quite hard to give any suggestions.
I read in your thesis: "Local functionality By implementing a custom install profile, I distributed the Hungar- ian interface translation with local functionality for Hungarian date format support and features for common hosts, beginning with Drupal 5.1 [38]."
Just dates? what about float? is this stuff already ready and hidden somewhere in the source of 5.2?
I needed Hungarian date support + I did not need to modify how floating point stuff is presented + Nobody else contributed that = It is not there. Gabor
On Thu, 11 Oct 2007 16:34:52 +0200 "Gábor Hojtsy" <gabor@hojtsy.hu> wrote:
On 10/11/07, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
My general feeling is that translations and taxonomies are too highly coupled... I won't comment further without some more knowledge on my part of the current status, but I think you got an idea about what I mean from my previous email.
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.
I ask you just a bit of patience more for my rudeness but at this time my module is agnostic of the drupal version and non Italian content still have to be thought... but I need a smooth path to have localised strings (dates, float, currency...). Any help on this?
From what you explained, your module might solve all Drupal i18n problems, so it is probably too complex for me to look at. Although I have not seen any from that, so it is quite hard to give any suggestions.
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. 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. If these functions could be integrated in the future of drupal 6 framework it would be better. 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 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 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. for my need I'd just set the locale the same as the language of the user. so I'd write mockup that have reasonable default param and some empty function to return always the same stuff so I could keep the outermost function interface constant. [1] I saw that these values get stored into {locales_meta}, but I didn't have the time to see in which object they are stored or what is the halal way to get them through drupal api.
I read in your thesis: "Local functionality By implementing a custom install profile, I distributed the Hungar- ian interface translation with local functionality for Hungarian date format support and features for common hosts, beginning with Drupal 5.1 [38]."
Just dates? what about float? is this stuff already ready and hidden somewhere in the source of 5.2?
I needed Hungarian date support + I did not need to modify how floating point stuff is presented + Nobody else contributed that = It is not there.
OK... you've read my rough proposal... any idea about how to make it Drupal 6 friendly/portable? -- Ivan Sergio Borgonovo http://www.webthatworks.it
On 10/11/07, Ivan Sergio Borgonovo <mail@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. Gabor
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
participants (4)
-
Frederik 'Freso' S. Olesen -
Gábor Hojtsy -
Ivan Sergio Borgonovo -
Wim Leers