Skip to content

Make Blazor WASM respect current UI culture #62905

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 8 commits into from
Jul 31, 2025

Conversation

dariatiurina
Copy link
Contributor

@dariatiurina dariatiurina commented Jul 24, 2025

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

@dariatiurina dariatiurina marked this pull request as ready for review July 25, 2025 12:42
@Copilot Copilot AI review requested due to automatic review settings July 25, 2025 12:42
@dariatiurina dariatiurina requested a review from a team as a code owner July 25, 2025 12:43
Copilot

This comment was marked as outdated.

@dariatiurina dariatiurina requested a review from Copilot July 28, 2025 13:45
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 ilonatommy changed the title Fix. 56824 -> Blazor WASM only relies on the current culture Make Blazor WASM respect current UI culture Jul 28, 2025
@dariatiurina dariatiurina self-assigned this Jul 29, 2025
Copy link
Member

@ilonatommy ilonatommy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good job! I added a few improvement ideas.

Copy link
Member

@pavelsavara pavelsavara left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@javiercn
Copy link
Member

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
Copy link
Member

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 ?

Copy link
Member

@ilonatommy ilonatommy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Member

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
Copy link
Member

javiercn commented Jul 31, 2025

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
Copy link
Member

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

@dariatiurina dariatiurina merged commit 6b15190 into dotnet:main Jul 31, 2025
30 checks passed
@dariatiurina dariatiurina deleted the 56824-fix-cultures-wasm branch July 31, 2025 10:25
@dotnet-policy-service dotnet-policy-service bot added this to the 10.0-rc1 milestone Jul 31, 2025
@ilonatommy
Copy link
Member

ilonatommy commented Jul 31, 2025

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
Copy link
Member

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
Copy link
Contributor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Blazor WASM only relies on the current culture (current UI culture isn't respected)
5 participants