Локализация приложений. Перевод и поддержка многоязычных приложений

Авторы: Таратин Михаил, Марков Сергей

Источник

Введение

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

Процесс локализации можно разбить на нескольких основных этапов: подготовка программы к локализации, перевод ресурсов, поиск и исправление ошибок. Рассмотрим их подробнее.

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

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

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

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

Но не все так плохо! Для упрощения процесса локализации были созданы специальные инструментальные средства, которые позволяют автоматизировать многие типичные задачи и значительно снизить затраты на локализацию. В данной статье будет рассмотрено применение одного из средств для локализации – Lingobit Localizer (www.lingobit.com).

Lingobit Localizer

Хотя Lingobit Localizer поддерживает несколько платформ (.NET, Visual C++, Borland Delphi и CBuilder, Java resource bundle), для примера возьмем небольшое приложение на MFC. Локализация приложений на других платформах осуществляется похожим образом. Добавим в тестовое приложение все стандартные ресурсы пользовательского интерфейса: диалоги, меню, панели инструментов, строки, форматные строки, изображения.

Создадим проект Lingobit Localizer и добавим туда скомпилированные файлы из локализуемого приложения. В качестве оригинального языка выберем “English – United States”, а в качестве целевого “Russian – Russia”. После создания проекта в левой части экрана появится навигационная панель, отображающая иерархию ресурсов доступных для локализации. В правой части появится таблица для редактирования переводов.

Рисунок 1. Рабочая среда проекта локализации

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

Теперь, когда изменения внесены, настало время проверить, как будет выглядеть приложение после перевода. Для этого достаточно вызвать команду Run Localized.

Этап №1: Подготовка к локализации

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

Прежде всего, необходимо решить следующие задачи:

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

К счастью, для автоматизации этих задач создан мастер псевдопереводов Pseudo Translate. Например, можно дописать в начало всех строк истинно русскую букву Ё или заменить букву a на a. Теперь, после запуска программы, вы уж точно не пропустите ни одного непереведенного элемента.

Рисунок 2. Программа после применения Pseudo Translation.

При попытке выполнить команду Register приложение аварийно завершается, несмотря на то, что оригинальное приложение работало без сбоев. Необходимо разобраться, какой из переводов был причиной ошибки. Чтобы найти этот элемент, можно изучить код под отладчиком, но этот способ требует наличия исходного кода и программиста, а прибегать к помощи разработчика переводчик или менеджер по локализации должен только в крайнем случае. Поэтому остается лишь один путь – поочередное отключение переводов и проверка корректности работы программы. На большом проекте это была бы огромная работа, но, к счастью, для автоматизации этой задачи существует инструмент Crash Finder. Он осуществляет бинарный поиск некорректных переводов, запрашивая о наличии ошибки при каждом запуске. Очень полезная функциональность, особенно если необходимо обнаружить ошибку в проекте, содержащем несколько тысяч элементов. Ведь для этого понадобится всего лишь около десяти запусков! Итак, воспользуемся Crash Finder для поиска подлого перевода.

Рисунок 3. В процессе работы Crash Finder.

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

Этап №2: Перевод ресурсов

Перевод дополнительных элементов

Кроме перевода строк и изменения координат элементов диалога, возможно, понадобится изменение и других данных. Хотя изменение картинок и иконок при локализации считается пагубной практикой, иногда этого не избежать. Для перевода бинарных данных (рисунков и т.п.) можно воспользоваться возможностью работы с внешними файлами. Для этого нужно выбрать элемент в таблице переводов и в контекстном меню вызвать команду «Save Original Data» или «Load Translated Data». После этого файл можно отредактировать внешними средствами и загрузить их обратно, но уже как перевод. Кроме того, иногда оказывается необходимым изменение параметров Version Info, в которых указывают язык программы.

Взаимодействие с переводчиками

