Inconsistency in decimal point for es_MX and es_NI locale

Bug #997248 reported by JoseLuisTriana
138
This bug affects 32 people
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
langpack-locales (Ubuntu)
Fix Released
Low
Gunnar Hjalmarsson
Nominated for Trusty by Adolfo Jayme Barrientos

Bug Description

In México we use the point as decimal separator and the comma to separate thousands, But in the es_MX locale in Ubuntu precise it is set as in Europe; In System configuration> Language Support > Regional Formats I found in the example that the character that separates the thousands and millions is the point (.) and the one that separates the decimals is the comma (,) and that's incorrect for México, See attachment.

This problem is seen when I try to use the calculator, or other gnome program that involves math, it's confusing.

Revision history for this message
JoseLuisTriana (theunfor) wrote :
Revision history for this message
JoseLuisTriana (theunfor) wrote :

Additional information:

apt-cache policy locales:
  Instalados: 2.13+git20120306-3
  Candidato: 2.13+git20120306-3
  Tabla de versión:
 *** 2.13+git20120306-3 0
        500 http://mx.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
        100 /var/lib/dpkg/status

tags: added: gnome3 precise string-fix
Revision history for this message
Jean-Baptiste Mardelle (jb-kdenlive) wrote :

The same problem affects the Nicaragua's locale file (es_NI.UTF-8). Nicaragua seems to use a dot as decimal separator, not a comma (*). This causes problems in my application (Kdenlive) that is based on Qt, which uses the correct decimal separator (a dot).

I don't understand why this "langpack-locales" package does not use the values from the Common Unicode Repository (http://cldr.unicode.org/), because it is not the first problem I notice (see issue #887395 ) and I saw several similar issues reported here...

(*) I did a quick search, could not find an official document but Wikipedia, Microsoft and the Unicode Repository all agree on the fact that Nicaragua uses a dot as decimal separator

Changed in langpack-locales (Ubuntu):
status: New → Confirmed
Revision history for this message
Eduardo B. Winter (eduardo-winter) wrote :

Same problem affects Dominican Republic, we use coma for Thousands and dot for decimals

Revision history for this message
Israel Benítez Esquivel (israelbz) wrote :

I've found a temporary solution for this bug, changing the LC_NUMERIC environment variable to "en_US.UTF-8".

sudo update-locale LC_NUMERIC=es_US.UTF-8

After that, the /etc/default/locale contains:

LANG="es_MX.UTF-8"
LANGUAGE="es_MX:es"
LC_NUMERIC=es_US.UTF-8

I suppose that the bug is related with the file /usr/share/i18n/locales/es-MX which contents the following lines:

LC_NUMERIC
copy "es_ES"
END LC_NUMERIC

However, try change this file and it had no effect with the decimal separator.

Revision history for this message
In , Law-redhat (law-redhat) wrote :

Back in November 2011, Uli checked in a large change which affected the LC_NUMERIC settings of various es_* locales. This change didn't reference any supporting documentation.

It's now being reported that various es_* locals have the wrong LC_NUMERIC settings for the decimal mark and thousands separator.

First I compared the es_* locales to CLDR for LC_NUMERIC settings. This turned up several differences (es_DO, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR, es_SV).

For each of those locales I then went in search of documents, preferably government documents which would show usage of the decimal mark and thousands separator.

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

All the above referenced documents show a decimal mark as '.' and the thousands separator as ',', which indicate glibc's localedata is wrong.

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

Thus es_PE is correct as-is.

Revision history for this message
In , Law-redhat (law-redhat) wrote :

Created attachment 6600
Patch to fix various es_* locales

Revision history for this message
In , Keld Simonsen (keld) wrote :
Download full text (3.5 KiB)

