Ubuntu

Inconsistency in decimal point for es_MX and es_NI locale

Reported by JoseLuisTriana on 2012-05-09
130
This bug affects 31 people
Affects Status Importance Assigned to Milestone
GLibC
Fix Released
Medium
langpack-locales (Ubuntu)
Low
Unassigned

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.

JoseLuisTriana (theunfor) wrote :
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
j-b-m (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

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in langpack-locales (Ubuntu):
status: New → Confirmed

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

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.

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.

Created attachment 6600
Patch to fix various es_* locales

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...

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) on 2012-09-11
summary: - Inconsistency in decimal point for es_MX locale
+ Inconsistency in decimal point for es_MX and es_NI locale

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...

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?

I am from DR (Dominican Republic)

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.

JorSol (jorsol) 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) on 2012-10-13
Changed in langpack-locales (Ubuntu):
status: Confirmed → In Progress
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
Daniel Holbach (dholbach) wrote :

Once you forwarded it, please also share the link here.

cyberneto (cyberneto) on 2012-10-24
Changed in langpack-locales (Ubuntu):
status: Incomplete → Confirmed
Michael Terry (mterry) wrote :

Unsubscribing ~ubuntu-sponsors since as dholbach says, we shouldn't apply this patch to Ubuntu ahead of upstream.

Changed in glibc:
importance: Unknown → Medium
status: Unknown → Confirmed

I confirm that in Nicaragua the decimal_point is "." and thousands_sep is ","

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.

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).

Adolfo Jayme (fitoschido) 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

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

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,

Carlos Leonel (clcl31080) wrote :

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

Regards,

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/

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

From:
LC_NUMERIC

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

JoseLuisTriana (theunfor) wrote :

Oh my god.. I reported this almost two years ago.. and nobody is willing to fix this... but by myself I don't use Ubuntu nor Gnome anyway... both have this problem KDE not.

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
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

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