Многоязычность в Drupal: сравниваем три рабочих варианта

В Drupal многоязычный сайт можно собрать тремя разными способами: хранить переводы в одной установке с префиксами URL, привязать языки к отдельным доменам или разнести их по независимым сайтам. На старте эти варианты выглядят похожими, но по-разному влияют на SEO, редакторскую работу, релизы и стоимость поддержки. Ниже — разбор для Drupal 10.3+ и Drupal 11.x: какие модули нужны, чем вы платите за каждую схему и когда выбор одной установки уже становится ошибкой.

Из чего состоит многоязычность в Drupal

Drupal не считает «перевести сайт» одной операцией. В ядре за разные части отвечают отдельные модули:

• Language добавляет языки и правила определения языка посетителя.
• Content Translation переводит сущности: материалы, пользовательские профили, термины таксономии и другие поддерживаемые типы.
• Configuration Translation переводит настройки, которые могут отображаться пользователю: названия меню, текстовые поля конфигурации, подписи и часть настроек представлений.
• Interface Translation отвечает за строки интерфейса Drupal и установленных модулей.

Включать всё подряд не стоит. Если редакторы переводят только статьи, начните с Language и Content Translation. Когда в интерфейсе появляются переводы меню, настроек и системных сообщений, добавьте остальные модули.

Сноска. Сущность — объект Drupal, который хранится и управляется как отдельная запись: например, материал, пользователь, термин таксономии или товар.

Главный выбор — не «какой модуль включить», а где будет жить граница между языками: внутри одной записи, на уровне домена или на уровне отдельного сайта.

Вариант первый: одна установка и префиксы в URL

Это базовая схема для большинства корпоративных сайтов: /ru/, /en/, /de/. Один Drupal обслуживает все языки, а перевод становится язычной версией исходной сущности. Например, русская и английская страницы товара связаны между собой и видны редактору как варианты одного материала.

Включите Language и Content Translation, добавьте языки и настройте определение языка через URL. Для новых материалов задайте язык явно, а для каждого перевода контролируйте заголовок, адрес, метатеги и связанные изображения. Отдельно проверьте меню: перевод страницы не гарантирует автоматический перевод названия пункта меню.

Что эта схема даёт

• один набор обновлений Drupal, модулей и тем;
• общие пользователи, роли, медиафайлы и редакторские процессы;
• связанные переводы, между которыми можно переключаться;
• меньше инфраструктурных настроек: не нужны отдельные DNS-записи и сертификаты для каждого языка.

Цена — общая зона риска. Ошибка в модуле, теме или конфигурации может одновременно затронуть все языковые версии. Кроме того, общий контент-модельный слой иногда неудобен, если редакционные процессы по языкам почти не пересекаются.

Вариант второй: одна установка и разные домены

Вместо префиксов можно использовать, например, example.ru и example.com. Drupal по домену определяет язык и показывает связанную версию материала. С точки зрения редактора это всё ещё один сайт, но для пользователя языки выглядят как самостоятельные площадки.

Такая схема подходит, когда домен важен для бренда, поискового продвижения или локальных требований. Она сложнее в эксплуатации: понадобятся DNS, TLS-сертификаты, корректная передача исходного домена через прокси и настройка Drupal для разрешённых хостов. Проверяйте не только главную страницу, но и ссылки на медиа, изображения, AJAX-запросы и формы на каждом домене.

Где домены оправданы

Выбирайте доменную схему, если языки ориентированы на разные рынки и должны иметь разные поисковые сигналы, контактные данные или маркетинговые сценарии. При этом не смешивайте домен с полной независимостью: база данных, обновления и многие настройки по-прежнему общие.

Главный риск — случайно сделать домен частью логики приложения. Если команда не тестирует абсолютные URL, канонические ссылки, cookie и редиректы, после запуска появляются циклы переадресации и страницы, которые открываются на «чужом» языке.

Вариант третий: отдельная установка для каждого языка

В этой модели русский, английский и немецкий сайты живут в разных экземплярах Drupal. Они могут иметь одинаковую тему и структуру, но обновляются, настраиваются и резервируются отдельно.

