search

dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.21k stars 9.95k forks source link

Runtime Culture and Localization #5471

Closed grahamehorner closed 5 years ago

grahamehorner commented 6 years ago

Please consider browser runtime cultural and allow switching of culture with in the Blazor environment

SteveSandersonMS commented 6 years ago

Good idea. It will be a while before we get to it, but it's good to have on the backlog.

DNF-SaS commented 6 years ago

Strange: ResourceManager.GetResourceSet() just returns null for every localized resource (these who reside in files with the ISO639-1 code in the filename)?

SteveSandersonMS commented 5 years ago

When doing this, be sure to check cases around Data Annotations validation and the built-in parsing validators in the Input* components to be sure they localize conveniently.

DamianEdwards commented 5 years ago

Is this issue intended to cover just the WASM side of the world, or localization in the Razor Components server-side features in 3.0 too?

SteveSandersonMS commented 5 years ago

@DamianEdwards Both. Currently this issue is quite high-level and all-encompassing, but will get broken down into several sub-issues as we start work on it.

grahamehorner commented 5 years ago

IMHO and just for my two pennies worth @SteveSandersonMS ;) as a developer of a multi-lingual application Razor Component circuits would need some mechanism to send the users browser culture to the server; to allow the rendering component(s) to identifier the correct resources to use and/or having routing determine any culture specifics; so for a starter for 10 a smaller task of the bigger story IMHO would be to possibly update the component circuit implementation to provide browser agent string and culture with in the messages sent to the signalr hub.

NOTE: do you think a user should be able to switch culture of the browser without causing issues/re-login etc. ? or should a user session be forced into a fixed culture ?

Franklin89 commented 5 years ago

I have experienced a strange behavior (in my opinion strange) as I wanted to try to implement some sort of localization (client side blazor). If I set the CultureInfo in the startup of the client app:

~~public void Configure(IComponentsApplicationBuilder app) { System.Threading.Thread.CurrentThread.CurrentCulture = new CultureInfo("de-CH"); System.Threading.Thread.CurrentThread.CurrentUICulture = new CultureInfo("de-CH"); app.AddComponent("app"); }~~

and then render a input with a DateTime field the input gets rendered in the correct format according to the culture. If I then change the date inside the input and the state gets updated the date gets displayed in the default format. I then tried the same with a string property.

~~public string Birthdate { get { Console.WriteLine(System.Threading.Thread.CurrentThread.CurrentCulture); return Birthdate.ToShortDateString(); } set { Birthdate = DateTime.Parse(value); } }~~

The culture that gets written to the console first shows the correct culture. After changing the value the culture is empty. So it seems to me that the culture gets cleared somehow.

Update Of course we don't need to change the CurrentThread but the CultureInfo.DefaultThreadCurrentCulture. So after changing it to:

CultureInfo.DefaultThreadCurrentCulture = new CultureInfo("de-CH");
CultureInfo.DefaultThreadCurrentUICulture = new CultureInfo("de-CH");

all is working as expected.

rynowak commented 5 years ago

We're using https://github.com/aspnet/AspNetCore/issues/9386 to track this area.