Matt Hiller Reporter
	Description • 18 years ago

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

	Steve England [:stevee]
	Comment 1 • 18 years ago

Related to / dupe of bug 165200?

	Matt Hiller Reporter
	Comment 2 • 18 years ago

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

	Greg K.
	Comment 3 • 17 years ago

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”.)

	Greg K.
	Comment 4 • 17 years ago

(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.)

	Brian Crowder
	Comment 5 • 17 years ago

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

	Brian Crowder
	Comment 6 • 17 years ago

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

	Brian Crowder
	Comment 7 • 17 years ago

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

	Brian Crowder
	Comment 8 • 17 years ago

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.

	Brian Crowder
	Comment 9 • 17 years ago

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

	Matt Hiller Reporter
	Comment 10 • 17 years ago

(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.

	Francesco Lodolo [:flod]
	Comment 12 • 17 years ago

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.

	Greg K.
	Comment 13 • 17 years ago

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.

	Brendan Eich [:brendan]
	Comment 14 • 17 years ago

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

	Marek Stępień [:marcoos, inactive]
	Comment 15 • 17 years ago

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

	Sato
	Comment 17 • 16 years ago

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.

	Olivier
	Comment 18 • 16 years ago

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).

	Brian Crowder
	Comment 19 • 16 years ago

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

	Matt Hiller Reporter
	Comment 20 • 16 years ago

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.

	bslwannabe
	Comment 21 • 16 years ago

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).

	Nicolas Barbulesco
	Comment 23 • 11 years ago

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

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

	Nicolas Barbulesco
	Comment 24 • 11 years ago

(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.

	André Bargull [:anba]
	Comment 25 • 7 years ago

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.

	Stefan Plewako [:stef]
	Comment 26 • 7 years ago

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

	André Bargull [:anba]
	Comment 27 • 7 years ago

(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"?

	Stefan Plewako [:stef]
	Comment 28 • 7 years ago

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

Yes, "en-US"

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 29 • 7 years ago

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

	Stefan Plewako [:stef]
	Comment 30 • 7 years ago

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.

	Stefan Plewako [:stef]
	Comment 31 • 7 years ago

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

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 32 • 7 years ago

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)?

	Stefan Plewako [:stef]
	Comment 33 • 7 years ago

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

	Zibi Braniecki [:zbraniecki][:gandalf]
	Comment 34 • 7 years ago

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