Lokalise в продакшене: какие ошибки в workflow ломают локализацию быстрее всего

Lokalise в продакшене: какие ошибки в workflow ломают локализацию быстрее всего

Lokalise хорошо работает там, где строки идут из кода, маркетинга и продукта в один контур. Но на практике команды чаще ломают не платформу, а процесс вокруг неё.

— Смешивают translation memory (TM) и term base (TB): TM должен подсказывать готовые переводы, TB — удерживать терминологию.
— Не фиксируют источник истины для строк: локализация начинает спорить с репозиторием, а не дополнять его.
— Отдают в перевод сырые ключи без контекста: скриншот, описание UI и ограничение по длине экономят больше времени, чем «поясним потом».
— Не задают правила для повторов и вариативных форм: один и тот же смысл расползается по продукту.

Для SaaS-команд критично заранее решить, где живут ресурсы: в Git, в CMS или в самой l10n-платформе. Если этого нет, любая интеграция с CLI, webhook или CI/CD начинает выглядеть как ручная сборка.

Практика простая: разделите ответственность, заведите глоссарий, проверьте контекстные поля и настройте проверку плейсхолдеров до выгрузки в релиз. Это дешевле, чем разбирать баги уже на интерфейсе.