de_DE has been using the wrong group separator for over 18 years
Florian Weimer
fweimer@redhat.com
Thu Apr 19 20:40:00 GMT 2018
On 04/19/2018 09:55 PM, Carlos O'Donell wrote:
> On 04/19/2018 03:55 AM, Florian Weimer wrote:
>> On 04/18/2018 11:10 PM, kdex wrote:
>>> Hence, the point is less that locale users need the ability to have
>>> U+2009 mapped on their keyboards somewhere, but rather that users
>>> should be able to input regular numbers and rely on their software
>>> to use their system locale to figure out how their numbers should
>>> be displayed according to the current locale.
>>
>> But that's not how people enter numbers in their word processor.
>>
>> U+2009 also has the wrong line breaking property in the basic Unicode
>> line breaking algorithm <https://unicode.org/reports/tr14/>, so it
>> makes it quite hard for word processors to do the right thing even if
>> the user managers to enter this character.
>
> We use U+202F now.
Ahh, I knew that I was missing something. Nice to know that Unicode has
a narrow non-breaking space. That's seems to be completely appropriate
if you want to use a narrow space in this context.
> There is some history here with regard to U+2009.
>
> I reviewed the es_MX case for thousands_sep becoming U+2009, and I wrote
> to the Mexican government, and reviewed the relative standards and
> cultural use cases, but I did *not* consider the impact on the ability for
> users to type or the line-breaking aspects of the change (nor do I think
> the standard covered these problems).
The matter of entering the character is not so important to glibc's use
case, I think. But it should matter for a standard with *word
processor* usage guidelines. If it requires using an
impossible-to-enter character for conformance, then it looks like
something went wrong during the standardization process.
Thanks,
Florian
More information about the Libc-alpha
mailing list