.NET 6, RC1: Get localization working

[SommerEngineering]

Describe the bug

I am trying to localize text in a Blazor WASM app. The process which loads the appropriate satellite assemblies seems to be very picky. In a simple "Hello World" blazor WASM app, it works as it should. If I implement the same steps in a more complex WASM app, switching cultures works (checked by logging), but not loading the assemblies.

To Reproduce

I tried to reproduce the issue in a simple repository: https://repos.tsommer.org/thorsten/BugWASMI18N. Right now, I'm failed to do so. The simple WASM app works as intended. Implementing the same steps in a complex real-world app, the situation arises that the satellite assemblies are not loaded. I will keep trying to reproduce the issue in the simple repository.

What I did (in the simple & complex app):

• Add the package <PackageReference Include="Microsoft.Extensions.Localization" Version="6.0.0-rc.1.21452.15" />
• Add the <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData> option to the project file
• Add resource files to the project with localized text
• Add a piece of JS code to the index.html to store & load the user's culture, e.g. window.localStorage['AppLanguage']
• Add the localization service builder.Services.AddLocalization()
• Load the user's culture var appLanguage = await jsInterop.InvokeAsync<string>("appCulture.get");
• Enable the culture e.g. CultureInfo.DefaultThreadCurrentUICulture = cultureInfo; etc.
• Finally, localize text e.g. @Localize["Name"] etc.

