是否有任何理由不使用标准的resx +静态绑定来本地化WPF?

时间:2011-02-15 19:45:49

标签: c# wpf localization resx

我正在寻找一种简单的方法来将我的应用本地化为日语以及默认的英语。唯一的要求是我们能够以指定的语言启动它。我们使用的是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个需要本地化的字符串。我认为最简单的路线在这里是最好的,特别是考虑到我们应用程序的相对简单性。

2 个答案:

答案 0 :(得分:7)

我肯定会推荐resx路线。我刚刚完成了一个大型wpf应用程序的构建,该应用程序将以各种语言进行本地化(目前只是en_GB和it_IT,但很快就会推出更多的语言环境)并且它运行得很好。

需要考虑的一些缺点:

  • 就像你提到的那样,它并不是真的 如果你愿意的话,这是一个很好 动态切换语言 (虽然这仍然可以实现 使用标记做了一些工作 扩展)。
  • 与locBaml方法相反 你需要把资源放进去 你的resx前期增加了一小部分 有点开销
  • 你几乎受到限制 本地化字符串(其中locBaml,as 据我所知,你可以这么做 本地化所有元素属性)

在我们方面,迄今为止resx方法的小幅缩减胜过了locBaml的缺点。

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

答案 1 :(得分:5)

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

使用resx的好处是它具有良好的后备(例如de-de,de,默认资源)。此外,locBaml的缺点是它使用CSV文件,其中包含可能导致的所有问题(例如需要转义包含逗号的字符串)。此外,必须在工具运行后重新签名强名称签名的程序集。