@dbaeumer it is relatively easy to access our global settings from the main side, e.g. see https://github.com/Microsoft/vscode/blob/master/src/vs/workbench/electron-main/windows.ts#L509 as example

The setting still needs to be contributed from a renderer though.

@bpasero the problem is that the code giving me access to the settings is already loaded and may be nls bundles are resolved with the wrong locale. I would need to re-resolve them which is not supported currently. The locale resolving is currently done in JS even before we initialize our loader since the loader loads the nls bundles.

Some comments from #4118

I understand your point but I think for the majority of the users the new behavior is correct. The reasons is:

• either your native language in non English and you configured your OS to your native language. Then you prefer the native language over English and VSCode will honor that with the March release
• your native language is non English but you configured the OS to English. Then VSCode starts in English.

I don't really see why a German would configure the OS to German and want to have VSCode in English. If his English is good enough for VSCode then I guess he would run the OS in English.

We can discuss tomorrow in the standup. Given that fixing this requires additional work/features I moved it to the backlog given the 'minor' value I see.

@egamma lets discuss that tomorrow. I can't think of an easy way to implement that right now.

I would like to port over also my comment :)

Comment 1:

IMHO, there is a case not covered well enough. e.g.:

having Windows locale in English and wanting to run VSCode in Spanish.
or having Windows locale in Spanish and wanting to run VSCode in English.
The only way to do this now is to use a command line argument.

But especially in Windows, it is unusual to launch a UI app from the command line with arguments. E.g: taskbar, windows start button, double clicking a file associated with VSCode, right click open with VSCode.

I suggest some alternative means to define the locale besides the command line argument.

Comment 2:

I think putting on the backlog is a bit too optimistic, since this is a "breaking change".

If I have Windows locale set to German, VS Code always started up in English.

Starting with the March release, VS Code will start in German and it has no way to durably disable this behaviour.

Thank you for adding the option!

@dbaeumer by the way here's a real world case of someone needing this setting: http://stackoverflow.com/questions/36083513/how-to-change-vs-code-locale

not that it's incorrectly translated, but most computer science vocabulary don't make much sense when translated, and when you are used to the English version.

I suggest to make this more prominent under the File > Preferences menu.

@dbaeumer @egamma

Why is there now a locale.json file instead of putting this in the settings file?

@chrisdias the settings store is loaded in too late #4118 (comment)

@Tyriar Understood, but we could load user\settings.json exactly the same way we load user\launch.json, there is no need to use the settings store if we need to get at this value early in the boot sequence. The files sit next to each other on disk, they are both .json files, they can be loaded the same way.

The thing I am pushing for is a consistent user experience for settings. We have Preferences -> User and Workspace Settings already and this is where we put everything settings related. It is easy for people to learn. I understand that the locale need to be global (User level) but we have other settings which are User only but exist in both user and workspace ("updateChannel" and "telemetry" are two examples). It is easy enough to understand that some things are User level and are ignored if found in the Workspace settings.

With us having a separate launch.json it creates more complexity. It is yet another file, it introduces another command in the command palette, it creates confusion because when i open settings I cannot find "locale" as an option (this is what got me started), and to follow our established model we would have to add another menu item under Preferences.

The only argument I can see for not putting the setting in user is that potentially, and I argue this is a only a remote possibility, the user level settings file could be so big that loading it to find the locale value would be a hit to startup performance. The size of a fully loaded settings file is 17k on disk (windows) and I'm guessing the OS could load that pretty fast :).

CC @egamma @dbaeumer

I'll reopen the issue to have the discussion since it is important for @chrisdias.

I like the suggestion from @bpasero to expose this like the other preferences from the preferences menu.

I also want to point out that we do not put all user preferences in the settings file, e.g., themes.

The reason why having a separate file was actually startup performance. It is not only reading the file it is also parsing it. And having a separate file allows for stating that file and only read it if present. If we put this into the settings file then we always have to read that file on startup and then in most cases find out that no value is stored in there.

I add a menu entry when I code it and quickly discussed it even with Ben but then decided against it since I thought it makes a single setting to prominent.

And there are more settings that have their own files: tasks.json, lunch.json, ....

My suggestion: Show it under File > Preferences and instead of opening a file we show a drop down of all supported languages (similar to how we show Themes). Selecting a language just writes to this file in the backend without the user knowing.

@dbaeumer @chrisdias

Summary from the stand-up discussion:

1. Finding the Configure Locale action in the Command Palette when you do not understand the display language doesn't work.
2. Configuring the locale command should have a fixed slot in the UI so that the user can always find it independent of the currently used display language.
3. Users do not know which display languages are available
4. Users do not know what the abbreviations for a particular display language is.

This can be addressed by a command in the UI, that shows the user the list of available locales e.g., in the quick box and the user can select from this list as suggest above #4170 (comment). With this approach it becomes an implementation detail where the locale information is stored. Since we do not modify the user's settings file programmatically, the locale information should not be stored in the .settings file.

Adding the quick box locale UI is not in scope given that we are frozen Adding a menu item as an intermediate step that opens the file is a small improvement, but I'd rather do nothing than making an intermediate solution so popular in the current UI.

@cdias what do you think?

@egamma one additional note: we should still allow to open the file for cases where people work on translations which are not part of the UI yet. But this is considered to be the expert mode.

So it sounds like the plan is to do doing nothing for March, correct? Can we at least provide IntelliSense for locale.json so I know which languages I can pick from and the proper format.

When we do a proper settings/configuration experience we can have nice UI for picking the language.

Can we at least provide IntelliSense for locale.json so I know which languages I can pick from and the proper format.

Suggest to just add fwlink in the comment that points to the doc page with the supported locales:

This is the forward link
http://go.microsoft.com/fwlink/?LinkId=761051

@egamma can you please verify that the forward link shows up.

Since the locale documentation is on the vnext branch I've updated the forward link to point to this location: https://github.com/Microsoft/vscode-docs/blob/vnext/docs/customization/locales.md

Can I have English, please?

Put en-US into the locale.json file open via the command 'Configure Language'.

Put en-US into the locale.json file open via the command 'Configure Language'.

There is one "small" problem with this suggestion: when I have Russian interface, and I press F1 then start to type "Configure Language" - I have no matches in command palette. Direct translation of "Configure Language" to Russian - still nothing.

Do you understand this problem, guys?

Please, provide some way to change language from File -> Preferences. It's just ridiculous to have to google and ask for recipe on stackoverflow.

We are aware of these problems and we are working on improving this in two ways:

• you will be able to always type the English command even if you are in a different UI language. For example you will be able to type 'git pull' or 'configure language' even if you are in Russian interface.
• we are looking into ways to integrate UI Language switching into the Menu.