Локализация интерфейсов ПО и систем управления: как избежать ошибок в переводе

Локализация интерфейса — это перевод и адаптация экранных строк для конкретного языка и условий работы пользователя. В программном обеспечении и АСУ ТП недостаточно правильно передать фразу: она должна помещаться на экране, сохранять смысл действия и совпадать с терминологией эксплуатационной документации.

Разберём эти задачи на примере локализации интерфейса АСУ ТП для газовой отрасли. В исходном массиве было 15 000 строк для перевода на английский, немецкий, китайский и арабский языки.

Чем локализация интерфейса отличается от перевода документа?

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

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

Особого внимания требуют четыре типа строк:

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

Для арабского языка добавляется проверка направления письма и расположения элементов интерфейса. Один только перевод текста не обеспечивает корректное отображение справа налево: это зависит и от реализации продукта.

Как заранее найти строки, которые не поместятся на экране?

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

В описанном случае псевдолокализация помогла выявить 180 потенциально обрезанных строк до перевода. Это не число ошибок в готовом продукте: речь о местах, которые потребовали внимания команды и проверки в макете или сборке.

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

Как сохранить единые термины в интерфейсе и документации?

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

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

Зачем проверять перевод в рабочей сборке?

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

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

Что дала проверка интерфейса АСУ ТП?

Предварительная проверка обозначила проблемные места до перевода. Затем локализованные строки протестировали в реальной сборке и сверили терминологию с руководством оператора. По материалам кейса, обнаруженные проблемы устранили до релиза.

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

Что передать для локализации интерфейса?

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

Ответы на часто задаваемые вопросы