Багатомовність Drupal: де ламається структура сайту
Багатомовність Drupal ламається не на етапі вмикання мов, а пізніше — коли контент починає жити своїм життям. Типова картина: матеріал перекладено, але його мовна версія отримала окрему адресу замість прив'язки до вихідного вузла.
Пошуковик бачить два самостійні документи з однаковим змістом, і обидві сторінки просідають у видачі — дублікати контенту розмивають вагу між версіями.
Друге джерело проблем — розсинхронізація перекладів. Частину полів перекладено, частина залишилася мовою оригіналу, а інтерфейсні рядки підтягуються з окремого набору і живуть за своїм розкладом.
У підсумку користувач бачить суміш мов на одній сторінці, а редактор не розуміє, яку версію він редагує і чи не затрé збереження чужий переклад.
Третій шар — помилки hreflang. Якщо в розмітці вказано неіснуючі адреси, переплутано коди регіонів або відсутнє зворотне посилання, пошуковик просто ігнорує підказки. Тоді мовні версії конкурують між собою, а потрібна аудиторія потрапляє не на ту сторінку.
Для підтримки це обертається тим, що кожна правка вимагає ручної перевірки адрес і зв'язків між версіями.
Окремо варто розглянути структуру мовних версій: вибір між перекладом вузлів, окремими матеріалами під кожну мову та доменною схемою визначає все подальше — від вартості правок до поведінки в пошуку.
Розбираємо, як вибудувати багатомовність Drupal без дублів, з коректним hreflang і передбачуваною підтримкою.
Що дає коректна мовна архітектура
Коректна мовна архітектура починається з того, що контент існує в одному екземплярі, а мовні версії — це його представлення.
У Drupal за це відповідають сутності з увімкненим перекладом полів і зв'язкою через langcode: правка вихідної сторінки не вимагає повторювати її в кожній мові, а переклади підтягуються до актуальної структури.
Якщо архітектура зібрана правильно, публікація нової мовної версії займає хвилини, а не години ручного копіювання.
Другий ефект — передбачувана індексація. Коли в кожної версії є власна адреса, коректний hreflang і канонічний тег, пошукові системи бачать різні мовні сторінки, а не дублі одного тексту.
Частка сторінок без дублів зростає, а разом із нею — і видимість у локальних видачах: відвідувач із потрібного регіону потрапляє на свою версію, а не на англомовну заглушку.
Третій ефект — стійкість до правок. Коли змінюється структура каталогу або шаблон картки, зміни застосовуються до всіх мов одразу, бо джерело контенту одне. Не доводиться звіряти десятки сторінок вручну й ловити розбіжності, які зазвичай спливають уже після релізу.
Швидкість публікації перекладів, частка сторінок без дублів і передбачуваність правок — це не абстрактні побажання, а вимірювані показники, які закладаються в архітектуру на старті. Саме тому ми розбираємо мовну модель до початку верстки, а не правимо її після запуску.
Способи організації перекладів: порівняння підходів
У Drupal переклад контенту та переклад інтерфейсу — два незалежні механізми, і плутати їх дорого: рядки інтерфейсу живуть у файлах перекладу та оновлюються окремо від сутностей, а самі сутності (матеріали, таксономія, меню, поля) отримують переклади на рівні бази.
Якщо вибрати спосіб під задачу неправильно, отримуєш або дублі матеріалів, або неперекладені підписи у формах і листах.
Другий шар вибору — як мови видно в адресах. Мовні префікси (/en/, /de/) простіші в налаштуванні та не потребують окремих сертифікатів, мовні домени дають чисті адреси та краще підходять, коли в мови своя аудиторія та своя пошукова видача. Зміна цього рішення після запуску — це переїзд усіх адрес, тому фіксуємо його до наповнення.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Переклад сутностей (вбудований) | Контент і таксономія, де переклади пов'язані між собою | Кількість мов і полів зростає — зростає обсяг бази; зв'язки між перекладами потрібно підтримувати |
| Переклад інтерфейсу через файли | Рядки тем, форм, листів, системні підписи | Не покриває контент; оновлення модуля може перезаписати рядок |
| Єдиний контент з мовними полями | Прості типи, де переклад — це одне-два поля | Не масштабується на великі обсяги, ламає пошук і фільтри |
| Мовні домени | Окрема видача та бренд на мову | Потрібні сертифікати, окреме налаштування редиректів і канонічних адрес |
| Мовні префікси | Швидкий старт, один домен | Слабше розводяться мови в пошуку, складніше з регіональними версіями |
На практиці майже завжди комбінують: сутності перекладають вбудованим механізмом, інтерфейс — файлами, а спосіб адресації вибирають за кількістю мов і вимогами до пошуку.
Обмеження, яке спливає пізніше за всіх, — спільний контент на кшталт цін або характеристик: його або дублюють за мовами, або виносять в окрему сутність зі зв'язками, і це рішення теж краще ухвалити до наповнення.
Етапи налаштування багатомовного сайту
Багатомовність у Drupal — це не встановлення модуля, а проєктування структури: від неї залежить, як пошуковики побачать версії сторінок і як редактори працюватимуть із ними.
Порядок робіт вибудовуємо так, щоб дублі адрес і розсинхрон перекладів не з'являлися на етапі введення контенту, а не лікувалися потім редиректами.
- Аудит мовної структури. Дивимося поточні матеріали, таксономії, меню та шаблони: що перекладається повністю, що залишається спільним, де контент уже задубльований. Фіксуємо цільові мови та регіональні варіанти, щоб не закладати зайві сутності.
- Схема мов і правила перекладу. Визначаємо, які типи матеріалів і поля перекладаються, що успадковується без перекладу, як ведемо мовну прив'язку термінів. На цьому кроці задаємо режим перекладу — ручний, зі спільним джерелом або змішаний.
- Налаштування перекладів. Вмикаємо потрібні мови, налаштовуємо типи матеріалів, поля та таксономії, підключаємо модулі перекладу інтерфейсу й контенту. Окремо перевіряємо, що редактор бачить лише релевантні мовні вкладки й не плодить копії.
- Перевірка адрес і розмітки. Налаштовуємо шаблони шляхів із мовним префіксом, виключаємо дублі, перевіряємо канонічні адреси та коректність мовних міток. Прогоняємо карту сайту й переконуємося, що кожна версія вказує на альтернативи.
- Тестування сценаріїв. Перевіряємо перемикання мов, поведінку за відсутності перекладу, роботу пошуку й форм, редиректи зі старих адрес. Окремо дивимося, як поводиться сайт при додаванні нової мови.
- Передача документації. Віддаємо регламент: які поля перекладати, як додавати мову, як перевіряти адреси перед публікацією. Плюс карта поточної структури та список відомих обмежень.
Такий порядок знімає головний біль багатомовних проєктів — розходження версій і дублі у видачі. Редактори працюють за зрозумілими правилами, а пошуковики отримують однозначну картину мовних версій.
Артефакти та документація після впровадження
Після впровадження мультимовності Drupal замовник отримує не «набір налаштувань», а комплект, за яким команда може працювати без нас: конфігурації, схеми адресації, регламенти та правила редиректів. Нижче — що саме передаємо на руки і навіщо кожен артефакт потрібен у щоденній роботі.
- Експорт конфігурації мов — які мови увімкнено, яка з них базова, як налаштовані префікси та визначення мови за адресою. Дозволяє розгорнути ту саму конфігурацію на стенді та проді без ручного складання.
- Схема адрес і перекладів — таблиця «мова → шаблон адреси → джерело перекладу», щоб новий контент отримував коректну адресу і не з'являвся дубль.
- Правила редиректів і канонічних адрес — карта перенаправлень зі старих адрес на нові та налаштування, що унеможливлюють склеювання мовних версій у пошуку.
- Регламент публікації — порядок дій редактора: яка мова заповнюється першою, як пов'язуються переклади, що перевіряється перед публікацією.
- Документація перекладів — глосарій термінів і правила оформлення, щоб різні редактори не розходилися у формулюваннях.
- Інструкція з hreflang — які зв'язки мов проставляються автоматично, а які задаються вручну і чому.
- Чек-лист приймання — набір перевірок: коректність адрес, відсутність дублів, робота перемикача мови, індексація кожної версії.
- Журнал змін конфігурації — що і коли змінювалося в налаштуваннях мов, щоб при збої швидко відкотитися до робочого стану.
Кожен артефакт закриває конкретний ризик: дублі в пошуку, втрачені переклади, зламані адреси після релізу. Опишіть задачу — повернемося з оцінкою та планом передачі документації.
Кейс: усунення дублів і розсинхрону перекладів
Корпоративний сайт на Drupal з чотирма мовними версіями: контент-редактори скаржилися, що переклади «губляться», а пошукова видача показувала різні адреси для однієї й тієї самої сторінки.
Аудит підтвердив найгірше: 38% проіндексованих адрес були дублями — матеріал російською відкривався і за основним шляхом, і за службовим з мовним префіксом, а мовні мітки на частині сторінок посилалися на самих себе замість альтернатив.
Що було до
Переклади жили окремими матеріалами, пов'язаними між собою вручну. Редактор публікував російську версію, потім копіював її та перекладав — зв'язки між копіями рвалися за будь-якого оновлення вихідника.
Середній час від публікації оригіналу до появи перекладу — 6 робочих днів, бо половину кроків робили вручну й звіряли очима.
Що змінили
Перевели контент-модель на штатний механізм перекладів: один матеріал з мовними версіями замість набору копій. Зв'язки між версіями тепер веде система, а не редактор — при оновленні вихідного матеріалу переклад позначається як застарілий і потрапляє в чергу на актуалізацію.
Мовні мітки збираються автоматично з набору опублікованих перекладів, службові адреси закриті від індексації, а канонічна адреса вказує на мовну версію, а не на загальний шаблон.
Що стало
Частка дубльованих сторінок в індексі впала з 38% до 2% — залишилися тільки усвідомлені винятки для схожих матеріалів. Час публікації перекладу скоротився з 6 днів до кількох годин: редактор працює з однією формою, а не з копіями.
Мовні мітки коректні на 100% перевірених сторінок, взаємні посилання між версіями більше не губляться при оновленнях.
Окремий ефект — передбачуваність. Раніше ніхто не міг сказати, скільки матеріалів реально перекладено: копії розходилися, частина жила без зв'язку з оригіналом.
Тепер зведення за мовами будується із самої системи, і прогалини в перекладах видно одразу, а не спливають у скаргах від регіональних команд.
Чим відрізняється переклад сутностей від перекладу інтерфейсу?
У Drupal це два незалежні шари локалізації, і плутати їх не можна. Переклад інтерфейсу — це рядки, які формує сама система та модулі: підписи полів, кнопки, листи, тексти помилок. Вони зберігаються окремо від контенту і підтягуються на етапі виведення сторінки.
Переклад сутностей — це вже дані: матеріали, таксономія, меню, блоки, користувацькі поля. Тут у кожної мовної версії свій набір значень, своя дата публікації та свій статус.
Різниця підходів безпосередньо впливає на структуру. Інтерфейсні рядки не створюють нових вузлів — один запис обслуговує всі мови, тому додавання мови не роздуває базу.
Сутності ж при увімкненому перекладі отримують окрему ревізію на кожну мову: в англомовної версії статті свій URL-аліас, свої метатеги, свої прив'язані файли.
Якщо переплутати шари — наприклад, завести «англійську версію» як новий матеріал замість перекладу — отримаєте дублі в карті сайту, розбіжні посилання та розсинхрон при оновленні.
На практиці це означає різну тактику підтримки. Рядки інтерфейсу оновлюються централізовано: правиш один — змінюється скрізь, де він виводиться. Контентні переклади правляться поштучно, і тут важливо, щоб редактор бачив, яка версія застаріла після правки вихідної.
Ми на старті фіксуємо, що саме перекладається як сутність, а що як рядок, — це знімає половину майбутніх питань «чому на одній сторінці старий текст».
Окремо варто зупинитися на синхронізації полів. Спільні для всіх мов значення — наприклад, артикул або зображення — виносимо в неперекладні поля, щоб не дублювати їх у кожній версії. Тоді структура залишається плоскою, а редактор не витрачає час на повторне введення.
Часті технічні сумніви щодо багатомовності
Багатомовність майже завжди впроваджують на працюючий сайт, а не на порожній: контент уже проіндексовано, посилання розійшлися зовнішніми джерелами, аналітика накопичена. Тому перше питання — не «як увімкнути другу мову», а «як не втратити те, що вже ранжується».
Що робити, якщо сайт уже розгорнуто і він приносить трафік?
Додаємо мови поверх поточної структури, не чіпаючи адреси основної. Базова мова залишається на попередніх шляхах, нові отримують префікс — так зовнішні посилання та накопичені сигнали зберігаються.
Далі закриваємо технічну частину: налаштовуємо зв'язку перекладів між матеріалами, вмикаємо визначення мови браузера з можливістю ручного перемикання та перевіряємо, що перемикач веде на той самий матеріал, а не на головну. Окремо стежимо за картою сайту: вона має містити всі мовні версії з коректними мітками.
Як уникнути дублів і не втратити позиції?
Дубль виникає, коли мовні версії віддають однаковий контент або коли переклад існує, але не пов'язаний з оригіналом. Лікується це зв'язкою перекладів на рівні матеріалів і коректними мовними мітками: кожна версія вказує на себе та на всі інші, включно з базовою.
Якщо переклад ще не готовий, сторінка не повинна відкриватися з порожнім вмістом — краще віддати базову версію з позначкою мови, ніж плодити порожні адреси, які пошуковик вважатиме дублями.
Як перевіряти мовні мітки та міграцію перекладів?
Перевірка мовних міток — регулярна процедура, а не одноразове налаштування: звіряємо, що кожна версія посилається на повний набір альтернатив, що мітки не ведуть на неіснуючі адреси і що базову мову вказано коректно.
Під час міграції перекладів переносимо не лише тексти, а й зв'язки між версіями — інакше після переїзду матеріали розпадаються на незалежні сторінки, і мовні мітки доводиться збирати заново. Прогоняємо перевірку до і після міграції, порівнюючи кількість пов'язаних пар.
Якщо сумнів не закрився — опишіть вашу структуру та поточний стан мов, повернемося з оцінкою та планом робіт.
Обговоримо задачу щодо мультимовності Drupal
Щоб повернутися з оцінкою та планом, а не із загальними словами, нам потрібно зрозуміти поточний стан проєкту.
Надішліть доступ до репозиторію та конфігурації (експорт конфігурації, файли перекладів, налаштування мовного визначення) — за ними ми проведемо аудит мультимовності та побачимо, де дублюється контент, як влаштовані зв'язки перекладів і що з hreflang.
- Адреси сайту та список мов: які локалі активні, чи є мовні домени або підпапки, як визначається мова відвідувача.
- Як зараз влаштований контент: переклади через зв'язки сутностей, окремі матеріали на мову або спільний шаблон із полями перекладу.
- Джерела перекладів: ручне введення, файли імпорту, зовнішній сервіс — і хто відповідає за синхронізацію.
- Поточні проблеми: дублі сторінок у видачі, «стрибуча» мова, зламані перемикачі, розбіжності в метатегах.
- Вимоги до SEO: чи потрібні окремі адреси під кожну мову, як мають виглядати canonical і hreflang.
- Обмеження: терміни, порушені розділи, інтеграції із зовнішніми системами та каталогами.
Після аудиту ми повернемося з оцінкою та планом: розкладемо роботи за етапами, вкажемо терміни впровадження та ризики міграції. Якщо частина контенту вже перекладена, покажемо, як перенести її без втрати зв'язків і позицій. Опишіть задачу — обговоримо деталі та запропонуємо рішення під ваш проєкт.
