Німецькі складені слова вилазять за межі діалогового вікна? Арабські тексти йдуть зліва направо, ламаючи layout? Це не баги перекладу — це проблеми технічної локалізації. Локалізація інтерфейсів і переклад ігор — це системна робота з текстом, шрифтами, форматуванням, правилами відмінювання та розмірами UI під кожну мову. Гра, яка «перекладена», але не локалізована, виглядає як машинний переклад: текст вилазить за кнопки, числа відображаються без урахування локалі, а RTL-рядки не дзеркаляться.
Ми локалізували понад 20 проєктів за 10+ років у геймдеві, включаючи проєкти з 15 мовами (арабська, іврит, китайська). Ми гарантуємо якість завдяки багаторічному досвіду. Використовуємо Unity Localization — стандарт для Unity-проєктів. Він працює через StringTable (текстові рядки з ключами) та AssetTable (локалізовані асети). Таблиці експортуються в XLIFF або CSV для передачі перекладачам (XLIFF імпорт підтримується).
Ключовий принцип: у коді та Prefab'ах — тільки ключі, жодних хардкоджених рядків. Компонент LocalizedString на TextMeshProUGUI — обов'язкова архітектура. Порушення цього правила означає ручний пошук усіх текстових рядків по сцені — це сотні об'єктів при додаванні нової мови.
Як працює технічна локалізація?
Технічна локалізація (LOC пайплайн) починається з аудиту: перевіряємо код на хардкоджені рядки, UI на негнучкі layout-и. Потім налаштовуємо StringTable/AssetTable, зв'язуємо ключі з елементами. Експортуємо в XLIFF для перекладачів, імпортуємо назад з верифікацією. Після — псевдолокалізація та тестування. Для CJK-мов підключаємо Dynamic Font Asset, для RTL — дзеркалювання UI.
Основні кроки:
- Аудит коду та UI.
- Налаштування StringTable/AssetTable.
- Експорт у XLIFF, імпорт перекладів.
- Псевдолокалізація (тестування подовженими рядками).
- Інтеграція шрифтів: Dynamic Font Asset для CJK, RTL-дзеркалювання.
- Фінальне тестування та виправлення багів.
Чому псевдолокалізація незамінна?
До отримання реальних перекладів ми запускаємо псевдолокалізацію: подовжуємо всі рядки на 30–40% і додаємо випадкові символи. Це виявляє переповнення контейнерів за 2–3 дні замість виявлення на етапі інтеграції перекладів. Без псевдолокалізації ви ризикуєте отримати баги за пару тижнів до релізу. Порівняння: псевдолокалізація в 3 рази ефективніше виявляє проблеми з переповненням до передачі рядків перекладачам, тоді як реальні переклади — тільки після імпорту.
Що таке Dynamic Font Asset і навіщо він потрібен?
Для китайської, японської та корейської мов статичний шрифтовий атлас важить 15–30 MB. Dynamic Font Asset завантажує лише гліфи, що зустрілися в тексті, скорочуючи пам'ять до кількох сотень кілобайт — це в 15–60 разів менше, ніж статичний. Мінус — мікрофризи (0.5–2 мс) при першому рендері нового ієрогліфа, але для мобільних проєктів це прийнятно.
| Характеристика | Статичний Font Asset | Dynamic Font Asset |
|---|---|---|
| Пам'ять | 15–30 MB | 0.5–2 MB (залежить від тексту) |
| Мікрофризи | Ні | Так (0.5–2 мс при нових гліфах) |
| Простота налаштування | Готовий атлас | Вимагає вказівки діапазонів Unicode |
Для арабської та івриту обов'язкова підтримка RTL. У TextMeshPro є вбудований RTL режим (TMP_Text.isRightToLeftText = true), але одного прапорця недостатньо. Елементи UI теж мають дзеркалитися: кнопка «Назад» переміщується з лівого краю на правий, список читається справа наліво. Це вимагає спеціальної логіки в Layout Manager або перемиканих Prefab'ів з дзеркальним layout'ом для RTL-мов.
З нашої практики: на проєкті з підтримкою російської, англійської та німецької ми зіткнулися з тим, що німецькі складені слова (наприклад, Geschwindigkeitsbegrenzung) не переносяться в TextMeshPro за замовчуванням. Рішення — Hyphenation через TMP_Settings + підключення словника переносів для німецької. Після налаштування текст коректно переноситься, контейнер діалогу перестав переповнюватися.
Типові помилки при локалізації:
- Хардкоджені рядки в коді та сценах — при додаванні мови доводиться шукати їх вручну.
- Відсутність RTL-дзеркалювання UI — арабський текст іде зліва направо, ламаючи навігацію.
- Ігнорування множинних форм — у російській три числа, в англійській два, в арабській шість.
- Невикористання псевдолокалізації — баги з переповненням виявляються тільки після інтеграції перекладів.
Орієнтовні терміни
| Масштаб | Терміни (без урахування часу перекладу) |
|---|---|
| Додавання однієї мови в готовий пайплайн | 3–7 днів |
| Побудова пайплайну локалізації з нуля (1–2 мови) | 1–3 тижні |
| Повна локалізація проєкту (5–10 мов, включаючи RTL) | 4–10 тижнів |
| Інтеграція із зовнішніми CAT-інструментами + автоматизація | 1–3 тижні |
Що входить у нашу роботу
Ми надаємо повний цикл локалізації під ключ:
- Аудит поточного коду та UI на готовність до локалізації.
- Налаштування пайплайну Unity Localization (або аналога для Unreal Engine).
- Створення StringTable/AssetTable, інтеграція з CAT-інструментами.
- Розробка Dynamic Font Asset для CJK та RTL-мов.
- Псевдолокалізація та тестування переповнення UI.
- Автоматизація імпорту/експорту перекладів.
- Документація з підтримки локалізації для команди.
Зв'яжіться з нами для аудиту вашого проєкту — ми підберемо оптимальне рішення. Отримайте консультацію інженера з локалізації, щоб уникнути типових помилок і скоротити час виходу на нові ринки.