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


localization c# wpf resx
person Stevoman    schedule 15.02.2011    source источник

Ответы (2)


arrow_upward
7
arrow_downward

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

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

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

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

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

person James Hay    schedule 15.02.2011
comment
Спасибо! Поверьте мне, вы должны быть очень рады, что вам никогда не приходилось использовать LocBaml в проекте полной сборки. Вы знаете, можно ли локализовать изображения с помощью resx? Не думаю, что нам когда-нибудь понадобится их локализовать, но на всякий случай ... - person Stevoman; 15.02.2011
comment
@Baconcheese - я бы добавил URL-адрес в resx, а затем использовал бы этот URL-адрес для объекта Uri, выставил бы этот Uri как свойство в ViewModel и привязал к нему Image. - person James Hay; 15.02.2011

arrow_upward
5
arrow_downward

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

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

person Daniel Rose    schedule 15.02.2011