Password reset process ignores the user's language preference

any news about this?

Bumping.

Patch attached to go a long way towards fixing this.

The problem is that the user is always anonymous when visiting the page, so the site's default language is always used.

In short, I use the code in the block below to get the user id from the URL, then get that user's preferred language, then pass the language to all calls to t(). This causes all the text to be translated to the user's preferred language.

//fetch uid from the URL, and use it to load the preferred language for the user trying to recover their password.
$uid = arg(2);
$user_language = user_preferred_language(user_load($uid));
$user_language = $user_language->language;

The only thing that doesn't translate is the title, because you can't pass t('Reset Password') as an argument to drupal_set_title(). The only way I can see to get around that is to write a new function for Locale which, when given a string, returns it's translation in the provided language. Then pass this function the string 'Reset Password', and pass the translation to drupal_set_title().

However, that will need to be part of another patch.

Attaching a screenshot to show the output. User requesting his password has 'Dutch' chosen as his profile language. Notice the title remains in English.

Just tagging so this can be found in the 'Usability' queue.

I've decided to just include drupal_set_title(t('Reset Password', array(), $user_language)), and leave it up to the translators to add a translation for it.

Also, this new patch integrates the small change made in #455630: Remove HTML tags from t() call in user.pages.inc, so if this patch is included, that one can be closed.

Oops - including patch!

+  //fetch uid from the URL, and use it to load the preferred language for the user trying to recover their password.

This should start with a capital letter and needs a leading space.

Should we just set global $language instead of all the t() changes?

Heh - we don't need that kind of thinking here. :p

I will reroll it with that suggested change. It will make future changes simpler, since people can just use t() without worrying about sending the language parameter.

Rerolled with suggested changes.

Final revision!

Famous last words. Final patch attached, this time without the added space.

Rerolled for current head.

The last patch is throwing errors on usage of the 3rd parameter to the t() function.
The 3rd parameter $user_language should become array('lang_code' => $user_language->language)

Attached is another approach to fix this solution, which doesn't require to add the 3rd parameter to each call of the t() function, but rather changes the full language interface to the preferred language of the user requesting a password reset.
I'm not sure whether that might introduce other problems, but on my testsite it seems to apply fine.

+++ modules/user/user.pages.inc	2 Nov 2009 14:46:52 -0000
@@ -77,6 +77,12 @@
   global $user;

Does the global $user item work here? Wouldn't the user be visiting the password reset page as anonymous?

If you can confirm that the global $user object is properly populated, then I would say this should be RTBC.

The global $user object is used at that point to verify if a user arriving on the password reset page isn't logged in.
So if the $user object is indeed properly populated at that point, an error message is displayed. See comment at line 87 in user.pages.inc.
If the user is anonymous, the $user object will be the default $user object for anonymous users, with $user->uid being 0.

Doh, I misread the patch. For some reason, I thought you were getting the preferred language for the global $user, instead of the one loaded from the URL.

At any rate, I think this is good to go in.

I think it makes sense to have test coverage for this.

Can we also expand out the code comment to explain that the reason we're special-casing this page is because the user comes in as anonymous? Also, wrap at 80 chars please. :)

I updated the patch as per webchick's comments.
It's my first core testcase, so feedback is appreciated.

#21: 86287-translate-reset-password-page-global-2.patch queued for re-testing.

At some point after the original patch was rolled it seems like the global $language_interface was changed to just $language.

New patch attached.

Patch in #25 works great. Manual tests and simpletest both work well.

Updating to RTBC

Thanks for getting involved with Drupal core development at the core sprint here at DrupalCon. This is a good start but needs some further work. We'll help/guide you along the way.

+++ modules/user/user.pages.inc	2010-04-22 12:25:28.529949248 -0700
@@ -89,6 +89,14 @@ function user_pass_submit($form, &$form_
+  // Set the interface to the user's preferred language
+  // Since a user comes in anonymous on this page, we fetch the uid from the URL
+  // and retrieve their language settings based on that.
+  $uid = arg(2);
+  $user_language = user_preferred_language(user_load($uid));
+  $language = $user_language;

This code could actually be moved down into the else-case. We already load the $user object further down in the function so we should avoid loading it twice.

+++ modules/user/user.test	2010-04-22 12:21:18.535984887 -0700
@@ -1585,3 +1585,86 @@ class UserTokenReplaceTestCase extends D
+    // now add a translated string to the locale system

To comply with the guidelines, code comments should start with a capital letter, and end with a point. Various comments in this patch need to be updated.

Cleaned up the comments in the patch; moved the global language assignment into the if/else.

Some formatting issues; comments given directly to patch author @krlucas.

removed spaces preceding line break.

p.s. not the patch author just the patch fixer ;)

