|
List Info Thread: Re: code proposal: localization of currency, ...
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
Re: code proposal: localization of currency, ... |
|
List Info Thread: Re: code proposal: localization of currency, ...
[1-2]
|
||||||||||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||||||||||
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