[development] code proposal: localization of currency, ...

[Ivan Sergio Borgonovo]

to skip the non technical (use case) part go to #tech

On Fri, 19 Oct 2007 06:15:45 +0200
Hans Salvisberg <drupal at salvisberg.com> wrote:

> Ivan Sergio Borgonovo conveniently avoided considering the cheaper
> case:

Actually it seems you're avoiding to consider the most common case in
which float and currency are displayed accordingly to the context of
the language used by the audience.

> Let's try a concrete example. We have, let's say
> 
>       $0.02

> Now, the user changes his language to French. Apparently, you're

If you've such problem you'll provide a Canadian content. That will
be French content, French interface and "Canadian" formatting of
currencies.
If you want to provide French content to French people too, with
French formatting, that's another issue since at my current knowledge
of i18n module you'll have to duplicate content.
That's not nice, but feasible, but the problem doesn't reside in
providing a formatting facility rather in i18n[1].

> There's also an Italian minority in the US, and I don't see why an 
> Italian American shouldn't install the Italian UI translation as an 
> option. So, how will you display those two cents?

I'm not aware of any community writing Italian with Chinese
formatting for currency and Swahili interface.

> Oh, so when the going gets tough, you're proposing NOT to use your 
> currency wrapper? But -- either we use it or we don't. We cannot
> not use it when the user changes to Japanese while at the same time
> use it when he changes to French, can we?

I'm not aware of any core functionality that output 2 different
currencies in the same page for 2 different audience.
If you're writing a module that display CHF for French people and USD
for American people in the same place it is up to you to decide which
format your audience will find less puzzling.
Having a formatting function won't make it harder in any way.
Actually it will still help.

> When you have a simple algorithm, then you can always construct a
> simple example for which the algorithm yields the correct result.
> That doesn't prove anything. If you want to contribute something
> useful then it needs to work in all but the most exotic cases.

The most exotic cases are MRO and MGA. Expressing any other currency
in their format wouldn't have any meaning.

> And, no, I disagree. It doesn't matter in what language this is 
> published, but it depends on where it's published. If it's a US 
> publication (whether in English or in Italian) then it should use
> US formatting, and if it's published in Italy (whether in English
> or in Italian), it should use Italian formatting.

You could do it. Provide the English formatting in the setup
interface even for Italian interface. I don't find it particularly
reasonable as 99% of the publications don't follow this rule but
you're free to do it.

So... that is a no problem.
If you have mixed language content and you didn't care about
installing i18n and you want uniform formatting of currency and
float... they will be uniform... cos without i18n there will be just
one version of the variable specifying the format.
If you've installed i18n and you want Italians see Pounds formatted
in Tanzanian way, you could do it too.

> > I would consider confusing having content and interface in one
> > language and currency and number format expressed in a format
> > that's not proper of that language.

> I agree. But who says that content and interface needs to be in the
> same language. Drupal makes it easy to switch the interface.
> Supplying all of your content in multiple languages is much much
> harder.

That's the purpose of i18n and its facilities.
If you write a module with currency wrapped around formatting
functions that may know about i18n (or just about your float
formatting) they could be localised no matter what your strange idea
of localisation is: French formatting in Italian interface with
Chinese content. Otherwise you'll have modules and core outputting
invariably with... US format.
Did you stop for a while thinking about the current situation?
You can decide how to output dates... but everything else will output
in US format and you can't change it globally.

If you mix content without the help of i18n it is up to your business
to decide which format is less puzzling to your audience.

> If you tie the currency and number format to the interface
> language, then you get exactly what you say you would consider
> confusing: users with different interface languages see the same
> content with different currency and number formats! Please take
> this in and try not to ignore it!

uuuh exactly... but currently this is the only choice they have...
Please take this in and try not to ignore it!

With a wrapper they:
- have a US site with US formatting, US content, US interface
- could still provide French site with mangled interface as it is now
since there is no support for localisation of currency/float.
- decide that if the site is a French site with a French interface,
it would be nice to show currency and dates and float the French way
- decide that they are too lazy to install i18n and provide French,
and English content mixed up and one way to format float, currency,
dates (no matter if they decide the best way is Cambodian for English
and French audience)
- use i18n and provide what they like for each interface content pair
- use i18n and decide that *that* float in *that* page/module doesn't
have to be formatted accordingly to the current set language but
accordingly to another provided it is defined.
- use i18n and decide that *that* float in *that* page doesn't have
to be formatted accordingly to the current set language but
accordingly to Klingon that is not specified in the supported
language list and provide their own function to format float coming
from a DB and format it in Klingon.

The only situation I can see some real confusion is when people with
i18n installed will want to read language "agnostic" nodes. Nodes
that haven't been assigned a language and that should be available to
anyone without changing the language.
Of course such kind of node belong to the "not translated" but
available to everyone.
But knowing the singularity, when you build such nodes you may
override the default interface language as you could see I proposed:
format_currency($number, $symbol, $language=null).

Modules should be built with the idea they should be translatable...
if they are not it is just a missing feature in the module not
something wrong with the facilities you could provide.

> > Is anyone using localisation without i18n module and then mixing
> > content in different languages just providing translation for
> > the interface?
> > Any case history of such kind of setup?

> I can't point you to a specific site, but if a site has a sizable

That's a clue. Have you ever build a multi-language site?

> minority that likes to use another language, then why not throw in
> a UI translation to make it easier for them to find their way on
> your site?

So what? At this moment you can just output in US format... no matter!
If you're in Switzerland where people use several languages but up to
my knowledge the same float/currency format... you'll be stuck with
US format no matter.

And you've a huge inheritance of modules that will continue to output
in US format only unless you provide some general facility that let
them switch the format accordingly to what the owner of the site
decide is best.
Module writers may decide to avoid wrapping if they think the content
they provide through their module is not suited to be localised or if
they think the wrapper can't handle the complexity of the content
they provide.

> > To me the localisation module alone can be used just for
> > mono-language websites.

> > So there shouldn't be a mix of [...]

> Why not? Because it doesn't suit your view of the world? Italian

Let me put it more clearly.
Localisation module is best suited for mono-language sites. If you're
going multi-language is definitively advisable to use i18n.

What the hell have you seen around till now?
I'm aware of blogs that mix Italian and English in the same place but
they aren't nice to see and I consider rude posting in English in an
Italian forum or in Italian in an English forum.

People are mixing content just because they ignore how nice drupal
i18n is compared to anything else I've seen...
i18n should actually be more advertised by drupal community.
This is a killer module compared to what other CMS have.

> websites and only Italian websites for Italians only? If you're
> serious about doing I18n/L10n then you definitely need to broaden
> your view! Supporting "a mix of ..." is what I18n/L10n is all
> about. 

Exactly... so why are you insisting people shouldn't have an option
and continue seeing stuff just formatted US way?


#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