За последние годы машинный перевод сделал серьёзный шаг вперёд. Если раньше он использовался в основном туристами, пытающимися объясниться с местными за границей, то сегодня его активно применяют в бизнесе. Особенно востребован он при переводе технической документации: благодаря объемам, прямому стилю и предсказуемой структуре, машинный перевод обеспечивает хорошее качество и позволяет существенно экономить ресурсы и поддерживать стабильное качество.

Но можно ли использовать машинный перевод в интерфейсе — самой чувствительной части продукта для пользователя?

Я управляю локализацией цифровых продуктов с акцентом на масштабирование процессов, их интеграцию в продуктовые циклы и соответствие бизнес-целям. Один из ключевых векторов моей работы — внедрение решений, ускоряющих выход продукта на международные рынки, включая стратегическое использование машинного перевода. В этой статье, опираясь на реальный кейс из своей практики, я расскажу, как выявить типичные ошибки нейронного машинного перевода в интерфейсах и понять, насколько такой подход подходит для вашего продукта. Это поможет принять взвешенное решение: можно ли использовать машинный перевод интерфейса вашего продукта без ущерба для качества локализации и пользовательского опыта.

Кейс: можно ли доверить перевод интерфейса продукта машине

Когда компания готовится выходить на новые рынки, критически важно найти баланс между скоростью масштабирования и качеством пользовательского опыта. На этом этапе я хотела проверить: можно ли использовать машинный перевод интерфейсов как рабочий инструмент без ущерба для восприятия продукта и при минимальных затратах на ручной перевод.

Цель эксперимента была прагматичной:

• протестировать может ли движок дать хороший перевод “из коробки” для быстрого запуска на новых языках,

• понять, будет ли последующая работа с машинным переводом выгоднее с точки зрения времени и ресурсов.

Мы не стремилась полностью автоматизировать локализацию: передо мной стояла задача проверить, можно ли без значительных вложений «прощупать» новые рынки. При этом интерфейс на локальном языке не должен был становиться барьером, напротив, он должен был оставлять у пользователей положительное впечатление и помогать вовлекать потенциальных клиентов.

Наше исследование

Мы выбрали несколько движков машинного перевода для тестирования на трех языках, перевели ресурсы в CAT-системе, подготовили скриншоты с переводом и отправили лингвистам для оценки качества. Они дали полноценную оценку качества, как общую характеристику переведённых экранов, так и характеристику каждой строки на предмет грамматических, лексических и стилистических ошибок, а также оценили процент соответствия перевода интерфейсному контексту и функционалу. 

В результате, некоторые движки показали результат выше 70% соответствия переводов интерфейсному контексту и функционалу переводов, особенно на испанский и португальский языки. Это уже хороший результат, однако использовать решения машинного перевода “из коробки”, несмотря на их стремительное развитие, все еще рискованно.

С чем движки машинного перевода не справились и как это влияет на UX

Даже самые продвинутые движки допускали ошибки, которые могли бы негативно сказаться на пользовательском опыте, если использовать машинный перевод «из коробки», без настройки и постредактуры.

На основе результатов тестирования я выделила ключевые типы ошибок, критичных именно в контексте пользовательского интерфейса:

• Перевод двусмысленных команд без учёта контекста интерфейса
  Пример: Run → Correr (по-испански «бежать») вместо Ejecutar («запустить»).
  Проблема: Буквальный перевод дезориентирует пользователя, особенно на кнопках, где важна мгновенная ясность.
  Риск: снижение кликабельности, рост отказов при первом взаимодействии.

• Перевод омонимов без учёта функциональной роли
  Пример: Pack samples → «Пакет образцов» вместо «Паковать образцы».
  Проблема: Движок воспринимает pack как существительное, а не как глагол.
  Риск: ошибки в CTA и командных блоках могут нарушить сценарий пользователя.

  

• Ошибки в регистре (capitalization)
  Пример: Privacy Notice → Aviso de Privacidad (Заголовочный регистр вместо строчного).
  Проблема: Нарушение норм снижает ощущение локализации как «родной».
  Риск: понижение доверия, особенно в разделах конфиденциальности и платежей.

• Неправильная интерпретация аббревиатур
  Пример: TIN (Taxpayer Identification Number) → estaño (олово).
  Проблема: движок принимает аббревиатуру за обычное слово, что приводит к искажению смысла.
  Риск: серьезные ошибки в юридичеcки значимых разделах.

