Multilingual website development on 1C-Bitrix

Multilingual Website Development on 1C-Bitrix

Multilingual support in Bitrix is not "install a translator plugin." It's an architectural decision that affects info block structure, URL routing, caching, SEO markup, and 1C integration. On a project with three languages and a 20K product catalog, the wrong approach to storing translations turns every product update into triple the work for the content manager.

Two Approaches: Multi-Site vs Subdirectories

Bitrix has no built-in "multilingual" module in the WPML or Laravel Translatable sense. Language versions are implemented through mechanisms built into the core, but they need to be combined correctly.

Multi-site via SITE_ID — each language = a separate site in the system. s1 — Russian, s2 — English, s3 — German. Each site gets its own domain or subdomain (en.company.com, de.company.com), its own template, its own language files. Info blocks are linked to the relevant sites.

Advantages:

• Complete content isolation — different info blocks for different languages, different catalog sections
• You can show different product ranges for different regions
• Cache doesn't overlap — each SITE_ID is cached separately

Disadvantages:

• Info block duplication. If the catalog is shared but descriptions are in three languages — three info blocks with identical structure. Updated the price in Russian — need to update in English and German. Automation via the OnAfterIBlockElementUpdate handler, but that's custom development
• Duplication of SEO settings, component templates, URL rules

Subdirectories — one site, language versions in /en/, /de/, /fr/. Language detection through the first URL segment. One info block with additional properties for each language: NAME_EN, DETAIL_TEXT_EN, NAME_DE, DETAIL_TEXT_DE.

Advantages:

• One info block — one point of product management
• SEO juice isn't diluted across domains
• Simpler for hreflang — all versions on one domain

Disadvantages:

• Property bloat. With 5 languages, every text field is multiplied by 5. The b_iblock_element_property table grows 5x
• Components need modification: result_modifier.php substitutes the NAME_{LANG} property value instead of the standard NAME

In practice, the multi-site approach works more often for commercial projects — it's architecturally cleaner, though more expensive to set up.

Language Files: Interface vs Content

Bitrix separates interface translation from content translation.

Interface — buttons, headings, form labels, system messages. Stored in language files lang/ru/, lang/en/, lang/de/ alongside templates and components. Each PHP file of a component or template has a corresponding language file. Loaded via Loc::getMessage('BUTTON_SUBMIT') or the deprecated GetMessage().

A typical mistake — hardcoded strings in templates. <button>Отправить</button> instead of <button><?= Loc::getMessage('FORM_SUBMIT') ?></button>. Invisible on the Russian site, but when adding a second language — manual search through all templates.

Content — page text, product descriptions, news. Stored in info blocks. Options:

• Separate info blocks for each language (with multi-site)
• Additional properties DETAIL_TEXT_EN, PREVIEW_TEXT_EN (with subdirectories)
• Highload translation reference — a table {ENTITY_TYPE, ENTITY_ID, LANG, FIELD, VALUE}. Flexible, but requires custom components for output

URL Structure and hreflang

Three URL options:

hreflang is mandatory for correct indexing. Without it, Google may show German users the Russian version of a page. Implementation:

<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/" />

Bitrix has no built-in hreflang mechanism. We add it through the template's header.php or via the OnEndBufferContent handler. The key challenge — mapping URLs of different language versions of the same product. If URLs are generated from symbolic codes (DETAIL_PAGE_URL => /catalog/#SECTION_CODE#/#CODE#/), the symbolic codes must be transliterated for each language. The product "Кресло офисное" → kreslo-ofisnoe in Russian, office-chair in English. Mapping — through a shared ID or a binding property between info blocks of different languages.

Content Translation: Manual, Automatic, Hybrid

Manual translation — maximum quality, minimum speed. For a catalog of 20K products with 5 text fields and 3 languages — 300K translation units. A professional translator handles 2-3K words per day.

Machine translation — Google Translate API, DeepL API, Yandex.Translate. We integrate into the admin panel: a "Translate" button next to the field, auto-fill on element creation. Quality is sufficient for technical descriptions, insufficient for marketing copy.

Machine translation pitfalls:

• Terminology — the machine doesn't know that "подшипник SKF 6205-2RS" shouldn't be translated. You need a glossary with exceptions
• HTML markup — the translation API can break tags. <strong>Гарантия</strong> 2 года turns into <strong>Guarantee 2</strong> years. We parse HTML and translate text nodes separately
• API limits — Google Translate: $20 per 1M characters. A catalog of 50K products with descriptions — 10-50M characters. Calculate in advance
• SEO quality — search engines can detect machine translation. For landing pages and categories — manual translation only, for product cards — machine translation with proofreading

Hybrid approach — machine translation for mass content (product cards, specs), manual for strategic pages (homepage, categories, landing pages). Works for 80% of projects.

RTL: Arabic, Hebrew

If Arabic or Hebrew is among the target languages — that's a separate layer of work.

• The dir="rtl" attribute on <html> — switches by LANGUAGE_ID
• CSS — logical properties instead of margin-left/margin-right: margin-inline-start, padding-inline-end. Or a mixin/utilities for mirroring
• Fonts — Arabic typography requires its own fonts, font-family switches by language
• Numbers, dates, currencies — Arabic numerals, date format, text direction in tables

Bitrix doesn't support RTL "out of the box" at the template level. Core CSS classes are LTR. Solution: a separate CSS theme for RTL languages, loaded by LANGUAGE_ID, or a PostCSS plugin that generates mirrored CSS automatically.

Stages

1. Language and market analysis (3-5 days) — which languages, which regions, what content is unique, what's shared
2. Architecture selection (2-3 days) — multi-site vs subdirectories, URL structure, translation strategy
3. Infrastructure setup (1-2 weeks) — creating sites/subdirectories, language files, routing
4. Template adaptation (2-4 weeks) — interface localization, hreflang, language switcher, RTL if needed
5. Content translation (2-8 weeks) — depends on volume, strategy, and number of languages
6. SEO audit (3-5 days) — checking hreflang, canonical, sitemap for each language, no duplicates in the index

Cost is determined after analyzing content volume, number of languages, and the chosen translation strategy.