Re: [development] code proposal: localization of currency, ...
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. A monetary amount is a number, possibly formatted in some special way, and a currency symbol/code placed somewhere. If a website wants to sell stuff in US$ they rarely want to get paid in any other currency -- well, they rarely support any language but English either... OTOH, if they sell stuff in Swiss Francs, they'll probably support at least German, French, and Italian (but Germany, France, and Italy have the Euro -- French Canada has the Canadian Dollar!). That Swiss site may support English as well, and they may also accept Euros, but the Euro amount won't be the same as the Swiss Franc amount, of course. And the UK does NOT use the Euro, but the Pound Sterling. Are there any English-speaking countries that do not use the Pound Sterling? This is much more complex than you think, and automating it would require a completely different approach. Essentially, a currency field would have to take the amount and the currency code (see http://en.wikipedia.org/wiki/ISO_4217), probably from a configurable list (which might have only one item), and format the number accordingly, with or without a currency symbol or code, at the user's option. Hans Ivan Sergio Borgonovo wrote:
- write functions like:
i18n_currency_format($number, $symbol='') { $tmp=i18n_number_format(abs($number), variable_get('currency_decimal',2) ); if($number<0) { $sign="-"; } $tmp=str_replace('d',$tmp, variable_get('currency_format','sd c'): $tmp=str_replace('c',$simbol,$tmp); $tmp=str_replace('s',$sign,$tmp); return $tmp; ); }
On Wed, 17 Oct 2007 17:47:09 +0200 Hans Salvisberg <drupal@salvisberg.com> 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. Eg. I'm expecting to read € 1.234,56 or 1.234,56 EUR French people may expect something like: 1.234€56 the - sign can take different places: - $ 1.234,56 $ -1.234,56 etc... an American may expect to read € 1,234,56 in other countries the symbol of the currency may be put after the number etc... site owner may decide that French people may see currency formatted in some way and English people see them formatted differently for the *same* currency. They may decide to use ISO or just the traditional format of that place. Providing a sort of PHP date format will just solve the issue and let people provide the format they prefer and show the format accordingly to the language chosen. Making it more general could mean adding: - sign position - decimal/thousands separator - major and minor currency symbols Unless you'd like to add support for non decimal systems as MRO and MGA. If this is a blocker for acceptance I could write a more generalised function. Other stuff could be included in the system described above. Even number formats have a wider range (some people group by 2 digit). I'm not aware of any other more generalised format. So... no interest at all in having localisation of currency and float format? -- Ivan Sergio Borgonovo http://www.webthatworks.it
Unless you'd like to add support for non decimal systems as MRO and MGA. If this is a blocker for acceptance I could write a more generalised function. Other stuff could be included in the system described above. Even number formats have a wider range (some people group by 2 digit). I'm not aware of any other more generalised format.
So... no interest at all in having localisation of currency and float format?
I was going to suggest to develop a cck field for money and currency as a proof of your concept, but a quick google told me it's already done : http://drupal.org/project/money http://drupal.org/project/currency_cck http://drupal.org/project/currency Drupal contrib is astounding Philippe
-- Ivan Sergio Borgonovo http://www.webthatworks.it
My Money CCK field module [1] already supports portions of the desired functionality: 1) You can choose whatever currency you want to store your amount in. 2) You can choose the digit group separator and the decimal separator. 3) Two formatters are offered: currency code before/after the amount. It shows you a list of existing currencies, relying on the Currency API module, which is part of the Currency module [2]. What would be required now, is the ability to either manually or based on locale, change the formatter completely. Also support for currency symbols would be needed, but that's almost trivial. It's not a Drupal core solution, but it is a solution. Cheers, Wim Leers ~ http://wimleers.com/work [1] http://drupal.org/project/money [2] http://drupal.org/project/currency On Oct 17, 2007, at 19:33 , Ivan Sergio Borgonovo wrote:
On Wed, 17 Oct 2007 17:47:09 +0200 Hans Salvisberg <drupal@salvisberg.com> 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.
Eg. I'm expecting to read € 1.234,56 or 1.234,56 EUR French people may expect something like: 1.234€56 the - sign can take different places: - $ 1.234,56 $ -1.234,56 etc... an American may expect to read € 1,234,56 in other countries the symbol of the currency may be put after the number etc... site owner may decide that French people may see currency formatted in some way and English people see them formatted differently for the *same* currency. They may decide to use ISO or just the traditional format of that place. Providing a sort of PHP date format will just solve the issue and let people provide the format they prefer and show the format accordingly to the language chosen.
Making it more general could mean adding: - sign position - decimal/thousands separator - major and minor currency symbols
Unless you'd like to add support for non decimal systems as MRO and MGA. If this is a blocker for acceptance I could write a more generalised function. Other stuff could be included in the system described above. Even number formats have a wider range (some people group by 2 digit). I'm not aware of any other more generalised format.
So... no interest at all in having localisation of currency and float format?
-- Ivan Sergio Borgonovo http://www.webthatworks.it
On Wed, 17 Oct 2007 19:52:33 +0200 Wim Leers <work@wimleers.com> wrote:
My Money CCK field module [1] already supports portions of the desired functionality: 1) You can choose whatever currency you want to store your amount in. 2) You can choose the digit group separator and the decimal separator. 3) Two formatters are offered: currency code before/after the amount.
I gave a look at the code. I think something a bit more generalised could gain more acceptance. I'm thinking about position of the sign and relaying on a more general number format. People may not want to follow ISO but just output their stuff accordingly to traditions.
It's not a Drupal core solution, but it is a solution.
I'm not expecting to get into core. I just would like to make my solution easier to maintain. If people would start to build up modules that wrap currency/float format function we may end up in making i18n easier. Same for float/large numbers. I'm not aware of how many modules output something that's not simple integers (and even large integers may have to be formatted...) but it looks like a must have feature. I think that a reasonably general solution can be found and people could tune it in a setting page as they would do with the date format in php. There are 2 currencies that are a bit tricky to format (non decimal ones) the rest is just a matter of providing a date alike string that could tell where to put sign and currency symbol. Number format could be inherited by the number formatting format. I'm not aware of any other strangeness other than grouping by hundreds other than thousands and using different char as separator for decimals/"thousands". As for currencies just 2 currencies can't be expressed in a meaningful way other than in their "native" format. Others can be "adapted". What I mean is that Italian expect to read € 1.234,56 as well as $ 1.234,56 while US people expect to read € 1,234.56 and $ 1,234.56 If we want to be really tough we could provide 3 number format for each language: - standard - scientific - accounting This would make this stuff pretty general and when modules will have to output numbers they will have the correct format in most of the cases. In *many circumstances* people won't tolerate that numbers/currencies don't get displayed in their local format. Editing all the contrib modules to retro-fit them to support localisation of format may be a PITA. If people think that their output doesn't have to be "localised" they could avoid to wrap their output with these functions as I think they are already doing when there is no purpose for using t(). Something that provide this base functionality is due. Gluing it together with i18n shouldn't be a problem. Function naming/signature and how much it has to be general will decide its acceptance. I'm still open to advices. thanks -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Oct 17, 2007, at 21:48 , Ivan Sergio Borgonovo wrote:
On Wed, 17 Oct 2007 19:52:33 +0200 Wim Leers <work@wimleers.com> wrote:
My Money CCK field module [1] already supports portions of the desired functionality: 1) You can choose whatever currency you want to store your amount in. 2) You can choose the digit group separator and the decimal separator. 3) Two formatters are offered: currency code before/after the amount.
I gave a look at the code. I think something a bit more generalised could gain more acceptance. I'm thinking about position of the sign and relaying on a more general number format. People may not want to follow ISO but just output their stuff accordingly to traditions.
Sign positioning was not yet needed, not even requested. But it could obviously be added with ease. IIRC, there's no such thing as CCK formatter settings though. This means that you'd have to provide formatters such as: "format: <ISO code> <sign> <amount>", "format: <sign> <ISO code> <amount>", "format: <symbol> <sign> <amount>", etc. As you can see, the number of formatters becomes overwhelming. Ideally, you would be able to define your own formatters (with drag and drop). But that's something CCK currently doesn't support (again, AFAIK). What do you mean by "relying on a more general number format"? The fact that all numbers are stored as an integer (this prevents rounding errors that could occur when it was stored as a float) and that only 2 decimals are assumed? That can be implemented easily. Wim Leers ~ http://wimleers.com/work
On Wed, 17 Oct 2007 23:38:04 +0200 Wim Leers <work@wimleers.com> wrote:
I gave a look at the code. I think something a bit more generalised could gain more acceptance. I'm thinking about position of the sign and relaying on a more general number format. People may not want to follow ISO but just output their stuff accordingly to traditions.
Sign positioning was not yet needed, not even requested. But it could obviously be added with ease. IIRC, there's no such thing as CCK formatter settings though. This means that you'd have to provide formatters such as: "format: <ISO code> <sign> <amount>", "format: <sign> <ISO code> <amount>", "format: <symbol> <sign> <amount>", etc. As you can see, the number of formatters becomes overwhelming. Ideally, you would be able to define your own formatters (with drag and drop). But that's something CCK currently doesn't support (again, AFAIK).
First I'd let the user free to chose if he want the iso code or whatever... even in Klingon currency. I'd just use a simple replace with a form similar to: Numbers: grouping: Number of digit: [3] Digit separator: [.] Decimal separator: [,] Currency: decimals: [2] format: [%s \( %S %d \)] %d is amount, %s is sign, %S is symbol, characters preceded by \ will be printed just if the sign is negative. example: %s \( %S %d \) will output something like - ( $ 1.234,00 ) or $ 1.234,00. I'm not aware of the thousands variations you could have but this should cover most needs. function will be something like format_currency($number, $symbol, $language=null) So you could override the default language in a i18n website when needed. To provide overriding I've to learn how to access variables of languages different from the one user is logged in... this seems to be an interface problem in i18n too since when you've to set localised variables you've to switch the language. It doesn't seem a blocker and it has impact just on i18n enabled websites. I still would like to have an idea of the acceptance of such stuff and if people have any suggestion to make it more core or i18n friendly. thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
FWIW, the french would actually expect "1 234,56 €", "1 234,56 EUR", "EUR 1.234,56" or "1234,45 euros" depending on the situation. Not sure we're worse than others in that respect, but this is just to show that even within a given country and for a given currency, a wide range of variation can exist and can not just be inferred from technical parameters. Using EUR (or USD, CAD, GBP, whatever) is mostly dedicated to professional parlance in international trade. Use of the plural form without an uppercase is typical of informal practice. Digit grouping varies wildly. Not forgetting that accountants will typically expect negative values to be formatted as "(12 345,67)" ----- Original Message ----- From: "Ivan Sergio Borgonovo" <mail@webthatworks.it> To: <development@drupal.org> Sent: Wednesday, October 17, 2007 7:33 PM Subject: Re: [development] code proposal: localization of currency, ... On Wed, 17 Oct 2007 17:47:09 +0200 Hans Salvisberg <drupal@salvisberg.com> 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. Eg. I'm expecting to read € 1.234,56 or 1.234,56 EUR French people may expect something like: 1.234€56 the - sign can take different places: - $ 1.234,56 $ -1.234,56 etc... an American may expect to read € 1,234,56 in other countries the symbol of the currency may be put after the number etc... site owner may decide that French people may see currency formatted in some way and English people see them formatted differently for the *same* currency. [...]
participants (5)
-
FGM -
Hans Salvisberg -
Ivan Sergio Borgonovo -
Philippe Jadin -
Wim Leers