Re: [development] code proposal: localization of currency, ...
What I'm trying to say is that any attempt to select a currency format based on the language choice of the user is misguided. Ivan Sergio Borgonovo wrote:
Forget about currency. Currency is completely unrelated to the user's language, and it certainly shouldn't change, just because a user changes their language.
Well you can express amounts in dollars, euros, yuan with different formats as you express floats.
Sure you /can/ do anything, but you're doing a disservice to the community if you introduce a flawed feature that well-meaning people might start using!
French people may expect something like: 1.234?56 the - sign can take different places: - $ 1.234,56 $ -1.234,56 etc...
How do you tell the French...
an American may expect to read ? 1,234,56
... from the American? 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? Let's try another example: A Swiss website (default language: German) sells something in Swiss Francs and Euros, and a price tag might look like CHF 1'700.70 EUR 1.000,50 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? I've never actually seen a website that uses two different number formats -- so maybe try this instead: CHF 1 700.70 EUR 1 000.50
In *many circumstances* people won't tolerate that numbers/currencies don't get displayed in their local format.
Quite the contrary is true. People are well aware that every website is located in some specific country, and they expect currency formats to follow the customs of that country, no matter what language they select. A website should never try to impersonate a foreign nationality, especially when it deals with monetary amounts. BTW, as to "won't tolerate" -- how many people (besides yourself) do you know who won't buy something, just because the website formats the price tag differently than their local grocery store? Hans P.S. Apparently, the message digest script munges your currency symbols and I'm only seeing question marks, so describing in words would help...
On Thu, 18 Oct 2007 23:42:30 +0200 Hans Salvisberg <drupal@salvisberg.com> wrote:
What I'm trying to say is that any attempt to select a currency format based on the language choice of the user is misguided.
Ivan Sergio Borgonovo wrote:
Forget about currency. Currency is completely unrelated to the user's language, and it certainly shouldn't change, just because a user changes their language.
Well you can express amounts in dollars, euros, yuan with different formats as you express floats.
Sure you /can/ do anything, but you're doing a disservice to the community if you introduce a flawed feature that well-meaning people might start using!
It won't be mandatory you use the wrapper.
Let's try another example: A Swiss website (default language: German) sells something in Swiss Francs and Euros, and a price tag might look like
CHF 1'700.70 EUR 1.000,50
In this case you'll use your formatting rules. Here you've different content for different audience in the same place, that's goes beyond the use of i18n module.
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. If I'm going to express Yen... I'll use the Japanese format too.
I've never actually seen a website that uses two different number formats -- so maybe try this instead:
CHF 1 700.70 EUR 1 000.50
Exactly. Have you ever seen a US newspaper expressing euros with Italian format? eg. E 1.234,56? I bet in US newspapers you'll find E 1,234.56
In *many circumstances* people won't tolerate that numbers/currencies don't get displayed in their local format.
Quite the contrary is true. People are well aware that every website is located in some specific country, and they expect
???? What if you have content in multiple languages for multiple audience? You're publishing data coming from a DB and you want to show it inside an Italian article *and* inside a US article? 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].
currency formats to follow the customs of that country, no matter what language they select. A website should never try to impersonate a foreign nationality, especially when it deals with monetary amounts.
A web site impersonating a foreign nationality?
BTW, as to "won't tolerate" -- how many people (besides yourself) do you know who won't buy something, just because the website formats the price tag differently than their local grocery store?
I'm expecting the Italian newspaper I read use Italian. Italian has rules about formatting currency. If I'm reading an Australian newspaper I do not expect they format Euro accordingly to Italian conventions. Banks may agree to use ISO standards to communicate each other, newspapers don't have to follow. I'm not against standardisation. I love it. I'd be happy all US people use the metric system and all Italian use English but when Italian people read Italian newspapers they expect them to follow Italian conventions. I can absolutely tolerate it. I would consider kindness if they would provide an interface that is adapted to my habit especially when the rest of the interface is in my language but the price doesn't conform to it. My clients would like I try to be kind with their customers. To me it sounds absolutely reasonable. If you've a shop selling in Euro to UK and Italian people and you provide 2 different interfaces you'd expect to show Regular price: E 1,234.56 Discounted price: E 567.89 to UK audience and Prezzo normale : E 1.234,56 Prezzo scontato: E 567,89 to Italian audience 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 prefer to read an English page with numbers, currencies and dates formatted the English way rather than an Italian page with currency, numbers and date in the English format. If I read 10/12/2007 in an Italian article I know it is 10th December. If I read 1,234 l in an Italian article I know it is a bit more than a liter. If I read 1,234 l in an English article I'd think it is a bit more than 1 thousand. What if I read $ 1,234 in an Italian article I'll be puzzled, I'll think about a mistake and I'll have to guess what they really mean from the context. That's not comfortable.
Hans
P.S. Apparently, the message digest script munges your currency symbols and I'm only seeing question marks, so describing in words would help...
Content-Transfer-Encoding: 7bit vs. Content-Type: text/plain; charset=UTF-8 Could it be? 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? To me the localisation module alone can be used just for mono-language websites. So there shouldn't be a mix of English content seen by Italian people with Italian interface with currency, float and dates inside the English content formatted in the Italian way. But if you use localisation module just to translate the interface you'd have Italian content, with Italian interface and Italian currencies, dates and numbers format even if they come from contrib modules once people start to use wrappers. -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (2)
-
Hans Salvisberg -
Ivan Sergio Borgonovo