The result in the simple app (https://repos.tsommer.org/thorsten/BugWASMI18N): It works as intended. The result in the complex app: the culture gets changed. Since the corresponding satellite assembly gets not loaded, @Localize["KEY"]
returns the none-localized text. This means, though, that the configuration & detection of the resource works.

Call for help

So that I can further narrow down the troubleshooting: Can you tell me the formal criteria that Blazor uses to decide that a satellite assembly needs to be loaded? Only blazor.boot.json can serve as a basis for decision, in my opinion. Here all satellites are listed correctly. Does a name matching take place here? What are the rules if so? At which point in the code should the satellite assembly be loaded? Should it happens after setting CultureInfo.DefaultThreadCurrentUICulture = cultureInfo;?

I am appreciative of any support and advice 🙂

Further technical details

.NET SDK (reflecting any global.json):
 Version:   6.0.100-rc.1.21458.32
 Commit:    d7c22323c4

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  11.6
 OS Platform: Darwin
 RID:         osx.11.0-arm64
 Base Path:   /usr/local/share/dotnet/sdk/6.0.100-rc.1.21458.32/

Host (useful for support):
  Version: 6.0.0-rc.1.21451.13
  Commit:  d7619cd4b1

.NET SDKs installed:
  6.0.100-rc.1.21458.32 [/usr/local/share/dotnet/sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 6.0.0-rc.1.21452.15 [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 6.0.0-rc.1.21451.13 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

[Xyncgas]

London bridges falling down, falling down, falling down, all the business burning down, by china's virtus

[StefanOssendorf]

I don't get localization working at all in .Net 6 RC1. When I follow the globalization doc no localization is happening.
Heres an MWE from me: https://github.com/StefanOssendorf/MWE-CSB-Net6RC1-LocalizationBroken

[SommerEngineering]

Alright: I have continued trying to analyze the process of localization. I discovered the following issues:

• The naming of the resource file seems to be relevant for Blazor using .NET 6 RC1. Although this is not documented in my opinion. The Blazer app is named App. A resource file App.resx (App.fr.resx, App.en.resx etc.) gets loaded, and I18N.resx (I18N.fr.resx, I18N.en.resx etc.) gets not loaded.
  • Regression: using .NET 5, I18N.resx was not an issue, though.
• When adding the localization service builder.Services.AddLocalization(), the resource path seems to be mandatory. When I omit the path, it does not work. In case I added it, e.g. builder.Services.AddLocalization(options => options.ResourcesPath = "Resources"); it works.
  • Regression: using .NET 5, it works fine without any path.
• When I change the culture from en-US to e.g. fr-FR, .NET 6 RC1 tries to load the fr culture and *fr.resx resource file. This is just wrong! The culture fr-FR and fr or en and en-US are different.
  • When the project defines e.g. en-US, fr-FR, and de-DE, the entire localization system does not work
  • I have to define en, fr, and de as well in order to work with .NET 6
  • This is a regression as well: using .NET 5, de-DE would load the *.de-DE.resx resource file.
• Unlike simple test examples about localization, changing the culture in a real business app should work without reloading. With Blazor, this is basically not a problem: we define a manager that exchanges messages between the components. As soon as the user changes the culture, we send a message to the active page. The page can then call this.StateHasChanged();. I have implemented this pattern quite simply in the test repository.
  • Using .NET 6 RC1, this fails. Blazor uses only the resource file which was loaded during the boot sequence. So, when I switched to fr-FR & I reload the page, it works. When I next change to de-DE, it falling back to the default translation. With other words: Blazor does not loads the needed assembly, e.g. *.de-de.resx. Reloading the page again, it works. When you try to change back to fr-FR, it fails again etc.
  • Again, this is a regression. Using .NET 5, this works just fine without needing to hard-reload the page.

Overall, I now get the impression that Blazor in .NET 6 does not handle localization identically to Blazor in .NET 5. Migrating a complex Blazor app with globalization and localization from .NET 5 to .NET 6 seems like a gamble at this point. I wish the team can fix this before we get the final release.

Maybe it's also me and I'm doing something wrong. I would be very happy to hear any feedback.

However, I do not want to nag: I want to thank the whole team for the great work on ASP.NET & Blazor/WASM in .NET 6. You folks have really done a great job. Working with your tools and features every day is really enjoyable. The localization thing seems to be rather the exception. Otherwise, everything works wonderfully. 🙂

[SteveSandersonMS]

@SommerEngineering Thanks for the detailed investigation.

I'm trying to work out whether at least some, maybe all of these issues are the same as #35459 (comment), or whether it's a new and different issue. In your repro code I don't see any files or classes called I18N so I can't tell. Could you show in your repro code an example of a resource-related class that doesn't work?

I'm also unsure of the purpose of these lines: https://repos.tsommer.org/thorsten/BugWASMI18N/src/branch/main/BlazorWebassemblyI18n/BlazorWebassemblyI18n.csproj#L15-L28 - I haven't typically needed to add anything like that for my resx files in the past so I'm not clear on how they are involved.

[SommerEngineering]

@SteveSandersonMS Thanks for the response.

• I18N: I tested it two times:
  • First time, I removed all files from Resources and re-created it using I18N as name. It failed.
  • Second time, I manually renamed all these files (and I had to apply the re-naming inside the *.Designer.cs as well; e.g. class name, reflection etc.) It failed again.
  • Because it does not work, I have not checked this version in. Instead, I renamed it back to App.*
• Line 15 to 28: Was automatically created by my JetBrains Rider IDE (I don't use Visual Studio).
  • It gets used to automatically re-generate the file App.Designer.cs (or I18N.Designer.cs etc.) which is really just an alternative to use IStringLocalizer<App>.
  • You can see both in action:
    • Line 48 uses the IStringLocalizer<App>, which does not need the *.Designer.cs file
    • Line 28 uses the generated class. Here, R is an alias to BlazorWebassemblyI18n.Resources e.g. @using R = BlazorWebassemblyI18n.Resources; (see line 3). So, @R.App.City is the generated App class (App.Designer.cs), using the generated field City. This is possible due to the line 15 to 28 inside the csproj file.
    • To ensure, that this automatic generated class is not source of this issues, I tried already to remove it. But this does not changed anything.

[SteveSandersonMS]

Thanks for supplying the repro. I investigated and did find some issues, but not the ones you've listed.

I18N: I tested it two times

For me it worked entirely fine to call it I18N. I suspect maybe you missed some step when renaming everything to use this name. For example if you continued to refer to IStringLocalizer<App> instead of IStringLocalizer<I18N>, the code would compile but wouldn't use your resources.

the resource path seems to be mandatory

For me it worked fine without any resource path when using the generated code.

When I change the culture from en-US to e.g. fr-FR, .NET 6 RC1 tries to load the fr culture and *fr.resx resource file. This is just wrong! The culture fr-FR and fr or en and en-US are different.

I think this is a mistake in your application code. Your resource file is named App.fr-fr.resx, but it needs to be App.fr-FR.resx to match the culture name. This was also the case in 5.0 (I checked by running your sample app on 5.0) so isn't a regression or change of behavior.

Unlike simple test examples about localization, changing the culture in a real business app should work without reloading... Using .NET 5, this works just fine without needing to hard-reload the page

I don't think this has ever been the case. Blazor WebAssembly only loads the resource assemblies during the initial app startup. So if you change the culture dynamically later, you do have to reload the page to get new resource assemblies. I ran your sample app on 5.0 and it behaved the same as on 6.0 (i.e., must reload to get the new resource assemblies).

This is unavoidable because fetching anything from the network is asynchronous and takes arbitrarily long, whereas changing a thread culture is synchronous. We couldn't possibly produce the behavior you mention without somehow blocking the UI thread, which browsers do not allow.

Nonetheless your report did lead me to find two other bugs, one of which is quite serious, so thanks very much for prompting this investigation! I'll file the other bugs seperately.