368838 - javascript Number.toLocaleString() doesn't follow OS locale settings on Mac OS X

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Matt Hiller]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.1) Gecko/20061204

javascript Number.toLocaleString() doesn't follow OS locale settings on Mac OS X. Underlying implementation depends on POSIX locale API being consistent with OS settings, which it is not on OS X.

Reproducible: Always

Steps to Reproduce:
1. In Mac System Preferences, open the International Control. Choose the Formats tab. Select a region that uses , as a decimal point instead of . (for example, Belgium)
2. Launch Firefox
3. type javascript:Number(1.5).toLocaleString() into the address bar
Actual Results:  
1.5 is displayed

Expected Results:  
1,5 should be displayed

The code that actually decides how toLocaleString should work is in js/src/jsnum.c, js_InitRuntimeNumberState. To determine how numbers should be displayed, the code makes a call to localeconv and inspects the locale structure that gets returned.

On OS X 10.4, however, OS locale settings do not get picked up by the POSIX locale machinery; the whole API exists on OS X for legacy purposes only, more or less. If the user sets the LANG environment variable appropriately before running firefox, toLocaleString()'s results will be consistent with that LANG value. Approximately zero OS X users would ever think to try this.

Bug first observed with XULRunner 1.8.0.5, but easily reproducible in FF.

Also, Tools->Page Info displays image sizes as, e.g., 14.45 KB instead of 14,45 KB on an OS X machine set up in this way. Fixing the toLocaleString behavior should fix that problem; see browser/base/content/pageInfo.js

Comment 1

[Steve England [:stevee]]

Related to / dupe of bug 165200?

Comment 2

[Matt Hiller]

Related, yes. Dupe, no. Moving this bug to the same product/component as was used for bug 165200.

Comment 3

[Greg K.]

Confirmed using FF  2.0.0.11 on OS X 10.4.11. I have the Region set to Austria/German in System Preferences/International/Formats and calling toLocaleString on a number such as 1234.56 returns exactly “1234.56” rather than the expected “1.234,56”.

Since FF ignores a lot of OS X system prefs I also tried setting FF’s preferred language to German (Preferences/Advanced/General/Languages) with the same result.

The test also fails the same way in Camino 1.5.4 (which tends to honor most, if not all, system prefs).

FF 2.0.0.11 on Windows passes the test, displaying 1234.56 as “1.234,56” with a German-language system locale.

(As an aside, IE 7 astonishingly assumes all numbers passed through toLocaleString() are prices, returning 1234 as “1.234,00”.)

Comment 4

[Greg K.]

(Note also from my comment 3 that FF on Mac fails to inculde any thousands separator, not just the correct one. FF on Win does include not only _a_ thousands separator, but the correct one.)

Comment 5

[Brian Crowder]

Mats:  Wondering if this is possibly related to either bug 327869 or bug 398485, do you have a moment to look?

Comment 6

[Brian Crowder]

Wait, disregard that.  I added that note to the wrong bug.

Comment 7

[Brian Crowder]

Matt Hiller: How do other apps/libraries deal with this inconsistency on OS X?

Comment 8

[Brian Crowder]

It's worth mentioning that the JS spec (15.7.4.3) permits toLocaleString() to return the same value as toString().

I still think this bug is worth fixing, but I'm not going to make it a high priority for myself.  A patch that uses CFNumberFormatter instead would be worth considering.

Comment 9

[Brian Crowder]

Better might be to use the constants documented here: http://developer.apple.com/documentation/CoreFoundation/Reference/CFNumberFormatterRef/Reference/reference.html#//apple_ref/doc/c_ref/kCFNumberFormatterCurrencyDecimalSeparator

Comment 10

[Matt Hiller]

