Make Blazor WASM respect current UI culture

[dariatiurina]

Make Blazor WASM respect current UI culture

Description

This pull request introduces support for differentiating between CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture in WebAssembly applications.

Changes

• Updated GetCultures method in WebAssemblyCultureProvider to accept both CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture, enabling separate handling of culture and UI culture. Adjusted logic to compute culture closure for both values.
• Added a new unit test in WebAssemblyCultureProviderTest to verify that GetCultures correctly computes the culture closure when both culture and UI culture are provided.
• Added an E2E test in WebAssemblyLocalizationTest to validate that the application can differentiate between CurrentCulture and CurrentUICulture and display localized resources accordingly. To make this test work the changes were done to LocalizedText.razor and BasicTestApp/Program.cs.

Fixes #56824

[Copilot]

Pull Request Overview

This pull request adds support for differentiating between CultureInfo.CurrentCulture and CultureInfo.CurrentUICulture in Blazor WebAssembly applications, addressing issue #56824 where WASM applications previously only relied on the current culture.

Key changes:

• Enhanced WebAssemblyCultureProvider.GetCultures method to accept both culture and UI culture parameters
• Updated culture loading logic to compute culture closure for both culture types
• Added comprehensive test coverage for the new functionality

Reviewed Changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
WebAssemblyCultureProvider.cs	Updated GetCultures method to handle both culture and UI culture parameters with proper closure computation
WebAssemblyCultureProviderTest.cs	Added unit test to verify culture closure computation with separate culture and UI culture values
WebAssemblyLocalizationTest.cs	Added E2E test to validate proper differentiation between CurrentCulture and CurrentUICulture
Program.cs	Enhanced culture configuration to support separate culture and UI culture query parameters
LocalizedText.razor	Added display element for UI culture to support E2E testing

[ilonatommy]

Good job! I added a few improvement ideas.

[pavelsavara]

Should we try to implement this for general WASM in runtime ? (not just Blazor)

[javiercn]

Should we try to implement this for general WASM in runtime ? (not just Blazor)

I was filing an issue to track this, but I just thought that it would "fundamentally" change the way this works. Currently you set the culture on the current thread (in managed code) before you start up the host and that triggers an async process when the host is built.

If we were to do something for wasm, it will have to be something that gets specified before any managed code runs, doesn't it? As we can't load the dlls when you change the CultureInfo.CurrentCulture for example.

[pavelsavara]

As we can't load the dlls when you change the CultureInfo.CurrentCulture for example.

We can't load it from synchronous code, but our startup is async.

That said, runtime already detects browser culture and sets it to managed during startup.
During runtime startup we could load proper satellite assemblies and set UI culture too.
I think we just don't do it yet.

Does Blazor trigger LoadCurrentCultureResourcesAsync even later than during startup ?
Is there public API for it ?

[ilonatommy]

Good job! The failures do not look related but also, they have not failed before your PR. I triggered a rerun. If you want to look into them to asses it yourself, that's the build link: https://dev.azure.com/dnceng-public/public/_build/results?buildId=1109517&view=ms.vss-test-web.build-test-results-tab&runId=30444950&resultId=114098&paneView=history

[ilonatommy]

That said, runtime already detects browser culture and sets it to managed during startup.

I don't think we are reading any managed info on runtime startup. We are checking 2 things:

• user preference passed to the startup config (withApplicationCulture)
• if not specified, checking the browser settings.

https://github.com/dotnet/runtime/blob/ac764af3e2d77aa582dff3511295ee701b831a7d/src/mono/browser/runtime/loader/icu.ts#L48

[javiercn]

As we can't load the dlls when you change the CultureInfo.CurrentCulture for example.

We can't load it from synchronous code, but our startup is async.

That said, runtime already detects browser culture and sets it to managed during startup. During runtime startup we could load proper satellite assemblies and set UI culture too. I think we just don't do it yet.

Does Blazor trigger LoadCurrentCultureResourcesAsync even later than during startup ? Is there public API for it ?

I'm not sure how much it will buy us through. The issue stands that a user can do CultureInfo.CurrentCulture = "my-culture" before the host starts and the right cultures/assemblies get loaded when the webassembly host starts.

Note that it's not enough to load the culture from the browser. Apps should be able to override that with values from cookies or any other source.

If we try to do it automatically, we run the risk of downloading unnecessary assemblies when the app developer sets the culture to a different value. That said, I don't think it would be a big deal, so if longer term we also want to do it on the runtime, that would be ok. I just question how much that buys us considering we need to keep the current functionality working.

[pavelsavara]

I don't think we are reading any managed info on runtime startup. We are checking 2 things:

We are not reading it, but we are setting it. The env variable will influence Mono and managed too AFAIK

https://github.com/dotnet/runtime/blob/abc4c652eca9e02c4ff5d4dac0ceb58a4a15b8e3/src/mono/browser/runtime/loader/config.ts#L222

I don't know if this would also set UI culture

[ilonatommy]

I don't think we are reading any managed info on runtime startup. We are checking 2 things:

We are not reading it, but we are setting it. The env variable will influence Mono and managed too AFAIK

https://github.com/dotnet/runtime/blob/abc4c652eca9e02c4ff5d4dac0ceb58a4a15b8e3/src/mono/browser/runtime/loader/config.ts#L222

I already forgot how it was, I am checking now and that LANG is used only for console encoding:

https://github.com/dotnet/runtime/blob/abc4c652eca9e02c4ff5d4dac0ceb58a4a15b8e3/src/libraries/Common/src/System/Text/EncodingHelper.Unix.cs#L29

The culture flow is rather:

• start runtime,
• check if config does not set invariant mode,
• if not, check if user set any preference with withApplicationCulture,
• if not, check the browser's culture
• load the shared based on this info.

I don't see a feedback loop runtime -> managed, beyond env variables about globalization mode:
https://github.com/dotnet/runtime/blob/abc4c652eca9e02c4ff5d4dac0ceb58a4a15b8e3/src/libraries/System.Private.CoreLib/src/System/Globalization/GlobalizationMode.cs#L15

[pavelsavara]

We are not running this test because we don't have remote executor

https://github.com/dotnet/runtime/blob/abc4c652eca9e02c4ff5d4dac0ceb58a4a15b8e3/src/libraries/System.Runtime/tests/System.Globalization.Tests/CultureInfo/CultureInfoCurrentCulture.cs#L122-L145

But I think this is the functionality we should be striving for. I think this is not just for console

[guardrex]

I created an RC1 doc tracking issue for this ...

[RC1] Blazor WASM respects the current UI culture
dotnet/AspNetCore.Docs#35872