Чому локалізація мобільної гри ламається на релізі
Локалізація мобільної гри майже ніколи не ламається на етапі перекладу — вона ламається на збірці, коли рядки вже роз'їхалися по екранах, а тестувальник бачить не вихідний макет, а його спотворену версію.
Німецький текст довший за англійський на третину, арабська розвертає верстку справа наліво, а китайська обходиться без пробілів — і там, де в макеті стояла акуратна кнопка, у релізі з'являється обрізане «Продовж…».
Це не косметика: кожна така кнопка — втрачений крок онбордингу, а онбординг вирішує, залишиться гравець чи видалить застосунок на першому екрані.
Проблеми локалізації ігор рідко обмежуються довжиною рядків. Формати дат, чисел і валют збираються із системних шаблонів, і якщо рядок «12/03» на одному ринку читається як грудень, а на іншому як березень — гравець бачить невірну дату події.
Множинні форми числівників у слов'янських мовах вимагають не двох варіантів, а трьох, і жорстко зашита логіка «один/багато» дає «5 кристалів» там, де мова чекає третю форму. Помилки перекладу інтерфейсу тут вторинні — первинна архітектура рядків, яка не передбачала варіативність.
Окрема категорія збоїв — загублені рядки. Тексти живуть у таблицях, частина підтягується із серверних конфігів, частина зашита в код, частина приходить із магазину застосунків.
Під час виведення гри на новий ринок ці джерела синхронізують вручну, і будь-яка розсинхронізація дає порожні плашки, англійські заглушки посеред локалізованого екрана або падіння на відсутньому ключі. Гравець не повідомляє про це в підтримку — він просто йде.
Ціна помилки рахується не в правках, а в конверсії: обрізаний перший екран, нечитабельна ціна у внутрішньоігровому магазині або зламаний формат дати в щоденній нагороді знижують частку тих, хто дійшов до першого платежу, помітно сильніше, ніж будь-яка затримка релізу. Розбираємо, як це закривається на рівні процесу, а не героїчними правками перед викладкою.
Що дає технічна локалізація мобільної гри
Технічна локалізація застосунків починається не з перекладу, а з того, як рядки потрапляють у збірку. Якщо тексти лежать прямо в коді або в розрізнених таблицях, кожна мова перетворюється на окрему гілку, яку потрібно вручну зводити з основною.
Правильно вибудуваний конвеєр локалізації прибирає цю ручну роботу: рядки винесені в ресурсні файли, ключі стабільні, а переклади підтягуються на етапі збірки.
Винесення рядків і керування ключами
Поки текст зашитий в інтерфейс, будь-яка правка копії вимагає участі розробника. Керування рядками перекладу через єдиний каталог із ключами виду screen.button.confirm відокремлює текст від логіки: правка копії не чіпає код, а новий рядок потрапляє в усі мови одразу. Побічний ефект — збірка перестає ламатися через незакриту лапку в перекладі.
Автоматична перевірка цілісності
Скрипт звіряє набір ключів між мовами і валить збірку, якщо в мові бракує рядка або залишився неперекладений placeholder. Це ловить обривки виду {count} items в арабському інтерфейсі до релізу, а не у відгуках. Частка таких дефектів, що доходять до користувача, падає до нуля.
Псевдолокалізація і перевірка верстки
Прогін інтерфейсу на «подовженій» псевдомові показує, де кнопка не вміщає німецький текст або де рядок виїжджає за край. Верстку правлять один раз на етапі розробки, а не після кожної нової мови.
Контекст для перекладача
Скриншот екрана і коментар до ключа знімають здогадки: перекладач бачить, що Post — це кнопка публікації, а не пошта. Повернення на доопрацювання за змістом скорочуються в рази.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручна збірка | 1-2 мови, короткий термін життя продукту | Кожна мова — ручна робота, зростає ризик розсинхрону |
| Напівавтоматичний конвеєр | 3-10 мов, власна команда розробки | Потребує підтримки скриптів і дисципліни за ключами |
| Зовнішня платформа керування рядками | Багато мов, часті релізи, зовнішні перекладачі | Залежність від сервісу, потрібне налаштування синхронізації |
Ми збираємо такий конвеєр на основі галузевих стандартів обміну перекладами — XLIFF залишається нейтральним форматом, який розуміють і платформи, і перекладацькі команди.
Етапи впровадження локалізації в цикл розробки гри
Локалізація не починається з перекладу — вона починається з інвентаризації того, що вже є в проєкті. Рядки часто розкидані між кодом, розміткою екранів, серверними відповідями та описами в магазині, частина зашита в графіку, частина збирається динамічно з фрагментів.
Поки ця картина не зібрана, будь-який переклад упирається в обрізаний текст, «поповзлі» кнопки та рядки, які ніхто не може знайти у вихідниках. Нижче — як ми вибудовуємо впровадження локалізації так, щоб вона стала частиною збірки, а не окремим авралом перед релізом.
- Аудит рядків і ресурсів. Проходимо по коду, розмітці та серверних відповідях, збираємо всі текстові ресурси в єдиний каталог, позначаємо «мертві» та дубльовані рядки. На виході — карта: де живе кожен рядок і хто його власник.
- Проєктування схеми локалізації. Визначаємо ключі, формат файлів обміну, правила плюралізації та відмінювання, розподіл за мовами й регіонами. Фіксуємо, що перекладається автоматично, а що потребує участі редактора.
- Налаштування конвеєра. Підключаємо систему керування перекладами до репозиторію: нові та змінені рядки йдуть на переклад, готові повертаються в проєкт окремою гілкою. Збірка сама підхоплює актуальні мовні файли.
- Перевірка на реальних збірках. Прогоняємо застосунок кожною мовою: довжина рядків у кнопках і меню, перенесення, шрифти, формати дат і чисел, порядок слів. Ловимо переповнення до релізу, а не у відгуках.
- Автоматичні перевірки у збірці. Додаємо контроль: неперекладені ключі, забуті рядки, розбіжності між мовами. Збірка падає, якщо мова відстала від основної версії.
- Передача команді. Оформлюємо регламент: як додати рядок, як запросити правку, хто відповідає за вичитку. Команда працює з локалізацією за тими самими правилами, що й з рештою коду.
- Підтримка після релізу. Нові мови та правки тексту стають у той самий конвеєр — без перезбирання процесу з нуля.
Така послідовність прибирає ручне перенесення рядків і тримає всі мови синхронними: додавання нової мови зводиться до підключення ще одного набору файлів, а не до окремого проєкту. Опишіть вашу задачу — повернемося з оцінкою та планом впровадження під ваш стек і релізний цикл.
Чим відрізняється локалізація мобільної гри від звичайного перекладу?
Переклад працює з текстом як із потоком символів: узяв рядок, замінив на інший, повернув у файл.
Локалізація мобільної гри працює з текстом як із частиною виконуваної логіки — рядок живе всередині ресурсів, підставляється в шаблони, відмінюється за числами й відмінками та рендериться конкретним шрифтом на конкретному екрані.
Тому локалізація vs переклад — це не «якісніше переклали», а інший клас задачі: перекладач віддає текст, локалізатор відповідає за те, що гра в цій локалі не зламається.
Локалізація ігрового інтерфейсу починається з інвентаризації рядків. Ми розбираємо ресурси за типами: статичні підписи кнопок і меню, репліки з підстановкою змінних, тексти з плюралізацією та гендерними формами, рядки, що збираються в рантаймі з фрагментів.
Остання категорія — головне джерело багів: перекладач бачить «Ви отримали 3 монети», а в коді це три окремі рядки, склеєні конкатенацією, і в мові з іншим порядком слів або іншою системою числівників таке складання дає сміття.
Динамічні рядки вимагають, щоб перекладач працював не з готовим реченням, а із шаблоном та його змінними. Ми позначаємо кожен плейсхолдер, фіксуємо допустимі типи підстановки та перевіряємо, що після підстановки максимального значення рядок не вилазить за контейнер.
Окремо йде форматування даних: дати, час, розділювачі розрядів, формати чисел і валют, одиниці вимірювання — усе це прив'язано до локалі пристрою, а не до мови інтерфейсу, і при неправильному налаштуванні гравець бачить дату в чужому форматі.
Шрифти та верстка закривають цикл. Не кожен шрифт містить потрібні глифи, а розширена кирилиця, арабська в'язь або ієрогліфи змінюють метрики тексту: підпис, який у вихідній локалі займав один рядок, у цільовій ламає кнопку.
Ми проганяємо локалізовані екрани через перевірку на переповнення та обрізання, а не покладаємося на те, що «переклад короткий».
Підсумок: звичайний переклад віддає файл із рядками, локалізація мобільної гри віддає робочу збірку в цільовій локалі — з перевіреними підстановками, коректними форматами та версткою, яка не роз'їжджається.
Кейс: як локалізація прискорила вихід гри на нові ринки
Був проєкт на рушії з окремими таблицями рядків за мовами: кожна нова локація додавалася вручну, а оновлення з однією мовою займало до трьох тижнів. Тексти жили в таблицях, верстка — в окремій гілці, і будь-яка правка у вихідному рядку ламала вже перекладені екрани. До релізу накопичилося 12% обрізаних рядків в інтерфейсі та постійні розбіжності між версіями.
Що змінили
Зібрали єдиний конвеєр: вихідні рядки вивантажуються у спільний формат, перекладачі працюють у ньому ж, а збірка мовного пакета запускається автоматично за тегом.
Ключі перестали дублюватися між екранами, додали перевірку довжини рядка під кожен макет — обрізання ловиться до збірки, а не на пристрої. Для арабської та івриту увімкнули дзеркалення розкладки на рівні стилів, а не ручною правкою верстки.
Метрики до і після
| Показник | До | Після |
|---|---|---|
| Випуск оновлення з новою мовою | до 3 тижнів | 3-4 дні |
| Обрізані рядки в інтерфейсі | 12% | менше 1% |
| Помилки верстки на нових мовах | регулярні, ловилися на тесті | поодинокі, відсікаються у збірці |
| Утримання на нових ринках | базове | зростання в перші тижні після старту |
Прискорення випуску мов дало не лише строки: команда почала додавати локалі паралельно з розробкою функцій, а не після. Результати локалізації стало видно за утриманням — гравці на нових ринках доходили до ключових механік частіше, бо інтерфейс перестав «рватися» їхньою мовою.
Unity Localization та аналогічні системи керування рядками закривають частину завдань, але не скасовують ручну перевірку контексту й довжини — тому в конвеєрі залишився етап ревʼю перекладів носієм до збірки.
Сумніви перед стартом: сумісність, міграція, відкат
Сумісність локалізації майже ніколи не впирається в рушій — вона впирається в те, як рядки пов'язані з логікою.
Якщо текст зашитий у код або зібраний в один плоский файл, додавання мови ламає збірку: ключі дублюються, частина рядків залишається неперекладеною, а форматні плейсхолдери на кшталт %1$s і {count} розходяться за позиціями.
Тому першим кроком ми розводимо контент і код: рядки виносяться в таблиці зі стійкими ключами, переклади підключаються як окремі набори, а не правкою вихідників.
Що якщо в проєкті вже є локалізація в іншому форматі? Міграція рядків іде через проміжну таблицю відповідності: старі ключі зіставляються з новими, конфлікти та «осиротілі» рядки потрапляють в окремий звіт, а не губляться мовчки.
Після перенесення проганяємо збірку всіма мовами — розбіжність за кількістю ключів між вихідним і цільовим наборами видно одразу.
Як відкочується невдала мова? Відкат локалізації — це повернення попереднього набору рядків, а не перезбірка застосунку: набори версіонуються окремо від коду, тому проблемна мова знімається перемиканням посилання, без нового релізу в магазині.
Псевдолокалізація (підстановка подовжених рядків) заздалегідь показує, де верстка не переживе німецький або фінський текст.
Що якщо в нас свій формат рядків і змінювати його не можна?
Пишемо конвертер між вашим форматом і робочим: на вхід подається поточний файл, на виході — той самий формат з оновленими значеннями. Вихідний конвеєр залишається недоторканим, а ми працюємо з проміжним представленням. Конвертер і правила зіставлення ключів передаємо разом з рештою документації.
На руки команда передає:
- конфігурації збірки за мовами та платформами;
- схему ключів з правилами іменування та областями застосування;
- політику версіонування наборів рядків і порядок відкату;
- звіт міграції: зіставлення старих і нових ключів, список конфліктів;
- документацію локалізації — регламент додавання мови та правки тексту;
- набір перевірок на розбіжність ключів і плейсхолдерів у збірці;
- інструкцію з псевдолокалізації для перевірки верстки.
Опишіть задачу — повернемося з оцінкою та планом: покажемо, які кроки потрібні саме вашому проєкту і що з цього вже закрито в поточному конвеєрі.
