Розробка мультимовного сайту на 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#/), символьні коди мають бути транслітеровані на кожну мову. Товар «Крісло офісне» → krislo-ofisne українською, 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 для кожної мови, відсутність дублів в індексі

Вартість визначається після аналізу обсягу контенту, кількості мов та обраної стратегії перекладу.