I'm confused - what's the difference from the current design?

@MaxSem There was never a ticket that specified the exact language and visual elements of this work. The first ticket (which you worked on) provided no requirements around these aspects (and it was meant to just focus on basic functionality). While you developed work that is close to what we want, there are certainly some differences -- for example, your implementation states that this preference requires only email (when, in fact, we're building a preference that requires both email and username). So, this ticket is meant to clean up and finalize the UX/language side of the work.

For one, when reading the UI of T234537#5553996, initially thought that "Require email address" meant requiring being in control of the email address (i.e. that the feature was like requiring that the user validates the change via email in addition of knowing the current password before password changes take action), whereas it actually is meant to require knowing which is the email address linked to the account.

As for the mockup, I would prefer a wording such as "Do not send password reset emails, unless the request provides both the username and the email address associated with that account."

I think that would be more clear, since this is basically a "Do not spam me" feature. However, double negations are usually frowned upon, and "Do not ... unless" may be too similar to that.

Also, the page providing the feature should clearly state the associated risk of confirming a suspicion of the user email address, in case it would be leaked (I think there's no implementation yet, so not sure if there would indeed be such confirmation oracle).

Thanks for the feedback, @Platonides! The text in the mock-up is outdated, and the mock-up is only meant to illustrate the basic placement of the text. The actual text will be much more clear, as there will be both a general statement ("Require both email address and username to reset password") and sub-text, which will be displayed inline ("If checked, the password reset email for this account will be sent only when both the email address and username are provided in the reset form"). The general statement is meant to be brief, so users can quickly read the information and get a basic sense of the functionality. However, if they want to receive additional information, they can certainly refer to the inline text as well.

@Platonides I just wanted to update you and let you know that your comments helped us rethink the language. We have just updated the language, which we hope is much more clear. So, thank you!

Change 553379 had a related patch set uploaded (by HMonroy; owner: HMonroy):
[mediawiki/core@master] Change password reset update language in preferences

https://gerrit.wikimedia.org/r/553379

I'm not sure if it's covered by this ticket, but I've noticed a discrepancy due to the requireemail preference being in the 'Email options' section: if the email is not confirmed, it says that "no email will be sent for any of the following features":

Change 553379 merged by jenkins-bot:
[mediawiki/core@master] Change password reset update language in preferences

https://gerrit.wikimedia.org/r/553379

In T234537#5700964, @Samwilson wrote:

But this isn't true for requireemail; password reset emails are sent even for unconfirmed email addresses.

Oh! Thanks for pointing this out @Samwilson. Did you test this?

I was under the impression that it wont send an email if it isn't confirmed. This is why we tried to get stats on how many people who add their emails actually confirm them.

@ifried, as Sam points out, this might change some designs.

Yep I tested it, password reminders are the only exception for confirmed email addresses. As $wgEmailAuthentication says: "all email functions (except requesting a password reminder email) only work for authenticated (confirmed) email addresses."

@Samwilson, thanks for this catch! I've tested and confirmed that password reset emails can be sent to unconfirmed email addresses. This impacts work in T234952. We originally implemented this behavior for confirmed users, as per T234952. For this reason, I have created a new ticket (T239937) to implement this same behavior for unconfirmed users. We can discuss it in Estimation today, and I'll connect with @Prtksxna on the ticket (after estimation) as well.

Also, we'll need to rethink the message for unconfirmed users, since the message is not accurate for them (given the new preference, as Sam has pointed out). Thanks!

Acceptance Criteria:

• Provide a checkbox under "Email options" that states "Send password reset emails only when both email address and username are provided."
• There should be sub-text (i.e. help text shown inline), which states: "This improves privacy and helps prevent unsolicited emails."

PRU in Special:Preferences now looks like:

Wording matched acceptance criteria.

As this is just an update to a translation, there is nothing else I can see to test.