Resx in Blazor WASM: What is "the issue" with the old static way of using the Resx Files?

Viewed 179

[Disclaimer: I'm a long-time Desktop developer slowly learning Web and Blazor, so might be a noob question] but,

How come, when you try to find best-practice for doing Localization in Blazor you are told from official MS Docs (https://docs.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view=aspnetcore-5.0&pivots=webassembly) and various blogs to do the following:

  1. Add NuGet Package: Microsoft.Extensions.Localization
  2. Register localization "builder.Services.AddLocalization();"
  3. Add your resx Files
  4. Make IStringLocalizer (@inject IStringLocalizer Loc)
  5. And finally use the following in your razor pages: @Loc["Greeting"]

Sure above works, but to a Desktop developer, this feels like a massive step-back in quality and "refactor-safeness" and the new way to use "magic strings" to reference the translations.

I've tested, and the "old way" on a Blazor Page of just:

  1. Adding a MyResource.resx
  2. Let it use the custom tool "PublicResXFileCodeGenerator" to make the .designer file
  3. Simply reference the translation using MyResource.MyTranslationKey;

It works, it is refactor-safe, no need for an injection or NuGet packages... It just works, but despite that, it is not the recommended way... My question is why not? What is the drawback (all the blog and documentation fail to say why the new way is better)

enter image description here

0 Answers
Related