On Wed, Aug 22, 2012 at 05:54:17PM +0000, law at redhat dot com wrote:
> http://sourceware.org/bugzilla/show_bug.cgi?id=14510
>
> Bug #: 14510
> Summary: LC_NUMERIC wrong for various latin america locales
> Product: glibc
> Version: 2.17
> Status: NEW
> Severity: normal
> Priority: P2
> Component: localedata
> AssignedTo: <email address hidden>
> ReportedBy: <email address hidden>
> CC: <email address hidden>
> Classification: Unclassified
>
>
> Back in November 2011, Uli checked in a large change which affected the
> LC_NUMERIC settings of various es_* locales. This change didn't reference any
> supporting documentation.
>
> It's now being reported that various es_* locals have the wrong LC_NUMERIC
> settings for the decimal mark and thousands separator.
>
> First I compared the es_* locales to CLDR for LC_NUMERIC settings. This turned
> up several differences (es_DO, es_GT, es_HN, es_MX, es_NI, es_PA, es_PE, es_PR,
> es_SV).
>
> For each of those locales I then went in search of documents, preferably
> government documents which would show usage of the decimal mark and thousands
> separator.
>
>
> 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
>
> All the above referenced documents show a decimal mark as '.' and the thousands
> separator as ',', which indicate glibc's localedata is wrong.
>
>
> 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
>
> Thus es_PE is correct as-is.

I checked a few of your references. They were economic reports.
Not kind of normative specifications from a standards or language authority.
You can also in my country (Denmark) find examples of use of the decimal point, which is
not a...

Read more...

Revision history for this message
JorSol (jorsol) wrote :

Yes, Nicaragua's locale file (es_NI.UTF-8) is affected too. The decimal separator is a dot "." not a comma "," and the thousands separator is a comma, not a dot.

$ locale -k LC_NUMERIC
decimal_point=","
thousands_sep="."

Expected results:
$ locale -k LC_NUMERIC
decimal_point="."
thousands_sep=","

/usr/share/i18n/locales/es_NI has:
LC_NUMERIC
copy "es_ES"
END LC_NUMERIC

and should be:
LC_NUMERIC
decimal_point "<U002E>"
thousands_sep "<U002C>"
grouping 3;3
END LC_NUMERIC

Then I make a "dpk-reconfigure locales" and works fine.

JorSol (jorsol)
summary: - Inconsistency in decimal point for es_MX locale
+ Inconsistency in decimal point for es_MX and es_NI locale
Revision history for this message
Eduardo B. Winter (eduardo-winter) wrote :

The exact same case for DR Dominican Republic, we use dot instead of coma for decimal place... this causes a lot of errors with applications, Open Office, OpenERP, etc...

Revision history for this message
Carlos Matos Villar (carlosmvillar19) wrote :

We need a Solution for those kind of issues!

What can we do with the operators that need the "." intead of "," to separate Decimals and Thousands?
There's a language pack for it?

Revision history for this message
JoseLuisTriana (theunfor) wrote :

This bug is very important, and should be fixed for the common user... Nobody needs to get too deep in the configuration.

Revision history for this message
JorSol (jorsol) wrote :
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "fix-decimal-separator-bug-997248.debdiff" of this bug report has been identified as being a patch in the form of a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-sponsors team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
cyberneto (cyberneto)
Changed in langpack-locales (Ubuntu):
status: Confirmed → In Progress
Revision history for this message
Daniel Holbach (dholbach) wrote :

Thanks a lot for your work on this.

To go ahead, do you think you could forward your change along with some explanation or a link to an official document to http://sourceware.org/bugzilla/enter_bug.cgi?product=glibc using the "localedata" component? It's important that Ubuntu does not get out of sync with other parts of the Free Software world and the change is approved by authorities.

Thanks in any case. If you need any more help with this, please let us know.

Changed in langpack-locales (Ubuntu):
status: In Progress → Incomplete
cyberneto (cyberneto)
Changed in langpack-locales (Ubuntu):
status: Incomplete → Confirmed
Changed in glibc:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Israel Benítez Esquivel (israelbz) wrote :

In Mexico the decimal_point is '.' and thousands_sep is ',' But this, surprisingly for me, may be wrong according the Real Academia Española

http://www.rae.es/dpd/srv/search?id=QHaq7I8KrD6FQAyXTS

2. Ortografía de los números escritos con cifras. Para escribir correctamente los números expresados en cifras, debe tenerse en cuenta lo siguiente:

