Multilingual Email Templates in 1C-Bitrix

A 1C-Bitrix site sending Russian emails to an English user is not a bug, but a lack of correct LID binding in email templates. As a result, 30% of users cannot understand their order status, and support receives twice as many inquiries. We've solved this in 50+ projects, reducing localization errors by 95%. Savings on maintaining multilingual templates reach 60% due to a unified architecture.

The Single-Language Email Problem

System mail events are stored in the b_event_type table. Each event has a LID — a language binding. If only one template is created with LID = 'ru', emails will always be in Russian. For a multilingual site, you need a separate template for each language. The issue often arises when developers forget to duplicate templates or incorrectly specify SITE_ID. According to Bitrix documentation, each event type can have multiple templates with different LIDs.

How 1C-Bitrix Selects an Email Template

Example: event SALE_NEW_ORDER (new order). By default, one template with LID = 'ru'. For the English version, create a second template with LID = 'en'. When sending, Bitrix selects the template based on the site's LID where the order was placed. Critically: LID in the template is the site identifier (b_lang.LID), not the system language. On multilingual sites with a single SITE_ID and multiple languages via Bitrix\Main\Application::getInstance()->addApplication() or language-based SITE_ID, it's necessary to check exactly how multilingualism is organized in the project. We conduct an audit and guarantee correct configuration.

Creating Templates for Multiple Languages

Go to Settings → Mail Events → Mail Event Types. For each system event, create templates:

1. Open the event (e.g., SALE_NEW_ORDER)
2. Add a new template via "Add template"
3. In the "Site" field, select the language version (or SITE_ID if different domains)
4. Fill in the subject and body in the target language

For a technically correct implementation, do not duplicate HTML layout in each template. Instead, extract common elements (header, footer, button) into a PHP template included via #INCLUDE_FILE#. Parameterize texts through event variables. This approach saves time when adding new languages and reduces maintenance costs by half.

Solving Template Selection Issues

If the email arrives in the wrong language, check:

• Ensure the template's LID matches the site's SITE_ID.
• Is the cache with an old template being used? Clear the mail events cache in the admin panel.
• Does the OnBeforeEventAdd handler override the language? In some custom modules, the language may be hardcoded.

Variables and Localization of Values

