WordPress.org

Make WordPress Core

Opened 13 months ago

Closed 7 weeks ago

Last modified 6 weeks ago

#47656 closed enhancement (fixed)

Remove 'Error:' prefixes from error notices as they're redundant

Reported by: garrett-eclipse Owned by: audrasjb
Milestone: 5.5 Priority: normal
Severity: normal Version:
Component: I18N Keywords: has-patch
Focuses: ui, accessibility, administration, ui-copy Cc:

Description

Branching from #47003

@ramiy's comment - https://core.trac.wordpress.org/ticket/47003#comment:10

I think that this ticket should handled only the merge of similar translation strings. A separate ticket should remove the Error: prefix from the error messages in the dashboard.

The Add New user form throws errors when invalid characters are used, etc. These have an Error: prefix on them which is unneeded and makes it harder to reuse some of the strings as found in #47003.

I would suggest they simply be removed.

Attachments (9)

47656.diff (36.1 KB) - added by quadthemes 3 months ago.
In this patch, 'Error:' prefixes have been removed and error messages text have been improved
47656.1.diff (34.2 KB) - added by sabernhardt 2 months ago.
refresh after [47808], with a few edited messages
47656.2.diff (35.8 KB) - added by audrasjb 8 weeks ago.
Patch refresh
47656.3.diff (32.7 KB) - added by afercia 8 weeks ago.
47656.4.diff (33.7 KB) - added by audrasjb 8 weeks ago.
47656.5.diff (33.8 KB) - added by afercia 8 weeks ago.
47656.6.diff (33.5 KB) - added by afercia 7 weeks ago.
47656.7.diff (34.1 KB) - added by sabernhardt 7 weeks ago.
Restoring the Error prefix for the 'site admin' message and removing an extra period from a 'site entry' message
gutenberg notices.png (53.1 KB) - added by afercia 7 weeks ago.
Forgotten screenshot: Gutenberg notices

Download all attachments as: .zip

Change History (61)

#1 follow-up: @SergeyBiryukov
13 months ago

Previous discussion: #15887, which resulted in [18841].

Specifically, I think comment:5:ticket:15887 sums up the purpose of the ERROR: prefix nicely:

All CAPITAL letters in a word typically denotes Emphasis. It's not meant to be

"Good day gentle, but incorrect, user - there seems to be an error. Be a sport and type in your e-mail address"

But rather

"HEY, USER! (yelling) THERE'S A PROBLEM! ATTENTION! ERROR. Type in your email address please"

Last edited 6 months ago by SergeyBiryukov (previous) (diff)

#2 @SergeyBiryukov
13 months ago

We could, however, move the ERROR: prefix out of the strings and add it separately, see the error message in wp-admin/themes.php for example. Related: #38860

Last edited 13 months ago by SergeyBiryukov (previous) (diff)

#3 in reply to: ↑ 1 @garrett-eclipse
10 months ago

  • Milestone changed from Awaiting Review to 5.4

Thanks @SergeyBiryukov I agree completely and feel isolating the prefix is our best option. I've updated #47003 with that information and am moving this into 5.4 so the two can coincide.

#4 @afercia
10 months ago

#48412 was marked as a duplicate.

#5 @afercia
10 months ago

  • Focuses ui accessibility ui-copy added

Quoting the description from the duplicate #48412. I'd also suggest to change the component to "Administration" as this is also related to UI and accessibility and not only to i18n.

Follow up to ticket:43037#comment:42

On #43037, some error messages for the login screen were improved and, amongst other things, the all caps word ERROR was removed..

There are other occurrences in core of the all caps ERROR included in error messages, and sentence case Error as well.

I'd like to propose to remove all of them: all caps should be avoided for better readability and because screen readers may pronounce all caps words as abbreviations.

Also: sometimes ERROR is all caps, sometimes it's sentence case, sometimes it's bold, sometimes the entire error message is bold. The most recently added ones (PHP compatibility and SIte Health) seem to use sentence case. Some consistency would be nice.

