Lokalise в продакшене: как не сломать string flow между кодом, PM и переводчиками

Lokalise в продакшене: как не сломать string flow между кодом, PM и переводчиками

Если у вас локализация живёт в одном кабинете, а разработка — в другом, Lokalise быстро превращается в узел интеграций. Сильная сторона платформы не в «переведите текст», а в том, как она держит поток: ключи, контекст, TM, glossary и экспорт в CI/CD.

Главные места, где команды ошибаются:
— не задают правила нейминга ключей, и потом ломают diff-review;
— не подключают скриншоты и комментарии, из-за чего растёт число вопросов к PM;
— смешивают термины из glossary и TM, хотя это разные слои качества.

Для SaaS-команды полезно заранее разделить зоны ответственности: продуктовые строки идут через один workflow, маркетинговые — через другой, а release notes лучше не смешивать с интерфейсом. Так уменьшается шум в задачах и проще настроить автоматические проверки на missing keys, plural forms и fallback.

Если Lokalise у вас уже стоит, проверьте три вещи: экспорт должен быть воспроизводимым, термины — единообразными, а ручные правки не должны обходить TM. Иначе платформа останется просто хранилищем строк, а не l10n-операционной системой.