Интеграция машинного перевода контента для 1С-Битрикс

Интеграция машинного перевода контента для 1С-Битрикс

Перевести каталог в 20 000 товаров на три языка силами переводчиков — это месяцы работы и значительный бюджет. Машинный перевод закрывает 80–90% объёма за часы, оставляя переводчикам только корректуру критически важных текстов: главную страницу, лендинги, юридические документы. Но интеграция MT-сервиса с 1С-Битрикс — не просто «вызвать API», там есть нетривиальные технические задачи.

Выбор MT-сервиса: что важно для Битрикс

Основные кандидаты: DeepL, Google Cloud Translation, Yandex Translate. Все три предоставляют REST API, но различаются по качеству для конкретных языковых пар и по отношению к специфичным проблемам контента e-commerce:

DeepL — лучшее качество для европейских языков (DE, FR, EN, PL). API v2 поддерживает формат text/html — переводит текст, сохраняя HTML-теги. Это критично для описаний товаров с вёрсткой.

Google Cloud Translation — широкий охват языков (200+), поддержка CIS-языков (KZ, UZ, AZ). Базовая модель (translate/v2) дешевле, NMT-модель (translate/v3) точнее.

Yandex Translate — оптимально для пары RU→KZ, RU→BE. API v2 поддерживает пакетную передачу до 10 000 символов за запрос.

Проблема №1: HTML в описаниях товаров

Описания в b_iblock_element поле DETAIL_TEXT часто содержат HTML-разметку. Если передать такой текст в MT-API как plain text — теги переведутся буквально: <strong> станет <сильный> (у Yandex это реальный кейс при передаче без указания формата).

Решение для Google Translation v3:

$client = new TranslationServiceClient();
$response = $client->translateText([
    'parent' => 'projects/{project}/locations/global',
    'contents' => [$htmlContent],
    'mimeType' => 'text/html',  // Критично!
    'sourceLanguageCode' => 'ru',
    'targetLanguageCode' => 'en',
]);

DeepL: параметр tag_handling=html в запросе. С этим флагом DeepL переводит только текстовые ноды, не трогая атрибуты тегов и структуру разметки.

Проблема №2: переменные и шорткоды в контенте

В описаниях товаров встречаются внутренние подстановки: {SIZE_GUIDE}, [product_id=123], <!--#include file="..."-->. MT-сервис может «перевести» эти конструкции — сломав функциональность.

Решение: перед отправкой в MT заменяем все служебные конструкции на плейсхолдеры, которые MT-сервис не трогает. Для DeepL используем ignore_tags или обрамляем конструкции в <keep> теги. После перевода делаем обратную замену.

$placeholders = [];
$pattern = '/\{[A-Z_]+\}|\[product_id=\d+\]/';
$text = preg_replace_callback($pattern, function ($match) use (&$placeholders) {
    $key = 'PLACEHOLDER_' . count($placeholders);
    $placeholders[$key] = $match[0];
    return $key;
}, $originalText);

// Переводим $text...

// Восстанавливаем плейсхолдеры
foreach ($placeholders as $key => $value) {
    $translatedText = str_replace($key, $value, $translatedText);
}

Пакетная обработка и лимиты API

Для каталога в 20 000 позиций нельзя переводить по одному запросу на товар — это и медленно, и дорого. Пакетная обработка:

• Google: до 1024 строк за запрос
• DeepL: до 50 текстов за запрос
• Yandex: до 10 000 символов суммарно за запрос

Реализуем очередь перевода: каждый товар — задача в очереди. Воркер берёт пакет, отправляет в MT-API, сохраняет результат. При ошибке — повтор с экспоненциальной задержкой.

Переводы сохраняем в языковые версии элементов (b_iblock_element_lang) через CIBlockElement::SetPropertyValues() с указанием LANGUAGE_ID. После сохранения инвалидируем кэш элемента.

Постредактирование: флаги для переводчика

Машинный перевод не финальный. Нужна возможность для переводчика пометить перевод как «требует проверки» или «отредактирован вручную». Добавляем свойство инфоблока MT_STATUS (список: auto, reviewed, manual) для каждого языка. Переводчик видит только элементы со статусом auto — не перебирает весь каталог.

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

Стоимость рассчитывается индивидуально. Учитываются: объём контента, количество языков, выбранный MT-сервис и требования к качеству перевода.