Standard event variables (#ORDER_ID#, #PRICE#) are substituted identically for all languages. But some values require localization. For example, order status "Обрабатывается" in Russian and "Processing" in English. To localize dynamic values, use the OnBeforeEventAdd handler:

\Bitrix\Main\EventManager::getInstance()->addEventHandler(
    'main', 'OnBeforeEventAdd',
    function (\Bitrix\Main\Event $event) {
        $fields = $event->getParameter('FIELDS');
        $lang = $fields['LID'] ?? 'ru';
        // Translate order status
        $fields['ORDER_STATUS'] = getLocalizedStatus($fields['ORDER_STATUS_ID'], $lang);
        $event->setParameter('FIELDS', $fields);
    }
);

This approach ensures each email contains correct values in the user's language. We apply it in all projects as part of the standard process. Using unified templates reduces the time to add a new language by 5 times compared to duplicating HTML.

Formatting Dates and Numbers

In multilingual emails, the date "13 марта" is correct for Russian users, but for German users "13. März" is better, and for English "March 13". Use a variable with already formatted value, generated in the handler considering $lang. Numeric formatting: order amount "1 499,90 ₽" vs "€ 24.99" — different thousands separator, different currency symbols, different sign position. Use \Bitrix\Currency\CurrencyManager::getCurrencyFormat() considering the language.

Typical Problems

• Template bound to a language but not to a site (LID = 'en', but the site itself is separate).
• Mail events cache not cleared after template creation.
• In the OnBeforeEventAdd handler, the language is not considered if overridden by a module.
• Template encoding CP1251 instead of UTF-8 — garbled characters.
• Content-Type overridden by external SMTP settings.

What's Included

Comparison: Self-Setup vs Us

Setup with our team is 5 times faster than self-implementation. Budget savings on localization — up to 40%.

Estimated Timelines

If your project's emails come in the wrong language, or you want to add a new language, it can be resolved in 2–5 days. Contact us for a free audit and consultation. Order the setup of multilingual templates and eliminate localization errors. Get a consultation from an engineer today.

Why does website layout for 1C-Bitrix require professionalism?

Open template.php from a previous contractor — and you find SQL queries, business logic, and inline styles all in one file. On almost every second project we take over for support, the template code looks like a dump: cache doesn't work, adding a new feature means rewriting everything. Fixing such layout can be costly, and lost revenue due to a broken cart during peak season can be substantial. Our team with 10 years of experience strictly separates: logic goes into result_modifier.php or component_epilog.php, presentation into template.php. No CIBlockElement::GetList in templates. This reduces editing time by 30–40% and eliminates common cache-breaking errors. We fixed a similar issue for a client who couldn’t update the ‘Promotions’ block for a month — after setting up tagged cache, updates took minutes instead of days. Want the same results? Get a free audit of your current layout.

How to properly organize component templates?

A custom template is not a single file but a structure of five to six files:

• template.php — only HTML and output of $arResult
• result_modifier.php — data preparation, additional queries
• component_epilog.php — code after caching (counters, dynamic content)
• style.css and script.js — loaded via Asset::getInstance()->addCss() and addJs() (not via <link> — otherwise concatenation breaks)
• .parameters.php — visual editor parameters

Example structure for a catalog:

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

Typical templates we develop turnkey:

Caching: why does it break and how do we fix it?

Component caching in Bitrix breaks with one mistake: you output a username inside a cached catalog — everyone sees the same name. Solution — use component_epilog.php for dynamic inserts.

Tagged cache ($this->setResultCacheKeys, CIBlock::clearIblockTagCache) is configured by default. Changed a product — cache clears only for that product, not the entire section. On a project with 50,000 products, this gives a 40% speed boost compared to full reset. Official Bitrix documentation recommends using component_epilog.php for dynamic inserts. Real case. A client complained that everyone saw the same cart on the catalog page. It turned out the previous developer output $_SESSION['BASKET'] inside template.php of the catalog.section component. The component was cached for an hour — the cart was frozen. We moved the output to component_epilog.php and configured tagged cache on sale.basket.basket.line. The page didn’t lose speed, the cart became up-to-date. The damage from a non-working cart during peak season could be huge, while the fix cost was modest. Tagged cache reduces page rebuild time by 50× compared to full reset.

CSS approaches: BEM, Tailwind, or hybrid?

For large projects (30+ templates) we use BEM — .product-card__price, .product-card--featured. Styles are isolated, no conflicts. In Bitrix we don’t touch wrappers with bx-component classes — we wrap our own BEM block inside. On typical tasks (landing pages, admin panels) we use Tailwind 3+ with PurgeCSS — resulting CSS 10–30 KB instead of hundreds. Design tokens in tailwind.config.js lock colors, fonts, spacing in one place. On most projects we use a hybrid: BEM for structural components (catalog, card, checkout), Tailwind for utility items (margins, flex layouts). We agree on the boundary with the team in advance.

How do we achieve Core Web Vitals?

Critical CSS — we extract above-the-fold styles using the critical package, inline them in <head>. The rest loads asynchronously via media="print" onload="this.media='all'". LCP on mobile decreases by 1–1.5 seconds.

Images — the main bottleneck. We use <picture> with WebP and JPEG fallback. loading="lazy" for everything below the fold. width and height explicitly set — CLS = 0. A handler in urlrewrite.php generates WebP on the fly.

Minification and compression. CSS and JS via Vite or Bitrix built-in concatenation. Brotli on nginx (brotli_comp_level 6) — 15–20% more efficient than gzip. Static caching: expires 1y + versioning via query string.

For a catalog of 10,000 products, LCP went from 4.2 s to 2.1 s. Conversions improved by 12% after the speed fix. Want similar results? Order a free audit — we’ll evaluate your current layout and propose specific steps.

Deliverables after layout completion

When you order template development or adaptation, you receive:

• Source files of component templates with separation into template.php, result_modifier.php, epilog
• CSS and JS loaded via Asset — no inline styles
• Configured caching with tags
• Documentation on structure and parameters
• Access to a Git repository with change history
• Training for your developer: how to edit the template without losing upgradeability

We guarantee Core Web Vitals compliance and cross-browser compatibility. Each project is assigned a lead engineer with 10+ years of Bitrix experience.

Process:

1. Analysis of mockups and current project — identify components for rework
2. Structure design — break the page into BEM blocks
3. Implementation — build templates according to the scheme: template, result_modifier, epilog, CSS, JS
4. Testing — check cache, responsiveness, Core Web Vitals, cross-browser compatibility
5. Deployment — staging, acceptance, production

At each stage you get intermediate results and can make corrections. Contact our team for a project estimate — we’ll provide a timeline and cost within 1–2 days after receiving mockups.

Common mistakes in Bitrix layout

• SQL queries inside template.php — breaks caching and creates heavy load
• Inline <style> and <script> — breaks Asset concatenation and slows loading
• Missing result_modifier.php — logic mixed with presentation
• Direct $_REQUEST in cached components — user-specific data leaks
• Not using component_epilog.php for dynamic content — entire cache invalidated on each user action

Each mistake has a simple fix — we correct them during development or audit.

Timelines

Ready to improve your layout? Order a preliminary consultation — we’ll calculate timelines and budget individually.