Blazor Localization does not work with InteractiveServer

[aco-mreble]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

When using <Routes @rendermode="InteractiveServer"/> in pre-rendering the correct locale from the browser is shown but after pre-rendering succceded the Fallback Locale is set again. If you disable pre-rendering the fallback locale will be set all the times

Expected Behavior

Blazor should set the correct locale for users

Steps To Reproduce

Create new Blazor Web App:

dotnet new blazor -o Test

in Program.cs add

builder.Services.AddLocalization();

and

app.UseRequestLocalization(["en-US", "de-DE"]);

In Components/App.razor change <Routes /> to

<Routes @rendermode="InteractiveServer"/>

for testing with prerender or

<Routes @rendermode="new InteractiveServerRenderMode(prerender:false)"/>

for testing without prerender.

In Components/Pages/Home.razor add this line below the page title

@(CultureInfo.CurrentCulture)

Then go to the website e.g. with Edge and go to Developer Tools -> Sensors -> Location and set it to "Berlin". In prerender: true some milliseconds you see the correct one, on prerender: false its allways the wrong one (en-US)

Exceptions (if any)

No response

.NET Version

8.0.101

Anything else?

Using Edge Version 121.0.2277.83 (Official build) (64-bit)

I believe I've pinpointed the issue: During the debugging of the RequestLocalizationMiddleware.Invoke method, I observed that each HttpRequest is sent with the appropriate Accept-Language header. However, the final call to this method targets http://localhost:XXXX/_blazor, where the header is unexpectedly set to en-US,en;q=0.9,de;q=0.8. I'm unsure of the cause, but since this is the last invocation of the method during a user's page request, the CultureInfo.CurrentCulture ends up being reset to en-US.

[ghost]

Thank you for filing this issue. In order for us to investigate this issue, please provide a minimal repro project that illustrates the problem without unnecessary code. Please share with us in a public GitHub repo because we cannot open ZIP attachments, and don't include any confidential content.

[aco-mreble]

Here is the repo:
https://github.com/aco-mreble/dotnet-aspnetcore-issue53707

[guardrex]

I'm going to keep an 👁️ on this for possible docs work, even if only a temporary call out is needed for a framework 😈 during the 8.0 era.

[mkArtakMSFT]

@halter73 could you please try to validate this? Thanks!

[halter73]

This appears to be a bug, or at least a shortcoming, of location override using "Sensors" pane in the Chrome/Edge dev tools as described in https://www.aleksandrhovhannisyan.com/blog/changing-locale-in-chrome-with-dev-tools/. I think it was primarily intended to override the location provided by JS Sensor APIs as the name implies, but it happens to change some (but not all) of the Accept-Language headers.

If you look at request headers the network tab in the developer tab, you'll see that it aligns with the Accept-Language reported by the middleware in the repro project.

This is not a bug in Blazor though. That's just what happens if you override the language using the "Sensors" pane. If instead, you go to edge://settings/languages, add "German (Germany) - Deutsch (Deutschland)" as a language and move it to the top, the Accept-Language headers should be correct, and everything should work as expected.

@guardrex I don't know if you want to include anything about this in our docs. Do they say anything about how to test localization? Maybe we could add something to https://learn.microsoft.com/aspnet/core/fundamentals/troubleshoot-aspnet-core-localization

[guardrex]

No, we don't in the Blazor glob/loc doc. We do cross-link to the main doc set article (IIRC). I'll take a closer look at this on Monday.

[guardrex]

BTW tho @aco-mreble ... Hisham and I have worked on the article, and we have two candidates for BWA glob/loc. I favor continuing to use local storage on the client, while Hisham likes hacking the loc cookie client-side. The article currently covers the approach that I favor.

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0

The bit that pertains to BWAs is here ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0#dynamically-set-the-culture-in-a-blazor-web-app-by-user-preference

If you're only trying to use interactive SSR, see this bit of the article ...

https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-8.0#dynamically-set-the-server-side-culture-by-user-preference

... and WRT to the discussion here about prerendering behavior, I don't have any knowledge on it. I will take a closer look on Monday. I'm off the weekend now 🎉.