A few examples:

<strong>ERROR:</strong> There was an error connecting to the server ...
<strong>Error:</strong> Current WordPress and PHP versions do not meet ...
<strong>Error:</strong> This plugin <strong>requires a newer version of PHP</strong>.
<strong>' . __( 'ERROR: The network could not be created.' ) . '</strong>

These messages appear in admin notices that are already marked as errors because of the red border. Moreover, I'm not sure there's the need to specify "error" at the beginning of the message, as that's not relevant for users. Instead, it's the content of the message that is relevant. For example:

ERROR: There was an error connecting to the server, Please verify the settings are correct.

Admittedly, this is the more evident case as the word "error" is repeated also in the second part of the message. (note: the comma should be changed to a period)

Also in other cases "Error" could be just removed. For example:

Error: Current WordPress and PHP versions do not meet minimum requirements for {plugin name here}

As a user, I'm not interested whether this is an error, a warning, an informational message or whatever :) I'm just interested in the content of the message which is already made prominent by the notice styling.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 months ago

#8 follow-up: @sabernhardt
6 months ago

After discussion in accessibility bug scrub, we agreed to focus on the easy part (replacing all-caps) for 5.4 and then try to make a bigger change to messaging (very) early in the 5.5 cycle.

This quick fix portion could be handled on ticket #42945:
Search for uppercase ERROR: and replace with Error:

#9 @SergeyBiryukov
6 months ago

In 47156:

Accessibility: Text Changes: Use sentence case for the word Error in various error messages, instead of all caps.

Using all caps should be avoided for better readability and because screen readers may pronounce all-caps words as abbreviations.

Props afercia, ryokuhi, sabernhardt, garrett-eclipse.
See #47656, #43037, #42945.

#10 in reply to: ↑ 8 @SergeyBiryukov
6 months ago

  • Milestone changed from 5.4 to 5.5

Replying to sabernhardt:

After discussion in accessibility bug scrub, we agreed to focus on the easy part (replacing all-caps) for 5.4 and then try to make a bigger change to messaging (very) early in the 5.5 cycle.

Replacing all-caps was addressed in [47156], moving to 5.5 for any follow-up changes.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


4 months ago

#12 @afercia
4 months ago

  • Owner set to audrasjb
  • Status changed from new to assigned

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


3 months ago

@quadthemes
3 months ago

In this patch, 'Error:' prefixes have been removed and error messages text have been improved

#14 @quadthemes
3 months ago

Since removing error prefixes and improving error messages was decided on the Slack, here is the patch for the same.
I would be glad if you can check this and give feedback for improving meesages.

@sabernhardt
2 months ago

refresh after [47808], with a few edited messages

#15 @sabernhardt
2 months ago

  • Keywords has-patch needs-testing added

Thanks for the patch, @quadthemes!

I like most of your wording improvements, but I edited a few:

  1. I corrected the verb agreement for the "Passwords don't match" error.
  2. The already-registered username and email address errors now consistently have a period before "Please" and they still use the word "This". (If changing "This" to "That" is preferred, I have no strong opinion either way.)
  3. If we add the word "text" to the empty comment error, I think it would be better to use the word "your": Please type your comment text.

The messages from wp_get_theme()->errors()->get_error_message() might benefit from keeping the 'Error:' prefix, yet the prefix is removed in my patch, too. (The code is found in wp-admin/themes.php.)

So in 47656.1.diff, these new strings are revised beyond simply removing the Error prefix (changes in bold):

  1. Passwords don&#8217;t match. Please enter the same password in both password fields.
  2. Please enter a username or email address.
  3. Please type your comment text.
  4. Site URL you&#8217;ve entered is already taken.
  5. There was a problem creating site entry.
  6. This email is already registered. Please choose another one.
  7. You can&#8217;t reply to a comment on a draft post.

This ticket was mentioned in Slack in #accessibility by sabernhardt. View the logs.


2 months ago

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


2 months ago