(In reply to comment #7)
> Matt Hiller: How do other apps/libraries deal with this inconsistency on OS X?
> 

Setting the context a bit more, I do the OS X build of Google AdWords Editor. I don't fully appreciate to what extent web app/jslibrary developers might depend on having a well-behaved toLocaleString.

Comment 12

[Francesco Lodolo [:flod]]

I think that this bug should be blocking 1.9, at least until this functions are used in the UI (see download manager, bug 409832), displaying non localized content.

Comment 13

[Greg K.]

Perhaps there’s a better place to discuss this, but it seems to me that toLocaleString isn’t very practical given how operating systems expose these prefs to users. They usually offer two; one for numbers, and one for currency. Also the number prefs, at least on Windows, add decimal places even when handling round numbers, which isn’t quite what you’d expect, or want.

JS ought to offer toLocaleString and toLocaleCurrencyString, and toLocaleString at least should offer an argument to control whether to keep round numbers round or add decimal places.

Comment 14

[Brendan Eich [:brendan]]

Greg: you are obviously right, and ECMA-262 Edition 3 (from the late 90s) got it wrong. The most productive course, if you are willing to help, is to file a bug at http://bugs.ecmascript.org/ on this. Thanks,

/be

Comment 15

[Marek Stępień [:marcoos, inactive]]

OK, so if this means fixing the ECMA spec first, then implementing it in Gecko, we need to reopen and fix bug 409832 separately.

Comment 17

[Sato]

I'm using Mac OS 10.5.3 (Build:9D34/Intel)/Firefox 3 RC2(Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; ja-JP-mac; rv:1.9) Gecko/2008053008 Firefox/3.0).

In "(new Date()).toLocaleString()" ,A day of the week is garbled.

Example,I input "javascript:alert((new Date()).toLocaleString());" to URL Field, "譌･  6/ 8 20:06:10 2008" is displayed.

In Mac OS 10.4.11(intel)/Firefox 3 RC1, this problem doesn't occur.
This problem occurs only by Leopard.

Comment 18

[Olivier]

I can confirm the behavior reported in the last comment (and this possibly is a different bug that could be fixed independently?).

Looks like an encoding problem (MacRoman vs. Unicode).

Comment 19

[Brian Crowder]

Date.toLocaleString() is a different routine than Number.toLocaleString(), so comments #17 and #18 are for another bug (maybe one that already exists?)

Comment 20

[Matt Hiller]

In reply to comment 4, no thousands separators are shown by default on the Mac 'cause that's how the default "C" POSIX locale works, and that's what the implementation ends up leaning on. Setting LANG to, e.g., da_DK before starting FF will change the behavior of Number.toLocaleString with regard to thousands-separators as well as with regard to the decimal point not just the decimal point.

Comment 21

[bslwannabe]

Re: <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=368838#c17">Comment 17</a> while the Japanese date may be correct in RC1 the British locale information is not honoured in version 3.0.5 on Mac OS X 10.4.11 (Intel) (Version id of Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.0.5) Gecko/2008120121 Firefox/3.0.5).

Comment 23

[Nicolas Barbulesco]

My Firefox 27 on Mavericks gives me 1,5 when I type this in the Web console :

alert(Number(1.5).toLocaleString());

Comment 24

[Nicolas Barbulesco]

(In reply to Nicolas Barbulesco from comment #23)

> My Firefox 27 on Mavericks gives me 1,5 when I type this in the Web console :
> 
> alert(Number(1.5).toLocaleString());

And now my Firefox 27.0.1 gives me 1.5.

There must be some kind of parameter at play, which I don't understand.

Comment 25

[André Bargull [:anba]]

I expect this issue has been fixed when we moved to using ICU (bug 853301). Please re-open if this is still an issue on Mac OS.

Comment 26

[Stefan Plewako [:stef]]

`Number(1.5).toLocaleString()` returns "1.5" for me.

Comment 27

[André Bargull [:anba]]

(In reply to Stefan Plewako [:stef] from comment #26)
> `Number(1.5).toLocaleString()` returns "1.5" for me.

Thanks for checking, much appreciated! So I guess `new Intl.NumberFormat().resolvedOptions().locale` returns "en-US" for you instead of the expected "pl-PL"?

Comment 28

[Stefan Plewako [:stef]]

(In reply to André Bargull from comment #27)

Yes, "en-US"

Comment 29

[Zibi Braniecki [:zbraniecki][:gandalf]]

It should use the Firefox locale, not OS locale. So if you're in en-US Firefox, it should be 'en-US' by default.

Comment 30

[Stefan Plewako [:stef]]

I'm using latest nightly pl under OS X 10.11.6 with language/region also set into Polish/Poland. I was wondering if the way I launch it (automator) makes difference but from what you write it shouldn't matter.

Comment 31

[Stefan Plewako [:stef]]

Just tested this and it seems to depend on the way I launch application.

Comment 32

[Zibi Braniecki [:zbraniecki][:gandalf]]

Can someone test it against the latest Nightly?

If it's still not fixed, can you go to about:support and paste here the bottom table (L10n&Intl)?

Comment 33

[Stefan Plewako [:stef]]

It looks fixed in latest Nightly on 10.11.6 but I don't have latest macOS around to test.

Comment 34

[Zibi Braniecki [:zbraniecki][:gandalf]]

I'm going to make it as WFM, please reopen if needed.