Локализация в Agile: как Платформа перевода встраивает перевод в разработку (на примере Kaspersky)

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

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

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

• Результат. У Kaspersky (около 10 приложений, около 20 языков, релиз раз в две недели) время одного релизного цикла приложения сократилось с 84 до 14 часов, а число шагов с почти 30 до 9. Локализация перестала задерживать выход версий.

От водопада к гибкой локализации: как меняется организация перевода

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

При Agile-локализации перевод встроен в спринт: тексты переводятся небольшими порциями, а команда локализации работает рядом с разработкой. Это имеет смысл, только если сама разработка итеративна. Непрерывная локализация идет дальше: контент готов к выпуску постоянно, а перевод становится частью CI/CD без отдельной передачи и «заморозки строк».

Зачем успевать за релизом: язык продукта влияет на спрос

По данным CSA Research (8 709 потребителей в 29 странах, 2020), 76% онлайн-покупателей предпочитают товары с информацией на родном языке, а 40% не покупают на сайтах на другом языке. Исследование об онлайн-торговле, но логика та же: пока локализованной версии нет, часть аудитории теряется, и задержка перевода означает отложенный выход на рынок.

Kaspersky как пример: масштаб задачи и переход на релизы раз в две недели

Kaspersky хорошо показывает, как быстро ручная локализация перестает справляться. Команда документации и локализации ведет тексты интерфейса и справочного центра для мобильных приложений безопасности. По ее данным, это около 25 000 слов UI-текстов на приложение при примерно десяти приложениях и около 20 языков на каждое. По нашей оценке, это порядка 250 000 слов базового текста и около 200 языковых версий, которые нужно держать актуальными, причем новые строки появляются каждую неделю.

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

Задержки в Agile-локализации сводятся к пяти причинам. Данные получены из конкретного релизного цикла для приложения, то есть из одного двухнедельного цикла на все языки:

• Подготовка к переводу (8–9 часов). До первой переведенной строки команда вручную собирала тексты из веток, готовила дельту, паковала файлы, загружала их на FTP и договаривалась с исполнителями по 20+ языкам.

• Параллельные ветки и правки. Без мультиветочности дельты уходили и возвращались вручную, а правка исходного текста запускала перевод только после основного пакета (еще 8 часов). Единообразие терминов между приложениями и языками не обеспечивалось.

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

• Сборки и скриншоты. Ошибки в нетранслируемых фрагментах и неэкранированные апострофы роняли сборки (до 8 часов на сборку), а ручная съемка занимала 16–32 часа за релизный цикл и до 70 часов для функции из 40 экранов на 20 языков.

• Ресурсы чужих команд. Скриншоты требовали тестовых устройств QA и времени разработчиков.

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

Мы решили эту задачу, используя четыре принципа. Ниже описано, как они сработали в проекте Kaspersky: по каким критериям клиент выбирал платформу и как мы подключили Git.

Четыре принципа гибкой локализации

• Перевод следует за коммитом. Строки попадают на платформу автоматически, как только разработчик или копирайтер добавил их в репозиторий, без ручной сборки пакетов.

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

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

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

Как Kaspersky выбирал платформу: критерии для Agile-локализации

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

Как Платформа перевода позволила подключить Git к локализации и сохранить требования безопасности

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

Компоненты ниже перечислены в порядке движения текста, на примере проекта Kaspersky.

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

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

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

• Наше решение отвечает за управление проектами: менеджер подтверждает готовые переводы и общается с командой в чате. Все языки и проекты ведутся в одной среде.

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

• Автоматические проверки защищают нетранслируемый текст плейсхолдерами и сообщают о критических ошибках до сборки.

• Скриншот-бот делает снимки локализованных экранов функции, которые команда выкладывает на FTP-сервер для лингвистов.

Результаты проекта Kaspersky разделены на три группы: время, ручные операции и работа команды. Сравнение идет с прежним процессом клиента.

Временные показатели: 84 часа против 14 в одном релизном цикле приложения

Время сократилось в 6 раз. В шести этапах, где раньше требовалось до 8 часов (сборка, дополнительные переводы, загрузка скриншотов, согласование исправлений, обновление ресурсов и запись в Git), теперь уходит от 0,25 до 2 часов. Это операции, которые сводились к ручной передаче и ожиданию. Самый крупный остаток приходится на скриншоты: 8 из 14 часов, поэтому следующий резерв ускорения лежит в этой части процесса, а не в переводе.

Для масштаба: двухнедельный спринт — это около 80 рабочих часов одного специалиста, поэтому 84 часа на одно приложение не помещались в него даже при полной занятости, а 14 часов — меньше двух рабочих дней.

Ручные операции и работа команды: меньше передач, стабильные сборки

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

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

• Старые баги найдены. Настройки критических ошибок выявили несколько давних проблем.

• Свободные ресурсы. Больше не нужно забирать устройства у QA и отвлекать разработчиков на скриншоты.

• Качество переводов. Скриншоты открываются прямо из редактора, и переводчики видят контекст каждой строки.

Для продуктовой команды главное изменение — предсказуемость: дата выпуска больше не зависит от локализации.

Чек-лист собран из шагов, которые предпринял Kaspersky. Не все просто выполнить, но большинство снижают число ошибок. Начинать стоит, если сама разработка идет короткими итерациями.

Интеграция

• Заранее протестируйте цепочку Git — Serge — платформа управления локализацией: все строки должны доходить до проектов и возвращаться в репозиторий.

• Договоритесь с инженерами о правилах именования веток и настройте cron-задание, которое по согласованной маске находит ветки для локализации.

• Настройте парсеры Serge, чтобы переводчики видели идентификаторы строк, комментарии и ссылки на скриншоты.

• Рассмотрите Kaspresso для UI-тестов и скриншотов: ссылка на скриншот в строке автоматически попадает в комментарии платформы.

Перевод и лингвистическое тестирование

• Загрузите глоссарии на платформу, чтобы терминология была единой.

• Заранее подключите штатных лингвистов и объясните внештатным переводчикам, как работать со скриншотами, комментариями и глоссариями.

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

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

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

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

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

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