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

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

13 голосов
/ 15 февраля 2011

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

7 голосов
/ 15 февраля 2011

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

Некоторые недостатки для рассмотрения:

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

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

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

5 голосов
/ 15 февраля 2011

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

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

...