public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "keld at keldix dot com" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sources.redhat.com
Subject: [Bug localedata/14510] LC_NUMERIC wrong for various latin america locales
Date: Wed, 22 Aug 2012 23:56:00 -0000	[thread overview]
Message-ID: <bug-14510-131-uDfaEDvYVu@http.sourceware.org/bugzilla/> (raw)
In-Reply-To: <bug-14510-131@http.sourceware.org/bugzilla/>

http://sourceware.org/bugzilla/show_bug.cgi?id=14510

--- Comment #2 from keld at keldix dot com <keld at keldix dot com> 2012-08-22 23:56:18 UTC ---
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: unassigned@sourceware.org
>         ReportedBy: law@redhat.com
>                 CC: libc-locales@sources.redhat.com
>     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 according to standards here.

I looked i the IBM national Language Support Reference Manual ("The green
bible"),
that I also used as one of the sources for making many locales.
For monetary decimal point, it seems like in North America in Spanish speaking
countries, they use the point, while in South America they use the comma.

This is not far from what you report, but I think we need some more
authoritative sources.

Keld

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.


  parent reply	other threads:[~2012-08-22 23:56 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-22 17:54 [Bug localedata/14510] New: " law at redhat dot com
2012-08-22 18:03 ` [Bug localedata/14510] " law at redhat dot com
2012-08-22 23:56 ` keld at keldix dot com [this message]
2013-06-10 17:51 ` jorsol at ubuntu dot org.ni
2013-06-18 20:49 ` ldominguez at tamps dot cinvestav.mx
2014-01-13 19:25 ` emileneth at gmail dot com
2014-02-12  4:49 ` carlos at redhat dot com
2014-06-17  5:54 ` fweimer at redhat dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-14510-131-uDfaEDvYVu@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).