Blazor WASM 中的 Resx：使用 Resx 文件的旧静态方式的“问题”是什么？

Question

[免责声明：我是一名长期的桌面开发人员，正在慢慢学习 Web 和 Blazor，所以可能是一个菜鸟问题]但是，

为什么当您尝试寻找在 Blazor 中进行本地化的最佳实践时，官方 MS 文档会告诉您（https://learn.microsoft.com/en-us/aspnet/core/blazor/globalization-localization?view= aspnetcore-5.0&pivots=webassemble）和各种博客执行以下操作：

1. 添加 NuGet 包：Microsoft.Extensions.Localization
2. 注册本地化“builder.Services.AddLocalization();”
3. 添加您的 resx 文件
4. 制作 IStringLocalizer (@inject IStringLocalizer Loc)
5. 最后在您的 razor 页面中使用以下内容：@Loc["Greeting"]

当然，上面的方法可行，但对于桌面开发人员来说，这感觉像是质量和“重构安全性”方面的巨大倒退，以及使用“魔术字符串”来引用翻译的新方法。

我已经测试过，Blazor 页面上的“旧方法”如下：

1. 添加 MyResource.resx
2. 让它使用自定义工具“PublicResXFileCodeGenerator”来制作.designer文件
3. 只需使用 MyResource.MyTranslationKey 引用翻译即可；

它有效，它是重构安全的，不需要注入或 NuGet 包...它只是有效，但尽管如此，它不是推荐的方法...我的问题是为什么不呢？缺点是什么（所有博客和文档都没有说明为什么新方法更好）

Answer 1

我认为使用有很多缺点PublicResXFileCodeGenerator，这可能导致当前关于如何在 [blazor-] 应用程序中支持 i18n 功能的建议。

\n

\n

请注意，这只是我个人提出的寻找可能导致当前建议的可能原因的列表：

\n

\n

答：Visual Studio 独占性

\n

方式如何PublicResXFileCodeGenerator似乎是 VisualStudio 独有的。如今，\xc2\xb4s 团队倾向于使用各种 IDE/编辑器来构建软件（fe VS、VSCode、Rider、WebStorm 等）。

\n

\n

至少从我过去几年的看法来看

\n

\n

使用IStringLocalizer适用于所有编辑器，甚至是记事本或 vim。

\n

B：没有默认后备

\n

通过推荐的访问翻译的方式，标记中始终会提供有用的后备。当使用生成的类型访问翻译单元时，情况并非如此。

\n

C：没有内置插值支持

\n

使用IStringLocalizer，有一种内置的、轻量级的、形式化的方式来利用插值字符串。它甚至鼓励使用此类字符串来支持手动构建此类值，这在翻译软件时被认为是不好的做法。

\n

做：

\n

@inject IStringLocalizer<DemoPage> L\n\n<h1>@L["Greetings,  {0}", userName]</h1> <!--Greetings, Arthur-->\n\n@code {\n  string userName = "Arthur";\n}\n

\n

唐\xc2\xb4T:

\n

\n<h1>@DemoPageRessources.Greeting @userName</h1> <!--Greetings Arthur-->\n\n@code {\n  string userName = "Arthur";\n}\n

\n

\n

这决定了字符串的顺序，这对于一种语言可能没问题，但对于另一种语言则不然。我猜想，当没有实际的翻译时，使用生成的类型实现这一点有点冗长，甚至可能导致运行时异常。

\n

\n