Locales: Thousands separator

Locales: Thousands separator

[Marko Myllynen]

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

Re: Locales: Thousands separator

[Carlos O'Donell]

On 06/20/2018 04:10 AM, Marko Myllynen wrote:
> 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.

No standards need citing. It was clear that SPACE was wrong.

> Given the considerations above, what do the glibc maintainers think
> about the current situation, is this inconsistency seen as an issue?

... the mistake is that we didn't check to harmonize with CLDR.

Please file a bug and we'll change from NNBSP->NBSP to match CLDR.

Even though I think NBSP is visually wrong, we need to change both
CLDR and glibc at the same time to match.

Cheers,
Carlos.

Re: Locales: Thousands separator

[Marko Myllynen]

Hi,

On 2018-06-20 16:01, Carlos O'Donell wrote:
> On 06/20/2018 04:10 AM, Marko Myllynen wrote:
>> 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.
> 
> No standards need citing. It was clear that SPACE was wrong.

Sure, there was no question about that.

>> Given the considerations above, what do the glibc maintainers think
>> about the current situation, is this inconsistency seen as an issue?
> 
> ... the mistake is that we didn't check to harmonize with CLDR.
> 
> Please file a bug and we'll change from NNBSP->NBSP to match CLDR.

Thanks, I just filed:

https://sourceware.org/bugzilla/show_bug.cgi?id=23318

> Even though I think NBSP is visually wrong, we need to change both
> CLDR and glibc at the same time to match.

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Mike FABIAN]

Carlos O'Donell <carlos@redhat.com> さんはかきました:

> On 06/20/2018 04:10 AM, Marko Myllynen wrote:
>> 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.
>
> No standards need citing. It was clear that SPACE was wrong.
>
>> Given the considerations above, what do the glibc maintainers think
>> about the current situation, is this inconsistency seen as an issue?
>
> ... the mistake is that we didn't check to harmonize with CLDR.
>
> Please file a bug and we'll change from NNBSP->NBSP to match CLDR.

CLDR usually has U+0020 SPACE, *not* U+00A0 NO-BREAK-SPACE.

See for example:

http://unicode.org/cldr/trac/browser/trunk/common/main/fi.xml

which contains:

5751	                <symbols numberSystem="latn">
5752	                        <decimal>,</decimal>
5753	                        <group> </group>
                                       ^  This is a regular space U+0020 SPACE
5754	                        <list>;</list>
5755	                        <percentSign>%</percentSign>
5756	                        <plusSign>+</plusSign>
5757	                        <minusSign>−</minusSign>
5758	                        <exponential>E</exponential>
5759	                        <superscriptingExponent>×</superscriptingExponent>
5760	                        <perMille>‰</perMille>
5761	                        <infinity>∞</infinity>
5762	                        <nan>epäluku</nan>
5763	                        <timeSeparator>.</timeSeparator>
5764	                </symbols>
> Even though I think NBSP is visually wrong, we need to change both
> CLDR and glibc at the same time to match.
>
> Cheers,
> Carlos.

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

Re: Locales: Thousands separator

[Marko Myllynen]

Hi,

On 2018-06-20 18:36, Mike FABIAN wrote:
> Carlos O'Donell <carlos@redhat.com> さんはかきました:
>> On 06/20/2018 04:10 AM, Marko Myllynen wrote:
>>> 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.
>>
>> Please file a bug and we'll change from NNBSP->NBSP to match CLDR.
> 
> CLDR usually has U+0020 SPACE, *not* U+00A0 NO-BREAK-SPACE.
> 
> See for example:
> 
> http://unicode.org/cldr/trac/browser/trunk/common/main/fi.xml
> 
> which contains:
> 
> 5753	                        <group> </group>
>                                        ^  This is a regular space U+0020 SPACE

