WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#12968 closed defect (bug) (fixed)

I18n-friendly strings for the new system of post types

Reported by: demetris Owned by: nbachiyski
Milestone: 3.0 Priority: normal
Severity: blocker Version: 3.0
Component: I18N Keywords: ux-feedback
Focuses: Cc:

Description

In the new system of post types, which is also used by core for registering the default post types, UI strings for the types are constructed with fprint, and are of the form Edit %s, Add New %s, etc.

In fact, this is the only possible way at the moment, since the only language/string information a post type provides upon registration is the singular and plural form of its label, singular_label and label. But this does not work for i18n, since even simple phrases like “Edit Posts” can have many structural differences across languages: word order, parts of speech, grammatical genders, grammatical cases, etc.

An obvious solution would be to have post types specify full strings for their labels. Supposing we’ll go with this solution, here are some ideas for arguments to get us started, based on some names ryan suggested in the long ticket for custom post types (#9674).

  • add_new_label (for the edit screen, it would take values like “Add new Post”, or “Add new Book Review”)
  • add_new_label_short (for the menu on the left)
  • edit_label
  • edit_label_plural

And some more:

  • delete_label (for sending to the bin)
  • delete_label_perm (for obliterating from the bin)
  • restore_label (for restoring from the bin)

Attachments (2)

wp30-20100429-post-tax-strings.txt (45.4 KB) - added by demetris 4 years ago.
Post type and taxonomy strings in WP v3.0 as of 30 April 2010
post-types-i18n.diff (26.0 KB) - added by nbachiyski 4 years ago.

Download all attachments as: .zip

Change History (34)

comment:1 ryan4 years ago

Indeed. I was thinking similarly: menu_label, add_new_label, add_new_label_plural, edit_label, edit_label_plural, etc.

comment:2 nacin4 years ago

Yeah, this is something we have to tackle for taxonomies too.

I guess we need to compile a list of actual labels currently used, then create the post object properties and register them for posts, pages, tags, and categories, then start replacing.

comment:3 nacin4 years ago

Closed #12697 as a duplicate. We also have to use the new strings in the nav menu UI.

comment:4 demetris4 years ago

Question that arises as I look at the post-type strings and at the custom taxonomies stuff:

What will the extra needed args/strings default to?

Now label (plural) defaults to $post_type, and then singular_label defaults to label. But that cannot work for strings of two or more words.

We can make all such strings required, or maybe we can introduce generic strings for defaults.

E.g., for taxonomies:

  • Add new term
  • Update term

And for post types:

  • Edit items or Edit articles
  • Add new item or Add new article

Or probably there is another, better solution?

comment:5 demetris4 years ago

Here is a list of current and obsolete strings for post types and for taxonomies, along with arguments that would replace them.

I will be updating the list as necessary (it is not exhaustive yet).

Also, I do not pay much attention to args nomenclature for now. I just want to understand what are the strings that need to become arguments upon registration.

POST TYPES

  • Add New › add_label_short or menu_add_label
  • Add New %s › add_label
  • Create Menu › add_label
  • Delete Menu › delete_label
  • Delete this page permanently › delete_label_perm
  • Delete this post permanently › delete_label_perm
  • Edit %s › edit_label_plural
  • Edit this page › edit_label
  • Edit this post › edit_label
  • Edit this post inline › edit_label_inline
  • Move this page to the Trash › delete_label
  • Move this post to the Trash › delete_label
  • New %s › add_label_short
  • Parent Page › label_parent (for hierarchical post types)
  • Remove this page from the Trash › restore_label or undelete_label
  • Restore this post from the Trash › restore_label or undelete_label
  • Save Menu › save_label
  • Search %s › search_label_plural

TAXONOMIES

  • Add %s › add_tax_short or menu_add_tax
  • Add a New %s › add_tax
  • Edit %s › edit_tax
  • Parent %s › tax_parent (for hierarchical taxonomies)
  • Popular %s › tax_popular_plural
  • Update %s › update_tax


MORE TAXONOMIES STUFF

  • + Add New %s
  • Choose from the most used tags in %s
  • All %s

comment:6 nacin4 years ago

Great work on this!

Let's leave Save Menu, Create Menu, and Delete Menu as is. Those are part of an admin UI that isn't going anywhere. Also, I imagine "Create Menu" will be preferred over "Add Menu."

Maybe we should register labels as part of an array (like we do with supports). I think we should also do label_*, versus *_label. We should also stick as close as possible to their actual default text, i.e. label_new_post for New % and label_edit_posts for Edit %. For longer ones, we can do label_restore_post_trash or label_restore_from_trash etc.

There are some other quirky tax labels in admin-ajax and possibly elsewhere, to allow full customization of the non-hier metabox.

comment:7 follow-up: nacin4 years ago

Also, I think we should default to the same strings used for 'post' and 'tag', as we more or less do now. I think 'item' is lame, 'term' less so.

Random thought, there's also a giant chunk of strings that spits out messages on edit.php.

comment:8 nacin4 years ago

These were the strings I was referring to: [13538].

comment:9 nacin4 years ago

I closed #12701 as a duplicate. Let's make sure we hit the favorites menu here as well.

comment:10 in reply to: ↑ 7 demetris4 years ago

Replying to nacin:

Also, I think we should default to the same strings used for 'post' and 'tag', as we more or less do now. I think 'item' is lame, 'term' less so.

Now that I’m thinking about that again, if we could use Page strings as defaults for hierarchical post types, and Post strings for non-hierchical ones, it would be perfect.

“tag” is not as generic to be ideal for defaults/fallbacks, but it will have to do, since it’s what we have available.

About the nomenclature:

Maybe we could simplify even more, and not use both label and post in the arg names. That is, maybe we could use:

  • edit_post
  • edit_posts or edit_post_plural
  • add_post
  • etc.

I’ll have another look at existing strings (and at the ones you linked to) and I’ll update the list in the next 24 hours.

comment:11 dimadin4 years ago

  • Cc dimadin added

Here are strings I found that are not on list above.

Post types:
No %s found in the Trash.
No %s found.
View %s

Taxonomies:
— Parent %s —

Also for
Mine <span class="\&quot;count\&quot;">(%s)</span>
should be disclosed that it could be any post type, not just posts.

comment:12 nacin4 years ago

  • Status changed from new to assigned

Nikolay has been working on a way to implement this. I believe the current idea is $post_type_object->labels['edit_post'].

We'll probably see this happen during the second code sprint day Tuesday. Assigning to him, he'll probably handle the commit as well.

comment:13 demetris4 years ago

Meanwhile, I have collected every current and obsolete string that has something to do with post types and taxonomies (and a few that have nothing to do).

See attached file.

(The number of strings is much smaller that the attachment size might suggest.)

demetris4 years ago

Post type and taxonomy strings in WP v3.0 as of 30 April 2010

comment:14 nbachiyski4 years ago

  • Status changed from assigned to accepted

comment:15 follow-up: nbachiyski4 years ago

Wow, that's a pretty long list.

There is no way we will add all of those in the register_post_type() arguments list.

We will leave most of them like this for now and just change those, which depend directly on post type.

In the next version we should rewrite them to use a neutral subject. Like an item or a thing. We can't do this 2 weeks before a release.

comment:16 in reply to: ↑ 15 demetris4 years ago

Replying to nbachiyski:

Wow, that's a pretty long list.

There is no way we will add all of those in the register_post_type() arguments list.

I realized that while I was compiling the complete list. :-) I did not expect there would be so many of them!

