Re: de_DE has been using the wrong group separator for over 18 years

[Carlos O'Donell <carlos at redhat dot com>]

On 04/19/2018 03:40 PM, Florian Weimer wrote:
> 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.

Exactly. So our locale progression has been:

U+0020 -> U+2009 -> U+202F

As we became more knowledgeable with Unicode, but that still doesn't
mean it should be chosen if it's not common practice.

>> 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.

Agreed.

I would expect a word processor to automatically format my numbers
given the locale. However, while writing by hand it can be a bit hard
to detect exactly when to do that, but not impossible.

In LibreOffice it's a slightly long "ctrl+shift+U 202f enter", but
it's not impossible, nor overly difficult, and you can script it with
a quick auto-correct e.g. :nbs: => U+202F, or some other kind of
automation.

-- 
Cheers,
Carlos.