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