For future reference, and regardless of how we solve this for 3.0, I think it would be good if we could avoid the introduction of neutral terms. I think the basic distinction we have now is worth preserving: Posts for stuff in reverse chronology, and Pages for hierarchical stuff.

comment:17 pavelevap4 years ago

  • Cc pavelevap@… added

Hi, I have similar problem (http://core.trac.wordpress.org/ticket/13299):

String "Add New" and combination with string "Category". No chance to achieve right format in Czech. Example: "Add New" can be "Vytvořit nový" or "Vytvořit novou" etc. It depends on the other word. "Category" is in Czech "Rubrika", but the right is "Vytvořit novou rubriku" and not "Vytvořit nová Rubrika" (it is nonsense). It is not good idea to join words for translators, there will be many similar problems (in Czech there is special inflexion and it is not possible to translate it). Other example are strings "All" (Czech "Všechny") and "Categories" (Czech "Rubriky"). In combination I need "Všechny rubriky" and not "Všechny Rubriky" (nonsense). But in other case I also need "Rubriky" with first capital letter...

It is not possible to find the right solution for me (I tried some combinations)... It is priority for many languages, I guess...

comment:18 nbachiyski4 years ago

  • Keywords has-patch dev-feedback added; needs-patch removed

comment:19 nbachiyski4 years ago

Here is the first part of the patch. It covers post types.

Next are taxonomies and statuses.

comment:20 follow-up: nacin4 years ago

I'd rather go with add_new and add_new_item (or add_new_post), instead of the corresponding add_new_bare and add_new. It's more obvious for both core and plugin developers when the key is as close to the string as possible. We've already had some bugs caused by confusion among the different cap checks.

Additionally:
We need to keep label for compat. We may want to keep singular_label as well. Simply populate them with the same values after running the helper function?

Does it make sense to group the capability checks as well? I really like that idea (->cap->edit_post, ->cap->edit_posts), and nothing is stopping us from again creating the back compat properties and just letting them sit here.

How much are we backing ourselves into a corner by adopting special strings everywhere? Does it hurt us when we want/need to change strings in the future?

comment:21 in reply to: ↑ 20 nbachiyski4 years ago

Replying to nacin:

I'd rather go with add_new and add_new_item (or add_new_post), instead of the corresponding add_new_bare and add_new. It's more obvious for both core and plugin developers when the key is as close to the string as possible. We've already had some bugs caused by confusion among the different cap checks.

I agree. Fell free to change them :-)

