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.

[joedolson]

Because of the scope of changes, this needs to be early.

[audrasjb]

as per accessibility team bug scrub, adding early keyword

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

Hello @Sukhendu2002, thanks for the patch! Is it ready for review? If so, could you please remove the Draft status? Thanks :)

This looks good to me, thanks @Sukhendu2002!
Note: The PHPUnit tests failure looks like an error (probably a timeout).
Pinging @SergeyBiryukov for 2nd review (as he is a both a committer and a GTE/Locale Manager.

[jdy68]

It's a great way to simplify the interface.

[beryldlg]

I totally agree to get rid of this unnecessarily verbose.

[fxbenard]

Good idea to remove this unnecessary "new" word

[audrasjb]

In 59784:

Administration: Replace "Add New {Item}" wording with "Add {Item}" across the administration.

This changeset replaces each occurrence of "Add New {Item}" label with "Add {Item}" in WordPress administration, to make the interface more consistent and simplify the translation effort.

Props jameskoster, audrasjb, ntsekouras, afercia, peterwilsoncc, youknowriad, joedolson, sukhendu2002, jdy68, beryldlg, fxbenard.
See #61219.

[audrasjb]

In 59786:

Bundled Themes: Replace references to "Add New" theme screen in bundled themes readme files.

Follow-up to [59784].

Props jameskoster, audrasjb, ntsekouras, afercia, peterwilsoncc, youknowriad, joedolson, sukhendu2002, jdy68, beryldlg, fxbenard.
Fixes #61219.

[audrasjb]

Reopening as I found some missed occurrences of "Add New". I have a PR ready to fix them.

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

[audrasjb]

In 59791:

Administration: Replace missed references of "Add New" in WP_Post_Type class.

Follow-up to [59784], [59786].

Fixes #61219.

[wildworks]

I want to let you know that this change affects not only the admin area but also Gutenberg.

See ​https://github.com/WordPress/gutenberg/pull/69111 for more details.

[timse201]

@audrasjb The new label is not set for "add (new) category".

/wp-admin/edit-tags.php?taxonomy=category

[audrasjb]

Thanks for spotting this @timse201!
Reopening to address this occurrence :)

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

[timse201]

thank you @audrasjb

[audrasjb]

In 60098:

Administration: Replace missed reference of "Add New" in WP_taxonomy class.

Follow-up to [59784], [59786], [59791].

Props timse201, audrasjb.
Fixes #61219.

[audrasjb]

Reopening for backport to branch 6.8.

[joedolson]

Reviewed. Looks good for backport.

[audrasjb]

In 60099:

Administration: Replace missed reference of "Add New" in WP_Taxonomy class.

Follow-up to [59784], [59786], [59791].

Reviewed by joedolson.
Merges [60098] to 6.8 branch.
Props timse201, audrasjb.
Fixes #61219.

[sitebolts]

#63293 was marked as a duplicate.

[sitebolts]

Hi all, a few thoughts/questions here:

1. Is it still possible to use separate custom wording on the menu item and page title? For a custom post type like "Location", we'd like to set ​the menu item to "Add New" to keep it short, but then display the full "Add New Location" on ​the editing screen.

Our assumption would be that the add_new arg would set one and the add_new_item arg would set the other, but it appears that the add_new arg is now completely ignored and that the add_new_item arg is instead outputted in both locations, leaving us unable to fully customize the wording.

2. The ​register_post_type documentation still mentions both 'add_new' and 'add_new_item' and appears to suggest using them in roughly the way that we were hoping to use them. Is that documentation no longer correct?

[Presskopp]

post moved, see https://core.trac.wordpress.org/ticket/63293#comment:8

[sabernhardt]

Please continue discussion on the new ticket, #63293.