Локализация большого и гибкого программного обеспечения: пример компании «Касперский»

Руководство локализацией в крупной софтверной компании — задача сложная сама по себе. Что же происходит, когда такая компания переходит на гибкие методы работы? Задача становится еще сложнее, и приходится быстро внедрять радикальные изменения. В этом примере из практики Екатерина Галицкая и Дарья Егорушкина из Kaspersky рассказывают о своем опыте повышения производительности и эффективности процессов с помощью Smartcat.

Дальнейший текст Екатерины и Дарьи

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

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

Существует также распространенное заблуждение, что мобильные приложения содержат лишь небольшой объем текста. Хотелось бы! В нашем случае, например, в среднем на одно приложение приходилось около 25 000 слов только в текстах пользовательского интерфейса, умноженных на 10 приложений и 20 языков перевода для каждого приложения. И все это с учетом новых текстов пользовательского интерфейса и документации, поступающих каждую неделю.

В результате локализация стала основным препятствием во всем процессе выпуска продукта. И если раньше менеджеры по продукту даже не знали членов команды локализации по именам — зачем им это было нужно, если все переводы появлялись «как по волшебству»? — то теперь они были осведомлены обо всех связанных с этим вопросах гораздо глубже, чем хотели бы.

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

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

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

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

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

• Все чаще возникали проблемы со сбоями сборки из-за ошибок в «непереводимых элементах», неэкранированных апострофах и других человеческих ошибках.

Что касается этапа лингвистического тестирования, он может занять до двух недель, по сравнению с тремя-пятью днями, которые потребовались для самого перевода. «Что же такое лингвистическое тестирование?», — спросите вы.

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

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

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

• Текст остался непереведенным, либо из-за ошибки переводчика, либо потому, что он был жестко запрограммирован, а не вынесен во внешний файл в виде string,

• Текст, переведенный в неправильном контексте, например, когда текст на кнопке — например, «Скачать» — грамматически является императивом, а не инфинитивом.

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

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

1. Нанять работников с небольшим опытом и сократить объем локализационных работ, что, естественно, приведет к снижению качества, ИЛИ
2. Автоматизировать процесс.

Мы выбрали второй вариант.

При выборе решения CAT/TMS нашими главными приоритетами были:

1. Меньшее количество внутренних согласований — утверждение бюджетов, генерация серийных ключей и все такое прочее,

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

3. Невысокие требования к серверу — опять же, чтобы избежать длительных процедур утверждения,

4. Доступная, желательно бесплатная стоимость доступа к услуге.

5. Адекватная поддержка со стороны сервиса, чтобы не пришлось нанимать внутреннего разработчика,

6. Требования безопасности — мы подключаемся к нему, а не наоборот,

7. Поддержка нескольких ветвей — чтобы переводить несколько функций параллельно,

8. Дополнительные переводы возможны параллельно с исходной партией.

Когда мы составили короткий список вариантов, в нем осталось только два названия: Smartcat и Zing, сервер непрерывной локализации от создателей Evernote.

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

Итак, выбор пал на Smartcat. Поскольку нам не разрешается подключать CAT-инструменты напрямую к нашей внутренней системе управления версиями, мы решили использовать пакет Smartcat–Serge. (Serge — это программное обеспечение с открытым исходным кодом, которое синхронизирует строки между системами контроля версий и управления переводами. Оно идентифицирует строки в файлах различных форматов и конвертирует их в стандартный для отрасли формат PO, который затем передается в Smartcat. Мы можем установить его прямо на наших серверах, поэтому никакая наша конфиденциальная информация не попадает за пределы компании.)

Вот что нам больше всего понравилось в полученном решении:

• Оно поддерживает все наши требования: многоветвленные конвейеры, дополнительные переводы, безопасность и т. д.

• Мы получаем обновления на лету, без необходимости скачивать или устанавливать что-либо,

• Мы можем создавать собственные схемы разбора строк благодаря пакету Smartcat–Serge,

• Мы можем общаться с переводчиками, работающими над нашими документами, не покидая платформу,

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

• Мы можем оплачивать все языки и проекты одним счетом,

• Нам очень нравится поддержка, которую мы получаем — команда Smartcat помогла нам наладить рабочий процесс и уделила приоритетное внимание некоторым функциям, которые были для нас критически важными,

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

Среди проблем, с которыми мы столкнулись, были следующие:

