Как выпускать продукты непрерывно на 20 языках и не умереть?

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

Кто мы

Привет всем! Мы — Екатерина Галицкая и Дарья Егорушкина из «Лаборатории Касперского» (отдел документации и локализации). Немного конкретнее: команда, в которой мы работаем, отвечает за написание и локализацию текстов интерфейса и справки для мобильных приложений.

Боли

Основным триггером изменений стали потребности разработки. Разработка перешла на частые релизы раз в две недели. Скоуп уменьшился, но переводить стали чаще, и надо было делать это быстрее. По сути, локализация стала узким горлышком разработки. И если раньше менеджеры проектов даже не знали имен локализаторов — а зачем вообще, ведь переводы волшебным образом появлялись сами, — то теперь практически все были в курсе проблем и даже знали, что такое лингвистическое тестирование :)

Исходные данные.

Сроки

Локализационный цикл занимал 3 недели:

• 3-5 дней — перевод;
• 2 недели — лингвистическое тестирование.

С переводом все понятно, а зачем лингвистическое тестирование, и что это вообще такое?

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

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

Объемы

Бытует миф, что если приложение мобильное, то оно маленькое, и что там переводить?
Ха-ха. Немного статистики:

• тексты в интерфейсе — в среднем 25 тыс. слов в проекте;
• 10 приложений;
• в среднем 19 локализаций в каждом проекте;
• обновление текстов в интерфейсе, перевод документации каждую неделю.

Почему не могли ускориться?

Посмотрим, из чего состоял каждый из этапов локализации. Этап перевода (9 шагов):

1. забрать из VCS вручную из разных бранчей;
2. вручную сформировать дельту на перевод;
3. создать пакеты на перевод;
4. выгрузить на FTP;
5. написать кучу писем агентствам, фрилансерам и локальным офисам;
6. после перевода забрать с FTP, загрузить в CAT, проверить;
7. выложить в VCS — не запутаться в бранчах;
8. запустить сборку, поправить ошибки, пересобрать сборку;
9. запустить допереводы и багфиксы в тех случаях, когда процесс перевода надо было запускать заново.

Проблемы этапа перевода: если коротко, то — ограничение старых процессов и много рутинной работы при использовании старых CAT:

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

Этап лингвистического тестирования (19 шагов):

1. Запустить сборку и дождаться ее.
2. Перезапустить, если сборка упала по вине локализационных ошибок.
3. Настроить специальную среду, если нет дебаг-меню.
4. Снять скриншоты по плану для одного языка.
5. Повторить для 20+ языков.
6. Уточнить у тестировщиков, как сделать неполучившиеся скриншоты.
7. Сформировать пакеты — переименовать скриншоты.
8. Выложить на FTP.
9. Поставить задачу агентствам.
10. Ответить на вопросы агентств.
11. Принять задачу.
12. Внести правки.
13. Собрать билд и дождаться его (иногда сборки могут долго стоять в очереди).
14. Пересобрать билд в случае ошибок.
15. Снять скриншоты для регресса (это скриншоты с подтверждением, что изменения внесены).
16. Сформировать задачи агентствам.
17. Выложить на FTP.
18. Списаться с агентствами.
19. При необходимости (например, если был доперевод) пройти еще круг регресса.

Проблемы этапа лингвистического тестирования: ручное снятие скриншотов занимало львиную долю времени. Если в фиче примерно 40 экранов, а языков 20, то это могло доходить до 70 часов ручного скриншотинга…

Помимо этого был и человеческий фактор.

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

Надо было искать решение, и при этом довольно быстро. Какие были варианты решения? Можно было:

• нанять больше студентов;
• сокращать количество локализационных работ (а значит, просаживать качество);
• автоматизировать рутинные задачи.

Мы остановились на последнем.

Что хотелось

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

Какие еще у нас были требования:

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

Из разных вариантов пристальнее всего мы рассматривали Zing (сервис переводов от разработчиков Evernote).

