[2.x] fix: send transactional emails in recipient's preferred locale - #4627
Merged
Conversation
Switches translator to the recipient's locale preference (falling back to the forum default) before translating subject/body, and carries that locale through to SendInformationalEmailJob and SendAbandonedExtensionsEmailJob so the wrapper template's greeting/signoff render in the same language. For abandoned-extensions notifications, moves translation inside the per-admin loop so each admin receives the email in their own preferred locale rather than all admins receiving the same language. Mirrors the existing pattern in NotificationMailer. Refs #4626
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
User::getPreference('locale')), falling back to the forum'sdefault_locale.SendInformationalEmailJobandSendAbandonedExtensionsEmailJobso the wrapper template'sgreeting/signoffstrings render in the same language as subject/body — fixing the mixed-language output described in [2.x] Transactional emails are sent in mixed languages instead of the recipient's preferred locale #4626.NotificationMailer::send().Fixes #4626
Changes
Mail/Job/SendInformationalEmailJob— adds optional?string $locale(after$viewsto preserve positional BC); injectsTranslatorInterfaceintohandle()and applies locale before send.Mail/Job/SendAbandonedExtensionsEmailJob— same shape.Api/Controller/SendTestMailController— switches to actor's locale, translates, restores previous locale infinally.User/Job/RequestPasswordResetJob— same pattern, recipient = looked-up user.User/EmailConfirmationMailer— same pattern.User/AccountActivationMailerTrait— same pattern (already hadUser $userin scope).Extension/AbandonedExtensionsFetcher::notifyAdmins()— moves translation inside loop, switches to Flarum'sLocale\TranslatorInterface(Symfony's contract doesn't exposesetLocale()), wraps loop intry/finally.Test plan
de), admin user preference = English (en). Trigger Send test mail — full email renders in English.NotificationMailer) are unchanged.Notes
localeparameter on both jobs is optional and trailing, so existing third-party callers (positional or named) continue to work unchanged. Whennull, behavior is identical to today.