Реліз англійською та українською — норма для команд, що продають у ЄС і обслуговують користувачів удома. Це також місце, де roadmap тихо подвоюється: кожна фіча — два тікети, кожен рев'ю скрінів — два кола, а «перекладемо потім» стає вічним боргом.
Не потрібні два продукти. Потрібен один продукт із чітким контрактом локалей.
Команди, у яких із цим проблеми, рідко страждають від нестачі перекладачів. Їм бракує рішення, прийнятого рано, про те, які частини продукту — це контент, а які — структура. Пропустіть це рішення, і кожен наступний вибір — як зібраний компонент, як заскоупений тікет, як тріажиться баг — робиться двічі, по-різному, залежно від того, хто того тижня торкався конкретного екрана.
Що спільне, а що перекладається
Не все — це текст. Три кошики:
| Спільне (одне значення) | Локалізоване | Поведінка залежно від локалі |
|---|---|---|
| Slug, ID, статус | Заголовок, тіло, CTA | Формати дат, валюта |
| Enum категорії | Назви країн у тексті | Fallback на мову за замовчуванням |
| Шляхи до зображень | Meta description | Юридичні лінки по ринку |
Окремі артборди в Figma «на кожну мову» змушують інженерію збирати лейаут двічі. Краще один лейаут, підміна рядків.
Звучить очевидно, коли написано прямим текстом, але саме тут більшість двомовних продуктів тихо розходяться. «UK-версія» екрана, що почалась як окремий Figma-фрейм, з часом дрейфує: правку відступів вносять в англійський фрейм у спринті — і ніхто не пам'ятає віддзеркалити її; нове поле додають у форму однієї локалі, а не обох; за півроку два «однакових» екрани поводяться настільки по-різному, що QA доводиться тестувати їх як окремі фічі. Один лейаут із підміною рядків так дрейфувати не може — просто нема чого міняти окремо.
Тут є й технічна причина, не лише дисципліна дизайну. В українській граматиці є форми множини, яких немає в англійській — «1 файл», «2 файли», «5 файлів» англійською згортається у два правила, а українською потрібно три (однина, кілька, багато), плюс окремі правила для чисел на кшталт 21 чи 22. Контракт локалей, що трактує множину як таблицю правил на мову (через ICU MessageFormat чи аналог), це переживає. Контракт, що трактує це як «просто підставити число в рядок», видає граматично неправильний UI-текст, який україномовний користувач помічає одразу, навіть якщо ніколи про це не скаже.
Рядки — в одному місці
Розкидане "Надіслати" по п'ятдесяти компонентах гарантує, що половину пропустите в UK. Централізуйте:
- UI-хром у locale JSON / каталогах повідомлень
- Довгий контент (блог, кейси) у файлах або CMS з вкладками локалей
- Листи й PDF — окремі шаблони; вони ламають i18n мовчки
Правило fallback, яке рятує сапорт: немає UK → показуємо EN, ніколи сирий ключ.
Централізувати рядки — легка частина цього правила; тримати їх централізованими — важка. Найчастіший провал не «ми ніколи не завели каталог повідомлень» — це «каталог є, але девелопер під дедлайном захардкодив рядок прямо в компоненті, щоб зробити hotfix, планував перенести в каталог пізніше, а «пізніше» так і не настало». За півроку таких випадків розкидано десяток по кодовій базі — жоден сам по собі не критичний, але разом вони й є причина, чому «простий» прохід перекладу займає два зайві дні. Lint-правило, яке ловить строкові літерали в JSX поза каталогом, ловить це на етапі PR, а не аудиту — а це різниця між п'ятихвилинним фіксом і дводенним.
Листи й PDF заслуговують окремого пункту, бо їх зазвичай генерує інший шлях коду, ніж UI, — сервіс транзакційних листів, бібліотека генерації PDF, воркер черги — і про цей шлях легко забути, коли міркуєш про «продукт». Листи скидання пароля, PDF інвойсів, підтвердження доставки — це саме той контент, що лишається англійським назавжди, бо його ніхто не поклав у той самий чекліст рев'ю, що й екрани.
Пишіть під переклад, не під каламбур
Англійський маркетинг любить ідіоми, які в українській розвалюються. Бриф для авторів:
- короткі речення й конкретні дієслова
- без каламбурів у головних CTA
- підписи кнопок до ~3–4 слів, щоб лейаут не плив
Українська часто довша. Кнопки й навігація потребують запасу, а не піксельно підігнаного EN-макету.
Розширення тексту — не похибка округлення: слов'янські мови зазвичай на 15–30% довші за англійський оригінал з тим самим змістом, а короткі UI-рядки (кнопка на два слова, лейбл нав-меню) можуть розширюватись у відносних цифрах ще сильніше, бо стискати вже нема куди. Кнопка, підігнана точно під «Get started» англійською, обріже або перенесе «Розпочати безкоштовно» українською, якщо ніхто не закладав цю різницю. Виправлення — не «зробити українську коротшою», це боротьба з мовою — а компоненти, що з самого початку толерують діапазон довжин рядка: тап-таргети з гнучкою шириною, текст, що може переноситись у два рядки без поламки лейауту, іконки, здатні нести сенс, коли лейбл доводиться скоротити.
Є й друга, менш очевидна пастка перекладу, варта згадки в брифі авторам: українська — граматично родова мова, і копірайт у минулому часі чи від першої особи (щось на кшталт «Ви завершили профіль», підтвердження, сформульовані як твердження) інколи вимагає вибору граматичної форми, про яку англійський текст навіть не думає. Писати оригінал EN нейтральним, теперішнім часом, у стилі інструкції («Заповніть профіль», а не «Ви це зробили!») дає перекладачам чистіше речення для роботи і уникає копірайту, що звучить дивно-родово чи неприродно в цільовій мові.
Типові помилки, які ми бачимо
Кілька патернів трапляються достатньо часто, щоб виділити їх окремо:
- Друга локаль як завдання тижня релізу. Двомовність, додана після того, як UI вже «готовий», зазвичай означає доробку компонентів з фіксованою шириною заднім числом — це повільніше, ніж зробити їх гнучкими з самого початку.
- Немає власника якості перекладу. Рядки перекладені, але ніхто не відповідає за те, щоб прочитати їх у контексті, на реальному екрані, перед релізом — і незграбна, машинна на вигляд фраза лишається назавжди.
- Перемикання локалі, що втрачає стан. Користувач посеред checkout перемикає мову і його кидає на головну — вдруге він мову перемикати не буде, він вирішить, що фіча зламана.
- SEO-метадані як другорядне. Відсутні
hreflang-теги, дубльовані canonical URL по локалях або sitemap лише англійською тихо коштують органічного трафіку на українському ринку, навіть коли сам UI повністю локалізований.
Чекліст релізу, який ловить дірки
Перш ніж вважати двомовний реліз готовим:
- Пройдіть критичний шлях обома мовами (signup, checkout, contact)
- Пошукайте неперекладені ключі й
TODO - Перевірте OG / meta для обох мов
- Вибірково — листи й помилки (їх забувають найчастіше)
- Юридичні сторінки існують або коректно падають на fallback
Автоматизуйте лінт відсутніх ключів. Клікайте вручну те, за що платять користувачі.
Причина, чому список саме в такому порядку: автоматичні перевірки ловлять відсутні рядки, але не ловлять рядок, що присутній, перекладений — і неправильний: кнопка з правильними словами, що тригерить не ту дію після пропущеної locale-специфічної умови, або підтвердження, коректне саме по собі, але двозначне поруч із полем, яке воно підтверджує. Це видно лише коли людина проходить реальний флоу реальною мовою — тому «клікайте те, за що платять» не приємний бонус, а перевірка, яку нічим не замінити. Листи й помилки в списку явно, бо це та частина продукту, з якою девелопер найменше стикається під час звичайного QA (500-ту помилку чи флоу скидання пароля рідко тригериш, тестуючи нову фічу), і тому найчастіше та, що лишається англійською в день релізу.
CMS і маркетингові сайти
Портфоліо й блог змінюються щотижня. Лише EN у git і «UK колись» — рецепт вічно напівперекладеного сайту. Або:
- публікуйте обидві локалі разом, або
- явно позначте EN-only і поставте UK у беклог з відповідальним
Часткова локалізація ок, якщо вона свідома. Випадкова — виглядає як баг.
Різниця важлива, бо відвідувач читає намір, а не процес. Сторінка, послідовно й чітко лише англійською, читається як свідомий вибір — можливо, цей контент розрахований на міжнародну аудиторію, і це нормально. Сайт, де частина сторінок українською, частина англійською, а розподіл виглядає випадковим, читається як недогляд — і змушує відвідувача сумніватись, що ще на сайті недороблене чи занедбане. Якщо UK-контент-команда не встигає за EN-командою, чесне рішення — видимий беклог з власником і приблизним таймлайном, а не тиша.
У Stereasoft ми збираємо двомовні Next.js і React Native продукти для клієнтів, що продають через кордони, роблячи це senior-командами на TypeScript і Node.js бекендах. Перемагають ті команди, для яких локаль — архітектура, вирішена ще на discovery, до першого зібраного компонента, а не полірування після демо.