Node is not using the system's locale

[jmealo]

Calling .toLocaleString() on Number and Date objects behaves differently than Chrome.

This behavior is present in Ubuntu 12.04 and OSX 10.8 using Node v0.8.17.

On Chrome:
1000.toLocaleString();

"1,000"

On Node:
1000.toLocaleString();

"1000"

Additional info:

process.env.lang is set to the the expected value en_US.UTF-8

locale on the terminal returns the following (OSX 10.8):
LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

locale on the terminal returns the following (Ubuntu 12.04):
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

Related bugs: #966

[bnoordhuis]

This is arguably a V8 bug. It ignores locale settings. In fact, all date and number formatting logic is hard-coded.

The reason it works in Chrome and Chromium is that those projects use v8-i18n on top of V8. I don't think that's a direction we want to take. It depends on libicu and that's a massive library. We would have to bundle it and that would increase our already large source tree by another 85 MB and ~500,000 LoC.

[andreioprisan]

Is there a better solution than including the v8-i18n package?

[bnoordhuis]

Not really. Localization is a complex affair (the people who don't think it is are usually native English speakers) so you end up using something like libicu anyway.

[jcollum-hcg]

I think the docs should be fixed, currently they imply that toLocaleString will use locales. This is from the docs:

var number = 3500;
console.log(number.toLocaleString()); // Displays "3,500" in English locale

http://nodemanual.org/latest/js_doc/Number.html#Number.toLocaleString

Unless nodemanual.org isn't the official doc.

[bnoordhuis]

Unless nodemanual.org isn't the official doc.

nodemanual.org isn't the official doc. :-)

[jcollum-hcg]

Dammit. What would you recommend using as the official doc? I've looked around a lot on this and haven't found anything.

[TooTallNate]

The latest official docs can always be found here:
http://nodejs.org/docs/latest/api/

On Tuesday, July 30, 2013, jcollum-hcg wrote:

Dammit. What would you recommend using as the official doc? I've looked
around a lot on this and haven't found anything.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4689#issuecomment-21830342
.

[jcollum-hcg]

http://nodejs.org/docs/latest/api/

That doesn't work: the Number class isn't documented there.

https://www.google.com/#sclient=psy-ab&q=site:nodejs.org+toLocalestring&oq=site:nodejs.org+toLocalestring&gs_l=hp.3...7944.8728.2.9527.5.5.0.0.0.0.63.244.5.5.0....0.0..1c.1.20.psy-ab.eAxKnlsZOA4&pbx=1&bav=on.2,or.r_cp.r_qf.&bvm=bv.49967636%2Cd.cGE%2Cpv.xjs.s.en_US.jOYpRJj4zMA.O&fp=cc03b8a15605e0b2&biw=1116&bih=927

First hit doesn't have toLocaleString and the rest of the hits are just irc logs.

[TooTallNate]

The Number class is part of JavaScript itself, which the NodeJS docs don't re-iterate. You probably want to read up on Mozilla's MDN docs for JavaScript, or perhaps read the ECMAScript 5 reference itself.

[jcollum-hcg]

Right but the MDN docs don't match with V8! MDN says you can pass in a BCP 47 locale string, which works in browsers but doesn't work in Node. I've looked for a V8 API reference but haven't found any that discuss Number::toLocaleString. It's frustrating -- since this is native code I'd rather not have to read C++ to figure out what a valid signature for my function call looks like.

Passing in a BCP 47 locale string clearly doesn't work in node, according to this issue ticket and my tests.

[bnoordhuis]

V8 master supports linking against ICU directly now so that's an option we'll probably offer in the future. I don't think we're going to bundle ICU so you'll have to install that separately and enable it with a ./configure switch.

[jcollum-hcg]

I just worked around it with some regex stuff, since I didn't need full i18n. I just wish I hadn't spent so much time on this issue -- MDN says you can do X but V8 doesn't do X and there's no docs that explain that, just github bug reports. As a developer I'd like to see better docs for V8 if I'm going to continue to use it in a production environment.

[jmealo]

I raised this issue last year and was told that browser support for i18n is
what allows V8 to detect system locale. It was indicated that it was not
technically feasible to integrate i18n support into Node. Can someone
please confirm?

On Wed, Jul 31, 2013 at 1:34 PM, Ben Noordhuis notifications@github.comwrote:

V8 master supports linking against ICU directly now so that's an option
we'll probably offer in the future. I don't think we're going to bundle ICU
so you'll have to install that separately and enable it with a ./configure
switch.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/4689#issuecomment-21880490
.

[bnoordhuis]

Not sure what you want me to confirm but here is a quick recap.

Previously, the only way to get native i18n in V8 was through the external v8-i18 module.

The V8 team recently pulled v8-i18n into V8 core (conceptually if not literally) but it still has a dependency on libicu and that's a library we're unlikely to bundle because of its massive size.

We'll probably add a configure option that lets you link against an external libicu but that's something you'll have to explicitly enable at build time.

tl;dr You can have native i18n but not by default.

Hope that clears things up.