Професійне налаштування української локалізації сайту під ключ

Українська локалізація сайту: де ламається верстка та логіка

Українська локалізація сайту ламається не на перекладі, а на інженерних деталях, яких перекладач не бачить. Класичний збій — кодування: файли перекладів зберегли в однобайтовому кодуванні замість UTF-8, і замість «ї», «і», «є», «ґ» на сторінці з'являються ромби або кракозябри.

Проблема випливає не одразу: на тестових даних з латиниці все чисто, а на реальному контенті розсипається половина карток товарів і листів.

Друга міна — довжина рядків інтерфейсу. Українські формулювання в середньому на 10–20% довші за російські, а в кнопках, табах і хлібних крихтах місце жорстко обмежене фіксованою шириною.

Кнопка «Сохранить» перетворюється на «Зберегти зміни» і виштовхує сусідній елемент за межу контейнера, а на мобільній ширині верстка з'їжджає повністю.

Далі — логіка, якої не видно в макеті. Сортування за алфавітом в українській будується інакше: «ґ» іде після «г», апостроф і м'який знак поводяться не як у російській розкладці, і стандартний компаратор без явної локалі вибудовує списки міст і категорій у неправильному порядку.

Форми ламаються на валідації: маска телефону під інший формат, відмінювання в листах «Вітаємо, {ім'я}» без урахування роду, дати у форматі, який парсер бази не приймає.

Окремо — пошук і фільтри: без нормалізації регістру та приведення апострофа до єдиного вигляду запит «Львів» не знаходить «Львів», а «ім'я» та «ім’я» вважаються різними рядками. Кожен такий дефект коштує грошей на підтримці та втрачає конверсію на рівному місці.

Розбираємо, як це закривається на рівні збірки, а не косметичними правками.

Що змінюється після коректної локалізації

Українська локалізація сайту — це не переклад рядків в інтерфейсі, а приведення всіх шарів продукту до норм мови та очікувань місцевої аудиторії.

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

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

Коли всі стани форми перекладені та узгоджені за тоном, людина проходить шлях до кінця без зайвих сумнівів, і конверсія форм зростає без змін у самій пропозиції.

Пошук по сайту — другий індикатор якості. Він має враховувати українську морфологію: відмінки, число, різні варіанти написання запиту.

Якщо пошуковий індекс зібрано за правилами мови, а не за прямим збігом рядків, користувач знаходить потрібний розділ з першої спроби, а не йде до конкурентів через зовнішній пошуковик.

Візуальні дефекти зазвичай проявляються там, де українські слова довші за звичні: кнопки, меню, заголовки карток, таблиці.

Ми перевіряємо макети на реальних текстах, а не на «рибі», тому переноси, міжрядкові інтервали та вирівнювання залишаються охайними на всіх роздільних здатностях.

Окремо проходимо службові сторінки, листи та повідомлення — їх часто забувають, а саме вони формують довіру аудиторії.

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

Наші інженери закривають локалізацію як інженерну задачу — від структури контенту до перевірки на живих сценаріях, тому ефект видно в метриках, а не лише в текстах.

Підходи до локалізації: ручний, автоматичний, гібридний

Вибір режиму локалізації — не питання смаку, а інженерне рішення з передбачуваними наслідками для строків, якості та вартості підтримки. Розглянемо три підходи, між якими реально обирають на проєктах.

Як обирають на практиці

Ручний переклад дає еталонну якість, але погано масштабується: кожна правка вихідного тексту запускає цикл заново. Машинний переклад закриває обсяг за хвилини, однак без глосарію він ламає однаковість — одне й те саме поняття в різних розділах звучить по-різному.

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

При оновленні сторінки система підсвічує змінені рядки — підтримка перекладів перестає бути повним перезбиранням.

Ми підбираємо режим під тип контенту та частоту релізів, а не під єдиний шаблон: інтерфейс і юридичні блоки йдуть через ручний контур, каталог — через гібридний. Це тримає якість української локалізації стабільною при кожному оновленні сайту.

Етапи впровадження української локалізації

Локалізація — це не переклад рядків, а зміна архітектури застосунку: рядки виносяться з коду в ресурси, підключається механізм вибору мови, а верстка перевіряється на стійкість до іншого алфавіту та довжини фраз. Нижче — послідовність робіт, яку ми проходимо на кожному проєкті, від аудиту до передачі.

1. Аудит локалізації. Скануємо код і шаблони: знаходимо рядки, вшиті прямо в розмітку та логіку, дати й числа у жорсткому форматі, тексти у зображеннях і листах. Фіксуємо обсяг і складаємо карту місць, куди доведеться втручатися.
2. Схема перекладу. Визначаємо структуру ресурсів — файли за розділами або єдиний каталог, ключі, вкладеність, правила для форм множини. Узгоджуємо, як українська версія співвідноситься з основною: окремі адреси, піддомен або перемикач на тій самій сторінці.
3. Налаштування словників. Підключаємо ресурси до застосунку, налаштовуємо визначення мови за адресою, заголовком браузера та вибором користувача зі збереженням у cookie. Заводимо службові рядки: кнопки, помилки, листи, повідомлення.
4. Перенесення текстів. Перекладаємо з урахуванням контексту екрана, а не за окремими фразами, — інакше «Зберегти» у формі та в налаштуваннях отримають різні формулювання. Терміни звіряємо за глосарієм, щоб назва функції не змінювалася від сторінки до сторінки.
5. Перевірка верстки. Проганяємо українські тексти на всіх ключових роздільних здатностях: вони довші за російські на 10–15%, через що ламаються кнопки, меню та таблиці. Правимо переноси, ширину блоків, відступи, перевіряємо сортування та регістр.
6. Тестування сценаріїв. Проходимо форми, замовлення, пошук, листи та повідомлення українською — від валідації полів до коректних дат і розділювачів чисел.
7. Передача проєкту. Віддаємо доступи, інструкцію щодо додавання рядків і правки перекладів, щоб команда могла оновлювати тексти без розробника.

Порядок важливий: якщо почати з перекладу, а не з аудиту, частину рядків доведеться переробляти після того, як з'ясується їхнє реальне розташування в коді. Опишіть завдання — повернемося з оцінкою та планом для вашої платформи.

Артефакти та документація після локалізації

Локалізація закінчується не моментом, коли українська версія відкрилася в браузері, а коли команда замовника може її самостійно супроводжувати. Тому весь результат ми передаємо у вигляді файлів, схем і регламентів — не «на словах», а в репозиторії поруч із кодом.

• Файли перекладів за локалями (uk, ru, en) у стандартному форматі обміну — їх можна відкрити в будь-якій CAT-системі та віддати зовнішньому перекладачу без перезбирання проєкту.
• Схема словників: які сутності лежать у базі, які у файлах, який ключ вважається джерелом істини при розбіжності.
• Регламент оновлення: хто і в який момент додає нові рядки, як вони потрапляють в українську версію, що відбувається зі старими перекладами при зміні вихідного тексту.
• Інструкція редактора — покроковий документ для контент-менеджера: де правити текст, як перевірити, що правка пішла на прод, як відкотити невдалу версію.
• Карта маршрутів і мовних префіксів: відповідність адрес між локалями, правила редиректів, налаштування канонічних посилань і hreflang.
• Чек-лист приймання української версії: покриття сторінок, коректність форм і листів, поведінка при перемиканні мови, відсутність неперекладених фрагментів.
• Список точок інтеграції із зовнішніми сервісами (платежі, доставка, повідомлення) з позначкою, які з них уже віддають українську мову, а які потребують окремого налаштування.
• Журнал рішень: чому вибрано той чи інший варіант перекладу спірних термінів, щоб через пів року ніхто не переспорив уже прийняте.

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

Кейс: усунення дефектів української локалізації на інтернет-магазині

Клієнт — інтернет-магазин з аудиторією в Україні — звернувся із завданням: українська версія формально є, але конверсія в ній помітно нижча за російську.

Почали з діагностики: зібрали статистику за формами оформлення замовлення, пошуковими запитами та зверненнями до підтримки за два тижні до правок.

Google Search Console і логи сервера показали картину, якої замовник не бачив: частина сторінок віддавала російські метатеги при українському URL, пошук за українськими запитами повертав порожній результат на 40% запитів через відсутність словоформ, а форми приймали кирилицю з апострофами як невалідний ввід.

Що було до правок

• Частка помилок при заповненні форм — 18% від усіх спроб оформлення замовлення.
• Пошук за українськими запитами без результату — 40% звернень до рядка пошуку.
• Звернення до підтримки зі скаргами на «не працює українською» — 12% від загального потоку тікетів.

Що змінили

Переписали валідацію форм під українську розкладку: апостроф, ґ, ї, є перестали вважатися спецсимволами. Налаштували морфологічний пошук з урахуванням відмінкових форм української мови.

Привели метатеги, hreflang і sitemap до єдиного стандарту — українські URL віддають лише український контент.

Що стало після

Частка помилок у формах упала до 4%. Пошук за українськими запитами тепер знаходить результат у 94% випадків. Звернення до підтримки щодо локалізації скоротилися втричі — з 12% до 4% від потоку. Конверсія української версії за місяць зрівнялася з російською.

Кейс показав головне: локалізація — це не переклад тексту, а робота з формами, пошуком і метаданими. Саме там ховаються дефекти, яких не видно при побіжному огляді сайту.

Чим відрізняється локалізація від перекладу та транслітерації?

Переклад — це перенесення сенсу тексту з однієї мови на іншу. Локалізація ширша: вона змінює весь продукт так, щоб український користувач сприймав його як зроблений для нього.

Переклад відповідає за формулювання, локалізація — за формати дат, порядок імені та прізвища, розділювачі в числах, валюту, одиниці вимірювання, розкладку форм і логіку адрес.

Один і той самий текст може бути перекладений бездоганно, але інтерфейс залишиться чужим, якщо дата стоїть у форматі місяць/день, а поле «область» відсутнє.

Транслітерація вирішує вузьке завдання: передати українськими літерами імена, назви компаній, адреси та реквізити там, де оригінальне написання технічно неможливе — у платіжних документах, банківських виписках, полях доставки.

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

Адаптація інтерфейсу — третій шар. Це не про літери, а про поведінку продукту: довжина українських рядків помітно більша за англійські, і кнопка, розрахована на коротке слово, ламає верстку.

Змінюються сортування списків з урахуванням алфавіту, відмінювання в шаблонах листів, формати телефонів, структура адреси, порядок полів у формах.

Окремо — термінологія: один і той самий термін має звучати однаково в інтерфейсі, листах, документації та довідці, інакше користувач втрачає орієнтацію.

Культурні особливості — те, що не видно у словнику: звертання на «ви» чи «ти», доречність прямої формулювання, місцеві свята та графік роботи підтримки, звичні способи оплати.

Ми розводимо ці шари на старті проєкту, щоб не перекладати те, що потрібно адаптувати, і не транслітерувати там, де потрібен повноцінний переклад.

Часті технічні питання щодо української локалізації

Локалізація — це не переклад рядків у шаблоні, а набір інженерних рішень, які зачіпають кодування, маршрутизацію, валідацію форм і логіку сортування. Нижче — відповіді на сумніви, які найчастіше виникають на етапі оцінки.

Що з кодуванням і українськими символами?

Усе зберігається й віддається в UTF-8 на рівні бази, з'єднання та заголовків відповіді — інакше «і», «ї», «є» та апостроф перетворюються на сміття під час запису в базу й зворотної видачі.

Окремо перевіряємо нормалізацію апострофа: він надходить із форм у різних варіантах, і без приведення до однієї форми пошук за рядками починає промахуватися.

Як працюють форми та валідація українською?

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

Дати, числа та сортування — де ламається?

Дати й числа форматуємо через локаль, а не рядковими шаблонами: порядок день-місяць, розділювачі розрядів і десяткова кома відрізняються від звичних.

Сортування списків іде за правилами українського алфавіту з урахуванням літер, яких немає в латиниці, — звичайне сортування за кодом символу дає неправильний порядок.

Чи можна додати українську версію без переписування сайту?

Так, якщо контент та інтерфейсні рядки винесені у словники, а маршрутизація підтримує мовний префікс. Тоді локалізація — це новий набір перекладів і налаштування правил, а не другий сайт. Якщо рядки зашиті в шаблони, спочатку виносимо їх у словник, далі процес іде передбачувано.

Обговоримо ваше завдання з локалізації

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

Далі фіксуємо план локалізації: структура адрес, перемикач мови, поведінка за відсутності перекладу, що робити з уже проіндексованими сторінками. Оцінку робіт і терміни даємо після того, як побачимо реальний обсяг рядків і типи контенту, — не «на око», а за фактом.

Що варто винести на першу розмову:

• які розділи й шаблони перекладаємо в першу чергу, а які можна в другу;
• де зберігаються тексти й як їх зручніше віддавати на переклад і правки;
• чи потрібна окрема українська версія з власними адресами або перемикач усередині сторінки;
• як бути з формами, листами, повідомленнями та службовими текстами;
• що робити з уже наявними сторінками й як не втратити поточний трафік;
• хто з боку замовника ухвалює формулювання й як швидко дає зворотний зв'язок;
• чи потрібна підтримка після запуску — правки, нові сторінки, оновлення текстів.

Консультація інженера на цьому етапі — це розбір вашої ситуації, а не продаж. Ми ставимо запитання, дивимося на структуру й повертаємося з оцінкою та планом локалізації: що робимо, у якому порядку, скільки це займе. Опишіть завдання — сайт, обсяг, терміни, що вже зроблено, — і ми повернемося з конкретикою.