Майже кожен другий проєкт, який приходить до нас, починається з фрази: «Сайт має бути українською та англійською. І, можливо, ще польською». Це звучить як невелика деталь у технічному завданні. На практиці ж мультимовність — одна з тих речей, які коштують бізнесу набагато більше, ніж здається на старті.
І справа тут не в технології. Зробити перемикач мов у Laravel — питання кількох годин. Справа в контенті, який живе: з’являються нові сторінки, змінюються описи товарів, публікуються новини, оновлюються умови доставки. І кожна така зміна потребує перекладу.
У цій статті ми розповімо, як побудували автоматизований пайплайн перекладу на базі ШІ всередині Laravel-проєкту, які архітектурні рішення прийняли, на які граблі наступили і — головне — де межа, за якою автоматизацію все ще варто контролювати людиною.
Проблема, з якою стикається майже кожен мультимовний сайт
Типова картина виглядає так.
Контент-менеджер додає нову сторінку українською. Далі текст іде до перекладача або агентства. Через два-п’ять днів повертається англійська версія, яку потрібно вручну вставити в адмінку, перевірити, чи не зламалась верстка, і опублікувати. Якщо мов три — помножте на три.
У результаті бізнес отримує:
- постійний розсинхрон між мовними версіями — українська вже оновлена, англійська ще «стара»;
- витрати, що ростуть пропорційно кількості контенту та мов;
- вузьке місце в процесі — переклад стає причиною, чому нова сторінка виходить із запізненням;
- ручну роботу з копіюванням текстів, під час якої губляться посилання, форматування та SEO-поля;
- страх додавати нову мову, бо це означає ще один повний цикл перекладу всього сайту.
Найпоказовіше те, що більшість цього контенту — не унікальна маркетингова творчість. Це описи товарів, технічні характеристики, новини, FAQ, службові повідомлення. Тобто саме той тип тексту, з яким сучасні мовні моделі справляються дуже добре.
Чому «просто підключити перекладач» не працює
Перша ідея, яка виникає у кожного розробника: викликати API машинного перекладу при збереженні запису і закрити питання. Ми теж із цього починали. І досить швидко зрозуміли, чому цього недостатньо.
Втрата контексту. Слово «замок» у розділі про нерухомість і в каталозі фурнітури — це різні слова. Класичний машинний переклад бачить речення, а не сторінку.
Термінологія. У кожного бізнесу є свої терміни: назви продуктів, тарифів, послуг, внутрішні поняття. Їх не можна перекладати щоразу по-різному. «Особистий кабінет» не має ставати то Account, то Personal Office, то Dashboard залежно від настрою алгоритму.
Розмітка та плейсхолдери. Тексти в реальних проєктах містять HTML, посилання, змінні на кшталт {name} або :count, Markdown. Наївний переклад регулярно ламає теги, переставляє атрибути або перекладає сам плейсхолдер.
Tone of voice. Бренд, який спілкується з клієнтом на «ти» і з легкою іронією, не може в англійській версії раптом звучати як юридичний договір.
SEO. Мета-теги, alt-тексти, slug сторінки, hreflang — усе це теж частина мультимовності. Якщо перекласти тільки «тіло» сторінки, для пошукової системи ви отримаєте напівпереклад.
Тобто задача не в тому, щоб перекласти текст. Задача — побудувати процес, у якому переклад є керованим, консистентним і не блокує публікацію.
Порада від Molfar: перш ніж обирати інструмент перекладу, опишіть, які саме типи контенту у вас є і чим вони відрізняються. Картка товару, юридична оферта та пост у блозі потребують різного підходу — і різного рівня контролю.
Як ми це побудували: архітектура рішення
Далі — коротко про те, як це влаштовано зсередини. Ми навмисно описуємо принципи, а не код: вони переносяться на будь-який стек, хоча наш базовий — Laravel.
1. Одне джерело правди
Кожен запис має мову-оригінал. Саме її редагує контент-менеджер, і саме вона є еталоном. Усі інші мовні версії — похідні. Це принципово: ми не дозволяємо системі опинитися в ситуації, коли англійський і український тексти незалежно «розійшлись» і ніхто не знає, який із них актуальний.
2. Переклад — асинхронна подія, а не синхронний виклик
Коли контент зберігається, ми не перекладаємо його «тут і зараз». Ми фіксуємо подію: «оригінал змінився». Далі спрацьовує черга (Laravel Queue), і окремі задачі перекладу виконуються у фоні для кожної цільової мови.
Це дає одразу кілька переваг:
- редактор не чекає 10–20 секунд на відповідь моделі під час збереження;
- помилка зовнішнього API не блокує публікацію оригіналу;
- задачі можна повторювати, обмежувати за кількістю запитів і масштабувати незалежно від основного застосунку.
3. Модель отримує контекст, а не лише текст
Це ключова відмінність від «просто перекладача». Перед викликом ШІ ми збираємо пакет контексту:
- тип контенту (картка товару, новина, сторінка послуги, системне повідомлення);
- глосарій компанії — терміни, які мають перекладатися завжди однаково або не перекладатися взагалі;
- опис tone of voice бренду;
- кілька вже схвалених людиною перекладів такого ж типу як приклад стилю;
- явні правила: не змінювати HTML-структуру, не чіпати плейсхолдери, зберігати довжину заголовків у розумних межах.
Саме контекст перетворює загальну мовну модель на «перекладача, який знає вашу компанію».
4. Структурована відповідь замість вільного тексту
Ми не просимо модель «перекласти цей HTML». Ми розбираємо контент на поля — заголовок, підзаголовок, тіло, мета-опис, alt-тексти — і просимо повернути результат у чітко визначеній структурі (JSON). Потім кожне поле проходить валідацію: чи збереглися теги, чи на місці плейсхолдери, чи не перевищена довжина мета-тегу.
Якщо валідація не пройшла — задача повторюється з уточненням. Якщо не пройшла і після повторів — переклад позначається як «потребує уваги», і про це дізнається редактор.
5. Людина залишається в процесі — але не на критичному шляху
Кожен автоматичний переклад зберігається зі статусом. Ми використовуємо просту модель:
- auto — згенеровано ШІ, ще не переглянуто;
- approved — переглянуто і схвалено людиною;
- stale — оригінал змінився після перекладу, версію потрібно оновити;
- manual — редактор переписав текст власноруч; автоматика його більше не чіпає без явного дозволу.
Для яких типів контенту переклад зі статусом auto можна публікувати одразу, а для яких — тільки після схвалення, вирішує бізнес, а не система. Картка товару з характеристиками може виходити автоматично. Публічна оферта — ні.
6. Fallback: сайт ніколи не показує порожнє місце
Якщо переклад ще не готовий, відвідувач бачить версію мовою-оригіналом або базовою мовою сайту, а не пустий блок чи технічний ключ. Це очевидна річ, яку, на диво, часто забувають.
7. SEO як частина перекладу, а не окрема задача
Мета-заголовок, мета-опис, alt-тексти зображень і slug генеруються в межах тієї ж задачі, що й основний текст. Для slug ми додатково застосовуємо транслітерацію та перевірку унікальності. Hreflang-теги формуються автоматично на основі того, які мовні версії реально існують та опубліковані.
8. Вартість, ідемпотентність і контроль
Переклад через API коштує грошей, тому:
- ми не перекладаємо повторно те, що не змінилося — для кожного поля зберігається хеш оригіналу;
- задачі ідемпотентні: повторний запуск не створює дублікатів і не «перезатирає» ручні правки;
- ведемо облік витрат на переклад у розрізі типів контенту, щоб бізнес бачив, куди йдуть гроші.
Порада від Molfar: заведіть глосарій ще до того, як почнете автоматизувати переклад. Це найдешевший спосіб суттєво підвищити якість результату — і водночас корисний документ для всієї команди, а не тільки для ШІ.
Що це дало бізнесу
Найпомітніший ефект — зникло вузьке місце. Нова сторінка з’являється всіма мовами практично одразу після публікації оригіналу, а не через кілька днів. Контент-менеджер працює однією мовою; перевірка перекладів стала окремою, необов’язковою для запуску задачею, яку можна робити в зручному темпі.
Другий ефект — передбачувана вартість. Витрати на переклад більше не залежать від того, чи знайдеться вільний перекладач цього тижня, і рахуються в термінах обсягу контенту, а не кількості годин.
Третій — і, на нашу думку, найважливіший стратегічно — додати нову мову стало дешево. Раніше нова мова означала повний цикл перекладу всього сайту з відповідним бюджетом і термінами. Тепер це зміна в конфігурації плюс фоновий процес, який поступово наповнює нову версію.
Побічний, але приємний бонус: якість самих оригінальних текстів зросла. Коли команда знає, що текст буде перекладено автоматично, вона починає писати чіткіше та структурованіше.
Де ми свідомо не довіряємо автоматиці
Ми не вважаємо, що ШІ-переклад — це універсальна відповідь. Є категорії контенту, які в наших проєктах проходять обов’язкове схвалення людиною або взагалі перекладаються вручну:
- юридичні тексти — договори, оферти, політики конфіденційності, умови повернення;
- брендові слогани та ключові маркетингові повідомлення — тут важлива не точність, а влучність;
- фінансова та медична інформація, де ціна помилки надто висока;
- контент із культурним підтекстом — жарти, ідіоми, локальні відсилки.
Для всього іншого — каталогів, новин, FAQ, описів послуг, системних повідомлень — автоматичний переклад із вибірковою перевіркою працює надійно.
Порада від Molfar: не намагайтесь автоматизувати 100% контенту з першого дня. Почніть із найбільш масового і найменш ризикового типу — наприклад, карток товарів — і розширюйте покриття, коли переконаєтесь у якості.
Типові помилки під час впровадження
Кілька речей, які ми або зробили самі, або бачили в чужих проєктах:
- Синхронний переклад при збереженні. Здається простим, але робить адмінку повільною і ненадійною.
- Відсутність статусів. Якщо не розрізняти «автоматичний» і «схвалений» переклад, редактор не знає, що саме потрібно перевірити.
- Переклад цілого HTML одним запитом. Модель може переставити теги або «поліпшити» структуру. Розбивайте на поля.
- Перезапис ручних правок. Найгірший сценарій: редактор годину шліфував текст, оригінал оновили, і автоматика все стерла. Ручні правки мають бути захищені.
- Ігнорування SEO-полів. Перекладене тіло сторінки з українським мета-описом — це не мультимовний сайт.
- Відсутність обмежень. Без rate limiting і обліку вартості одна масова зміна каталогу може несподівано згенерувати тисячі запитів до API.
Висновок
Мультимовність — це не перемикач у шапці сайту. Це процес, який супроводжує кожну зміну контенту протягом усього життя проєкту.
Сучасні мовні моделі вперше дозволяють зробити цей процес автоматичним без втрати якості — але тільки за умови, що навколо моделі побудована правильна архітектура: контекст, валідація, статуси, участь людини там, де вона справді потрібна.
І правильне питання для бізнесу тут звучить не: «Чи можна замінити перекладача штучним інтелектом?»
А: «Скільки контенту ми не публікуємо іншими мовами лише тому, що переклад — це дорого і довго?»
Саме відповідь на це питання визначає, чи потрібна вам така автоматизація.
Molfar Insight
Ми не вважаємо, що кожному сайту потрібен ШІ-пайплайн перекладу. Якщо у вас десять сторінок, які змінюються раз на рік, — професійний перекладач зробить це краще і дешевше.
Але якщо контент живе і оновлюється щотижня, а мовних версій дві і більше, вартість «ручної» мультимовності зростає непомітно і постійно. У такому випадку інвестиція в автоматизований процес окуповується не через економію на одному перекладі, а через те, що сайт нарешті починає говорити з усіма клієнтами одночасно.
Правильна автоматизація — це не та, що повністю прибирає людину з процесу, а та, що залишає їй лише рішення, які справді потребують людини.