Changed initial culture detection

[dariatiurina]

Changed initial culture detection

Description:

This pull request introduces support for retrieving and managing the application's culture information throughout the Blazor WebAssembly stack. The main changes include adding a new method for accessing the application culture from both JavaScript and .NET, updating initialization logic to use this value, and ensuring the culture can be accessed and tested consistently.

Logic behind change:

The previously introduced method of checking the initial culture of the application was flawed. In the meaning, it held the culture that was set after before WebAssemblyHostBuilder.CreateDefault(args) run as initial. It was not correct. We should assume that culture that runtime detected as default. The additional change in runtime (dotnet/runtime#119269) was made to make this fix possible.

We as well checked the differences between initial UI culture and the current UI culture, which is not correct, because browser and JS do not divide between UI culture and culture. Therefore some unprompted errors could've been thrown.

Changes:

• Added a new method getApplicationCulture and implemented it in the runtime configuration setup, allowing JavaScript to expose the application's culture to .NET.
• Updated initialization logic in WebAssemblyCultureProvider to use the culture provided by JavaScript, falling back to invariant culture if unavailable.
• Extended the IInternalJSImportMethods interface and its implementation to include the new GetApplicationCulture method, enabling .NET code to retrieve the culture via interop.
• Modified culture change detection logic to only check for changes in CurrentCulture and not CurrentUICulture, refining the conditions under which an exception is thrown for unsupported culture changes.

Fixes #37258

[Copilot]

Pull Request Overview

This pull request changes how the initial culture is detected in Blazor WebAssembly applications. Previously, the system used the culture set after WebAssemblyHostBuilder.CreateDefault(args) ran, which was incorrect. The fix now uses the runtime-detected default culture through a new JavaScript interop method.

Key changes:

• Added a new getApplicationCulture method accessible from both JavaScript and .NET to retrieve the runtime's default culture
• Updated culture change detection to only check CurrentCulture instead of both CurrentCulture and CurrentUICulture
• Integrated the new culture retrieval method throughout the WebAssembly hosting infrastructure

Reviewed Changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
WebAssemblyCultureProvider.cs	Updated initialization to use runtime-detected culture and simplified culture change validation
IInternalJSImportMethods.cs	Added interface method for retrieving application culture
InternalJSImportMethods.cs	Implemented the new culture retrieval method with JS import binding
TestInternalJSImportMethods.cs	Added test implementation returning "en-US" for the new culture method
MonoPlatform.ts	Exposed the culture retrieval function in the runtime configuration
GlobalExports.ts	Added the culture method to the internal Blazor interface

[ilonatommy]

Good job with finding a clean way of passing the config value to the managed code!

We have to wait for the runtime PR to be propagated, other than this and the minor comment, it's perfect.