Extension does not respect `js/ts.locale`

[DanielRosenwasser]

If you set js/ts.locale, our extension will not respect it and will continue to display error messages in English. This is because we (at least) don't send locale over on server initialization.

We should have at least the same parity as the existing extension. Things to test out:

• Different sources for locale options (js/ts.locale, typescript.locale, global editor display language)
• Locale changes on the fly with no restart (may not be supported, or we force a restart)
• Locale changes take place after a window reload/manual restart if necessary

[jakebailey]

The LSP client does this automatically; I assume the old server has this as it was the only way to do it. Does anyone actually set this? (Will have to make sure undefined works at least)

[DanielRosenwasser]

You're right - this just automatically takes effect if someone uses "Configure Display Language".

We should see what feedback is like here - I don't know if anyone would actually want to override this.

[DanielRosenwasser]

We'll reopen if people provide feedback.

[chikujoyayabo]

Hello, I'd like to provide some feedback on why overriding the locale is actually very necessary.

For Chinese developers, keeping the global editor language in Simplified Chinese (zh-cn) is very common. However, the Simplified Chinese translations for TypeScript diagnostic and error messages are often quite poor and difficult to understand.

Reading the original English (en) errors is immensely more helpful for grasping the actual issue. More importantly, English error messages are essential when searching for solutions on Google, StackOverflow, or GitHub issues.

Having the ability to use js/ts.locale to decouple the TS server language from the global VS Code display language is a very practical feature for us. I really hope you can reconsider bringing this parity back to the new extension. Thank you for all your hard work on this new extension!