.NET Core 3.x.x installer language in Portuguese instead of English

[RomBrz]

Issue Title

.NET Core 3.0.x and 3.1.0 installers using different language to installation instead of the language of the download, seems like that prior to 3.x.x the installers runs at system language, and with 3.x.x runs with server location.

General

The behavior of the installer changed with .NET Core 3.x.x. For example, if i go to the official download site and pickup the .NET Core 2.1.14 Server Bundle (english site), download and execute it on a server, the installer will be in English language.
If i download the .NET Core 3.0.1 Server Bundle on the same official site, and execute on the same server, the installer will be in Brazilian Portuguese language. The same occurs with 3.0.0 and the new 3.1.0.

The server is with English language, but region set to Brazil. So seems like the behavior changed with the 3.0.0.

This is normal? This is expected? Does this affect the behavior of the server? (All installed in english, but only with .NET 3.x.x installed in PT-BR).

Prior to .NET Core 3.x.x, for example, i'm from Brazil, and download the .NET Core. I would install on a server with english language and region settings set to Brazil.

[scalablecory]

@dagood

[dagood]

The version number makes sense, since localized text was added for 3.0.0+ with 349ed16.

About region vs. language setting affecting the language used, there's an issue about it at dotnet/installer#2453, but I'm not too familiar with that. (It's possible this is something that the WiX Burn engine is handling that we can't change.) @joeloff

You can pass a command line arg to set the LCID used in the installer, -lang 1033, if that happens to help.

None of this affects the product you get on the machine after the install is complete.

[RomBrz]

I cannot pass the command line arg, because i cannot read full helper..
If i put this:
.\dotnet-hosting-3.0.1-win.exe /?
The helper screen appears in Portuguese and there's more text than the window size and i cannot scroll down or export the text, so i cannot even read how i should pass the arg correctly.

I tried to start the installer with that:
.\dotnet-hosting-3.0.1-win.exe -lang 1033
.\dotnet-hosting-3.0.1-win.exe --lang 1033
.\dotnet-hosting-3.0.1-win.exe "-lang 1033"
.\dotnet-hosting-3.0.1-win.exe "--lang 1033"
.\dotnet-hosting-3.0.1-win.exe '-lang 1033'
.\dotnet-hosting-3.0.1-win.exe '--lang 1033'
.\dotnet-hosting-3.0.1-win.exe /lang 1033 (seems like the args to install .NET Core are with "/" instead of "-", but didn't work to)
.\dotnet-hosting-3.0.1-win.exe "/lang 1033"
.\dotnet-hosting-3.0.1-win.exe '/lang 1033'
Start-Process dotnet-hosting-3.0.1-win.exe -ArgumentList '/lang 1033'
Start-Process dotnet-hosting-3.0.1-win.exe -ArgumentList '-lang 1033'

Every one of these opens a Portuguese window instead of a English window.

I have these 1001 Error events in my server:

Fault bucket , type 0
Event Name: CbsPackageServicingFailure2
Response: Not available
Cab Id: 0

Problem signature:
P1: 10.0.17763.793
P2: Microsoft-Windows-LanguageFeatures-Basic-pt-br-Package
P3: 10.0.17763.1
P4: amd64
P5: unknown
P6: 800f0954
P7: CBS Other
P8: Absent
P9: Absent
P10: FodHelper(LanguageFeaturesOnDemand)

So i think that may be connected these errors with the .NET Core 3.x installed in pt-br language.. or it's just a coincidence?

[dagood]

The helper screen appears in Portuguese and there's more text than the window size and i cannot scroll down or export the text, so i cannot even read how i should pass the arg correctly.

Yikes, yes, I see this as well in Spanish (a lang pack I happen to have on my VM). Filed #18152 for this issue, thanks for pointing it out.

Every one of these opens a Portuguese window instead of a English window.

Apologies, I've used -lang x before with the SDK and Runtime installers, and it works there. You're right, it doesn't work on the hosting bundle. I had no idea it would work differently for this specific installer. 😕

The -? message doesn't list any language option anyway (even for the SDK and Runtime installers), so my suggestion to check the help was also pointless in the first place, sorry.

I think there are two questions that I'll need to let @joeloff answer at this point:

1. How can the hosting bundle installer be forced to use a certain LCID? (Also useful for testing.)
2. Should the installer be using Region or Language to choose the language it displays, and should this be fixed?

[joeloff]

The UI should default based on the OS locale as that's set by the underlying installer engine. AFAIK, burn doesn't support overriding the LCID, at least, it's not officially documented, but the support might have been added in a later WiX update.

@dagood which version of WiX is runtime/SDK using when building? 3.11 or later?

[dagood]

• Core-Setup, 3.10.4 https://github.com/dotnet/core-setup/blob/68b32ff4b583fa458d124b81acc316b223e6b223/src/pkg/Directory.Build.props#L58
• Core-SDK, 3.10.4 https://github.com/dotnet/core-sdk/blob/2bedb36a6a83ebb72e993f82ff439896046471ae/src/redist/targets/GenerateMSIs.targets#L6

[joeloff]

ok, I tried with the 3.0.1 hosting bundle on an en-CA OS. I was able to run with -lang 1036 and it popped up the French UI as expected. Ditto for 1049 which displayed Russian.

[joeloff]

We are missing the 1033 folder, so when you have a non-ENU region in the OS, it will default in this case to pt-BR, but then try to apply the override to en-US (1033), not find the folder and fallback to the OS default.

@anurse this issue is mentioned in the other UI issue for the help page. We'd be touching the same code, so might be good to just fix this as well. They'd also repro for the shared-framework installer since they share UI elements.

[dagood]

So now we know now why the override isn't working, and that's fixable in a future patch to the installers.

About the main issue where it's using an unexpected language in the first place... I'm able to repro the problem as described in the issue description on the 3.0.1 hosting bundle (but in Spanish), and and at that point my OS is in this state (PowerShell commands):

$ [CultureInfo]::CurrentCulture

LCID             Name             DisplayName
----             ----             -----------
3082             es-ES            Spanish (Spain)

$ [CultureInfo]::CurrentUICulture

LCID             Name             DisplayName
----             ----             -----------
1033             en-US            English (United States)

So maybe the burn bundle, some UI stuff it depends on, .NET, or something along those lines is using CurrentCulture when it should use CurrentUICulture? Looking it up, CurrentUICulture is newer than CurrentCulture, so maybe this is a problem of legacy code. This is all just a theory though, I'm not familiar enough with loc or the depths of the installer UI to go much further without doing a lot more digging.

[joeloff]

For the default engine in WiX, that's all native code. I'm guessing there's similar rules to how .NET handles resources. If I remember correctly, it's something like specific first, then the language, then neutral so for English it might search "en-US", then "enu" or "en", then neutral.

I did notice that the engine logs a property value it sets for the LCID, but regardless of the override, it doesn't seem to record when the value changes in the log

[RomBrz]

Still happens with 3.0.3 and 3.1.2

[joeloff]

@anurse the fix for this is pretty simple. It's just the 1033 folder that's missing, causing the UI to fail when you force it to 1033 on a non en-US OS

[scalablecory]

@dagood has this been resolved? Thanks.

[dagood]

It hasn't, as far as I know. Moving this to dotnet/aspnetcore as the installer mentioned is built there, and there's also dotnet/installer#2453 tracking the same issue in dotnet/installer for the SDK installer.