Локализация мобильного приложения: как выстроить процесс и уложиться в сроки (на примере Yandex Go)

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

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

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

• Результат. Обращений пользователей об ошибках локализации стало меньше, часть задач укладывается в SLA на 100%, у других срок доставки сократился.

Профессиональная локализация мобильных приложений охватывает не только строки интерфейса. В Yandex Go в нее входят тексты приложения, документы, коммуникации, push-уведомления, полноэкранные сообщения и контент внутри приложения. Формат дат, валюты и тон общения тоже зависят от рынка.

Хороший пример — Deli by Yango в Израиле, международный бренд Яндекс Лавки. Для него адаптировали не просто язык: другими были бренд, тон, визуал и маркетинг. Это и отличает локализацию от перевода с русского и английского на иврит.

Английский обычно становится первым шагом. В Yandex Go он главный язык после русского: без него сервис не может существовать. Рекомендация от нас: при переводе приложения на английский сразу выносите тексты из кода и давайте переводчикам контекст. Тогда английская версия не превращается в отдельную ветку, которую придется переделывать при добавлении других языков.

До автоматизации перевод контента строился на ручной передаче файлов между командами, и с ростом продукта эта схема начала давать сбои.

• Один цикл перевода статьи выглядел так: технический писатель готовил материал на русском языке, переносил его в Excel-файл, передавал переводчикам, согласовывал работу и документы, ждал перевода, а затем заново разворачивал готовый текст в документации RuStore. На одну статью уходило около двух недель.

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

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

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

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

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

В Yandex Go выбирали языки по аудитории. Кроме английского, популярны армянский, финский, сербский и иврит: в этих странах много пользователей, не говорящих по-русски. Казахстан, наоборот, крупный рынок, где 97% пользователей работают с русской версией.

Новую функцию переводят на все 16 языков, даже если она запускается только в России. Граждане Армении, Азербайджана, Киргизии, Узбекистана и других стран, которые живут в России, часто выбирают в приложении родной язык. Поэтому язык нужно планировать по аудитории, а не по стране запуска.

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

• Строки хранят в ресурсах. Все тексты интерфейса лежат в res/values/strings.xml, а не в коде. Файл по умолчанию должен содержать каждую строку приложения.

• Переводы лежат в каталогах с языком. Например, res/values-fr/strings.xml. Если строки нет, Android берет ее из файла по умолчанию. Для небольших региональных вариантов есть квалификатор региона, например values-en-rGB.

• Переводчику нужен контекст. К строке добавляют комментарий: где она показывается и какие у нее ограничения по длине. Текст, который нельзя переводить (подстановки, значения), помечают тегом <xliff:g>.

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

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

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

Менеджер Yandex Go Андрей Новокрещанов описывает проблемы одной фразой: сроки, деньги и качество перевода. На практике они выглядели так:

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

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

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

• Масштаб. 16 языков и 17 стран, где одни и те же функции нужно запускать с разным брендом и тоном.

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

Интеграцию делали как MVP: подключили платформу к внутренним системам и продолжили улучшать. Весь процесс занял пару месяцев, несмотря на множество систем на стороне большого Яндекса и необходимость строить процессы на стороне Yandex Go с нуля. Цель MVP — единая точка общения для команд, которые раньше работали каждая в своем инструменте. Следующий шаг — единый входящий поток заявок, простой и понятный.

Yandex Go не называет цифр, но показатели понятны:

• Сроки. Единого SLA для всей команды нет, срок зависит от заявки. Для части задач SLA выполняется в 100% случаев, для других срок доставки сократился.

• Качество. С момента перехода количество жалоб пользователей на ошибки локализации снизилось: пользователи сообщают о них в службу поддержки, и их стало меньше.

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

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

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

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

• Хранилище документов, в том числе облачное. Источник текстов для локализации.

• Трекер задач. Контролирует задачи и сроки.

• Коннекторы и бэкенд-скрипты. Передают контент между внутренними системами и платформой без ручных пересылок и обеспечивают непрерывную работу.

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

• Возврат в приложение. Готовые переводы попадают в релиз новой функции.

• Вынесите тексты из кода и добавьте контекст для переводчиков.

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

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

• Запустите MVP-интеграцию вместо идеального решения: первую версию в Yandex Go сделали за пару месяцев.

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

• Следите за метриками: число жалоб пользователей на ошибки локализации и соблюдение SLA.

• Проверьте приложение на неподдерживаемом языке и в RTL-макетах до релиза.

Каждый новый рынок добавляет языки, бренды и тон общения. По планам 2021 года Yandex Go готовил запуск Yango Deli в Париже и Лондоне, поэтому локализация остается частью продукта, а не разовой задачей. Чем раньше процесс выстроен, тем проще добавлять языки без потерь в сроках.