Re: Locales: Thousands separator

[Stanislav Brabec <sbrabec at suse dot cz>]

Marko Myllynen wrote:
> Hi,
> 
> Commit 70a6707 [1] changed many locales to use U+202F NARROW NO-BREAK
> SPACE (NNBSP) as the thousands separator instead of U+00A0 NO-BREAK
> SPACE (NBSP). The patch submission nor the follow-up discussion [2] did
> not cite any standards or references as rationale for this change.

The change was inspired by typography textbooks. Typography textbooks
recommend use of thin space as thousands separator. According to
Wikipedia, also ISO 31-0, International Bureau of Weights and Measures,
the International Union of Pure and Applied Chemistry and American
Medical Association recommends use of thin spaces.
https://en.wikipedia.org/wiki/Thin_space
https://en.wikipedia.org/wiki/Decimal_separator#Digit_grouping

NNBSP is the only UNICODE match for thin unbreakable space.

> CLDR defines thousand separator as NBSP for many of the languages
> affected by the change (the presentation on the page below is not
> optimal, you'll probably need to check the source code to see that
> indeed it's U+00A0 (using the " " notation) which is in use):
> 
> https://www.unicode.org/cldr/charts/33/by_type/numbers.symbols.html#a1ef41eaeb6982d
> 
> This means that due to the glibc change there is now inconsistency
> between the affected glibc locales and any CLDR-using platform. As a
> concrete example, Java 9 enabled CLDR locale data by default [3], so
> this inconsistency is not limited to cases across different systems but
> there might be applications running on a recent GNU/Linux system using
> different thousands separator.
> 
> I have been under impression that the long-term plan for glibc locales
> would be to use CLDR data as source to the extent possible so this
> change would seem to be at odds with that plan. I found no indications
> from CLDR Trac that CLDR would be switching to NNBSP. This inconsistency
> also presents a dilemma for keymap definitions when there is only one
> feasible key combination available for producing non-breaking space:
> which variant to choose, the glibc one or the CLDR one.
> 
> Given the considerations above, what do the glibc maintainers think
> about the current situation, is this inconsistency seen as an issue?

When I proposed this change, I was not aware of use of CLDR.

Created ticket now:
https://unicode.org/cldr/trac/ticket/11217

-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                         e-mail: sbrabec@suse.com
Křižíkova 148/34 (Corso IIa)                  tel: +49 911 7405384547
186 00 Praha 8-Karlín                          fax:  +420 284 084 001
Czech Republic                                    http://www.suse.cz/
PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76