Lokalise в продакшене: 7 вещей, которые ломают локализацию чаще всего

Lokalise в продакшене: 7 вещей, которые ломают локализацию чаще всего

Lokalise удобно выглядит на уровне UI, но в реальном процессе чаще всего спотыкаются не о кнопки, а о структуру проекта. Если не разделить ресурсы по продуктам, платформам и языковым ролям, translation memory быстро смешивает контексты, а термины начинают «переезжать» между командами.

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

Вторая типовая ошибка — рассчитывать, что интеграция с CI/CD сама решит процесс. Без правил для веток, статусов строк и правок через pull request локализация превращается в ручной обмен файлами. Это особенно болезненно, когда продукт живёт на нескольких платформах и релизы идут не синхронно.

Если у вас есть machine translation, не пускайте её сразу в финальный контур. Сначала задайте: где MT разрешён, какие поля требуют post-editing, кто валидирует термины и как откатывается неудачная партия. Иначе автоматизация ускорит не выпуск, а накопление шумов.

Держите Lokalise как оркестратор контента, а не как склад строк: разделяйте домены, фиксируйте правила ключей и не смешивайте TM с glossary.