Alert message, "No tags found!" cannot be set for a non-hierarchical custom taxonomy.

[alexmansfield]

I think the easiest way to explain this will be by stepping through the process I used to find this bug.

1. Create a new non-hierarchical taxonomy (non-hierarchical just means they function like tags, not categories). For the sake of argument, let's say this taxonomy applies to posts.

2. Go view a post in the admin (or create a new post). The meta box for the bew taxonomy is displayed and contains an input box for creating items in this taxonomy, a message about separating multiple items with commas, and a link to view the most used items in the taxonomy. The text for this link can be set when creating a custom taxonomy, which is great!

3. Click the link to display the most used items in this taxonomy. Typically this displays a tag cloud of the most used items. However, if no items have been saved yet, it instead displays the message: "No tags found!"

The text for this message cannot be set when creating a custom taxonomy. Regardless of the taxonomy name, the word "tags" is used.

I've attached an image of a custom taxonomy called "Classifications" where the "tags" message is still in use.

This message is defined on line 654 of the wp-admin/includes/ajax-actions.php file (at least it is in WordPress 3.5.1).

Since this isn't in the same file as the rest of the labels that can be set when creating a taxonomy, I'm not sure how to go about making it editable. Maybe just change the text from "No tags found!" to "None found!" I can't say it's the greatest solution, but at least it wouldn't say the word "tags" when the taxonomy isn't actually "tags".

Any thoughts?

[alexmansfield]

Example of the "No tags found!" message that cannot be re-labeled for custom taxonomies.

[SergeyBiryukov]

Although it's not documented anywhere as far as I can see, it's actually possible to customize the string by adding no_tagcloud parameter to your register_taxonomy() call (see [13538]):

register_taxonomy( 'classification', 'post', array(
	...
	'no_tagcloud' => __( 'No classifications found!', 'your-textdomain' ),
) );

Seems like the string was missed in [15190], so it didn't make it into the labels array. I guess we should move it there. We could also change the default to "No items found" or "No terms found".

[thee17]

Or the default could be "No (taxonomy name) found." Although I'm not sure if that would cause i18n or l10n issues.

[DrewAPicture]

23597.diff​ adds no_tagcloud to the labels array as "No terms found."

[SergeyBiryukov]

Replying to thee17:

Or the default could be "No (taxonomy name) found." Although I'm not sure if that would cause i18n or l10n issues.

It would, see dd32's comment for why we're trying to avoid post type and taxonomy names in generic strings.

[SergeyBiryukov]

23597.2.diff​ is basically a follow-up to [15190].

It keeps the current string for consistency, since the other default strings in get_taxonomy_labels() also refer to tags.

[DrewAPicture]

Replying to SergeyBiryukov:

23597.2.diff​ is basically a follow-up to [15190].

It keeps the current string for consistency, since the other default strings in get_taxonomy_labels() also refer to tags.

Oh right. And since it's now in the labels array it's overrideable.

[SergeyBiryukov]

In 23483:

Move 'no_tagcloud' argument to the taxonomy labels object. props DrewAPicture for initial patch. fixes #23597.

[DrewAPicture]

Labels array parameter updated with no_tagcloud entry. See: ​http://codex.wordpress.org/Function_Reference/register_taxonomy#Arguments

[nacin]

As done in [15190], can we rename this so the label key matches the value?

Normally I would say no_items_found, but in this case, not_found probably makes more sense, to be parallel with register_post_type().

[SergeyBiryukov]

In 23484:

Rename 'no_tagcloud' taxonomy label to 'not_found', for consistency with the post type label of the same key. fixes #23597.

[SergeyBiryukov]

Updated the Codex page: ​http://codex.wordpress.org/index.php?title=Function_Reference/register_taxonomy&diff=127781&oldid=127780