Поделиться через

Как подготовиться к локализации (HTML)

  • Статья

[ Эта статья адресована разработчикам приложений среды выполнения Windows для Windows 8.x и Windows Phone 8.x. В случае разработки приложений для Windows 10 см. раздел последняя документация]

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

Инструкции

Используйте файлы ресурсов и квалификаторы

Указывайте строковые ресурсы в файлах ресурсов. Подробности: Краткое руководство: перевод ресурсов пользовательского интерфейса.

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

Добавляйте контекстно-зависимые комментарии

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

Файл ResJSON позволяет использовать метаданные в полях, начинающихся с символа подчеркивания (таких как комментарии).

{
    "String"  : "Hello World",
    "_String1.comment" : "This is a comment to the localizer"
}

Локализуйте предложения, а не слова

Рассмотрим следующую строку: "The {0} could not be synchronized." (Не удалось синхронизировать {0}.)

{0} можно заменить целым рядом слов, например: "встречу", "задачу", "документ". Подобная замена возможна в английском языке, но в немецком для соответствующего предложения выполнима не всегда. Обратите внимание, что в приведенных ниже предложениях на немецком некоторые слова в строке шаблона ("Der", "Die", "Das") должны соответствовать параметризованному слову:

Английский Немецкий
The appointment could not be synchronized. (Не удалось синхронизировать встречу.) Der Termin konnte nicht synchronisiert werden.
The task could not be synchronized. (Не удалось синхронизировать задачу.) Die Aufgabe konnte nicht synchronisiert werden.
The document could not be synchronized. (Не удалось синхронизировать документ.) Das Dokument konnte nicht synchronisiert werden.

 

В качестве еще одного примера рассмотрим предложение "Remind me in {0} minute(s)." (Напомнить через {0} мин.). Использование "minute(s)" подходит для английского, но в других языках могут использоваться другие слова. Например, в польском в зависимости от контекста используются слова "minuta", "minuty" или "minut".

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

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

Правильно задавайте порядок следования параметров

В разных языках порядок следования параметров может отличаться. Для примера рассмотрим строку "Every %s %s" (Каждое %s %s), где первая подстрока %s заменяется названием месяца, а вторая подстрока %s — числом месяца. Эта строка выглядит естественно в английском языке, но после локализации приложения на немецкий язык она уже не будет выглядеть естественно, поскольку в немецком языке название месяца должно следовать за числом.

Для решения этой проблемы нужно заменить вышеупомянутую строку на "Every %1 %2" (Каждое %1 %2), чтобы порядок следования параметров можно было менять для конкретного языка.

Не допускайте излишней локализации

Локализуйте конкретные строки, а не теги. Рассмотрим следующие примеры:

Излишне локализованная строка Правильно локализованная строка
<ссылка>условия использования</ссылка> условия использования
<ссылка>политика конфиденциальности</ссылка> политика конфиденциальности

 

Включение вышеупомянутого тега <link> в ресурсы означает, что он тоже будет локализован. Причем этот тег станет недействительным. Локализовывать следует только сами строки. Теги в основном должны рассматриваться как код, не подлежащий локализации. Однако в некоторых длинных строках должна содержаться разметка для сохранения контекста и обеспечения правильного порядка параметров.

Не используйте одинаковые строки в различных контекстах

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

В одинаковых контекстах можно использовать одинаковые строки. Например, можно использовать строку "Volume" (Громкость) для обозначения как громкости звуковых эффектов, так и громкости музыки, поскольку и то, и другое отражает мощность звука. Однако не следует использовать эту же строку, когда речь идет о томе жесткого диска (hard disk volume), поскольку в этом случае контекст и значение другие и слово может быть переведено неправильно.

Еще один пример — использование строк "on" (вкл.) и "off" (выкл.). В английском языке "on" и "off" можно использовать при обозначении переключения в режим "В самолете", включения или отключения Bluetooth, а также других устройств. Для итальянского же языка перевод будет зависеть от того, что именно включается или выключается. Поэтому нужно будет создать пару строк для каждого контекста.

Также в английском языке строки наподобие "text" или "fax" могут использоваться и как существительное, и как глагол, что может привести к путанице во время перевода. Поэтому создавайте отдельные строки для обоих вариантов использования слов. Если вы не уверены, одинаковы ли контексты, для верности используйте отдельную строку.

Обозначайте ресурсы с помощью уникальных атрибутов

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

Используйте осмысленные идентификаторы ресурсов — это даст дополнительный контекст для перевода.

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

Выбирайте правильный подход к осуществлению перевода

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

