Специальные возможности
Часть 2. Структурирование ресурсов для языка по умолчанию
В предыдущем разделе мы создали лишь один файл resources.resjson в корневой папке проекта и мы отложили работу с изображениями. Следующий шаг заключается в улучшении структуры проекта, что позволит нам добавлять локализованные ресурсы для дополнительных языков, включая изображения.
Начнем со строк, выполните следующие шаги:
- папку strings в корневом разделе проекта приложения.
- В данной папке создайте подпапку, имя которой соответствует тегу языка BCP-47, заданному как язык по умолчанию в манифесте (например, en-US, fr-FR, ja-JP, или лишь базовый язык, en или ru).
- Переместите файл resources.resjson в данную папку.
Если сейчас вы снова запустите приложение, вы должны увидеть, что всё работает. Если вы вернетесь к вышеупомянутому материалу "Как именовать ресурсы, используя квалификаторы" (http://msdn.microsoft.com/library/windows/apps/hh965372.aspx), вы увидите, что загрузчик ресурсов совершенно счастлив, если вы используете квалификаторы наподобие кодов BCP-47 в качестве имен папок. Он обычно просматривает все имена папок в поисках квалификаторов, поэтому вы можете создавать более глубокую иерархию для того, чтобы сортировать ресурсы так, как вам хочется. Таким образом, вы можете сначала отсортировать ресурсы по контрасту и масштабированию, если нужно, и включить суффиксы языков в имена файлов (с использованием формата lang-<BCP-47 тег="">). Более того, вы можете создать дополнительные файлы .resjson в данных папках и делает еще некоторые интересные вещи. Смотрите врезку "Дополнительные файлы строковых ресурсов".
В любом случае, то что вы сейчас сделали, переместив ваши ресурсы в папку для языка по умолчанию, установленному в качестве резервного языкового ресурса – это то, что загрузчик ресурсов будет обращаться к ним, если он не сможет найти более подходящих ресурсов для текущего языка пользователя. Находить совпадения, это, на самом деле, сложный процесс, где загрузчик ресурсов измеряет нечто вроде "расстояния" между предпочтениями пользователя и доступными ресурсами и выбирает то, что ближе к предпочтениям. Это делает возможным выбрать, например, en-GB как более близкий к en-AU чем en-US. В общем случае, таким образом, это означает, что при поиске для конкретного языка сначала будет использованы ресурсы с квалификатором de-DE (немецкий язык), затем – следующий ближайший язык, использующий квалификатор de, а затем будет осуществлен переход к языку по умолчанию (если нет ресурсов для других языков пользователя). Короткий вывод из всего этого заключается в том, что вам всегда следует помнить о том, что идентификаторам языков, заданным в манифесте, соответствует полный набор ресурсов. Тогда, если даже вы не локализуете некоторые из этих ресурсов (например, для точного соответствия культурным особенностям), хотя бы один из таких ресурсов будет найден). Для получения полного представления по этому вопросу обратитесь к материалу "Сопоставление языков" (http://msdn.microsoft.com/library/windows/apps/jj673578.aspx) в документации.
Врезка: Дополнительные файлы строковых ресурсов
И WinRT и WinJS могут работать с дополнительными файлами строковых ресурсов (.resjson), позволяя вам, если нужно, организовывать строковые ресурсы в нескольких файлах. Например, строки с сообщениями об ошибках обычно выделяют в файл errors.resjson. Ссылаясь на строковой идентификатор, находящийся в одном из таких дополнительных файлов, всё, что нужно – использовать синтаксис
/<file> /<identifier>
вместо простого <identifier>. Этот синтаксис работает и в HTML, и в JavaScript, и в манифесте приложения. Смотрите Сценарий 5 примера "Ресурсы приложения и локализация" (http://code.msdn.microsoft.com/windowsapps/Application-resources-and-cd0c6eaa).
С файлами .resjson можно делать и еще кое-что, добавляя в их имена квалификаторы для схем высокой контрастности, масштабирования, указывающие на домашний регион, и так далее, и даже организовывать эти файлы в любой из существующих папок. Это показано в Сценарии 13 того же самого примера, где есть множество разных файлов .resjson в папке strings/scenario13, имя каждого из которых имеет вид scenario13.<qualifiers>.resjson. Так как имя папки не использует стандартных квалификаторов, вам нужно сделать кое-что еще, чтобы со всем этим работать, использовать API Windows.ApplicationModel.Resources.Core.ResourceManager (http://msdn.microsoft.com/library/windows/apps/windows.applicationmodel.resources.core.resourcemanager.aspx), но этим стоит заниматься, если вы настоящий ресурсный наркоман!
В случае с изображениями, мы уже видели, что если у нас есть папка images и размещаете в ней файлы наподобие logo.contrast-high_scale-140.png, вы можете просто ссылаться на файлы с помощью обычного относительного URI, не использующего квалификатор, наподобие /images/logo.png и загрузчик ресурсов найдёт их.
Совет. Потенциальная множественность изображений с различными вариантами масштабирования, контраста, языка, и возможное наличие других изображений (наподобие вариантов для разных направлений), имеют важное значение для пакета приложения: большее количество изображений увеличат размер пакета. Более крупный пакет в Магазине Windows может оттолкнуть некоторых пользователей от загрузки вашего приложения, особенно если они пользуются лимитированными сетями. Таким образом, нужно аккуратно оценить реальную необходимость в изображениях, которые позволят обеспечить вариации различных факторов, особенно это касается больших изображений, и оптимизировать уровень сжатия всех изображений для уменьшения размера пакета. Задайтесь вопросом, нужно ли локализовать ваш экран-заставку – обычно одно из самых больших изображений, особенно в масштабе 180%, и проверьте, хорошо ли выглядит изображение, подготовленное для масштаба в 180%, когда оно масштабируется до 140%, до 100%. Если ваш экран-заставка, другими словами – это лишь изображение с достаточным уровнем контрастности и вы используете на нём универсальное имя приложения, один файл можно будет использовать во всех случаях.
Так же обратите внимание, что нет необходимости предоставлять ресурс без квалификатора, если вы предоставляете все остальные специфические варианты, так как масштабированный вариант всегда будет иметь преимущество над обычным. В результате, ресурсы без квалификаторов в именах просто занимают место в пакете приложения, но никогда не используются.
Для подготовки к локализации, нам нужно лишь переместить изображения в папку для нашего языка по умолчанию, как мы поступали и со строками. Так как вы уже используете относительные URI для того, чтобы ссылаться на изображения (с использованием ms-appx:/// или нет), вы можете использовать любой желаемый путь к папке в качестве корневой папки для изображением. Там, создайте папку с именем, соответствующим подходящему тегу языка BCP-47 и переместите все ваши файлы для языка по умолчанию в эту папку. В приложении "Here My Am!", например, изображения находятся в папке images, таким образом, всё, что нужно сделать – это создать папку en-US в данной папке, переместить в нее все изображения, и все мои ссылки вида /images/tile.png будут продолжать работать. И потому что теперь они находятся в папке, которая соответствует языку приложения по умолчанию, они становятся резервными изображениями.
У мня есть одно изображение, maperror.png, которое расположено в папке pages/home вместе с файлом home.html, который на него ссылается. Я переместил это изображение в папку images/en-US и обновил ссылки URI соответствующим образом (но потом отказался и от него, и от taphere.png в пользу динамического рисования в элементе canvas). Вы можете, конечно, разместить изображения в любом желаемом количестве папок, учитывая, что каждая из них имеет внутри себя папки, соответствующие различным языкам. Возможно, это более удобно, однако, использовать одну корневую папку, или лишь несколько. В случае с "Here My Am!", в конце данного шага у меня было две языковых папки в проекте:
В вашем приложении, соответственно, посмотрите на ссылки на изображения в проекте. В HTML обращайте особое внимание на элементы img. В CSS обращайте внимание на стили background-image. В манифесте посмотрите на закладку Интерфейс приложения (Application UI) (логотипы, значки), на закладку Объявления (Declarations) (еще логотипы), и на закладку Упаковка (Packaging) (логотип для Магазина Windows). В JavaScript, наконец, проверьте любые URI, которые вы могли назначить свойствам элементов или CSS-стилям, так же как и те, на которые вы могли ссылаться в XML для плиток, индикаторов событий и всплывающих уведомлений.
После всего этого проверьте каждое изображение для того, чтобы определить, нуждается ли оно в локализации, включая те, которые должны быть реверсированы для использования в языках с письменностью справа налево (для этих целей вы можете использовать по одной копии для всех RTL-языков, назвав их с помощью квалификатора layoutdir qualifier; посмотрите об этом в материале "Как именовать ресурсы, используя квалификаторы" (http://msdn.microsoft.com/library/windows/apps/hh965372.aspx) ). Изображения, не нуждающиеся в локализации (возможно, изображение для плитки, логотипы, простые графические элементы, которые вы используете в макете), держите в папке резервного языка. Они будут использованы, если другие не подойдут под текущий набор квалификаторов (язык, масштаб, контраст и так далее). Полагайтесь на резервные данные, если только у вас нет других вариантов. В итоге, теперь всё готово для локализации!
Врезка: Пример "Ресурсы приложения и локализация"
Пример "Ресурсы приложения и локализация" (http://code.msdn.microsoft.com/windowsapps/Application-resources-and-cd0c6eaa) показывает множество различных сценариев того, как можно управлять локализованными ресурсами и ссылаться на них. Полезно будет потратить некоторое время на работу с этим примером, так как он использует большую часть того, о чем мы здесь говорили: графические ресурсы (Сценарий 1); строковые ресурсы в HTML, JavaScript и в манифесте (Сценарии 2-4); использование дополнительных файлов ресурсов (Сценарий 5); отправка сведений о языке на веб-сервис (Сценарий 7); комбинацию ресурсов и привязки данных (Сценарий 8); использование ресурсов с именами, содержащими дефис ((Сценарий 9); вызов и обработка изменения язка (Сценарии 10 и 6); переназначение языкового контекста по умолчанию (Сценарий11); использование WinJS для разрешения ресурсов в веб-контексте (Сценарий 12); и многомерные резервные данные ((Сценарий 13).
Создание локализованных ресурсов: набор средств для многоязыковых приложений
Примите поздравления! Благодаря всему, что мы сделали в предыдущих разделах, мы должны получить приложение, которое полностью готово к локализации. Всё, что нужно теперь сделать – получить переведенные версии ваших файлов .resjson (для строк, примите к сведению возможность разреженной локализации) и переведенные версии любых необходимых изображений.
Совет. Если у вас есть изображения, которые содержат текст, убедитесь, что у в ваших файлах ресурсов есть строки, соответствующие содержимому изображений, так как их обычно используют в качестве атрибутов alt для изображений. Делая это, вы получаете необходимый перевод для изображений в процессе локализации строк.
Если хотите вы можете просто передать ваши файлы .resjson files, вместе с изображениями, содержащими текст, переводчику или в агентство переводов и предоставить им возможность делать свою работу. Когда вы получите материалы обратно, просто создайте дополнительные папки с кодами BCP-47 в ваших папках strings и images, поместите в них данные файлы и всё будет сделано. Вы увидите подобные структуры в примере "Ресурсы приложения и локализация", о котором мы упоминали ранее.
Ручной перевод может занять много времени и немало стоить. Это, от части, потому что профессиональные переводчики не обязательно имеют инструменты для работы с файлами ресурсов, обходясь текстовыми редакторами. Им хорошо было бы иметь современные инструменты, которые помогали бы им отслеживать состояние работы по переводу и много всего еще, работать с индустриальным стандартом в виде формата XML, известным как XLIFF (XML Language Files). В итоге, это обязывает нас (и наши чековые книжки!) упростить жизнь переводчикам, даже уменьшить объем работы, позволив просматривать связанные переводы вместо того, чтобы делать всю работу с нуля.
Для того чтобы в этом помочь, Microsoft предлагает бесплатный инструмент Multilingual App Toolkit (набор средств для многоязыковых приложений) для Visual Studio 2012 (http://msdn.microsoft.com/ru-rU/windows/apps/hh848309.aspx). Как только вы загрузите и установите набор средств, загрузите ваш проект в Visual Studio и выполните команду Сервис>Включить набор многоязычных инструментов (Tools>Enable Multilingual App Toolkit). Вам нужно сделать это для каждого проекта по отдельности, потому что в этот момент набор средств создает многоязычные ресурсы для вашего приложения – в файле resources.pri даже если вы не добавляли дополнительные файлы .resjson.
Как только вы включили набор инструментов, в меню Проект (Project) добавляется команда Добавить языки переводов (Add Translation Languages). Она вызывает диалоговое окно Языки переводов (Translation Languages), как на рис. 16.5, в котором вы выбираете желаемые целевые языки. На самом верху списка будет автоматически активирована опция Псевдоязык (qps-ploc) (Pseudo Language); мы будем использовать его в следующем разделе для тестирования локализации. Это то, что обычно делают перед локализацией. Кроме того, отметьте, что многие языки отмечены логотипом "Microsoft Translator", что означает, что перевод для них можно, по большей части, выполнить автоматически, сберегая время переводчиков и ваши деньги.
Рис. 16.5. Первое диалоговое окно набора средств для многоязыковых приложений для выбора языков перевода. Слева можно видеть опцию Псевдо-язык (Pseudo Language), искусственный язык с множеством интересных символов, которые представляют нужды большинства других языков
Видео!
Ниже представлены ссылки на видеоматериалы по набору средств для многоязыковых приложений:
- "Введение в набор средств для многоязыковых приложений" (http://channel9.msdn.com/Series/Introducing-Windows-8/Introduction-to-the-Multilingual-App-Toolkit).
- "Создание многоязыковых приложений с использованием набора средств для многоязыковых приложений" (http://channel9.msdn.com/Series/Introducing-Windows-8/Build-Multi-language-apps-using-the-Multilingual-App-Toolkit), здесь говорится о создании строковых ресурсов, как мы уже обсуждали.
- "Тестирование многоязыковых приложений с использованием набора средств для многоязыковых приложений" (http://channel9.msdn.com/Series/Introducing-Windows-8/Test-Multi-language-apps-using-the-Multilingual-App-Toolkit), это видео посвящено тому, о чем мы будем говорить в разделе "Тестирование с использованием псевдо-языка" позже.
- "Локализация многоязыковых приложений с использованием набора средств для многоязыковых приложений" (http://channel9.msdn.com/Series/Introducing-Windows-8/Localize-Multi-Language-apps-using-the-Multilingual-App-Toolkit), показывает как использовать редактор набора средств, который мы скоро рассмотрим.
- "Отправка локализованного приложения в Магазин Windows" (http://channel9.msdn.com/Series/Introducing-Windows-8/Submitting-your-localized-app-to-the-Store) рассматривает особенности размещения вашего приложения на соответствующих рынках.
Как только вы выбрали нужные языки (вы можете добавить больше позднее), нажмите ОК, и набор средств создаст в вашем проекте папку с именем MultilingualResources, наполненную множеством XLF-файлов (эти файлы любят переводчики). Поначалу они будут практически пустыми, но сейчас вы увидите, для чего было создавать файл ресурсов по умолчанию. Щёлкните правой кнопкой по проекту в Обозревателе решений и выберите команду Построение (Build) или Перестроить (Rebuild), или выполните аналогичную команду меню. Благодаря этой команде будет осуществлен просмотр ваших строковых ресурсов (в том числе – любых локализованных вариантов, которые вы уже создали) и XLF-файлы будут заполнены вашими строками. В ходе этого процесса так же извлекаются ссылки на ваших изображения, не являющиеся логотипами (изображения плиток и экрана-заставки будут опущены), которые так же, возможно, нужно перевести.
Теперь, для настоящего развлечения, сделайте двойной щелчок по XLF-файлу для того, чтобы загрузить Многоязычный редактор (Multilingual App Toolkit Editor), показанный на рис. 16.6. Здесь вы можете управлять тем, какие ресурсы можно или нужно переводить, отслеживать состояние перевода. Если язык так же поддерживается системой перевода Microsoft Translator, в верхней части будет активна кнопка Перевести (Translate) для перевода отдельной записи, а так же – Перевести всё (Translate All). Нажмите последнюю кнопку и сидите, наслаждаясь зрелищем. Через некоторое время вы увидите, что набор средств перевел все строки, пометив их все состоянием Требуется проверка (Needs review), как показано на Рис. рис. 16.7.
Рис. 16.6. Многоязычный редактор (Multilingual App Toolkit Editor), XLF-редактор со встроенным машинным переводчиком
Как только перевод будет завершен, сохраните файл и закройте редактор, если хотите. Перейдите в раздел Панель управления>Часы, язык и регион>Язык (Control Panel>Clock, Language, and Region>Language) и перенесите целевой язык в верхнюю часть списка языков. Теперь вернитесь в Visual Studio и запустите приложение – и перед вами результаты первого этапа локализации, как показано на рис. 16.8. для "Here My Am!" (Обратите внимание на то, что я решил не переводить название программы, менять его чем-то, что предложит переводчик, я сохранил его английское написание из-за его уникальной грамматики).
Рис. 16.8. "Here My Am!" на хинди, с использованием машинного перевода. Такой перевод, конечно, следует проверить носителю языка. Как видите, я проверяю, есть ли у Йогананды советы относительно языка
Если вы хотите, чтобы ваше приложение обитало на окраинах и не беспокоитесь о том, чтобы отправлять в Магазин Windows приложение, над которым люди на других рынках могут посмеяться или покритиковать вас за небрежность, тогда ничто вас не останавливает от отправки приложения на такие рынки с машинным переводом, подобным этому. Если же вам больше нравятся хорошие оценки и отзывы, тогда полезно будет найти носителей языка, которые смогут проверить и исправить машинный перевод. И эти полезные люди тоже могут использовать Многоязычный редактор для работы с вашими XLF-файлами. Когда эти файлы будут проверены и возвращены к вам, импортируйте их обратно в Visual Studio, щёлкните правой кнопкой по XLF-файлу в Обозревателе проектов и выберите команду Импортировать переводы (Import Translation). Новый перевод будет включен в состав программы при следующем построении.
Работая с профессиональными переводчиками, вы так же можете использовать специальный формат XLIFF Translation, для этого щелкните правой кнопкой мыши по XLF-файлу в Visual Studio и выберите команду Отправить в перевод (Send for Translation).
Вот еще три замечания об этом процессе. Во-первых, могут быть некоторые строки или части строк, которые не нужно переводить. В Многоязычном редакторе вы можете установить параметр Подлежит переводу (Translatable) в значение Нет (No) для всей строки для того, чтобы машинный перевод не изменял её. В случае с частями строк, они будут переводиться, но вы можете отредактировать их, приведя в нужное состояние, после чего, в поле Комментарий (Comments) сделать соответствующую запись для переводчиков.
Во-вторых, набор средств для многоязыковых приложений может определить, что вы уже сделали перевод в XLF-файле, в результате команды построения проекта не переписывают переведенные строки. В то же время, он импортирует любые новые строки, которые вы могли добавить в файл ресурсов и удаляет те, которые были удалены. Изменение в идентификаторе ресурса обрабатывается как удаление и добавление, то есть, перевод строки будет потерян.
И, наконец, если вы хотите удалить язык, просто щёлкните правой кнопкой по XLF-файлу и выберите Исключить из проекта (Exclude From Project). Это исключит файл из построения проекта, но сохранит файл (и переводы) в папке проекта.