This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug localedata/14510] LC_NUMERIC wrong for various latin america locales


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

Christian ServÃn <emileneth at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |emileneth at gmail dot com

--- Comment #5 from Christian ServÃn <emileneth at gmail dot com> ---
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/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]