#18 @audrasjb
8 weeks ago

  • Keywords needs-refresh added; needs-testing removed

Patch looks good to go on my side.
I think it already needs some refresh. It's difficult to keep such patches up to date against trunk, so I'll refresh the patch now. Hopefully it can quickly be committed so we don't have to refresh it too many times ;)

@audrasjb
8 weeks ago

Patch refresh

#19 @audrasjb
8 weeks ago

  • Keywords commit added; needs-refresh removed

#20 follow-up: @afercia
8 weeks ago

  • Keywords commit removed

Thanks for the refresh. Some issues in the latest patch:

  • I don't think files from external libraries should be changed, as they will be replaced with the next library updated. See src/js/_enqueues/vendor/tinymce/langs/wp-langs-en.js.
  • There's a reason why many strings use &#8217; instead of directly using the curly quote . For example: The email address isn&#8217;t correct. should not be changed to The email address isn’t correct
  • Running grunt precommit, the Tests_Ajax_ReplytoComment::test_with_draft_post is failing because a string changed: Failed asserting that exception message 'You can’t reply to a comment on a draft post.' contains 'You are replying to a comment on a draft post.'.

Will fix and commit.

@afercia
8 weeks ago

#21 @afercia
8 weeks ago

  • Keywords commit added

#22 in reply to: ↑ 20 @SergeyBiryukov
8 weeks ago

Replying to afercia:

I don't think files from external libraries should be changed, as they will be replaced with the next library updated. See src/js/_enqueues/vendor/tinymce/langs/wp-langs-en.js.

Although wp-langs-en.js is in the vendor directory, it's not an external library. It has WordPress-specific strings (as the prefix suggests), and can be safely included in this change.

#23 @SergeyBiryukov
8 weeks ago

  • Keywords needs-refresh added

@audrasjb
8 weeks ago

#24 @audrasjb
8 weeks ago

  • Keywords needs-refresh removed

Thanks, @SergeyBiryukov. Ticket refreshed.

#25 @afercia
8 weeks ago

Good to know, thanks Sergey!

#26 @afercia
8 weeks ago

  • Keywords commit removed

I noticed that some revised string from 47656.1.diff by @sabernhardt are missing from the Following patches. For example: Passwords don&#8217;t match. is now missing. I think these were missed unintentionally so I'm going to re-add them.

@afercia
8 weeks ago

#27 @afercia
8 weeks ago

  • Keywords commit added

#28 @afercia
8 weeks ago

To better clarify the point that the message content is more important than the "Error" prefix, here's a summary of some bits of the relevant conversation on the WordPress Slack.

For example, when the "Error" prefix is in a wp_die():

http://cldup.com/iqCFMVAUTs.png

On such a page, it’s pretty evident an error occurred. I'm not sure what value the word “Error” adds in this case.

Same applies to the admin notices: they're already pretty prominent.

When the content is clear and understandable by everyone, there's probably no need to add anything else.

Also regarding consistency: in the current WordPress codebase, there are error messages that don’t use the prefix “Error” at all. Overall, keeping it simple is probably the best option.

Lastly, reading the arguments from #15887, I'm not sure "yelling" at users is a good strategy for a good user interface.

#29 @afercia
8 weeks ago

There are also a few cases where a warning admin notice has a bold "Warning" prefix :)

For example:

http://cldup.com/WuasphgdAT.png

<div class="notice notice-warning inline active-plugin-edit-warning">
	<p><?php _e( '<strong>Warning:</strong> Making changes to active plugins is not recommended.' ); ?></p>
</div>

Which leads us to one of the points mentioned on the relevant conversation on Slack:

WordPress displays errors, warnings, info notices. Should we then add the word “Warning” to warnings and “Info” to informational messages? (edited)

As a user, I’m interested in the content of the message. Not interested that much in the color it uses or the category it belongs to.

I'd tend to think this is one more inconsistency which should be addressed separately.

#30 @afercia
8 weeks ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 48059:

