Перевод в ИТ и инновациях: когда текст является частью продукта, а не документом о нём

Все предыдущие статьи этого цикла описывали работу с документами. Инструкция, регламент, проект, контракт — это завершённые тексты с автором, датой и версией. Переводчик получает файл, возвращает файл, проект закрывается.

В ИТ так не работает.

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

Именно поэтому в этой сфере употребляют слово локализация, а не «перевод». И это не маркетинговая замена термина, а точное описание другого типа работы.

Что входит в сферу

Программные продукты. Интерфейсы десктопных, веб- и мобильных приложений, SaaS-платформы, встроенное программное обеспечение, административные панели.

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

Маркетинг. Сайты и лендинги, описания в магазинах приложений, рассылки, кейсы, блоги, презентации.

Юридические тексты. Условия использования, лицензионные соглашения, политики конфиденциальности, соглашения об обработке данных.

Учебные материалы. Онбординг, курсы, сертификационные программы, видео и субтитры.

Инновации. Патентные заявки, грантовые проекты, материалы для инвесторов, документация R&D, due diligence.

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

Особенность первая: текст живёт в коде

Локализационный файл — это не документ, а структура данных. Практические следствия:

Плейсхолдеры и переменные. Строка «Deleted %d files from %s» содержит два подставляемых значения. Их нельзя переводить, терять или менять местами без специального синтаксиса. В языках, где порядок слов естественно другой, нужны позиционные аргументы (%1$s, %2$s), и если разработчик их не предусмотрел, это проблема разработчика, которую локализатор должен заметить и обозначить.

Разметка внутри строк. HTML-теги, ссылки, форматирование. Теги сохраняются, текст внутри переводится, атрибуты — в зависимости от типа.

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

Ключи строк. Идентификаторы, по которым приложение обращается к тексту. Не переводятся никогда.

Множественное число: главный технический вызов русской локализации

В английском две формы множественного числа: 1 file / 2 files. В русском четыре: 1 файл, 2 файла, 5 файлов, 1,5 файла.

Это означает, что строка, в которой разработчик предусмотрел две формы, физически не может быть корректно локализована на русский. Правильное решение — использование стандартного механизма плюрализации (ICU MessageFormat или plural forms в gettext), который поддерживает нужное количество форм.

Локализатор, который просто пишет «файл(ов)» или «5 файла», прячет проблему вместо того, чтобы её решить. Профессиональный подход — зафиксировать дефект интернационализации и передать команде разработки.

Склонение и род

Две родственные сложности, которых нет в английском:

Подставляемые значения не склоняются. «Удалить {filename}?» работает, а «Перейти к {section}» уже требует дательного падежа от слова, которого локализатор не видит. Решение — перестройка фразы в конструкцию, не требующую согласования.

Род не определён. «User added a comment» по-русски требует выбора: добавил или добавила. Варианты — безличная конструкция («Комментарий добавлен») или техническое решение на стороне продукта.

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

Особенность вторая: строка без контекста

Самая распространённая причина ошибок локализации — не незнание языка, а отсутствие контекста.

Слово Open может быть действием на кнопке (Открыть) или статусом в списке (Открыт). Post — существительное или глагол. Free — бесплатный или свободный. Set — набор или установить. Home — главная страница, домашний экран или начало. В ресурсном файле это просто строки, вырванные из интерфейса.

Что даёт решение:

• скриншоты или доступ к сборке продукта;
• комментарии разработчика к строкам (максимальная длина, тип элемента, пояснение);
• информативные ключи: button.settings.save вместо str_0147;
• просмотр перевода непосредственно в интерфейсе перед релизом.

Вопрос «дайте контекст» от локализатора — это не признак непрофессионализма, а признак противоположного. Исполнитель, который никогда не задаёт таких вопросов, просто угадывает.

Особенность третья: ограничения пространства

Русский при переводе с английского в среднем длиннее на 10–15 %, а на коротких строках — вдвое и больше. Самые острые зоны:

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

Рабочие подходы: ограничения длины задаются в самом файле и проверяются автоматически; для критичных мест применяется псевдолокализация на стороне разработки, которая ещё до перевода показывает, где текст не поместится.

Особенность четвёртая: процесс не имеет конца

Продукт выпускается спринтами. Каждый релиз приносит новые строки, изменённые строки и удалённые строки. Пакетная модель «собрали за квартал, отправили на перевод» здесь не работает: локализация должна двигаться вместе с разработкой.

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

Последствия для качества:

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

Терминология: три разные проблемы