gah. missed one.

That does it. Did manual testing and the automated .test works dandily. RTBC, thanks for playing.

Thanks krlucas for giving this some love :)

#33: 86287-translate-reset-password-page-global-4.patch queued for re-testing.

I guess this needs only a slight update to reflect some changes made to HEAD to get back to RTBC. Please, somebody with the skills to do so fix this patch so that this nasty issue is not included in D7. That would be terrible.

Good karma awaits the person who finishes this!

Re-rolled patch against latest Drupal cvs head...

dddave perhaps you can test it (for some karma)?

I am going to set up my first D7 test install tonight. I'll give it a test right after D7 is up and running.

I am currently strunggling to get my mail server going to test this out. I am not the brightest bulp in in this regard so this might take a while...

Moved this to 8.x. Re-rolled #39.

Re-rolled patch from #42 after #22336: Move all core Drupal files under a /core folder to improve usability and upgrades.

Re-roll patch from #43.

#45: translate-reset-password-with-test-86287-45.patch queued for re-testing.

#45: translate-reset-password-test-only-86287-45.patch queued for re-testing.

...perhaps this would help get a few more eyes on this.

+++ b/core/modules/language/src/EventSubscriber/LanguageRequestSubscriber.php
@@ -87,6 +109,16 @@ public function onContainerInitializeSubrequestFinished() {
+    if ($this->currentUser->isAnonymous()) {
+      $uri = $this->requestStack->getCurrentRequest()->getRequestUri();
+      if (preg_match('/^\/user\/reset\/(\d+)$/', $uri, $matches)) {
+        $account = $this->entityTypeManager->getStorage('user')
+          ->load($matches[1]);
+        if ($account) {
+          $this->currentUser = $account;
+        }
+      }
+    }

Putting a special case in this service for one path does not seem like a good idea at all.

Can we go back to the patch at #45, which needs a reroll?

As suggested by #58, I restart from scratch (as the previous patch was 7 years ago).

To start with this issue, here the test-only so it obviously fail, to demonstrate the issue.
I will work on the necessary following patch on the next days (if nobody already creates the fix before ^^).

After digging on the code of resetPassword, I found a solution to make it work properly, but it will certainly create some "side effects", let's tests them with testbot.

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.

For now if you "reset your password" using the Spanish (es) langcode, then you will receive the mail in Spanish (es), even when the use has a preferred langcode. We maybe need to update the Issue summary to reflect this - it's not the default site language but UI..

Here is the idea behind my patch:

Use the preferred langcode when the user has one or use the UI langcode if the user never set his preferred langcode.
By doing this, I avoid using the default site language (which would be used if getPreferredLangcode return NULL) when the user go thought /es/user/password without having a preferred langcode. So I maintained the default behaviour - using the UI langcode when user has not preferred langcode.

Also, should we add some code coverage to asserts the following ?!
- When user has no preferred langcode & use a localised form of Reset Password (Eg. /es/user/password) it will receive a link in Spanish
- When a user has a preferred langcode & use a localised form of Reset Password (Eg. /es/user/password) it will receive a link in his preferred langcode.

Thanks for you review & your suggestions !

+++ b/core/modules/user/src/Form/UserPasswordForm.php
@@ -133,9 +133,16 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
+    // Get the UI langcode as default lang.
     $langcode = $this->languageManager->getCurrentLanguage()->getId();
 
-    $account = $form_state->getValue('account');
+    // When the user has a preferred lang, use it instead of UI lang.
+    if ($account->getPreferredLangcode()) {
+      $langcode = $account->getPreferredLangcode();
+    }

I look at this code, and I think: surely there must be something that encapsulates this logic, so we don't have to do it?

Isn't this the job of the language negotiation system? Is this code in LanguageNegotiationUser perhaps not working because on the reset password page the user isn't logged in yet?

  public function getLangcode(Request $request = NULL) {
    $langcode = NULL;

    // User preference (only for authenticated users).
    if ($this->languageManager && $this->currentUser->isAuthenticated()) {
      $preferred_langcode = $this->currentUser->getPreferredLangcode(FALSE);
      $languages = $this->languageManager->getLanguages();
      if (!empty($preferred_langcode) && isset($languages[$preferred_langcode])) {
        $langcode = $preferred_langcode;
      }
    }

Im using only one language on my site. (not english) I try to overwrite the system emails sent to users when an account gets activated, it is overwitten on both the /admin/config/people/accounts and also the /admin/config/regional/translate admin pages.

The problem is that all the emails gets sent out as the original translaton, and not the overwritten. Only the pending admin approval email gets sent as the one I entered. all the others stay the same.

I hope this is related and helps to figure out the issue.

Hey @joachim, thanks for your message in #65.

Indeed, it can't work because the code in LanguageNegotiationUser required the user to be logged in.

Do you have any idea how we can continue on this issue - in the case my solution in #60 does not fit ?

Here's a question, why does "the code in LanguageNegotiationUser required the user to be logged in"? Anonymous users need LanguageNegotiation too.

That's the bug...

@alienzed I agree with you, but it's another question. That this issue can't resolve whiteout going out-of-scoop. Should we then open a new Issue & add it as blocker for this one ?

All good questions... Personally I resolved my issue by following the pack and making sure my user has the right language set (although in my case, since I am actually manipulating the user for this request, I set the language the page is in to the profile right before calling _user_mail_notify())

@wengerk's suggestion of opening a new issue and referencing it as blocking is probably the way to go, since, again, why should anonymous users not have LanguageNegotiation? Unfortunately I have no appetite to push on that at this point.

As for this specific issue, what do we think is more appropriate?
a) The language of the page
b) The language in the user profile

