User password reset form button text is wrong

Updated the button text as well as the tests that depend on that text - SiteMaintenanceTest and UserPasswordResetTest.

Added a patch for D7 as well.

1: D8core-user-password-reset-2131849-1.patch queued for re-testing.

Fixing tag to clue in the UX team on this issue. It may seem pedantic, but since this is a very user-facing string, it's probably good to spend a bit of time (not too much) to get it right.

And, hm. While the new text is certainly more accurate, searching Google for "Request password reset" (quoted) only returns 347,000 results. This implies this is not really standard terminology used by others.

What if we just named the button something really super boring like "Submit"? The page title is "Request new password" which already tells you what you are doing here.

I'm not that fussed either way, so if there are no better ideas within a week or so, we can go with this.

I am not sure about this change.

1) It seems like an uncommon label it focuses on the very technical "request" rather than the action of getting a new password.

2) It doesn't specify the medium. Clicking this button could result in anything, nothing indicates that I will get an e-mail.

I think both, will result in a decrease in usability - even though we are more accurate.

I'm happy to re-roll the patches with new button text - I'm not a UX person and don't have a strong feeling about this beyond that jhodgdon's point is correct - the text should somehow elucidate what's really going to happen...

I am just wondering, this is on a page right? Maybe we shouldn't be just relabeling the button but making the page more clearer?

I'll get on new patch(es) this evening - if anyone's in a rush, feel free to preempt me :-)

@jhodgdon Agreed :)

Here's a re-rolled D8 patch, with before and after screenshots. The password reset page now includes some explanatory text and the button simply says "Submit."

Works perfectly, attached before & after screen shots.

I'm down with those changes for the most part, but not with changing 'username' to 'user name.' I get your point but it would be inconsistent with pretty much every other usage in the system. There are 800-odd uses of 'username' and only 63 of 'user name' and the latter is primarily used in comments rather than in UI text.

I changed the text to 'Reset your password' rather than the more casual 'Forgot your password?' I've no objection to the latter, it just seemed out of character for the system as a whole. If consensus is for 'Forgot your password?' I'm cool with it.

Anyway, here's a new patch, with "after" screenshots for the three use cases that were changed - 1) Anon password reset request from /user, 2) Password reset request from login block, and 3) Authenticated user password reset request from /user

Yeah - There's something going on with the routes for the local tasks, and code that seems to think that /user/password will only be called for anon users ... clearly not a correct assumption :-). But it's also not really related to this specific issue, so I'm thinking maybe this should be RTBC'ed if possible and we can move on to that after. My 2 cents, anyway.

Patch no longer applies.

umm my mistake...

problems with the testbot.

Before:

After:

After:

Before:

and this remains the same:

The patch looked to be fine and the button text i s displaying correctly!!

again.

and again.

and again.

Committed 666f423 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation.

diff --git a/core/modules/user/src/AccountForm.php b/core/modules/user/src/AccountForm.php
index ac16e4e..7cf5ad6 100644
--- a/core/modules/user/src/AccountForm.php
+++ b/core/modules/user/src/AccountForm.php
@@ -141,7 +141,8 @@ public function form(array $form, FormStateInterface $form_state) {
           array(
             '%mail' => $protected_values['mail'],
             '%pass' => $protected_values['pass'],
-            '!request_new' => $request_new)
+            '!request_new' => $request_new,
+          )
         );
       }

Fixed to implement our coding standards on commit.

Note that a "semi-backport" of this to Drupal 7 is currently being discussed at #734536: Terminology wrong around "Request new password" (which this issue was probably originally a duplicate of).