MSBuild should respect upstream tool language requests

[cdmihai]

Different upstream tools have different language configuration requirements:

• dotnet CLI sets DOTNET_CLI_UI_LANGUAGE and VSLANG (MSBuild should respect upstream tool language requests #1596 (comment) https://github.com/dotnet/cli/issues/9722#issuecomment-409358296)
• Visual Studio has a fallback mechanism guideline. In order:
  • VSLANG environmnent variable
  • /lcid command line switch
  • call GetConsoleFallbackUICulture (we only do this currently)

Related info: https://github.com/dotnet/cli/issues/4988#issuecomment-266836559

[nguerrera]

VSLANG is sufficient for CLI and VS since we set that when the language is overridden by means other than VSLANG.

[martinstein]

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.

[cdmihai]

Only option I know is to change the machine's language.

[nguerrera]

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.

[lobster2012-user]

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.

[KirillOsenkov]

chcp 437 seems to work if you call it before invoking MSBuild

[nagilson]

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.

[sidorov-alex]

Setting DOTNET_CLI_UI_LANGUAGE=en helped for me.

[chylex]

I already set DOTNET_CLI_UI_LANGUAGE=en and I'm still getting this...

[sidorov-alex]

@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.

[Seikilos]

Note: This only work for msbuild using dotnet build. Calling msbuild directly does not honor the language.

[nagilson]

This should be added & fixed in 8.0 preview 5!

[chylex]

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.

[adam-zluva]

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=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.

[rainersigwald]

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...

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 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.

To make things extra confusing, some of those cs mean C# and some mean Czech.

[rainersigwald]

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=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".

You'll have to take this up with JetBrains, that sounds like a Rider bug (or doc bug) to me.

[nagilson]

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?

@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.

[rainersigwald]

I would have expected VSLANG to do it . . .

[nagilson]

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.

[chylex]

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.

[rainersigwald]

To be clear:

1. MSBuild will continue to be localized by default.
2. It should be easy to opt out of this, which should be the case in 17.9/8.0.200 (pending release) thanks to Fix the ui language override helper method for input language "en"  #9392.
3. There may be bugs in certain scenarios or with certain tools. Please report them!
4. 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).

[ForNeVeR]

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?

[rainersigwald]

Exactly correct. But we know of the big can't-set-DOTNET_CLI_UI_LANGUAGE=en bug in 8.0.100 (#9254), so make sure it's not that one before filing please :)

[chylex]

Understood, but

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).

sorry, I'm not going to spend a month of my life reporting endless issues in awful machine translations on your documentation websites, which will only keep piling up as you continue to add new articles. At least MSBuild looks like it might be localized by humans, from the few bits of text I've seen, but what's happening in your online documentation is tragic.