Post Formats: i18n issues

[SergeyBiryukov]

1. Most of the time, we refer to the "Standard" post format with the appropriate context:
   ​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/includes/class-wp-posts-list-table.php#L1013
   ​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/press-this.php#L480
   ​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-includes/post.php#L5325
   
   In a couple of places, however, the context is missing:
   ​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/includes/meta-boxes.php#L318
   ​http://core.trac.wordpress.org/browser/tags/3.5.1/wp-admin/options-writing.php#L90

2. [23449] introduced Edit screen UI for post formats. There's now a "Standard" tab above the post title. In Russian, "post" is feminine and "format" is masculine, so seeing "Standard" adjective without the "format" word next to it is confusing. I guess the tab needs a separate context. Fixed in [23843].

3. [23843] introduced a couple of issues:
   1. ucfirst( sprintf( __( '%s Post' ), $slug ) ):
      ​http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php?rev=23868#L186
      1. '%s Post' is not localizable, see dd32's comment in #17609.
      2. ucfirst() doesn't always work correctly for UTF-8 characters, it depends on PHP locale.
      We should use actual labels instead of just putting post format slugs into a generic string.
   2. i18n is missing in line 397:
      ​http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php?rev=23868#L397 No longer relevant; see #24452.

[johnbillion]

23503.2.patch​ adds a new set of labels to post types for each post format, uses these labels in the admin UI, and corrects the other issues mentioned above by Sergey.

[helen]

#23911 was marked as a duplicate.

[SergeyBiryukov]

Pages don't have post formats, looks like there should be null instead of 'Standard Page', etc.

Or, we could introduce a new function (I'd suggest get_post_format_labels()) instead of piggybacking on get_post_type_labels().

[SergeyBiryukov]

Or just add an argument to get_post_format_strings() to return 'Standard Post', etc.

[johnbillion]

The point is though that any post type can be given support for post formats, and the 'Page' format labels are used as fallback for hierarchical post types.

[SergeyBiryukov]

Ah, I see. Makes sense then.

[kopepasah]

Remove 'Post' from the post format tip.

[kopepasah]

Replying to johnbillion:

The point is though that any post type can be given support for post formats, and the 'Page' format labels are used as fallback for hierarchical post types.

At first I was going to recommend using the current post type (instead of 'Post') for each custom post type (e.g. Standard Post, Aside Book, Gallery Food, et cetera), but reading that this does not fit the context.

Because any post type can be given support for post formats, I recommend taking out the word 'Post' and any other post type altogether. Users should not have to be reminded which post type they are editing.

The only tip that needs to show is the format.

[c3mdigital]

#23972 was marked as a duplicate.

[SergeyBiryukov]

#23976 was marked as a duplicate.

[nvartolomei]

#23979 was marked as a duplicate.

[SergeyBiryukov]

Related: #24018

[SergeyBiryukov]

23503.post-format-tip.patch​ is not localizable. Dynamic strings like sprintf( __( '%s' ), $slug ) or _e( $post_format ) cannot be extracted by gettext:
​http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/

23503.2.patch​ looks good to me. The "Post format" context is probably not necessary for strings like "Standard Post" in get_post_type_labels(). It's only needed for ambiguous strings like "Standard".

[kopepasah]

Replying to SergeyBiryukov:

23503.post-format-tip.patch​ is not localizable. Dynamic strings like sprintf( __( '%s' ), $slug ) or _e( $post_format ) cannot be extracted by gettext:
​http://ottopress.com/2012/internationalization-youre-probably-doing-it-wrong/

Thanks for pointing that out. Localization is not my forte. I will read through that article and resubmit my patch.

[DrewAPicture]

Add "Edit {format} Post" labels

[DrewAPicture]

Cast format labels as object, shorten keys

[DrewAPicture]

23503.4.patch​ follows feedback from @nacin and @SergeyBiryukov in ​IRC last night and adds post format post type labels as a sub-object in the form of '{format} Post', 'Edit {format} Post'.

Still needs a little help in terms of merging default values with undefined format labels in register_post_type() form cpts.

[SergeyBiryukov]

23503.5.patch​ fixes the issue with merging CPT labels with the default ones (mentioned by Drew in the ​IRC chat). While we're at it, also reformats the whole labels array for better readability.

I guess the context for post format labels is superfluous, as they are not ambiguous. We can add it later if needed.

[johnbillion]

Related to this, we should get rid of the annoying and unnecessary title attribute on the post format selectors.

[DrewAPicture]

refresh

[johnbillion]

Point #3 in this ticket is also no longer relevant due to #24452. Patch for the remaining issue coming up.

[SergeyBiryukov]

In 24522:

Consistently use get_post_format_string() to get Standard post format name with the correct context. props johnbillion. fixes #23503.