ECMA-402 support in Node.js should be reliable now, as it's building
with full-icu by default since Node.js 13. So I made it the first
choice.
Actually, I'm not even sure if the remaining variables are still useful.
But if they are used, here are my modifications:
- As for POSIX environment variables, I chose `LC_MESSAGES` over
`LC_CTYPE`, as it better reflects the purpose of the usage (we are using
the detection result to show prompt messages).
- I removed `LANGSPEC` because I can't find any documentation of it except
for one single mention in Wikipedia. I can't find any real usage of it
on my Windows machine.
- As we no longer use `LC_CTYPE`, it seems that `C` is no longer a
possible value for `shellLocale`, so I removed the fallback check logic.
If no more bug reports of Windows users are received in the coming
months, I think we can remove the TODO comment entirely.
function getLocale() {
const shellLocale =
- process.env.LC_ALL ||
- process.env.LANG || // Unix maybe
- process.env.LC_CTYPE || // C libraries maybe
- process.env.LANGSPEC || // Windows maybe
- Intl.DateTimeFormat().resolvedOptions().locale || // Node.js - Internationalization support
- 'en-US'
+ Intl.DateTimeFormat().resolvedOptions().locale || // Built-in ECMA-402 support
+ process.env.LC_ALL || // POSIX locale environment variables
+ process.env.LC_MESSAGES ||
+ process.env.LANG ||
+ // TODO: Windows support if needed, could consider https://www.npmjs.com/package/os-locale
+ 'en-US' // Default fallback
const locale = shellLocale.split('.')[0].replace('_', '-')
- // locale might be 'C' or something else
- return locale.length < 5 ? 'en-US' : locale
+ return locale
}
export default function getLanguage() {