Рассмотрим следующие варианты:

  • Файлы ресурсов могут быть переведены непосредственно внутри проекта. Этот вариант лучше всего подойдет для проекта с небольшим объемом строковых ресурсов, который нужно перевести на два или три языка. Это подходящий вариант для случая, когда разработчик владеет несколькими языками и готов сам организовать процесс перевода. Преимущества этого подхода: быстрота; не требуется специализированного программного обеспечения для перевода; минимален риск неправильного перевода. Недостаток: процесс не является масштабируемым. В частности, может легко теряться синхронизация между ресурсами на разных языках, что портит впечатление от использования приложения и ухудшает его обслуживание.
  • Файлы строковых ресурсов имеют текстовый формат XML или ResJSON и поэтому могут быть переведены с помощью любого текстового редактора. Затем переведенные файлы копируются обратно в проект. При таком подходе есть риск, что переводчик может случайно изменить теги XML, но зато работа по переводу происходит вне проекта Microsoft Visual Studio. Этот вариант подходит для проектов, которые нужно перевести на небольшое количество языков. XLIFF — это формат XML, специально разработанный для использования в проектах по локализации; он используется рядом переводческих компаний и поддерживается некоторыми средствами для локализации. Для создания XLIFF-файлов из других файлов ресурсов (.resw/.resjson) можно использовать набор средств для многоязычных приложений.

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

Также примите во внимание следующие рекомендации:

  • Используйте средство для локализации. Существует ряд средств для локализации, выполняющих анализ файлов ресурсов и позволяющих изменять только строки, подлежащие переводу. Этот подход снижает вероятность случайного редактирования тегов XML переводчиком. Недостаток состоит в необходимости применения во время локализации нового инструмента и процесса. Средство для локализации удобно применять для проектов с большими объемами строковых ресурсов, но с небольшим количеством языков, на которые осуществляется перевод. Подробнее см. в разделе Набор средств для многоязычных приложений.
  • Воспользуйтесь услугами компании-локализатора. Если ваш проект содержит большой объем строковых ресурсов и его нужно перевести на много языков, рассмотрите вариант привлечения компании-локализатора. Компания-локализатор может дать рекомендации по процессу и средствам локализации, а также предоставить услуги по переводу ваших файлов ресурсов. Такое решение — наилучшее, но одновременно и самое дорогое. Кроме того, в этом случае для переводимых данных увеличивается время от начала разработки до выпуска.
  • Снабжайте ваших специалистов по локализации необходимыми сведениями. Сообщайте о строках, которые могут рассматриваться и как существительное, и как глагол. Объясняйте значение специально созданных терминов, используя терминологические средства. Не допускайте грамматических ошибок в строках, избегайте двусмысленности и чрезмерного использования технических терминов, которые могут привести к непониманию.

Клавиши доступа и метки

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

<label id="theLabel" data-win-res="{accessKey: 'theLabelAccessKey'}" for="xPrinterRedirection" accessKey="L">The <u>L</u>abel</label>
<input type="checkbox" value="OFF" id="xPrinterRedirection" name="xPrinterRedirection" />

Следует добавлять комментарии такого рода: Make sure that <u>L</u> is synchronized with the access key "theLabelAccessKey"

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

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

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

  1. Добавьте "ms-resource:Appname" как отображаемое имя пакета и отображаемое имя приложения.

  2. Создайте папку ja-JP в разделе "strings" и добавьте два файла ресурсов следующим образом:

    strings\
    en-us\
    ja-jp\
        Resources.altform-msft-phonetic.resw
        Resources.resw

  3. В Resources.resw для общей папки ja-JP: добавьте строковый ресурс для Appname "希蒼".

  4. В Resources.altform-msft-phonetic.resw для японоязычных ресурсов с символами фуриганы: добавьте значение фуриганы для AppName "のあ".

Пользователь может выполнять поиск имени приложения "希蒼", используя как значение фуриганы "のあ" (noa), так и фонетическое значение (используя функцию GetPhonetic из редактора метода ввода (IME)) "まれあお" (mare-ao).

Сортировка выполняется по формату, установленному на региональной панели управления:

  • Если установлены японские региональные параметры пользователя,
    • Если включена фуригана, "希蒼" сортируется по "の".
    • Если фуригана отсутствует, "希蒼" сортируется по "ま".
  • Если установлены не японские региональные параметры пользователя,
    • Если включена фуригана, "希蒼" сортируется по "の".
    • Если фуригана отсутствует, "希蒼" сортируется по "漢字".