Локалізація Contentful: де ламається багатомовний контент
У Contentful багатомовність — властивість моделі, а не окремий модуль: кожне поле запису або локалізоване, або спільне для всіх локалей. Перший збій росте саме звідси — заголовок і текст позначені як локалізовані, а частина адреси, обкладинка й метаполя залишилися спільними.
Англійська версія відкривається, але адреса й прев’ю в ній російські: це вже не переклад, а суміш мов.
Далі — розсинхрон перекладів. Редактор правит текст у базовій локалі, переклад оновлюється вручну й відстає; чим частіше виходять правки, тим ширша розбіжність, і через місяць ніхто не скаже, яка версія актуальна.
Резервна локаль маскує проблему: відвідувач бачить підставлений текст основної мови й не розуміє, чому половина сторінки чужа.
Окрема історія — дублі записів.
Якщо локалізацію не налаштували одразу, команда заводить по запису на кожну мову й пов’язує їх вручну: зв’язки рвуться при першому перейменуванні, асети дублюються, реєстр зростає швидше за контент, а дві версії починають конфліктувати за однією й тією самою адресою.
Зверху лягає перемикач мови. Він будується за списком локалей у просторі, а не за фактом наявності перекладу, тому натискання на іншу мову веде на порожню сторінку або на биту адресу версії — частина адреси не локалізована, маршрут зібраний за старим шаблоном. Нижче розбираємо, як це закривається на рівні моделі, маршрутів і збірки.
Що дає керована багатомовність сайту
Мовна версія — це не копія сторінки, а окремий запис із локаллю та правилом підстановки. Коли схема версій описана в моделі контенту, а не в шаблонах, редактор наповнює сторінку новою мовою тими самими полями, що й основною, а розробник не переносить розмітку вручну.
У Contentful локалі, зв’язки між версіями та історія змін живуть в одному сховищі — звідси й керованість.
Чотири ефекти, які видно в метриках.
- Строк випуску сторінки. Нова мова збирається з готових блоків: перекладається текст, структура й компоненти використовуються повторно. Замість викладання окремої копії зі своєю версткою — публікація локалі в тому самому дереві.
- Обсяг ручних правок. Підстановка налаштовується за полем: порожній переклад показує значення мови за замовчуванням. Розділ відкривається, не чекаючи повного перекладу, а правка тексту не розходиться по копіях.
- Клас відмов. Мовні адреси та зв’язки між версіями будуються з даних, а не з ручних списків. Зникає типовий збій, коли після релізу частина локалей віддає основну мову або губить сторінку.
- Частка зарубіжного трафіку. Відвідувач потрапляє на свою мову з першого заходу й залишається на ній. Зростає частка візитів на локальній версії та глибина перегляду, бо перемикати мову вручну не потрібно.
Схема версій задає й порядок роботи: нову локаль вмикають налаштуванням, а не окремим проєктом.
Моделі локалізації Contentful: порівняння варіантів
Contentful зберігає мовні версії двома різними способами: переклад на рівні поля всередині запису або окремий запис під кожну мову.
Моделі локалізації відрізняються не лише зберіганням — від них залежать схема адрес, підстановка відсутніх перекладів і права редакторів, а зміна моделі посеред проєкту коштує дорожче, ніж вибір на старті.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Мова як поле запису | Набір полів однаковий для всіх мов, переклади публікують синхронно | Одна схема на всі мови: поле під окремий ринок не додати, права на мову не роздати |
| Окремий запис на мову | У ринків свої поля, свої дати публікації та власні зв’язки | Міжмовні зв’язки дублюються вручну й розсинхронізуються, обсяг контенту зростає пропорційно до кількості мов |
| Окремий простір під мову | Потрібна ізоляція: свої моделі, права та незалежний графік релізів | Схему синхронізують вручну, медіа дублюється, наскрізний пошук за мовами не працює |
Вибір моделі ведуть за трьома ознаками: чи розходяться схеми між ринками, хто відповідає за публікацію та скільки мов планується в найближчий рік.
Далі модель задає поведінку підстановки: при локалізації на рівні поля відсутній переклад віддає базова локаль за кожним полем окремо, а при окремих записах зв’язки між мовами доводиться вести самому.
Етапи впровадження багатомовного контуру
Багатомовний контур ламається не на перекладах, а на моделі даних: поки локаль не заведена в структуру, кожна нова мова перетворюється на ручне дублювання записів і розходження версій. Нижче — шість кроків, де кожен спирається на попередній, тому переробки не спливають на середині.
- Аудит контентної моделі. Розбираємо типи записів Contentful і поля: де текст, де посилання на інші записи, де значення зашиті в шаблон. Позначаємо поля, обов’язкові до перекладу, і спільні для всіх мов — зображення, ключі інтеграцій, службові значення.
- Проєктування схеми мов. Фіксуємо перелік локалей, основну локаль і регіональні варіанти з єдиними кодами. Окремо вирішуємо, чи потрібні варіанти письма справа наліво і як це позначається на верстці — від цього залежать макети й довжина рядків.
- Правила резервної підстановки. Задаємо ланцюжок: немає перекладу — беремо значення регіонального варіанта, потім основної локалі. Визначаємо поля, де підстановка допустима, і ті, де потрібен повний переклад, інакше чужий текст спливе на вітрині.
- Налаштування та зв’язка з рендерингом. Локалі прив’язуємо до адрес, додаємо мовні альтернативи для пошукових систем, перемикач і метадані. Спільні елементи — меню, підвал, формати дат і чисел — перекладаємо словниками, а не дублями записів.
- Перевірка перемикання. Проганяємо всі маршрути в кожній локалі: порожні поля, биті посилання, обрізані кнопки, поведінка кешу та індексація. Дивимося не лише головну, а й картки, форми та сторінки помилок.
- Приймання та передача. Віддаємо чек-ліст додавання локалі, регламент для редакторів і список полів, обов’язкових до заповнення. Далі нова мова заводиться за інструкцією, без правок у коді.
Що передаємо після впровадження: конфігурації та регламенти
Передаємо не набір розрізнених налаштувань, а робочу модель багатомовного контенту: у кожного артефакту є власник у вашій команді та зрозумілий порядок змін. Нижче — що саме залишається у вас після запуску і за якими точками інженер приймає роботу.
- Конфігурація мов. Список локалей, мова за замовчуванням і ланцюжок підстановки «мова-регіон → мова → основна»: незаповнене поле показує осмислений текст, а не порожній блок у верстці.
- Схеми зв’язків записів. Карта типів контенту та посилань між ними: що перекладається окремим записом, а що залишається спільним (зображення, довідники, характеристики). Окремо — як зв’язки не розпадаються при додаванні нової мови.
- Політики доступу до чернеток. Ролі перекладача, редактора й розробника, права на попередній перегляд неопублікованого контенту та заборона публікації в основний канал для позаштатних авторів.
- Регламент випуску перекладів. Порядок «чернетка → вичитка → публікація», відповідальний за затвердження та правило для частково перекладених матеріалів.
- Правила маршрутизації. Формування адрес за мовами, редиректи зі старих адрес, визначення мови відвідувача — на рівні маршрутизатора застосунку.
- Автоперевірки повноти. Задача на етапі збірки повідомляє про локаль із незаповненими обов’язковими полями: пропущений переклад не доїжджає до користувача.
- Документація. Карта контентних моделей, інструкція для редакторів, схема ролей і токенів доступу.
- Передача та супровід. Запис обговорення спірних місць, журнал публікацій і канал для запитань після запуску.
Опишіть задачу — повернемося з оцінкою та планом, включно з переліком артефактів під ваш контур.
Кейс: 12 мов і зростання частки зарубіжного трафіку
Що було до
Контент для кожної мови лежав в окремій таблиці, а рядки інтерфейсу — прямо в компонентах. Нова локаль означала правки в чотирьох десятках файлів, і жоден не був пов’язаний з рештою: переклад приходив пізніше за верстку, і ми вручну звіряли, що не залишилося порожніх блоків.
Відсутній ключ віддавався як порожній рядок — користувач бачив діру в розмітці замість англійського тексту.
Строк випуску мовної версії — близько трьох тижнів: половина на правки, половина на перевірку регресій.
Що змінили
Контент переїхав у Contentful, локалізовані поля описані на рівні моделі: у сутності один набір полів і значення за локалями, а не паралельні копії записів. Ланцюжок підстановки заданий явно — якщо польського тексту немає, віддається англійський.
Збірка формує статичну сторінку для кожної локалі, вказівники мови та карта сайту генеруються з того самого списку локалей. Перевірка повноти словника вбудована в збірку: неповний переклад блокує злиття й не доходить до користувачів.
Що стало
Строк випуску нової локалі — два дні: перекладач працює в інтерфейсі редактора, розробник підключає маршрут і підстановку. Обсяг ручних правок при випуску мови впав приблизно у вісім разів — звірка ключів пішла з процесу.
Клас помилок «порожній блок замість перекладу» закритий конструктивно. Частка зарубіжних відвідувачів зросла з 4% до 19% після перших шести мов і до 27% до дванадцяти.
Що робити, якщо контент уже перекладено, а схема мов змінюється
Частково налаштована багатомовність у Contentful — найчастіший випадок: дві-три локалі заведені, частина полів локалізована, частина тягнеться з базової через підстановку, а код мови зашитий у маршрут.
Зміна схеми мов тут не «перемикання налаштування», а міграція даних: у кожного запису змінюється набір локалізованих полів і зв’язків.
Починаємо з інвентаризації: які типи контенту справді перекладені, де переклад лежить у нелокалізованому полі, які локалі ввімкнені, але порожні, і за яким ланцюжком зараз іде підстановка.
Окремо дивимося поля-зв’язки та посилання на медіа — при зміні схеми рвуться саме вони, а не тексти.
Міграцію контенту виконуємо скриптом через API керування: вивантажуємо записи з усіма локалями, зіставляємо старі коди мов з новими, пишемо назад.
Працюємо на копії середовища, скрипт ідемпотентний і перезапускається: спочатку переносимо довідники, потім контент, який на них посилається. Перед прогоном фіксуємо знімок — він же служить точкою відкату.
Адреси зберігаємо через таблицю відповідності локалей маршрутам, а не через код мови в шляху. Старі шляхи продовжують відповідати постійним перенаправленням, нові додаються поруч — зовнішні посилання та пошукова видача не губляться.
Головний ризик переходу — тихі порожні поля: після зміни ланцюжка підстановки запис збирається, але віддає пустоту. Тому ланцюжок вибудовуємо явно, проганяємо збірку та інвалідацію кешу до перемикання, а саму схему змінюємо за один прохід, щоб не залишитися в стані напівпереходу.
Технічні сумніви щодо багатомовної схеми
На погодженні обсягу робіт із локалізації Contentful повторюються ті самі п’ять розвилок. Відповідаємо на них до старту — щоб спірні місця не спливли в середині впровадження, коли змінювати рішення вже пізно.
Що показувати мовою, де перекладу ще немає?
Для кожного поля задаємо мову-джерело. Порожнє значення не залишає діру у верстці: відвідувач бачить осмислений текст, а резервна підстановка працює на рівні поля — частково перекладена сторінка залишається цілою.
Що з адресами сторінок для кожної мови?
Адреси будуємо з локалізованого заголовка або залишаємо стабільну нейтральну адресу з префіксом мови. Другий варіант дешевший у підтримці: посилання не рвуться при правці тексту, а перенаправлення потрібні лише при зміні структури.
Обов’язково перекладати всі поля одразу?
Ні. Ділимо поля на обов’язкові до перекладу та допоміжні — службові підписи, технічні описи, значення за замовчуванням. Частковий переклад скорочує перший етап, а повнота наповнення видна у звіті за мовами.
Чи не сповільнить багатомовність збірку?
Збірка йде лише за зміненими мовами та полями, решта береться з кешу. Додавання мови додає секунди, а не хвилини — якщо схему контенту заклали заздалегідь, а не доклеювали поверх готових сторінок.
Хто відповідає за якість перекладів?
Ми відповідаємо за схему, підстановку, адреси та збірку. Тексти — на боці замовника або його перекладача; зі свого боку даємо глосарій, перелік обов’язкових полів і звіт про прогалини, щоб пропуски були видні до публікації.
Обговоримо задачу: схема мов, строки та порядок робіт
Щоб повернутися з оцінкою строків і планом впровадження, а не із загальними словами, потрібні вхідні дані: перелік локалей та їхній пріоритет, хто перекладає і хто публікує контент, поточна схема типів і полів, а також як влаштована маршрутизація мов у застосунку. Із цього складається склад робіт, і вже за ним рахуємо строки за етапами.
Порядок робіт вибудовуємо так, щоб кожен крок спирався на перевірений попередній:
- фіксуємо схему локалей і ланцюжки фолбеку: яка мова підставляється, коли перекладу немає, і що при цьому бачить користувач;
- правимо контент-модель: де поле локалізоване, де спільне, які зв’язки не можна дублювати за мовами;
- налаштовуємо перемикання мови та адреси сторінок, включно з коректними метаданими для пошукових систем;
- описуємо ролі редакторів і порядок публікації: хто перекладає, хто перевіряє, у якій черговості виходить локаль;
- ловимо неповні переклади, змішані мови всередині одного документа та поведінку кешу при оновленні локалі;
- передаємо документацію: схему локалей, домовленості щодо полів та інструкцію для редакторів.
Кожен пункт отримує окрему оцінку, тому частину обсягу можна закривати поетапно — наприклад, спочатку дві локалі, потім решту. Опишіть задачу та поточний стан контенту — повернемося з планом впровадження, складом робіт і строками.