a) Al escribir números de más de cuatro cifras, se agruparán estas de tres en tres, empezando por la derecha, y separando los grupos por espacios en blanco: 8 327 451 (y no por puntos o comas, como, dependiendo de las zonas, se hacía hasta ahora: 8.327.451; 8,327,451). Los números de cuatro cifras se escriben sin espacios de separación: 2458 (no 2 458). En ningún caso deben repartirse en líneas diferentes las cifras que componen un número: 8 327 / 451.

b) Nunca se escriben con puntos, comas ni blancos de separación los números referidos a años, páginas, versos, portales de vías urbanas, códigos postales, apartados de correos, números de artículos legales, decretos o leyes: año 2001, página 3142, código postal 28357.

c) Para separar la parte entera de la decimal debe usarse la coma, según establece la normativa internacional: El valor de π es 3,1416. No obstante, también se admite el uso anglosajón del punto, extendido en algunos países americanos: El valor de π es 3.1416.

Revision history for this message
JorSol (jorsol) wrote :

@israelbz , in Europe they use a decimal_point as ',' (coma) and thousands_sep as '.' (dot), so the RAE is not wrong, in Spain they use that convention....

But in various countries in America is used as decimal_point a '.' (dot) and thousands_sep is ',' (coma).

Revision history for this message
Adolfo Jayme Barrientos (fitojb) wrote :

Israel, JorSol is right. Let me quote expert Javier Bezos from Fundéu: "No hay unidad sobre la marca decimal en el mundo hispanohablante, pues la coma es habitual en España y Cono Sur, mientras que el punto es más frecuente en México y los países del Caribe."

Changed in langpack-locales (Ubuntu):
importance: Undecided → Low
Revision history for this message
In , Luis Dominguez (ldominguez-y) wrote :

In Mexico, the official regulation (NOM-008-SCFI-1993, and NOM-008-SCFI-2002) set the decimal sign is as in the IS; however, in 2009 both the comma and the point were declared valid. Unfortunately, these kind of regulations are not mandatory, and people use the other notation in daily use, or as in the examples by <email address hidden>

[ESP]
2009 reform: http://www.dof.gob.mx/nota_detalle.php?codigo=5111108&fecha=24/09/2009

Last release: http://www.amap.com.mx/download/26.NOM-008-SCFI-2002%20Sistema%20general%20de%20unidades%20de%20medida.pdf

Revision history for this message
Heriberto Alvarado A (chimi-hto) wrote :

In Costa Rica, We have the same problem, same as Mexico, Nicaragua, Honduras, El Salvador, and others latin american countrys. The locale file is affected. I commented to support the initiative to correct this error. I hope it can be solved in the near future..

Regards,

Revision history for this message
Carlos Leonel (clcl31080) wrote :

In Guatemala, we have the same problem. Please correct this error.

Regards,

Revision history for this message
In , Christian Servín (emileneth-h) wrote :

The reference:
"México: http://www.economia.gob.mx/files/diagnostico_economia_mexicana.pdf"

Is a gobernment document for formal informational purposes and it obeys a visual design (like a powrpoint presentation), it is not intended for computer systems I'm listing the troubles with this document:

a) Numerical data is presented with one, two or three decimals, depending on the precision needed in the graph or paragraph. For day to day computational numerical presentations two digit is good enough, just the same as en_US.
b) The document arbitrarily use Monetary format without the thousand separator ",", page 22 uses the notation 833,998 mdp (millions of pesos) without the $ symbol, but like the en_US we do use the $ symbol for money
c) Commonly the percentual values are good enough with %XX.x, math is math here and in china.

Latin American numerical keyboard uses the "." for decimal and it is important for us because when we make calculations with this keyboard its we use this key for fast typing, same as in en_US

Right now the locale is like the spaniard persons use it. We can use the es_ES way (decimal"," & thousands".") only when we exchange documents with en_ES country, but it is not very common.

In México as of Jan 2010 it was introduced an increment in tax, up to 16%, this value introduces troubles while calculating accounting balances when using only 2 decimal digits, so since that date accounting and monetary systems began to use 4 digit precision. Formatted monetary values must include all 4 digits to avoid manual transcription errors or precision errors during numerical methods.

