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

image

Кто мы


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

Боли


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

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

Сроки


Локализационный цикл занимал 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 — фреймворк для автотестирования. Как раз на нем сделан автоскриншотинг, который мы используем в локализации. Как побочный результат автотестов.