Чому локалізація сайту білоруською ламає верстку та пошук
Білоруську додають як «ще одну мову» — і отримують набір збоїв, які не видно на тестових даних.
Кирилиця в білоруській потребує додаткових символів (ў, і), яких немає в латинських підмножинах шрифту: браузер підставляє системний fallback, метрики рядка змінюються, і текст у кнопці або колонці таблиці обрізається трикрапкою.
Якщо кодування сторінки або бази не переведено на UTF-8 повністю, форма з полем «Імя» віддає знаки питання, а валідація на сервері відхиляє коректне введення.
Дублі сторінок — друга за частотою проблема. Локалізована версія відкривається за окремою адресою без мовних метатегів і канонічних посилань, і пошуковик бачить дві конкуруючі сторінки замість однієї з двома мовними варіантами.
Редиректи за геолокацією погіршують ситуацію: відвідувач з білоруською мовою в браузері потрапляє на переклад, а пошуковий робот — на вихідну версію, і обхід закінчується індексацією не тієї сторінки.
Плюралізація ламає форми інакше. У білоруській три форми множини, і правило «одна форма для всього» дає «5 тавараў» там, де потрібно «5 тавараў», але «2 тавары».
Рядки, зашиті в шаблони та скрипти, при зміні мови залишаються на вихідній — інтерфейс стає наполовину перекладеним, а замовник дізнається про це від користувачів.
Ціна кожного збою — не косметика: обрізаний текст знижує конверсію форми, дублі розмивають позиції, невірний редирект віддає пошуковому роботу не той контент. Розбираємо, як це закривається на рівні конфігурації, а не ручної правки сторінок.
Що дає коректна білоруська версія: швидкість, охоплення, надійність
Зростання частки органічного трафіку з Білорусі
Пошукові системи зіставляють мову сторінки з мовою запиту, тому коректна білоруська версія починає показуватися за запитами, де раніше сайт просто не брав участі.
Якщо мову інтерфейсу проставлено в розмітці сторінки й підтверджено в карті сайту, пошуковик віддає білоруськомовну версію саме тим користувачам, які шукають білоруською.
Частка візитів із Білорусі зростає не за рахунок реклами, а за рахунок запитів, які раніше йшли до конкурентів.
Зниження відмов і зростання конверсії
Людина, яка потрапила на сторінку рідною мовою, швидше знаходить потрібний розділ і рідше йде одразу. Перекладені форми, кнопки й підказки працюють однаково на всіх етапах — від кошика до підтвердження замовлення, тому відвідувач не кидає оформлення на середині.
Окремо перевіряємо відмінювання числівників і відмінки: «1 тавар», «2 тавары», «5 тавараў» — без цього текст виглядає машинним і підриває довіру.
Відсутність дублів і штрафів за них
Білоруська та російська версії живуть на різних адресах і пов'язані перехресними посиланнями із зазначенням мови. Це знімає головну причину дублів: пошуковик розуміє, що перед ним дві локалі одного сайту, а не копії, і не знижує позиції. Канонічні адреси та коректні мовні мітки зберігають накопичену вагу сторінок.
Швидкість завантаження й охоплення аудиторії
Шрифти з підтримкою білоруських символів підключаємо з обмеженим набором накреслень і локально — сторінка не чекає зовнішніх сервісів і не «стрибає» під час відрисовування.
У підсумку сайт однаково швидко відкривається обома мовами, а охоплення розширюється на аудиторію, яка принципово обирає білоруський інтерфейс.
Підходи до локалізації: ручна розмітка, файли перекладів, зовнішні сервіси
Вибір способу зберігання рядків визначає, наскільки швидко команда зможе додавати мови та наскільки передбачувано поводитиметься інтерфейс при відмінюванні числівників. Нижче — три робочі варіанти, між якими реально обирають на старті проєкту.
| Підхід | Коли підходить | Обмеження |
|---|---|---|
| Ручна розмітка в шаблонах | Одна мова, короткий термін, статичний контент | Тексти розкидані по розмітці, друга мова вимагає правок у кожному файлі, плюралізація пишеться вручну |
| Файли перекладів | Багатомовний продукт, команда з редакторами, регулярні релізи | Потрібна дисципліна ключів, при зростанні проєкту — збірка та перевірка на пропуски |
| Зовнішні сервіси | Багато мов, перекладачі поза командою, часті правки тексту | Залежність від зовнішнього сервісу, затримка підвантаження, складніше версіонувати разом із кодом |
Ручна розмітка дає повний контроль над формулюванням, але вже на другій мові перетворюється на борг: будь-яка правка тексту — це пошук по всіх шаблонах, а форми множини доводиться прописувати умовами. Такий варіант виправданий лише для лендінгу з фіксованим набором блоків.
Файли перекладів — базовий сценарій для i18n: рядки винесені в окремі ресурси за локалями, ключі версіонуються разом із кодом, редактор править текст без доступу до розмітки.
Плюралізація описується правилами мови, а не розгалуженнями в шаблоні, тому білоруські форми числівників підставляються коректно для будь-якої кількості.
Зовнішні сервіси знімають із команди синхронізацію перекладів і підходять, коли мов багато і текст змінюється часто. Плата — зовнішня залежність і затримка підвантаження рядків, тому критичні для відрисовки тексти зазвичай тримають локально, а сервіс використовують для решти.
Етапи впровадження білоруської локалізації: від аудиту до передачі
Локалізація — це не переклад рядків у файлі, а зміна схеми даних, шаблонів і збірки. Починаємо з аудиту: дивимося, де текст зашитий у шаблони, де надходить із бази, де формується на стороні сервера, і які місця вже залежать від мови.
На виході — карта рядків із позначкою ризику: динамічні підписи, склеювання фраз, формати дат і чисел, які при зміні мови ламаються першими.
Далі проєктуємо схему ключів і налаштовуємо i18n. Ключі робимо ієрархічними та стабільними, щоб переклад не прив'язувався до верстки, а плюралізація та відмінки описувалися правилами мови, а не умовами в коді.
Рядки виносимо в окремі каталоги, шрифти підключаємо з потрібними накресленнями та запасом за гліфами.
- Аудит локалізації. Інвентаризація рядків, пошук зашитого тексту, оцінка обсягу та точок ризику.
- Схема ключів. Єдиний формат іменування, групи за розділами, правила для змінних і вкладеності.
- Налаштування i18n. Підключення бібліотеки, каталоги перекладів, плюралізація, формати дат, чисел і валют.
- Шрифти та верстка. Підбір накреслень із повним набором символів, перевірка переносів і розтягування блоків.
- Тестування. Прогін сценаріїв білоруською, перевірка довгих рядків, псевдолокалізація, регрес за іншими мовами.
- Документація. Регламент додавання рядків, глосарій термінів, інструкція для контент-менеджера.
- Передача. Демонстрація процесу, доступи до каталогів перекладів, чек-ліст для нових сторінок.
Такий порядок прибирає головну причину зривів — правки у верстці після того, як переклад уже готовий. Рядки та правила фіксуються до наповнення, тому нова мова додається копіюванням каталогу, а не перезбиранням шаблонів. Опишіть ваше завдання — повернемося з оцінкою обсягу та планом робіт.
Артефакти локалізації: файли перекладів, схеми ключів, регламенти
Локалізація — це не лише перекладені рядки, а й набір артефактів, за якими команда далі працює без нас. Нижче — що саме залишається у замовника на руках після виведення білоруської версії.
- Файли перекладів — вихідні каталоги рядків у форматі, який читає ваша платформа (JSON, YAML або PO), з розподілом за просторами імен: інтерфейс, листи, помилки, юридичні тексти. Кожен файл версіонується в репозиторії, тому історія правок і відкат доступні так само, як для коду.
- Карта ключів — таблиця відповідності: ключ, значення білоруською, контекст використання, екран або шаблон, де рядок виводиться. За нею редактор без доступу до коду розуміє, що і де змінювати, а розробник бачить, які ключі ще не задіяні.
- Регламент оновлення — порядок дій при додаванні нового рядка: хто заводить ключ, як він потрапляє до каталогу, які перевірки проходять переклади перед викладенням. Без цього правила локалізація розповзається вже на другому релізі.
- Політики доступу — ролі для перекладачів, редакторів і розробників: хто може правити тексти, хто лише пропонує зміни, хто затверджує. Права розмежовані так, щоб правка рядків не відкривала доступ до решти системи.
- Інструкції для редакторів — як працювати з плюралізацією та відмінковими формами білоруської, які терміни вважаються затвердженими, де дивитися глосарій. Окремо фіксуємо правила для чисел, дат і валют.
- Схема підключення шрифтів і розкладок — які накреслення використовуються для білоруських символів, як перевірено коректність відображення на різних пристроях і в різних браузерах.
- Чек-лист приймання — набір перевірок перед релізом: повнота перекладу, відсутність обрізаних рядків в інтерфейсі, коректна робота перемикача мов, збереження вибору користувача.
Ці артефакти передаємо у вашому репозиторії та у вигляді читабельної документації — щоб підтримку можна було вести власними силами або передати іншій команді без відновлення контексту з нуля.
Кейс: як білоруська версія прискорила завантаження та прибрала дублі
Клієнт — виробник промислового обладнання — вийшов на білоруський ринок із готовим російськомовним сайтом: підставили переклад у шаблон, додали окремий піддомен і запустили.
Через місяць у пошуку індексувалися дві версії кожної сторінки з майже однаковим текстом, а на мобільних сторінка каталогу завантажувалася помітно довше за російську. Розбираємо кейс локалізації за метриками до і після.
Що було до
Дублі виникали через те, що білоруська версія віддавалася без коректних мовних метаданих, а canonical вказував сам на себе в обох версіях.
Пошуковик не розумів, яку сторінку вважати основною, і тягнув в індекс обидві — частка проіндексованих дублів сягала 40% від загальної кількості адрес.
Відмови на білоруській версії були вищими: шрифти підключалися окремим набором файлів, і текст встигав мигнути невидимим до їх завантаження.
Що змінили
Ми перевели локалізацію на єдиний механізм підстановки рядків з роздільними файлами перекладів і коректною плюралізацією — форми для одного, двох і п'яти предметів більше не збиралися вручну в шаблоні.
Для кожної мовної версії проставили взаємні мовні посилання і canonical, а сам піддомен закрили від індексації там, де контент збігався.
Шрифти з кириличними і латинськими накресленнями об'єднали в один набір з обмеженням за використовуваними знаками — браузер перестав тягнути зайві файли.
Що стало
Число проіндексованих дублів упало з 40% до нуля — в індексі залишилася одна версія кожної сторінки. Час завантаження каталогу на мобільних скоротився приблизно на третину, частка відмов на білоруській версії опустилася до рівня російської.
Окремо зазначимо: правки в перекладах тепер вносяться в один файл і підхоплюються на всіх сторінках, без ручної правки шаблонів.
Яндекс та інші пошукові системи такі сигнали враховують однаково — коректні мовні метадані знімають конкуренцію версій між собою.
Чим відрізняється локалізація від перекладу і коли потрібна плюралізація
Переклад — це заміна рядків в інтерфейсі.
Локалізація — це коли сайт поводиться як місцевий: числа, дати, формати адрес, порядок імені та прізвища, розділювачі розрядів, валюта, одиниці вимірювання та правила відмінювання підставляються за правилами мови, а не за залишковим принципом.
Переклали кнопку — отримали переклад. Налаштували i18n — отримали продукт, який не ламається при зміні мови.
Ключова різниця проявляється на динамічних даних. Рядок «5 товарів» при перекладі перетворюється на дві форми, а в білоруській їх більше: «1 тавар», «2 тавары», «5 тавараў». Якщо в коді зашита одна форма, за будь-якої кількості виведеться «тавараў» — і це помітить кожен носій. Тому плюралізація — не прикраса, а обов'язковий шар поверх словника.
Правила відмінювання в білоруській спираються на три категорії: однина, небагаточисельна (2, 3, 4) і множина (5 і більше, а також 11–14). Числівники на кшталт 21, 22, 25 успадковують форму останньої цифри, але 11–14 завжди йдуть за множиною.
Це описується в правилах ICU-плюралізації, і рушій сам вибирає потрібну форму за числом — програмісту не потрібно писати умови вручну.
Окрема історія — відмінки. «1 тавар у кошыку», «2 тавары ў кошыку», «5 тавараў у кошыку» — прийменник і закінчення змінюються разом із числом. Якщо рядки збираються конкатенацією, порядок слів і відмінки розваляться при першій же зміні фрази. Тому локалізація вимагає цілих шаблонів із підстановкою, а не склеювання частин.
Локалізація потрібна, коли аудиторія читає інтерфейс білоруською і очікує природних формулювань: інтернет-магазин із кошиком, особистий кабінет, форма замовлення, повідомлення. Якщо сайт — лише вітрина зі статичних сторінок, достатньо перекладу.
Щойно з'являються числа, дати та відмінювані сутності — без плюралізації та правил мови не обійтися.
Часті технічні сумніви щодо білоруської локалізації
Білоруська локалізація рідко робиться «з нуля» — частіше її вбудовують у працюючий сайт, де вже є маршрутизація, метатеги та накопичена пошукова видача.
Тому ключові сумніви замовника стосуються не самого перекладу, а того, як нова мовна версія уживеться з поточною інфраструктурою і чи не просяде трафік. Розбираємо три найчастіші технічні питання.
У нас уже розгорнутий сайт — чи доведеться все переробляти?
Ні. Ми додаємо мовний шар поверх наявного: тексти виносимо в окремі файли перекладів, маршрути отримують префікс мови, а шаблони залишаються спільними. Старі адреси продовжують працювати через редиректи, тому вже проіндексовані сторінки не втрачають позиції. Переписувати фронтенд повністю не потрібно — змінюється лише шар відображення контенту.
Як підтримувати переклади, коли контент змінюється щотижня?
Рядки зберігаються у структурованих файлах, а не «зашиті» в розмітку, — правку вносить редактор без розробника.
Для текстів із підстановками налаштовуємо правила відмінювання: білоруська потребує трьох форм множини, і це описується в конфігурації плюралізації, а не хардкодиться в шаблонах.
Під час додавання нової сторінки неперекладені ключі підсвічуються автоматично, тож «дірки» не потрапляють у продакшн.
Що з SEO — чи не втратимо позиції в пошуку?
Кожна мовна версія отримує власну адресу та коректні метатеги, а зв'язок між версіями описується через alternate-розмітку — пошуковик розуміє, що це один сайт двома мовами, а не дублі.
Окремо перевіряємо кодування та шрифти: білоруські символи мають відображатися однаково на всіх пристроях, без «квадратиків» і підміни гліфів. Після запуску відстежуємо індексацію обох версій і за потреби коригуємо карту сайту.
Якщо ваш випадок не потрапив у ці три — опишіть задачу, повернемося з оцінкою та планом робіт.
Обговоримо ваше завдання з локалізації сайту білоруською
Щоб оцінка локалізації білоруською була точною, а не «на око», нам потрібен доступ до вихідних кодів або до робочої копії проєкту.
Далі ми дивимося, як влаштований вивід тексту: статичні рядки в шаблонах, рядки з бази, тексти в скриптах і листах — у кожного джерела свій спосіб підключення словників.
Від цього залежить і обсяг робіт, і те, де плюралізація та відмінки потребуватимуть ручних правил, а де обійдеться стандартною конфігурацією.
Окрема частина оцінки — верстка та шрифти. Білоруські «ў» та «і» ламають макети, розраховані на кирилицю без цих знаків: рядки стають довшими, кнопки переносяться, обрізаються заголовки.
Ми заздалегідь перевіряємо, чи підтримують підключені шрифти потрібні глифи, і закладаємо в план заміну гарнітури або налаштування резервних накреслень.
Після розбору ви отримуєте план робіт з етапами, порядком викладки та точками перевірки на проміжних стендах. У план входить і підтримка після запуску: словники поповнюються в міру правок контенту, нові сторінки підключаються до вже налаштованої схеми, а не переписуються з нуля.
Що увійде в роботу:
- інвентаризація всіх джерел тексту та оцінка обсягу перекладу;
- налаштування словників і перемикача мов без втрати поточних адрес сторінок;
- правила плюралізації та відмінювання для білоруської;
- перевірка шрифтів і правка верстки під подовження рядків;
- локалізація службових листів, повідомлень і системних повідомлень;
- тестовий стенд з обома мовами та чек-ліст приймання;
- регламент підтримки та порядок додавання нових рядків.
Опишіть завдання — який у вас проєкт, на якому етапі локалізація і що вже зроблено з перекладу. Повернемося з оцінкою термінів і планом робіт, розкладеним за етапами.
