7 ошибок в l10n-пайплайне, из-за которых ломается качество и сроки

7 ошибок в l10n-пайплайне, из-за которых ломается качество и сроки

Локализация падает не на переводе, а на стыках: исходники, TM, глоссарий, QA, релизный цикл. Если один из слоёв живёт отдельно, команда начинает чинить симптомы, а не процесс.

— Нет единого source of truth для строк: разработка меняет ключи, а локализация продолжает работать по старым файлам.
— Глоссарий существует, но не встроен в CAT-tool и QA, поэтому термины расходятся между командами.
— Translation memory копится без очистки: в ней остаются устаревшие сегменты, и они возвращаются в новые релизы.
— Машинный перевод включён без правил постредактуры: одинаковые тексты в продукте получают разный тон и стиль.

Ещё одна типовая проблема — ручные передачи между Jira, Git и платформой локализации. Чем больше «сдвигов руками», тем выше шанс потерять контекст: скриншоты, plural rules, плейсхолдеры, ограничения по длине. В такой схеме QA превращается в пожарную проверку, а не в контроль качества.

Лучше строить пайплайн так, чтобы проверка шла до релиза: валидировать ключи в CI/CD, синхронизировать TB и TM, а для MT задавать отдельные правила по домену и тону. Тогда локализация перестаёт быть отдельной очередью задач и становится частью инженерного контура.