Многоязычный онбординг в SaaS — это не просто перевод текста на первом экране. Пользователь должен понимать каждый шаг, сохранять свои ответы и завершать регистрацию, даже если он сменит язык или вернётся позже. Для этого стоит отделить языковые предпочтения от бизнес-данных и рассматривать сценарий как процесс с проверяемыми состояниями.
Это руководство посвящено регистрации организации: что показать до создания учётной записи, что сохранять в процессе и что проверять, чтобы обнаружить ошибки. Оно не ставит целью определить общую стратегию интернационализации всего приложения.
Разделите язык интерфейса, контент и регистрационные данные
В форме могут одновременно встречаться три типа информации, однако хранить и переводить их следует по-разному:
- Язык интерфейса: определяет подписи, инструкции, сообщения валидации и системные сообщения. Это настройка взаимодействия с приложением, например
esилиfr. - Контент продукта: тексты, которыми управляет бизнес, например описание тарифа, категория или шаблон приветствия. Для них могут существовать собственные переводы, и решение о языке может приниматься отдельно.
- Данные, введённые пользователем: название организации, домен или описание. Их нужно сохранять в том виде, в котором их ввёл пользователь, не переводя при смене языка интерфейса.
В модели данных не используйте одно неоднозначное поле language для обозначения разных понятий. Настройку языка интерфейса можно назвать preferred_locale; если для управляемого контента указывается язык, его следует связать с этим контентом. Название организации, напротив, не должно меняться при смене языка интерфейса.
Такое разделение также проясняет, как работать с селекторами. Если пользователь выбирает отрасль из переведённых вариантов, сохраняйте стабильный идентификатор, а не видимую подпись. Тогда выбранный вариант можно будет показать на другом языке, не изменяя бизнес-данные и не полагаясь на то, что подпись останется неизменной.
Выберите язык до создания учётной записи
Регистрация часто начинается до аутентификации пользователя и сохранения его предпочтений в профиле. Поэтому системе нужно явно задать начальное правило. Можно показать селектор, предложить язык браузера или сочетать оба подхода. Автоматическое определение должно помогать пользователю, а не мешать ему выбрать другой вариант.
Определите приоритет сигналов, если их несколько. Например, явный выбор, сделанный во время регистрации, должен иметь приоритет над последующим автоматическим определением. Выбранный язык можно временно сохранить в сессии или в записи процесса регистрации; после создания учётной записи его можно скопировать в настройки пользователя. Если у организации есть отдельная настройка языка, не смешивайте её с личным предпочтением.
Также стоит решить, что происходит, если пользователь переходит по ссылке-приглашению, продолжает сессию на другом устройстве или возвращается после истечения срока действия. Задокументируйте правило приоритета и не допускайте, чтобы запрос без состояния стирал действительный выбор. Если процесс можно продолжить на другом устройстве, не храните предпочтение только в браузере: при необходимости свяжите его с сохранённым состоянием онбординга.
Спроектируйте состояния для смены языка и продолжения регистрации
Представляйте онбординг как последовательность состояний, а не как набор отдельных страниц. Запись может содержать текущий шаг, уже заполненные поля, выбранный язык и состояние процесса, например «ожидает», «завершён» или «истёк». Согласованное сохранение данных позволяет восстановить процесс, не создавая организацию при каждой повторной загрузке страницы.
В PHP-приложении проверяйте на сервере и состояние процесса, и каждое полученное значение. Интерфейс может управлять навигацией, но не должен быть единственным источником истины при определении завершённости шага. Используйте стабильные идентификаторы шагов и вариантов, а обновления обрабатывайте так, чтобы повторный запрос не создавал дубликаты ресурсов. Например, повторный запрос на создание организации должен распознавать существующий процесс, а не запускать ещё одну регистрацию.
При смене языка обновляйте подписи и сообщения, сохраняя корректные ответы. Если из-за реальных различий в правилах между рынками какой-либо ответ перестал быть допустимым, объясните причину и попросите пользователя исправить его; не удаляйте ответ без уведомления. Выбор языка также не должен менять идентификатор процесса или сбрасывать прогресс.
Обеспечьте согласованность подписей, проверок и ошибок
Перевод должен охватывать весь сценарий, а не только заголовки. Переведите подписи, пояснения, кнопки, состояния загрузки, подтверждения, сообщения валидации и ошибки, после которых можно продолжить работу. Если на экране смешаны языки, пользователь может неправильно понять, что нужно сделать, даже когда поля работают корректно.
Правила валидации должны быть согласованы на клиенте и сервере. Правило выражается общим условием — например, обязательное поле не должно быть пустым, — а интерфейс показывает сообщение на выбранном языке. Не составляйте сообщения из переведённых фрагментов: порядок слов и грамматика могут различаться. Вместо этого используйте полные сообщения, связанные со стабильными ключами ошибок.
Отделяйте внутренний код ошибки от текста, который видит пользователь. Например, приложение может вернуть ключ organization_name_required, а интерфейс — сопоставить его с подходящим сообщением. В технические журналы можно записывать код и идентификатор процесса, но не следует раскрывать лишние персональные данные или возвращать внутренние исключения в браузер.
При сбое сети или временной недоступности ответа сообщите, сохранились ли ответы, и предложите безопасно продолжить или повторить попытку. Сообщение должно быть понятным и не должно обещать сохранение данных, если сервер этого не подтвердил.
Тестируйте сценарии целиком, а не только переводы
Тесты должны охватывать последовательность действий и переходы между состояниями. Практический набор включает следующие случаи:
- Начать регистрацию на одном из доступных языков, заполнить несколько полей и убедиться, что подписи и сообщения отображаются на этом языке.
- Сменить язык в середине процесса и проверить, что ответы сохраняются, выбранные варианты отображаются в переводе и дублирующиеся ресурсы не создаются.
- Отправить форму с некорректными данными и проверить, что сообщения об ошибках понятны, переведены и связаны с нужными полями.
- Вызвать ошибку, после которой можно продолжить, повторить попытку и проверить, какие ответы сохранились и не выполнился ли переход процесса больше одного раза.
- Выйти из регистрации и продолжить её позже, в том числе после истечения срока действия или из новой сессии, чтобы проверить правило сохранения языковых предпочтений.
- Проверить введённые пользователем значения и выбранные идентификаторы до и после смены языка.
Автоматизируйте проверку важных инвариантов: смена языка не должна менять название организации; возобновление процесса не должно создавать дубликат учётной записи; ошибка валидации не должна удалять корректно заполненные поля. Добавьте UI-тесты, чтобы убедиться, что все тексты отображаются и на экране не остаются ключи переводов. Ручное тестирование также полезно для выявления непонятных сообщений и инструкций, которые больше не помещаются в макет.
Контрольный список перед включением ещё одного языка
- Понятно ли, какое поле задаёт язык интерфейса и кто может его менять?
- Сохраняется ли выбор до создания учётной записи и при возобновлении процесса?
- Остаются ли введённые данные и идентификаторы вариантов неизменными при смене языка?
- Переведены ли все подписи, пояснения, сообщения валидации, подтверждения и ошибки во всём сценарии?
- Безопасны ли повторные попытки и запросы, не приводят ли они к дублированию регистрации?
- Проверяют ли тесты начало процесса, смену языка, возобновление и ошибку, после которой можно продолжить?
Надёжная многоязычная регистрация строится на чётком распределении ответственности за каждый тип данных и проверке того, что состояние сохраняется при обычных действиях пользователя. Перед включением нового языка пройдите весь сценарий — от первого выбора до подтверждения: каждый экран должен помогать пользователю, не переосмысливая введённые им данные и не сбрасывая прогресс.
