Объяснение основных понятий MUI

• Необходимые условия для многоязыкового интерфейса пользователя
• Отделение исходного кода от языковых ресурсов
  • Первые дни: код и ресурсы живут вместе
  • Логическое разделение кода и локализуемых ресурсов
  • Физическое разделение кода и ресурсов
• Динамическая загрузка языковых ресурсов
• Создание приложений MUI

Необходимые условия для многоязыкового интерфейса пользователя

Основным предварительным требованием для создания приложения, совместимого с muI, для Windows Vista и за ее пределами является проектирование приложения в соответствии с рекомендациями по глобализации Windows.

Отделение исходного кода от языковых ресурсов

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

Рекомендуемое решение для приложений, совместимых с MUI, — это последний из описанных здесь способов, а именно физическое разделение исходного кода приложения и ресурсов, при этом сами ресурсы разбиваются на один файл на поддерживаемый язык для максимальной гибкости при сборке, развертывании и обслуживании.

Первые дни: код и ресурсы живут вместе

Изначально локализованные приложения создавались путем изменения исходного кода и изменения ресурсов (обычно строк) в самом коде и перекомпиляции приложений. Это означало, что для создания локализованной версии приходилось копировать исходный код, переводить текстовые элементы (ресурсы) в исходном коде и перекомпилировать код. На следующем рисунке показан код приложения с текстом, который необходимо локализовать.

Хотя этот подход позволяет создавать локализованные приложения, он также имеет существенные недостатки:

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

Сочетание этих недостатков делает это крайне неэффективным предложением и требуется более лучшая модель.

Логическое разделение кода и локализуемых ресурсов

Значительное улучшение по сравнению с предыдущей моделью заключается в логическом разделении кода и локализуемых ресурсов для приложения. Это изолирует код от ресурсов и гарантирует, что код остается нетронутым при изменении ресурсов путем локализации. С точки зрения реализации строки и другие элементы пользовательского интерфейса хранятся в файлах ресурсов, которые относительно просты в переводе и логически отделены от разделов кода.

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

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

• Хотя код и локализованные ресурсы логически разделены, они по-прежнему физически соединены в один исполняемый файл. В частности, удобство обслуживания по-прежнему проблематично, так как для одного и того же дефекта кода (идентичного во всех языковых версиях) требуется исправление для каждого языка. Таким образом, если приложение отправляется на 20 языках, исправление службы должно быть выдано 20 раз (по одному для каждого языка), даже если код исправлен только один раз.
• Эта модель не поддерживает распространение и использование многоязычных приложений. Это может стать серьезной проблемой в сценариях oem и enterprise. Например, если компьютер должен совместно использоваться двумя пользователями на разных языках, потребуется установить приложения дважды с этой моделью, а затем необходимо будет включить некоторый механизм для чередовки двух установок. При этом предполагается, что нет дополнительных зависимостей, которые препятствуют реализации даже этого сценария. На следующем рисунке показан пример одного дефекта кода, требующего двух исправлений.

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

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

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

Физическое разделение кода и ресурсов

Следующим эволюционным шагом является физическое разделение кода и ресурсов. В этой модели ресурсы абстрагируются от кода и физически разделяются в разных файлах реализации. В частности, это означает, что код может стать по-настоящему независимым от языка; Фактически один и тот же физический код поставляется для всех локализованных версий приложения. На следующем рисунке показано, что код и локализуемые ресурсы должны быть физически разделены.

Этот подход имеет несколько преимуществ по сравнению с предыдущими подходами:

• Развертывание многоязычных решений значительно упрощается. Для добавления поддержки любого языка требуется только доставка и установка нового набора языковых ресурсов для этого конкретного языка. Это особенно важно, если языковые ресурсы не все доступны одновременно. С помощью этой модели можно развернуть приложение на наборе основных языков и увеличить количество поддерживаемых языков с течением времени без необходимости изменять или повторно развертывать фактический код. Это преимущество дополнительно расширяется резервным механизмом, который позволяет частично локализовать приложения и системные компоненты на заданном языке, гарантируя, что ресурсы, не найденные на этом предпочтительном языке, "откатываются" на другой язык, который также понимают пользователи. В целом эта модель помогает облегчить значительную нагрузку, с которой сталкиваются глобальные компании при развертывании приложений на нескольких языках, так как она обеспечивает развертывание одного образа гораздо более эффективным способом.
• Повышена удобство обслуживания. Дефект кода необходимо исправить и развернуть только один раз, так как код полностью не зависит от локализации. В этой модели исправление дефекта кода при условии, что изменение не связано с пользовательским интерфейсом, гораздо проще и экономиче, чем в любой из предыдущих моделей.

Динамическая загрузка языковых ресурсов

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

Исходный код приложения, объединенный в основной двоичный файл, не зависящий от языка, может использовать ИНТЕРФЕЙСы API MUI на платформе Windows, чтобы абстрагировать выбор соответствующего языка пользовательского интерфейса для заданного контекста. MUI поддерживает это следующим образом:

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

Преимущества динамической загрузки ресурсов пользовательского интерфейса с приоритетным резервным вариантом:

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

Создание приложений MUI

В предыдущих разделах были описаны варианты разделения исходного кода от языковых ресурсов, а также преимущества использования основных API-интерфейсов платформы Windows для динамической загрузки локализованных ресурсов. Хотя это рекомендации, следует также отметить, что нет конкретного предписывающего способа разработки приложения MUI для платформы Windows.

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

В следующей таблице перечислены различные варианты проектирования, доступные разработчикам приложений, которые хотят создать приложение MUI для платформы Windows.

Параметры языка пользовательского интерфейса	создание ресурсов;	Загрузка ресурсов
Отслеживание языковых параметров пользовательского интерфейса в операционной системе${REMOVE}$	Один язык в двоичном файле разделенного ресурса (технология ресурсов MUI) -или- Несколько языков в двоичном файле ресурса без разделения	Приложение вызывает стандартные функции загрузки ресурсов. Ресурсы возвращаются на языках, соответствующих параметрам операционной системы.
	Механизм ресурсов для конкретного приложения	Приложение вызывает API MUI, чтобы получить предпочитаемые потоком языки пользовательского интерфейса или предпочитаемые процессом языки пользовательского интерфейса из операционной системы и использовать эти параметры для загрузки собственных ресурсов.
Параметры языка пользовательского интерфейса для конкретного приложения${REMOVE}$	Один язык в двоичном файле разделенного ресурса -или- Несколько языков в двоичном файле ресурса без разделения	Приложение вызывает API MUI, чтобы задать языки пользовательского интерфейса для конкретного приложения или предпочитаемые процессом языки пользовательского интерфейса, а затем вызывает стандартные функции загрузки ресурсов. Ресурсы возвращаются на языках, заданных языком приложения или системы. -или- Приложение проверяет ресурсы на определенном языке и обрабатывает извлечение собственных ресурсов из полученных двоичных данных.
	Механизм ресурсов для конкретного приложения	Приложение управляет загрузкой собственных ресурсов.