Чому машинний переклад ламає AI-локалізацію інтерфейсів
Класичний машинний переклад працює з рядком як з ізольованою одиницею тексту.
В інтерфейсі рядок майже ніколи не несе повного змісту: коротке «Зберегти» живе в модальному вікні одного сценарію, а «Зберегти як чернетку» — у меню іншого, і без контексту екрана рушій вибирає не той рід, відмінок і термін. Різниця видна не в красі формулювання, а в кількості дефектів, які ловить приймання.
Окрема проблема — змінні та підстановки всередині фрази. Рушій може переставити їх, склеїти із сусіднім словом або змінити порядок, і рядок або падає на форматуванні, або показує користувачеві сирий шаблон замість значення.
Скорочення в інтерфейсі погіршують картину: «Налашт.», «Кільк.», «Ред.» не мають усталеної словникової відповідності, і модель підставляє випадковий синонім, ламаючи однаковість по всьому продукту.
Далі починається різнобій термінів. Коли кожен рядок перекладається окремо, те саме поняття на сусідніх екранах звучить по-різному, а іноді й у трьох варіантах на одному екрані.
Користувач втрачає орієнтацію: незрозуміло, чи ведуть «Профіль», «Акаунт» і «Обліковий запис» в один і той самий розділ.
Замикає все цикл ручних правок після збірки. Їх вносять прямо в готові файли локалізації, вони не повертаються в пам'ять перекладів і глосарій, а наступна збірка затирає виправлення або приносить нові помилки на тих самих рядках.
Розбираємо, як це закривається в AI-локалізації, яка бачить контекст екрана цілком, а не окремий рядок.
Що дає контекстна AI локалізація інтерфейсу
Автоматична локалізація інтерфейсу працює не з окремими рядками, а із сегментами: кожен рядок іде на переклад разом із ключем, назвою екрана, обмеженням за довжиною та знімком місця, де він відображається.
Модель бачить, що «Зберегти» — це кнопка в модальному вікні, а не пункт меню, і добирає форму за родом, числом і відмінком. Змінні всередині рядків, форми множини та вкладені посилання перевіряються до збірки, тому зіпсована підстановка не доживає до тестового середовища.
Єдина термінологія тримається на глосарії та пам'яті перекладів. Глосарій фіксує обов'язкові терміни та заборонені варіанти, пам'ять повертає раніше узгоджений сегмент, якщо вихідний текст не змінювався.
Під час правок продукту перезбираються лише зачеплені сегменти, решта береться з накопиченої бази — тому нова мовна версія виходить інкрементально, а не збирається заново.
На практиці частка рядків, що доходять до ручного вичитування, падає з більшості до одиниць відсотків, а спірні місця повертаються редакторові з позначкою, чому вибрано саме цей варіант.
Обмін сегментами відбувається в галузевому форматі XLIFF, тому напрацювання не замикаються в одному інструменті й переносяться між редакторами та версіями продукту.
Термін випуску мовної версії визначається вже не обсягом тексту, а часом на розбір спірних сегментів — типово дні замість тижнів.
Термінологія при цьому не розповзається: на кожному релізі перевіряється, що новий текст використовує ті самі терміни, а розбіжності потрапляють у звіт для редактора, а не в інтерфейс.
Формати перекладу: пофразний, контекстний, з глосарієм
Варіанти відрізняються не якістю перекладу як такою, а тим, скільки відомостей про продукт ми подаємо на вхід.
Пофразний переклад бере рядок ізольовано, контекстний — разом з екраном, сусідніми елементами та даними підстановки, а глосарій проєкту й правила стилю фіксують термінологію та тон поверх будь-якого з режимів. Від цього залежить, де система помиляється і скільки ручної перевірки залишається на виході.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Пофразний переклад | Короткі підписи, кнопки, статуси; мови з простою морфологією | Омоніми та розірвані фрази дають помилки, рід і число не узгоджуються з підставлюваними значеннями |
| Контекстний переклад | Підказки, тексти помилок, листи, екрани з багатою морфологією | Потрібне вивантаження екранів і прив'язка ключів до блоків, під час оновлення інтерфейсу зв'язку треба перезбирати |
| Глосарій проєкту | Продукти з усталеною термінологією, галузеві та регульовані теми | Глосарій треба вести: синоніми, конфлікти термінів, відмінкові форми, регістр назв |
| Глосарій і правила стилю | Кілька команд, єдиний тон, довгі тексти довідки та онбордингу | Більше підготовки й ручної перевірки; правила без автотестів розходяться між релізами |
На практиці режими не конкурують, а комбінуються: пофразний залишається для коротких ключів, контекстний вмикається там, де рядок залежить від оточення, а глосарій і правила стилю працюють поверх обох.
Спірні випадки йдуть на ручну перевірку за формальною ознакою — розбіжність із глосарієм, довжина, розрив підстановки, — а не за смаком виконавця. Далі питання в тому, як рядки потрапляють у систему і що з ними відбувається під час оновлення продукту.
Як ми впроваджуємо контекстний переклад інтерфейсів
Локалізація ламається не на перекладі, а на контексті: рядок «Скасувати» на кнопці та в системному повідомленні вимагає різного роду й довжини, а без позначок перекладач вибирає навмання.
Тому ведемо роботу як інженерний процес — від аудиту рядків до регламенту, за яким нові тексти не ламають уже зібрані екрани.
- Аудит рядків інтерфейсу. Вивантажуємо рядки з ресурсних файлів і шаблонів, позначаємо дублі, використовувані в різних місцях, і відокремлюємо те, що правиться вручну під юридичні вимоги.
- Розмітка контексту. Рядок отримує екран, роль елемента, обмеження за довжиною, рід і число, перелік змінних підстановки — за ними модель відрізняє заголовок від підпису кнопки.
- Налаштування правил перекладу. Глосарій термінів, список «не перекладати» (ключі, власні назви, коди помилок) і єдине звертання до користувача, щоб формулювання не розходилися між екранами.
- Тестовий контур. Збираємо копію продукту й дивимося реальні екрани: обрізання тексту, перенесення, підстановка змінних, напрям тексту справа наліво, де він потрібен.
- Приймання перекладу. Носій мови розбирає спірні місця — ідіоми, скорочення, звертання — і повертає правки разом із причиною, щоб правило пішло в глосарій, а не в один рядок.
- Регламент оновлення. Без контексту рядок не проходить у збірку, а змінений глосарій підсвічує вже перекладені місця для повторної перевірки.
Після приймання команда отримує карту рядків, глосарій і правила: оновлення інтерфейсу йде тим самим контуром і не перетворюється на ручне звіряння екранів.
Артефакти проєкту: глосарії, правила, панелі контролю
Проєкт локалізації інтерфейсів живе довше, ніж триває впровадження: терміни з'являються, екрани змінюються, мови додаються. Тому разом із працюючою системою ми передаємо артефакти, які команда замовника править сама, без звернення до нас.
- Глосарій термінів — продуктові й технічні поняття із забороненими синонімами та позначкою «не перекладати»; система бере їх зі словника, тому один термін звучить однаково на всіх екранах і мовах.
- Правила стилю для кожної мови — звертання до користувача, регістр, довжина кнопок і підписів, формат чисел і дат; файл правил правиться без перезбирання системи.
- Панель контролю якості — частка рядків, що пройшли перевірку, черга спірних сегментів і розбіжності з глосарієм: видно, де система впевнена, а де потрібна людина.
- Документація з перекладу — опис процесу, ролей і точок перевірки; новий інженер входить у роботу за нею, а не за листуванням.
- Регламент оновлення словників — хто і як додає термін, скільки прикладів потрібно для приймання правки та як відкотити невдале правило.
- Набір тестових рядків з еталонною відповіддю — проганяється автоматично після кожної правки, регрес видно до релізу.
- Журнал рішень — спірні випадки з обґрунтуванням вибору, щоб за півроку ніхто не перевинаходив уже ухвалене.
Усе це зберігається у вашому репозиторії та версіонується разом із кодом: правка проходить перевірку, відкат можливий на будь-яку попередню версію словника. Супровід не потребує нас — ми залишаємося для розвитку, а не для рутинних правок.
Кейс: виведення продукту на вісім мов без ручного вичитування
Що було до
Продукт замовника — панель керування мережевою інфраструктурою на восьми мовах інтерфейсу. Рядки жили в таблицях виду «ключ — текст»: перекладач отримував файл без контексту й не бачив, де рядок з'явиться, якого він роду та скільки місця йому відведено на екрані.
Редактор повертав на доопрацювання близько 32% рядків, терміни розходилися між мовами, а випуск однієї нової мови займав шість тижнів.
Що змінили
Рядки та глосарій зведено в Phrase, і до кожного рядка автоматично прив'язується контекст: знімок екрана, сусідні підписи, обмеження за довжиною, ознака відмінюваності.
Глосарій закріпив терміни із забороною синонімів, пам'ять перекладів підставляє узгоджені формулювання замість повторного перекладу.
Збірка релізу проганяє перевірки: незакриті підстановочні мітки, перевищення довжини, терміни поза глосарієм. Провалилася перевірка — мова не потрапляє у випуск, а не спливає в інтерфейсі в користувача.
Що стало
Частка ручних правок після редактора впала з 32% до 4% — правки стосуються стилю, а не змісту й термінології. Спірні терміни в інтерфейсі скоротилися з 180 до 12, і всі закриті рішеннями глосарію.
Випуск мови займає дев'ять днів замість шести тижнів: переклад іде паралельно з розробкою, перевірки виконуються на кожній збірці, а не в кінці. Додавання дев'ятої мови звелося до підключення набору рядків — обв'язка, перевірки та глосарій уже працюють.
Чим контекстний переклад відрізняється від пофразного?
Пофразний переклад ріже інтерфейс на сегменти й обробляє кожен окремо: на вхід іде один рядок без сусідніх ключів, екрана та ролі користувача.
Працює швидко й передбачувано, але омонімію, рід і порядок слів система вгадує за частотністю — «Відкрити» в пункті меню та в діалозі підтвердження отримують один і той самий варіант.
Контекстний підхід подає на вхід групу: сусідні ключі, тип елемента (кнопка, підпис, текст помилки), обмеження за довжиною та затверджену термінологію продукту.
Система бачить, що перед нею заголовок розділу з трьох слів, а не частина речення, і вибирає форму за правилами мови, а не за статистикою.
| Підхід | Що бачить система | Де губиться зміст | Обмеження |
|---|---|---|---|
| Пофразний | один рядок без сусідів | омоніми, рід, порядок слів | термінологія не утримується між екранами |
| Контекст сегмента | рядок, сусідні ключі, тип елемента | рідко — на ідіомах і абревіатурах | потрібні розмічені зв'язки ключів |
| Контекст і глосарій | рядок, оточення, затверджені терміни, минулі версії | майже не губиться | потребує рев'ю термінології та оновлення пам'яті перекладів |
Обмеження пофразного перекладу не лікуються розміром моделі: якщо зміст не передано на вхід, відновлювати його нічим. Особливо помітна різниця на формах, помилках валідації та підказках, де рядок залежить від стану екрана.
Ми фіксуємо контекст в обмінному форматі XLIFF: ключ, вихідний текст, нотатки та зв'язки із сусідніми одиницями їдуть разом із сегментом, тому оточення не губиться під час вивантаження та повторної збірки. Ручне рев'ю все одно залишається — термінологію та юридично значущі формулювання перевіряє людина.
Часті технічні сумніви перед стартом проєкту
Перед стартом інженери та керівники напряму ставлять схожі питання: як переконатися, що переклад не попливе в інтерфейсі, що робити з уже готовими перекладами та як підключити глосарій, щоб терміни залишилися єдиними. Нижче — короткі відповіді, які зазвичай знімають сумніви до оцінки робіт.
Усі вони про механіку: на чому перевіряємо, як переносимо наявні рядки та що слугує точкою повернення. Якщо вашого питання тут немає — розберемо окремо та закладемо в план.
Як перевірити якість перекладу до релізу?
Збираємо контрольний набір рядків із вашого продукту — заголовки, кнопки, тексти помилок, листи. Розбіжності за термінами та довжиною підписів потрапляють у звіт, який ви читаєте до випуску.
У нас є готові переклади — переробляти все?
Ні. Переносимо наявні файли, зіставляємо ключі та показуємо конфлікти: де старий переклад розходиться з глосарієм або контекстом екрана. Рішення щодо кожного рядка залишається за вами.
Як підключається глосарій?
Файлом із парами «термін — переклад» і пріоритетом вище за модель: він перевизначає вибір системи. Нові терміни додаємо по ходу, зміни набувають чинності з наступної збірки.
Що якщо після релізу формулювання не влаштують?
Набори перекладів версіонуються. Невдалий реліз відкочується до попереднього набору цілком, а правка окремого рядка не потребує перезбирання решти інтерфейсу.
Обговоримо завдання перекладу інтерфейсу та повернемося з планом
Щоб оцінка спиралася на факти, а не на відчуття, нам потрібен короткий розбір вашого інтерфейсу: з чого він зібраний, як оновлюється та які мовні версії потрібні насамперед. Опишіть завдання — повернемося з планом робіт, термінами за етапами та складом команди.
На розборі уточнюємо:
- обсяг: скільки екранів і рядків, де тексти лежать у коді, а де — у системі керування перекладами;
- контекст: які дані потрібні моделі, щоб розрізняти роль користувача, стан екрана та зміст однакових рядків у різних місцях;
- мови та пріоритети: які версії запускаємо першими, чи потрібне письмо справа наліво, відмінювання та різні довжини формулювань;
- глосарій: як фіксуємо назви продукту, терміни, одиниці вимірювання, формати дат і чисел;
- вбудовування: де підключаємо переклад — у конвеєр збірки, в редактор контенту чи в обидва місця;
- регламент оновлень: як нові рядки потрапляють у переклад і як правки редактора повертаються в продукт без втрати;
- доступи та приймання: хто з боку замовника підтверджує якість і за якими критеріями ми вважаємо етап закритим.
За підсумками ви отримуєте карту рядків, глосарій, правила обробки контексту, схему вбудовування у ваш процес збірки та план першого запуску на одній мовній версії. Далі розширюємо на решту, не переробляючи основу. Напишіть, що за інтерфейс і які мови в пріоритеті, — повернемося з оцінкою та планом робіт.
