Локализация ломает сроки выпуска: где теряются строки
«Сохранить» вписано прямо в разметку экрана, ключа у строки нет и в словаре она не значится. Через месяц формулировку меняют, правка уходит в код, а перевод остаётся от старой версии — при добавлении языка эту строку просто не находят. Потеря тихая: интерфейс уже на тестировании, а часть экранов на новом языке остаётся прежней.
Дальше расходятся ключи. Один и тот же смысл живёт под тремя именами, переводчики получают их как разные строки и переводят по-разному — для одной кнопки в интерфейсе появляются «Удалить», «Стереть» и «Убрать». Локализация интерфейсов превращается в ручную сверку: никто не знает, сколько строк реально в продукте и какие из них уже не используются.
Выпуск версии начинает зависеть от внешнего цикла перевода. Строки отправляют после заморозки кода, возвращают частями, и правки не успевают к дате. Потеря строк при выпуске становится нормой: что-то уезжает непереведённым, что-то переведено под старую версию текста и расходится с логикой экрана.
Сроки выхода нового языка считаются тогда не днями работы переводчика, а неделями согласований и поиска зашитых мест. Мы начинаем с i18n-аудита: инвентаризируем строки, вытаскиваем жёстко зашитый текст, сводим дубли ключей и настраиваем сборку так, чтобы пропущенный перевод останавливал выпуск, а не всплывал в проде. После выноса текста в ресурсы новый язык — это набор словарей и проверок, а не правки в коде. Разбираем, как это закрывается.
Что даёт контролируемый контур перевода: эффект в метриках
Контур перевода измеряется не числом языков в переключателе, а временем до релиза локализованной версии и долей строк, прошедших без ручной правки. Ниже — что меняется в метриках, когда строки, память переводов и проверки работают в одном процессе.
Время выпуска версии на новом языке
Строки уходят на перевод при слиянии ветки: выгрузка, сопоставление с памятью переводов и возврат готовых сегментов идут без ручной сборки файлов. Новый язык заводится без отдельного цикла выпуска — версия выходит за дни вместо недель, а релиз на уже заведённом языке идёт вместе с основной сборкой.
Доля автоматического перевода
Память переводов накапливает подтверждённые сегменты, поэтому от релиза к релизу растёт доля строк, закрытых без переводчика: точные совпадения — полностью, близкие — с правкой пары слов. На зрелом проекте автоматически закрывается 80–90% объёма, вручную остаются новые разделы и юридические тексты.
Классы дефектов локализации
Ошибки локализации чаще структурные, чем смысловые: обрезанный интерфейс, склейка строк, неверные формы множественного числа и дат, непереведённые заглушки. Правила склонений и форматы берём из стандарта Unicode CLDR, обрезание ловит автотест на самой длинной строке языка, заглушки блокируются на сборке.
Объём ручных правок
Доля сегментов, которые редактор правит после автоперевода, падает с трети до единиц процентов: спорные места собираются в очередь вычитки по порогу уверенности, а не размазываются по всему тексту. Глоссарий фиксирует термины, и одни и те же правки не возвращаются из релиза в релиз.
Режимы локализации: ручной, автоматический, гибридный
Режим локализации — следствие трёх параметров: объёма текста, частоты правок и цены ошибки в терминологии. Если строки меняются каждый релиз, а языков несколько, ручной проход по всему корпусу не окупается — переводится только дельта.
| Вариант | Когда подходит | Ограничения |
|---|---|---|
| Ручной | Регуляторные и юридические тексты, маркетинг, где важен тон | Плохо масштабируется при частых релизах |
| Автоматический с пост-редактурой | Большие объёмы однотипных строк интерфейса, справочные материалы | Без глоссария теряет единообразие, нужна вычитка носителем |
| Гибридный | Продуктовый интерфейс, документация, частые многоязычные релизы | Требует настроенной памяти переводов и контроля качества |
Как это выглядит в проекте
Гибридный режим строится вокруг памяти переводов: совпавшие строки подставляются автоматически, новые уходят в автоматический перевод с редактурой. Глоссарий терминов фиксирует продуктовые названия и запрещённые варианты, поэтому «личный кабинет» не превращается в три разных термина на трёх экранах.
Перед этим мы делаем i18n-аудит: ищем строки, склеенные из фрагментов, жёстко зашитый порядок слов, места, где длина перевода ломает вёрстку. Правка на уровне кода занимает минуты, правка после выпуска — недели вычитки по всем языкам.
Пост-редактура перевода делится на лёгкую и полную: служебным подписям достаточно проверки терминов и подстановок, пользовательские сценарии читают как готовый текст. Метрика одна — доля строк, вернувшихся из автоматического перевода с правками; по мере наполнения памяти переводов она падает.
Этапы внедрения: от i18n-аудита до приёмки выпуска
Локализация ломается не на переводе, а раньше — на строках, зашитых прямо в код, склейках вида «файл + число + окончание» и разметке внутри шаблонов. Пока не видно, сколько текста живёт в интерфейсе, письмах, мобильных уведомлениях и подсказках, любая автоматизация множит хаос. Ниже — маршрут работ, после которого перевод становится регулярным шагом сборки, а не ручной гонкой перед выпуском.
-
Инвентаризация строк. Собираем текстовые ресурсы из репозиториев, шаблонов, экранов, системных писем и уведомлений. Результат — реестр: источник, экран, состояние (переведено, устарело, дубль). Он же становится основой оценки объёма.
-
Схема ключей локализации. Проектируем пространства имён и правила именования: ключ привязан к экрану или сущности, а не к самому тексту и не к порядковому номеру. Тогда формулировку на исходном языке можно править без перевыпуска переводов.
-
Вынос строк из кода. Заменяем литералы на ключи, разбираем склейки на шаблоны с подстановкой — в другом языке порядок слов иначе не собрать. Отдельно размечаем множественные числа, падежи и роды.
-
Настройка контура. Подключаем хранилище переводов, автоматическую выгрузку при сборке и контроль, что в выпуск не уходит ни один ключ без перевода. Резервный язык задаётся явно, а не остаётся на усмотрение настроек по умолчанию.
-
Тестовый язык и проверка на псевдо-локали. Прогоняем интерфейс на тестовом языке с псевдо-локализацией: искусственно удлиняем строки, добавляем диакритику. Так до носителя ловятся переполнения кнопок, обрезанный текст и жёстко заданная ширина блоков.
-
Приёмка выпуска и передача команде. Фиксируем чек-лист: полнота ключей, отсутствие непереведённого, корректность форматов даты, числа и валюты, работа поиска по локализованному контенту. Отдаём схемы, скрипты проверки и регламент обновления — поддержка остаётся у вашей команды.
Артефакты локализации: что остаётся у вашей команды
Перевод без сопутствующих документов живёт до следующего релиза: строки правят прямо в файлах, термины расходятся, приёмка превращается в спор о вкусах. Поэтому контур локализации мы сдаём комплектом, который остаётся в вашем репозитории и не зависит от нас.
- Карта строк — таблица «ключ → файл → экран или сценарий → статус → ответственный»: сразу видно, что ещё не локализовано и кто закрывает пробел.
- Глоссарий — термины с частью речи, регистром и запрещёнными синонимами, подключённый к памяти переводов: спорный термин решается один раз, а не в каждом релизе.
- Политика ключей — правила именования, запрет на склейку фразы из фрагментов, требования к подстановкам и согласованию числа.
- Настройки контура — извлечение строк из кода, подключение каталогов перевода, автоматические проверки на этапе сборки.
- Регламент приёмки перевода — что считается блокирующим дефектом, кто принимает и по какому чек-листу возвращает на доработку.
- Отчёт аудита — срез до и после: доля непереведённых строк, дубли и «мёртвые» ключи, строки, зашитые в код, потерянные подстановки.
Каждый артефакт встроен в сборку, а не лежит отдельным документом: непереведённая строка или расхождение с глоссарием тормозят выпуск до релиза. Через один цикл ваша команда ведёт контур локализации сама.
Кейс: как сократили ручные правки и ускорили выпуск версий
Продукт выходил на четырёх языках, а строки для перевода собирали вручную: разработчики выгружали таблицы, переводчики возвращали их обратно, ключи к тому моменту уже расходились. На каждой итерации 28-30% строк приходилось править руками — часть теряла подстановки, часть не влезала в кнопку, часть так и оставалась на исходном языке.
Сначала навели порядок в самом каталоге: единый ключ, контекст экрана, предел длины подписи и комментарий для переводчика. Затем сбор строк стал частью сборки продукта — новые и изменённые фрагменты попадают в очередь перевода сами, а проверки до выгрузки отсекают склейки, потерянные подстановки и незакрытые формы множественного числа.
Через три цикла автоматически закрывалось 96% строк, доля ручных правок упала с 30% до 4%, выпуск нового языка сократился с 6-8 недель до пяти рабочих дней, а дефектов интерфейса на версию стало единицы вместо сорока с лишним. Приёмка перестала быть ручным перебором экранов: спорные места приходят списком с указанием ключа и экрана.
Картина совпадает с отраслевой: по данным CSA Research, основной прирост в скорости выпуска языков даёт автоматизация повторяющихся операций с текстом, тогда как качество держится на глоссарии, контексте и проверках, встроенных в конвейер до публикации.
Чем i18n-аудит отличается от разовой локализации интерфейса?
Разовая вычитка правит текст в уже выпущенном продукте: заказчик видит исправленные экраны, но источник расхождений остаётся. Через релиз-два появляются новые строки, снова всплывают склейки шаблонов, неверный порядок слов в вопросах и падежи в подстановках — это и есть локализационный долг.
i18n-аудит идёт от кода, а не от текста: находит зашитые в разметку фразы, проверяет плейсхолдеры и их порядок, множественные числа, форматы дат и чисел, запас длины подписи в кнопке, направление письма справа налево. То, что при вычитке выглядит как опечатка переводчика, часто оказывается дефектом структуры строки.
| Подход | Когда подходит | Что остаётся за рамками |
|---|---|---|
| Разовая вычитка | Один язык, нужно быстро снять видимые расхождения | Правила не меняются: следующая партия строк приносит те же ошибки |
| i18n-аудит и постоянный контур | Продукт развивается, языков несколько, релизы регулярные | Нужны доступ к репозиторию и согласованный глоссарий |
Постоянный контур — это проверки на сборке, ключи с контекстом для переводчика, глоссарий и память переводов. Новая строка проходит их до релиза, поэтому долг не накапливается, а перевод интерфейса перестаёт быть отдельным проектом на каждую волну правок.
Уже выпущенный продукт переводят на такой контур без остановки релизов: сначала правила и проверки, затем постраничный разбор спорных мест.
Частые вопросы про автоматизацию перевода и i18n-аудит
Заказчики проверяют не саму автоматизацию, а её края: не поедет ли смысл, кто отвечает за терминологию, что делать с уже выпущенным продуктом. Ниже — ответы на сомнения, которые всплывают чаще всего.
Машинный перевод выдаёт «почти правильно» — как понять, что результат пригоден?
Оцениваем не «красоту», а долю строк, которые проходят без правки. Модель получает глоссарий продукта, память переводов и контекст экрана — термины и обращения не пересобираются заново в каждом релизе. Остаток правит редактор-носитель языка, но это единицы процентов строк, а не весь объём.
Кто отвечает за единую терминологию в интерфейсе, письмах и справке?
Терминология живёт в глоссарии: на каждое понятие — один перевод, часть речи, запрет синонимов. Глоссарий подключается и к переводу, и к проверке: недопустимый вариант останавливает сборку локализации до релиза. Разночтения между экранами и документацией не накапливаются.
Переведённые строки ломают вёрстку — как это ловится заранее?
Подпись на другом языке растёт, и кнопка или колонка разъезжается. До перевода прогоняем псевдолокализацию — интерфейс на удлинённых строках, чтобы узкие места нашлись на тестовом стенде, а не у пользователя. Отдельные правила — на подстановки, склонения и форматы чисел и дат.
Продукт уже выпущен. Придётся ли переписывать код?
Строки вынимаются из кода и шаблонов, спорные места закрываются обёрткой, дальше перевод идёт тем же контуром, что и в новых разделах. Обратный путь тоже есть: правку вносят в источник, и контур пересобирает только затронутые файлы, не трогая остальные.
С чего начать: что подготовить до запуска контура перевода
Старт контура перевода — это не подключение сервиса, а инвентаризация. Пока не описаны источники строк, правила сегментации и владельцы глоссария, автоматический проход даёт разнобой в терминах и ломает переменные внутри строк интерфейса.
- Карта строк: какие поверхности переводятся (веб, мобильные сборки, письма, справка), какие остаются на языке оригинала, кто владелец каждой.
- Аудит готовности к локализации: склейка строк конкатенацией, зашитые в код форматы дат, чисел и падежей, множественные формы — всё, что мешает машинному проходу.
- Глоссарий и правила терминологии: устойчивые термины с запретом синонимов, отдельно — названия продукта и юридические формулировки, которые не переводятся.
- Память переводов и схема сегментации: повторяющиеся блоки не переводятся заново, доля совпадений растёт с каждым релизом.
- Пилотный язык: один рынок с наибольшей нагрузкой, на котором контур проверяется целиком до масштабирования.
- Критерии приёмки: доля непереведённых строк, число сломанных переменных на релиз, время вычитки, воспроизводимость отката к предыдущей версии.
- Роли и доступы: кто согласует терминологию, кто принимает релиз, кому уходит уведомление о расхождении.
После пилота контур тиражируется на остальные языки без пересборки процесса: меняется только набор глоссариев и правила для конкретного рынка.
Опишите задачу — объём строк, текущие форматы, целевые рынки и ограничения по срокам — и мы вернёмся с оценкой и планом работ, включая порядок пилота и чек-лист приёмки.
