I18n for taxonomy labels

[nbachiyski]

When registering a taxonomy the developer can provide labels for the taxonomy, but because if the structural differences between languages they can't be used in longer phrases.

We need a list of the most common strings to be part of the registration process. Just like the way we did that for custom post types in #12968

[nbachiyski]

First pass at the patch.

[nacin]

Looks good overall.

I would call $ptype->label->parent_item something like parent_page_colon instead, just to better match the string and also to pair it with parent_item_colon on the taxonomy side.

Also, and I imagine this may be the same for post types in this patch, we need to ensure that label and singular_label still work. If those are set, they need to be used inside the labels object. I imagine that singular_label should inherit a value from label as long as the latter is set.

For taxonomies especially, label has existed since 2.5. we added singular_label to both, so if we want to eliminate that now (like I did with the capabilities, added now), then we should do so. Otherwise, you know as well as I do that we won't end up removing these in 3.1 :-)

[nbachiyski]

Replying to nacin:

...
I would call $ptype->label->parent_item something like parent_page_colon instead, just to better match the string and also to pair it with parent_item_colon on the taxonomy side.

I don't like page in the key name. But I changed it to parent_item_colon to better match the taxonomy.

Also, and I imagine this may be the same for post types in this patch, we need to ensure that label and singular_label still work. If those are set, they need to be used inside the labels object. I imagine that singular_label should inherit a value from label as long as the latter is set.

That's exactly what I do. See _get_custom_object_labels()

For taxonomies especially, label has existed since 2.5. we added singular_label to both, so if we want to eliminate that now (like I did with the capabilities, added now), then we should do so. Otherwise, you know as well as I do that we won't end up removing these in 3.1 :-)

Challenge accepted :-) They will be removed in 3.1.

[nbachiyski]

(In [14614]) I18n for custom taxonomies. Fixes #13357

[nacin]

I'm against removing label. That should stay as a way to register a simple post type, and everything else should inherit from there (based on hierarchical/non-hierarchical). Especially since it has existed for some time.

That said, *now* would be the time to kill off singular_label. It will otherwise appear (and already has appeared) in nearly every 3.0 custom post type tutorial, and will be impossible to remove.

[nbachiyski]

Do you think many people will want to define only name and don't touch any of the other labels? Since these are only a couple of strings, I, myself, would define them all even for a simple post type or taxonomy.

If really you think keeping label will be useful, you should mention it in the phpdoc and make it official.

We can contact tutorial authors to change them. It's not so deeply carved in stone. We can also issue a deprecated warning and let developers know there is a new way of doing it.

I agree about singular_label. I will remove it.

[nacin]

Well, for taxonomies, that's all you could do until now. You'd otherwise get the strings for tags everywhere. And it wasn't really bothersome -- especially with nonhierarchical taxonomies, "tag" isn't that big of a deal.

Label has been around for so long (register_taxonomy was 2.5), I don't see a problem with syncing them, especially since it allows for the quick-and-dirty approach.

So long, singular_label.

[nacin]

[14619]

[dimadin]

I found one more use which isn't covered by this fixes. In wp-admin/includes/meta-boxes.php on line 250, there is a string "Choose from the most used tags in %s", where %s is replaced with taxonomy name ("Post Tags" by default).

[ryan]

(In [14748]) Don't subsitute a translated string into a translated string. Props dimadin. fixes #13357