msbuild
msbuild copied to clipboard
dotnet
MSBuild should respect upstream tool language requests
Different upstream tools have different language configuration requirements:
- dotnet CLI sets
DOTNET_CLI_UI_LANGUAGEandVSLANG(https://github.com/Microsoft/msbuild/issues/1596#issuecomment-409362785 https://github.com/dotnet/cli/issues/9722#issuecomment-409358296) - Visual Studio has a fallback mechanism guideline. In order:
VSLANGenvironmnent variable/lcidcommand line switch- call
GetConsoleFallbackUICulture(we only do this currently)
Related info: https://github.com/dotnet/cli/issues/4988#issuecomment-266836559
VSLANG is sufficient for CLI and VS since we set that when the language is overridden by means other than VSLANG.
Is there a workaround while this is still in development? I've tried:
set DOTNET_CLI_UI_LANGUAGE=en
and also:
set VSLANG=1033
to try to get the msbuild output to switch to English when using the dotnet build command, but neither works.
It might be interesting for msbuild to do what CLI does and re-export other things like PreferredUILanguage. This would give the same compiler localization as dotnet build if you configure an env var.
The BuildParameters class has culture and uiculture fields.
I don’t see the ability to set these parameters through the command line parameters (dotnet build | dotnet pack).
In my case, I use the CI / CD service (gocd), artifact files has invalid the wrong encoding, it is not clear how to set the encoding.
This would be incredibly useful when reporting problems; I do use non-English UI language, but it'd be very useful if the output language could be specified by environment variable or something because others do not understand it.
I'm not exactly sure if this is a MSBuild part or somewhere else, but for example, when I type dotnet new -i Microsoft.PowerShell.Standard.Module.Template, there's a first few messages that are printed in local language (in my case, Korean) saying "determining projects to restore". I've tried setting chcp 437, $env:DOTNET_CLI_UI_LANGUAGE = "en-us" and $env:VSLANG=1033 but none of them seem to work.
@Gnbrkm41 I've filed https://github.com/dotnet/sdk/issues/12747 on your behalf. Since it's dotnet.exe it should probably go there.
For now, chcp 437 from the command line should work for MSBuild.exe.
Deleting C:\Program Files\dotnet\sdk\{sdk-version}\{locale} folder can also be used as a workaround.
It has been over 5 years since the issue opened. Is it resolved? I still cannot change the MSBuild locale without changing OS locale. Tried chcp 437, $env:DOTNET_CLI_UI_LANGUAGE = "en-US" and $env:VSLANG="1033".
I think we can solve this issue by geting UILanguageOverride into MSBuild to support overriding its output language:
https://github.com/dotnet/sdk/blob/49d9b4148c4f65fd3f691186a4533375c3a83c97/src/Cli/dotnet/UILanguageOverride.cs#L9
This is so frustrating. I tried setting DOTNET_CLI_UI_LANGUAGE=en, killed all MSBuild processes, and I'm still getting compile errors in my system language, which is completely useless because every error on Google is in English.
I also tried deleting every cs folder I found among the many MSBuild folders I have from various .NET versions, but apparently that was too much and MSBuild is now crashing trying to load localized resource DLLs.
Can't there be a simple way to just stop localizing output? I'm sure there are a few people who find this useful so it doesn't have to be the default, but I think for the majority of non-American programmers, this is really not helpful at all.
Agree. At least you can search few results with the localized message in StackOverflow ;-(
@hcoona I will add that you can usually search for the error code and copy the actual English error from Microsoft's documentation, which sounds like it would not be a lot of extra steps, but in reality it goes more like this:
- Search the error code on Google.
- Visit a Microsoft documentation page for the error.
- Be automatically redirected to a localized version of the documentation. I'm not sure about compiler errors specifically, but most times these "localized" documentation pages are actually machine-translated, which means there are many grammatical errors and mistranslations which actively harm the understandability of your documentation for foreigners.
- Manually switch the website language to English.
- Finally you can copy/paste the actual error message into Google.
I'm sorry, but this whole thing is a terrible user experience.
I agree the UX is quite poor. I have been working to improve the UX in the .NET SDK/CLI, hoping to give it a try and migrate that same code here. Once that's been approved there.
@chylex My configuration:
- Windows 11 + VS Code 1.74.3
- .NET 7.0.102
- I've set environment variable for user in system settings DOTNET_CLI_UI_LANGUAGE=en
- For build I execute "dotnet build"
- My system language is Russian
Output:
Executing task: C:\Program Files\dotnet\dotnet.exe build D:\Work\BadBroker/BadBroker/BadBroker.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary
MSBuild version 17.4.1+9a89d02ff for .NET Determining projects to restore... All projects are up-to-date for restore. D:\Work\BadBroker\BadBroker\Program.cs(25,5): error CS1061: 'WebApplication' does not contain a definition for 'Ru nnn' and no accessible extension method 'Runnn' accepting a first argument of type 'WebApplication' could be found (are you missing a using directive or an assembly reference?) [D:\Work\BadBroker\BadBroker\BadBroker.csproj]
- The terminal process "C:\Program Files\dotnet\dotnet.exe 'build', 'D:\Work\BadBroker/BadBroker/BadBroker.csproj', '/property:GenerateFullPaths=true', '/consoleloggerparameters:NoSummary'" terminated with exit code: 1.
- Terminal will be reused by tasks, press any key to close it.
As you can see there is only English output.
If I delete DOTNET_CLI_UI_LANGUAGE environment variable then output looks like:
Executing task: C:\Program Files\dotnet\dotnet.exe build D:\Work\BadBroker/BadBroker/BadBroker.csproj /property:GenerateFullPaths=true /consoleloggerparameters:NoSummary
MSBuild version 17.4.1+9a89d02ff for .NET Определение проектов для восстановления... Все проекты обновлены для восстановления. D:\Work\BadBroker\BadBroker\Program.cs(25,5): error CS1061: "WebApplication" не содержит определения "Runnn", и не удалось найти доступный метод расширения "Runnn", принимающий тип "WebApplication" в качестве первого аргумента ( возможно, пропущена директива using или ссылка на сборку). [D:\Work\BadBroker\BadBroker\BadBroker.csproj]
- The terminal process "C:\Program Files\dotnet\dotnet.exe 'build', 'D:\Work\BadBroker/BadBroker/BadBroker.csproj', '/property:GenerateFullPaths=true', '/consoleloggerparameters:NoSummary'" terminated with exit code: 1.
- Terminal will be reused by tasks, press any key to close it.
Note: This only work for msbuild using dotnet build. Calling msbuild directly does not honor the language.
Not working for me in .NET 8... I have the DOTNET_CLI_UI_LANGUAGE=en environment variable set on my whole user, but compile errors are still in Czech...
I ended up going into C:\Program Files\dotnet\sdk\8.0.100, deleting every single folder named cs, then restoring some of them that were in analyzers folders because it can't just fallback to english for some reason, but at least the compile errors are finally in English.
Strangely, this only made MSBuild output, which was previously also localized, fallback to English, but the actual (I assume, dotnet) error message is still in Czech.
I've also noticed that the DOTNET_CLI_UI_LANGUAGE=en only works when I use dotnet build in CL directly. If I build the project in Rider, theoutput is still in system's language, despite Rider detecting the env variable in Run Configuration and JetBrains stating "build console output in Rider returns the same content as of running dotnet build manually".
I'm a bit lost here and quite frustrated. Why would anyone want development tools to be localized?
Not working for me in .NET 8... I have the
DOTNET_CLI_UI_LANGUAGE=enenvironment variable set on my whole user, but compile errors are still in Czech...I ended up going into
C:\Program Files\dotnet\sdk\8.0.100, deleting every single folder namedcs, then restoring some of them that were inanalyzersfolders because it can't just fallback to english for some reason, but at least the compile errors are finally in English.
Not working for me in .NET 8... I have the
DOTNET_CLI_UI_LANGUAGE=enenvironment variable set on my whole user, but compile errors are still in Czech...
It looks like MSBuild's messages are in English but the C# compiler's are in Czech. @nagilson, does DOTNET_CLI_UI_LANGUAGE not imply that the CLI sets the variables that Roslyn checks for?
I ended up going into
C:\Program Files\dotnet\sdk\8.0.100, deleting every single folder namedcs, then restoring some of them that were inanalyzersfolders because it can't just fallback to english for some reason, but at least the compile errors are finally in English.
To make things extra confusing, some of those cs mean C# and some mean Czech.
Why would anyone want development tools to be localized?
Opinions on this vary widely, by individual dev and by culture--as I understand it many Europeans are on the "just give us English" side and many East Asian folks are strongly on "if it's in English it's useless, give me a translation". So we have to try to find compromises.
I've also noticed that the
DOTNET_CLI_UI_LANGUAGE=enonly works when I usedotnet buildin CL directly. If I build the project in Rider, theoutput is still in system's language, despite Rider detecting the env variable in Run Configuration and JetBrains stating "build console output in Rider returns the same content as of running dotnet build manually".
You'll have to take this up with JetBrains, that sounds like a Rider bug (or doc bug) to me.
It looks like MSBuild's messages are in English but the C# compiler's are in Czech. @nagilson, does
DOTNET_CLI_UI_LANGUAGEnot imply that the CLI sets the variables that Roslyn checks for?
@rainersigwald There is no logic to set a special variable for Roslyn in the SDK or MSBuild to my knowledge (which should be most of the code.) I was not aware they had their own language variable, is that the case? It does set VSLANG.
I looked at it again since its been a while. Actually, it looks like it sets PreferredUILang too, which it says is for C#/VB. https://github.com/dotnet/sdk/blob/main/src/Cli/Microsoft.DotNet.Cli.Utils/UILanguageOverride.cs But it does only set those things if it detects a language override, which It should in this case. May be helpful to get a aka.ms//binlog. If the user had set VSLANG or PreferredUILang, as well to something else, then it would NOT override that.
Opinions on this vary widely, by individual dev and by culture--as I understand it many Europeans are on the "just give us English" side and many East Asian folks are strongly on "if it's in English it's useless, give me a translation". So we have to try to find compromises.
Then maybe having English as default for Europeans would be a better compromise? I'm repeatedly frustrated with Microsoft's approach to localization of development tools, such as MSDN (Microsoft Learn?) randomly forcing terrible machine translations of documentation pages, which aren't even consistent with the translations in MSBuild / Roslyn, making it even more difficult to find anything!
For example, Adam's example error message "Očekával se středník (;)." is apparently translated on https://learn.microsoft.com/cs-cz/dotnet/csharp/misc/cs1002 as "; Očekává", which is complete nonsense. Not to mention that comments in the example code on that page are still in English. This is not helpful at all.
If you're not going to do localization properly, then don't make it the default option. If you are doing proper localization for East Asian languages, and they have a lot of resources on the internet in their language so it's easier for them to find help, then sure, default to localized for them. For my small european country in particular, this is not the case at all, and all it's doing is hurting communication and searchability.
To be clear:
- MSBuild will continue to be localized by default.
- It should be easy to opt out of this, which should be the case in 17.9/8.0.200 (pending release) thanks to https://github.com/dotnet/msbuild/pull/9392.
- There may be bugs in certain scenarios or with certain tools. Please report them!
- For quality-of-translation issues, please file bugs on individual repos (but be aware that they'll need to be mirrored to the internal Microsoft loc bug tracking system and then triaged and fixed by the Microsoft loc team).
To clarify: we should expect everything in the build process to respect DOTNET_CLI_UI_LANGUAGE=en, and open new issues (on the corresponding component issue tracker: e.g. Roslyn, .NET SDK, etc.) if something misbehaves in this mode. Correct?
