Локалізація без жалю

Помилки, які ми досі бачимо

Сайт побудовано англійською, через рік перекладено на дві мови і «полагоджено» патчами на роутах назавжди. Відбитки видно одразу: захардкоджені рядки, відсутні переклади на рідкісних сторінках, валюти, що ніколи не змінюються, та пошукова система, що не знаходить половини локалізованого контенту.

Більшість цього — не проблеми перекладу. Це проблеми архітектури. Переклад — найлегше; це єдина частина, яку планують більшість команд, і вона — найменша частка реальної роботи.

П'ять шарів локалізації

Коли кажемо «сайт локалізований», ми насправді маємо на увазі, що продумано п'ять окремих шарів:

Рядки. Видимий текст.
Формати. Дати, числа, валюти, одиниці, схеми адрес.
Контент. Різні історії, продукти, приклади — інколи зовсім різні послуги — для різних ринків.
URL і SEO. Як сайт сигналізує пошуковим системам, що той самий контент існує кількома мовами.
Операції. Редакторський флоу, перекладацький пайплайн, fallback-політика, деплой.

Сайт, який цілить у рядки й ігнорує інші чотири — не локалізований. Це перекладена головна, прикручена до одно-локального продукту.

Переклад — це легка частина

Складна частина — все навколо тексту. URL, slug-и, дати, валюти, одиниці, пагіновані списки, фасети пошуку, sitemap, canonical, hreflang. Кожна з цих речей — рішення, і правильне рішення залежить від локалі, не лише мови.

Короткий перелік того, що — не «просто переклад»:

Дата «12/04/2026» — це який день у цьому ринку?
Ціна, відформатована з правильною валютою, у правильній позиції, з правильним розділювачем тисяч.
Телефон у форматі місцевої конвенції.
Поле імені, що не передбачає, що «ім'я» і «прізвище» мапляться на кожну культуру.
Пошуковий індекс, що знає: «färg» і «farg» — це обидва матч.
Sitemap, що перелічує всі локальні варіанти кожної сторінки.

Команда, що влучає в це з першого дня, виводить чисто. Команда, що це відкладає, патчить це назавжди.

Стратегії URL — оберіть раз, тримайтесь

Три чесні опції, у кожної свої наслідки:

Префікс у підпапці. /en/about, /lv/about, /ua/about. Один домен, один CDN, найпростіша аналітика. Дефолт для більшості команд.
Піддомен. en.site.com, lv.site.com. Корисно, якщо регіонам потрібна інша інфра або DNS-маршрутизація.
TLD по країні. site.com, site.lv, site.com.ua. Найсильніший SEO-сигнал, найскладніша експлуатація.

Також — питання дефолтної локалі. Ми майже завжди радимо прибирати префікс у дефолтної локалі (/about для англійської, /lv/about для латиської). Причини:

Дефолтна локаль несе найбільше трафіку, а короткі URL краще для шерів та реклами.
Існуючі вхідні посилання менше ламаються, коли непрефіксні шляхи лишаються canonical.
Пошуковики обробляють цей кейс добре, якщо hreflang правильно налаштовано.

Оберіть раз. Тримайтесь. Міграція URL-стратегій пізніше — найдорожча форма локалізаційного переробу.

Питання контенту

Більшість команд припускає, що той самий контент перекладається на кожну локаль. Іноді це правильно. Частіше — ні.

Кілька чесних випадків:

Різні послуги. Український ринок може хотіти Telegram-first рішення; латвійський — WordPress-важкі. Переклад не тієї послуги — гірше, ніж її відсутність.
Різні відгуки. Локальне доведення б'є загальне. Покажіть латвійського клієнта латвійському відвідувачу.
Різні кейси. B2B-аудиторія одного ринку може відгукуватись на SaaS-кейс; інша — ні.
Різна преса і партнерства. Локальні сигнали довіри важливі.

