Альтернатива наследованию MarkupExtension в Silverlight - PullRequest
Новая
       27

Альтернатива наследованию MarkupExtension в Silverlight

1 голос
/ 12 сентября 2011

Я использую наследование MarkupExtension в своем приложении WPF, которое я хотел бы перенести в Silverlight.

Я сделал расширение разметки "Locale", которое можно использовать в xaml 

<TextBlock Text="{ui:Locale aRandomId,'My default translation'}" />

Фактически, это MarkupExtension связывает свойство, к которому оно применено, со строкой «Мой перевод по умолчанию» или, если найдено, с предложением, хранящимся в базе данных с именем «aRandomId».

Это MarkupExtension позволяет мне динамически изменять локаль моего пользовательского интерфейса (markupextension регистрируется на слабое событие 'LocaleChanged', которое вызывает обновление каждого связанного с ним свойства)

Поскольку мы не можем наследовать от MarkupExtension в Silverlight, я хотел бы знать, существует ли какой-нибудь механизм, который может его заменить.

Спасибо.

PS: я могу предоставить источник этого MarkupExtension, если необходимо.

Ответы [ 2 ]

0 голосов
/ 12 сентября 2011

Я знаю, что это получит много традиционных ответов, но я также хотел бы выдвинуть что-то совершенно оригинальное, что мы пытались (и успешно) делали сами для более эффективной локализации Silverlight, используя Attached Properties вместо привязки:

Ссылка: Локализация проектов Silverlight после завершения

Мы сочли ресурсы и решения для связывания утомительными и не гибкими, поскольку все они требуют установки переводов впроект (и, следовательно, нуждается в повторном развертывании приложения, когда оно изменилось).

Кроме того, выбранный язык всегда изменяется, и когда это происходит, все строки одновременно.Перенос накладных расходов на привязки для этой цели кажется безумным, когда вы можете просто перегенерировать текущую страницу, если язык меняется.

Традиционно переводы отправляются партиями и управляются языком (с уникальными ключами, примечаниями переводчика и т. Д.), Поэтомумы также нашли, что это гораздо лучше подходит для этого.

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

  • Центральный репозиторий для любого количества языков
  • Изменение языка путем загрузки новых данных (не более 200 КБ на язык в большом приложении)
  • Требуется только загрузка языка и изменение наfly
  • Поддерживает редактирование ресурсов в приложении переводчиками (требуются дополнительные формы пользовательского интерфейса).
0 голосов
/ 12 сентября 2011

Для этой цели я использую Converter и ConverterParam:

MSDN Binding.Converter

Это довольно легко сделать, но вы чувствуете себя очень наглядно, когда в вашем приложении их много.

Обновление: Может быть, я слишком усложняю ваши потребности ... В моих приложениях у меня есть два шаблона использования: один с конвертером и один без. В простейшем случае я просто хочу получить строку для локализованного словаря, и она выглядит следующим образом: 

Text="{Binding Localization[my_string_key], Source={StaticResource ViewModelLocator}}"
...