是否有任何理由不使用标准 resx+static 绑定来本地化 WPF？答案

【问题标题】：Is there any reason NOT to use standard resx+static binding for localizing WPF?是否有任何理由不使用标准 resx+static 绑定来本地化 WPF？
【发布时间】：2011-06-27 21:08:05
【问题描述】：

我正在寻找一种非常简单的方法来让我的应用程序本地化为日语以及默认的英语。唯一的要求是我们能够以指定的语言启动它。我们使用的是笨重、复杂、容易出错的 LocBaml 东西，这让我们的构建过程变得异常困难。

我正在考虑将所有内容移回资源文件（Strings.resx、Strings.ja.resx）并仅进行静态绑定，如下所示：

<TextBlock Text="{x:Static resx:MyWindow.MessageText}" />

然后在启动时找出他们想要的语言并切换它从哪个资源中提取字符串：

public static void Main(string[] args)
{
  if (args[0] == "-lang")
  {
    Thread.CurrentThread.CurrentUICulture = CultureInfo.GetCultureInfo(args[i + 1]);
  }

  App app = new App();
  app.InitializeComponent();
  app.Run();
}

这很简单，似乎唯一真正的缺点是我们无法在运行时切换，这不是我们想做的事情。我见过一些像这样的本地化扩展：

http://wpflocalization.codeplex.com/

http://www.wpftutorial.net/LocalizeMarkupExtension.html

它们提供更简洁的 Xaml 并且在设计时看起来更好一些，但除了允许您在运行时更改语言之外，我看不出任何功能差异。我在这里遗漏了什么，还是我们应该走简单的内置路线？总而言之，我们只有大约 100 个需要本地化的字符串。我认为这里最简单的路线是最好的，尤其是考虑到我们的应用程序相对简单。

【问题讨论】：

标签： c# wpf localization resx

【解决方案1】：

我肯定会推荐 resx 路线。我刚刚完成了一个大型 wpf 应用程序的构建，该应用程序将以多种语言本地化（目前只有 en_GB 和 it_IT，但不久将推出更多语言环境），并且运行良好。

需要考虑的一些缺点：

就像你提到的，它并不是真正的如果你想的话，很好的解决方案动态切换语言（虽然这仍然可以实现使用标记做一些工作扩展名）。
与 locBaml 方法相反你需要把资源放在你的 resx 前期增加了一个小一点开销
您几乎仅限于本地化字符串（其中 locBaml，如据我所知，你几乎可以本地化所有元素属性）

就我们而言，resx 方法的小缺点远远超过了 locBaml 的缺点。

需要注意的是，我没有在完整的构建项目中使用 locBaml 方法。我和你的情况一样，不得不调查这两种方法。事后看来，这对我们来说绝对是正确的决定。

【讨论】：

谢谢！相信我，您应该很高兴您从未在完整的构建项目中使用过 LocBaml。你知道图像是否可以用 resx 本地化吗？我认为我们永远不需要对它们进行本地化，但只要以防万一......
@Baconcheese - 我将 url 添加到 resx 中，然后让 Uri 对象使用该 url，将该 Uri 作为 ViewModel 上的属性公开并绑定 Image。

【解决方案2】：

我们使用WPF localization extension。它提供本地化字符串的运行时切换和设计时查看。

使用 resx 的好处在于它有很好的回退（例如 de-DE、de、默认资源）。 locBaml 的缺点是它使用 CSV 文件，可能会导致所有问题（例如需要转义包含逗号的字符串）。此外，在工具运行后，必须对强名称签名的程序集进行签名。

【讨论】：