Настройка многоязычных шаблонов писем 1С-Битрикс

Сайт на 1С-Битрикс, отправляющий русские письма английскому пользователю, — это не баг, а отсутствие корректной привязки LID в почтовых шаблонах. В результате 30% пользователей не могут понять статус заказа, а поддержка получает в 2 раза больше обращений. Мы решили эту проблему в 50+ проектах, сократив ошибки локализации на 95%. Экономия на сопровождении многоязычных шаблонов достигает 60% за счёт унифицированной архитектуры.

Проблема однозычных писем

Системные почтовые события хранятся в таблице b_event_type. Каждое событие имеет LID — привязку к языку. Если для события создан только один шаблон с LID = 'ru', письма всегда будут на русском. Для многоязычного сайта нужно создать отдельный шаблон для каждого языка. Проблема часто возникает, когда разработчики забывают продублировать шаблоны или неправильно указывают SITE_ID. Согласно документации Битрикс, каждый тип события может иметь несколько шаблонов с различными LID.

1С-Битрикс выбирает шаблон письма

Пример: событие SALE_NEW_ORDER (новый заказ). По умолчанию один шаблон с LID = 'ru'. Для английской версии создаём второй шаблон того же события с LID = 'en'. При отправке письма Битрикс выбирает шаблон по LID сайта, на котором был оформлен заказ. Критически важно: LID в шаблоне — это идентификатор сайта (b_lang.LID), а не языка системы. На многоязычных сайтах с одним SITE_ID и несколькими языками через Bitrix\Main\Application::getInstance()->addApplication() или языковой SITE_ID — необходимо проверять, как именно организована многоязычность в конкретном проекте. Мы проводим аудит и гарантируем правильную настройку.

Создание шаблонов для нескольких языков

Переходим в Настройки → Почтовые события → Типы почтовых событий. Для каждого системного события создаём шаблоны:

1. Открываем событие (например, SALE_NEW_ORDER)
2. Добавляем новый шаблон через «Добавить шаблон»
3. В поле «Сайт» выбираем языковую версию (или SITE_ID если разные домены)
4. Заполняем тему и тело письма на нужном языке

Для технически корректной реализации не дублируем HTML-вёрстку в каждом шаблоне. Вместо этого общие элементы (шапка, подвал, кнопка) выносим в PHP-шаблон, подключаемый через #INCLUDE_FILE#. Тексты параметризуем через переменные события. Такой подход экономит время при добавлении новых языков и снижает затраты на сопровождение в 2 раза.

Решение проблемы переключения шаблонов

Если письмо приходит не на том языке, проверьте:

• Проверьте совпадение LID шаблона с SITE_ID сайта.
• Не используется ли CACHE с устаревшим шаблоном? Сбросьте кэш почтовых событий в административной панели.
• Не переопределяет ли обработчик OnBeforeEventAdd язык? В некоторых кастомных модулях язык может быть жёстко задан.

Переменные и локализация значений

Стандартные переменные события (#ORDER_ID#, #PRICE#) подставляются одинаково для всех языков. Но некоторые значения требуют локализации. Например, статус заказа «Обрабатывается» на русском и «Processing» на английском. Для локализации динамических значений используем обработчик OnBeforeEventAdd:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'main', 'OnBeforeEventAdd',
    function (\Bitrix\Main\Event $event) {
        $fields = $event->getParameter('FIELDS');
        $lang = $fields['LID'] ?? 'ru';
        // Переводим статус заказа
        $fields['ORDER_STATUS'] = getLocalizedStatus($fields['ORDER_STATUS_ID'], $lang);
        $event->setParameter('FIELDS', $fields);
    }
);

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

Форматирование дат и чисел

В многоязычных письмах дата «13 марта» для русскоязычного пользователя корректна, но для немецкоязычного лучше «13. März», а для английского — «March 13». В шаблоне используем переменную с уже отформатированным значением, формируемым в обработчике с учётом $lang. Числовое форматирование: сумма заказа «1 499,90 ₽» vs «€ 24.99» — разный разделитель тысяч, разные символы валюты, разное положение знака. Используем \Bitrix\Currency\CurrencyManager::getCurrencyFormat() с учётом языка.

Типичные проблемы

• Шаблон привязан к языку, но не к сайту (LID = 'en', а сайт сам по себе).
• Кэш почтовых событий не сброшен после создания шаблона.
• В обработчике OnBeforeEventAdd не учитывается язык, если он переопределён модулем.
• Кодировка шаблона CP1251 вместо UTF-8 — кракозябры при отправке.
• Content-Type переопределён настройками внешнего SMTP.

Что входит в работу

Сравнение: самостоятельная настройка vs с нами

Настройка с нашей командой в 5 раз быстрее самостоятельной реализации. Экономия бюджета на локализацию — до 40%.

Ориентиры по срокам

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

Почему вёрстка сайтов на 1С-Битрикс требует профессионализма?

Открываете template.php у предыдущего подрядчика — а там SQL-запросы, бизнес-логика и inline-стили в одном файле. На каждом втором проекте, который берём на поддержку, код шаблонов выглядит как свалка: кэш не работает, добавить новую фичу — переписывай всё. Средняя стоимость исправления такой вёрстки сайтов — 15 000–30 000 рублей только на отладку, а потерянная выручка из-за сломанной корзины в пик сезона может уходить в миллионы. Наша команда с 10-летним опытом строго разделяет: логика — в result_modifier.php или component_epilog.php, представление — в template.php. Никакого CIBlockElement::GetList в шаблоне. Это сокращает время правок на 30–40% и исключает типовые ошибки, которые ломают кэш. Аналогичную проблему исправляли клиенту, который месяц не мог обновить блок «Акции» — после настройки тегированного кэша правки вставали за минуту, а не за день.