• Изначально мы не могли выполнять поиск текста во всех документах проекта — теперь эта проблема решена, так как Smartcat реализовал эту функцию.

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

Учитывая наш опыт работы с Smartcat на данный момент, мы надеемся, что их команда уже работает над решением этих проблем.

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

До

До внесения изменений нам приходилось выполнять около 30 шагов на этапах перевода и лингвистического тестирования:

Перевод:

1. Захватить тексты из разных ветвей в репозитории — вручную,

2. Создать дельту для перевода — вручную,

3. Собрать пакеты для перевода,

4. Загрузите их на FTP-сервер,

5. Напишите кучу писем агентствам, фрилансерам или местным офисам,

6. Загрузите перевод с FTP-сервера, когда он будет готов,

7. Загрузите его в CAT-инструмент и убедитесь, что все выглядит нормально,

8. Загрузить переведенные строки в репозиторий, стараясь не перепутать ветки — вручную,

9. Запустить сборку, исправить ошибки, завершить сборку,

10. Запросить дополнительные переводы — по сути, повторить тот же процесс снова.

Лингвистическое тестирование:

1. Запустить сборку и дождаться ее завершения,

2. Перезапустить сборку, если она завершилась с ошибкой из-за локализационных ошибок,

3. Настроить специальную тестовую среду, если нет меню отладки,

4. Сделать все необходимые скриншоты для более чем 20 языков,

5. Совместно с командой контроля качества выясните, как получить недостающие скриншоты,

6. Создайте и назовите пакеты скриншотов,

7. Загрузите их на FTP-сервер,

8. Назначьте задачи переводческим агентствам для проверки переводов,

9. Отвечать на вопросы агентств,

10. Принимать задачи и вносить изменения,

11. Выполнять сборку — что иногда занимает много времени,

12. Переделывать сборку, если были ошибки,

13. Делать скриншоты для регрессивного тестирования,

14. Снова загрузить скриншоты и поручить задачи переводческим агентствам,

15. Снова обсудить все с агентствами,

16. Снова провести еще один раунд регрессионного тестирования, если были изменения в переводе.

После

Теперь у нас всего девять шагов на всех этапах:

1. Копирайтер фиксирует новые строки в Git. Серж автоматически передает строки в Smartcat,

2. Менеджер локализационных проектов назначает переводчиков,

3. Переводчики переводят в контексте — с помощью скриншотов и комментариев, которые всегда под рукой,

4. Менеджер локализационных проектов проверяет и утверждает перевод, который затем автоматически возвращается в Git,

5. Команда локализаторов запускает бота для создания скриншотов локализованных текстов,

6. Команда локализаторов помещает локализованные скриншоты на FTP-сервер и отправляет их лингвистам,

7. Лингвисты проверяют и при необходимости исправляют переводы, просматривая локализованные скриншоты,

8. Изменения автоматически попадают в Git,

9. Команда локализаторов закрывает пул-реквест.

Вот и все — благодаря такому тройному снижению сложности мы действительно чувствуем разницу по сравнению с тем, что было раньше!

Все цифры приведены за один выпуск — каждые две недели — и за одно приложение.

Дополнительные преимущества, некоторые из которых мы не ожидали, включают:

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

• Smartcat обнаружил некоторые старые ошибки благодаря настройкам критических ошибок.

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

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

Вот несколько конкретных шагов, которые мы предприняли после внедрения Smartcat. Мы разместили их здесь в качестве «шпаргалки» для других компаний и команд, которые хотят пойти по нашим стопам. Не все из них легко выполнить, но большинство поможет сделать процесс локализации более плавным и менее подверженным ошибкам.

Интеграция:

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

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

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

• Создайте cron-задачу для поиска веток локализации в соответствии с согласованной выше маской имени.

• Рассмотрите возможность тестирования пользовательского интерфейса и создания скриншотов функций с помощью фреймворка Kaspresso. Например, наши разработчики добавляют ссылку на скриншот для каждой используемой ими строки. Когда файл попадает в Smartcat, ссылка на скриншот автоматически попадает на вкладку «Комментарии». Вы можете узнать больше о Kaspresso и о том, почему вам может понадобиться его использовать, здесь.

Локализация и лингвистическое тестирование:

• Если у вас есть готовые глоссарии, загрузите их в Smartcat, чтобы обеспечить единообразие ваших локализаций.

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

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

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

Надеемся, что эти советы были полезны — поделитесь с нами своими!