number.toLocaleString() no longer formatting properly on FreeBSD 12.2
Categories
(Core :: JavaScript: Internationalization API, defect)
Tracking
()
People
(Reporter: samuel233, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:85.0) Gecko/20100101 Firefox/85.0
Steps to reproduce:
- Open a web page using number.toLocaleString(),
- Or alternatively use the developer console, create a local variable, and call number.toLocaleString() on it
Actual results:
Since I upgraded to Firefox 85, calling number.toLocaleString() without parameters no longer returns a formatted string, however passing the culture as a parameter, with for example: myNumberVariable.toLocaleString("en-US") formats the string properly.
The property navigator.language properly returns "en-US".
Expected results:
The string should be formatted properly
|
||
Updated•3 years ago
|
|
||
Comment 1•3 years ago
|
||
What is the return value when evaluating new Intl.NumberFormat().resolvedOptions().locale? It should return your default locale.
(In reply to André Bargull [:anba] from comment #1)
What is the return value when evaluating
new Intl.NumberFormat().resolvedOptions().locale? It should return your default locale.
The return value is en-US-posix
|
||
Comment 3•3 years ago
|
||
Ah, so it's the same question as bug 1685075.
Indeed thanks! I didn't find this ticket, I used the wrong keyword I guess. One new piece of info I may add however is that, while the ticket you linked mentions that only Firefox 86 is impacted, I am running Firefox 85 and I am impacted (this problem appeared as soon as I upgraded to 85).
This means that this issue is currently breaking the formatting of web pages for users (and in my case, toLocaleString is used pretty much everywhere, especially on checkout/purchase pages, so this is quite impacting and I may not be the only one concerned).
|
|
||
Comment 5•3 years ago
|
||
This means that this issue is currently breaking the formatting of web pages for users (and in my case, toLocaleString is used pretty much everywhere, especially on checkout/purchase pages, so this is quite impacting and I may not be the only one concerned).
The problem is that what you describe as "broken" formatting is the formatting as expected by the JavaScript specification.
We need to figure out how it should be fixed in the spec :)
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #5)
This means that this issue is currently breaking the formatting of web pages for users (and in my case, toLocaleString is used pretty much everywhere, especially on checkout/purchase pages, so this is quite impacting and I may not be the only one concerned).
The problem is that what you describe as "broken" formatting is the formatting as expected by the JavaScript specification.
We need to figure out how it should be fixed in the spec :)
Ah I see that makes sense. I guess what's really annoying is the change of behavior then: the browser has been behaving in a certain way, and now the behavior changes in a way disrupting existing applications. Updating all applications sounds impratical, and even so the way to get the hold behavior back is not clear.
One the one hand, maybe navigator.language will start returning en-US-posix too next time, but, also, having to pass a culture explicitly every time toLocaleString() is called is impractical and would require a thorough refactoring of all my web applications (I am bringing this is up because I am likely not alone). While the right behavior is sorted, I would love to have some hints on a viable way to get back to business with as little friction as possible. But I truly hope the old behavior will be brought back once the spec is sorted (but this sounds like a long process).
|
|
||
Comment 7•3 years ago
|
||
While the right behavior is sorted, I would love to have some hints on a viable way to get back to business with as little friction as possible. But I truly hope the old behavior will be brought back once the spec is sorted (but this sounds like a long process).
The simplest way would be to adjust your locale to not be en-US-posix or report to ICU that the way they handle en-US-posix is wrong.
I completely understand how it feels frustrating! I'm sorry that a fix that we implemented to respect the locale and pass it appropriately to the library designed to handle, is causing a trouble.
I hope we'll have a design decision soon (I poked the person assigned to it in the relevant issue) and we'll be able to make an informed decision on how to fix your experience!
|
||
Comment 8•3 years ago
|
||
(In reply to Zibi Braniecki [:zbraniecki][:gandalf] from comment #7)
I hope we'll have a design decision soon …
Any design decision yet?
|
|
||
Comment 9•3 years ago
|
||
Any design decision yet?
Still deciding on the Unicode level - https://unicode-org.atlassian.net/browse/CLDR-14487
Current proposal is to canonicalize to en-QP
|
|
||
Comment 10•3 years ago
|
||
Bug 1685075 removed "en-US-posix" from the ICU data file, so when the user default locale is "en-US-posix", we will now fallback to the parent locale "en-US".
Description
•