sindresorhus / os-locale Goto Github PK

• https://tools.ietf.org/html/rfc5646
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl#Locale_identification_and_negotiation
• https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/NumberFormat

Is that even possible? If not, are you interested in implementing this?

It can often be the case that users set a LC_TIME value differently than LC_ALL, LC_MESSAGES, or LC_LANG.

webstorm's command line
$ locale
LANG=
LC_COLLATE="C"
LC_CTYPE="zh_CN.UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

error
/Users/echo/project/nodejs/router_admin/node_modules/os-locale/index.js:43
cache = getLocale(/LANG="([^"]*)"/.exec(stdout)[1]);
^
TypeError: Cannot read property '1' of null
at /Users/echo/project/nodejs/router_admin/node_modules/os-locale/index.js:43:51
at ChildProcess.exithandler (child_process.js:742:7)
at ChildProcess.emit (events.js:110:17)
at maybeClose (child_process.js:1015:16)
at Socket. (child_process.js:1183:11)
at Socket.emit (events.js:107:17)
at Pipe.close (net.js:485:12)

For synchronous tools like yargs, it would be awesome to have a synchronous mode for locale lookups.

npm audit yields: https://www.npmjs.com/advisories/1084

Using webpack 5.36.1 results in an error since os-locale 6.0.0