Of course the profile is a more authoritative data point, but that is assuming their language preference truly reflects what the user wants and not what was set and forgotten by default during initial registration
Then, what makes more sense for someone who has clearly lost access to their account, perhaps due to a relatively long absence from the site. Can we take anything from the fact they are browsing the site in a specific language? Furthermore, wouldn't it be a bit weird to request the reset in english, and then to get the email in french (or whatever languages are available...)

Think about that as if it were a human to human interaction. You walk into a store you've been to many times, they know you can speak french as you have spoken french in the past (this is your preference as far as they are concerned), you go up to the counter and ask the cashier a question in English. Should the cashier respond in English or in French?
English I think is the intuitive 'human' choice here, because it is immediately obvious that the person speaks English and they've chosen their most up to date language preference by means of speaking in that language.
French is the OCD technical guy's choice, being a configuration setting that should be respected.

So personally I think the page's language is the intuitive authority here, just for conversation's sake :)

Thoughts?

just to be clear, by:

I set the language the page is in to the profile right before calling _user_mail_notify())

I meant that ultimately I enforce the language as defined by path prefix. I set That language to the user's profile right before sending the email, so as to override their profile's preference.

I think this really depends on the situation. Maybe it should be a setting...

Are the issues not directly related? No one but a user can request a password reset email, and users all have a default language preference set on account creation. Thus there is always a language preference, and password reset emails only work on accounts, which have the preference, thus

If Anonymous comes in with a path prefix or a domain prefix, I'd expect the email to be sent in that language for sure, if that's how you've configured your language detection priorities.

is not how it works now. The Profile Preference is taken instead of the page's language as defined by path prefix/domain/whatever. I did not mean to derail the thread at all, I arrived here because I had the same problem and had to fix the user's profile programmatically prior to sending the email, because it was not respecting the page's language.

It's just updated patch from #56 for 8.7.x. I agree that isn't a good solution but it works for my case.

I re-rolled the #39 (Drupal 7) patch for the D 7.67 version. Not sure if it is OK to post it here.

The patch #78 is not working in Drupal-8.7.10. An error is appearing.

Too few arguments to function Drupal\\language\\EventSubscriber\\LanguageRequestSubscriber::__construct(), 4 passed in /var/www/html/[rootfolder]/core/lib/Drupal/Component/DependencyInjection/Container.php on line 281 and exactly 6 expected in /var/www/html/[rootfolder]/core/modules/language/src/EventSubscriber/LanguageRequestSubscriber.php on line 81

