Added Culture persistence between Client and Server

[dariatiurina]

Added Culture persistence between Client and Server

Description

This pull request introduces a new mechanism to persist and enforce the server-side culture on the client in Blazor WebAssembly applications. The main feature is the addition of the CultureStateProvider, which captures the current culture during server prerendering and applies it on the client after hydration.

Changes:

• Introduced the CultureStateProvider class, which captures the current thread's culture and UI culture for persistence and can reapply them on the client side after hydration.
• Registered CultureStateProvider in relevant project files so it is available for both server and WebAssembly projects.
• Added the EnforceServerCultureOnClient extension method to IRazorComponentsBuilder, which registers and persists the CultureStateProvider for interactive WebAssembly render mode.
• Changed the startup flow in WebAssemblyHost so that, after restoring persisted state, the stored culture is applied (if available) before loading culture-specific resources.
• Added end-to-end tests to verify that the server culture is correctly persisted and restored on the client when enabled, and not persisted by default.
• Added EnforceServerCultureOnClient to the unshipped PublicAPI.

Fixes #26941

[Copilot]

Pull Request Overview

This pull request introduces a culture persistence mechanism for Blazor WebAssembly applications, allowing server-side culture settings to be maintained on the client after hydration. The main purpose is to ensure consistent localization between server prerendering and client-side execution.

• Adds CultureStateProvider class to capture and restore culture information across server-client transitions
• Integrates culture restoration into the WebAssembly host startup sequence after state restoration
• Provides EnforceServerCultureOnClient extension method to enable this feature opt-in

Reviewed Changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/Components/Shared/src/CultureStateProvider.cs	New class that captures current culture during prerendering and applies it on the client
src/Components/WebAssembly/Server/src/WebAssemblyRazorComponentsBuilderExtensions.cs	Adds EnforceServerCultureOnClient extension method for configuration
src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHost.cs	Integrates culture restoration into startup flow after state restoration
src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHostBuilder.cs	Registers CultureStateProvider for WebAssembly projects
src/Components/test/E2ETest/ServerRenderingTests/InteractivityTest.cs	E2E tests verifying culture persistence behavior
Various project files	Adds shared source references for CultureStateProvider

Comments suppressed due to low confidence (3)

src/Components/Shared/src/CultureStateProvider.cs:5

• The CultureStateProvider class should be in a more appropriate namespace. Since it deals with culture persistence and not forms, it should be in Microsoft.AspNetCore.Components.Web or Microsoft.AspNetCore.Components namespace instead of Microsoft.AspNetCore.Components.Forms.

namespace Microsoft.AspNetCore.Components.Forms;

src/Components/WebAssembly/WebAssembly/src/Hosting/WebAssemblyHost.cs:5

• This using statement is inconsistent with the actual namespace where CultureStateProvider should be located. If the class is moved to the correct namespace, this using statement should be updated accordingly.

using Microsoft.AspNetCore.Components.Forms;

src/Components/WebAssembly/Server/src/WebAssemblyRazorComponentsBuilderExtensions.cs:10

• This using statement is inconsistent with the actual namespace where CultureStateProvider should be located. If the class is moved to the correct namespace, this using statement should be updated accordingly.

using Microsoft.AspNetCore.Components.Forms;

[javiercn]

Looks great.

Mainly we will have to discuss the naming on API review

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.

[ilonatommy]

@javiercn, this looks good. Were we waiting for rc2 to do it? Why is it on hold? I thought we API-review only merged PRs

[javiercn]

@ilonatommy we punted it to 11.

There are a few tweaks that we want to do that involve public API.

Ideally we do API review as we go, no after the merge.

[dotnet-policy-service]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no conflicting changes have occurred, please rerun validation before merging. You can do this by leaving an /azp run comment here (requires commit rights), or by simply closing and reopening.