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