Additionally:
We need to keep label for compat. We may want to keep singular_label as well. Simply populate them with the same values after running the helper function?

Yes, we should populate them. I thought we were introducing these in 3.0 and we had nothing to be compatible with. Thinking is bad.

Does it make sense to group the capability checks as well? I really like that idea (->cap->edit_post, ->cap->edit_posts), and nothing is stopping us from again creating the back compat properties and just letting them sit here.

I like groupings, too.

How much are we backing ourselves into a corner by adopting special strings everywhere? Does it hurt us when we want/need to change strings in the future?

Change of those strings is expensive, because even a minor change in string format or adding a new string has to be communicated with plugin devs and they will need to change their code.

That's why I tried to limit the number strings we expose via this interface. In the future, only the most common ones should go there. Having post/page in the less frequently used strings is fine.

nbachiyski4 years ago

comment:22 nbachiyski4 years ago

Here is a patch, updated with nacin's notes.

comment:23 nbachiyski4 years ago

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

(In [14571]) I18n for custom post type labels. Props demetris, dimadin. Fixes #12968

comment:24 nbachiyski4 years ago

The commit adds documentation, which should soon appear at http://phpdoc.wordpress.org/trunk/WordPress/Post/_wp-includes---post.php.html#functionregister_post_type

There is another ticket for doing the same with taxonomies: #13357

comment:25 nacin4 years ago

Related for capabilities: #13358

comment:26 demetris4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Nikolay, I think we need one more string in the default array, for the edit.php screen:

edit_items / that is, a plural version of edit_item, defaulting to Edit Posts and Edit Pages

(Now the edit.php screen uses $post_type_object->labels->edit_item.)

I can submit a patch for that.

comment:27 demetris4 years ago

  • Keywords has-patch removed

comment:28 nacin4 years ago

  • Keywords ux-feedback added; dev-feedback removed

Actually, we can probably convert that over to labels->name, see #11274.

comment:29 nacin4 years ago

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

(In [14616]) Use 'Posts', 'Pages', and corresponding custom post type names as the edit.php title. fixes #12968, fixes #11274.

comment:30 demetris4 years ago

  • Keywords dev-feedback added
  • Resolution fixed deleted
  • Status changed from closed to reopened

I am not happy with the new titles of edit.php, for two reasons:

First, I believe that such prominent UI strings should not change unless there is a very good reason (which does not exist in this case).

Second, the new titles introduce unneeded and maybe confusing variety. What I mean: The menu subitem that sends you there is titled Edit. The screens for individual pages/posts are titled Edit Post and Edit Page. But the edit.php screens, which do the same thing but for more than one posts/pages, are now named just Posts and Pages.

comment:31 nacin4 years ago

  • Keywords dev-feedback removed
  • Resolution set to fixed
  • Status changed from reopened to closed

Re-open #11274 then.

comment:32 nacin4 years ago

(In [14857]) Remove now-unused post_type_object->labels>edit, which was 'Edit' (with context). see #12968, see #11274.

Note: See TracTickets for help on using tickets.