Мультиязычный каталог на 1С-Битрикс: перевод товаров и свойств

Вывести магазин на новый рынок звучит просто: «давайте добавим английскую версию». А на практике это упирается в десятки вопросов, о которых не думаешь заранее. Где хранить переводы названий и свойств? По какому адресу открывать английскую версию — /en/, поддомен или отдельный домен? Как быть с ценами в другой валюте и другими регионами доставки? Почему после перевода кнопок товары остались на русском, а умный фильтр показывает «Красный» вместо «Red»? Как объяснить поисковику, что это не дубли, а языковые версии? И, наконец, как обменивать переводы с 1С, чтобы не переводить один и тот же товар дважды.

В этой статье разберём, как построить мультиязычный сайт на 1С-Битрикс с полноценным каталогом, без общих слов. Пройдём по всей цепочке: чем перевод интерфейса (языковые файлы) отличается от перевода контента каталога; какие есть подходы к языковым версиям — многосайтовость, отдельные свойства-переводы товаров и отдельные инфоблоки — и когда какой выбирать; где физически хранить перевод каталога — названия, свойства, описания; как сделать переключатель языков и ЧПУ вида /en/; как перевести свойства умного фильтра; как связать мультиязычность с мультивалютностью и регионами; как настроить SEO языковых версий (hreflang, canonical, отдельная индексация) и как обменивать многоязычный магазин с 1С через мультиязычные реквизиты. Материал — выжимка из наших внедрений по разработке многоязычного сайта на 1С-Битрикс, где каталог на нескольких языках закладывается в архитектуру с самого начала.

Что такое мультиязычный каталог

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

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

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

Главная сложность мультиязычного каталога в том, что текст на странице приходит из разных источников. Кнопка «В корзину» — из шаблона, название товара — из инфоблока, значение свойства «Цвет» — из справочника, символ валюты — из настроек валют, текст письма о заказе — из почтовых шаблонов. Чтобы версия была переведена полностью, а не «на четверть», нужно перевести каждый из этих источников. Именно поэтому мультиязычность — это не «добавить кнопку с флагом», а системная работа по всей архитектуре сайта.

Два слоя перевода: интерфейс и контент

Ключ к пониманию всей мультиязычности — разделить перевод на два слоя, которые устроены и переводятся совершенно по-разному. Если этого не сделать, получится классическая ошибка: «перевели, а половина осталась на русском».

Слой 1. Интерфейс (статические тексты шаблона)

Это надписи, которые заложены в код и не зависят от конкретного товара: «В корзину», «Купить в один клик», «Сортировать по цене», «Показать ещё», «Характеристики», «Отзывы», подписи полей формы, кнопки, системные сообщения об ошибках. Их не тысячи, они конечны и меняются редко. В Битриксе такие тексты хранят в языковых файлах (lang-файлы) — массивах строк, привязанных к языку. При переключении языка интерфейс подставляет строки из нужного файла.

Слой 2. Контент каталога (динамические данные)

Это то, что хранится в базе как данные и меняется постоянно: названия товаров, значения и заголовки свойств, описания, тексты и метатеги категорий, баннеры, статьи. Этот слой нельзя перевести языковыми файлами, потому что он живёт не в коде, а в инфоблоках. Его переводят одним из подходов к мультиязычности каталога: многосайтовость, свойства-переводы или отдельные инфоблоки (об этом ниже).

Разница принципиальна. Интерфейс переводит разработчик один раз при создании шаблона — и дальше строки просто есть. Контент каталога переводит контент-менеджер (или обмен с 1С) на каждый новый товар, и это непрерывный процесс. Смешивать их нельзя: нельзя положить название товара в языковой файл (оно динамическое), и нельзя хранить перевод кнопки в свойстве товара (оно статическое). Понимание этих двух слоёв — фундамент, без которого мультиязычный проект разваливается на «наполовину переведённые» страницы.

Языки интерфейса и языковые файлы