I'm also facing this issue in Drupal Version 8.7.5.

Please provide a good solution.

During the user registration, If the user goes through the 'Arabic' language then he/she will receive all emails in 'Arabic' language. For more information see the below attached file.

All emails are sent as per the user's preferred language.

For example:-
The user has registered a new account of the german language. In the user profile, german language is set automatically by language module. So, all emails are sent to german language.

@rohit-drupal I'm not sure about the solution in #78 as @joachim points out #58 putting a special case in the service feels wrong. #60 was taking another approach that looks more correct. Looking the discussion after that patch I think what we need to need is agree what the behaviour should be - and detail what the current behaviour is for what we want to fix - in the issue summary.

#2991677-13: Wrong language in token_options in user_mail function has a test that is not needed for that issue in the end, but could be useful to this issue.

After working on #2991677: Wrong language in token_options in user_mail function, we discovered and fixed the bug to ensure both email content and token content reflects the same $langcode for any email sent by user_mail.

The fix on #60 looks more right with me as well, submitForm() it should not be passing the browsers language to _user_mail_notify() when we're expecting to see the user's preferred language on return.

If we can agree on this direction, I'd be happy to push out a patch base on #60, or we can review it again.

I think #60 is still too complex.
1) We don't infer the user's preferred language from the current language when registering a user, so why do we do it when resetting a password? It seems to be a badly-implemented edge-case feature.
2) #74 makes an excellent point:

Let's assume for a moment that your site supports English and Chinese. User A comes in speaking Chinese (having their browser set to Chinese) and enters user B's email address. User B, who doesn't understand Chinese, gets a Chinese email from your site, and they'll be scared.

I think it best to just remove any code in UserPasswordForm about the current language and leave it to _user_mail_notify() to send email in user's language.

If a site really wants to have emails sent in the browsing language if the user has no preferred language, then they can swap out the User entity class and override the getPreferredLangcode() method. A simple case for contrib/custom.

My bigger concern is with the language of the password reset email. The IS only mentions the language of the page the user visits after clicking on the one-time login url in the email. This is the "token language" that @g-brodiei fixed in #2991677: Wrong language in token_options in user_mail function. But as I understand it, I would have expected the current code to result in the text of the email to be in the language the visitor was browsing in not the user's preferred language. Can someone confirm this is what happens, or point me to a test about this?

Update issue summary.

Here I have just added reroll of patch #78, it still NW as per comment #85.

Discussed with @pameeela, @g-brodiei and Kristen pol on slack. A few things emerged:

- when a user registers, their browsing language at registation becomes their account preferred language
- this means that the only people without a preferred language are those from before language is enabled. They're a real edge case, and it's not unreasonable to assume they're comfortable in the site default language.
- another scenario related to #74 where using the browsing language as the password reset language is problematic is remote support, where someone other than the user tries to help them by triggering a password reset for them

Given this, I think we should ignore browsing language entirely. It's simpler, safer and will very rarely be a significant problem.

Additionally, the IS says:

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, i

But shouldn't it say:

Receive email in English with reset link to French page fr/user/reset.
After #2991677: Wrong language in token_options in user_mail function this will be consistent: email in English and reset link to English page /user/reset

Thank you for summarising the discussion on slack @jonathanshaw!

Yeah, it's much clearer the way you rephrase the sentence~ thanks.

Updated the IS.

Providing patch base on the approach to:

1. Use the default language instead of browser language when user accounts preferred language is not set.
2. Use the preferred language when it's set, assure the reset URL respects it.
3. Set the langcode correctly from submitForm() in UserPasswordForm.php

Notice:
1.The method $account->getPreferredLangcode() will automatically fallback to the site's default language by it's default. It will only return empty string when the argument passed in is false. therefore, we don't need to set a condition check in submitForm().

// Set default langcode is "en" and preferred_langcode is "".

// gets "en",
$account->getPreferredLangcode()

// gets "", when default langcode is "en" and preferred_langcode is "".
$account->getPreferredLangcode(false)

Updated IS on task to do.

Yay! Looking good.

