На Хабре не раз обсуждались вопросы локализации/интернационализации приложений, и поскольку у нас в этом вопросе накопился значительный опыт, мы решили им поделиться, сделав больший акцент на организации всего процесса. Локализация приложений — более сложная задача, чем принято считать, и подойти к ней можно разными способами: можно изначально создать простой и понятный текст, можно вложиться в крутых переводчиков, которые из любого текста вытянут смысл, можно сделать подготовку и перевод текста «как-нибудь», но посадить сообщество или тестировщиков на выверку финального результата. Необходимо только помнить, что выверка исходного текста делается на одном языке, а выверка результата — на всех языках, т. е. усилий надо затратить в N раз больше.

Вообще, локализация — это по факту открытие еще одного рынка, и понятно, что, при принятии решения о локализации, руководство рассчитывает получить дополнительную прибыль. При этом зачастую в эту самую локализацию вкладывают лишь малую часть от общего бюджета разработки (скажем, порядка 1–2 %). Т.е. расчет идет на то, что, добавив 1 %, можно получить + 50 % дохода. Насколько реалистичными могут быть такие ожидания?

Цели и объем

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

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

Говоря о переводе софта, можно выделить следующие основные типы контента:

• Строки самого приложения;
• Руководство пользователя;
• Помощь по продукту.

При переходе к каждому последующему пункту объем информации, которую надо переводить, возрастает. Само приложение может содержать 10–100 тысяч слов, различные руководства и обучающие курсы — еще 200–500 тысяч, а полная помощь по продукту — до 1–3 миллионов слов (все, конечно, зависит от проекта).

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

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

Организация процесса

Итак, допустим, выбор сделан, локализация нужна.

Сразу необходимо задуматься о том, как все будет реализовано технически. Т. е. будут ли строки извлекаться из продукта, или перевод будет идти непосредственно в исходных материалах, и т. д.

Возможные варианты (не все, конечно) для софта:

• Строки находятся непосредственно в исходном коде программы. Реализация:
  • Локализуются и хранятся сами исходники. Тогда локализованная версия собирается параллельно с основным кодом. Минусы: возможны большие затраты на поддержку билдов, самого продукта, поскольку баги необходимо исправлять в нескольких версиях — исходной и переведенных.
  • Существует специальный механизм перевода, который, используя исходную строку (возможно с дополнительным идентификатором, например, модуля программы), получает перевод на рантайме или во время сборки локальной версии. В дополнение потребуется механизм вытаскивания строк (parsing). Сам перевод может храниться как в отдельных файлах, так и в базе данных. Плюсы: можно оперативно исправлять переводы.

• Строки отделены от кода.
  Строки могут быть размещены в отдельных файлах (например, resx, po, txt и т. д.) или базе данных. В самом коде может использоваться некоторый идентификатор строки (не обязательно уникальный) и механизм локализации, выдающий перевод. Тут также можно идти двумя путями: добавлять переведенные строки на этапе билда, а можно реализовать и отдельный механизм для рантайма. Существенным отличием от пункта 1 является то, что исправлять баги надо только в самом коде.

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

Контент

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

В лучшем случае N переводчиков попросят менеджера проектов перевода (TRM) прояснить эту фразу. TRM не обязательно является специалистом по продукту: это человек, который организовывает процесс. Ему придется потратить заведомо больше времени, чтобы разобраться в ситуации, чем людям, которые непосредственно создают контент.

В худшем случае N переводчиков, чтобы не терять время, переведут фразу так, как им будет удобно. В результате придется исправлять перевод на N языках, N раз привлекая для подтверждения корректности правки не только TRM, но и тестеров. После чего N*Х клиентов потратят время, чтобы установить обновление программы.

Терминология

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

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

Строки продукта

Существует множество способов создания контента приложения. Конкретная реализация зависит от процесса разработки, способа размещения строк и других факторов.

Частая ситуация: дизайнер, общаясь с клиентом (или продакт-маркетингом), создает первичную спецификацию продукта.

Далее программист пишет код, иногда копируя названия элементов интерфейса, иногда привнося что-то свое, включая ошибки.

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

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

Добавьте еще две проблемы:

• Далеко не каждый программист (да и вообще, не каждый человек) даже на родном языке может четко и грамотно формулировать свои мысли (увы, но это так).
• Команда разработчиков варится в своей специализированной области, где им все понятно, при этом используя свой собственный жаргонный язык.

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

Большую роль играет наличие проработанного стайл-гайда (пример). И, кстати, тот факт, что существует отдел технических писателей, еще не гарантирует наличие стайл-гайда.

Рассмотрим случай, когда строки все-таки проходят какой-то контроль.

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

Аспекты проверки исходного контента

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

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

Приведенные примеры – это по смыслу одинаковые строки, но при этом их создают разные программисты в разных отделах. Вместо того, чтобы везде использовать что-то одно, у нас 10 вариантов, за перевод которых надо платить деньги.

Система Controlled Language

Один из путей решения задачи по упрощению контента — внедрение системы Controlled Language (CL). Ее основная идея состоит в унификации языка и терминологии приложения, приведении его в соответствие с разработанным стайл-гайдом компании и автоматизации проверки. При этом используется определенный набор: например, ограниченный набор слов, грамматических конструкций, ограничения на длину предложения и т. д.
Система дает следующие преимущества:

• Текст воспринимается проще, облегчается работа с продуктом, что выгодно и тем клиентам, которые используют программу на ее оригинальном языке.
• Повышается качество перевода: при переводе простого текста допускается меньше ошибок.
• Сокращается стоимость перевода: при ограниченном наборе слов, фраз и конструкций возрастает объем частичных совпадений (а также 100%-ных совпадений и повторов).
• Улучшается качество вспомогательного контента: как за счет «фундамента» в виде лучших софтовых строк, так и от непосредственного применения системы CL.
• Повышается качество машинного перевода: CL позволяет убрать многозначность, которая является одной из основных проблем, влияющих на качество МТ.

Controlled Language можно разворачивать у себя внутри, можно отдавать подрядчикам, например, просто как перевод с English на Simplified English.

Резюме

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

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

Автор: ABBYYTeam

Источник