Как Headless CMS управляет связью между многоязычными версиями контента на глобальных сайтах?

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

При оценке решения на базе Headless CMS для глобальных веб-сайтов необходимо одновременно проверять модель контента, процесс перевода и вывод на фронтенде. Наличие связей в CMS не означает, что сайт будет корректно переключать языки или генерировать hreflang; API, предоставляющий контент, должен передавать достаточно информации, чтобы фронтенд мог определить, «какие языковые версии одного и того же контента доступны для публичного просмотра».

Сначала определите, что считать «одним и тем же контентом», а затем решайте, как хранить переводы

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

Рекомендуется разделять бизнес-идентичность и идентичность языковой версии, чтобы связи не нарушались при изменении языкового заголовка или пути:

• contentGroupId: идентификатор одного и того же контента на разных языках, который не меняется при переводе или переименовании.
• variantId и locale: идентификаторы конкретной версии и ее языкового региона, например de-DE; в пределах одной группы для одинаковых значений locale следует установить ограничение уникальности.
• sourceVariantId и sourceRevision: указывают, на основе какой версии и какой редакции создан перевод, чтобы можно было определить, не устарел ли он.
• slug, статус и дата публикации: управляются отдельно для каждой языковой версии; результат публикации на исходном языке не наследуется автоматически.

Рекомендуется использовать формат BCP 47 для кодов языков. Необходимость разделять en-US и en-GB следует определять на основе различий в контенте, а не просто по наличию целевой страны. Номера рынков в бизнес-системах можно хранить отдельно; не смешивайте их с полем языка.

Локализация полей или отдельные записи для каждого языка: что выбрать?

Обе модели позволяют устанавливать связи; различие заключается в уровне детализации редактирования и публикации.

Модели продуктов и технические характеристики можно сделать общими, а заголовки, описания и SEO-тексты вести отдельно для каждого языка; цены, сведения о сертификации и условия доставки, возможно, потребуется задавать отдельно для каждого рынка. Не переводите все поля без исключения и не позволяйте «общим полям» скрывать реальные региональные различия.

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

Включите связи между переводами в процесс публикации, а не только в интерфейс редактирования

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

1. Когда исходный текст получает статус, позволяющий его переводить, создайте задачу с указанием группы контента, языка, пути к полю и исходной редакции.
2. При возврате перевода проверьте исходную редакцию; если исходный текст уже изменился, сохраните черновик перевода и сообщите о конфликте, не перезаписывая его незаметно.
3. На этапе проверки проверьте терминологию, связанные ресурсы, региональные ограничения и локализованные SEO-поля, а затем опубликуйте контент с использованием соответствующих разрешений.
4. После публикации или снятия с публикации запустите через Webhook повторную сборку страниц, сброс кэша и обновление языковой навигации; повторяйте обработку событий, завершившихся ошибкой.

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

Результат отката API должен быть явным

Если при запросе страницы на французском языке возвращается английский контент, а фронтенд по-прежнему помечает его как французский, объявленный язык не будет соответствовать языку основного текста страницы. API должен возвращать запрошенный язык, фактический язык ответа и сведения о том, был ли применен откат, а не только фрагмент основного текста.

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

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

Для SEO-связей используйте только реально доступные версии

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

• hreflang должен включать текущую страницу и фактически существующие соответствующие версии; ссылки должны быть взаимными. Коды языковых регионов также должны соответствовать формату, поддерживаемому поисковыми системами.
• Для индексируемых отдельных языковых страниц обычно следует указывать canonical на саму страницу; не следует направлять все такие страницы на исходную языковую версию, иначе сигналы канонизации будут противоречить друг другу.
• Версии, которые не опубликованы, перенаправляют пользователей, возвращают ошибку или помечены как noindex, не должны выводиться в качестве альтернативных языковых страниц для индексации.

При приемке можно проверить одну и ту же группу контента в четырех ситуациях: «изменение исходного текста», «перевод не опубликован», «языковая версия снята с публикации» и «изменение slug», наблюдая за синхронностью изменений в API, языковой навигации, кэше и hreflang. Если в административной панели связи отображаются корректно, но на сайте по-прежнему остаются неработающие адреса, в первую очередь проверьте события публикации и цепочку сборки фронтенда, а не создавайте связи между переводами заново.