Globalization support in Blazor WASM #17017
Labels
area-blazor
Includes: Blazor, Razor Components
Components Big Rock
This issue tracks a big effort which can span multiple issues
enhancement
This issue represents an ask for new feature or an enhancement to an existing one
feature-blazor-wasm
This issue is related to and / or impacts Blazor WebAssembly
Milestone
What we want to deliver here for 3.2 is setting the thread culture appropriately during application startup. We need a design that:
If there is any prior art in ASP.NET Core's server-side logic for choosing a thread culture based on an incoming "accept-language" header, we should look at what parts of that could be reused.
If we're unclear about any aspect of the design, I'd favour picking something more manual and low-level rather than inventing any complex rules. For example, if it was simplified so much that we didn't have automatic language->culture mappings and developers always had to control the exact mapping logic (preferably via procedural code, not a special new config notion) that would be OK.
I don't yet know whether this needs to be controlled on the JS side (e.g., in some callback function passed to Blazor.start) or whether it can be done in .NET (e.g., in
Program.cs
). The design for this needs to consider pros/cons of those options, particular accounting for whether we can make server/client/prerendering all naturally consistent with each other.The text was updated successfully, but these errors were encountered: