Создание приложений Магазина Windows с дизайном, адаптируемым к региональным настройкам

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

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

Мы действительно говорим о языковом стандарте, представляющем настройки для локального языка, применяемые независимо от языка культурного контекста (то есть региона). Например, языковой стандарт для англоговорящих пользователей в США (en-US) отличается от стандарта англоговорящих пользователей в Австралии (en-AU).

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

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

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

Пример 1. Именование, основанное на региональных параметрах

Ситуация. Ваша компания работает в нескольких регионах. В США она называется My Contoso, Inc., но в Великобритании известна как My Contoso Ltd.

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

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

Резервирование имен приложений

На информационной панели вашей учетной записи разработчика Магазина Windows выберите Submit an App (Отправить приложение) и щелкните App name (Название приложения) наверху:

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

После этого щелкните Reserve another name (Зарезервировать еще одно название) — последняя строка на предыдущем снимке экрана. Впишите еще одно локализованное название приложения, повторите это действие для каждого нужного региона. В нашем примере мы используем My Contoso, Inc. и My Contoso Ltd.

Локализация названий в приложении

Чтобы упростить локализацию в Visual Studio/Visual Studio Express, первым делом удостоверьтесь, что у вас установлен набор средств для многоязычных приложений: http://msdn.microsoft.com/en-us/windows/apps/bg127574. Они помогут управлять локализованными ресурсами. В нашем примере название приложения — это единственный источник (строка), который мы хотим изменить.

При создании нового проекта вы увидите набор ресурсов по умолчанию, добавленных в папку /strings/<locale> проекта. В нашем примере мы используем английскую версию Visual Studio на ПК с Windows и региональными настройками en-US. Таким образом, у нас по умолчанию есть папка /strings/en-US.

Теперь мы добавим подходящий код языка в соответствии с каждым локализованным названием приложения. Выберите приложение в Solution Explorer и щелкните Tools (Инструменты) на главной панели инструментов VS, а затем пункт Enable Multilingual Toolkit (Включить набор средств для многоязычных приложений). Далее щелкните правой кнопкой мыши на название проекта в панели Solution Explorer, выберите Add translation language (Добавить язык перевода), а затем укажите региональные настройки для нужных рынков. В нашем примере мы добавим English (United Kingdom)[en-GB].

В папке /MultilingualResources появится новый файл: <project_name>_en-GB.xlf. Этот файл теперь является центром всех ваших локализованных ресурсов.

Примечание. В этой же папке ресурсов находится еще один файл — _qps-ploc.xlf. Это файл, добавляемый по умолчанию набором средств для многоязычных приложений, необходим для псевдолокализации. В нашем случае он не потребуется.

Скомпилируйте и запустите проект, чтобы заполнить XLF-файл оригинальными ресурсами на английском языке из /strings/en-US/resources.resjson.

Теперь заменим жестко запрограммированное название приложения подходящими названиями ресурсов. Отредактируйте файл resources.resjson и создайте новую запись, соответствующую названию по умолчанию:

"appTitle": "My Contoso, Inc."

Заново соберите приложение и перезагрузите ресурсы, если этого потребует программа. Настала пора добавить наши локализованные названия приложений, отредактировав файл _en-GB.XLF. Дважды щелкните файл в Solution Explorer, чтобы открыть редактор, и измените appTitle на My Contoso Ltd.

Теперь на главной странице приложения (допустим, мы использовали шаблон проекта приложения JavaScript Hub) откройте hub.html и замените название приложения по умолчанию на имя ресурса (appTitle). Замените это

<h1 class="titlearea win-type-ellipsis">
<span class="pagetitle">App1</span>
</h1>

на это:

<h1 class="titlearea win-type-ellipsis">
<span class="pagetitle" data-win-res="{textContent: 'appTitle'}"></span>
</h1>

В манифесте приложения во вкладке Visual Assets (Визуальные активы) измените жестко заданную по умолчанию метку Display name, чтобы название приложения было локализовано на Начальном экране и в Диспетчере задач. Воспользуйтесь для этого указателем ресурсов ms-resource:appTitle.

