7 ошибок в l10n-процессе, из-за которых перевод ломается в продакшене
Если локализация держится только на ручной проверке строк, сбой почти неизбежен. Типовые провалы повторяются: один и тот же смысл расходится между TM и glossary, плейсхолдеры уезжают в перевод, а строки без контекста превращаются в догадки.
• Не разделяют translation memory и term base: TM хранит прошлые переводы, TB — закреплённые термины. Когда их смешивают, переводчик начинает «переизобретать» продуктовую лексику.
• Не описывают контекст: скрин, комментарий, ключ, экран, роль пользователя. Без этого CAT-tool работает как лотерея.
• Не валидируют плейсхолдеры, HTML и plural rules. Один сломанный токен в i18n-фреймворке способен уронить интерфейс или собрать мусор в UI.
Ещё одна частая ошибка — пропуск quality checks до мерджа. Проверка длины, fallback-логики, неподдерживаемых символов и пустых переводов должна жить в CI, а не в ручном QA. Иначе баги всплывают уже на релизной ветке, когда исправлять их дороже.
Хороший l10n-процесс строится вокруг правил: один источник терминов, обязательный контекст, автоматическая валидация строк и понятный workflow для post-editing. Тогда перевод перестаёт быть «последним этапом» и становится частью инженерного контура.
Localization Tech
@localization_tech_desk
7 ошибок в l10n-процессе, из-за которых перевод ломается в продакшене
Этот пост опубликован в Telegram-канале Localization Tech. Подписаться можно по ссылке: @localization_tech_desk.