Якщо ваша CMS моделює лише «один шматок контенту, перекладений тричі», ви впрешся в цю стіну швидко. Плануйте під модель, де частина контенту спільна, частина — на локаль. Це реальне інженерне рішення, не налаштування.

hreflang як треба

Найбільш неправильно сконфігурований тег у сучасному вебі. Правила, що тримаються:

Кожна сторінка в кожній локалі перелічує всі інші локальні варіанти.
Сторінка перелічує себе (self-referential).
Використовуйте x-default для безлокального fallback (зазвичай English).
Значення hreflang точно збігаються з URL — код мови, код країни, якщо є.

Робочий hreflang каже Google, яку сторінку показати латвійському користувачу з Риги. Зламаний означає, що пів-часу показується не та мова. Аудит — пів дня, окупається за тиждень.

Стратегія форматів

Формат	Дефолт	Часта помилка
Дати	Серверний рендер, locale-aware	Форматування в клієнті через `Date()`
Валюти	Locale-aware, ISO-код видно	Захардкоджений "$" чи "€"
Числа	`Intl.NumberFormat`	`toLocaleString()` без локалі
Множина	ICU MessageFormat	`count === 1 ? "item" : "items"`
Імена	Одне поле повного імені	Примусове розщеплення first/last
Адреси	Locale-aware порядок полів	US-формат полів у кожному ринку

Кожен рядок — поріз від паперу окремо. Разом вони кажуть клієнту, що сайт побудовано не під нього.

Що закриваємо до виводу

Чек-лист, який тримаємо в кожному мультилокальному проєкті:

Список усіх рядків у коді, у файлі перекладів, без захардкодженого тексту в компонентах.
Список усіх locale-aware форматів із правилом, коли який вживається.
Fallback-політика. Що робити, коли переклад відсутній — показувати дефолт? показувати ключ? валити білд? Оберіть і задокументуйте.
Спосіб додати четверту локаль без правки коду компонентів. Якщо додати «fr» — це зміни в 40 файлах, архітектура не та.
Статичний рендер-пайплайн, що не штрафує менші локалі гіршою продуктивністю.
hreflang і sitemap, що переживають зміни контенту.
Staging, який будь-хто в команді може дивитись у будь-якій локалі.
Перекладацький воркфлоу, яким редактори реально користуються.

Команди, що закривають це з першого дня, виводять із трьома локалями. Команди, що відкладають — виводять з однією і ніколи повністю не наздоганяють.

Погляд редактора

Локалізований сайт настільки хороший, наскільки добрий воркфлоу, що породжує переклади. Питання, на які треба відповісти до запуску:

Хто пише source-of-truth-рядок?
Хто перекладає, і як він знає, що нове?
Як переклади ревьюються до публікації?
Що відбувається, коли вихідний рядок змінюється після перекладу?
Як редактор переглядає локаль, мовою якої не володіє?

Якщо відповідь на щось — «розберемось пізніше», ви розберетесь. Просто аж після третього зірваного дедлайну.

Коли не локалізувати

Деякі сайти не варто локалізувати взагалі. Патерн:

B2B-продукт із одним глобальним ринком.
Нішевий сервіс, де аудиторія розмовляє одною мовою за вибором.
Команда до product-market-fit, де бюджет краще витрачати на продукт.

Локалізація — це важіль. Це і накладні. Якщо аудиторія не ділиться чітко за мовою, накладні можуть переважити важіль. Обирайте чесно.

Що ми реально віддаємо

Коли команда замовляє мультилокальний білд:

Типобезпечний пайплайн перекладів із валідацією під час білду.
Статичний експорт по локалях із правильним hreflang.
CMS-модель, що підтримує і спільний, і локальний контент.
Staging-середовище з перемикачем локалі, видимим усій команді.
Документований воркфлоу для додавання нової локалі.
Тестовий набір, що валить білд на відсутньому ключі.

Сайт, побудований так, масштабується на чотири, п'ять, шість мов, не стаючи кошмаром підтримки. Сайт, побудований без цих рішень, застрягає на двох.