Open taoyouh opened 4 years ago
@taoyouh thanks for contacting us.
This is likely due to the url used to establish the connection with server-side Blazor.
@rynowak do you have any thoughts around this?
@SteveSandersonMS We could consider tackling query string parameters when we setup the connection to the hub so that things like this would possibly work. Do you have any opinions?
@anurse how does query string localization work in SignalR?
SignalR doesn’t do anything with it. Any culture information on the HttpContext when it reaches SignalR should be preserved.
@anurse do you have any docs or thoughts on how to do this E2E for SignalR applications?
Nope. It’s not something we’ve really thought about.
Hi,
Same here. For info, If I debug the GetString Method, the correct culture is displayed.
We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.
Hi, could recreate the problem in 5.0.2
I debugged through the RequestLocalizationMiddleware and yes the _blazor/ calls reset the current thread culture that is then used during the second call inside a razor component. I had a breakpoint inside the OnInitialized lifecycle hook and on first hit my injected IStringLocalizer instance had the correct string resolved. When the breakpoints hits the second time (which is expected when using blazor server/prerendered) the IStringLocalizer has a different result. Creating logs like:
dbug: Microsoft.Extensions.Localization.ResourceManagerStringLocalizer[1]
ResourceManagerStringLocalizer searched for 'Welcome' in 'BlazorApp1.Resources.Pages.Index' with culture 'en'.
dbug: Microsoft.Extensions.Localization.ResourceManagerStringLocalizer[1]
ResourceManagerStringLocalizer searched for 'Welcome' in 'BlazorApp1.Resources.Pages.Index' with culture 'de'.
on each request with culture/ui-culture query parameter used in the url.
Potentially related to: https://github.com/dotnet/aspnetcore/issues/28521
We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.
I don't know why, but after I modified my Pages/_Hosts.cshtml file to contain:
this.HttpContext.Response.Cookies.Append(
CookieRequestCultureProvider.DefaultCookieName,
CookieRequestCultureProvider.MakeCookieValue(
new RequestCulture(
CultureInfo.CurrentCulture,
CultureInfo.CurrentUICulture)));
The querystring started to work...
(Sorry but I don't know how to format code on github comments..., mine never works)
AFAIK the QueryStringRequestCultureProvider
works well with the Blazor Server
Describe the bug
When using QueryStringRequestCultureProvider on Blazor Server, the culture immediately changes from the one given in query string to the one set in HTTP headers.
To Reproduce
Launch the app with URL http://localhost:xxx/?culture=zh-CN. The page displays "zh-CN" for less than 1 second and changes to "en"
Further technical details
Version of .NET Core SDK:
IDE: Visual Studio 16.5.0