Ivan Sergio Borgonovo conveniently avoided considering the cheaper case: Let's try a concrete example. We have, let's say $0.02 Now, the user changes his language to French. Apparently, you're jumping to the conclusion that he must be a member of the "French people" -- that's wrong more that two thirds of the time, but if we leave that aside for the moment, what do you propose to do with those two cents now? Consider the same scenario in Canada -- what do you propose to do? 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?
Now the user changes his language to a) French or b) Japanese (hint: Yen amounts have no fractional part). What do you propose to do?
Use the float format for the Japanese audience to express Euros.
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?
Will you expect to see:
[A] The current debt of US is $ 1.234.567.890,33
and
Il debito corrente degli US ? di $ 1.234.567.890,33
or you would expect something like:
[B] The current debt of US is $ 1,234,567,890.33
and
Il debito corrente degli US ? di $ 1.234.567.890,33
I'd expect [B].
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. 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.
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. 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!
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 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?
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 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. Hans