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