Skip to content
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

Globalization support in Blazor WASM #17017

Closed
mkArtakMSFT opened this issue Nov 12, 2019 · 2 comments
Closed

Globalization support in Blazor WASM #17017

mkArtakMSFT opened this issue Nov 12, 2019 · 2 comments
Assignees
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

Comments

@mkArtakMSFT
Copy link
Member

mkArtakMSFT commented Nov 12, 2019

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.

@mkArtakMSFT mkArtakMSFT added enhancement This issue represents an ask for new feature or an enhancement to an existing one PRI: 1 - Required Components Big Rock This issue tracks a big effort which can span multiple issues area-blazor Includes: Blazor, Razor Components feature-blazor-wasm This issue is related to and / or impacts Blazor WebAssembly labels Nov 12, 2019
@mkArtakMSFT mkArtakMSFT added this to the blazor-wasm milestone Nov 12, 2019
@Andrzej-W
Copy link

You should also add support for time zones:
mono/mono#15260
mono/mono#6368

@mkArtakMSFT
Copy link
Member Author

This is being resolved as part of the localization work.

@ghost ghost locked as resolved and limited conversation to collaborators Apr 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
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
Projects
None yet
Development

No branches or pull requests

4 participants