Re: [development] code proposal: localization of currency, ...
Ivan Sergio Borgonovo wrote:
The site will be displayed in Spanish, with Spanish format of currency. If "Spanish" means some of the Latin American countries that may have a different format for currencies... let it be...
Why won't you understand that this is not good enough? By releasing something that works only some of the time, and only for your favorite countries, you'd do more harm than good, because a lot of less-educated people might start using it, thinking that it acually works. Drupal's "localization" is nothing more than a language selection. It's acceptable as far as language selection goes, but it's much too coarse to really be called "localization," and certainly not suited as a base for something as complex as currency formatting.
Anyway the format functions will support a "language" parameter that will override the current user language.
IT'S NOT A QUESTION OF LANGUAGE!!!
I'm not proposing a catch them all solution and I think this facility won't get into the way of people.
Yes, it will. Once module writers start to use it, site administrators will not only have to deal with one (possibly sub-optimal) currency format, but with one per language, which is clearly worse.
People writing modules will know what will happen to their currency/float if they wrap them with the formatting functions.
No, they won't! They'll just (wrongly!) assume that it'll do the right thing for most users, which shifts the plague over to the site administrators! What might be useful for many sites is an API with an options page that lets the site administrator freely define THE currency format for the site (completely independent of lanugage!). He'd still only have one, but at least he'd have the one he selected. That would be a big step forward. Don't try to be smart. Software that tries to be smart and to guess the user's wishes (based on the author's less than perfect view of the world) is absolutely maddening! Hans
On Mon, 22 Oct 2007 09:46:02 +0200 Hans Salvisberg <drupal@salvisberg.com> wrote:
What might be useful for many sites is an API with an options page that lets the site administrator freely define THE currency format for the site (completely independent of lanugage!). He'd still only have one, but at least he'd have the one he selected. That would be a big step forward.
If you think that there aren't multi-language sites yes.
Don't try to be smart. Software that tries to be smart and to guess the user's wishes (based on the author's less than perfect view of the world) is absolutely maddening!
I'm not trying to be smart, I'm trying to add freedom to chose. A) if your site is not multi-language administrators will have one place where to specify at their will what should be the formats B) if you've a multi-language site administrators will be able to specify many formats. The fact that language and localisation are one thing for drupal is another problem, because if you're dealing with 2 localisations that share the same language but not the same string format you'll have to "duplicate" content. But this happens just if you are using i18n since without i18n there is not such a thing as content<->language association and you don't have multiple places where you can set locale format info... Now... let's see how we can go forward and add "localisation" to "translation" for multi-language sites. Let's see localisation as 2 orthogonal components: - translation - string format Actually the fact that some localisation share the format part is accidental. How do you expect default to be set? I think a good place to set a default localisation is "language". A correctly guessed language will eventually put people on the right path to adjust their localisation. It may be wrong... but is better than being wrong and having one choice. If you want to go further... you should let people chose their format. So signature of the functions should be changed to something like: outerfuncname(param, ... $format_override) inspite of $language. If someone is actually willing to change the default/selected format... then let it be. Internally the function first will chose the default associated to the language, later when we will provide a user based choice... the first choice will be whatever selected by the user, second choice would be the language default. I think that $format_override is anyway a too long list of parameters... outerfuncname should just be used to chose the format accordingly to language or user choice when ready and we could offer an innerfuncname for actually doing the work to module developer since I didn't see anything in PHP that is more sophisticated than number_format and setlocale is not thread safe. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
B) if you've a multi-language site administrators will be able to specify many formats. The fact that language and localisation are one thing for drupal is another problem, because if you're dealing with 2 localisations that share the same language but not the same string format you'll have to "duplicate" content.
This comes down to user options of representations. The user selects the format for floating point and the format for currency. The two have separate formats because non-currency floating point is likely to have different representation. The hardest part is knowing which format to use when representing the data to the user; i.e. is this number representing currency or non-currency. When it comes to accounting systems, floating numbers should be avoided and all data should be stored and processed as integers to avoid rounding issues while processing. Only at the time of representation do we present the fractions by dividing by the most significant fraction (e.g. 100). At the time of input we multiply by the most significant fraction and round as necessary. This also has a benefit of processing faster as integer processing is faster than decimal processing. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Mon, 22 Oct 2007 08:12:05 -0400 Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
B) if you've a multi-language site administrators will be able to specify many formats. The fact that language and localisation are one thing for drupal is another problem, because if you're dealing with 2 localisations that share the same language but not the same string format you'll have to "duplicate" content.
This comes down to user options of representations. The user selects the format for floating point and the format for currency.
I'd add this at a later stage and I think since you can keep signature consistent, it doesn't represent a problem. Language at the beginning will provide the format, later they will provide the default for the format.
The two have separate formats because non-currency floating point is likely to have different representation. The hardest part is
Just curious... are there float that don't share with currency separators and grouping? Anyway man 5 locale is a good place where to look at to provide a quite general formatting function.
knowing which format to use when representing the data to the user; i.e. is this number representing currency or non-currency.
the application will know. If you're passing to a formatting string something you should know what it is. I'm not aware of any facility that let eg. theme('table' decide how to format stuff accordingly to the content type.
When it comes to accounting systems, floating numbers should be avoided and all data should be stored and processed as integers to avoid rounding issues while processing. Only at the time of
right... so any currency formatting function should take int as argument. doesn't PHP really offer anything out-of-the-box? nearly-out-of-the-box? not-to-far-from-out-of-the-box? ;) -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
Just curious... are there float that don't share with currency separators and grouping?
The possibility exists but probably more based on some other unit of measure. This thought just brought a good point to mind; currency is a unit of measure, so in looking at coding for localizing currency other units of measure should also be considered. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Tue, 23 Oct 2007 08:12:01 -0400 Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
Just curious... are there float that don't share with currency separators and grouping?
The possibility exists but probably more based on some other unit of measure. This thought just brought a good point to mind; currency is a unit of measure, so in looking at coding for localizing currency other units of measure should also be considered.
But you should consider formatting and not conversion. Conversion is a responsibility of the application (module) not of core. Unless you could group unit of measure in few groups it would be overwhelming. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
On Tue, 23 Oct 2007 08:12:01 -0400 Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ivan Sergio Borgonovo <mail@webthatworks.it>:
Just curious... are there float that don't share with currency separators and grouping?
The possibility exists but probably more based on some other unit of measure. This thought just brought a good point to mind; currency is a unit of measure, so in looking at coding for localizing currency other units of measure should also be considered.
But you should consider formatting and not conversion. Conversion is a responsibility of the application (module) not of core.
Are you sure? What about miles vs kilometers? What about foreign exchanges of currency?
Unless you could group unit of measure in few groups it would be overwhelming.
The unit of measure would need to be stored with the value in the DB so that if I enter 2 miles you can read it as 3.219 (or 3,219 or 3 219 or ...) kilometers and we now both have a good mental picture. Formatting is only 1/2 the picture, converting to differing units of measure is the other half. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
And sometimes, the notation can be *really* challenging: http:// en.wikipedia.org/wiki/Tanzanian_shilling#Symbol. (I stumbled upon this while extending the Currency API with support for currency symbols...) Wim Leers ~ http://wimleers.com/work
On Oct 22, 2007, at 14:12 , Earnie Boyd wrote:
When it comes to accounting systems, floating numbers should be avoided and all data should be stored and processed as integers to avoid rounding issues while processing. Only at the time of representation do we present the fractions by dividing by the most significant fraction (e.g. 100). At the time of input we multiply by the most significant fraction and round as necessary. This also has a benefit of processing faster as integer processing is faster than decimal processing.
Just for the record, the Money CCK field already does this. Wim Leers ~ http://wimleers.com/work
participants (4)
-
Earnie Boyd -
Hans Salvisberg -
Ivan Sergio Borgonovo -
Wim Leers