Provide a context for post statuses

[xibe]

1) /wp-admin/nav-menus.php: the "Most Recent" string (/wp-admin/includes/nav-menu.php:645) should be separated between the Pages context and the Articles context, since they can take different forms according to the language (i.e.: in French, "Articles" is masculine, "Pages" is feminine.

2) /wp-admin/edit.php: Same contextual need for "All", "Published", "Scheduled" and the rest of the per-status selector, for posts and articles (and others...).

[RanYanivHartstein]

+1 for this, the need exists for the Hebrew translation as well.

[westi]

Both of these improvement require a fair few changes.

The strings for the Post Statuses have context of "Post" but get used for all Post Types.

Marking as a 3.2 candidate

[xibe]

Still an issue in 3.4-alpha.

[chriscct7]

Still a valid issue in 4.0

[cfoellmann]

A list of affected strings in context must be compiled by multiple people speaking different languages presenting these "irregularities"

[xibe]

In current trunk (targetting 4.1), the "Most recent" string has moved to https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/nav-menu.php#L692
"View All" could also use some contextualization: https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/nav-menu.php#L697

As for the "All", "Published", "Scheduled" and other post statuses, they are of course spread on several files:
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/ajax.actions.php
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-posts-list-table.php
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/meta-boxes.php
https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/post.php

(can't update the Version ticket property anymore, sad)

[johnbillion]

The version field indicates the first version in which the issue was present.

[iworks]

It should be like this:

switch( $post_type_name ) {
   case 'post':
       _ex( 'Most Recent', 'post' );
       break;
   case 'page':
       _ex( 'Most Recent', 'page' );
       break;
   default:
       _e( 'Most Recent' );
       break;
}

or can be like this:

_ex( 'Most Recent', $post_type_name );

[ocean90]

Replying to iworks:

or can be like this:

_ex( 'Most Recent', $post_type_name );

No, variables are not supported as a context parameter.

[iworks]

Replying to ocean90:

Replying to iworks:

or can be like this:

_ex( 'Most Recent', $post_type_name );

No, variables are not supported as a context parameter.

I expected this answer ;-)

[swissspidy]

Since variables are not supported for context and the labels are indeed different for different post types (as noted by OP), what about adding this to get_post_type_labels()?

[fxbenard]

Bump it up. Time to solve it. A 5 year old ticket ;)

[xibe]

Replying to ocean90: Thank you, it is indeed much clearer this way :)

[rockwell15]

Patch for #14981

[swissspidy]

Thanks for the patch, @rockwell15!

Just note that not only the post statuses should be post type labels, but also the other mentioned strings like __( 'Search' ), __( 'View All' ) and __( 'Most Recent' ).

Also, we usually use yoda conditions, i.e. if( 'private' === $post->post_status ) {...} instead of if( $post->post_status == 'private' ) {...}

[rockwell15]

Replying to swissspidy:

Thanks for the patch, @rockwell15!

Just note that not only the post statuses should be post type labels, but also the other mentioned strings like __( 'Search' ), __( 'View All' ) and __( 'Most Recent' ).

Also, we usually use yoda conditions, i.e. if( 'private' === $post->post_status ) {...} instead of if( $post->post_status == 'private' ) {...}

Ok, I'll fix the conditions format.

I didn't add those 3 strings you mentioned to get_post_type_labels() since those only appear once regarding post type (wp-admin/includes/nav-menu.php ~ line 382), so I thought it unnecessary for that function to fetch them every time it is called. You think I should add them to get_post_type_labels() though?

[swissspidy]

Replying to rockwell15:

I didn't add those 3 strings you mentioned to get_post_type_labels() since those only appear once regarding post type (wp-admin/includes/nav-menu.php ~ line 382), so I thought it unnecessary for that function to fetch them every time it is called. You think I should add them to get_post_type_labels() though?

Yes!

Again, that's what has been reported originally. These strings can be translated differently per post type. Just separating posts and pages is not enough. There are other post types as well.

[ocean90]

