Клиенту пришло письмо на другом языке: выбор локали

Если транзакционное письмо пришло на другом языке, проверьте, чья локаль выбрана и как она попала в фоновое задание. Язык адресата, текущей страницы и сотрудника, запустившего действие, может различаться. Задайте явный порядок выбора, сохраните нужный контекст и формируйте тему, тело и связанные элементы согласованно, включая повторную отправку.

Менеджер оформляет действие, клиент читает письмо

Учебный сценарий: менеджер работает в русском интерфейсе, а клиент выбрал испанский. Менеджер подтверждает заказ, приложение ставит уведомление в очередь. Если язык письма берётся из текущего запроса менеджера, клиент получит русский текст. Если обработчик полагается на собственную настройку по умолчанию, результат может оказаться ещё другим.

Определяйте адресата каждого уведомления отдельно. Письмо клиенту и внутреннее сообщение сотруднику по одному событию могут требовать разных языков. У них не должно быть общего неявного состояния «локаль этого заказа», если продукт обещает учитывать предпочтение конкретного получателя. Для общего адреса организации нужна собственная согласованная политика.

Карта выбора языка по событию

Таблица предлагает модель для учебного сервиса. Названия языков и порядок приоритетов здесь выбраны для примера, а не объявлены универсальным правилом законодательства или всех почтовых платформ.

Фоновому обработчику нужен явный контекст

Не предполагайте, что очередь автоматически знает язык HTTP-страницы. Сохраните решение в подходящем для вашей архитектуры виде: готовое сообщение либо данные, достаточные для его воспроизводимого построения. При передаче только ссылки на пользователя определите, читается ли его актуальное предпочтение в момент отправки или применяется снимок на момент события.

В документации Laravel 12 описана локаль mailable, которая сохраняется и для отправки через очередь. Также предусмотрено предпочтение локали модели получателя. Это конкретные средства фреймворка. Они не выбирают за продукт владельца языка и не исправляют очередь, если в неё изначально передали чужое предпочтение.

Если один обработчик последовательно формирует разные письма, проверьте отсутствие утечки контекста между ними. Русское уведомление сотруднику не должно определять язык следующего испанского письма клиенту. В выбранном стеке должны быть понятны момент установки локали и восстановление состояния после обработки, в том числе после ошибки.

Тема не должна жить отдельно от тела

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

В Symfony Mailer показана возможность задать локаль для TemplatedEmail. Это не основание считать, что произвольная строка темы, подготовленная заранее, автоматически переведётся вместе с шаблоном. В реализации нужно явно проследить каждый этап перевода и форматирования, особенно при фоновой обработке.

Локаль и часовой пояс тоже не равны. Клиент может читать на одном языке, находясь в другой зоне. Для уведомления со временем действия согласуйте, какая дата показывается и как её понять. Не выводите необходимый язык только из IP или страны: эти признаки не заменяют явное предпочтение адресата.

Fallback должен быть решением, а не случайным остатком

В документации Symfony Translation описан поиск резервных переводов и настройка fallback. Если перевод одного ключа отсутствует, система может взять его из другого ресурса. Для пользовательского письма технически допустимый результат иногда даёт смесь языков, поэтому проверять следует не только наличие отдельных ключей.

Выберите, что делать с неполным комплектом: использовать целиком проверенный резервный язык, отложить уведомление для допустимого случая или применить иной согласованный путь. Для срочного служебного сообщения условия должны быть особенно ясными. Не заменяйте важную инструкцию пустым местом и не показывайте пользователю внутренний идентификатор перевода как готовый текст.

Проверяйте комплект до выпуска шаблона: тема, тело, обязательные ссылки и нужные переменные. Сохраните версию перевода, если она влияет на воспроизведение события. Если язык интерфейса уже добавлен, это ещё не подтверждает готовность всех почтовых сценариев. Перечень уведомлений должен быть частью разработки SaaS.

Что делать при смене языка и повторной отправке

Различайте повтор доставки прежнего сообщения и новое действие пользователя «отправить ещё раз». В первом случае полезна воспроизводимость первоначального выбора; во втором продукт может намеренно применить актуальное предпочтение. Выберите правила явно. Иначе одно событие после нескольких попыток будет иметь разные версии текста без понятной причины.

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

Приёмка без настоящей рассылки

1. Составьте список событий и получателей. Для каждого определите источник локали и порядок резервного выбора.
2. Подготовьте учебные профили с разными языками клиента, менеджера и организации. Постройте сообщения через тот же путь, включая очередь, который предусмотрен в реализации.
3. Проверьте тему, тело, текстовую альтернативу, даты и ссылки в сохранённом тестовом результате. Не ограничивайтесь одним письмом регистрации.
4. Поставьте подряд задания разных локалей, в том числе с ошибкой между ними. Следующее сообщение должно получить собственный контекст.
5. Удалите один перевод в тестовом комплекте и проверьте выбранное правило fallback без смешения обязательных фрагментов.
6. Смените предпочтение после постановки в очередь и выполните оба вида повтора. Результат должен соответствовать заранее принятому правилу.

Выбор языка — часть логики веб-приложения, а получение письма и его транспорт можно отдельно проверять в рамках поддержки почты. Для исправления передайте разработчику событие, учебные настройки получателя и ожидаемую локаль, не пересылая действующие секретные ссылки. Так проблему можно воспроизвести без реальной массовой отправки.