Каждый из нас должен заниматься своим делом, программист – программировать, переводчик – переводить. Особенно, если это касается перевода на не особо привычные в нашей стране языки, например, китайский. Для столь разумного разделения труда необходимо обеспечить взаимодействие и обмен информацией между всеми участниками процесса. Для этого существует Exchange Wizard. Он позволяет отослать задание переводчикам в виде файла проекта или интегрированного дистрибутива, который содержит специальную версию программы для переводчика и файл проекта. Благодаря тому, что проект включает в себя все необходимые для перевода данные, нет необходимости посылать переводчику исходные тексты или даже бинарные файлы вашего приложения. После того, как переводчик закончит свою работу, можно будет интегрировать его переводы в основной проект.

Повторное использование переводов

Перевод дубликатов (Translate Duplicates)

Есть ли среди читателей журнала любители переводить кнопку Cancel во всем приложении? Никому не хочется делать одно и тоже действие множество раз. Как раз для этой задачи, можно воспользоваться функцией Translate Duplicates, которая переводит повторяющиеся строки во всем приложении.

Translation Memory

Если у вас уже есть перевод некоторых терминов, можно им воспользоваться при переводе новой программы. Translation Memory в Lingobit Localizer обладает функциональностью импорта/экспорта данных в множестве форматов. В частности, поддерживаются любые текстовые файлы и файлы в формате TMX. TMX (Translation Memory Exchange) – это недавно принятый стандарт для обмена переводами между приложениями для автоматизированного перевода. Так, например, вы можете передать набор переводов из одного проекта в другой, или импортировать переводы из словарей Microsoft, использованных для локализации Windows, Office и многих других продуктов.

Этап №3: Проверка перевода

Теперь, когда перевод ресурсов закончен, настало время проверить корректность перевода. Конечно же, можно посадить за это дело тестера и попросить его перепроверить всю программу, но многие из ошибок можно заметить, даже не запуская приложение. Например, легко забыть пробел в конце или начале перевода, если он был в оригинале, или указать одинаковые мнемоники в меню или даже обнаружить строки, выходящие за граница элемента диалога. Чтобы отыскать подобные ошибки, можно использовать механизм Validation. Он предоставляет обширный набор проверок, что позволяет выявить большинство стандартных ошибок переводчика, понимание которых чуждо нетехническому разуму. Итак, проверим проект.

Рисунок 4. Список проверок Validation.

Как видно из рис. 5, многие из этих ошибок трудно заметить при переводе, но легко обнаружить с помощью Validation.

Рисунок 5. Результаты работы Validation.

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

Этап №4: Поддержка многоязычного приложения

Допустим, что когда мы выпустили перевод и разослали дистрибутивы на множестве языков по всему миру, разработчики решили немного изменить интерфейс приложения, и теперь необходимо обновить переводы на все языки. Это была бы огромная по трудоемкости задача, если бы не Scan for Changes. Эта функция производит сопоставление новой версии приложения с предыдущей (переведенной), в зависимости от соответствия выставляет статусы для каждого из элементов и переносит переводы в новую версию. Механизм действует по следующему принципу: если элемент не изменился, статус останется прежним, и перевод будет сохранен полностью. В случае, когда можно провести только приблизительное соответствие, элемент получит статус «Updated», и тоже сохраняет свой перевод, но впоследствии такие элементы надо будет перепроверить. Переводы элементов, для которых не было найдено соответствия, будут удалены, а новые элементы, которые появились только в последней версии, получат статус «New».

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

Рисунок 6. Результаты работы Scan for Changes

Проверив элементы со статусом «Updated» и переведя элементы со статусом «New», можно выпускать переводы для следующей версии. Не правда ли, просто! Те, кто пробовал поддерживать актуальность переводов вручную, поймут меня.

Другие аспекты локализации

Управление проектом локализации

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

Тут на помощь придет система управления статусами. Перевели элемент – получаем статус In Process, отправляем на проверку коллеге – ставим For Review, закончили перевод – ставим Complete и т.д. Идентифицировав состояние перевода, можно включить фильтрацию по статусам или проверить ход проекта, изучив статистику.

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

Рисунок 7. Сравнение двух версий проекта.

Переход с других способов локализации

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

Интеграция в систему сборки

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

Заключение

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