"Intl.DateTimeFormat().resolvedOptions().locale" returns different values in extension host to VS Code process

[DanTup]

I'm using MacBook with its system language set to en-GB. I launched VS Code (from the dock, not the terminal) and if I run:

Intl.DateTimeFormat().resolvedOptions().locale

in the Chrome dev tools console, I see this:

However, in an extension's activate function if I do this:

console.log(Intl.DateTimeFormat().resolvedOptions().locale);

Then I see this:

I need to get the system language in order to set the LANG env variable for spawned processes because CocoaPods crashes if LANG is not set to something-UTF-8, and there's no way to set it without a language part so I need to get at the system language.

[alexdima]

I don't think we have any code to reset/remove things. @deepak1556 Do you have any ideas? (the extension host is using ELECTRON_RUN_AS_NODE)

[DanTup]

FWIW we've worked around this in Flutter. It still seems weird these don't line up and it might be useful for the extension host to have access to it, but it's not pressing for me anymore. Thanks!

[deepak1556]

I can confirm this issue,

@alexandrudima here are my observations.

1. Renderer process prints the proper locale
2. Extension host reports incorrect locale
3. Running the Code executable from command line with export ELECTRON_RUN_AS_NODE=1 set code -e 'console.log(Intl.DateTimeFormat().resolvedOptions().locale)' prints the correct locale.

To make things more concrete, v8 and icu are shared between node and electron so behavior being different between these two processes are highly unlikely unless we are intervening.

[deepak1556]

Okay I have narrowed down the issue, it seems to be a problem with child_process module that is messing with the locale. Tried the following sample

const { spawn } = require('child_process');
const locale = spawn("/Users/demohan/Downloads/electron-v6.1.5-darwin-x64/Electron.app/Contents/MacOS/Electron", ['-e', 'console.log(Intl.DateTimeFormat().resolvedOptions().locale)'], {env: {
	'ELECTRON_RUN_AS_NODE': 1
}});

locale.stdout.on('data', (data : any) => {
  console.log(`stdout: ${data}`);
});

locale.stderr.on('data', (data : any) => {
  console.error(`stderr: ${data}`);
});

prints en-US while running on the command line prints the proper system locale used at the moment, in my case de

[rzhao271]

Confirmed the issue still occurs on the latest Insiders on Big Sur.

[rzhao271]

I copied the code from #85675 (comment) to a file main.js (with a different Electron spawn path) and did the following:

1. I added a line console.log(Intl.DateTimeFormat().resolvedOptions().locale) at the end.
2. In the terminal, I ran export LANG='fr_CA.UTF-8'
3. 🐛 node main.js results in fr-CA as the locale, but en-US as the spawned locale.
4. I changed the spawn call to spawn node directly instead.
5. ✅ node main.js results in both locales to be fr-CA.

Keeping the Electron label on this issue.

[rzhao271]

Electron actually reports the locale properly if one changes the env parameter above to the following:

{
    ...process.env,
    'ELECTRON_RUN_AS_NODE': 1
}

Even if we were to spawn just node, I noticed that providing env: {} for the options causes the locale mismatch, too, so the first issue is that the problem isn't in Electron, but has to do with whether we are explicitly passing in process.env or not.

A second issue is the user must set the LANG environment variable in order for process.env to pick up the correct locale. I set my macOS display language to French, and node still displayed en-US as the locale until I explicitly changed the LANG environment variable.

For the first issue, we already use process.env at

vscode/src/vs/workbench/services/extensions/electron-browser/localProcessExtensionHost.ts

Line 215 in 724181f

const env = objects.mixin(processEnv, {

Therefore, we aren't forgetting to add process.env.LANG, but rather, process.env.LANG just isn't there by the time that code runs. I confirmed that explicitly adding LANG as an env variable in the launch config to run a custom extension containing the console log line from #85675 (comment) also fixes the issue.

[rzhao271]

So I first thought the issue was as-designed, because my minimal repro was a bit too minimal, but it's actually a more generic upstream issue.
When spawning processes, the child process somehow loses the locale information.

Minimal repro:

main.js

const { app, BrowserWindow } = require('electron');
const cp = require('child_process');

// If we ask for the locale before the app is ready, we actually get en-US here, too.
app.whenReady().then(() => {
    console.log(Intl.DateTimeFormat().resolvedOptions().locale);
    const proc = cp.fork(__dirname + '/child.js');
    proc.on('exit', () => app.quit());
})

child.js

console.log(Intl.DateTimeFormat().resolvedOptions().locale);

Output on macOS with the language set to Spanish (Latin America):

es-MX
en-US

[rzhao271]

In the past week, I learned that

• If one fetches the locale too early in the main process, before the app is ready, then the incorrect locale is returned
• The entry point for running electron as node differs from the entry point for electron GUI apps
• The former entry point doesn't call l10n_util::OverrideLocaleWithCocoaLocale, whereas the latter one does. That function, specific to macOS, allows one to fetch the correct locale in the main process after the app is ready
• When running electron as node, we want the behaviour to be similar to running node itself, so patching electron as node to override the locale might not be the best idea (hence the closed upstream PR)

My plan now is to fetch the locale before spawning the extension host, and pass the locale in as an environment variable. I'll also merge it in next iteration to get more testing.

[rzhao271]

Here's the current situation:

1. The original poster of this issue has already found a workaround (Set the LANG when invoking cocoapods flutter/flutter#45710)
2. I already tried passing in Intl.DateTimeFormat().resolvedOptions().locale as the locale to the extension host, but we end up with locales such as fr that do not correspond to anything available on the OS, causing a regression in several extensions (spawn comes with a broken locale and $LANG #142857).
3. Non-web extensions can instead use https://www.npmjs.com/package/os-locale to detect the OS locale. If we use this module ourselves, then the extension host becomes slower to spawn in general, and in the worst case, we might break some extensions again.

Therefore, I'll mark this issue as a wontfix for now.