Locales: Thousands separator

[Marko Myllynen <myllynen@redhat.com>]

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.

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?

1)
https://sourceware.org/git/?p=glibc.git;a=commit;h=70a6707fa15e63591d991761be025e26e8d02bb6
2) https://sourceware.org/ml/libc-alpha/2016-11/msg00062.html
3)
https://docs.oracle.com/javase/9/intl/internationalization-enhancements-jdk-9.htm

Thanks,

-- 
Marko Myllynen