Плюс очевиден: команда каждого рынка получает почти полную свободу. Можно использовать разные поля, модули, редакционные роли и расписание публикаций. Минус тоже очевиден: каждое изменение нужно повторить несколько раз. Чем больше установок, тем выше суммарная цена обновлений, мониторинга, резервного копирования и расследования инцидентов.

Отдельные сайты не решают задачу синхронизации автоматически. Если один и тот же товар должен появиться на трёх языках, вам понадобится собственный процесс обмена данными или ручная публикация. Это уже интеграционная задача, а не настройка многоязычности Drupal.

Сравнение подходов

Как выбрать схему для проекта

1. Опишите единицу публикации. Если один материал должен иметь несколько переводов и переключатель языка, начинайте с одной установки и Content Translation. Проверка: редактор открывает материал и видит связанные язычные версии.
2. Определите различия между рынками. Составьте список отличий: поля, цены, меню, формы, роли, юридические страницы. Если различаются только тексты и SEO-поля, отдельные сайты преждевременны. Проверка: для каждого отличия понятно, решается ли оно переводом сущности или настройкой.
3. Выберите адреса. Для простого запуска используйте префиксы. Домены добавляйте, когда они нужны бизнесу, а не только потому, что выглядят солиднее. Проверка: для каждого языка есть один ожидаемый канонический URL и нет взаимных редиректов.
4. Проверьте редакционный процесс. Назначьте ответственного за исходный материал, перевод, вычитку и публикацию. Проверка: команда понимает, что происходит, если исходник изменили после выхода перевода.
5. Сделайте тестовый релиз. Проверьте миграции, кеш, формы, поиск, sitemap, права доступа и резервное восстановление. Проверка: тестовая копия поднимается из бэкапа, а ссылки каждого языка не ведут на другой домен или язык.

Какой вариант выбирать в типовых случаях

Контентный и корпоративный сайт

Начните с одной установки и префиксов. Это минимальное количество инфраструктуры и самый понятный процесс для редакторов. Домены понадобятся только при доказанной потребности в локальном поисковом присутствии или отдельных рыночных правилах.

Каталог с разными ценами и ассортиментом

Не пытайтесь решить региональные цены одним переводом. Перевод отвечает за язык, а не за бизнес-правила. Сначала проверьте, поддерживает ли ваша модель данных валюты, склады, налоговые параметры и доступность товаров; если рынки отличаются радикально, отдельные сайты могут оказаться дешевле в долгосрочной перспективе, несмотря на двойное сопровождение.

Несколько независимых редакций

Если команды не согласуют релизы, имеют разные роли и публикуют разные материалы, отдельные установки дают предсказуемую изоляцию. Но до выбора оцените число повторяющихся операций: обновление ядра, установка патчей безопасности, тестирование темы и восстановление из резервной копии.

Что ломается чаще всего

• Перевели материал, но не меню. Меню и интерфейсные строки имеют отдельные механизмы перевода. Проверяйте их на тестовом языке, а не только на странице материала.
• Язык определяется по браузеру и перекидывает пользователя. Автоматическое определение удобно, но может конфликтовать с выбранным URL и кешем. Для публичного сайта зафиксируйте приоритет правил и не меняйте язык уже открытой страницы без понятной причины.
• Кеш смешивает языки. Ошибка проявляется, когда посетитель видит заголовок другого языка при правильном адресе. Проверьте, учитывает ли слой кеширования язык и домен, включая CDN и reverse proxy.
• Перевод не обновился после изменения исходника. Drupal не может автоматически проверить качество перевода. Добавьте статус перевода в редакционный чек-лист и решите, кто повторно отправляет материал на вычитку.
• Отдельные сайты расходятся по версии. Разные версии ядра и модулей усложняют поиск причины ошибки. Зафиксируйте матрицу совместимости и общий календарь обновлений.

Что сделать дальше

Соберите небольшой прототип на копии сайта: два языка, один тип материала, меню, форма и одна интеграция с внешним сервисом. Сравните не внешний вид, а время публикации перевода, поведение кеша и восстановление после ошибки. После выбора архитектуры зафиксируйте правила URL, канонические адреса, порядок определения языка и владельца перевода. В проде отдельно измеряйте ошибки по языкам, долю страниц без перевода и задержку публикации между исходником и локализацией.