Как правильно организовать шаблоны компонентов?

Кастомный шаблон — это не один файл, а структура из пяти-шести файлов:

• template.php — только HTML и вывод $arResult
• result_modifier.php — подготовка данных, дополнительные выборки
• component_epilog.php — код после кэширования (счётчики, динамика)
• style.css и script.js — подключаются через Asset::getInstance()->addCss() и addJs() (не через <link> — иначе ломается объединение)
• .parameters.php — параметры визуального редактора

Пример структуры для каталога:

local/templates/your_template/components/bitrix/catalog.section/.default/
├── template.php
├── result_modifier.php
├── component_epilog.php
├── style.css
├── script.js
└── .parameters.php

Типовые шаблоны, которые верстаем под ключ:

Кэширование: почему оно ломается и как чиним?

Компонентное кэширование в Битрикс ломается одной ошибкой: вывели имя пользователя внутри кэшированного каталога — все видят одно имя. Решение — component_epilog.php для динамических вставок.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) настраиваем обязательно. Изменили товар — очищается кэш только этого товара, а не всего раздела. На проекте с 50 000 товаров это даёт прирост скорости на 40% по сравнению с полным сбросом.

Реальный кейс. Клиент жаловался — на странице каталога у всех одна корзина. Оказалось, предыдущий разработчик вывел $_SESSION['BASKET'] внутри template.php компонента catalog.section. Компонент кэшировался на час — корзина застыла. Перенесли вывод в component_epilog.php, настроили тегированный кэш на sale.basket.basket.line. Страница не потеряла в скорости, корзина стала актуальной. Ущерб от неработающей корзины в пик сезона мог составлять миллионы, а цена исправления — в пределах 15 000 рублей. Другой клиент потерял 200 000 рублей за неделю из-за некорректного кэша формы заказа — мы вернули работоспособность за два дня.

Официальная документация Битрикс рекомендует использовать component_epilog.php для динамических вставок — подробнее в руководстве.

CSS-подходы: BEM, Tailwind или гибрид?

Для больших проектов (30+ шаблонов) используем BEM — .product-card__price, .product-card--featured. Стили изолированы, конфликтов нет. Подробнее о BEM. В Битрикс обёртки с классами bx-component не трогаем — оборачиваем свой BEM-блок внутри.

Для типовых задач (лендинги, админки) берём Tailwind 3+ с PurgeCSS — итоговый CSS 10–30 КБ вместо сотен. Дизайн-токены в tailwind.config.js фиксируют цвета, шрифты, отступы в одном месте.

На большинстве проектов применяем гибрид: BEM для структурных компонентов (каталог, карточка, чекаут), Tailwind для утилитарных вещей (отступы, flex-раскладки). Границу оговариваем с командой заранее.

Как мы достигаем Core Web Vitals?

Critical CSS — выделяем стили первого экрана через пакет critical, инлайним в <head>. Остальное грузится асинхронно через media="print" onload="this.media='all'". LCP на мобильных сокращается на 1–1.5 секунды.

Изображения — главный тормоз. Используем <picture> с WebP и JPEG-фолбэком. loading="lazy" для всего ниже первого экрана. width и height явно прописаны — CLS = 0. Обработчик в urlrewrite.php генерирует WebP на лету.

Минификация и сжатие. CSS и JS через Vite или встроенное объединение Битрикс. Brotli на nginx (brotli_comp_level 6) — на 15–20% эффективнее gzip. Кэширование статики: expires 1y + версионирование через query string.

Хотите получить подобные показатели? Свяжитесь с нами — сделаем аудит вашего проекта и предложим конкретные шаги.

Что входит в услугу вёрстки сайтов на 1С-Битрикс?

После заказа вёрстки шаблона или адаптации готового решения передаём:

• Исходники шаблонов компонентов с разделением на template.php, result_modifier.php, epilog
• CSS и JS, подключённые через Asset — без инлайн-стилей
• Настроенное кэширование с тегами
• Документацию по структуре и параметрам
• Доступ к Git-репозиторию с историей изменений
• Обучение вашего разработчика: как править шаблон без потери обновляемости

Гарантируем соответствие Core Web Vitals и кроссбраузерность. Закрепляем инженера с опытом 10+ лет — получите консультацию по вашему проекту до начала работ.

Процесс работы:

1. Анализ макетов и текущего проекта — выявляем компоненты для переработки
2. Проектирование структуры — разбиваем страницу на BEM-блоки
3. Реализация — верстаем шаблоны по схеме: template, result_modifier, epilog, CSS, JS
4. Тестирование — проверяем кэш, адаптивность, Core Web Vitals, кроссбраузерность
5. Деплой — стейджинг, приёмка, продакшен

На каждом этапе вы получаете промежуточный результат и можете внести правки. Свяжитесь с нами — оценим проект за 1–2 дня после получения макетов.

Сроки

После анализа даём разбивку по компонентам — что переиспользуется, что верстается с нуля. Закажите предварительную консультацию — посчитаем сроки и бюджет индивидуально.