Description of problem:
Many latin-american countries use the "point" (.) for decimal numbers separator, not the "comma" (,). I find this urgent because arithmetic operations return wrong results because they only understand the comma as the separator.
Version-Release number of selected component (if applicable):
Fedora 17. es_MX and many other latam localizations (es_XX)
You can check that under the "Region and Language" section of the control center, also, the calculator is affected by this (and many other apps)
Steps to Reproduce:
1.Go to the "Region and Language" configuration GUI
2.Select "Spanish (Mexico)" as the language
3.Select "Mexico" as the format setting
4.You can see that the decimal separator is the "comma"
It uses a comma instead of a point
it is software Bug with control-center-3.4.2-1.fc17.x86_64
Is this issue with input? any specific keyboard with xkb (or ibus)? Also please confirm that it is Fedora 17.
This behavior is also in Fedora 16. I've been lazy and never bothered to report it, thinking that it might be fixed in Fedora 17. I remember that Fedora 15 didn't behave like that.
This is annoying because in makes programs like gnome-calculator unusable. For example, If you are writing numbers with decimals and try to use dot(.) for decimal numbers, gnome-calculator ignores the input unless you use comma. A simple 1.1 x 1 becomes 11 x 1.
Noe Nieto is right. This isn't a bug, it's more like a "bad localization".
Let me explain, the default localization file for es_MX (and many other es_XX latam localizations) says that we use the same numerical layout as Spain (es_ES) but that's NOT true. We use the "point" for decimals and the "comma" for thousands.
A possible fix is changing the es_MX localization file and remove the "copy es_ES" and typing the correct information. Please fix this, it's annoying.
And yes, I'm using fedora 17 with the latest updates (20/08/12)
I can see in locale file es_ES is is defined differently
mon_decimal_point "<U002C>" ,
mon_thousands_sep "<U002E>" .
while in es_US it is
mon_decimal_point "<U002E>" .
mon_thousands_sep "<U002C>" ,
Thats might be problem
Thats right, the right config is in es_US. I suggest that the "copy es_ES" option under the LC_NUMERIC setting be changed for "copy es_US"... or correct it manually, one by one (setting mon_decimal_point "<U002E>" and mon_thousands_sep "<U002C>" on every es_XX file, skipping the ones that actually are that way)...
I've found another localization error (This time in the gnome-shell), should I file another bug report or can I simply report it here as well?
(In reply to comment #7)
> Thats right, the right config is in es_US. I suggest that the "copy es_ES"
> option under the LC_NUMERIC setting be changed for "copy es_US"... or
> correct it manually, one by one (setting mon_decimal_point "<U002E>" and
> mon_thousands_sep "<U002C>" on every es_XX file, skipping the ones that
> actually are that way)...
thanks for clarification.
This is confirmed issue with locale file (es_MX);
Current locale file es_MX:
>>>copy "es_ES" <<<this is bug, need to copy from en_US or change as LC_MONETARY
Issue: decimal and thouands separator should be same as Monetary in Number
(In reply to comment #8)
> I've found another localization error (This time in the gnome-shell), should
> I file another bug report or can I simply report it here as well?
Please file a separate bug for gnome-shell.
So, can someone with more familiarity with the latin america locales indicate which ones they think need to be changed so that we can do the necessary research to make those changes?
In general, we don't blindly change locales without some kind of documentation; anecdotal evidence WRT locales is generally ignored.
Yes agree, we cant do such a major change without reference.
Might be we can refer to Unicode cldr
or any other source
It's been claimed that CLDR isn't authortative enough, gov't documents would be better. If the best we have is CLDR, then it'll be a bit more of an uphill struggle.
I'd still like to see a list of the locales that need to be changed.
No props. In that case we should wait for references from users belonging to these languages.
FWIW, these are the es_* locales where we differ from CLDR with respect to LC_NUMERIC. es_DO, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR, es_SV.
Interestingly enough, all these were changed to copy es_ES by Uli within the last year as part of upstream sourceware BZ 13147, which was in response to a Red Hat BZ (number escapes me).
Of course Uli made this change and didn't reference any documents; furthermore, it was precisely the patch originally posted for BZ 13147 which had prompted Uli to claim to me that CLDR wasn't correct.
Noe, Benjamin, if you could find any local government documents which we could reference with examples of the proper formatting it'd go a long way towards getting this fixed. Note the document doesn't need to specify numerical formatting, just have examples. Similarly local newspapers are considered sufficient to get this stuff fixes these days.
A financial newspaper in Mexico.
Main site: http://www.elfinanciero.com.mx/
Stocks report with losts of examples:
This is the central bank of Mexico
A couple of examples
Let us know if this is useful. I can search for other sources if needed.
A government statistics site (There are pretty much examples everywhere, even at the main page):
The finances section of antoher newspaper's site:
Thanks people, we hope this help.
It helps. As a was wandering those links, I found an unemployment report which had the unemployment percentage which giving us the decimal mark and some large numbers which gives us the thousands separator & grouping.
Unfortunately those sites didn't have links which looked like I could use them and reference them at a later date if someone objected to the change. But it was enough to put me on the right track to find some gov't documents which show examples.
We can get grouping from this document from the Guatemala Government. Once we know grouping uses ',', then the decimal mark must be '.'.
Interestingly enough, Peru which was supposed to use '.' as the decimal separator and ',' as the thousands separator according to CLDR seems to do the opposite according to these government inflation and labor reports:
Anyway, I'll see if this is good enough to get things fixed upstream.
Submitted upstream as BZ 14510. A proposed patch is attached to that upstream bugzilla. If/when the upstream maintainers accept those patches we'll pull them into Fedora via our standard merging processes.
Thank you, people!