Проблема первая: соответствие платформе

Приложение живёт не само по себе, а в среде операционной системы. Если в системе элемент называется «Настройки», в приложении не может быть «Установки». Если система говорит «Учётная запись», продукт не говорит «Аккаунт».

Источники истины — официальные терминологические базы и стилистические руководства платформ. Это не вопрос вкуса: пользователь воспринимает несоответствие как ошибку продукта.

Проблема вторая: терминология, которая ещё не устоялась

Искусственный интеллект, DevOps, блокчейн, кибербезопасность — сферы, где терминология формируется прямо сейчас. У одних понятий есть несколько конкурирующих вариантов, у других нет ни одного устоявшегося.

Правило, которое работает: последовательность внутри продукта важнее «правильности вообще». Решение принимается один раз, вместе с клиентом, фиксируется в глоссарии и соблюдается. Худший вариант — когда в пределах одного интерфейса появляются «развёртывание», «деплой» и «деплоймент».

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

Проблема третья: ложные друзья ИТ-перевода

• application — приложение в программном контексте, но заявка в бизнес-контексте;
• image — образ (диска, контейнера) или изображение; два разных термина;
• library — библиотека, и в этом значении это не «книгохранилище»;
• thread — поток выполнения или ветка обсуждения;
• instance — экземпляр;
• host — узел, хост или принимать (как глагол);
• driver — драйвер, а не «водитель» и не «фактор»;
• commit, branch, merge — устоявшиеся соответствия в контроле версий, которые не совпадают с бытовыми значениями;
• resolution — разрешение экрана или решение проблемы;
• execute — выполнить.

Отдельно — нормы правописания: «веб-» присоединяется через дефис (веб-сайт, веб-сервис, веб-приложение), «онлайн» и «офлайн» пишутся без дефиса, «интернет» в общем употреблении со строчной буквы.

UX-текст: жанр, в котором буквальность вредит

Микрокопия интерфейса — кнопки, подсказки, пустые состояния, сообщения об ошибках, онбординг — требует другого подхода, чем документация.

Здесь работает не точность воспроизведения, а функция. Английское Get started дословно не переводится; нужно то, что выполняет ту же роль по-русски в том же объёме символов.

Несколько практических принципов:

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

Юридические тексты в ИТ: ловушка несоответствия систем

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

Это тот случай, когда механическая подстановка «привычного» соответствия меняет юридическое содержание. Правильный подход — уточнить с клиентом, в какой системе должен жить документ, и при необходимости сохранить оригинальные термины с пояснением.

Форматы данных, которые легко сломать

• дата: формат ДД.ММ.ГГГГ против американского ММ/ДД/ГГГГ — 03.04.2026 читается по-разному;
• время: 24-часовой формат;
• десятичный разделитель — запятая; разделитель разрядов — неразрывный пробел;
• валюта: позиция символа, сокращение, конвертация;
• единицы измерения и размеры файлов;
• сортировка по алфавиту: кириллический порядок отличается от латинского;
• часовые пояса и переход на летнее время;
• кодировка: всё должно быть в UTF-8, и появление «кракозябр» — признак проблемы в конвейере, а не в переводе.

Инновации: патенты, гранты, инвестиционные материалы

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

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

Материалы для инвесторов — презентации, меморандумы, документы due diligence — требуют сочетания технической точности с бизнес-регистром, а часто и краткости, которой в оригинале нет.

Типичные ошибки в локализации

• переведённые или повреждённые плейсхолдеры и ключи строк;
• «файл(ов)» и другие обходные пути вместо корректной плюрализации;
• перевод строки в неверном значении из-за отсутствия контекста;
• текст, который не помещается в элемент интерфейса;
• расхождение с терминологией операционной системы;
• несколько вариантов одного термина в пределах продукта;
• дословный перевод микрокопии, который звучит неестественно;
• американский формат даты в русскоязычном интерфейсе;
• игнорирование альтернативных описаний и меток доступности;
• подстановка терминов GDPR в документ, который работает по украинскому праву.

Как мы работаем с ИТ-проектами

В «Профпереклад» локализационные проекты ведут лингвисты с ИТ-специализацией, с обязательным редактированием, корректурой и автоматизированной проверкой. Специфика отрасли добавляет к стандартному циклу:

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

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

«Профпереклад» — компания № 1 на рынке переводческих услуг Украины по рейтингу CSA Research, сертифицированная по стандарту ISO 17100:2015. Более 18 лет работаем с локализацией программных продуктов, технической документацией и материалами инновационных проектов.