Специальные возможности
Готовность к мировому рынку и локализация
На протяжении многих лет я слышал много слов, описывающих процесс подготовки приложения к различным региональным рынкам, и я могу представить, что вы тоже это слышали: локализация, локализуемость, интернационализация, глобализация и готовность к мировому рынку. Для того, чтобы быть честным, должен заметить, что разница между этими терминами некоторое время была мне не вполне ясна, но я, наконец, нашёл отличное объяснение в довольно старой книге по настольным приложениям, которая называется "Developing International Software", Dr. International (Microsoft Press, 2003). Те же идеи выражены в материале "Глобализация: шаг за шагом" (http://msdn.microsoft.com/en-US/goglobal/bb688110). Таким образом, позвольте мне начать лекцию с простого обзора этой точки зрения.
Цель, которую мы преследуем с помощью приложений для Магазина Windows – сделать их доступными на таком количестве рынков по всему миру, которое доступно в Магазине Windows. Для того чтобы это сделать, приложение нужно написать так, чтобы оно могло приспосабливаться к любому языку и культуре, с которыми оно может столкнуться. В некоторых ситуациях вам понадобиться создавать специальную версию приложения, но, к счастью, у вас может быть одно приложение с локализованными ресурсами, которое работает на большинстве рынков. Действительно, дни одноязычных приложений прошли.
Для того, чтобы достичь этой цели, вы, сначала, должны подготовить приложение к мировому рынку. Готовность к мировому рынку подразумевает, что хотя приложение изначально поддерживает лишь один язык и культуру (весьма вероятно, ваши), оно не делает никаких предположений об этих особенностях в HTML, CSS и JavaScript (и в WinRT-компонентах). Таким образом, основное приложение нейтрально по отношению к языку, культуре и рынку, принимая во внимание следующие факторы:
- Каждая строка, которая может быть показана в пользовательском интерфейсе приложения, включая атрибуты элементов, наподобие aria-label и img.alt, выделяется в файл ресурса, таким образом, разные ресурсы могут быть загружены для разных языков. (В наши дни использование текста в формате Unicode стало привычным, поэтому отображение текста на множестве языков – это не проблема, но помните об этом, если вы осуществляете перенос на новую платформу старого программного обеспечения или используете веб-сервисы, которые могут работать иначе).
- Каждое локализованное изображение (те, которые содержат текст или содержимое, специфичное для конкретной культуры), организуются в папки, выделенные для отдельных языков, соответствующим образом названные, чтобы загрузчик ресурсов мог найти их автоматически.
- Любое форматирование и манипулирование датой, временем, валютой, используют API, которые автоматически применяют региональные настройки.
- Любые сортировки или упорядочения данных принимают во внимание язык пользователя, используя для этой цели соответствующие API.
- Не делается предположений о том, как объединяются строки; формат строк с помощью соответствующих заполнителей вместо этого включают в языко-зависимые строковые ресурсы, чтобы они могли быть локализованы.
- Веб-сервисы, которые использует приложение, могут изменяться в зависимости от расположения, по причине необходимости местной информации или соответствия региональным законам.
- Текст может быть расположен слева направо или справа налево. Вертикальное расположение текста так же возможно, но может быть реализовано в виде отдельной версии приложения, так как для этого нужен уникальный макет.
- Ввод текста работает для всех языков, данные либо поступают от клавиатуры, либо от Редактора метода ввода (Input Method Editor (IME)), что подразумевает, что вам следует избегать жёстко заданных в коде имён шрифтов, которые не имеют полной поддержки Unicode support. Полезно придерживаться типографики таблиц стилей WinJS – они имеют встроенную поддержку для, по меньшей мере, 109 языков.
- Пользователь может переключить язык во время выполнения программы и приложение должно соответствующим образом на это отреагировать.
Приложение, готовое к мировому рынку, коротко говоря, и глобализовано – с использованием API, которые учитывают региональную специфику и легко локализуемо, так как добавление поддержки для других языков не требует изменений кода, а лишь добавление новых строковых и графических ресурсов. Это больше вопрос того, как вы структурируете эти ресурсы, и как вы будете ссылаться на них в разметке и исходном коде приложения.
Процесс локализации, таким образом, это создание или приобретение подобных ресурсов, специфичных для культуры и языка, для чего существуют некоторые весьма полезные инструменты, позволяющие упорядочить работу по переводу.
В следующих разделах мы сначала рассмотрим вопросы глобализации, узнаем, как структурировать ресурсы, чтобы они были локализуемыми, и затем посотрим как работать с локализованными ресурсами. После этого мы готовы будем взглянуть на последний шаг в долгом пути создания приложения: на отправку приложения в Магазин Windows.
Глобализация
Помимо языка, в разных частях мира отличается представление даты и времени (в том числе – календари); представление чисел, мер (единиц), телефонных номеров и адресов; валют; размеров бумаги (об этом мы говорили в Главе 4); есть отличия в том, как сортируется (упорядочивается) текст; отличия в направлении текста и в шрифтах, которые используются для вывода текстов вместе с методами ввода.
Глобализация приложения подразумевает отсутствие предположений о том, как всё это реализуется, вместо этого нужно использовать API WinRT, которые сделают всё как нужно в зависимости от настроек текущего пользователя. И глобализация, преимущественно, означает работу с этими API.
Помимо использования API, посмотрите на само содержимое приложения, проверьте слова, фразы, выражения, которые может быть очень сложно перевести (или на потенциально политически оскорбительные), в особенности разговорные, просторечные, проверьте слэнг, метафоры, жаргон и так далее. Используйте изображения, понятные всем, которые вряд ли могут быть неправильно поняты где-то в мире (представьте себе, что вы носите футболку с подобным изображением в стране, где вы собираетесь продавать приложение!). Проявляйте осторожность при работе с картами, так как имеются разногласия между различными народами о том, где, в действительности, должны быть нарисованы их границы. Лучше ссылайтесь на "страну/регион", чем просто на "страну", так как спорные территории могут не иметь статуса страны.
Кроме того, учитывайте региональные законы, касающиеся экспорта и относящиеся к алгоритмам шифрования, так как вам может быть запрещено делать приложение доступным на некоторых рынках. Посмотрите материал "Ограничения на экспорт средств шифрования" (http://msdn.microsoft.com/library/windows/apps/hh694069.aspx). Кроме того, если вы пишете игру, следует помнить о региональных требованиях по оценке игр, которые могут привести к такому объему дополнительной работы, который выполнять невыгодно. Смотрите материал "Требования к публикации игр в Windows" (http://msdn.microsoft.com/library/windows/apps/hh452788.aspx).
Если вы используете веб-сервисы, убедитесь в том, что вы так же используете сервисы, которые соответствуют региональным особенностям расположения пользователя. Это может быть необходимо по закону в некоторых странах (особенно в том, что касается финансовых операций и карт) и часто гарантирует, что пользователи получают с данного сервиса информацию, соответствующую их региону, если только они не настроят приложение иным образом. Так же вам может понадобиться возможность передать данные о расположении пользователя и его языке подобным сервисам, в итоге, они смогут вернуть содержимое, которое уже локализовано. Кроме того, полезно для общей производительности приложения использовать сервера, которые сравнительно близко расположены к пользователю, чем те, которые находятся по другую сторону земного шара!
Наш первый шаг среди всего этого, однако, заключается в том, чтобы узнать, где, на самом деле, исполняется ваше приложение, узнать язык и культурные предпочтения пользователя. Поэтому давайте посмотрим, как это сделать.
Язык пользователя и другие настройки
Когда пользователь приобретает устройство под управлением Windows 8 или устанавливает Windows 8 на компьютер, она, вероятнее всего, будет настроена для страны, в которой он живет. Однако, многие пользователи говорят на нескольких языках, независимо от страны проживания и они могут захотеть работать с Windows на конкретном языке, который не имеет ничего общего с их расположением. По этой причине вам всегда следует отдельно рассматривать предпочтения пользователя от реального местоположения устройства, применяя предпочтительные настройки пользователя к тому, как ваше приложение отображает информацию, но использовать физическое расположения для управления тем, какие сервисы вы используете и другими, более функциональными аспектами.
Язык и другие предпочтения настраиваются по адресу Панель управления>Часы, язык и регион (Control Panel>Clock, Language, and Region). Здесь вы можете добавлять языки и выбирать основной (смотрите рис. 16.3.), изменять методы ввода, задавать расположение (страну или территорию) и устанавливать форматы даты, времени, чисел и валюты ( рис. 16.4.)
Хорошо, что есть API глобализации, так как иначе иметь дело со всеми возможными здесь вариантами было бы непросто! (Обратите внимание, что изменение форматов на Рис. 6.9. повлияет лишь на те приложения для Магазина Windows, которые исполняются с использованием языка, который вы настраиваете; каждый набор пользовательских форматов относится к конкретному языку).
Основные сведения об установках пользователя доступны посредством объекта Windows.System.UserProfile.GlobalizationPreferences (http://msdn.microsoft.com/library/windows/apps/windows.system.userprofile.globalizationpreferences.aspx) и через классы в пространстве Windows.Globalization (http://msdn.microsoft.com/library/windows/apps/windows.globalization.aspx). Объект GlobalizationPreferences лишь предоставляет удобные свойства. Четыре из них: calendars, clocks, currencies, и languages являются массивами строк (объектов IVectorView, если точнее), которые содержат предпочитаемые установки пользователя в порядке предпочтения.В случае с параметром languages, здесь содержится список тегов языков в формате BCP-47 (http://tools.ietf.org/html/bcp47).
Кроме того, этот объект содержит строковое свойство, которое называется homeGeographicRegion, которое является сокращением для значения, выбранного на закладке Местоположение (Location) в Панели урпавления на Рис. 6.9, и свойство weekStartsOn, которое содержит значение типа DayOfWeek (http://msdn.microsoft.com/library/windows/apps/windows.globalization.dayofweek.aspx). Сценарий 1 примера "Параметры глобализации" (http://code.msdn.microsoft.com/windowsapps/Globalization-preferences-6654eb36) получает и отображает эти данные. Возможно, вы захотите добавить в него код для отображения данных из currencies, так как данные по валюте он не предоставляет. Внеся в него эти изменения и добавив несколько языков в мою систему, я увидел следующее:
Вообще говоря, эти значения, это обычно именно то, что обычно нужно для обмена данными с веб-сервисом, если он предоставляет локализованные данные для приложения. Однако, пользовательские параметры языка лучше получать несколько иным образом, как мы скоро увидим.
Часто нужно знать больше подробностей по каждому из этих параметров, для чего мы можем обратиться к классам пространства имен Windows.Globalization. Некоторые из них являются статическими классами, которые присутствуют в API для предоставления вам строковых идентификаторов, которые вы можете использовать для выполнения сравнений в коде, не записывая строки явным образом. ClockIdentifiers (http://msdn.microsoft.com/library/windows/apps/windows.globalization.clockidentifiers.aspx), например,просто содержит два строковых свойства: twelveHour и twentyFourHour, значения которых совпадают с тем, что возвращается из GlobalizationPreferences.clocks. Похожим образом, CalendarIdentifiers (http://msdn.microsoft.com/library/windows/apps/windows.globalization.calendaridentifiers.aspx) содержит строковые значения для gregorian, hebrew, hijri, japanese, julian, korean, taiwan, thai, и umAlQura. Таким образом, если вы хотите сравнить календарь, который предпочитает пользователь с каким-то конкретным, вы можете написать такой код:
var userCalendar = Windows.System.UserProfile.GlobalizationPreferences.calendars[0];
if (userCalendar == Windows.Globalization.CalendarIdentifiers.julian) {
// ...
}
При таком подходе ваш код полностью соответствует ключевому принципу глобализации, который касается того, тчо не нужно делать предположения о том, какими могут быть строки календаря.
Другие классы, связанные с глобализацией, несколько богаче по своим масштабам и функция. Класс Language (http://msdn.microsoft.com/library/windows/apps/windows.globalization.language.aspx), экземпляр которого обычно создают с указанием конкретного тега BCP-47 tag, предоставляет такие сведения, как displayName, nativeName, languageTag, и script. Сценарий 2 вышеупомянутого примера показывает это. Класс Language так же имеет два статических члена. Один из них – это метод isWellFormed, который сообщит вам, содержит ли строка верный тег BCP-47. Второй - это свойство currentInputMethodLanguageTag, которое содержит тег BCP-47 для предпочтительного языка ввода пользователя, который может быть настроен в Панели управления, отличаясь, если нужно, от языка по умолчанию. (Смотрите ссылку Параметры (Options) в правой части Рис. 6.8; так же это показывает Сценарий 4 нашего примера).
Далее, имеется класс GeographicRegion (http://msdn.microsoft.com/library/windows/apps/windows.globalization.geographicregion.aspx), который, при создании его экземпляра без аргументов, предоставляет подробности о домашнем регионе пользователя. Вы так же можете создать экземпляр, указав конкретную строку для местоположения. В любом случае, он вернет вам displayName, nativeName, множество кодов форматов для региона (code, codeThreeDigit, codeThreeLetter, и codeTwoLetter), и currenciesInUse (массив трехбуквенныех кодов формата ISO 4217). Сценарий 3 примера коказывает эти значения для вашей конфигурации, например, так:
Класс ApplicationLanguages (http://msdn.microsoft.com/library/windows/apps/windows.globalization.applicationlanguages.aspx), в свою очередь, содержит лишь несколько значений. manifestLanguages представляет собой массив языков, определенных в манифесте приложения; вы устанавливаете их при локализации приложения. Объекты languages содержат комбинацию массива GlobalizationPreferences.languages и данных из manifestLanguages. Первый элемент в списке – это наилучшее значение для использования в приложении с учетом предпочтений пользователя, и это значение можно передать веб-сервису для целей локализации.
Далее, это свойство primaryLanguageOverride (тег BCP-47) для приложений, которые позволяют выбирать предпочтительный язык приложения (и обавлять его в смесь из параметров languages). Установив это, вы сообщаете системе, какой язык использует приложение, таким образом, оно может настроить собственный интерфейс и параметры, существующие между сеансами работы. Так как это сравнительно затратная операция, избегайте использования primaryLanguageOverride для временных целей, таких, например, как вывод нескольких элементов на другом языке. Для этого создайте новый языковой контекст и используйте его непосредственно. Смотрите документацию по Windows.ApplicationModel.Resources.Code.ResourceContext (http://msdn.microsoft.com/library/windows/apps/windows.applicationmodel.resources.core.resourcecontext.aspx) и Сценарий 13 примера "Ресурсы приложения и локализация" (http://code.msdn.microsoft.com/windowsapps/Application-resources-and-cd0c6eaa).
Последний класс, Calendar (http://msdn.microsoft.com/library/windows/apps/windows.globalization.calendar.aspx), весьма обширен и содержит слишком много членов, чтобы здесь их перечислять, многие из которых работают с форматированием или выполняют календарные расчеты. Прежде чем этим заняться, однако, давайте посмотрим шире на вопрос форматирования данных.