Нам нужно также немного подкорректировать стандартную опцию Default language (Язык по умолчанию) во вкладке манифеста Application (Приложение). Обычно достаточно удалить значение из пункта Default language (Язык по умолчанию). В этом случае тег ресурсов XML X-generate должен обработать языки соответствующим образом. Однако из-за текущей ошибки в инструментах Майкрософт вам придется вручную добавить текущие целевые языки в манифест. Делается это так:

1. Отредактируйте манифест в режиме интерфейса и удостоверьтесь, что в Default language (Язык по умолчанию) прописан ваш язык.
2. Отредактируйте манифест в режиме программного кода и добавьте языки, необходимые приложению:

<Resources>
  <Resource Language="x-generate" />
  <Resource Language="EN-US" />
  <Resource Language="EN-GB" />
 </Resources>

И наконец, зайдите во вкладку Packaging (Пакеты) в файле манифеста и измените Package Display Name (Отображаемое имя пакета) на ms-resource:appTitle:

Ваше приложение теперь локализовано.

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

Когда вы в итоге отправите свое приложение в Windows Store, пакет будет привязан к названиям приложений, которые вы ранее зарезервировали в своей учетной записи разработчика Магазина Windows.

Примечание. Чтобы упростить предыдущий пример, мы выбрали en-US в качестве набора ресурсов по умолчанию. По идее, при глобализации нужно задать резервный язык, который не обязательно привязан к региону. К примеру, можно указать English (без указания конкретного региона) в качестве резервного. В этом случае мы добавим папку strings\en, в которой будет размещен общий ресурс appTitle со значением My Contoso. Кроме того, нам нужно будет добавить новый язык перевода en-US для My Contoso, Inc. Благодаря этому, в случае если региональные настройки пользователя не поддерживаются приложением, по умолчанию будут использоваться ресурсы на английском языке.

Пример 2. Активы приложений, основанные на региональных настройках

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

Давайте продолжим предыдущий пример с нашим приложением My Contoso. Допустим, что на американском рынке приложение использует синий логотип и крупный шрифт синего цвета, в то время как в Великобритании — красный логотип и более мелкий шрифт. Таким образом, нам нужно создать активы, соответствующие этим рынкам.

Логотип

Как и в случае с другими локализованными ресурсами, просто создайте подпапку в /images для каждого нужного региона. В нашем примере мы используем en-US (США) и en-GB (Великобритания).

Затем поместите локализованные логотипы в соответствующие папки, используя уникальные имена для каждого файла.

При этом можно добавлять различные файлы scale-* для каждого изображения. Любые ссылки к основному имени файла, которые вы указываете в приложении (например, /images/contoso_logo.png), автоматически привязываются к нужной локализованной (и масштабированной) версии.

Стили

Для приложений на JavaScript стили расположены в файлах CSS, так что вы должны просто создать отдельный CSS-файл с подходящими стилями для каждого региона.

Пример CSS для США:

hubpage .hub .section1 {
  width: 520px;
  color:blue;

}
Пример CSS для Великобритании:
.hubpage .hub .section1 {
  width: 320px;
  color:red;

}

Затем, как и в случае с локализованными логотипами, создайте подпапки, соответствующие регионам, и поместите в них нужные CSS-файлы.

Повторите со всеми CSS для каждой фрагментной страницы приложения, где это необходимо.

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

Примечание: данный метод является более точным, чем подключение нескольких языков в одном файле CSS, о чем подробно рассказывается в статье «Как настраивать макеты и шрифты для различных языков и использовать макеты с направлением текста справа налево».

Вот результат работы приложения для рынка США:

А вот для Великобритании:

Резерв

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

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

Подведем итоги

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

У подобного подхода есть несколько преимуществ. С точки зрения конечного пользователя, предоставляется простой интерфейс, учитывающий личность пользователя. Например, по умолчанию на основе региональных настроек пользователю демонстрируются изображения, которые он понимает или ожидает увидеть. На экране больше не появятся раздражающие и мешающие работе диалоговые окна с запросами «Укажите ваш язык» или «Укажите вашу страну». С точки зрения разработчика, данный метод обеспечивает высокий уровень гибкости и масштабируемости. Приложение выпускается один раз для всех целевых рынков, с единым, простым в поддержке исходным кодом, возможностью расширения на новые рынки без изменения структуры кода или дублирования публикаций в Магазине Windows.