Отдельные тексты категорий для каждого языка: как расширить админку без копий каталога

Что в категории остаётся общим

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

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

Учебный раздел «Компактные приводы» содержит одинаковые товары в двух языковых версиях. Название, краткое описание и SEO тексты переводятся отдельно. Связь с товарами и технический код остаются общими. Такая карта позволяет объяснить редактору, почему изменение описания не должно менять состав каталога, а перенос категории затрагивает обе версии одновременно.

Как составить карту локализованных полей

Для каждого поля указывают назначение и область. Например, публичное название, вступление, подробный текст, SEO title и description относятся к языку. Сортировка раздела может быть общей либо зависеть от витрины; это отдельное решение. Не стоит автоматически локализовать все поля только потому, что появилась языковая вкладка. У каждого различия должна быть причина и проверяемый результат.

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

Поля или отдельные записи переводов

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

У каждой модели есть ограничения. Фиксированные поля проще увидеть в одной форме, но добавление языка меняет схему. Связанные записи легче расширять, но требуют контроля уникальности пары «категория, язык» и загрузки нужного перевода. Эти технические детали не должны перекладываться на редактора. В админке он работает с понятным названием языка и состоянием текста.

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

Интерфейс редактирования

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

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

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

Отсутствующий перевод как отдельное состояние

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

Для названия и подробного текста правила могут различаться. Категории нужна понятная навигационная подпись, а длинный SEO текст может быть необязателен. Поэтому один универсальный резервный вариант для всех полей часто неудобен. Полезно описать поведение каждого значимого элемента и проверить пустые состояния на стенде. Это делает отсутствие перевода управляемым, а не аварийным случаем.

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

Как публичная страница выбирает язык

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

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

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

Независимость сохранения

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

Очистка поля проверяется отдельно. Пустая строка может быть осознанной редакционной правкой, поэтому сервер не должен всегда игнорировать её как «нет обновления». У операции нужна ясная семантика. Иногда форма передаёт список изменённых полей, иногда отдельное действие очистки. Выбор зависит от существующего API, но результат должен быть предсказуемым для редактора.

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

Импорт и массовое заполнение

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

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

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

Проверка качества перевода и структуры

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

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

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

Критерии готовности

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

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

Независимая работа двух редакторов

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

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

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

Смежная тема разобрана в материале Большой интернет-магазин: каталог, поиск и ассортимент.

Вопросы по теме

Как дать редактору разные тексты одной категории для разных языков?

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

Документация и источники

• Google Search Central: мультирегиональные сайты: Разделение языковых версий и ограничения автоматического перенаправления по предполагаемому языку.