Review all the 'Add New' strings

[afercia]

Description

In WordPress core, there is a well established pattern where all the 'Add New' strings use title case, for example:

__( 'Add New Post' )
__( 'Add New Page' )
__( 'Add New Template' )

In the editor the situation is mixed. Sometimes it's title case, somtimes it's not. For example, even on the same line of code, this string uses inconsistent casing:

( slug === 'post_tag' ? __( 'Add new tag' ) : __( 'Add new Term' ) );

I'd think all these strings should be consistent with what Core does since ages and always use title case. Worth running a search through the entire code base and update all the inconsistent occurrences, where necessary.

See also on Core Trac:
https://core.trac.wordpress.org/ticket/47125
https://core.trac.wordpress.org/ticket/58577#comment:11

I'm not sure there is a good reason why tag should be lowercase while Term is title case. Also, the word new should always be title case.

Step-by-step reproduction instructions

• Run a case insensitive search in the codebase for all the strings that start with Add new.
• Observe the casing inconsistencies in your search results.

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[jamestitus299]

Do you believe this inconsistent pattern can be an issue for future developers?
Should all the 'Add New' strings use title case?

[xerpa43]

So the changes are to be made like this : Add new tag to " Add New Tag"

[alexstine]

Reviewed the PR and left suggestions. Its close.

[xerpa43]

ok, so the issue is solved, I guess.

[jamestitus299]

Yeah.

[afercia]

Quickly noting that this change in WordPress core https://core.trac.wordpress.org/changeset/56515 aligned all the existing 'Add New' strings with the editor by adding context in the text itseld. So for example the existing string in core:

_x( 'Add New', 'post' )

had been changed to:

__( 'Add New Post' )

That aligns with thte efitor, where there are no occurrences of just Add New and the text is always more specific instead.
See https://core.trac.wordpress.org/ticket/47125

[peterwilsoncc]

How present is this bug in practice.

Looking at the associated pull request it seems that the editor pulls in the labels as defined when registering post types and taxonomies, which is good, so are the default strings ever actually used?

If they are, it seems to be a WordPress-Develop bug in which the labels are not being defined correctly causing the editor to duplicate strings unnecessarily. Is this something that needs fixing in WP-Dev so Gutenberg doesn't need to maintain a set of fallbacks? IE, outside of WordPress/wordpress-develop#6585

[afercia]

Looking at the associated pull request it seems that the editor pulls in the labels as defined when registering post types and taxonomies, which is good, so are the default strings ever actually used?

@peterwilsoncc this issue description includes an example, where you can see the editor sometimes uses its own strings instead of pulling them in from core. I have no idea why. Usign the core strings would avoid inconsistencies, of course.

[peterwilsoncc]

@afercia Yeah, I saw that but the editor will only use it's own strings if they are registered in core as null. I could only get to the Gutenberg strings with the following change to WP-Dev.

diff --git a/src/wp-includes/class-wp-taxonomy.php b/src/wp-includes/class-wp-taxonomy.php
index 254ea6a15c..60572db868 100644
--- a/src/wp-includes/class-wp-taxonomy.php
+++ b/src/wp-includes/class-wp-taxonomy.php
@@ -624,7 +624,7 @@ final class WP_Taxonomy {
 			'edit_item'                  => array( __( 'Edit Tag' ), __( 'Edit Category' ) ),
 			'view_item'                  => array( __( 'View Tag' ), __( 'View Category' ) ),
 			'update_item'                => array( __( 'Update Tag' ), __( 'Update Category' ) ),
-			'add_new_item'               => array( __( 'Add New Tag' ), __( 'Add New Category' ) ),
+			'add_new_item'               => array( null, null ),
 			'new_item_name'              => array( __( 'New Tag Name' ), __( 'New Category Name' ) ),
 			'separate_items_with_commas' => array( __( 'Separate tags with commas' ), null ),
 			'add_or_remove_items'        => array( __( 'Add or remove tags' ), null ),

Such a case seems like something that should be handled in WP-Dev so that the editor can use const newTermLabel = taxonomy?.labels?.add_new_item ?? '';. Resolving it Wp-Dev would help avoid the issue recurring in Gutenberg.