There seems to be some sort of rendering issue with the above file: if
you download the CLDR data for the above file
(https://unicode.org/Public/cldr/33/cldr-common-33.0.zip) and
investigate the corresponding common/main/fi.xml file in it, you'll find
U+00A0 not U+0020 in there.

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Andreas Schwab]

On Jun 20 2018, Marko Myllynen <myllynen@redhat.com> wrote:

> There seems to be some sort of rendering issue with the above file: if
> you download the CLDR data for the above file
> (https://unicode.org/Public/cldr/33/cldr-common-33.0.zip) and
> investigate the corresponding common/main/fi.xml file in it, you'll find
> U+00A0 not U+0020 in there.

That doesn't say anthing.  The file uses NBSP extensively for
formatting.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Locales: Thousands separator

[Marko Myllynen]

Hi,

On 2018-06-21 00:26, Andreas Schwab wrote:
> On Jun 20 2018, Marko Myllynen <myllynen@redhat.com> wrote:
> 
>> There seems to be some sort of rendering issue with the above file: if
>> you download the CLDR data for the above file
>> (https://unicode.org/Public/cldr/33/cldr-common-33.0.zip) and
>> investigate the corresponding common/main/fi.xml file in it, you'll find
>> U+00A0 not U+0020 in there.
> 
> That doesn't say anthing.  The file uses NBSP extensively for
> formatting.

Not sure why NBSP is used for formatting but if we look at e.g. Albanian
where there's an earlier Trac ticket stating that thousands separator
has been changed to NBSP (https://unicode.org/cldr/trac/ticket/5247),
the initial reference I mentioned
(https://www.unicode.org/cldr/charts/33/by_type/numbers.symbols.html#a1ef41eaeb6982d)
and the corresponding Albanian file (common/main/sq.xml) inside the
above zip are both consistent with the change to use NBSP as recorded in
the Trac ticket.

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Marko Myllynen]

Hi,

On 2018-06-21 16:07, Marko Myllynen wrote:
> 
> Not sure why NBSP is used for formatting but if we look at e.g. Albanian
> where there's an earlier Trac ticket stating that thousands separator
> has been changed to NBSP (https://unicode.org/cldr/trac/ticket/5247),
> the initial reference I mentioned
> (https://www.unicode.org/cldr/charts/33/by_type/numbers.symbols.html#a1ef41eaeb6982d)
> and the corresponding Albanian file (common/main/sq.xml) inside the
> above zip are both consistent with the change to use NBSP as recorded in
> the Trac ticket.

FWIW, an additional reference could be the CLDR Survey Tool
(http://cldr.unicode.org/index/survey-tool) which provides also an
interface to query values:

https://st.unicode.org/cldr-apps/

If you go from there to CLDR Survey Tool -> <locale> -> Numbers ->
Symbols -> Group it'll show U+00A0 instead of U+0020 for the earlier
mentioned case examples (and other locales using NBSP).

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Florian Weimer]

On 06/20/2018 03:01 PM, Carlos O'Donell wrote:
> On 06/20/2018 04:10 AM, Marko Myllynen wrote:
>> 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.
> 
> No standards need citing. It was clear that SPACE was wrong.

DIN has a breaking space in their national standard, too, as discussed 
previously.  But I agree that we don't need to follow standards when 
they are clearly technically broken or do not reflect existing practice, 
particularly in the area of cultural conventions.

Thanks,
Florian

Re: Locales: Thousands separator

[Stanislav Brabec]

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

Re: Locales: Thousands separator

[Mike FABIAN]

Stanislav Brabec <sbrabec@suse.cz> さんはかきました:

> When I proposed this change, I was not aware of use of CLDR.
>
> Created ticket now:
> https://unicode.org/cldr/trac/ticket/11217

I also think that it is better to change CLDR in this case,
especially since it seems to use U+0020 SPACE.

Surely a non breakable version of a space seems better.

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。

Re: Locales: Thousands separator

[Stanislav Brabec]

On 06/20 2018 at 05:20 PM Stanislav Brabec wrote:
> Marko Myllynen wrote:
>> 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.
...
>> 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
> 
CLDR decided to accept the NNBSP approach.

In the CLDR version 36, they decided to use French as a NNBSP trial:
https://www.unicode.org/cldr/charts/36/by_type/numbers.symbols.html#a1ef41eaeb6982d

-- 
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: +420 284 084 060
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

Re: Locales: Thousands separator

[Marko Myllynen]

Hi Stanislav,

On 04/12/2019 18.57, Stanislav Brabec wrote:
> On 06/20 2018 at 05:20 PM Stanislav Brabec wrote:
>> Marko Myllynen wrote:
>>> 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.
> ...
>>> 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
>>
> CLDR decided to accept the NNBSP approach.
> 
> In the CLDR version 36, they decided to use French as a NNBSP trial:
> https://www.unicode.org/cldr/charts/36/by_type/numbers.symbols.html#a1ef41eaeb6982d

Thanks for the heads-up. However, I'm unable to find where this
intention is clearly stated, could you please share a public reference
for this that could be used to pass the news onwards?

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Stanislav Brabec]

Marko Myllynen wrote:
> Hi Stanislav,
>
> On 04/12/2019 18.57, Stanislav Brabec wrote:
>> On 06/20 2018 at 05:20 PM Stanislav Brabec wrote:
>>> Marko Myllynen wrote:
>> CLDR decided to accept the NNBSP approach.
>>
>> In the CLDR version 36, they decided to use French as a NNBSP trial:
>> https://www.unicode.org/cldr/charts/36/by_type/numbers.symbols.html#a1ef41eaeb6982d
>>
>> Thanks for the heads-up. However, I'm unable to find where this
>> intention is clearly stated, could you please share a public reference
>> for this that could be used to pass the news onwards?

https://unicode-org.atlassian.net/browse/CLDR-11217 comment 6.

-- 
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: +420 284 084 060
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

Re: Locales: Thousands separator

[Marko Myllynen]

Hi,

On 12/12/2019 16.15, Stanislav Brabec wrote:
> Marko Myllynen wrote:
>> On 04/12/2019 18.57, Stanislav Brabec wrote:
>>> On 06/20 2018 at 05:20 PM Stanislav Brabec wrote:
>>>> Marko Myllynen wrote:
>>> CLDR decided to accept the NNBSP approach.
>>>
>>> In the CLDR version 36, they decided to use French as a NNBSP trial:
>>> https://www.unicode.org/cldr/charts/36/by_type/numbers.symbols.html#a1ef41eaeb6982d
>>>
>>> Thanks for the heads-up. However, I'm unable to find where this
>>> intention is clearly stated, could you please share a public reference
>>> for this that could be used to pass the news onwards?
> 
> https://unicode-org.atlassian.net/browse/CLDR-11217 comment 6.

I don't think that's conclusive; the comment was made on Dec 2018 and
e.g. this later ticket on the subject still seems unresolved:

https://unicode-org.atlassian.net/browse/CLDR-11423

Also, CLDR 34 release notes mention French migration from NBSP to NNBSP
but CLDR 35/36 notes do not mention anything NNBSP related, surely that
kind of change would have been release notes worthy?

http://cldr.unicode.org/index/downloads/cldr-34
http://cldr.unicode.org/index/downloads/cldr-35
http://cldr.unicode.org/index/downloads/cldr-36

Thanks,

-- 
Marko Myllynen

Re: Locales: Thousands separator

[Rafal Luzynski]

20.06.2018 10:10 Marko Myllynen <myllynen@redhat.com> wrote:
> [...]
> 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.

As far as I know Java uses its own implementation of ICU internally
(icu4j, if I remember correctly).  It does not attempt to use or to
imitate the libc API (I mean the functions like sprintf or strfromd
or strftime).  So it is easier to compare it with libicu rather than
glibc.

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

True although I always assumed that the differences between CLDR
and glibc would be allowed if we have a good reason to differ.

> [...]
> Given the considerations above, what do the glibc maintainers think
> about the current situation, is this inconsistency seen as an issue?

That was going to be my question.  Actually two questions:

1. Are there users complaining about this change?  By users I mean
   both the application developers (who use glibc to develop their
   applications) and actual end users (who see the output generated
   by glibc).
2. Does this change cause any technical problems, like application
   failures or malfunctions?

> 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


20.06.2018 17:20 Stanislav Brabec <sbrabec@suse.cz> wrote:
> [...]
> Created ticket now:
> https://unicode.org/cldr/trac/ticket/11217

Thank you.  Is it likely that we get an answer from CLDR soon?
It would be bad to flash the git reverts.

That said, although I like the change from NBSP to NNBSP, my
preference of NNBSP over NBSP is weak so I am not going to
object against reverting back to NBSP if you guys decide this.

Regards,

Rafal

Re: Locales: Thousands separator

[Carlos O'Donell]

On 06/20/2018 06:42 PM, Rafal Luzynski wrote:
> 20.06.2018 10:10 Marko Myllynen <myllynen@redhat.com> wrote:
>> 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 [...]
> 
> True although I always assumed that the differences between CLDR
> and glibc would be allowed if we have a good reason to differ.

Each case is unique.

In this case we don't have a strong rationale for being different.

We should match CLDR within reason.

We could switch to NBSP, and just wait for the CLDR ticket to be
resolved, and then switch back to NNBSP and we would both match.

The goal is to try harmonize this data across the various
implementations. There is nothing more frustrating for users
than to have different display data like this.

Does that make sense?

Cheers,
Carlos.

Re: Locales: Thousands separator

[Rafal Luzynski]

21.06.2018 16:15 Carlos O'Donell <carlos@redhat.com> wrote:
> [...]
> We could switch to NBSP, and just wait for the CLDR ticket to be
> resolved, and then switch back to NNBSP and we would both match.
>
> The goal is to try harmonize this data across the various
> implementations. There is nothing more frustrating for users
> than to have different display data like this.
>
> Does that make sense?

As I said previously, I will not object.  But I have one suggestion:
as the new ticket has been reported to CLDR let's wait few days
and push our change just before the freeze which will be soon anyway.
Just in case if CLDR responds "OK, NNBSP would be better" within
those few days.  I would like to avoid switching back and forth.

I hope the change is as simple as "git revert", otherwise we may
prepare a patch already and keep it around.

Regards,

Rafal

Re: Locales: Thousands separator

[Mike FABIAN]

Rafal Luzynski <digitalfreak@lingonborough.com> さんはかきました:

> 21.06.2018 16:15 Carlos O'Donell <carlos@redhat.com> wrote:
>> [...]
>> We could switch to NBSP, and just wait for the CLDR ticket to be
>> resolved, and then switch back to NNBSP and we would both match.
>>
>> The goal is to try harmonize this data across the various
>> implementations. There is nothing more frustrating for users
>> than to have different display data like this.
>>
>> Does that make sense?
>
> As I said previously, I will not object.  But I have one suggestion:
> as the new ticket has been reported to CLDR let's wait few days
> and push our change just before the freeze which will be soon anyway.
> Just in case if CLDR responds "OK, NNBSP would be better" within
> those few days.  I would like to avoid switching back and forth.
>
> I hope the change is as simple as "git revert", otherwise we may
> prepare a patch already and keep it around.

It looks like CLDR agrees that NNBSP is better:

https://unicode.org/cldr/trac/ticket/11217#no2

     Status changed from new to accepted

     Need to check that these are parse variants. Typographically the right
     approach. For discussion.

-- 
Mike FABIAN <mfabian@redhat.com>
睡眠不足はいい仕事の敵だ。