Меню и навигация в многоязычном WordPress — это структурированные данные

Навигация — это больше, чем переведённый текст

У многоязычного меню есть две задачи одновременно: оно показывает читаемые подписи на текущем языке и сохраняет структуру, которая сообщает WordPress, куда должен вести каждый элемент. Эта структура включает отношения родитель–дочерний элемент, тип назначения за каждым пунктом и языковой контекст, в котором должен разрешаться элемент.

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

Что делает меню структурированными данными

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

Это означает, что перевод должен учитывать связи, а не только слова. Если родительский пункт меняет язык, а его дочерние пункты не сопоставлены с эквивалентными назначениями, дерево навигации становится несогласованным. Результат — не просто неудачная формулировка, а сломанная информационная архитектура для этой языковой версии.

Почему важно сопоставление назначений

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

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

Языковая маршрутизация меняет форму меню

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

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

Типичные сбои, когда меню переводят как строки

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

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

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

Практические последствия для владельцев и внедряющих WordPress

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

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