• Стилевой разнобой в списках
  Пример: смесь инфинитива и императива в одном списке.
  Проблема: Нарушает ритм и структуру интерфейса.
  Риск: повышение когнитивной нагрузки, увеличение времени на выполнение задачи.

• Неоправданные уточнения и усложнения
  Пример: Any OS → Tout système d'exploitation вместо просто OS; More → Plus d'information вместо просто Plus.
  Проблема: Избыточная формальность утяжеляет интерфейс.
  Риск: интерфейс становится менее дружелюбным.

  

• Конверсии: некорректный CTA снижает кликабельность;

• Понимания продукта: искаженные команды или термины могут привести к недоверию;

• Удержания: пользователь, запутавшийся в интерфейсе, может просто уйти;

• Расходов: исправление таких ошибок на проде дороже, чем тестирование и постредактирование на этапе запуска.

Поэтому даже при использовании машинного перевода важно заранее определить зоны риска и вложиться в минимальный уровень редактуры. Это особенно важно для интерфейсных текстов, где ошибка видна сразу.

Мы приняли решение использовать машинный перевод, но всегда с редактурой лингвиста-носителя языка. Чтобы сократить время на постредактирование и QA локализации, я сосредоточила свои усилия на глоссарии, который существенно расширила, а также протестировала подход с предварительным уточнением входных данных для движка — добавляла инструкции к переводу, чтобы сохранить ключевые технические элементы (переменные, аббревиатуры). Это помогло сократить количество типичных ошибок и повысить читаемость перевода на выходе.

Такой подход можно развивать дальше, включая более глубокое предварительное редактирование (pre-editing): добавлять подсказки с информацией о продукте, его стиле общения, целевой аудитории и даже конкретных фичах, которые сейчас проходят локализацию.

Как масштабировать тестирование машинного перевода и сохранить выгоду от автоматизации

Однако важно понимать, что чем сложнее структура промтов, тем выше риск непредсказуемого поведения модели. Поэтому необходимо регулярно проверять результаты на макетах или на этапе препродакшена, чтобы убедиться, что качество перевода не пострадало и контекст не искажен.

Эксперимент с машинным переводом интерфейса получил положительную оценку внутри компании. Теперь при добавлении новых локалей в других продуктах, включая более масштабные, тестирование качества машинного перевода стало частью стандартного процесса. Но здесь возник новый вызов: если проверять все интерфейсы целиком, это сведёт на нет основное преимущество машинного перевода — экономию времени и ресурсов.

Поэтому, опираясь на типовые ошибки, с которыми я столкнулась во время тестирования, я сформулировала критерии отбора экранов для оценки. Такой подход помогает сфокусироваться на участках с наибольшим риском ошибок, избежать лишних затрат и при этом получить объективное представление о качестве перевода.

Лучше всего тестировать машинный перевод на экранах:

• Со множеством команд, кнопок и других коротких текстовых элементов — чтобы выявить ошибки двусмысленных переводов и неправильной интерпретации функциональных терминов (например, неверный перевод глаголов-команд или омонимов), а также неоправданные уточнения, которые усложняют интерфейс.

• С развернутыми фразами и предложениями — чтобы проверить, сохраняет ли движок корректное употребление регистра (capitalization), придерживается ли стиля исходного текста и правильно интерпретирует аббревиатуры в контексте.

• Содержащих списки из нескольких (не менее трёх) пунктов или опций — чтобы убедиться, что машинный перевод сохраняет грамматическое согласование и последовательность стиля, избегая смешивания форм (например, инфинитив и повелительное наклонение) внутри одного списка.
  

Заключение

Локализация интерфейса — один из самых тонких этапов адаптации продукта для новых рынков. Здесь перевод сталкивается с особыми вызовами: короткими и контекстно зависимыми элементами, культурными особенностями и высокими ожиданиями пользователей. Использование нейронного машинного перевода в интерфейсе возможно, но этот перевод требует тонкой настройки, постредактуры и разумной стратегии тестирования.

Чтобы понять, насколько машинный перевод применим к вашему продукту, достаточно начать с малого — протестировать несколько тщательно отобранных экранов. Выбирайте те, где выше риск ошибок: с короткими UI-элементами, списками и более развернутыми фразами. Это даст вам представление о том, какие движки справляются лучше, где возможны сбои и сколько усилий потребуется на редактуру. Такой подход позволяет извлечь максимум пользы из машинного перевода — без потерь в качестве и пользовательском опыте.