Globalization support in Blazor WASM #17017
Description
What we want to deliver here for 3.2 is setting the thread culture appropriately during application startup. We need a design that:
- Lets developers indicate somehow what range of cultures their application supports. Presumably this includes "just one", "just a particular set", or "all".
- If possible, and without making too many assumptions, includes sensible default logic for mapping the browser's language setting to a best choice of supported culture
- Allows the developer to override that mapping logic if they want
- If possible, is automatically consistent between server-side prerendering and client-side WebAssembly execution modes
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.