vscode-csharp
vscode-csharp copied to clipboard
dotnet
IntelliSense strings are localized
Yesterday my VS Code updated Omnisharp, since then my intellisense and debugging messages are being outputted in another language from English, there doesn't seem to be any way to configure or change that behaviour.
Can you give us some examples of intellisense strings?
I know the debugger hasn't yet done the work to ship any localized strings. So if you are getting localized debugger strings they must be from VS Code itself. I am not sure if there are any parts of the language service that have localization yet.
You were right, I could fix the intellisense, however I still get this:
With 1.32.3-beta.9:
Meanwhile with 1.32.4 or 1.32.5:
@Spikent We need more info--what OS are you on? If you're on Windows, what is your language is your system set to use? This looks like a Unity project--what language is Unity configured to use?
@rchande I'm running Windows 10 Pro, and it's locale is set to Spanish, which I'm guessing it's what Omnisharp is picking up on recent updates to set its locale to...
The Project is a Godot project, it's running on c#.
This is essentially a feature request for us to set the locale of OmniSharp based on the VS Code language configuration.
@Spikent Thank you for the feature request. What's happening here is that one of OmniSharp's dependencies recently implemented localization for error messages, meaning that they will now be printed in your system language instead of English. To work around this (and get English error messages), you can delete the new localization files:
Open your "OmniSharp" log and find the path to OmniSharp from the beginning of the log, eg:
OmniSharp server started.
Path: C:\Users\rchande\.vscode-insiders\extensions\ms-vscode.csharp-1.16.1\.omnisharp\1.32.5\OmniSharp.exe
PID: 144684
Navigate to the directory eg C:\Users\rchande\.vscode-insiders\extensions\ms-vscode.csharp-1.16.1\.omnisharp\1.32.5, and enter the subfolder that corresponds to your system language. In @Spikent's case, the folder would be "es" because the system language is Spanish. Remove all the DLLs whose name starts with Microsoft.CodeAnalysis.
This should result in English error messages.
@rchande yes, i renamed my localized folder, this fixes intellisense, thank you!
I fixed it in a similar way as you proposed, it worked non the least, I think there should be a option to allow users to run based on VS code locale or the system one, since some people might actually find this handy!
Thanks for fix, should help anyone that runs into the same situation as us.
I have a opposite requirement, my locale is Chinese, but I want to set IntelliSense to English, I set "Configure Display Language" to "en"
it works here:
but it does not work on IntelliSense
@chinaq you can follow the work around that @rchande gave above for now.
Same problem for me on VSCode 1.30.1: Im getting error and warning hints on spanish, despite having VSCode locale to "en_US". Cant find any option to change this behavior.
Any news on this? (Workaround did worked btw, just asking for news on definitive solution).
I believe that for most of the developers, the fact of having error messages in one language - English - is really a big benefit.
Please be aware that the amount of information you can google with Polish, Chech, or other similar language is minimal. Amount of information in English is huge. Translating error messages or other related information to my mother language makes my work much much harder.
Please do not change my development language to anything different then English by default.
In VS, there is an Option-International Settings. By default, both the UI and intellisense info language are the same as Windows language settings. If it is set to English, both of them will be set to English.
For myself, while I agree English is the basic skill for programmers, I would still like to have a standalone setting to determine the language of intellisense info. But it's also OK totally corresponding to VSC's UI language.
I also found a DOTNET_CLI_UI_LANGUAGE env, but it only affects terminal panel(and external terminal).
My Windows 10 is in pt-BR and I also have this problem.
Navigate to the directory eg
C:\Users\rchande\.vscode-insiders\extensions\ms-vscode.csharp-1.16.1\.omnisharp\1.32.5, and enter the subfolder that corresponds to your system language. In @Spikent's case, the folder would be "es" because the system language is Spanish. Remove all the DLLs whose name starts withMicrosoft.CodeAnalysis.This should result in English error messages.
Yes, this workaround worked, but it would be great to have a user friendly configuration for it. Consider it on the next version. :D
Thank you.
I have the same problem on mac os Mojave (10.14.3) with dotnet 2.1.504 installed.
The omnisharp server prints all messages in spanish, although I have english as locale both for the terminal and vscode. Unfortunately the workaround is not working, as on mac the Microsoft.CodeAnalysis dlls are not located on the omnisharp installation folder.
Changing the language with no warning and without giving a way to put it back is quite annoying. For a workaround in mac, you can change the system language to english, but this solution is cumbersome
I have the same problem Terminal and IntelliSense https://i.imgur.com/GoxqoRx.png
Almost one year later, this bug (yes, it's a bug as a) OmniSharp ignores VSC's language setting and b) has no option for setting its own language either) still is unresolved.
If one might outline to some extend how to fix that (besides the mentioned awesome workaround by @rchande above), I'd love to implement it.
@Eagle3386 OmniSharp is just using the users's language setting. To alter this you would need to change the C# extension (https://github.com/OmniSharp/omnisharp-vscode) to read the VS Code setting and pass it to the server (https://github.com/OmniSharp/omnisharp-roslyn) which would also have to be changed to respect that configuration.
Alright, I'll try and see if I can handle that. Wish me luck, cause up to now, I've only fixed MS docs.. 🤣
I've managed to add an option, extend unit tests without much work and also retrieve VSCode's current display language (stored in vscode.env.language).
However, I seem unable to find docs about the needed variable name for dotnet (OmniSharpServer -> server.ts, line 304, seems to enable direct "pass-through" for dotnet's settings).
Any help would be greatly appreciated! 👍
Update: Found it while adding "terminal.integrated.env.windows": { "DOTNET_CLI_UI_LANGUAGE": "en" }, (or en-us) to my user/workspace settings.json file to fix terminal output, too.
Maybe setting environment variable prior to to launching omnisharp-roslyn / dotnet via child thread already solves the issue.. 🤔
Update: Found it while adding
"terminal.integrated.env.windows": { "DOTNET_CLI_UI_LANGUAGE": "en" },(oren-us) to my user/workspacesettings.jsonfile to fix terminal output, too. Maybe setting environment variable prior to to launching omnisharp-roslyn / dotnet via child thread already solves the issue.. 🤔
I had found this on the above comment. It doesn't work. You can try by setting it in Windows' environment variable.
I had found this on the above comment. It doesn't work. You can try by setting it in Windows' environment variable.
For the (external) terminal panel, it definitely works.
Regarding OS-roslyn, it clearly can't work up to now as there's no code for reading the environment variable and then passing it into the child thread's environment and/or launch arguments.. 😉
Any news on this? Is there a better solution than the workaround yet available?
Update: Found it while adding
"terminal.integrated.env.windows": { "DOTNET_CLI_UI_LANGUAGE": "en" },(oren-us) to my user/workspacesettings.jsonfile to fix terminal output, too. Maybe setting environment variable prior to to launching omnisharp-roslyn / dotnet via child thread already solves the issue.. 🤔
Yes, the easiest way 🙌
