[wp-trac] [WordPress Trac] #50442: Add prefixes to all admin notices (Warning, Error, Success, Info)

[WordPress Trac]

#50442: Add prefixes to all admin notices (Warning, Error, Success, Info)
----------------------------+-----------------------------------------
 Reporter:  kebbet          |       Owner:  joedolson
     Type:  enhancement     |      Status:  accepted
 Priority:  normal          |   Milestone:  6.5
Component:  Administration  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:                  |     Focuses:  ui, accessibility, ui-copy
----------------------------+-----------------------------------------

Comment (by costdev):

 Thanks for the ping @joedolson!

 To what extent should we consider extenders who may make use of these
 functions in 6.4?

 - If they already prefix their notices with an appropriate or preferred
 string, forcing Core's own may be akin to a regression/BC
 break/inconvenience.
 - For extenders who transfer to the new functions, they may use the same
 (translated) strings they previously used with hardcoded HTML. If those
 strings already contain a prefix and the extender feels they should now
 remove their prefix as Core enforces one, their translations will also
 need to be updated.
 - Checking for existing prefixes is likely to be unreliable and an
 unnecessary (albeit, tiny) performance hit.
 - Core could instead enforce its own rule for prefixing `$message`
 parameters passed in Core.
 - The previous point is the reason why I didn't suggest adding a `(string)
 $prefix` key to `$args`.

 To be clear though, I personally like the idea of abstracting this to
 `wp_get_admin_notice()`. The functions were created to benefit exactly
 this type of ticket. There are unlikely to be many notices requiring
 translation in the first place, and the markup is filterable if someone
 really doesn't like them.

 I mentioned the above points because I think our thoughts about at least
 some of these should be documented on this ticket.

 -----

 Regarding whether to prefix all notice types:

 IMO, it's good for users to get the context of the notice right away -
 That's why we use colours. As these can't be utilized by all users, the
 prefixes should increase accessibility, and that's the main reason I think
 prefixing all notice types makes sense.

 -----
 > Combine strings constructed like `__('Error:') . __('any string')` into
 one string for better context for translators

 This is where the use of the functions becomes problematic. The combined
 strings would be provided via the `$message` parameter, and therefore
 couldn't be standardized within the function. Thoughts @joedolson? How
 important do you think this addition is @kebbet?

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/50442#comment:6>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform