Simplify add_new_item labels for core post types

[jameskoster]

If "new" is removed from the add_new_item string for core post types then button labels can be shortened, and title case (which is inconsistent with Gutenberg buttons) sidestepped.

• "Add New Post" → "Add Post"
• "Add New Page" → "Add Page"
• "Add New User" → "Add User"
• "Add New Theme" → "Add Theme"
• And so on.

It's most problematic in the Site Editor where labels like "Add New Template Part" feel unnecessarily verbose.

What do y'all think?

[audrasjb]

Just adding my two cents: on fr_FR as well as in several other locales, we decided a bunch of years ago to strip the notion of "new" in our translation.

Example: Instead of Ajouter une nouvelle page for Add new page we have Ajouter une page which works very well and is also less verbose. People probably understand that when they "add" a post or a user this will probably be a new one 🙂

Conclusion: this is a +1 on my side.
Not sure if this will work for our en_US fellow contributors BTW 😊

[sabernhardt]

Related: #47125, GB53984

Trac ticket: https://core.trac.wordpress.org/ticket/61219

If "new" is removed from the add_new_item string for core post types then button labels can be shortened, and title case (which is inconsistent with Gutenberg buttons) sidestepped.

"Add New Post" → "Add Post"
"Add New Page" → "Add Page"
"Add New User" → "Add User"
"Add New Theme" → "Add Theme"
And so on.

It's most problematic in the Site Editor where labels like "Add New Template Part" feel unnecessarily verbose.

Description is from the ticket.

[afercia]

and title case (which is inconsistent with Gutenberg buttons) sidestepped.

Regarding the casing, I would say it's Gutenberg that is inconsistent with Core. This was previously raised in the Gutenberg repository, see ​https://github.com/WordPress/gutenberg/issues/53984

Regarding removing 'new' I have no strong opinions. However, it's not just about post type labels. Such a change should be done for all the WordPress objects (tazonomies, users, etc.) labels that contain 'new'. For example:

• 'Add New Tag'
• 'Add New Category'
• 'Add New Link Category'
• 'Add New Link'
• 'Add New Plugin'
• 'Add New Theme'
• 'Add New User' / 'Add New Users'
• 'Add New Site'
• 'Add New Comment'
• 'Add New Header Image'
• 'Add New Image'
• Any other label I may be missing.

There is also the 'new_item' label e.g. in the admin bar on multisite and I guess other palces, which is for example:

• 'New Post'
• 'New Changeset'
• 'New Template'

This label should be updated as well for consistency. I'm not sure it would be great to have the UI sometimes show 'Add Template' and sometimes 'New Template'.

It is also worth considering a change like this would impact custom post types / taxonomies added by plugins. All extenders should be informed to update their labels but in the meantime users would likely see a mixed pattern in the UI e.g. 'Add Post', 'Add Page', 'Add New Product', 'Add New Book', etc.

This LGTM. I saw that we have three similar labels for taxonomies too. I wonder if we should align these as well.

[afercia]

To get an idea of how post types / taxonomies labels changes may impact plugins, see #60045.
That's specific to the change introduced in #47125 in the scenario where custom posts omit one of the labels. In that case, WordPress will use the default labels which include the words 'Post' and 'Page'.
This is not to say I'm opposed to this proposed change. However, labels changes should be carefully considered.

More importantly, if we go with removing 'new' I would like to see this change made consistently throughout the entire codebase. It's not just about post type labels There's way more to change.

I agree with @afercia that if this change is to be made it ought to be done throughout the code base: add new plugin, add new theme and even the very well hidden add new link.

I think this and ​https://github.com/WordPress/gutenberg/issues/53984 can be solved independently and if anything the upstream ticket is actually an issue in WordPress-Develop if the strings aren't making it through to the editor interface.

Agreed about consistency and making this change everywhere. I've update lots of files and hopefully haven't missed anything.

[joedolson]

In the Accessibility bug scrub today, we agreed that this would be a good change and worth making for 6.7. Milestoning. We'll need to take some time to ensure consistency, e.g. make sure that the add item string for action links and 'new_item' is only used for labeling, but overall this results in simplification and removes a redundancy in the admin.

[davidbaumwald]

With 6.7 Beta 1 releasing in a few hours, this is being moved to 6.8 given a lack of recent momentum towards a resolution.

If any committer feels the remaining work can be resolved in time for Beta 1 or any other specific milestone and wishes to assume ownership during that cycle, feel free to update the milestone accordingly.