Есть ли причина НЕ использовать стандартную привязку resx + static для локализации WPF?

Я ищу мертво-простой способ, чтобы мое приложение было локализовано на японском языке, а также на английском языке по умолчанию. Единственное требование - мы можем запустить его на определенном языке. Мы использовали материал 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 строк, которые должны быть локализованы. Я думаю, что самый простой маршрут лучше всего здесь, особенно учитывая относительную простоту нашего приложения.

ОТВЕТЫ

Ответ 1

Я определенно рекомендую маршрут resx. Я только что закончил создание большого приложения wpf, которое будет локализовано на разных языках (в настоящее время это только en_GB и it_IT, но в ближайшее время выталкивает больше локалей), и он отлично работал.

Некоторые недостатки, которые следует учитывать:

  • Как вы упомянули, это не отличное решение, если вы хотите динамически переключаться на языки (хотя это еще может быть достигнуто с небольшим количеством работы с использованием разметки расширения).
  • В отличие от подхода locBaml вам необходимо разместить ресурсы в ваш resx upfront, который добавляет небольшой бит служебных данных
  • Вы в значительной степени ограничены локализации строк (где locBaml, as насколько я знаю, вы можете в значительной степени локализовать все свойства элемента)

В нашем отношении незначительные отступления от подхода resx намного превосходили недостатки locBaml.

Одно предостережение: я не использовал подход locBaml в проекте полной сборки. Я был в той же ситуации, что и вы, и мне пришлось исследовать оба подхода. Оглядываясь назад, это было правильное решение для нас.

Ответ 2

Мы используем расширение локализации WPF. Он обеспечивает переключение времени выполнения и просмотр времени локализованных строк.

Хорошая часть использования resx заключается в том, что он имеет хороший резерв (например, de-DE, de, default resource). Кроме того, locBaml имеет тот недостаток, что он использует CSV файл со всеми проблемами, которые могут вызвать (например, необходимость избегать строк, содержащих запятые). Кроме того, после того, как инструмент запущен, необходимо сместить строгие подписанные сборки.