Problem/Motivation
This issues discussion has now changed it's focus to determine the users expectation on what language should the content of recovery email is when multiple language is setup. (email requested from /user/password or /fr/user/password). Currently it uses the language of the viewing page (active langcode) where reset email is requested as seen from the example below, but not the user's preferred langcode.
Current behaviour
The reset link provided will direct user according to the language of viewing /user/password page.
Example:
User A with language preference English
visit /zh/user/password => receive a reset content and link to /zh/user/reset...... that is Chinese.
Expected behaviour
User's preference should be respected. Therefore, we should be expecting email shown in English even when the reset request is sent on Chinese page.
Example:
User A with language preference English
visit /zh/user/password => receive a reset content and link to /en/user/reset. Be it English.
Another related issue upon the language of user's email text content not aligning with content/link from token_replacement is addressed in #2991677: Wrong language in token_options in user_mail function.
Original Problem/Motivation
The "reset password" page that comes up after clicking on a one-time login link uses the default site language instead of the user's language.
To reproduce this, you need the localization module activated, more than one language installed, and a user that has changed the language in their profile.
Hans
Steps to reproduce
- New Drupal install
- Enable language (language), interface translation(locale)
- Add new language French, set path prefix for both languages (en, fr)
- Translate the recovery email content of French without replacing the original tokens.
- Set User Accounts language preference as English.
- Log out, or use Incognito mode to request a reset email from French interface "/fr/user/password"
- Receive Email reset link of French, but not English, while the email content itself is French.
(This is the original behaviour prior to fix of #2991677: Wrong language in token_options in user_mail function, if patch applies, then both content and link will follow current active langcode, not user preferred langcode.)
Proposed resolution
1. #60, fix the submitForm of UserPasswordForm.php.
If you take a close look at user_pass_reset_url it already works with a langcode to translate the link. So the "problem" belongs on the Drupal\user\Form\UserPasswordForm::submitForm which use the UI langcode instead of User Preferred Langcode.
2. #78, fix LanguageRequestSubscriber.php of language module.
By taking the request url into part of the argument and determine whether user object should be set or not when visiting /user/password url, further used for the decision of langcode.
Remaining tasks
1. Decide the behaviour of returning language of email should be.
2. Decide the method to fix.
3. Add tests.
User interface changes
1. Language of Recovery Email's content and link will be altered.