Lokalise в продакшене: 6 мест, где локализация ломается не в переводе, а в процессе

Lokalise в продакшене: 6 мест, где локализация ломается не в переводе, а в процессе

Если в проекте уже есть Lokalise, главная ошибка — считать его просто «панелью для строк». На практике качество зависит от связки: i18n в коде, ключи, ветки, правила нейминга, TM и glossary.

Проверяйте сразу:
— ключи должны быть стабильными и без смысла «на глаз»;
— в Figma/репозитории нужен один источник истины для строк;
— plural rules и placeholders надо валидировать до передачи в перевод;
— glossary и translation memory должны обновляться вместе, иначе команды начинают спорить с системой.

Отдельно смотрите на workflow: кто создаёт задачу, кто ревьюит, где живёт статус и как возвращается контент в продукт. Если это не описано, локализация превращается в цепочку ручных пингов и экспортов. Для SaaS это почти всегда дороже самого перевода.

Ещё один частый провал — импорт без контроля контекста. Скриншоты, описания экрана, комментарии к ключам и сегментам экономят больше времени, чем попытка «додумать» смысл по строке. Машинный перевод тут не спасает, если у термина нет базы.

Хорошая настройка Lokalise — это не про интерфейс, а про дисциплину ключей, терминов и возврата в код.