Aspnetcore: Runtime Culture and Localization

[grahamehorner]

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

[SteveSandersonMS]

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

[DNF-SaS]

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

[SteveSandersonMS]

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]

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]

@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]

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]

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]

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