Blazor WASM Pre-Rendering Localization Behaviour

[TomJD]

Describe the bug

Added localization to Blazor WASM with pre-rendering enabled. When pre-rendering is disabled, the localization language gets picked up instantly upon load. With pre-rendering on, it first shows the initial language (en-GB in my use case) and then switches to the selected language (fr-FR in my use case) after loading.

I would like to know how I can avoid this visible change of culture.

I am storing the culture in LocalStorage and picking it up in Program.cs. (currently hard-coded in the repo due to testing). Also attempted via Cookie.

To Reproduce

minimal repo Available

Exceptions (if any)

Further technical details

• ASP.NET Core 5.0.100-rc.1.20452.10
  .NET runtimes installed:
  Microsoft.AspNetCore.All 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 5.0.0-rc.1.20451.17 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.1.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.11 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.21 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.22 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.2.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 5.0.0-rc.1.20451.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.0.0 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.3 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.7 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 3.1.8 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]
  Microsoft.WindowsDesktop.App 5.0.0-rc.1.20452.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

• VS Community Preview Version 16.8.0 Preview 3.2

[javiercn]

@TomJD thanks for contacting us.

Do you setup the culture on the request? Prerendering will pick up the culture on the server or the culture set by the localization middleware.

[TomJD]

Hello @javiercn thank you for your time.

I registered it in the Startup file on the server. This is what I have so far:

Program.cs

        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);

            builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
            builder.Services.AddScoped<IWeatherForecastService, WeatherForecastService>();

            builder.Services.AddBlazoredLocalStorage();
            builder.Services.AddLocalization(/*options => options.ResourcesPath = "Resources"*/);
            var host = builder.Build();

            // removed

            await host.RunAsync();
        }

and on the Server project:

ConfigureServices
services.AddLocalization();

Configure

            var supportedCultures = new CultureInfo[]
            {
                new CultureInfo("en"),
                new CultureInfo("fr")
            };
            app.UseRequestLocalization(new RequestLocalizationOptions
            {
                DefaultRequestCulture = new RequestCulture("fr"),
                SupportedCultures = supportedCultures,
                SupportedUICultures = supportedCultures,
                RequestCultureProviders = new[] { new CookieRequestCultureProvider() }
            });

The first load is French, and changes automatically over to English. The cookie exists with French culture, so I cannot find what is causing the switching back to English... translations found within the .resx are correct

[TomJD]

After a glass of red wine and some further digging, this seems to work, but does not seem ideal:

Program.cs (hard coded French default)

        public static async Task Main(string[] args)
        {
            var builder = WebAssemblyHostBuilder.CreateDefault(args);


            builder.Services.AddScoped(sp => new HttpClient { BaseAddress = new Uri(builder.HostEnvironment.BaseAddress) });
            builder.Services.AddScoped<IWeatherForecastService, WeatherForecastService>();


            builder.Services.AddBlazoredLocalStorage();
            builder.Services.AddLocalization(/*options => options.ResourcesPath = "Resources"*/);
            var host = builder.Build();

            var culture = new CultureInfo("fr");
            CultureInfo.DefaultThreadCurrentCulture = culture;
            CultureInfo.DefaultThreadCurrentUICulture = culture;

            await host.RunAsync();
        }

Startup.cs

ConfigureServices

        public void ConfigureServices(IServiceCollection services)
        {
            services.AddLocalization();


            services.AddControllersWithViews();
            services.AddRazorPages();


            services.AddBlazoredLocalStorage();
            services.AddSingleton<IWeatherForecastService, WeatherForecastService>();
        }

Configure

 public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            var supportedCultures = new CultureInfo[]
            {
                new CultureInfo("en"),
                new CultureInfo("fr")
            };
            app.UseRequestLocalization(new RequestLocalizationOptions
            {
                DefaultRequestCulture = new RequestCulture(supportedCultures[1]),
                SupportedCultures = supportedCultures,
                SupportedUICultures = supportedCultures,
                RequestCultureProviders = new[] { new CookieRequestCultureProvider() }
            });

[...]
}

It seems that because it is being rendered twice, once by the client and then once by the server, the settings is being overwritten. For instance, if I force

English in the Configure and French in Program.cs , the UI ends up in French.
French in the Configure and English in Program.cs , the UI ends up in English.

Is there a way to avoid this? At the moment, it seems that services registered on the client also need to be registered on the server. So in my use case, I would need to use JSInterop to read the cookie being set for the localization and pass it in the config of Program.cs as well as reading the cookie on the server perhaps via middleware so they are the equally configured on both, client & server.

If one is different than the other, the culture set in Program.cs overwrites.

Or perhaps I'm lost... ?

[SteveSandersonMS]

I'm not 100% certain what your desired behavior is, but if you want both prerendering (server-side) and interactive rendering (client-side) to run as the same culture then you'll need to store the culture choice somewhere accessible to both server and client code.

For example, you might choose to store it in a cookie, and use the server's UseRequestLocalization middleware to pick it up and set the server-side thread culture. Then you could, on the server, emit that choice of culture into the resulting HTML page by adding some expression into your _Host.cshtml file (for example, write it out as a <meta> tag on the page). Then your WebAssembly Program.cs could use JS interop to read that value from the DOM and use it to set the culture. Then you'd be sure always to have consistency between the two.