WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#13357 closed defect (bug) (fixed)

I18n for taxonomy labels

Reported by: nbachiyski Owned by: nbachiyski
Milestone: 3.0 Priority: normal
Severity: blocker Version:
Component: I18N Keywords: has-patch commit
Focuses: Cc:

Description

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

Attachments (1)

i18n-for-taxonomies.diff (29.6 KB) - added by nbachiyski 5 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 @nbachiyski5 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed
  • Status changed from new to accepted

First pass at the patch.

comment:2 follow-up: @nacin5 years ago

  • Keywords commit added; dev-feedback removed
  • Status changed from accepted to assigned

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 :-)

comment:3 in reply to: ↑ 2 @nbachiyski5 years ago

  • Status changed from assigned to accepted

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.

comment:4 @nbachiyski5 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:5 @nacin5 years ago

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.

comment:6 @nbachiyski5 years ago

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.

comment:7 @nacin5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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.

comment:8 @nacin5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

comment:9 @dimadin5 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

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).

comment:10 @ryan5 years ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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

Note: See TracTickets for help on using tickets.