Re: [development] code proposal: localization of currency, ...
On Fri, 19 Oct 2007 12:22:22 +0200, Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
#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
I've been pondering this, and I think currency has a lot of parallels to time management. Consider the PHP 5.2 DateTime object. It stores the timestamp internally somehow, but you can't get to it. A time unit can be formatted, or mutated to another timezone object. Those operations are completely orthogonal. The timezone mutator rules also change quite regularly, thanks to national governments that can't make up their minds. Neither of those is usefully related to language or locality. Currency is similar. It can be formatted in a number of ways (with/without decimal, with comma-dot or dot-comma separation, with spaces separation, with currency symbol, with currency abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality. Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-) --Larry Garfield
On Fri, 19 Oct 2007 11:20:27 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality.
Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-)
Pardon my ignorance, do you have the patience to explain? but... you're putting all this responsibility on the site administrator that would specify a string to format it. You're not "mutating" one currency in another. You're just expressing a currency in the "locale" format. Maybe we should express locale in a more complex way: language + "localisation" so that English may be Canadian, UK or US... with some system to avoid content duplication Are you referring to exchange rate? That will be an issue of the application programmer. I'm not interested in an object to store currency... currency will appear magically in a variable (task of the app. programmer) and they have to be formatted accordingly to the locale (maybe a wider concept than what locale is now). Before revolutionising locale (language + "localisation specialisation") I'd just add the formatting functions. You can keep the signature of functions and just create an EnglishUK EnglishUS etc... language if you really need to deal with the difference. I'd put date/currency/whatever object out of drupal. I think it's not the task of a CMS to "understand" content unless you're obliged too. So why should you provide a currency object? -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Friday 19 October 2007, Ivan Sergio Borgonovo wrote:
On Fri, 19 Oct 2007 11:20:27 -0500
Larry Garfield <larry@garfieldtech.com> wrote:
abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality.
Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-)
Pardon my ignorance, do you have the patience to explain? but... you're putting all this responsibility on the site administrator that would specify a string to format it.
Correct, because there is no definitive "Pounds Sterling are always always always displayed in this format" rules. Different clients/use-cases will want it done differently. In 2 years, I'm not sure if I've ever had 2 clients ask for their dates to be displayed in the same format... and they're all in the Midwestern US! :-) While currency doesn't have as much variation, from earlier on this thread it certainly looks like there's a fair bit. In practice, of course, just like there's a DateTime::W3C formatting constant a fully-featured Currency Value Object would have a Currency::USD formatting constant that would be used for 80% of all use cases for the US dollar.
You're not "mutating" one currency in another. You're just expressing a currency in the "locale" format.
No, I'm making a distinction between mutating (which involves exchange rates, which fluctuate hourly) and formatting (which is a string representation of whatever the current decimal is in some format or another). Yes, mutating is probably not a task for core. In fact I thing this whole set of functionality belongs in a Money API module of some sort (there's that TLA again! <g>). I am primarily drawing parallels between the complexities of currency and the complexities of time.
Maybe we should express locale in a more complex way: language + "localisation" so that English may be Canadian, UK or US... with some system to avoid content duplication
If I'm a stock broker, then my location/timezone is New York, my language is Spanish (if I'm an immigrant), and I want money displayed in 18 different currencies using international abbreviations (EUR, USD, etc.) Binding the format to a locality or language is going to fail at dozens of edge cases.
Are you referring to exchange rate? That will be an issue of the application programmer. I'm not interested in an object to store currency... currency will appear magically in a variable (task of the app. programmer)
Variable of what type? With what properties? String or double? Who ensures that it's always restricted to two decimal points, and based on which rounding scheme (there are several, actually)? There's a lot of logic here that can/should be encapsulated and generalized. That's exactly what Value Objects are good for. (I don't mean object on the level of Node or User or other Assets. I'm talking about more general OO concepts.)
and they have to be formatted accordingly to the locale (maybe a wider concept than what locale is now).
My current locale settings have little bearing on the type of money I am dealing with.
I'd put date/currency/whatever object out of drupal.
Then you're just guessing about how to format float numbers, which is an inherently
I think it's not the task of a CMS to "understand" content unless you're obliged too. So why should you provide a currency object?
... How is it not a CMS's job to understand content? Drupal knows a huge amount about its content right now. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sat, 20 Oct 2007 11:02:34 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
On Friday 19 October 2007, Ivan Sergio Borgonovo wrote:
On Fri, 19 Oct 2007 11:20:27 -0500
Larry Garfield <larry@garfieldtech.com> wrote:
abbreviation, etc.) or mutated from one currency (timezone) to another. The currency mutation rules also change rapidly. Neither format nor mutation is reliably related to language or locality.
Sounds like a prime case for a Currency "Value Object" somewhat modeled on the DateTime object (but as a true Value Object, rather than a mutable object). :-)
Pardon my ignorance, do you have the patience to explain? but... you're putting all this responsibility on the site administrator that would specify a string to format it.
Correct, because there is no definitive "Pounds Sterling are always always always displayed in this format" rules. Different clients/use-cases will want it done differently.
In 2 years, I'm not sure if I've ever had 2 clients ask for their dates to be displayed in the same format... and they're all in the Midwestern US! :-) While currency doesn't have as much variation, from earlier on this thread it certainly looks like there's a fair bit.
So, since they will have a "format string" in the admin panel they will format stuff as they wish, even the same format for all the languages. Sure enough you could have in the same site: - float for bathing - float for summer - float for fun - ... but this won't block people from taking advantage of a localised float/currency etc... all over one language section of a web site. 99.9% of sites will need coherent format across a language section and not 99.9% of the web sites will like to have US format as only choice.
No, I'm making a distinction between mutating (which involves exchange rates, which fluctuate hourly) and formatting (which is a string representation of whatever the current decimal is in some format or another). Yes, mutating is probably not a task for
as you said they are orthogonal. The application programmer will provide the "number" as it has to be (already rounded, with the correct exchange ratio bla bla bla), the administrator will provide has it has to be formatted for every language/localisation). The application programmer won't have to code for *every* localisation most of the time... and if it has to... he could.
core. In fact I thing this whole set of functionality belongs in a Money API module of some sort (there's that TLA again! <g>). I am primarily drawing parallels between the complexities of currency and the complexities of time.
Maybe we should express locale in a more complex way: language + "localisation" so that English may be Canadian, UK or US... with some system to avoid content duplication
If I'm a stock broker, then my location/timezone is New York, my language is Spanish (if I'm an immigrant), and I want money displayed in 18 different currencies using international abbreviations (EUR, USD, etc.) Binding the format to a locality or language is going to fail at dozens of edge cases.
The signature of the localisation function take the "symbol" as a parameter. You're providing a way to format the currency, not to compute it. 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... As since the symbol is passed as a parameter you'll have something like: 1,234.56 EUR 1,234,56 USD or EUR 1.234,56 USD 1.234,56 or 1 234,56 EUR 1 234,56 USD I find it unreasonable to write in the same page: 1,234.56 USD 1 234,56 EUR And in that case you're not dealing with localisation, you're just mixing up everything, you may have your reasons but I'm thinking of a facility that will let module writer "localise" their module if they *can* be localised... if they can't they will deal with it. Anyway the format functions will support a "language" parameter that will override the current user language. At this moment module writer can just display things in US format *or* write their own format functions for the language they are willing to support even if *most* of the time you're just willing to write 1,234.56 EUR vs 1.234,56 EUR
Are you referring to exchange rate? That will be an issue of the application programmer. I'm not interested in an object to store currency... currency will appear magically in a variable (task of the app. programmer)
Variable of what type? With what properties? String or double?
It is up to the application programmer to provide the correct number already rounded. I'd pass integers + the # of decimals.
Who ensures that it's always restricted to two decimal points, and
Passed to the format function. My fault, I put the number of decimal in the wrong place. It shouldn't be in the administrative interface rather in the format function: format_currency($number, $decimal, $symbol, $language=null) I'd limit the scope of this stuff just to *format*. Like PHP number_format but that add symbol and sign position.
based on which rounding scheme (there are several, actually)? There's a lot of logic here that can/should be encapsulated and generalized. That's exactly what Value Objects are good for. (I don't mean object on the level of Node or User or other Assets. I'm talking about more general OO concepts.)
and they have to be formatted accordingly to the locale (maybe a wider concept than what locale is now).
My current locale settings have little bearing on the type of money I am dealing with.
I'd put date/currency/whatever object out of drupal.
Then you're just guessing about how to format float numbers, which is an inherently
I think it's not the task of a CMS to "understand" content unless you're obliged too. So why should you provide a currency object?
... How is it not a CMS's job to understand content? Drupal knows a huge amount about its content right now.
By necessity not by will I hope. The more knowledge you spread in a system the more you make it interdependent and entangled. What I mean is that drupal should know as less as possible about what dates, currency and float are and *why* they have to be formatted in some way (eg. parenthesis vs. sign etc...) this should be up to the site administrator, to provide the right format string and to the application programmer, even rounding is not a task drupal should be aware of, nor exchange rates and timezones; or at least it may provide the information to the application programmer, but it shouldn't know how and why it is used. I'm not proposing a catch them all solution and I think this facility won't get into the way of people. But at this moment every module writer that would like to "localise" float, currency and date format, should read the language variable, write a function that chose a format *for every language he want to support* (not every language the site *actually* support, but really a function aware of every language he want like to support). The net result is: - no one is willing to get into this mess so no module is localised - if any is localised there will be a lot of duplication of code - everyone will provide his own format for float in French so that pages will display float differently accordingly to the module writer idea of what the French format is, if French format is supported at all by the module writer that maybe decided to support just Malay and Bergamasco. - site administrators/builders won't have control on the format Surely a module writer may have HIS reasons to have HIS idea of what is French format and HOW to deal with currencies... but these facilities won't stop him, that is actually dealing with a special case and should be aware of what he is doing, to provide HIS OWN solution to HIS OWN problem. If demand for special format will be high enough you could add: - scientific float - accounting currency - etc... People writing modules will know what will happen to their currency/float if they wrap them with the formatting functions. If they think it doesn't work for them they could avoid it. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Sunday 21 October 2007, Ivan Sergio Borgonovo wrote:
The application programmer will provide the "number" as it has to be (already rounded, with the correct exchange ratio bla bla bla), the administrator will provide has it has to be formatted for every language/localisation). The application programmer won't have to code for *every* localisation most of the time... and if it has to... he could.
I think I see the disconnect here. You're talking about a site admin level. I'm speaking strictly of a general code-level currency mechanism. The actual format string that would be passed in, yes, would come from variable_get() or something like that so that it's the same site-wide, just like were we to use DateTime in Drupal 7 (which I highly encourage) we would not, presumably, have every module author calling ->format() with their own string.
I think it's not the task of a CMS to "understand" content unless you're obliged too. So why should you provide a currency object?
... How is it not a CMS's job to understand content? Drupal knows a huge amount about its content right now.
By necessity not by will I hope. The more knowledge you spread in a system the more you make it interdependent and entangled.
That's where good use of design patterns helps you keep the system smart but decoupled. ;-) (It is relevant that a given field is a date field or a SSN field; it's not relevant to every single function that touches that structure, however.)
What I mean is that drupal should know as less as possible about what dates, currency and float are and *why* they have to be formatted in some way (eg. parenthesis vs. sign etc...) this should be up to the site administrator, to provide the right format string and to the application programmer, even rounding is not a task drupal should be aware of, nor exchange rates and timezones; or at least it may provide the information to the application programmer, but it shouldn't know how and why it is used.
Again, it seems we're addressing different problems. You're after a float version of the date() (or format_date()) function with site-wide defaults. I'm talking about currency as its own value entity independent of the administrative settings, on top of which defaults could be built. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sun, 21 Oct 2007 12:27:14 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
I think I see the disconnect here. You're talking about a site admin level. I'm speaking strictly of a general code-level currency mechanism. The actual format string that would be passed in, yes, would come from variable_get() or something like that so that it's the same site-wide, just like were we to use DateTime in Drupal 7 (which I highly encourage) we would not, presumably, have every module author calling ->format() with their own string.
I hope I understood it right.
What I mean is that drupal should know as less as possible about what dates, currency and float are and *why* they have to be formatted in some way (eg. parenthesis vs. sign etc...) this should be up to the site administrator, to provide the right format string and to the application programmer, even rounding is not a task drupal should be aware of, nor exchange rates and timezones; or at least it may provide the information to the application programmer, but it shouldn't know how and why it is used.
Again, it seems we're addressing different problems. You're after a float version of the date() (or format_date()) function with site-wide defaults. I'm talking about currency as its own value entity independent of the administrative settings, on top of which defaults could be built.
If I understand it right... this is the not orthogonal part... If you're going to introduce a drupal-core object for currency *on top of which* default could be built, first we have to have an object that represent currency, then we have to add to that object facilities for formatting. I'm scared I don't have the time to wait for a committee to approve a currency object. At this moment my idea of a currency is an integer + # of decimal digits. If we want to provide "super-deluxe" formatting we could go all the way down as locale does and add: mon_grouping and all the other stuff. But it is a long long run. I was looking for any "DateTime" Object into 5.2 and I didn't find anything interesting other than in xmlrpcs.inc. I did look for anything related to drupal and datetime objects and I stumbled into: http://drupal.org/node/130694 http://drupal.org/files/issues/datetime.module.txt and here http://drupal.org/node/37405 with a reference to Drupal 7. hints? No matter what I'll end to do... but maybe there is some chance it could be recycled if I've an idea of what are the plans. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Sunday 21 October 2007, Ivan Sergio Borgonovo wrote:
I was looking for any "DateTime" Object into 5.2 and I didn't find anything interesting other than in xmlrpcs.inc. I did look for anything related to drupal and datetime objects and I stumbled into: http://drupal.org/node/130694 http://drupal.org/files/issues/datetime.module.txt and here http://drupal.org/node/37405 with a reference to Drupal 7.
hints?
No matter what I'll end to do... but maybe there is some chance it could be recycled if I've an idea of what are the plans.
We don't use DateTime in Drupal 6 at all, as it's PHP 5.2 only, and Drupal 7 hasn't opened up yet. KarenS would probably be the go-to person on what the date handling plans are for D7. for DateTime in general, I recommend this page: http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetimezon... It's a good description of the theory behind how date handling works in PHP 5.2, as well as the pros and cons of the DateTime class signature itself. (Short version: It really needs to be a Value Object, but it isn't, but a Value Object wrapper around it shouldn't be hard.) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sun, 21 Oct 2007 15:06:40 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
No matter what I'll end to do... but maybe there is some chance it could be recycled if I've an idea of what are the plans.
We don't use DateTime in Drupal 6 at all, as it's PHP 5.2 only, and
bwaaaa I think today my assembly session blew up my mind. s/PHP/Drupal/
Drupal 7 hasn't opened up yet. KarenS would probably be the go-to person on what the date handling plans are for D7.
for DateTime in general, I recommend this page:
http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetimezon...
It's a good description of the theory behind how date handling works in PHP 5.2, as well as the pros and cons of the DateTime class signature itself. (Short version: It really needs to be a Value Object, but it isn't, but a Value Object wrapper around it shouldn't be hard.)
Woops and what about the currency/float format party? Is there any plan for that? thx -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Sunday 21 October 2007, Ivan Sergio Borgonovo wrote:
On Sun, 21 Oct 2007 15:06:40 -0500
Larry Garfield <larry@garfieldtech.com> wrote:
No matter what I'll end to do... but maybe there is some chance it could be recycled if I've an idea of what are the plans.
We don't use DateTime in Drupal 6 at all, as it's PHP 5.2 only, and
bwaaaa I think today my assembly session blew up my mind. s/PHP/Drupal/
Oops. :-)
Drupal 7 hasn't opened up yet. KarenS would probably be the go-to person on what the date handling plans are for D7.
for DateTime in general, I recommend this page:
http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetime zone/
It's a good description of the theory behind how date handling works in PHP 5.2, as well as the pros and cons of the DateTime class signature itself. (Short version: It really needs to be a Value Object, but it isn't, but a Value Object wrapper around it shouldn't be hard.)
Woops and what about the currency/float format party? Is there any plan for that?
thx
Well since I only started talking about it 2 days ago, not that I know of. :-) Really, I was just throwing out an alternative approach to take that would offer more long-term flexibility for currency handling. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sun, 21 Oct 2007 15:53:20 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
for DateTime in general, I recommend this page:
http://laughingmeme.org/2007/02/27/looking-at-php5s-datetime-and-datetime zone/
Finally I read it fully. It looks Zend is going Microsoft if you read one of the comments ;) I've vague memories of Windows timezone setup and it doesn't let you guess there is such a mess behind. Anyway I can't find a place in drupal for such a beast. (OK, I may be wrong... but then tell me...). There is the time of the server and there is the time of the user. You don't know where the user is and you've to ask which timezone he prefer. Guessing where the user is and which timezone he is in, is a risk that doesn't fit to much in core. Once you ask... well you don't need the Olson bag with you. Computations with dates should be a language task not drupal task. I've the same feeling with currencies. To avoid rounding problems I'd think as currencies as int + decimal places. As we can see from man 5 locale there are more options for formatting currencies and numbers and it doesn't seem there is any reasonable working facility in php to exploit.
Well since I only started talking about it 2 days ago, not that I know of. :-) Really, I was just throwing out an alternative approach to take that would offer more long-term flexibility for currency handling.
Unless you take in Zend stuff I see no way to exploit all the info you generally have in locale and locale settings are shared across threads in the same process. BTW Debian etch installed in Italian: ivan@wtw:~$ export LANG='it_IT.utf8';export LC_ALL='it_IT.utf8'; php -r 'setlocale(LC_ALL,'it_IT.utf8');$num=1.5;echo $num;echo("\n");' 1.5 ivan@wtw:~$ locale -a C it_IT.utf8 POSIX that 1.5 should be 1,5 -- Ivan Sergio Borgonovo http://www.webthatworks.it
participants (2)
-
Ivan Sergio Borgonovo -
Larry Garfield