|Summary:||Wrong decimal point separator for many latin-american localizations|
|Product:||[Fedora] Fedora||Reporter:||Benjamin Ariel Nava Martinez <arielnmz>|
|Component:||glibc||Assignee:||Jeff Law <law>|
|Status:||CLOSED UPSTREAM||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||17||CC:||aalam, control-center-maint, fweimer, i18n-bugs, jakub, law, mkasik, nnieto, pfrankli, piotrdrag, psatpute, rstrode, schwab|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2012-08-22 18:04:05 UTC||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Benjamin Ariel Nava Martinez 2012-08-20 03:55:42 UTC
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) How reproducible: 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" Actual results: It uses a comma instead of a point Expected results: A point Additional info:
Comment 1 A S Alam 2012-08-20 06:26:17 UTC
it is software Bug with control-center-3.4.2-1.fc17.x86_64
Comment 2 A S Alam 2012-08-20 06:32:39 UTC
Is this issue with input? any specific keyboard with xkb (or ibus)? Also please confirm that it is Fedora 17. thanks
Comment 3 Noe Nieto 2012-08-20 18:26:27 UTC
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.
Comment 4 Benjamin Ariel Nava Martinez 2012-08-21 01:30:13 UTC
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)
Comment 5 Pravin Satpute 2012-08-21 05:14:29 UTC
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
Comment 7 Benjamin Ariel Nava Martinez 2012-08-21 05:39:39 UTC
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)...
Comment 8 Benjamin Ariel Nava Martinez 2012-08-21 05:48:10 UTC
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?
Comment 9 A S Alam 2012-08-21 05:55:08 UTC
(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: LC_MONETARY int_curr_symbol "<U004D><U0058><U004E><U0020>" currency_symbol "<U0024>" mon_decimal_point "<U002E>" mon_thousands_sep "<U002C>" mon_grouping 3;3 positive_sign "" negative_sign "<U002D>" int_frac_digits 2 frac_digits 2 p_cs_precedes 1 p_sep_by_space 1 n_cs_precedes 1 n_sep_by_space 1 p_sign_posn 1 n_sign_posn 1 END LC_MONETARY LC_NUMERIC >>>copy "es_ES" <<<this is bug, need to copy from en_US or change as LC_MONETARY END LC_NUMERIC Issue: decimal and thouands separator should be same as Monetary in Number package: glibc-common-2.15-56.fc17.x86_64
Comment 10 A S Alam 2012-08-21 05:56:34 UTC
(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.
Comment 11 Jeff Law 2012-08-21 15:33:21 UTC
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.
Comment 12 Pravin Satpute 2012-08-21 15:56:31 UTC
Yes agree, we cant do such a major change without reference. Might be we can refer to Unicode cldr http://unicode.org/cldr/trac/browser/tags/release-21-0-2/posix/es_ES.UTF-8.src http://unicode.org/cldr/trac/browser/tags/release-21-0-2/posix/es_MX.UTF-8.src or any other source
Comment 13 Jeff Law 2012-08-21 17:16:32 UTC
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.
Comment 14 Pravin Satpute 2012-08-21 17:49:24 UTC
No props. In that case we should wait for references from users belonging to these languages.
Comment 15 Jeff Law 2012-08-21 19:40:27 UTC
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. Jeff
Comment 16 Noe Nieto 2012-08-21 23:27:04 UTC
El financiero ============= A financial newspaper in Mexico. Main site: http://www.elfinanciero.com.mx/ Stocks report with losts of examples: http://www.elfinanciero.com.mx/index.php?option=com_content&view=section&id=2&Itemid=4 Banxico ======= This is the central bank of Mexico Main site: http://www.banxico.org.mx/ A couple of examples http://www.banxico.org.mx/SieInternet/consultarDirectorioInternetAction.do?accion=consultarCuadro&idCuadro=CF315§or=11&locale=es http://www.banxico.org.mx/SieInternet/consultarDirectorioInternetAction.do?accion=consultarCuadro&idCuadro=CM2§or=11&locale=es Let us know if this is useful. I can search for other sources if needed.
Comment 17 Benjamin Ariel Nava Martinez 2012-08-22 00:39:38 UTC
Another sources: A government statistics site (There are pretty much examples everywhere, even at the main page): http://www.inegi.org.mx/ The finances section of antoher newspaper's site: http://www.oem.com.mx/elsoldelbajio/finanzas.aspx Thanks people, we hope this help.
Comment 18 Jeff Law 2012-08-22 17:33:25 UTC
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. Mexico: http://www.economia.gob.mx/files/diagnostico_economia_mexicana.pdf Dominican Republic: http://www.bancentral.gov.do/noticias/avisos/aviso2010-06-25.pdf We can get grouping from this document from the Guatemala Government. Once we know grouping uses ',', then the decimal mark must be '.'. http://www.ine.gob.gt/np/enei/ENEI2011.htm Honduras: http://www.ine.gob.hn/drupal/node/175 http://archivo.laprensa.hn/Negocios/Ediciones/2011/02/07/Noticias/Tasa-de-desempleo-de-Honduras-subio-a-44 Nicaragua: http://www.bcn.gob.ni/estadisticas/economicas_anuales/nicaragua_en_cifras/2010/Nicaragua_en_cifras2010.pdf Panama: http://www.mef.gob.pa/portal/2011-Comunicados/2011-DISMINUYESUSTANCIALMENTEELDESEMPLEOENPANAMA.html Puerto Rico: http://www.periodicolaperla.com/index.php?option=com_content&view=article&id=3606:en-puerto-rico-la-tasa-de-empleo-cae-al-nivel-mas-bajo-en-la-historia&catid=93:analisis-economico&Itemid=300 El Salvador: http://www.minec.gob.sv/index.php?option=com_content&view=article&catid=1:noticias-ciudadano&id=1567:encuesta&Itemid=77 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: http://www.bcrp.gob.pe/docs/Publicaciones/Reporte-Inflacion/2010/marzo/Reporte-de-Inflacion-Marzo-2010.pdf http://www.inei.gob.pe/biblioineipub/bancopub/Est/Lib0909/libro.pdf Anyway, I'll see if this is good enough to get things fixed upstream.
Comment 19 Jeff Law 2012-08-22 18:04:05 UTC
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.
Comment 20 Benjamin Ariel Nava Martinez 2012-08-22 23:23:01 UTC
Thank you, people!