The patch needs to cover the table views trunk/src/wp-admin/includes/class-wp-posts-list-table.php@35901#L264​ too.

[rockwell15]

Ok, thanks for clarification. I'll get on that.

Replying to ocean90:

The patch needs to cover the table views trunk/src/wp-admin/includes/class-wp-posts-list-table.php@35901#L264​ too.

What table views are you referring to exactly, the 'Mine', 'All', and 'Sticky'?

[rockwell15]

Added post statuses, nav menu filters, & table view labels to get_post_type_labels()

[fxbenard]

Replying to ocean90:

The patch needs to cover the table views trunk/src/wp-admin/includes/class-wp-posts-list-table.php@35901#L264​ too.

In French like edit/ quick edit/ trash/ view are verbs, no need to translate them differently

[ocean90]

Replying to fxbenard:

In French like edit/ quick edit/ trash/ view are verbs, no need to translate them differently

I'm talking about "All", "Pending" or "Mine".

[fxbenard]

Replying to ocean90:

I'm talking about "All", "Pending" or "Mine".

All > Tous or Toutes
Pending > En attente
Mine > Le mien or La mienne

Yes it's needed

[rockwell15]

I think this patch addresses everything!

[SergeyBiryukov]

#35056 was marked as a duplicate.

[rockwell15]

Fixed patch index

[fxbenard]

It's still time to have a last look here no? it will improve i18n for several languages

[xibe]

Indeed!

Testing @rockwell15's patch would mean generating the POT file and checking that the contexts are indeed separated, right? I'll try and do that.

[wolforg]

I agree with this, the women in the french community aren't happy when they read "Les miens" for the pages.

[ocean90]

Please avoid any further +1 and use the star beside the title instead.

It would be more helpful if you could test the latest patch and provide feedback.

14981.3.patch​: I don't think we should split the string All <span class="count">(%s)</span>, see https://core.trac.wordpress.org/ticket/31859 and https://core.trac.wordpress.org/ticket/31251#comment:17.

[swissspidy]

Replying to ocean90:

14981.3.patch​: I don't think we should split the string All <span class="count">(%s)</span>, see https://core.trac.wordpress.org/ticket/31859 and https://core.trac.wordpress.org/ticket/31251#comment:17.

Agree, though it makes things a bit inconsistent. For example, the string Published is needed both with the <span> and without it. What should we do about that?

See: #31859, 31251#comment:17

---

14981.diff​ is an updated patch without the splitted All <span class="count">(%s)</span> string. I also removed the auto-draft string as it's not needed (maps to draft) and fixed some wording (Sticky is still Sticky in plural, not Stickies).

As for testing the changes, I ran php tools/i18n/makepot.php wp-frontend src test.pot and the strings get correctly added to the POT file with the different contexts.

[fxbenard]

Can you send the pot over, I'll be happy to give it a try and check everything is working fine.

[swissspidy]

Replying to fxbenard:

Can you send the pot over, I'll be happy to give it a try and check everything is working fine.

Sure, I uploaded the wp-admin and wp-frontend pot files here: ​https://cloudup.com/caCUNvosi9C
The relevant entries are only in wp-frontend.pot, they shouldn't be in wp-admin.pot anymore.

[xibe]

I'm not sure of the proper way of testing the POT.

Is it to check that the All and Pending strings are separated (because contextualized)? So far (within poEdit), doesn't seem to have changed anything. Am I missing something?

Thank you!

[DrewAPicture]

Assigning to mark the good-first-bug as "claimed".

[rockwell15]

Refreshed patch & added the logic to 'post-state'

[garrett-eclipse]

Hello,

I was going to close #44599 in favour of the work done here, but have two questions after looking at the 14981.4.patch @rockwell15 provided.

1. Will all $post_states be covered as the following are missing; protected, page_on_front, page_for_posts and page_for_privacy_policy.
2. The context provided for the post statuses in the labels function is either 'post' or 'page'. Can they indicate they are post statuses by using 'post status' and 'page status'.

Great work here, thank you