Непрерывная локализация программного обеспечения: как настроить локализацию через Git (на примере Xsolla)

• Проблема. Релиз раз в две недели, 8 продуктов и до 21 языка: управление проектом занимало больше времени, чем сам перевод.

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

• Решение. Строки хранятся в Git, Serge автоматически забирает новые, отправляет на платформу и возвращает готовые переводы в репозиторий.

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

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

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

• программное обеспечение и игры, где новые строки появляются в каждом релизе;

• руководства пользователя и API-спецификации, включая сгенерированные автоматически;

• сайты и блоги на генераторах статических страниц;

• любые проекты, где контент создается по гибкой методологии.

Xsolla — глобальный дистрибьютор и издатель видеоигр, который предоставляет разработчикам инструменты для расширения аудитории. У компании 8 ключевых продуктов, релиз раз в две недели и от 6 до 21 языка на каждый продукт. По нашей оценке, это от 48 до 168 комбинаций «продукт — язык» в каждом релизном цикле. Каждый релиз приносит новый контент, и его нужно локализовать за считаные дни.

Раньше Xsolla использовала разные онлайн-платформы для перевода и была ими недовольна. Локализационный инженер Наталья Павликова описывала это так: локализация нескольких новых строк на 20 языков требовала больше управления проектом, чем перевода. Требования команды к новому решению были конкретными:

• автоматически забирать локализуемый контент из репозитория;

• сделать процесс прозрачным и гибким;

• отправлять локализованный контент обратно в репозиторий.

Xsolla построила процесс на связке нашего решения и Serge — инструмента с открытым исходным кодом, который отвечает за извлечение строк и генерацию ресурсов. Наше решение хранит проекты и память переводов и дает единую среду для работы с документами.

Локализация через Git: шесть шагов от коммита до релиза

1. Разработчики Xsolla обновляют файлы проекта в Git.

2. Serge отслеживает репозиторий, извлекает строки из обновлений, создает из них PO-файлы и отправляет на платформу.

3. Менеджер по локализации распределяет непереведенные строки между переводчиками команды.

4. Переводчики переводят и отмечают документы выполненными.

5. Serge забирает готовые строки, возвращает их в исходные файлы и отправляет в репозиторий Git.

6. Разработчики публикуют релиз вместе с локализацией.

Управление строками локализации: что делает Serge

Serge не просто конвертирует форматы. Это конвейер обработки и синхронизации файлов, который можно настроить под разные процессы:

• локализованные ресурсы сохраняют ту же структуру, что и исходные;

• если исходный файл меняется, пока старая версия еще переводится, Serge обрабатывает такие случаи сам, и инженерам не нужно вручную объединять изменения;

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

• он работает непрерывно, и обновленные ресурсы появляются в течение минут, поэтому сборки не падают из-за устаревших строк;

• PO-парсер привязывает каждый сегмент к идентификатору строки, поэтому при повторном импорте обрабатываются только измененные строки.

• Git хранит исходные строки и принимает готовые переводы.

• Serge следит за репозиторием, извлекает строки, создает PO-файлы, передает их на платформу и возвращает переводы в исходные файлы.

• Наше решение управляет проектами и памятью переводов и распределяет задачи.

• Команда переводчиков Xsolla переводит строки. Для критичного контента подключают дополнительных лингвистов-корректоров.

• Релиз выходит вместе с локализацией, а не после нее.

Результаты Xsolla описывает качественно, без цифр:

• Менеджеры проектов и разработчики. Каждый занимается своим делом: менеджерам не нужно пересылать и конвертировать файлы, это делает Serge.

• Ветки. Разработчики создают новые ветки, объединяют и откатывают их, а связка в фоне локализует строки именно той ветки, с которой работают.

• Качество. Постоянная команда переводчиков сохраняет единый голос продукта, а для самых важных текстов можно подключить еще корректоров.

Вывод: при релизах раз в две недели и десятках комбинаций «продукт — язык» ручное управление строками стало бы постоянной задачей. После настройки интеграции эта нагрузка перешла на автоматику.

• Храните локализуемые строки в системе контроля версий. Если их там нет, начните с переноса.

• Сформулируйте требования до выбора решения: автоматическое получение строк, прозрачный процесс, возврат результата в репозиторий.

• Запустите Serge на своих серверах, чтобы платформа не получала доступ к закрытым репозиториям.

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

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

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

• Соберите всех участников в одной среде: разработчиков, редакторов, менеджеров проектов и инженеров по качеству.

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

• Заведите память переводов, настройте правила предперевода и подключите память как источник.

• Добавьте глоссарии в интерфейс: переводчикам не нужно искать термины во внешних файлах.

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