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 (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:
  • 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

[Gnbrkm41]

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.

[KirillOsenkov]

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

[shadow-cs]

Deleting C:\Program Files\dotnet\sdk\{sdk-version}\{locale} folder can also be used as a workaround.

[hcoona]

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

[dominoFire]

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

[chylex]

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.

[hcoona]

Agree. At least you can search few results with the localized message in StackOverflow ;-(

[chylex]

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

1. Search the error code on Google.
2. Visit a Microsoft documentation page for the error.
3. 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.
4. Manually switch the website language to English.
5. Finally you can copy/paste the actual error message into Google.

I'm sorry, but this whole thing is a terrible user experience.