I18n-friendly strings for the new system of post types

[demetris]

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)

[ryan]

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

[nacin]

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.

[nacin]

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

[demetris]

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?

[demetris]

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

[nacin]

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.

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

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

[nacin]

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

[nacin]

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

[demetris]

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.

[dimadin]

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.

[nacin]

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.

[demetris]

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

[demetris]

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

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

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.

[demetris]

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.

[pavelevap]

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

[nbachiyski]

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

Next are taxonomies and statuses.

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

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?

[nbachiyski]

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.

[nbachiyski]

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

[nbachiyski]

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

[nbachiyski]

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

[nacin]

Related for capabilities: #13358

[demetris]

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.

[nacin]

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

[nacin]

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

[demetris]

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.

[nacin]

Re-open #11274 then.

[nacin]

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