For the same reason we also use 4 digits when exchanging currencies (same as en_US): http://finance.yahoo.com/q?s=USDMXN=X

This issue goes back to 2012, its time to make it right

See also:

http://publib.boulder.ibm.com/infocenter/forms/v3r5m0/index.jsp?topic=/com.ibm.form.designer.locales.doc/i_xfdl_r_formats_es_MX.html

http://lh.2xlibre.net/locale/es_MX/

http://www.localeplanet.com/icu/es-MX/

Revision history for this message
In , Christian Servín (emileneth-h) wrote :

I just edited my
/usr/share/i18n/locales/es_MX

From:
LC_NUMERIC
copy "es_ES"
END LC_NUMERIC

To:
LC_NUMERIC
copy "en_US"
END LC_NUMERIC

and inside LC_MONETARY
int_frac_digits4
frac_digits 4

Revision history for this message
In , Carlos-0 (carlos-0) wrote :

This issue has been fixed for a while now. Marking as fixed.

It does not fix the fractional digits for es_MX though, and those remain at 2. Please file a new bug to discuss making this 4.

localedata/ChangeLog

2012-09-05 Jeff Law <email address hidden>

        [BZ#14510]
        * locales/es_DO: Fix LC_NUMERIC decimal_point and thousands_sep.
        * locales/es_GT: Likewise.
        * locales/es_HN: Likewise.
        * locales/es_MX: Likewise.
        * locales/es_NI: Likewise.
        * locales/es_PA: Likewise.
        * locales/es_PR: Likewise.
        * locales/es_SV: Likewise.

Changed in glibc:
status: Confirmed → Fix Released
Revision history for this message
Miguel Meléndez (miguelmmg) wrote :

The status is "Fix Released" but this bug still affects Precise and Trusty.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

@Miguel: It means that it has been fixed upstream. I will propose a similar Ubuntu change.

Changed in langpack-locales (Ubuntu):
assignee: nobody → Gunnar Hjalmarsson (gunnarhj)
status: Confirmed → In Progress
Changed in langpack-locales (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package langpack-locales - 2.13+git20120306-13

---------------
langpack-locales (2.13+git20120306-13) utopic; urgency=low

  * debian/patches/ubuntu-es-decimal_point-thousands_sep.patch:
    Modify thousands separator and decimal point in some Spanish
    locales (LP: #997248, LP: #1074797).
 -- Gunnar Hjalmarsson <email address hidden> Fri, 25 Apr 2014 01:50:00 +0200

Changed in langpack-locales (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Miguel Meléndez (miguelmmg) wrote :

Is the fix available in proposed packages for Precise and Trusty?

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

On 2014-04-25 20:12, Miguel Meléndez wrote:
> Is the fix available in proposed packages for Precise and Trusty?

No, the fix so far is for utopic. I have attached a trusty patch to bug #1074797, and hopefully it will soon be uploaded to trusty-proposed.

Precise is two years old, and considering the nature of the bug, I for one am not inclined to work with getting the fix into precise. If you think otherwise, please feel free to try.

Revision history for this message
Adolfo Jayme Barrientos (fitojb) wrote :

Thanks for your work on this, Gunnar!

no longer affects: hundredpapercuts
Revision history for this message
Scott Kitterman (kitterman) wrote : Please test proposed package

Hello JoseLuisTriana, or anyone else affected,

Accepted langpack-locales into trusty-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/langpack-locales/2.13+git20120306-12.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

tags: added: verification-needed
Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :
tags: added: verification-done
removed: verification-needed
Revision history for this message
Scott Kitterman (kitterman) wrote : Update Released

The verification of the Stable Release Update for langpack-locales has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

Revision history for this message
argotvisual (mad-argotvisual) wrote :

There are a regression in Trusty, after a update, the bug appears again, the locale es_MX has the 'copy "es_ES"' estatement in LC_NUMERIC.

It is very important, because as in my case the server sends the float numbers in the format 10,5, 10.5, in the case of Chrome browser, the HTML5 numeric type fields don't display the number causing errors in Web applications.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.