Bug 218139 – Intl.NumberFormat formats ar-AE numbers differently from other browsers

• Status: RESOLVED
• Resolution: MOVED
• Component: JavaScriptCore

[Rob Snow]

What steps will reproduce the problem?
(1) Open console
(2) Run `new Intl.NumberFormat("ar-AE", {useGrouping: false}).format(9876543210)`

What is the expected result?
"٩٨٧٦٥٤٣٢١٠"

What happens instead?
"9876543210"

See https://github.com/unicode-org/cldr/blob/master/common/main/ar_AE.xml#L42

[Alexey Proskuryakov]

This is an intentional choice in Apple's ICU (for Apple employees, see rdar://problem/45142422&21778421).

Rob, are you reporting this as simply a mismatch with CLDR, or does this cause issues?

[Rob Snow]

Can you explain more of why this is an intentional choice? (for us non-Apple folk)
We are relying on CLDR to handle number formatting and it's appearing differently between the browsers. This is problematic because I need to parse numbers as well, for which I also rely on CLDR because the Intl object doesn't have a corresponding number parser. I'd prefer to not have Safari specific code to override this. It certainly causes a loss of faith as well because I don't know how many more of these intentional differences exist. It also means it's harder for me to write unit tests for because Node uses CLDR as well.

[Yusuke Suzuki]

Anyway, Intl feature is not ensuring the underlying data, and it depends on the implementation.
Please report the feedback against Apple radar since this is the intension in AppleICU, not WebKit ;)

[Radar WebKit Bug Importer]

<rdar://problem/80365345>

[Yusuke Suzuki]

It is now upstreamed to CLDR :)
https://github.com/unicode-org/cldr/commit/c601fc4fd1321f6af4a5f9ae67f4f198305e5c63

[Myles C. Maxfield]

is "WONTFIX" really the right resolution? If the bug report is "Intl.NumberFormat formats ar-AE numbers differently from other browsers" then a legit solution is "make the other browsers match WebKit."

Seems like MOVED would be a better resolution.

[Yusuke Suzuki]

Sounds good. Changed it to MOVED.