l10n-процессы ломаются не в переводе, а на стыке контента, кода и терминов

l10n-процессы ломаются не в переводе, а на стыке контента, кода и терминов

Если локализация у команды «не едет», обычно проблема не в CAT-tool, а в договорённостях:
— нет единого source of truth для строк;
— glossary живёт отдельно от translation memory (TM);
— разработка и лингвисты видят разные статусы задач.

Минимальный рабочий контур такой: контент попадает в систему через понятный экспорт, термины — в term base, повторы — в TM, а статус каждой строки синхронизируется с задачей в трекере. Тогда переводчик не гадает, а разработчик не ждёт ручной пересборки. Это особенно важно, когда в продукте есть i18n-фреймворк, плейсхолдеры и переменные.

Перед запуском любого потока проверьте три вещи:
— строки не режутся по смыслу;
— плейсхолдеры и ICU-сообщения валидируются;
— fallback-язык задан явно, а не «по умолчанию где-то в коде».

Если этого нет, даже сильная language QA превращается в пожарную команду. Лучшая l10n-архитектура — та, где ошибки ловятся до перевода, а не после публикации.