Локалізація інтерфейсів та текстових блоків ігор
Локалізація—це не переклад рядків у таблицю. Це системна робота з текстом, шрифтами, форматуванням, правилами відмінювання та розмірами UI-елементів для кожної мови. Гра, яка «перекладена», але не локалізована, виглядає як машинний переклад: текст вилізає за кнопки, числа відображаються без урахування локалі, арабський текст йде зліва направо.
Технічний конвеєр локалізації в Unity
Стандарт для Unity-проектів зараз—пакет Unity Localization (com.unity.localization). Він працює через StringTable та AssetTable: StringTable зберігає текстові рядки з ключами, AssetTable—локалізовані ассети (текстури, аудіо, шрифти). Таблиці експортуються в CSV/XLIFF для передачі перекладачам та імпортуються назад.
Ключовий принцип: у коді та в Prefabs повинні бути тільки ключі, жодних жорстко закодованих рядків. LocalizedString на компоненті TextMeshProUGUI з прив'язкою до StringTable—обов'язкова архітектура. Порушення цього правила означає, що при додаванні нової мови доведеться вручну шукати всі текстові рядки по сцені—це сотні об'єктів.
Plural Rules—окрема біль. У російській мові три форми числівників: «1 предмет», «2 предмета», «5 предметів». В англійській—дві. В арабській—шість. Unity Localization підтримує Plural через Smart String з форматуванням {count:plural:предмет|предмета|предметов}, але правила для кожної мови потрібно прописувати явно через Plural Rule Provider або використовувати готові правила з CLDR (Common Locale Data Repository).
Дата та числа: 1,234.56 (EN) vs 1.234,56 (DE) vs 1 234,56 (RU). Без явного використання CultureInfo при форматуванні в C# числа відображаються в форматі системної локалі пристрою—непередбачувано. Всі числа, валюти та дати повинні форматуватися через string.Format(CultureInfo.GetCultureInfo(currentLocale), ...) або через Smart String з форматом {value:C} з явною прив'язкою локалі.
Шрифти під різні мови: найчастіше недооцінена проблема
CJK (китайська/японська/корейська) шрифт для TextMeshPro—це Font Asset з десятками тисяч глифів. Повний CJK Font Asset в SDF може важити 15–30 MB тільки для текстурного атласу. Для мобільного проекту з бюджетом пам'яті це неприйнятно.
Рішення: Dynamic Font Asset з Population Mode → Dynamic. Атлас заповнюється тільки глифами, які реально зустрічаються в тексті. При першому запуску в пам'яті тільки кілька сотень використаних ієрогліфів. Мінус—можлива мікрофриз (0.5–2 мс) при першому рендері нового глифу. Для більшості ігор прийнятно.
Для арабської та іврИТ обов'язкова підтримка RTL (right-to-left). У TextMeshPro є вбудований RTL режим, активується через TMP_Text.isRightToLeftText = true. Але одного прапора недостатньо: елементи UI теж повинні дзеркалитися (кнопка «Назад» переміщується з лівого краю на правий, список читається справа наліво). Це потребує спеціальної логіки в Layout Manager або переключаємих RTL-layout Prefabs для RTL-мов.
Кейс: кирилиця та перенос слів
На проекті з підтримкою російської, англійської та німецької зіткнулися з тим, що німецькі складові слова (Geschwindigkeitsbegrenzung—«ограничение скорости») не переносяться в TextMeshPro за замовчуванням, а просто вилізають за межу поля або переходять на новий рядок цілком. Це ламало діалогові вікна: фіксований розмір контейнера, текст уходить за нижній край.
Рішення: Hyphenation через TMP_Settings → Enable Word Wrapping + підключення словника переносів для німецької через користувальницький TMP_HyphenationDictionary. Формат словника сумісний зі стандартом LibreOffice (TeX hyphenation patterns). Після підключення німецький текст коректно переносився за правилами, контейнер діалогу перестав переповнюватися.
Інструменти та інтеграція з перекладачами
Перекладачі не працюють у Unity. Стандартний workflow: Unity Localization → експорт StringTable в XLIFF 1.2 або CSV → передача в CAT-інструмент (Phrase, memoQ, SDL Trados) → отримання перекладених XLIFF → імпорт назад у Unity. Цей цикл повинен бути автоматизований через Editor-скрипт, інакше ручний імпорт 15 мов × 20 таблиць = кілька годин роботи при кожному оновленні рядків.
Рядки з форматуванням (Smart String з плейсхолдерами {name} або {count}) повинні супроводжуватися інструкцією для перекладача: що означає плейсхолдер, в якій частині фрази він може бути переміщений. В німецькій {count} Gegenstände gefunden—плейсхолдер на початку, що нормально. В японській порядок слів інший, плейсхолдер може бути в кінці. CAT-інструменти підтримують захист плейсхолдерів від випадкового перекладу.
Тестування локалізації
Псевдолокалізація—запуск UI з тестовими рядками збільшеної довжини та випадковими символами. Unity Localization має вбудований Pseudo Locale з опцією розширення рядків на 30–40% (характерно для німецької та фінської порівняно з англійським оригіналом). Запускаємо псевдолокаль ще до появи реальних перекладів—проблеми з переповненням текстових полів видні одразу.
Перевірка Missing Translation: Unity Localization логує відсутні ключі в Console з попередженням, але у продакшні це повинно виводити fallback-значення, а не пустий рядок. Налаштовується через Localization Settings → Missing Translation Behavior.
| Масштаб | Строки (без урахування часу перекладу) |
|---|---|
| Додавання однієї мови у готовий конвеєр | 3–7 днів |
| Побудова конвеєру локалізації з нуля (1–2 мови) | 1–3 тижні |
| Повна локалізація проекту (5–10 мов, RTL включаючи) | 4–10 тижнів |
| Інтеграція з зовнішніми CAT-інструментами + автоматизація | 1–3 тижні |
Вартість розраховується індивідуально після аналізу обсягу рядків та підтримуваних мов.