Из плюсов:

• кастомизируемость под себя;
• бесплатный installation pack — нужны были только серверные мощности;
• нет абонентской платы;
• подключение своих переводчиков;
• закрытый доступ (может хоститься внутри компании).

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

Что выбрали

Поскольку нам нельзя напрямую подключать CAT-систему к внутренней системе контроля версий, нужен был другой коннектор. Можно написать самим либо взять имеющийся. Так мы протестировали связку Git — Serge — Smartcat.

Из плюсов:

• Поддержка работы с несколькими бранчами.
• Обновление ресурсов на лету.
• Независимость от парсеров CAT (написание конфигурационных файлов на нашей стороне). В Smartcat уходят PO-файлы.
• Переписка с фрилансерами практически «в одном окне».
• Есть поиск и подбор фрилансеров (общение напрямую, подбор под нужды проекта — в нашем случае важна скорость и качество перевода).
• Можно оплачивать работы по всем языкам и проектам одним счетом.
• По нашей просьбе подняли приоритет в разработке новых фич: внедрили новые фичи (поиск текста по всем файлам проекта и т. д.), пофиксили некоторые проблемы.
• Быстрый техсаппорт — помощь в настройке.
• Фактически бесплатный вход в сервис (подписка опциональна).
• Проверки.

Минусы:

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

Что сделали и как стало

Кратко — поменяли процесс работы с текстами интерфейса :) Что сделали:

• Протестировали связку Git — Serge — Smartcat.
• Договорились с разработчиками о правилах именования бранчей для писателей и локализаторов (это нужно, чтобы удалить переписку с разработчиками, а также, чтобы настроить правила для локробота).
• Перевели три сложных проекта на новое решение (каждый по 25 тысяч слов на язык — это чисто тексты в интерфейсе, 20+ локализаций).
• Залили глоссарии в Smartcat, создали конфиги для Serge.
• Подключили внутренних лингвистов и агентство.
• Допилили парсеры на стороне Serge: лингвисту на этапе перевода видны ID сегмента, комментарии к сегменту, ссылки на референсные скриншоты.
• Запустили cron, который находит бранчи по маске на локализацию и редактуру сорсового (английского) языка.
• Пропилотировали перевод онлайн-справки (успешно).
• Провели первый набор фрилансеров, обучили нашему процессу работы: перевод с использованием скриншотов, комментариев, глоссария.
• Поддержан Monorepo: разработаны новые конфигурационные файлы для Serge с учетом автоматического поиска файлов на локализацию по монорепозиторию.
• Наши разработчики внедрили фича-скриншотинг на базе фреймворка Kaspresso. Это позволило решить не только проблему с автоскриншотингом^*, но и сделать контекст для переводчиков. Так, для каждой новой строки в файле добавляется ссылка на скриншот, чтобы понять, где и как используется эта новая строка. Когда файл с новыми строками «улетает» в Smartcat, ссылки на скриншот попадают в поле «Комментарии к сегменту».

Как теперь выглядит локализация (9 шагов на все):

1. Писатель коммитит новые строки в Git. Строки автоматически обрабатываются и «улетают» в Smartcat.
2. Локализатор назначает переводчиков (этот шаг скоро уйдет, правда же, ребята из Smartcat?))))
3. Переводчики переводят не просто так, а со скриншотами — то есть в контексте.
4. Локализаторы проверяют перевод (делают complete file). Робот берет обратно перевод не по строке, а когда работа над всем файлом закончена. Перевод автоматически улетает обратно и сабмитится в Git.
5. Локализаторы запускают автоскриншотинг.
6. Локализаторы выкладывают скриншоты на FTP.
7. Локализаторы отвечают на вопросы лингвистов.
8. Локализаторы при необходимости вносят правки в Smartcat. Правки автоматически коммитятся в Git.
9. Локализаторы закрывают pull request.