I18N: Remove the "Error:" prefix from error messages.

For a number of years, most of the WordPress error messages have been prefixed with "Error:". However, these messages appear in a context where it's already clear an error occurred. Whether it's an error, a warning, or any other classification, that's not so relevant for users. The content of the message is the relevant part. The "Error:" prefix doesn't add great value while it does add unnecessary complexity for the message readability.

Also, revises some of these messages to improve clarity and removes HTML from translatable strings.

Props garrett-eclipse, ramiy, SergeyBiryukov, afercia, sabernhardt, quadthemes, audrasjb.
See #47003, #43037, #42945, #15887.
Fixes #47656.

#31 @johnjamesjacoby
8 weeks ago

Sorry for being late to the progress here.

Short history lesson: these prefixes were originally added to address the accessibility concern that HTML div tags do not provide any context as to what kind of notice is being displayed or how severe the problem is.

Without "Error" and "Warning" type prefixes, and without any additional hint as to why that paragraph is important, these HTML tags are now simply just yet-another paragraph on the page.

Perhaps that is no longer a concern thanks to some related work that is not linked here. Not trying to get in the way of progress, I promise, but I have a small concern that without aria tags or something similar, removing these prefixes may be making accessibility worse for a subset of the audience being targeted for improvements here.

#32 @johnjamesjacoby
8 weeks ago

Also note that during WordCamp Europe contributor day, bbPress was patched - #BB3377 - to change to sentence case.