ERROR in node:child_process
Module build failed: UnhandledSchemeError: Reading from "node:child_process" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
    at D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:742:26
    at Hook.eval [as callAsync] (eval at create (D:\projects\tfnative2\jsserver\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Object.processResource (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:739:9)
    at processResource (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:220:11)
    at iteratePitchingLoaders (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:171:10)
    at runLoaders (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:397:2)
    at NormalModule.doBuild (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:729:3)
    at NormalModule.build (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:878:15)
    at D:\projects\tfnative2\jsserver\node_modules\webpack\lib\Compilation.js:1311:12
    at NormalModule.needBuild (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:1143:32)
 @ ./node_modules/os-locale/exec.js 4:0-46 6:27-48 27:8-33
 @ ./node_modules/os-locale/index.js 2:0-41 8:15-19 12:8-16
 @ ./src/config.ts
 @ ./src/index.ts 16:17-36

ERROR in node:util
Module build failed: UnhandledSchemeError: Reading from "node:util" is not handled by plugins (Unhandled scheme).
Webpack supports "data:" and "file:" URIs by default.
You may need an additional plugin to handle "node:" URIs.
    at D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:742:26
    at Hook.eval [as callAsync] (eval at create (D:\projects\tfnative2\jsserver\node_modules\tapable\lib\HookCodeFactory.js:33:10), <anonymous>:6:1)
    at Hook.CALL_ASYNC_DELEGATE [as _callAsync] (D:\projects\tfnative2\jsserver\node_modules\tapable\lib\Hook.js:18:14)
    at Object.processResource (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:739:9)
    at processResource (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:220:11)
    at iteratePitchingLoaders (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:171:10)
    at runLoaders (D:\projects\tfnative2\jsserver\node_modules\loader-runner\lib\LoaderRunner.js:397:2)
    at NormalModule.doBuild (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:729:3)
    at NormalModule.build (D:\projects\tfnative2\jsserver\node_modules\webpack\lib\NormalModule.js:878:15)
    at D:\projects\tfnative2\jsserver\node_modules\webpack\lib\Compilation.js:1311:12
 @ ./node_modules/os-locale/exec.js 3:0-36 6:17-26
 @ ./node_modules/os-locale/index.js 2:0-41 8:15-19 12:8-16
 @ ./src/config.ts
 @ ./src/index.ts 16:17-36

The callback is never invoked when running on Windows XP. It seems the wmic process remains alive indefinitely, so the callback is invoked only if you kill the wmic process manually.

It turns out that running wmic from node works if you use one of the synchronous members of the child_process family. Why wmic won't exit when using one of the asynchronous exec variants is a mystery to me.

Our Windows app that uses os-locale has been flagged as a security risk because it will launch any file named "wmic", regardless of extension, and the file can be anywhere on the PATH, including the app's own directory. It could be a vbs file, for example.

The suggested secure way (if you have to use wmic):

1. Always use the exe extension.
2. Always use the full standard path to wmic.exe.

https://github.com/sindresorhus/os-locale/blob/master/index.js#L7

const defaultLocale = 'en_US';

Could we provide a custom defaultLocale like en?

Motivations:

navigator.languages
// ["en", "zh-CN", "zh", "zh-TW", "ja"]

$ ls 0.18.8-sdk/osx64/nwjs.app/Contents/Resources/ | grep en
> document.icns
en.lproj
en_GB.lproj

I've turned off locale detection in yargs for the time being, due to this error message I'm seeing on node 0.10.x:

Native thread-sleep not available.
This will result in much slower performance, but it will still work.
You should re-install spawn-sync or upgrade to the lastest version of node if possible.
Check /Users/benjamincoe/bcoe/yargs/node_modules/spawn-sync/error.log for more details

Like we discussed in that other thread, I think a configuration option for turning off spawning would be an ideal solution -- this would help address performance issues that @kevinsawicki raised as well.

If the user is just looking for a locale to provide translated messages this module will return a reasonable locale.

But -- I know that's not very common -- the user may want to select a different locale for each locale category. If he does that using POSIX variables (for example, a user using LC_MESSAGES=en_US and LC_MONETARY=en_GB) he could see money information in the wrong format if using os-locale.

Also, the locale resolution based on environment variables and locale stdout is selecting variables in the wrong order (just like yargs is doing).

IMHO, a good strategy is following gettext for POSIX environments.

Hi!

What about releasing a 2.0 that returns a Promise instead of callbacks?
I'll send a PR if you'd accept that 👼

Thanks ⭐

I wanted to contribute, but:

• fork
• clone
• yarn install
• yarn test

Results in an error:

Going through test commands individually, it's the xo binary that throws this.

Does anyone encounter the below issue while using the packag os-locale?

Error [ERR_REQUIRE_ESM]: Must use import to load ES Module: C:\Users\Admin\Desktop\node_modules\os-locale\index.js
require() of ES modules is not supported.
require() of C:\Users\Admin\Desktop\node_modules\os-locale\index.js from C:\Users\Admin\Desktop\xxxx\lib\helper\utils.js is an ES module file as it is a .js file whose nearest parent package.json contains "type": "module" which defines all .js files in that package scope as ES modules.
Instead rename index.js to end in .cjs, change the requiring code to use import(), or remove "type": "module" from C:\Users\Admin\Desktop\node_modules\os-local

locale is not enough, such as zh-HK means two languages zh-Hans-HK and zh-Hant-HK.

macOS shell:

$ defaults read -g AppleLanguages
(
    "zh-Hans-HK",
    "zh-Hant-HK"
)
$ locale
LANG="zh_HK.UTF-8"
LC_COLLATE="zh_HK.UTF-8"
LC_CTYPE="zh_HK.UTF-8"
LC_MESSAGES="zh_HK.UTF-8"

Hi - I'm not sure if this is an issue with your library so sorry if I've made a mistake.

I use the library yargs and it's started regularly throwing in your library through this line which was added as part of 1.2.0 in the change linked below

cf130b6#diff-168726dbe96b3ce427e7fedce31bb0bc

var stdout = execFileSync('wmic', ['os', 'get', 'locale'], {encoding: 'utf8'});

It gives the following error every other build or soError: Command failed: wmic os get locale

Does anything spring to mind, I've not found a whole lot online as to what the problem might be. If you'd be willing I'd be happy to make a pull request to make this call fault tolerant.

Thanks
Neil

It seems that the following command is used under macOS for detecting the locale:

defaults read -globalDomain AppleLocale

But it turns out this returns the value of the "Region" thing here:

Not the actual primary language, so for example I'm getting en_GB even though my primary and only language is en_US.

Hi @sindresorhus

Currently, mem (< 4.0.0 versions) is vulnerable to Denial of Service (DoS) attacks.
Can you release v2.1.1 with mem 4.0.0 ?
There are many packages which depend on v2.

Thank you.

In my project, I need to know the default encoding of OS.

If it is not difficult, would you please add a function that returns default encoding as well?

It seems a NodeJS process issue.
1, execute "locale" in mac terminal:
locale
LANG="zh_CN.UTF-8"
LC_COLLATE="zh_CN.UTF-8"
LC_CTYPE="zh_CN.UTF-8"
LC_MESSAGES="zh_CN.UTF-8"
LC_MONETARY="zh_CN.UTF-8"
LC_NUMERIC="zh_CN.UTF-8"
LC_TIME="zh_CN.UTF-8"
LC_ALL=

2, call locale via process.childProcess.execFileSync
var childProcess = require('child_process');
var execFileSync = childProcess.execFileSync;
var ret = execFileSync('locale', {encoding: 'utf8'});
console.log(ret);

Notice the difference of output:
LANG=
LC_COLLATE="C"
LC_CTYPE="UTF-8"
LC_MESSAGES="C"
LC_MONETARY="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_ALL=

See vercel/hyper#3091

It looks like if people have their region set to one country and the display language to another, os-locale generates a invalid xx_xx pair, not sure if this should be validated in the lib or the app using it.

I upgraded my electron application to the version 2.0.3, and after this, I am getting this error

execa.stdout is not a function when I tried use the os-locale library, before it is working with electron 1.7.8

Thanks for your help, regards

TypeError: osLocale.then is not a function

log:

λ node render.js

  var region = osLocale(locale);
                        ^

ReferenceError: locale is not defined
    at Object.<anonymous> (render.js:6:25)
    at Module._compile (module.js:570:32)
    at Object.Module._extensions..js (module.js:579:10)
    at Module.load (module.js:487:32)
    at tryModuleLoad (module.js:446:12)
    at Function.Module._load (module.js:438:3)
    at Module.runMain (module.js:604:10)
    at run (bootstrap_node.js:393:7)
    at startup (bootstrap_node.js:150:9)
    at bootstrap_node.js:508:3