Разработка мультиязычного сайта на 1С-Битрикс

Разработка мультиязычного сайта на 1С-Битрикс

Мультиязычность в Битриксе — это не «поставить плагин переводчика». Это архитектурное решение, которое затрагивает структуру инфоблоков, URL-маршрутизацию, кеширование, SEO-разметку и обмен с 1С. На проекте с тремя языками и каталогом на 20К товаров неправильно выбранный подход к хранению переводов превращает каждое обновление товара в тройную работу для контент-менеджера.

Два подхода: мультисайтовость vs подкаталоги

В Битриксе нет штатного модуля «мультиязычность» в привычном понимании WPML или Laravel Translatable. Языковые версии реализуются через механизмы, встроенные в ядро, но их нужно правильно скомбинировать.

Мультисайтовость через SITE_ID — каждый язык = отдельный сайт в системе. s1 — русский, s2 — английский, s3 — немецкий. Каждый сайт получает свой домен или поддомен (en.company.com, de.company.com), свой шаблон, свои языковые файлы. Инфоблоки привязываются к нужным сайтам.

Преимущества:

• Полная изоляция контента — разные инфоблоки для разных языков, разные разделы каталога
• Можно показывать разный ассортимент для разных регионов
• Кеш не пересекается — каждый SITE_ID кешируется отдельно

Недостатки:

• Дублирование инфоблоков. Если каталог общий, но описания на трёх языках — три инфоблока с одинаковой структурой. Обновили цену в русском — нужно обновить в английском и немецком. Автоматизация через обработчик OnAfterIBlockElementUpdate, но это кастомная разработка
• Дублирование SEO-настроек, шаблонов компонентов, URL-правил

Подкаталоги — один сайт, языковые версии в /en/, /de/, /fr/. Определение языка через первый сегмент URL. Один инфоблок с дополнительными свойствами для каждого языка: NAME_EN, DETAIL_TEXT_EN, NAME_DE, DETAIL_TEXT_DE.

Преимущества:

• Один инфоблок — одна точка управления товаром
• SEO-сок не размывается между доменами
• Проще для hreflang — все версии на одном домене

Недостатки:

• Раздутие свойств инфоблока. При 5 языках каждое текстовое поле умножается на 5. Таблица b_iblock_element_property растёт в 5 раз
• Компоненты нужно доработать: result_modifier.php подставляет значение свойства NAME_{LANG} вместо стандартного NAME

На практике для коммерческих проектов чаще работает подход с мультисайтовостью — он чище архитектурно, хотя и дороже в настройке.

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

Битрикс разделяет перевод интерфейса и перевод контента.

Интерфейс — кнопки, заголовки, подписи форм, системные сообщения. Хранится в языковых файлах lang/ru/, lang/en/, lang/de/ рядом с шаблонами и компонентами. Каждый PHP-файл компонента или шаблона имеет соответствующий языковой файл. Подключение через Loc::getMessage('BUTTON_SUBMIT') или устаревший GetMessage().

Типичная ошибка — захардкоженные строки в шаблонах. <button>Отправить</button> вместо <button><?= Loc::getMessage('FORM_SUBMIT') ?></button>. На русском сайте незаметно, при добавлении второго языка — ручной поиск по всем шаблонам.

Контент — тексты страниц, описания товаров, новости. Хранится в инфоблоках. Варианты:

• Отдельные инфоблоки для каждого языка (при мультисайтовости)
• Дополнительные свойства DETAIL_TEXT_EN, PREVIEW_TEXT_EN (при подкаталогах)
• Highload-справочник переводов — таблица {ENTITY_TYPE, ENTITY_ID, LANG, FIELD, VALUE}. Гибко, но требует кастомных компонентов для вывода

URL-структура и hreflang

Три варианта URL:

hreflang — обязателен для корректной индексации. Без него Google может показывать немецким пользователям русскую версию страницы. Реализация:

<link rel="alternate" hreflang="ru" href="https://company.com/catalog/product/" />
<link rel="alternate" hreflang="en" href="https://company.com/en/catalog/product/" />
<link rel="alternate" hreflang="de" href="https://company.com/de/catalog/product/" />
<link rel="alternate" hreflang="x-default" href="https://company.com/catalog/product/" />

В Битриксе нет штатного механизма для hreflang. Добавляем через header.php шаблона или через обработчик OnEndBufferContent. Ключевая сложность — сопоставление URL разных языковых версий одного товара. Если URL генерируются из символьного кода (DETAIL_PAGE_URL => /catalog/#SECTION_CODE#/#CODE#/), символьные коды должны быть транслитерированы на каждый язык. Товар «Кресло офисное» → kreslo-ofisnoe на русском, office-chair на английском. Сопоставление — через общий ID или свойство-привязку между инфоблоками разных языков.

Перевод контента: ручной, автоматический, гибридный

Ручной перевод — качество максимальное, скорость минимальная. Для каталога на 20К товаров с 5 текстовыми полями и 3 языками — 300К единиц перевода. Профессиональный переводчик обработает 2-3К слов в день.

Машинный перевод — Google Translate API, DeepL API, Яндекс.Переводчик. Интегрируем в админку: кнопка «Перевести» рядом с полем, автозаполнение при создании элемента. Качество достаточное для технических описаний, недостаточное для маркетинговых текстов.

Подводные камни автоперевода:

• Терминология — машина не знает, что «подшипник SKF 6205-2RS» не нужно переводить. Нужен глоссарий с исключениями
• HTML-разметка — API переводчика может сломать теги. <strong>Гарантия</strong> 2 года превращается в <strong>Guarantee 2</strong> years. Парсим HTML, переводим текстовые ноды отдельно
• Лимиты API — Google Translate: $20 за 1M символов. Каталог на 50К товаров с описаниями — 10-50M символов. Считаем заранее
• SEO-качество — поисковики умеют определять машинный перевод. Для посадочных страниц и категорий — только ручной перевод, для карточек товаров — машинный с вычиткой

Гибридный подход — машинный перевод для массового контента (карточки товаров, характеристики), ручной для стратегических страниц (главная, категории, посадочные). Работает в 80% проектов.

RTL: арабский, иврит

Если среди целевых языков есть арабский или иврит — это отдельный пласт работы.

• Атрибут dir="rtl" на <html> — переключается по LANGUAGE_ID
• CSS — logical properties вместо margin-left/margin-right: margin-inline-start, padding-inline-end. Или миксин/утилиты для зеркалирования
• Шрифты — арабская типографика требует своих шрифтов, font-family переключается по языку
• Числа, даты, валюты — арабские цифры, формат даты, направление текста в таблицах

В Битриксе RTL не поддерживается «из коробки» на уровне шаблонов. Штатные CSS-классы ядра — LTR. Решение: отдельная CSS-тема для RTL-языков, загружаемая по LANGUAGE_ID, или PostCSS-плагин, генерирующий зеркальный CSS автоматически.

Этапы

1. Анализ языков и рынков (3-5 дней) — какие языки, какие регионы, какой контент уникален, какой общий
2. Выбор архитектуры (2-3 дня) — мультисайтовость vs подкаталоги, структура URL, стратегия перевода
3. Настройка инфраструктуры (1-2 недели) — создание сайтов/подкаталогов, языковые файлы, маршрутизация
4. Адаптация шаблонов (2-4 недели) — локализация интерфейса, hreflang, переключатель языков, RTL при необходимости
5. Перевод контента (2-8 недель) — зависит от объёма, стратегии и количества языков
6. SEO-аудит (3-5 дней) — проверка hreflang, canonical, sitemap для каждого языка, отсутствие дублей в индексе

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