Passing undefined for the locale in the Intl.NumberFormatter constructor uses the system locale

• Component: JavaScriptCore
• Status: RESOLVED MOVED

[Myles C. Maxfield]

1. This doesn't match Chrome (but does match Firefox)
2. This causes bugs on some sites which may receive numerals they weren't expecting (See the prices in https://www.westelm.com/search/results.html?words=floor%20lamp with your system set to Arabic)
3. There are fingerprinting concerns

[Myles C. Maxfield]

Created attachment 450860 [details]
Example

Open the example in Chrome and WebKit with your system set to Arabic.

[Radar WebKit Bug Importer]

<rdar://problem/88471306>

[Yusuke Suzuki]

OK, this is because upstream CLDR has two options for numbering-system in ar locale.

1. arab
2. latn

By default, it is pointing "arab". But it looks like there is an option "latn".
And according to CLDR issue (https://unicode-org.atlassian.net/browse/CLDR-10825)

> And add: <defaultNumberingSystem alt=”latndigi”>latn</…> → Google (and other companies like Netflix) which want to default non-country-specific Arabic to ASCII can use this...we can then test it out, see how it works, and based on that experience see if we should switch default and alt
> Stock ICU uses “standard” variant for ar.xml (Arab); Google etc will filter the data so that ar.xml gets <defaultNumberingSystem>Latn</…>

So, Stock ICU (& current Apple ICU) uses arab. Google's fork is using latn.

[Myles C. Maxfield]

Okay, because this bug is about Apple's internal implementation of ICU, let's move this to radar and continue there. Marking as RESOLVED MOVED.