Начнём с более простого слоя — интерфейса. В 1С-Битрикс язык — это встроенная сущность. В системе есть список языков, каждый со своим кодом (ru, en), названием и настройками форматов (даты, числа). К языку привязываются языковые файлы — файлы lang/<код>/*.php рядом с компонентами, шаблонами и модулями, в которых лежат переводы строк.

Как это работает на практике:

• Строки задаются через сообщения. В коде вместо «В корзину» пишут вызов языкового сообщения по ключу, а сам текст лежит в языковом файле для каждого языка. Один ключ — свой перевод в ru и в en.
• Файлы лежат рядом с кодом. У шаблона сайта, у каждого компонента и его шаблона есть папка lang с подпапками по языкам. Перевод интерфейса — это заполнение этих файлов.
• Язык определяется сайтом/страницей. Какой язык интерфейса показать, определяется текущим сайтом (в многосайтовости) или настройкой языка — и все сообщения подставляются на нём.
• Есть инструмент перевода в админке. Локализацию интерфейса удобно вести через штатный механизм перевода: он показывает недостающие строки и позволяет заполнять переводы, не редактируя файлы вручную.

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

Три подхода к мультиязычности каталога

Теперь главное — как перевести сам контент каталога. В 1С-Битрикс исторически сложились три подхода, и выбор между ними определяет всю архитектуру мультиязычного магазина. Ниже — сравнение, а дальше разберём каждый подробно.

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

Подход 1: многосайтовость с языками

Самый «взрослый» подход — использовать штатную многосайтовость 1С-Битрикс. В ней каждая языковая версия — это отдельный сайт со своим идентификатором, своим языком интерфейса, своим шаблоном, своими настройками и, как правило, своим набором инфоблоков (или своей привязкой инфоблока к сайту). Русская версия — сайт s1 на языке ru, английская — сайт s2 на языке en, и так далее.

Что даёт эта модель:

• Полная независимость версий. У каждого сайта свой каталог, свои цены и валюты, свои регионы доставки, свои формы, свои менеджеры и почтовые события. Английская версия может продавать не то же самое, что русская.
• Разные адреса. Версии разводят по папке (/en/), поддомену (en.site.ru) или отдельному домену (site.com) — маршрутизация настраивается на уровне списка сайтов и обработки URL.
• Свой язык интерфейса на сайте. Каждый сайт привязан к языку, поэтому языковые файлы интерфейса подставляются автоматически.
• Раздельная бизнес-логика. Скидки, свойства заказа, способы оплаты и доставки настраиваются на сайт — это удобно, когда рынки живут по разным правилам.

Цена этой гибкости — сложность. Многосайтовость требует аккуратной настройки, дублирования части контента, слаженного обмена с 1С по каждому сайту и внимательной работы с общими и раздельными данными (например, единый склад, но разные цены). Зато для серьёзного выхода на зарубежный рынок, где версия — это фактически отдельный магазин на своём языке и в своей валюте, это самый чистый и масштабируемый путь. Именно так мы обычно строим многоязычные сайты на 1С-Битрикс, когда версии должны жить самостоятельно.

Отдельно отметим: многосайтовость и мультирегиональность технически похожи (в обоих случаях — несколько «сайтов» или поддоменов), и часто их совмещают. Разница в назначении: язык переключает перевод, регион — город/условия. Как устроена региональная схема на поддоменах и что это даёт SEO, подробно разобрано в статье про мультирегиональность и поддомены.

Подход 2: свойства-переводы товаров

Более лёгкий подход — держать один инфоблок с одним набором товаров и хранить переводы в дополнительных свойствах. У товара, помимо основного названия и описания, заводят свойства «Название (EN)», «Описание (EN)», а для характеристик — параллельные свойства или переводимые справочники значений. Витрина на английском языке при выводе берёт не базовые поля, а английские свойства.

Плюсы этого подхода:

• Единый каталог. Товар один, у него один артикул, одна цена, одни остатки, один основной раздел. Не нужно синхронизировать несколько каталогов между собой.
• Простой обмен с 1С. В учётной системе товар тоже один; переводы можно передавать как дополнительные реквизиты в те же переводные свойства.
• Лёгкое соответствие версий. Русская и английская карточка — это буквально одна запись, поэтому hreflang, переключатель и связь версий делаются тривиально: тот же товар, другой язык вывода.
• Меньше дублирования. Картинки, файлы, служебные данные общие; переводится только текст.

Минусы и ограничения:

• Разрастание свойств. На каждый язык — свой набор переводных свойств; при 3–4 языках и многих характеристиках инфоблок становится громоздким.
• Логика вывода на стороне шаблона. Компоненты нужно настроить так, чтобы на нужной версии они брали правильные свойства, — это кастомизация вывода и фильтра.
• Хуже для сильно разных версий. Если английская версия должна продавать другой ассортимент по другим правилам, «свойства на язык» становятся неудобны — это территория многосайтовости.

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

Подход 3: отдельные инфоблоки на язык

Промежуточный вариант — завести отдельный инфоблок под каждый язык: «Каталог RU» и «Каталог EN». Товары в них — независимые элементы, но связанные между собой служебной привязкой (обычно через свойство-привязку или общий внешний код), чтобы можно было найти английский аналог русского товара для переключателя и hreflang.

Когда это уместно:

• Каталоги пересекаются частично. Часть товаров общая, часть уникальна для рынка — отдельные инфоблоки позволяют версиям расходиться, не ломая друг друга.
• Нужна независимая структура разделов. Дерево категорий на английском может отличаться от русского (другая логика спроса на рынке) — отдельный инфоблок даёт своё дерево.
• Разные наборы свойств. Если на разных рынках товар описывают разными характеристиками, отдельные инфоблоки избавляют от «широкого» общего набора свойств.

Сложности:

• Синхронизация. Один товар живёт в нескольких инфоблоках; нужно поддерживать связь и следить, чтобы аналоги не рассинхронизировались по цене, остаткам, статусу.
• Обмен усложняется. Обмен с 1С должен раскладывать один товар по нескольким инфоблокам с разными переводами — это уже нетривиальная настройка.
• Дублирование данных. Общие для всех языков поля (картинки, цены) приходится либо дублировать, либо выносить в общий источник.

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

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

Выбор подхода — это не вопрос вкуса, а следствие того, насколько сильно расходятся языковые версии. Сформулируем в виде проверочных вопросов, которые быстро приводят к решению.

1. Различается ли ассортимент? Если на английском продаётся то же самое, что на русском, — склоняйтесь к свойствам-переводам. Если набор товаров, категорий и правил заметно разный — к многосайтовости.
2. Различаются ли валюты и регионы? Разные валюты, цены и условия доставки на каждый язык — сильный аргумент за многосайтовость, где всё это настраивается на сайт.
3. Насколько независимы бизнес-процессы? Отдельные менеджеры, свои акции, свои письма, своя оплата — снова многосайтовость. Общий бэк-офис и один поток заказов — свойства-переводы проще.
4. Сколько языков планируется? Два-три близких языка при общем каталоге хорошо ложатся на свойства-переводы. Много рынков со своей спецификой — многосайтовость.
5. Как устроен обмен с 1С? Если в 1С товар один и переводы можно передать реквизитами — свойства-переводы отлично стыкуются. Если в учёте под рынки заведены разные номенклатуры — ближе многосайтовость/отдельные инфоблоки.

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

Где хранятся переводы каталога

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

Из таблицы видно главное: текст каталога приходит из множества мест, и «перевести каталог» — значит пройти по всем строкам этой таблицы, а не только по названиям товаров. Особенно легко забыть про значения свойств и заголовки свойств (их видно в умном фильтре и в характеристиках), про метатеги (их не видно на странице, но их читает поиск) и про единицы измерения и валюту (мелочь, которая сразу выдаёт «недоперевод»). Хранение переводов проектируют так, чтобы у каждого из этих источников был предусмотрен способ отдать текст на нужном языке.

Отдельно про справочники значений. Списочные свойства (цвет, бренд, материал) удобно хранить как справочник — либо встроенный список значений свойства, либо highload-справочник. Во втором случае у элемента справочника легко завести переводные поля (значение на каждом языке), и тогда одно значение «красный/red/rot» живёт единой записью с переводами, а не тремя разными свойствами. Как устроены highload-справочники и почему они удобны для больших каталогов со множеством характеристик, мы разбирали в контексте структуры каталога — см. статью про структуру каталога, разделы и хлебные крошки.

Переключатель языков и ЧПУ /en/

Покупатель должен понимать, что версия на его языке существует, и легко на неё переключаться. За это отвечают две вещи: адреса языковых версий (ЧПУ) и сам переключатель языков.

Адреса языковых версий

Есть три стандартных способа развести версии по URL, у каждого свои плюсы:

• Подпапка /en/. Русская версия — в корне, английская — в папке: site.ru/catalog/ и site.ru/en/catalog/. Просто в настройке, весь «вес» домена общий, легко поддерживать. Самый частый выбор для мультиязычности.
• Поддомен en.site.ru. Версия живёт на поддомене. Удобно, когда версии сильно независимы; чаще применяется для регионов, чем для языков.
• Отдельный домен site.com. Для серьёзного выхода на зарубежный рынок под своим брендом и доменной зоной. Максимальная независимость, но и максимум работы.

В многосайтовой модели маршрутизация по папке настраивается в списке сайтов (папка сайта /en/) и в правилах обработки адресов, чтобы запросы из /en/ обслуживал англоязычный сайт. ЧПУ каталога при этом на каждой версии свои: /catalog/smartfony/ на русской и /en/catalog/smartphones/ на английской (символьные коды разделов и товаров на английской версии тоже уместно делать латинскими и осмысленными на её языке).

Переключатель языков

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

• для свойств-переводов это тривиально — тот же элемент, другой язык вывода;
• для отдельных инфоблоков/сайтов — через связь товаров и разделов между версиями (по внешнему коду/привязке);
• для контентных страниц — через соответствие путей или явную привязку переводов.

Если соответствие не выстроено, переключатель приходится «ронять» на главную, и это заметно ухудшает и удобство, и SEO (об этом — в разделе про hreflang). Поэтому переключатель проектируют вместе с моделью хранения переводов, а не прикручивают в конце.

Перевод свойств умного фильтра

Умный фильтр — то место, где недоперевод виден особенно ярко. Покупатель на английской версии открывает фильтр и видит «Цвет: Красный, Синий», «Бренд: …» на русском — и версия сразу выглядит сырой. Дело в том, что фильтр строится из свойств каталога, а у свойства есть две переводимые части, и обе нужно перевести.

• Заголовок свойства. «Цвет» → «Color», «Диагональ» → «Screen size», «Бренд» → «Brand». Это подпись группы в фильтре и в характеристиках.
• Значения свойства. «Красный» → «Red», «Чёрный» → «Black». Это конкретные варианты, по которым фильтруют.

Как перевод свойств реализуется в зависимости от подхода:

• Многосайтовость. Заголовки свойств можно задавать на язык через привязку инфоблока к сайту/языку; значения списочных свойств хранят как справочник с переводами и выводят на языке текущего сайта.
• Свойства-переводы. Под каждый язык — своё свойство (например, COLOR и COLOR_EN) со своим списком значений, и фильтр на английской версии строят по английским свойствам.
• Справочник значений (highload). Наиболее аккуратный вариант для больших каталогов: значение хранится один раз с переводными полями, и фильтр берёт нужный перевод по языку. Не плодит свойства и легко масштабируется на новые языки.

И критически важный технический момент: после перевода значений свойств нужно пересобрать фасетный индекс. Умный фильтр в 1С-Битрикс работает быстро благодаря заранее рассчитанному индексу фасетов; если поменяли значения или добавили переводы, а индекс не пересобрали, фильтр будет отдавать старые данные, пустые группы или неверные счётчики. Поэтому перевод свойств всегда завершают пересборкой фасетного индекса и проверкой фильтра на каждой языковой версии.

Мультиязычность, валюты и регионы

На реальном проекте выход на новый язык почти никогда не бывает «чистым»: вместе с языком приходят другая валюта и другой регион. Важно понимать, что это три независимых механизма, которые в 1С-Битрикс настраиваются по отдельности, но должны быть согласованы.

• Язык отвечает за перевод: интерфейс и контент каталога. Управляется языком/сайтом.
• Валюта отвечает за деньги: в какой валюте показывать и считать цены. Управляется модулем валют и настройкой цен/типов цен.
• Регион отвечает за географию: наличие, склады, доставку, иногда — цены. Управляется многосайтовостью/местоположениями.

Их часто совмещают: английская версия по адресу /en/ показывает цены в евро и доставку по Европе. Но нельзя реализовывать «валюту через язык» или «регион через язык» — каждый механизм остаётся своим. Язык переключает слова, валюта — цифры и символ, регион — условия. Если их запутать (например, зашить символ валюты в языковой файл), система станет неуправляемой при добавлении новой комбинации «язык + валюта + регион».

Практически связка выглядит так: в многосайтовой модели у сайта s2 (английского) задают язык en, валюту вывода EUR/USD, свой регион и свои типы цен. Тогда покупатель на английской версии видит переведённый каталог, цены в нужной валюте и релевантные условия доставки — но каждый из этих аспектов настроен своим модулем. При модели «свойства-переводы» язык переключается выводом, а валюту и регион всё равно подключают отдельными механизмами поверх единого каталога. Детали ценообразования в нескольких валютах (типы цен, курсы, округление, вывод) вынесены в отдельный разбор — мультивалютность и цены в 1С-Битрикс, а региональная схема — в статью про мультирегиональность и поддомены.

SEO языковых версий: hreflang и canonical

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

hreflang — связывает эквиваленты

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

• Взаимность. Каждая версия ссылается hreflang-тегами на все остальные версии этой же страницы — и на саму себя. Русская указывает на английскую, английская — на русскую.
• x-default. Отдельным тегом указывают версию по умолчанию — куда отправлять пользователя, чей язык не совпал ни с одним из имеющихся.
• Точные пары. hreflang ведёт со страницы на её эквивалент, а не на главную другой версии. Карточка товара — на карточку того же товара, категория — на ту же категорию.
• Только реальные версии. Не указывают hreflang на несуществующие переводы — иначе поиск получит битые сигналы.

canonical — разделяет версии

У каждой языковой версии страницы свой canonical на саму себя. Частая грубая ошибка — поставить на английской странице canonical на русскую (в надежде «отдать вес основному домену»): в этом случае поиск сочтёт английскую версию неканоничной копией русской и просто выкинет её из индекса. Правильно: русская каноникализируется на русскую, английская — на английскую, а связь между ними обеспечивает hreflang.

Ещё несколько важных SEO-моментов мультиязычного каталога:

• Метатеги на языке версии. Title, Description, H1 категорий и товаров должны быть переведены — иначе английская страница получит русский заголовок в выдаче.
• Отдельная индексация. Каждая версия открыта для индексации на своём языке; закрывать вторую версию в robots «чтобы не было дублей» — ошибка, для этого есть hreflang.
• Sitemap с языками. В карту сайта включают URL всех версий (при желании — с указанием языковых альтернатив).
• Единая логика URL. Адреса версий предсказуемы и стабильны; смена структуры /en/ задним числом ломает и hreflang, и индекс.

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

Обмен переводов с 1С

Мультиязычный каталог редко наполняют руками — товары приходят обменом из 1С. И тут возникает вопрос: откуда взять переводы, если в типовой выгрузке передаётся один язык — тот, на котором ведётся номенклатура? Есть два принципиальных сценария.

Сценарий А. Переводы ведут в 1С

Самый управляемый путь — хранить переводы в учётной системе и обменивать их вместе с товаром. Для этого в 1С заводят мультиязычные реквизиты: наименования и значения характеристик на разных языках. Технически это делают дополнительными реквизитами/сведениями, отдельными полями или через механизм локализации, а выгрузку настраивают так, чтобы переводы попадали в соответствующие свойства (при модели «свойства-переводы») или в нужную языковую версию (при многосайтовости/отдельных инфоблоках).

• Плюс: перевод делается один раз в учётной системе, а обмен сам раскладывает его по языкам сайта. Контент-менеджеру не нужно дублировать работу на сайте.
• Минус: требует доработки конфигурации 1С и настройки выгрузки; не всякий подрядчик по 1С готов вести переводы в учёте.

Сценарий Б. Переводы ведут на сайте

Если менять 1С нельзя, переводы делают на стороне сайта (руками или автопереводом с последующей вычиткой) и хранят в переводных свойствах/версиях. Здесь ключевая опасность — обмен не должен затирать переводы при очередной выгрузке. Правила, которые это предотвращают:

• Сопоставление по стабильному внешнему коду. Обмен находит товар по XML_ID, а не создаёт заново, — иначе переводы «отвяжутся» вместе с пересозданной карточкой.
• Переводные поля вне перезаписи. Свойства-переводы исключают из обновляемых обменом полей (обмен пишет базовый язык и цены/остатки, но не трогает переводные свойства).
• Аккуратное слияние. Если часть переводов всё же приходит из 1С, а часть ведётся на сайте, настраивают правила слияния, чтобы источники не конфликтовали.

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

Автоперевод или ручной перевод

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

Разумная рабочая схема выглядит так:

1. Автоперевод как заготовка. Пакетно перевести названия, свойства и описания машиной и сложить в переводные поля — получить полный черновик версии.
2. Ручная вычитка ключевого. Носителем или отраслевым переводчиком вычитать то, что важнее всего: названия и свойства ходовых категорий, тексты и метатеги основных разделов, коммерческие блоки.
3. Приоритет по трафику и марже. Сначала довести до идеала топовые категории и товары, дальше — по убыванию важности; редкий «хвост» может пожить на автопереводе.
4. Единый глоссарий. Зафиксировать перевод терминов, брендов и характеристик, чтобы «диагональ», «цвет», «материал» переводились одинаково везде.

Технически автоперевод удобно встроить в наполнение (пакетно перевести и разложить по языкам), но публиковать без редактуры то, что видит покупатель и индексирует поиск, не стоит: массово автопереведённый каталог без вычитки и продаёт хуже, и ранжируется хуже. Автоперевод — это ускоритель ручной работы, а не её замена.

Перевод писем, статусов и служебных текстов

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

• Письма о заказе. Подтверждение заказа, смена статуса, восстановление пароля — почтовые шаблоны заводят на каждый язык, и система должна отправлять письмо на языке версии, где оформлен заказ.
• Статусы заказа. «Принят», «В обработке», «Отправлен» — их названия переводят, чтобы в личном кабинете и письмах статус был на нужном языке.
• Способы оплаты и доставки. Названия и описания способов оплаты/доставки — это тоже контент, который нужно перевести на язык версии.
• Свойства заказа и формы. Подписи полей оформления, тексты соглашений, сообщения валидации — часть через языковые файлы, часть через настройки, и всё это проверяют на второй версии.
• Единицы, валюты, форматы. Единицы измерения, символ и формат валюты, форматы дат и чисел — мелочи, которые сразу выдают недоперевод.

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

Пошагово: запускаем мультиязычный каталог

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

1. Определить рынки и требования. Какие языки, валюты, регионы; насколько различаются ассортимент и бизнес-логика версий. Это определяет выбор подхода.
2. Выбрать подход к мультиязычности. Многосайтовость, свойства-переводы или отдельные инфоблоки — исходя из того, насколько версии расходятся. Зафиксировать решение.
3. Настроить языки и сайты. Завести язык(и) интерфейса и (при многосайтовости) сайты с папкой /en/, шаблоном и маршрутизацией по URL.
4. Спроектировать хранение переводов. Определить, где живут переводы названий, описаний, заголовков и значений свойств, разделов, метатегов; продумать справочники значений.
5. Перевести интерфейс. Заполнить языковые файлы шаблона и всех кастомных компонентов; убедиться, что в коде нет «зашитых» строк.
6. Перевести контент каталога. Названия, описания, разделы, свойства и их значения, метатеги — вручную/гибридно; завести глоссарий терминов.
7. Настроить умный фильтр и пересобрать фасет. Проверить, что фильтр берёт переводы заголовков и значений; пересобрать фасетный индекс на каждой версии.
8. Подключить валюты и регионы. Настроить валюту вывода и региональные условия для каждой версии отдельными механизмами, согласованно с языком.
9. Сделать переключатель и URL. Настроить ЧПУ версий и переключатель, ведущий на эквивалентную страницу другого языка с сохранением контекста.
10. Настроить SEO версий. hreflang между эквивалентами (+ x-default), canonical каждой версии на саму себя, переведённые метатеги, карта сайта, отдельная индексация.
11. Согласовать обмен с 1С. Решить, где ведутся переводы; настроить мультиязычные реквизиты или защиту переводных полей от перезаписи; сопоставление по XML_ID.
12. Перевести служебные тексты и принять. Письма, статусы, оплату/доставку, формы; пройти полный сценарий покупки на каждой версии и по чек-листу.

Заметьте, что «перевод текстов» — лишь часть работы: половина шагов приходится на архитектуру (подход, сайты, хранение, обмен) и на SEO/служебный слой (фасет, hreflang, письма, статусы). Именно поэтому мультиязычный каталог — это инженерный проект, а не «прогнать тексты через переводчик».

Реализация в 1С-Битрикс

Соберём в одном месте, какими штатными средствами Битрикса реализуется всё описанное, — чтобы было понятно, что где настраивается.

Ключевая мысль этой таблицы: у каждого слоя перевода — свой инструмент. Интерфейс — языковые файлы. Контент — инфоблоки (свойства-переводы или сайты). Фильтр — свойства плюс фасетный индекс. Адреса — сайты и urlrewrite. Деньги — модуль валют. География — регионы. SEO — hreflang/canonical в шаблоне. Обмен — мультиязычные реквизиты и стабильные коды. Полноценный мультиязычный каталог получается тогда, когда каждый из этих механизмов настроен и согласован с остальными, а не когда «перевели тексты и добавили флажок».

Частые ошибки

• Смешанный язык на странице. Перевели один слой (интерфейс или контент), а второй забыли — кнопки английские, товары русские, или наоборот. Проверяют оба слоя и все источники текста.
• Название товара в языковом файле. Попытка перевести динамический контент через lang-файлы. Названия и свойства — это данные инфоблока, а не строки интерфейса.
• Непереведённые свойства фильтра. Товары перевели, а заголовки и значения свойств — нет; умный фильтр остался на исходном языке. Переводят и заголовок, и значения.
• Забыли пересобрать фасет. После перевода значений свойств не пересобрали фасетный индекс — фильтр отдаёт старые/пустые данные.
• canonical второй версии на первую. На английской странице canonical указывает на русскую — версия выпадает из индекса. У каждой версии canonical на саму себя.
• Нет hreflang. Языковые версии не связаны — поиск считает их дублями или показывает не тот язык. Нужен взаимный hreflang с x-default.
• Переключатель «роняет» на главную. Кнопка языка ведёт не на эквивалентную страницу, а на главную другой версии — теряется контекст и раздражается покупатель.
• Валюта или регион «через язык». Символ валюты или условия региона зашиты в перевод. Валюта и регион — отдельные механизмы, а не часть языка.
• Обмен затирает переводы. Выгрузка из 1С пересоздаёт товары или перезаписывает переводные поля. Сопоставление по XML_ID, переводы вне перезаписи или в мультиязычных реквизитах.
• Забытые служебные тексты. Витрина переведена, а письма, статусы заказа и способы оплаты/доставки остались на исходном языке. Проверяют полный сценарий покупки.
• Автоперевод без вычитки. Весь каталог опубликован машинным переводом — хуже продаёт и хуже ранжируется. Ключевой контент вычитывает человек.
• Подход выбран наугад. Начали со свойств-переводов, а версии переросли в самостоятельные магазины — приходится дорого переезжать. Подход выбирают под реальную дистанцию между версиями.

Чек-лист мультиязычного каталога

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

1. Подход зафиксирован. Выбран и обоснован подход (многосайтовость / свойства-переводы / отдельные инфоблоки) под реальную дистанцию между версиями.
2. Оба слоя переведены. И интерфейс (языковые файлы), и контент каталога; в коде нет «зашитых» строк.
3. Свойства переведены полностью. Заголовки и значения свойств на языке версии; фасетный индекс пересобран.
4. Метатеги на языке. Title, Description, H1 категорий и товаров переведены на язык версии.
5. Адреса и переключатель. ЧПУ версий (/en/ или домен) стабильны; переключатель ведёт на эквивалентную страницу с сохранением контекста.
6. hreflang и canonical. Взаимный hreflang с x-default между эквивалентами; canonical каждой версии на саму себя; версии открыты для индексации.
7. Валюты и регионы. Валюта вывода и региональные условия настроены своими механизмами, согласованно с языком.
8. Служебные тексты. Письма, статусы заказа, оплата/доставка, формы и единицы/форматы переведены; пройден полный сценарий покупки.
9. Обмен с 1С безопасен. Сопоставление по XML_ID; переводы не затираются; при необходимости — мультиязычные реквизиты.
10. Качество перевода. Ключевой контент вычитан человеком; есть глоссарий терминов; автоперевод не опубликован «как есть».
11. Приёмка по версиям. Каждая языковая версия пройдена глазами целиком — без «островков» исходного языка.

Вывод

Мультиязычный каталог на 1С-Битрикс — это не «кнопка с флагом», а системная работа по нескольким слоям сразу. Сначала — архитектурное решение: какой подход к языковым версиям выбрать (многосайтовость для сильно разных версий, свойства-переводы для общего каталога, отдельные инфоблоки для промежуточных случаев) и где вести переводы (в 1С через мультиязычные реквизиты или на сайте). Затем — два слоя перевода: интерфейс через языковые файлы и контент каталога через инфоблоки, включая обязательный перевод заголовков и значений свойств с пересборкой фасета. И поверх — переключатель и ЧПУ версий, связка с валютами и регионами как отдельными механизмами, SEO на паре hreflang + canonical и безопасный обмен со стабильными кодами.

Практический вывод один: мультиязычность закладывают в архитектуру с самого начала. Выберете подход наугад, переведёте только половину слоёв, забудете про свойства фильтра, canonical или письма — и получите «наполовину переведённый» магазин, который и покупателя раздражает, и в поиске не работает. Пройдёте по всей цепочке аккуратно — язык, контент, фильтр, валюта, регион, URL, hreflang, обмен — и получите многоязычный магазин, который одинаково хорошо продаёт на каждом рынке и корректно индексируется на каждом языке. А если такой каталог нужно спроектировать и запустить, мы помогаем с этим в рамках разработки многоязычного сайта на 1С-Битрикс и настройки мультирегионального сайта на 1С-Битрикс. Больше разборов по теме — в рубрике «Каталог и поиск».