Re: [development] code proposal: localization of currency, ...
Ivan Sergio Borgonovo conveniently avoided considering the cheaper case: Let's try a concrete example. We have, let's say $0.02 Now, the user changes his language to French. Apparently, you're jumping to the conclusion that he must be a member of the "French people" -- that's wrong more that two thirds of the time, but if we leave that aside for the moment, what do you propose to do with those two cents now? Consider the same scenario in Canada -- what do you propose to do? There's also an Italian minority in the US, and I don't see why an Italian American shouldn't install the Italian UI translation as an option. So, how will you display those two cents?
Now the user changes his language to a) French or b) Japanese (hint: Yen amounts have no fractional part). What do you propose to do?
Use the float format for the Japanese audience to express Euros.
Oh, so when the going gets tough, you're proposing NOT to use your currency wrapper? But -- either we use it or we don't. We cannot not use it when the user changes to Japanese while at the same time use it when he changes to French, can we?
Will you expect to see:
[A] The current debt of US is $ 1.234.567.890,33
and
Il debito corrente degli US ? di $ 1.234.567.890,33
or you would expect something like:
[B] The current debt of US is $ 1,234,567,890.33
and
Il debito corrente degli US ? di $ 1.234.567.890,33
I'd expect [B].
When you have a simple algorithm, then you can always construct a simple example for which the algorithm yields the correct result. That doesn't prove anything. If you want to contribute something useful then it needs to work in all but the most exotic cases. And, no, I disagree. It doesn't matter in what language this is published, but it depends on where it's published. If it's a US publication (whether in English or in Italian) then it should use US formatting, and if it's published in Italy (whether in English or in Italian), it should use Italian formatting.
I would consider confusing having content and interface in one language and currency and number format expressed in a format that's not proper of that language.
I agree. But who says that content and interface needs to be in the same language. Drupal makes it easy to switch the interface. Supplying all of your content in multiple languages is much much harder. If you tie the currency and number format to the interface language, then you get exactly what you say you would consider confusing: users with different interface languages see the same content with different currency and number formats! Please take this in and try not to ignore it!
Is anyone using localisation without i18n module and then mixing content in different languages just providing translation for the interface? Any case history of such kind of setup?
I can't point you to a specific site, but if a site has a sizable minority that likes to use another language, then why not throw in a UI translation to make it easier for them to find their way on your site?
To me the localisation module alone can be used just for mono-language websites.
So there shouldn't be a mix of [...]
Why not? Because it doesn't suit your view of the world? Italian websites and only Italian websites for Italians only? If you're serious about doing I18n/L10n then you definitely need to broaden your view! Supporting "a mix of ..." is what I18n/L10n is all about. Hans
to skip the non technical (use case) part go to #tech On Fri, 19 Oct 2007 06:15:45 +0200 Hans Salvisberg <drupal@salvisberg.com> wrote:
Ivan Sergio Borgonovo conveniently avoided considering the cheaper case:
Actually it seems you're avoiding to consider the most common case in which float and currency are displayed accordingly to the context of the language used by the audience.
Let's try a concrete example. We have, let's say
$0.02
Now, the user changes his language to French. Apparently, you're
If you've such problem you'll provide a Canadian content. That will be French content, French interface and "Canadian" formatting of currencies. If you want to provide French content to French people too, with French formatting, that's another issue since at my current knowledge of i18n module you'll have to duplicate content. That's not nice, but feasible, but the problem doesn't reside in providing a formatting facility rather in i18n[1].
There's also an Italian minority in the US, and I don't see why an Italian American shouldn't install the Italian UI translation as an option. So, how will you display those two cents?
I'm not aware of any community writing Italian with Chinese formatting for currency and Swahili interface.
Oh, so when the going gets tough, you're proposing NOT to use your currency wrapper? But -- either we use it or we don't. We cannot not use it when the user changes to Japanese while at the same time use it when he changes to French, can we?
I'm not aware of any core functionality that output 2 different currencies in the same page for 2 different audience. If you're writing a module that display CHF for French people and USD for American people in the same place it is up to you to decide which format your audience will find less puzzling. Having a formatting function won't make it harder in any way. Actually it will still help.
When you have a simple algorithm, then you can always construct a simple example for which the algorithm yields the correct result. That doesn't prove anything. If you want to contribute something useful then it needs to work in all but the most exotic cases.
The most exotic cases are MRO and MGA. Expressing any other currency in their format wouldn't have any meaning.
And, no, I disagree. It doesn't matter in what language this is published, but it depends on where it's published. If it's a US publication (whether in English or in Italian) then it should use US formatting, and if it's published in Italy (whether in English or in Italian), it should use Italian formatting.
You could do it. Provide the English formatting in the setup interface even for Italian interface. I don't find it particularly reasonable as 99% of the publications don't follow this rule but you're free to do it. So... that is a no problem. If you have mixed language content and you didn't care about installing i18n and you want uniform formatting of currency and float... they will be uniform... cos without i18n there will be just one version of the variable specifying the format. If you've installed i18n and you want Italians see Pounds formatted in Tanzanian way, you could do it too.
I would consider confusing having content and interface in one language and currency and number format expressed in a format that's not proper of that language.
I agree. But who says that content and interface needs to be in the same language. Drupal makes it easy to switch the interface. Supplying all of your content in multiple languages is much much harder.
That's the purpose of i18n and its facilities. If you write a module with currency wrapped around formatting functions that may know about i18n (or just about your float formatting) they could be localised no matter what your strange idea of localisation is: French formatting in Italian interface with Chinese content. Otherwise you'll have modules and core outputting invariably with... US format. Did you stop for a while thinking about the current situation? You can decide how to output dates... but everything else will output in US format and you can't change it globally. If you mix content without the help of i18n it is up to your business to decide which format is less puzzling to your audience.
If you tie the currency and number format to the interface language, then you get exactly what you say you would consider confusing: users with different interface languages see the same content with different currency and number formats! Please take this in and try not to ignore it!
uuuh exactly... but currently this is the only choice they have... Please take this in and try not to ignore it! With a wrapper they: - have a US site with US formatting, US content, US interface - could still provide French site with mangled interface as it is now since there is no support for localisation of currency/float. - decide that if the site is a French site with a French interface, it would be nice to show currency and dates and float the French way - decide that they are too lazy to install i18n and provide French, and English content mixed up and one way to format float, currency, dates (no matter if they decide the best way is Cambodian for English and French audience) - use i18n and provide what they like for each interface content pair - use i18n and decide that *that* float in *that* page/module doesn't have to be formatted accordingly to the current set language but accordingly to another provided it is defined. - use i18n and decide that *that* float in *that* page doesn't have to be formatted accordingly to the current set language but accordingly to Klingon that is not specified in the supported language list and provide their own function to format float coming from a DB and format it in Klingon. The only situation I can see some real confusion is when people with i18n installed will want to read language "agnostic" nodes. Nodes that haven't been assigned a language and that should be available to anyone without changing the language. Of course such kind of node belong to the "not translated" but available to everyone. But knowing the singularity, when you build such nodes you may override the default interface language as you could see I proposed: format_currency($number, $symbol, $language=null). Modules should be built with the idea they should be translatable... if they are not it is just a missing feature in the module not something wrong with the facilities you could provide.
Is anyone using localisation without i18n module and then mixing content in different languages just providing translation for the interface? Any case history of such kind of setup?
I can't point you to a specific site, but if a site has a sizable
That's a clue. Have you ever build a multi-language site?
minority that likes to use another language, then why not throw in a UI translation to make it easier for them to find their way on your site?
So what? At this moment you can just output in US format... no matter! If you're in Switzerland where people use several languages but up to my knowledge the same float/currency format... you'll be stuck with US format no matter. And you've a huge inheritance of modules that will continue to output in US format only unless you provide some general facility that let them switch the format accordingly to what the owner of the site decide is best. Module writers may decide to avoid wrapping if they think the content they provide through their module is not suited to be localised or if they think the wrapper can't handle the complexity of the content they provide.
To me the localisation module alone can be used just for mono-language websites.
So there shouldn't be a mix of [...]
Why not? Because it doesn't suit your view of the world? Italian
Let me put it more clearly. Localisation module is best suited for mono-language sites. If you're going multi-language is definitively advisable to use i18n. What the hell have you seen around till now? I'm aware of blogs that mix Italian and English in the same place but they aren't nice to see and I consider rude posting in English in an Italian forum or in Italian in an English forum. People are mixing content just because they ignore how nice drupal i18n is compared to anything else I've seen... i18n should actually be more advertised by drupal community. This is a killer module compared to what other CMS have.
websites and only Italian websites for Italians only? If you're serious about doing I18n/L10n then you definitely need to broaden your view! Supporting "a mix of ..." is what I18n/L10n is all about.
Exactly... so why are you insisting people shouldn't have an option and continue seeing stuff just formatted US way? #tech I think this kind of support should be available independently from i18n for mono-language sites and I gave some example on how it could be used even without i18n support but if no sign of acceptance/suggestions come out I'm going to write it as if it was part of i18n with function names in their own "namespace". Starting with the right foot and giving them a more "corish" name would make it easier to be included in module development. If no suggestions for better acceptance comes out shortly I'll start to write an interface for setting up this stuff and the functions. If someone is aware of some more strangeness of float/currency formatting let me know. Suggestions for the formatting string for currency are also welcome. Especially a way to specify character that shouldn't be outputted in case the number is positive. Is there anything more than: general scientific accounting notation for float/currency. I'd think that accounting rules are rather specific to each country and accounting modules would be specific for a country and let the developer take care of the problem independently of the interface/language. As well as I'll keep scientific notation in US format. Anyway in spite of adding one parameter to format_number I could just write format_scientific and format_??? later to avoid messing up with signatures and over planning. At this moment I'm aware of people using different char for grouping and different size of grouping (eg. 1 23 45 to write what US people would write as 12,345). Providing support for such formatting is a bit more overhead cos you can't use directly php format_number. Can anybody confirm that there are some places where they group differently? Is anyone scared about the extra overhead of an if clause if grouping is != 3 so that most common case could be optimised with format_number and everything else use a custom function? Is it worth to support this cases? Still they can be supported later without changing the signatures of the functions. BTW I'm already using i18n and custom date format for each language and it works like a charm thx [1] as a matter of fact Drupal is providing one of the best framework for internationalisation I'm aware of. It doesn't mean it can't be improved. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (2)
-
Hans Salvisberg -
Ivan Sergio Borgonovo