Конечно, есть еще поле для автоматизации и улучшений. Но уже можно почувствовать разницу с тем, что было сначала.

Что такое Serge

Это opensource-решение, коннектор между системой контроля версий (SVN, Git, Gerrit (Git-based code review system), Mercurial) и TMS, в нашем случае Smartcat.

Почему нам «зашел»: у всех облачных TMS есть коннектор из «коробки». Но такие коробочные коннекторы подключаются к репозиторию напрямую. Что в нашем случае невозможно. Какие есть варианты:

• раскрывать часть системы контроля версий;
• клонировать папки с ресурсными файлами в открытый доступ;
• получать и обрабатывать ресурсные файлы до отправки в TMS, потом экспортировать в TMS.

Раскрывать часть системы — рискованно.

Делать клон — можно, только для этого нужны временные и людские ресурсы.

Serge же как раз умеет получать ресурсные файлы и обрабатывать их до отправки в TMS. В итоге архитектура такая: Git — Serge — TMS.

Serge забирает файлы из Git и обрабатывает их по определенным правилам. Дальше конвертирует их в формат PO и отправляет в Smartcat. Serge получает переведенные PO-файлы из Smartcat, преобразует их и коммитит в Git.

Также для нас большой плюс Serge, что он развернут у нас внутри компании. Таким образом, вся «кухня» остается за каменной стеной. Ничего секретного не выходит наружу :)

Основные функции:

• Соответствие сорс-таргет по файлу и ID ресурсной строки.
• Возможность отбирать файлы по маске в пути или по содержимому.
• Обработка содержимого ресурсных файлов до/после парсинга.
• Настройка парсеров.

С другими фичами Serge можно познакомиться на сайте или посмотреть ролик.

Итоги

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

Результаты и цифры

Этап	Сколько часов было (2018)	Сколько часов стало (конец 2019)
Собрать строки со всех бранчей. Вручную	1	0
Получить только новые или измененные строки на итерацию, загрузить в старую CAT-тулу для 20 языков	4	0,25
Создать пакеты на перевод. Повторить для 20 языков.	0,5	0
Поставить задачи агентствам/переводчикам. 1 язык = 1 агентство.	2	0
Загрузить пакеты с переводами на FTP для каждого языка. Повторить для 20 языков.	0,5	0
Списаться, получить подтверждение от агентства/переводчика, что задача взята. Повторить для 20 языков.	2-3	0
Ответить на вопросы переводчика. Повторить для 20 языков.	2-4	0,5
Принять перевод для каждого языка	1	0,25
Запустить билд	< 8 (правка багов из старой CAT-тулы)	0,25
Доперевод (повторить все вышеуказанное)	8	0,25
Получить скриншоты	16-32 (сами вручную)	8 (автоскриншотилка)
Выложить на FTP	8	1
Списаться с агентством/фрилансерами	8	1
Внести правки в ресурсы	8	2
Залить изменения в Git	8	0,25
Чистого времени	84	14

Бонусы:

• Сборки не падают: переменные, непереводимые слова вынесены в плейсхолдеры, апострофы экранируются на этапе применения парсеров.
• Не отбираем девайсы у тестировщиков.
• Не тратим время разработчиков, тестировщиков, чтобы пофиксить сборку или разобраться, как снять тот или иной скриншот.
• Перевод в контексте: английские скриншоты есть уже на этапе перевода, и их ЛЕГКО открыть и просмотреть.
• Smartcat дает возможность выносить в критическую ошибку непереведенные сегменты — нашли некоторые бажные строки из старой CAT.

В дополнение связка Git — Serge — Smartcat позволила перевести работу UX-писателей в Smartcat. Как мы это сделали, расскажем в следующей статье :).

*Подробнее про автоскриншотинг: наши коллеги писали автотесты и создали Kaspresso — фреймворк для автотестирования. Как раз на нем сделан автоскриншотинг, который мы используем в локализации. Как побочный результат автотестов.