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

В Drupal недостаточно перевести текст страницы: меню, подписи полей, системные сообщения и настройки могут остаться на другом языке. На проекте это быстро превращается в проблему маршрутов и контента: поисковик видит две страницы по одному адресу, редактор не понимает, какой перевод опубликован, а обновление конфигурации затирает часть настроек. Ниже — практическая схема для Drupal 10 и 11 на штатных модулях ядра; функции и интерфейсы конкретного сайта могут зависеть от установленных модулей.

Сначала разделите четыре вида перевода

Включённая многоязычность в Drupal — не одна настройка. Ядро распределяет работу между модулями, и у каждого свой объект:

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

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

Перевод сущности — отдельный языковой вариант одного объекта Drupal, а не обязательно новая независимая страница. Например, английская и французская версии узла связаны как переводы одной сущности; поля при этом могут переводиться по отдельности.

Выберите адреса до заполнения сайта

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

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

Настройте перевод не только для узлов

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

1. Добавьте нужные языки. Убедитесь, что в списке нет дубликатов с разными кодами и что основной язык выбран правильно. Проверка: язык отображается в административном интерфейсе и доступен для выбора при создании материала.
2. Включите перевод нужных типов сущностей. Настройте перевод для типа материала и отдельно проверьте поля. Проверка: у тестового материала появляется возможность добавить перевод, а поля, которые должны быть общими, не предлагают отдельное значение для языка.
3. Разберите меню и таксономию. Термины и пункты меню могут требовать перевода отдельно от материала. Проверка: откройте страницу на втором языке и убедитесь, что меню ведёт на соответствующие языковые адреса, а не на исходный вариант.
4. Настройте перевод конфигурации и интерфейса. Переведите названия меню, нужные текстовые настройки и пользовательские строки. Проверка: пройдите путь до нужной страницы в анонимном окне — административный просмотр может показывать строки, недоступные обычному посетителю.
5. Проверьте неполные переводы. Решите, что показывать, если материал не переведён: скрывать его, показывать исходную версию или оставлять ссылку на перевод без публикации. Проверка: откройте язык с отсутствующим переводом напрямую и проверьте, что ответ соответствует редакционному правилу.

Не путайте синхронизацию конфигурации и перевод

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

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

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

Что ломается при проверке

• Переключатель ведёт не туда. Обычно перевод связали с материалом, но забыли о языке меню или правилах построения ссылок. Проверяйте переходы с опубликованной страницы, а не только переключение в форме редактирования.
• Часть интерфейса осталась исходной. Это может быть строка модуля, темы или кастомного кода, для которой не добавлен перевод. Зафиксируйте точный текст и найдите его через инструменты перевода интерфейса, если строка доступна для перевода.
• После импорта изменился вид страницы. Проверьте не только контент, но и конфигурацию отображения, меню и переводы конфигурации. Сравнивайте окружения после каждого импорта, а не только после релиза.
• В поиске появились неправильные адреса. Проверьте внутренние ссылки, перенаправления после смены схемы URL и метаданные страниц. Не рассчитывайте, что переключатель языка сам исправит уже опубликованные ссылки.

Когда какой подход выбрать

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

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

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

Соберите таблицу типов контента, полей, меню и конфигурации с отметками «переводится» и «общее». Затем создайте тестовую страницу на двух языках и проверьте её как анонимный посетитель: прямой адрес, меню, переключение, отсутствие перевода и переход к целевому действию. После этого зафиксируйте схему URL и повторяйте ту же проверку после обновлений Drupal и импорта конфигурации.