1. +++ b/core/modules/user/src/Form/UserPasswordForm.php
   @@ -168,9 +168,11 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   +    // $langcode will fallback to default langcode if property preferred_lancode is not set.
   +    $langcode = $account->getPreferredLangcode();
   ...
        $mail = _user_mail_notify('password_reset', $account, $langcode);
   

   Do we need to do this at all? Can't we leave it to _user_mail_notify() to handle langcode entirely?

2. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +  public function testUserPasswordResetPreferredLanguage() {
   

   There's quite a lot of repetition in this test. It feels like either (a) it should be 3 different tests, with some shared logic in setUp() and some helper methods, or (b) it needs an @dataProvider.

3. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +    $this->assertStringNotContainsString("$default_language_code/user/reset/", $resetURL);
   

   Let's assert what it does contain as well.

4. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +    ¶
   ...
   +    // ¶
   ...
   +  ¶
   

   Extra spaces at end of line I think

5. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +    // Test reset URL respects preferred language over other lanugage settings.
   

   spelling "language"

6. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +    $this->assertMailString('body', '/fr/user/reset', 1);
   

   I find it curious this does not use $resetURL, maybe there's a good reason.

7. Needs a coding standards check

1. Removed $langcode from formSubmit() as we do not need it to make use of preferred_langcode from account, it is determined automatically within _user_mail_notify. (Thanks for the suggestion! totally missed that.)
2. Combined repeated code to two helper method to help with assertion.
3. Fixed coding standard, removed empty space.

1. I'm afraid I still find the test a little difficult to understand, I think a committer might not be happy with it. Could we make it work with a simple data provider like this?
   

   [
     [
       'browsing_lang' => NULL,
       'account_lang' => NULL,
       'expected_reset_lang' => 'en',
     ],
     [
       'browsing_lang' => NULL,
       'account_lang' => 'zh',
       'expected_reset_lang' => 'zh',
     ],
     [
       'browsing_lang' => 'zh',
       'account_lang' => NULL,
       'expected_reset_lang' => 'en',
     ],
     [
       'browsing_lang' => 'zh',
       'account_lang' => 'zh',
       'expected_reset_lang' => 'zh',
     ],
     [
       'browsing_lang' => 'zh',
       'account_lang' => 'fr',
       'expected_reset_lang' => 'fr',
     ],
   ]

   It would be so much easier to understand the intention of the test.

2. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +    // Unset language prefixes.
   +    $config = $this->config('language.negotiation');
   +    $config->set('url.prefixes', [])->save();
   

   I'm not familiar with language testing, but I'm surprised if these lines are needed. The test isolation is usually pretty good even without explicit resetting like this.

3. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,88 @@ public function testUserPasswordReset() {
   +   * default lanugage is different.
   

   spelling: 'language' not 'lanugage'

Finally got this into a dataprovider, just too many variables mixed together LoL!

Gonna cross my finger and see how this one goes!

1. Removed repetitive code from test, and use dataprovider to loop through all assertions.
2. Removed final config reset of language.negotiation and prefixes.

I got:

86287-104.patch:57: trailing whitespace.
   * 
86287-104.patch:81: trailing whitespace.
    
86287-104.patch:85: trailing whitespace.
  
warning: 3 lines add whitespace errors.

when applying patch #104 so I'm attaching new patch to fix code standard.

Except that, I think patch fixes the problem and it looks good to me.

Ahhhh! Coding standards! The spaces, thanks @paulocs!

Nice!

+++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
@@ -205,6 +213,108 @@ public function testUserPasswordReset() {
+    $this->account->preferred_langcode = $setPreferredLangcode;
+    $this->account->save();
+    $this->assertSame($actualPreferredLangcode, $this->account->getPreferredLangcode(FALSE));
...
+        'setPreferredLangcode' => 'null',

Should preferred langcode really be the string 'null'? I'd have expected

if (!empty$setPreferredLangcode)) {
  this->account->preferred_langcode = $setPreferredLangcode;
  $this->account->save();  
  $this>assertSame($actualPreferredLangcode, $this->account->getPreferredLangcode(FALSE));
}

In which case there's no need for $actualPreferredLangcode at all, you can simpy do

$this>assertSame($setPreferredLangcode, 
$this->account->getPreferredLangcode(FALSE));

Wow, thanks for the suggestion @jonathanshaw ! The code looks much cleaner now

Thanks for pointing out the NULL settings for preferred language. For this, under the suggestion you made to remove $actualPreferredLangcode, I changed the test below for preferred langcode to set as an empty string instead of 'null' string.

'Test language prefix set as zh, visiting zh with preferred language as \'\'' => [
        'setPreferredLangcode' => '',
        'activeLangcode' => 'zh-hant'

1. Made change base on suggestions of #110
2. Update test description in dataprovider to fit each scenario

Here I have fixed failed test of patch #112.

Thanks @ravi.shankar

drupalGetHeader() is deprecated in drupal:9.2.0 and is removed from drupal:10.0.0. Use $this->getSession()->getResponseHeader() instead. See https://www.drupal.org/node/3168383
4x in UserPasswordResetTest::testUserPasswordResetPreferredLanguage from Drupal\Tests\user\Functional

Looks like we need to chase HEAD.

Fixed failed test of patch #116.

I just skimmed the patch and notices a missing doc bloc.

+++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
@@ -205,6 +213,105 @@ public function testUserPasswordReset() {
+  public function languagePrefixTestProvider() {

Needs a doc bloc.

Leaving novice tag for this work. If you make this change remember to remove the novice tag. thx.

Addressed comment #121.

Thanks!

1. +++ b/core/modules/user/src/Form/UserPasswordForm.php
   @@ -168,11 +168,9 @@ public function validateForm(array &$form, FormStateInterface $form_state) {
   -    $mail = _user_mail_notify('password_reset', $account, $langcode);
   

   This is the only place in core that passes in a langcode that is not the preferred langcode. This issue seems to suggest that all email should be sent to a user with their preferred langcode - which makes sense to me. We should file a follow-up to discuss deprecating this argument.

2. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,110 @@ public function testUserPasswordReset() {
   +    \Drupal::configFactory()->reset('language.negotiation');
   

   This is not necessary. We're rebuilding the container in the next line.

3. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,110 @@ public function testUserPasswordReset() {
   +    // Test Default langcode is different from active langcode when visiting different.
   +    if ($setPreferredLangcode !== 'en') {
   +      $this->assertLangcodeDifferent($prefix, $activeLangcode, 'en');
   +    }
   +
   +    // Test password reset with language prefixes.
   +    $this->assertLanguagePrefixResetUrl($visitingUrl, $expectedResetUrl, $unexpectedResetUrl);
   

   I think adding the assert functions makes it harder to work out what is being tested. Generally we should only add assert functions when they are called multiple times like in a loop and that's not happening here.

4. +++ b/core/modules/user/tests/src/Functional/UserPasswordResetTest.php
   @@ -205,6 +213,110 @@ public function testUserPasswordReset() {
   +    $this->assertSame($activeLangcode, $this->getSession()->getResponseHeader('Content-language'));
   +    $this->assertSame($defaultLangcode, $this->languageManager->getDefaultLanguage()->getId());
   +    $this->assertNotSame($this->languageManager->getDefaultLanguage()->getId(), $this->getSession()->getResponseHeader('Content-language'));
   

   Given the two assertSame()s the assertNotSame seems superfluous.

5. This behaviour was introduced in #82499: Email text posting in the user's language - which is the issue that introduce the idea of a preferred user langcode! I think it was done to maintain existing behaviour. And not really an active choice. Pinging @Gábor Hojtsy...

I cannot think of why we decided in #82499: Email text posting in the user's language to send the pw reset email in the page language. The only case would be if new users are not saved with the right (page language) code when they get created. Then you would get the wrong email if we use the user preferred langcode. But I believe that is not the case, so this behaviour change is definitely good.

Updated test code base on #126, thanks!

I created #3186752: Deprecate langcode argument to _user_mail_notify() for the deprecation.

Updating credit for reviews that made reviews that affected the patch.

Committed and pushed a719eefbf1 to 9.2.x and b2984279e6 to 9.1.x. Thanks!

Hi, about this patch, we on anonymous always send English mail (EN is default, but page is current language is RO)

This issue is closed. Please open a new issue if you have a bug to report or feature to request.

Please state clearly (a) what the current behaviour is and (b) what you think the behaviour should be.