Техническая локализация мобильных игр: полный цикл

Почему локализация мобильной игры ломается на релизе

Локализация мобильной игры почти никогда не ломается на этапе перевода — она ломается на сборке, когда строки уже разъехались по экранам, а тестировщик видит не исходный макет, а его искажённую версию. Немецкий текст длиннее английского на треть, арабский разворачивает вёрстку справа налево, а китайский обходится без пробелов — и там, где в макете стояла аккуратная кнопка, в релизе появляется обрезанное «Продолж…». Это не косметика: каждая такая кнопка — потерянный шаг онбординга, а онбординг решает, останется игрок или удалит приложение на первом экране.

Проблемы локализации игр редко ограничиваются длиной строк. Форматы дат, чисел и валют собираются из системных шаблонов, и если строка «12/03» на одном рынке читается как декабрь, а на другом как март — игрок видит неверную дату события. Множественные формы числительных в славянских языках требуют не двух вариантов, а трёх, и жёстко зашитая логика «один/много» даёт «5 кристаллов» там, где язык ждёт третью форму. Ошибки перевода интерфейса здесь вторичны — первична архитектура строк, которая не предполагала вариативность.

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

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

Что даёт техническая локализация мобильной игры

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

Вынос строк и управление ключами

Пока текст зашит в интерфейс, любая правка копии требует участия разработчика. Управление строками перевода через единый каталог с ключами вида screen.button.confirm отделяет текст от логики: правка копии не трогает код, а новая строка попадает во все языки сразу. Побочный эффект — сборка перестаёт ломаться из-за незакрытой кавычки в переводе.

Автоматическая проверка целостности

Скрипт сверяет набор ключей между языками и валит сборку, если в языке не хватает строки или остался непереведённый placeholder. Это ловит обрывки вида {count} items в арабском интерфейсе до релиза, а не в отзывах. Доля таких дефектов, доходящих до пользователя, падает до нуля.

Псевдолокализация и проверка вёрстки

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

Контекст для переводчика

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

Мы собираем такой конвейер на основе отраслевых стандартов обмена переводами — XLIFF остаётся нейтральным форматом, который понимают и платформы, и переводческие команды.

Этапы внедрения локализации в цикл разработки игры

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

1. Аудит строк и ресурсов. Проходим по коду, разметке и серверным ответам, собираем все текстовые ресурсы в единый каталог, помечаем «мёртвые» и дублирующиеся строки. На выходе — карта: где живёт каждая строка и кто её владелец.
2. Проектирование схемы локализации. Определяем ключи, формат файлов обмена, правила плюрализации и склонений, разделение по языкам и регионам. Фиксируем, что переводится автоматически, а что требует участия редактора.
3. Настройка конвейера. Подключаем систему управления переводами к репозиторию: новые и изменённые строки уходят на перевод, готовые возвращаются в проект отдельной веткой. Сборка сама подхватывает актуальные языковые файлы.
4. Проверка на реальных сборках. Прогоняем приложение на каждом языке: длина строк в кнопках и меню, переносы, шрифты, форматы дат и чисел, порядок слов. Ловим переполнения до релиза, а не в отзывах.
5. Автоматические проверки в сборке. Добавляем контроль: непереведённые ключи, забытые строки, расхождения между языками. Сборка падает, если язык отстал от основной версии.
6. Передача команде. Оформляем регламент: как добавить строку, как запросить правку, кто отвечает за вычитку. Команда работает с локализацией по тем же правилам, что и с остальным кодом.
7. Поддержка после релиза. Новые языки и правки текста встают в тот же конвейер — без пересборки процесса с нуля.

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

Чем отличается локализация мобильной игры от обычного перевода?

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

Локализация игрового интерфейса начинается с инвентаризации строк. Мы разбираем ресурсы по типам: статичные подписи кнопок и меню, реплики с подстановкой переменных, тексты с плюрализацией и гендерными формами, строки, собираемые в рантайме из фрагментов. Последняя категория — главный источник багов: переводчик видит «Вы получили 3 монеты», а в коде это три отдельные строки, склеенные конкатенацией, и в языке с другим порядком слов или другой системой числительных такая сборка даёт мусор.

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

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

Итог: обычный перевод отдаёт файл со строками, локализация мобильной игры отдаёт работающую сборку в целевой локали — с проверенными подстановками, корректными форматами и вёрсткой, которая не разъезжается.

Кейс: как локализация ускорила выход игры на новые рынки

Был проект на движке с раздельными таблицами строк по языкам: каждая новая локаль добавлялась вручную, а обновление с одним языком занимало до трёх недель. Тексты жили в таблицах, вёрстка — в отдельной ветке, и любая правка в исходной строке ломала уже переведённые экраны. К релизу накопилось 12% обрезанных строк в интерфейсе и постоянные расхождения между версиями.

Что изменили

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

Метрики до и после

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

Unity Localization и аналогичные системы управления строками закрывают часть задач, но не отменяют ручную проверку контекста и длины — поэтому в конвейере остался этап ревью переводов носителем до сборки.

Сомнения перед стартом: совместимость, миграция, откат

Совместимость локализации почти никогда не упирается в движок — она упирается в то, как строки связаны с логикой. Если текст зашит в код или собран в один плоский файл, добавление языка ломает сборку: ключи дублируются, часть строк остаётся непереведённой, а форматные плейсхолдеры вроде %1$s и {count} расходятся по позициям. Поэтому первым шагом мы разводим контент и код: строки выносятся в таблицы с устойчивыми ключами, переводы подключаются как отдельные наборы, а не правкой исходников.

Что если в проекте уже есть локализация в другом формате? Миграция строк идёт через промежуточную таблицу соответствия: старые ключи сопоставляются с новыми, конфликты и «осиротевшие» строки попадают в отдельный отчёт, а не теряются молча. После переноса прогоняем сборку на всех языках — расхождение по числу ключей между исходным и целевым наборами видно сразу.

Как откатывается неудачный язык? Откат локализации — это возврат предыдущего набора строк, а не пересборка приложения: наборы версионируются отдельно от кода, поэтому проблемный язык снимается переключением ссылки, без нового релиза в магазине. Псевдолокализация (подстановка удлинённых строк) заранее показывает, где вёрстка не переживёт немецкий или финский текст.

На руки команда передаёт:

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

Опишите задачу — вернёмся с оценкой и планом: покажем, какие шаги нужны именно вашему проекту и что из этого уже закрыто в текущем конвейере.