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

Ste*_*man 13 c# wpf localization resx

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

我正在考虑将所有内容移回资源文件(Strings.resx,Strings.ja.resx)并只执行静态绑定,如下所示:

<TextBlock Text="{x:Static resx:MyWindow.MessageText}" />
Run Code Online (Sandbox Code Playgroud)

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

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();
}
Run Code Online (Sandbox Code Playgroud)

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

http://wpflocalization.codeplex.com/

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

它们提供了更清晰的Xaml,并且在设计时看起来更好一些,但除了允许您在运行时更改语言之外,我看不出任何功能差异.我在这里遗漏了什么,或者我们应该选择简单而内置的路线?总和我们只有~100个需要本地化的字符串.我认为这里最简单的路线是最好的,特别是考虑到我们应用程序的相对简单性.

Jam*_*Hay 7

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

需要考虑的一些缺点:

  • 就像你提到的那样,如果你想动态切换语言,它并不是一个很好的解决方案(虽然这仍然可以通过使用标记扩展的一些工作来实现).
  • 与locBaml方法相反,您需要在resx中预先放置资源,这会增加一些开销
  • 你几乎只限于本地化字符串(其中locBaml,据我所知,你几乎可以本地化所有元素属性)

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

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


Dan*_*ose 5

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

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