Процесс перевода

WPF --- Элементы управления WPF --- Процесс перевода

Когда вся необходимая для локализации инфраструктура готова, остается только создать соответствующие подчиненные сборки с альтернативными версиями окон (в форме BAML) и разместить их в подходящих папках. Очевидно, что для того, чтобы сделать это вручную, потребуется приложить немалые усилия. Более того, локализация обычно предполагает привлечение сторонних переводчиков для работы над исходным текстом. Понятное дело, что ожидать наличия у них навыков программирования, достаточных для того, чтобы свободно ориентироваться в проекте Visual Studio, недальновидно (да и доверять им код тоже не стоит). Из-за всего этого необходим какой-нибудь способ для управления процессом локализации.

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

• Вы помечаете в приложении элементы, которые требуется локализовать. При желании можете также добавить комментарии для того, чтобы помочь переводчикам.

• Далее вы извлекаете локализуемые детали в файл .csv (текстовый файл с разделителями-запятыми) и отправляете его переводчику.

• После получения переведенной версии этого файла вы снова запускаете утилиту LocBaml, чтобы сгенерировать необходимую подчиненную сборку.

Давайте рассмотрим каждую стадию данной локализации более подробно.

Подготовка элементов разметки к локализации

Первое, что необходимо сделать — добавить во все элементы, которые требуется локализовать, специальный атрибут Uid. Например:

<Button х:Uid="Button_l" Margin="10" Padding="3">A button</Button>

Атрибут Uid играет роль подобную той, что выполняет атрибут Name — в данном случае он уникальным образом идентифицирует кнопку в контексте одного XAML-документа. Это позволяет указать локализованный текст только для этой кнопки.

Однако существуют несколько причин того, почему в WPF используется атрибут Uid, а не значение Name: имя может быть не назначено, а устанавливаться в соответствии с различными соглашениями и применяться в коде. На самом деле свойство Name само по себе является локализуемым фрагментом информации.

Очевидно, что текст — это не единственная деталь, которую требуется локализовать. Также следует подумать о шрифтах, размерах шрифтов, полях, отступах, других связанных с выравниванием деталях, и т.д. В WPF каждое свойство, которое может понадобиться локализовать, помечено атрибутом System.Windows.LocalizabilityAttribute.

Хотя и необязательно, но атрибут Uid лучше добавить к каждому элементу в каждом окне локализуемого приложения. Это может потребовать приложения массы дополнительных усилий, однако существует инструмент MSBuild, который умеет делать это автоматически. Он используется так:

msbuild /t:updateuid LocalizableApplication.csproj

Здесь предполагается, что атрибуты Uid должны быть добавлены в приложение под названием LocalizableApplication.

Если требуется проверить, у всех ли элементов имеются атрибуты Uid (и не был ли какой-нибудь из них по случайности продублирован), можно запустить MSBuild следующим образом:

msbuild /t:checkuid LocalizableApplication.csproj

Инструмент MSBuild легче всего запускать из командной строки Visual Studio (выбрав в меню Start (Пуск) команду Programs --> Microsoft Visual Studio 2010 --> Visual Studio Tools --> Visual Studio 2010 Command Prompt), так чтобы сразу же устанавливался путь для удобного доступа. После этого можно очень быстро перейти в папку проекта и запустить MSBuild.

Генерируемые с помощью MSBuild атрибуты Uid устанавливаются в соответствии с именем элемента управления, к которому относятся. Если у элемента нет имени, MSBuild создает менее полезный атрибут Uid на основе имени класса с числовым суффиксом.

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

Извлечение локализуемого содержимого

Для извлечения локализуемого содержимого всех элементов служит утилита командной строки LocBaml. В настоящее время LocBaml не поставляется в виде скомпилированного инструмента. Вместо этого по адресу http://msdn.microsoft.com/en-us/library/ms771568(VS.100).aspx доступен ее исходный код, который должен компилироваться вручную.

Используя LocBaml, следует обязательно находиться именно в той папке, в которой содержится скомпилированная сборка (например, это может быть LocalizableApplication\bin\Debug). Чтобы извлечь список локализуемых деталей, нужно указать LocBaml на подчиненную сборку и задать параметр /parse, как показано ниже:

locbaml /parse en-US\LocalizableApplication.resources.dll

Утилита LocBaml выполняет в подчиненной сборке поиск всех имеющихся в ней скомпилированных BAML-ресурсов и генерирует файл .csv с деталями. В данном примере этот файл .csv получит имя LocalizationApplication.resources.csv.

Каждая строка в извлеченном файле представляет одно локализуемое свойство, которое применялось для того или иного элемента в документе XAML, и состоит из семи перечисленных ниже значений:

• Имя BAML-pecypca (например, LocalizableApplication.g.en-US.resources:windowl.baml).

• Идентификатор Uid элемента и имя свойства, подлежащего локализации. Например: StackPane1_1 :System.Windows.FrameworkElement.Margin.

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

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

• Значение, показывающее, можно ли значение данного свойства изменять переводчику. Всегда равно True, если только специально не указано противоположное.

• Дополнительные комментарии, которые были предоставлены для переводчика. Если комментарии не предоставлялись, это значение будет пустым.

• Значение свойства. Это именно та деталь, которая и должна локализоваться.

Создание подчиненной сборки

Теперь можно переходить к созданию подчиненных сборок для других культур. Для решения этой задачи нужна утилита LocBaml, но на этот раз ее следует использовать с параметром /generate.

Не забывайте о том, что подчиненная сборка будет содержать альтернативную копию каждого завершенного окна в виде вложенного BAML-pecypca. Для того чтобы создать такие ресурсы, утилита locbaml должна просмотреть исходную подчиненную сборку, заменить все новые значения из переведенного файла .csv и затем сгенерировать новую подчиненную сборку. А это означает, что утилите LocBaml понадобится указать на исходную подчиненную сборку и (с помощью параметра /trans:) на переведенный список значений. Ей также должна быть сообщена культура, представляемая этой сборкой (в параметре /cul:). Имейте в виду, что культуры определяются с помощью двухсоставных идентификаторов, которые перечислены в описании класса System.Globalization.CultureInfo.

Ниже показан иллюстрирующий все это пример:

locbaml /generate en-US\LocalizableApplication.resources.dll
   /trans:LocalizableApplxcation.resources.French.csv
   /cul:fr-FR /out:fr-FR

Эта команда делает описанные ниже вещи:

• Использует исходную подчиненную сборку en-US\LocalizedApplication.resources.dll.

• Использует переведенный .csv-файл French, сvs.

• Использует культуру "французский язык (Франция)".

• Помещает вывод в подпапку fr-FR (которая должна уже существовать). Хотя может показаться, что это должно выполняться неявным образом на основании используемой культуры, однако, данную деталь все-таки следует предоставлять обязательно.

При выполнении этой команды утилита LocBaml создаст новую версию сборки LocalizableApplication.resources.dll с переведенными значениями и поместит ее в подпапку приложения с именем fr-FR.

Теперь, в случае запуска данного приложения на компьютере, где для параметра культуры установлен французский язык (Франция), автоматически появится альтернативная версия окна.