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