Build host should localize message output

[dibarbet]

See #74896

See https://github.com/dotnet/roslyn/blob/main/src/Workspaces/Core/MSBuild/MSBuild/BuildHostProcessManager.cs#L158

When starting the build host we do not pass the user value for DOTNET_CLI_UI_LANGUAGE to the build host, so the output is not localized. Likely we should just be passing this over to the build host.

There is an open question of what should happen if VSCode configures one language, and DOTNET_CLI_UI_LANGUAGE specifies a different one.

[jasonmalinowski]

I would not expect us to directly listen to the environment variable. If we were going to support localization, I'd expect us to look at CurrentCulture or similar in that launch point and then pass that along as a switch to get it to be passed to the other process. The reason for distinction would be there's no requirement that MSBuildWorkspace be used in a process where DOTNET_CLI_UI_LANGUAGE is valid in the first place, and if we're running a .NET Framework host, we can't set the environment variable there.

[JoeRobich]

If we were going to support localization, I'd expect us to look at CurrentCulture or similar in that launch point and then pass that along as a switch to get it to be passed to the other process.

I agree. Many users expect their VS Code Locale to take precedence.

[jasonmalinowski]

@JoeRobich I think we already pass the locale over to Current[UI]Culture as a part of LSP command dispatching, right? So as long as MSBuildWorkspace does the right thing, this should hopefully work?

[JoeRobich]

@jasonmalinowski Yes. I think we should pass the CurrentCulture as you suggest. Do not want to break the chain of VS Code locale -> Roslyn LSP -> BuildHost by looking at an environment variable.