7 ошибок в локализации продукта, которые ломают процесс до выхода в продакшен

7 ошибок в локализации продукта, которые ломают процесс до выхода в продакшен

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

— Без контекста переводчик получает «Save», «Enable», «Plan» и делает догадки. Нужны скриншоты, ключи, описание UI-сценария.
— Если термины живут в текстах, глоссарии и голове продакта одновременно, TM начинает тащить мусор.
— Когда строки правят в продукте, а не через l10n-пайплайн, ломаются повторное использование, QA и инкрементальные обновления.

Ещё одна типовая проблема — смешивать translation memory и term base. TM хранит готовые переводы фрагментов, TB задаёт обязательные термины. Если их не разделять, в интерфейсе появляются «почти одинаковые» названия для одной сущности.

Проверьте базовый контур: i18n-ключи не должны зависеть от английской грамматики, placeholder’ы — быть стабильными, а формат даты, числа и валюты — приходить из локали, а не из шаблона. Тогда CAT-tool и QA ловят ошибки раньше, чем их увидит пользователь.

Вывод простой: локализация — это не этап после разработки, а часть архитектуры продукта. Чем раньше вы зафиксируете ключи, термины и workflow, тем меньше будет ручного постредактирования и спорных правок.