7 ошибок в l10n-процессе, которые ломают выпуск раньше, чем текст

7 ошибок в l10n-процессе, которые ломают выпуск раньше, чем текст

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

— Нет единого source of truth: строки лежат в репозитории, в таблице и в таск-трекере одновременно.
— Не зафиксированы плейсхолдеры, теги и ICU-сообщения.
— TM и glossary существуют, но не встроены в проверку качества.
— Нет правил для fallback-стратегии и empty states.
— Релиз ждёт перевод, а перевод ждёт релиз: цикл замирает.

Самый дорогой провал — отсутствие контекста. Скриншот, описание сценария, длина строки, тон интерфейса и ограничение по символам дают переводчику больше, чем длинный комментарий без привязки к UI. Для продукта это ещё и способ уменьшить post-editing effort в MT-пайплайне.

Хороший l10n-процесс обычно строится вокруг трёх вещей: проверка ключей на этапе CI, терминологический контроль через term base и QA-правила для чисел, дат, ссылок и переменных. Если этого нет, локализация становится ручной операцией, а не частью инженерного контура.

Начинайте не с «перевода интерфейса», а с инвентаризации строк и правил их проверки: это быстрее всего показывает, где процесс течёт.