The localize call:

vscode/src/vs/workbench/api/common/extHostLogService.ts

Line 21 in ba3978f

const name = initData.remote.isRemote ? localize('remote', "Extension Host (Remote)") : isWorker ? localize('worker', "Extension Host (Worker)") : localize('local', "Extension Host");

The webworker one is weird... because there isn't a concept of env vars so VSCODE_NLS_CONFIG isn't a thing in the web like it is in node and is used to configure the REH AMD Loader:

vscode/src/vs/server/node/extensionHostConnection.ts

Line 46 in ba3978f

VSCODE_NLS_CONFIG: JSON.stringify(nlsConfig, undefined, 0)

I'm not seeing us configure the AMD loader with the language which is why that one isn't working.

vscode/src/vs/base/worker/workerMain.ts

Line 67 in ba3978f

function loadAMDLoader() {

Originally posted by @TylerLeonhardt in #192787 (comment)

After getting the current language in html, pass it to worker when initializing it. Is it OK? AMDLoader in other places needs to pass other attributes such as supported languages, but here only the current language may be enough, because the page or application will be refreshed when switching languages.

That might do the trick... this is specifically talking about Core strings that exist in the webworker that need to be localized... in other words, not strings inside of an extension, for example.