Если сайт собран в Gutenberg, переводить приходится не только текст страницы. На мультиязычном проекте отдельно всплывают шаблоны, повторно используемые блоки, паттерны, меню, метаданные и иногда динамические элементы темы или плагинов. Ошибка здесь обычно одна и та же: переводят только видимый текст, а потом получают смешанные языки, дубли страниц или блоки, которые невозможно нормально редактировать на второй языковой версии.
Правильный подход зависит не от самого Gutenberg, а от того, как устроен мультиязычный сайт: это отдельные языковые версии с собственными URL, единый сайт с переключателем языка или магазин, где нужно переводить ещё и карточки товаров, атрибуты и служебные строки. Ниже разберу, как организовать перевод блоков так, чтобы потом можно было поддерживать сайт без хаоса.
Сначала определите, что именно вы переводите
В Gutenberg под перевод попадает не один тип контента. На практике нужно разделить сайт на несколько слоёв:
- обычные записи и страницы — основной контент, собранный из блоков;
- шаблоны темы — части сайта, которые выводятся через редактор сайта или theme.json;
- повторно используемые блоки и синхронизированные паттерны — элементы, которые вставляются в несколько мест;
- динамический контент — записи, товары, таксономии, поля, виджеты, строки темы и плагинов;
- интерфейс WordPress — админка, кнопки, системные сообщения, строки плагинов и темы.
Это важно, потому что перевод интерфейса WordPress не решает задачу перевода контента. И наоборот: даже если страница переведена вручную, это не означает, что переключатель языка, хлебные крошки, заголовки архивов и метаописания тоже будут локализованы.
Как устроен перевод блоков Gutenberg на практике
Есть два рабочих сценария.
1. Отдельная языковая версия для каждой страницы
Это нормальный вариант для большинства сайтов. У каждой страницы есть своя версия на другом языке, свой URL и свой набор переводимых полей. Например, русская страница и английская страница существуют как связанные записи, а не как один текст с автоматической подменой языка на лету.
Такой подход нужен, если вы хотите:
- редактировать перевод отдельно;
- контролировать SEO каждой языковой версии;
- переводить не только текст, но и заголовки, alt, мета-теги, slug, меню;
- избежать ситуации, когда один перевод ломает весь сайт.
2. Автоматический показ перевода без отдельной редакции
Это проще на старте, но хуже для качества и контроля. Машинный перевод может быть полезен для черновика, внутреннего проекта или сайта с большим объёмом контента, где нужно быстро получить базовую версию. Но для коммерческого сайта, корпоративного проекта или любого ресурса, где важны доверие и точность, автоматический перевод без ручной проверки обычно недостаточен.
Если контент создаётся в Gutenberg, автоматический перевод особенно рискованен для блоков с кнопками, списками, таблицами, цитатами и вставками HTML. Машина часто переводит текст внутри блока, но не понимает контекст, а иногда ломает разметку или смысл CTA.
Что делать с обычными страницами и записями
Для страниц и записей лучший рабочий порядок такой: сначала создаёте языковую структуру, потом переводите контент, затем проверяете связку между версиями. Если используете плагин мультиязычности, у него обычно есть собственный способ связать оригинал и перевод. Важно не дублировать страницу вручную через копирование в редакторе, если плагин умеет хранить языки как связанные сущности: иначе позже будет сложно обновлять контент и поддерживать hreflang.
При переводе блоков Gutenberg смотрите не только на текст внутри абзацев. Отдельно проверяйте:
- заголовки блоков;
- кнопки и их ссылки;
- подписи к изображениям;
- alt-тексты;
- цитаты, списки, таблицы;
- встроенные HTML-блоки;
- внутренние ссылки на другие страницы того же языка.
Если внутри страницы есть блоки с динамическим выводом, например последние записи или товары, их не переводят как обычный текст. Там нужно настраивать сам источник данных: переводы записей, категорий, атрибутов, терминов и, если нужно, шаблонов вывода.
Как переводить шаблоны, части шаблонов и повторно используемые блоки
Именно здесь чаще всего возникают проблемы. В Gutenberg есть элементы, которые выглядят как обычный блок, но по смыслу являются общими для сайта. Если перевести их неправильно, изменения начнут расходиться по всем страницам.
Шаблоны и части шаблонов
Если вы используете редактор сайта и шаблонные части, переводить их нужно как отдельные сущности, а не как текст внутри одной страницы. Это касается шапки, подвала, шаблона записи, шаблона страницы архива и других общих областей. На мультиязычном сайте у каждой языковой версии обычно должны быть свои тексты в шапке, подвале, кнопках и навигации, если они зависят от языка.
Здесь важно понять ограничение темы и плагина мультиязычности. Не каждый плагин одинаково хорошо работает с block themes и редактором сайта. Перед запуском проверьте, умеет ли решение переводить шаблоны, части шаблонов и глобальные стили без ручного обхода.
Повторно используемые блоки и синхронизированные паттерны
Повторно используемый блок удобен, когда один и тот же фрагмент нужен на многих страницах. Но на мультиязычном сайте он может стать источником путаницы. Если блок синхронизирован, изменение в одном месте затронет все страницы. Это полезно для единого дисклеймера или CTA, но опасно, если внутри блока есть текст, который должен отличаться по языкам.
Практически это решается так:
- если элемент должен быть одинаковым на всех языках, оставляйте его синхронизированным и переводите как отдельную сущность, если плагин это поддерживает;
- если текст должен отличаться, не используйте один общий блок для всех языков — создайте отдельные версии;
- если блок содержит и общий, и локализуемый контент, лучше разделить его на несколько блоков.
Иначе вы получите ситуацию, когда перевод одной кнопки меняет текст на всех страницах сразу, а это уже не перевод, а общий источник ошибок.
Как выбрать способ перевода: вручную, автоматически или в гибридном режиме
Для большинства сайтов рабочим оказывается гибридный сценарий: машинный перевод как черновик плюс ручная редактура. Но подходит он не всем.
| Сценарий | Когда подходит | Что учитывать |
|---|---|---|
| Ручной перевод | Корпоративный сайт, услуги, экспертный контент, юридически значимые тексты | Дольше и дороже, но выше контроль качества |
| Автоматический перевод | Большой архив, внутренний проект, быстрый запуск черновой версии | Нужна обязательная проверка ключевых страниц |
| Гибридный подход | Большинство коммерческих сайтов и контентных проектов | Удобно масштабировать, если плагин позволяет редактировать перевод вручную |
Если сайт небольшой, проще сразу делать ручные версии ключевых страниц. Если контента много, сначала переводят приоритетные страницы: главную, услуги, категории, карточки товаров, контакты, FAQ. Остальное переводят по мере необходимости.
Что важно для SEO мультиязычного сайта
Перевод блоков сам по себе не делает сайт мультиязычным с точки зрения поиска. Для SEO нужны отдельные языковые URL, корректные внутренние ссылки, метаданные и разметка языковых версий. Если этого нет, поисковик может увидеть дубли или неправильно определить язык страницы.
Проверьте минимум следующее:
- у каждой языковой версии свой URL-адрес;
- переведены title и meta description;
- внутренние ссылки ведут на страницы того же языка;
- на сайте корректно работает переключатель языка;
- плагин или тема выводят hreflang, если это предусмотрено решением;
- не смешиваются языки в меню, хлебных крошках и футере.
Если используете автоматический перевод, не рассчитывайте, что поисковик сам всё поймёт. Для коммерческих страниц и страниц, которые должны ранжироваться, текст лучше вычитать и адаптировать под язык, а не просто дословно перевести.
На что проверить сайт после перевода
После настройки не ограничивайтесь просмотром главной страницы. Ошибки обычно всплывают в местах, которые не видны сразу.
- Откройте несколько страниц на каждом языке и проверьте, не остались ли фрагменты исходного языка.
- Проверьте меню, футер, кнопки и формы.
- Посмотрите, как отображаются повторно используемые блоки.
- Проверьте, не ведут ли ссылки на неправильную языковую версию.
- Если есть WooCommerce, отдельно проверьте карточки товаров, категории, атрибуты, служебные страницы и письма.
- Убедитесь, что в индексе не появляются лишние копии страниц без языковой привязки.
Если после перевода блоков часть контента всё равно отображается на исходном языке, проблема обычно не в Gutenberg, а в том, что конкретный элемент живёт не в записи, а в шаблоне, виджете, строке темы или настройке плагина. Тогда нужно искать источник именно там.
Когда без разработчика или поддержки плагина не обойтись
Если сайт собран на block theme, использует сложные шаблоны, динамические блоки или нестандартные поля, иногда приходится смотреть код темы и логику вывода. Это нормально. Не каждый мультиязычный плагин одинаково хорошо работает со всеми комбинациями темы, редактора сайта и сторонних блоков.
К разработчику или в поддержку плагина стоит обращаться, если:
- перевод шаблонов не сохраняется или сбрасывается;
- повторно используемые блоки не разделяются по языкам так, как нужно;
- динамический блок выводит данные только на одном языке;
- переключатель языка ломает структуру URL;
- после обновления темы исчезает часть переводов.
На практике мультиязычность в Gutenberg — это не одна настройка, а связка из структуры сайта, способа хранения переводов и дисциплины редактирования. Если сразу разделить обычные страницы, шаблоны и общие блоки, дальше сайт будет нормально масштабироваться и не превратится в набор случайных копий на разных языках.