Since the plan appears to remove them entirely, is it possible to link to (or create) a ticket or handbook page with what the penultimate design is for these types of notices? That way plugins (like the bb's) can work towards that instead of reacting to incremental changes between rapid release cycles?

#33 @kebbet
8 weeks ago

Noted this as well after the merge. Thought Error-messages should have a clear contextual header and not only communicate the severeness with color, like it's stated here -> https://www.w3.org/TR/WCAG21/#use-of-color

Another reference for alert-messages.
https://designsystem.digital.gov/components/alert/

#34 @afercia
8 weeks ago

Thanks for raising your points @johnjamesjacoby and @kebbet.

I do know use of color is not sufficient. On the other hand, one of the points of this change is that the notice content is way more important than a plain text prefix or visual effects like bolded text.

Prefixes like "Error:" or "Warning:" don't add any semantics. The whole notice is not guaranteed to be perceived by assistive technology users. For example, for screen reader users this is just text placed after (or before) the main H1 heading. Sometimes notices appear in the middle of the page content too.

The admin notices accessibility should be improved by other means, depending also whether they're PHP-generated notices that appear after a page load or JavaScript-generated ones that are "injected" into the DOM.

There are ways to improve accessibility for both cases, for example:

  • PHP: the notice text should be prepended to the document title, as that's the first thing screen readers announce after a page load
  • PHP: the notice text should be added to the main H1 heading as that's the part of the content with higher chances to be navigated to
  • JavaScript: notices injected in the DOM should have an aria role alert or status so that they're announced by screen readers
  • in any case, an admin notice should be visually prominent and appear within the current viewport for low vision users
  • etc.

All the above items are slightly outside the scope of this ticket though. Of course, I'd be glad to discuss further improvements and create separate tickets.

is it possible to link to (or create) a ticket or handbook page with what the penultimate design is for these types of notices?

I'd be very in favor of that. Any volunteer is very welcome :)

#35 follow-up: @johnjamesjacoby
8 weeks ago

Prefixes like "Error:" or "Warning:" don't add any semantics

Are semantics the priority? If so, there still does not appear to be any, nor is there a ticket to add them.

Prefixes provided at least some context where there is otherwise none.

There are ways to improve accessibility for both cases

Perhaps these ways are worth exploring, relatively quickly?

I'd be very in favor of that. Any volunteer is very welcome :)

It would be most impactful if trusted experts make these recommendations. I'm not claiming to be one here specifically.

All the above items are slightly outside the scope of this ticket though

I understand.


From this comment:

there's no need for the Error: prefix as it's redundant since it's already in an error notice

Unfortunately, it is not redundant for assistive technologies or to people with trouble interpreting colors due to a lack of context in the mark-up itself. These prefixes were all they had, and now they're gone.


Simply removing these strings probably should not be the end of the effort. Theoretically, the lives of the translations maintainers are marginally improved, without measured the negative impact for other audiences. (Heck... Maintainers still need to go through the extra effort of manually removing these prefixes from every single language dictionary anyways, so it's not like removing these prefixes makes less work.)

#36 @kebbet
8 weeks ago

The latest changeset from this ticket re-added the term webmaster, that this ticket changed: #50394

Edit: It is now fixed.

Last edited 7 weeks ago by SergeyBiryukov (previous) (diff)

#37 in reply to: ↑ 35 @afercia
7 weeks ago

Replying to johnjamesjacoby:

is it possible to link to (or create) a ticket or handbook page with what the penultimate design is for these types of notices?

I'd be very in favor of that. Any volunteer is very welcome :)

It would be most impactful if trusted experts make these recommendations. I'm not claiming to be one here specifically.

@johnjamesjacoby I do appreciate your feedback and I'm saying that genuinely. However, what I'd expect from a core contributor with great experience like you is to take action to make things better.

Instead, it sounds like you're asking others to implement your suggestions. I'm pretty sure you know better than me that we all have a very limited time and we just try to do our best. Pleased o feel free to take any action you feel appropriate to make things better.

That said, this ticket was created one year ago and since then has been discussed at least 5-6 times during the accessibility team bug-scrubs and meetings. I'll take charge to add again this issue to the next accessibility meeting agenda for further discussion.

#38 @johnjamesjacoby
7 weeks ago

what I'd expect from a core contributor with great experience like you is to take action to make things better

You don’t want this from me. The action I feel is correct to take is to revert, because I believe this change makes WordPress worse for an underrepresented subset of users in the contributor community. I also don’t want to be accused to white-knighting them, and I don’t want to come into a completed issue and boss people around.

I want to have a polite and respectful dialogue, not be bullied into finishing the job other people started because I happened to notice something potentially wrong that I don’t consider myself an expert on anymore, and cannot take the time to become one quickly anymore.

If I would do what you suggested I do, I’d similarly be told to stay in my lane because that’s the response I’ve gotten a hundred other times in the past.

it sounds like you're asking others to implement your suggestions

No. I’m politely suggesting the busy contributors who suggested this change consider the cost of it, since that does not appear to have happened in Trac. If it happened in Slack, well… that’s not linked here either, and not everyone can attended every meeting in person.

It’s wholly unfair to expect me to think you have good intentions when you think I have bad ones, of laziness or similar.

I'll take charge to add again this issue to the next accessibility meeting agenda for further discussion.

OK. Thanks!

This ticket was mentioned in Slack in #accessibility by nrqsnchz. View the logs.


7 weeks ago

#40 @sabernhardt
7 weeks ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

You can blame me for pushing to commit the latest set of changes without first making sure it was the best course of action.

In the accessibility meeting discussion, several attendees agreed that the error prefix can provide value. Some members suggested appending prefixes to more messages, at least any prefixes that convey specific additional meaning such as Error, Warning and/or Success. (Adding "Info" or "Note" is likely less valuable, as all of the messages are informational notifications.) Changes related to that may belong on this ticket, and they also could fit within the scope of the WP Notify project.

#41 @afercia
7 weeks ago

  • Keywords commit removed

If it happened in Slack, well… that’s not linked here either

I can count 5 links to mentions of this ticket in Slack before your last comment.

Regardless, as promised this ticket was discussed again during today's accessibility meeting. The prevalent opinion is to revert the commit.

Also, the team agreed that all the "Error" and "Warning" notices need respectively a "Error:" and "Warning:" prefix. In fact, the prevalent opinion about these two types of notices is that it's either a "remove prefixes everywhere" or "add prefixes everywhere".

The situation in core before this commit was greatly inconsistent and it is still inconsistent. Various Errors don't have a prefix, only a few Warnings have a prefix.

Worth also reminding most of the admin notices are just hardcoded HTML. It's understandable that the lack of standard, reusable, methods to get / print out admin notices in a so large project contributes to inconsistency over time.

Regarding the "Info" and "Success" notices there's no consensus yet.

Some in the team feel the arguments for Errors and Warnings should apply also to Info and Success, i.e.: add "Info:" and "Success:" prefixes everywhere. Others feel it wouldn't be necessary.

All the other considerations for better accessibility from comment:34 still apply. They should go in a separate ticket.

Thanks also to @sabernhardt who just beat me to reopen this ticket :)

#42 @afercia
7 weeks ago

Worth mentioning there's also some documentation to update, e.g.:

https://codex.wordpress.org/Plugin_API/Action_Reference/admin_notices
https://developer.wordpress.org/reference/hooks/admin_notices/

Please ad in a comment if you find more documentation that needs to be updated.

For reference: the current admin notices types were added in #27418.

Last edited 7 weeks ago by afercia (previous) (diff)

@afercia
7 weeks ago

#43 @afercia
7 weeks ago

47656.6.diff reverts [48059] and:

  • keeps the revised strings from comment:15 as it's an improvement
  • revises one more string to avoid using the word "error" twice in the same message

I'd appreciate some quick testing to verify I didn't miss anything.

@sabernhardt
7 weeks ago

Restoring the Error prefix for the 'site admin' message and removing an extra period from a 'site entry' message

#44 @sabernhardt
7 weeks ago

Thanks! After checking each of the strings in 47656.6.diff, I made two more changes in 47656.7.diff :

  1. Removing an extra period from <strong>Error</strong>: There was a problem creating site entry..
  2. Restoring the Error prefix for the site admin message in wp-includes/user.php: <strong>Error</strong>: Couldn&#8217;t register you&hellip; please contact the <a href="mailto:%s">site admin</a>!
Last edited 7 weeks ago by sabernhardt (previous) (diff)

#45 @afercia
7 weeks ago

@sabernhardt thanks!

#46 @afercia
7 weeks ago

  • Resolution set to fixed
  • Status changed from reopened to closed

In 48115:

I18N: Restore the "Error:" prefix for error messages.

Partially reverts [48059] as there's no full consensus on the removal of the text prefix. Further actions should be taken to improve consistency and accessibility of the admin notices. Keeps some improvements to the translatable strings from [48059].

Fixes #47656.

#47 @afercia
7 weeks ago

To summarize further actions that should go in a new ticket:

Accessibility improvements
At the very least (see comment:34):

  • PHP notices: the notice text, or maybe better some text that informs users there's a notice, should be prepended to the document title as that's the first thing screen readers announce after a page load
  • PHP notices: explore mechanisms to allow users to navigate to the notices, whether they're printed out close to the main H1 heading or in the middle of the page
  • JavaScript notices: notices injected in the DOM should have an aria role alert or status so that they're automatically announced by screen readers
  • In any case, an admin notice should be visually prominent and appear within the current viewport for low vision users

#48 @kebbet
7 weeks ago

I created a new ticket (#50442) for the first bit, but where is the screenshot you mention?

@afercia
7 weeks ago

Forgotten screenshot: Gutenberg notices

#49 @gziolo
7 weeks ago

In 48117:

Blocks: Add context fields to WP_Block_Type

New block context related fields were added as part of https://github.com/WordPress/gutenberg/pull/22686. This changest backports them to WP_Block_Type class.

Props aduth, spacedmonkey, mcsf, epiqueras.
Fixes #47656.

#50 @gziolo
7 weeks ago

I pasted a wrong ticket number in [48117], sorry about that.

#51 @SergeyBiryukov
7 weeks ago

For reference, #48529 appears to be the correct ticket for [48117].

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.


6 weeks ago

Note: See TracTickets for help on using tickets.