Opened 3 months ago
Last modified 2 weeks ago
#23503 new defect (bug)
Post Formats: i18n issues
Reported by: | SergeyBiryukov | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 3.6 |
Component: | I18N | Version: | trunk |
Severity: | normal | Keywords: | has-patch |
Cc: | xoodrew@… |
Description (last modified by SergeyBiryukov)
- 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
[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].
- [23843] introduced a couple of issues:
- ucfirst( sprintf( __( '%s Post' ), $slug ) ):
http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php?rev=23868#L186- '%s Post' is not localizable, see dd32's comment in #17609.
- ucfirst() doesn't always work correctly for UTF-8 characters, it depends on PHP locale.
- i18n is missing in line 397:
http://core.trac.wordpress.org/browser/trunk/wp-admin/edit-form-advanced.php?rev=23868#L397
- ucfirst( sprintf( __( '%s Post' ), $slug ) ):
Attachments (7)
Change History (27)
SergeyBiryukov — 3 months ago
comment:1 SergeyBiryukov — 2 months ago
- Description modified (diff)
- Keywords needs-patch added; has-patch removed
- Summary changed from Standard post format needs more contexts to Post Formats: i18n issues
johnbillion — 2 months ago
comment:2 johnbillion — 2 months ago
- Keywords has-patch added; needs-patch removed
comment:4 SergeyBiryukov — 2 months ago
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().
comment:5 SergeyBiryukov — 2 months ago
Or just add an argument to get_post_format_strings() to return 'Standard Post', etc.
comment:6 follow-up: ↓ 8 johnbillion — 2 months ago
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.
comment:7 SergeyBiryukov — 2 months ago
Ah, I see. Makes sense then.
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.
comment:9 c3mdigital — 8 weeks ago
#23972 was marked as a duplicate.
comment:10 SergeyBiryukov — 8 weeks ago
#23976 was marked as a duplicate.
comment:11 nvartolomei — 8 weeks ago
#23979 was marked as a duplicate.
comment:12 SergeyBiryukov — 8 weeks ago
Related: #24018
comment:13 follow-up: ↓ 14 SergeyBiryukov — 8 weeks ago
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".
comment:14 in reply to: ↑ 13 kopepasah — 8 weeks ago
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.
comment:15 DrewAPicture — 8 weeks ago
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.
comment:16 DrewAPicture — 8 weeks ago
- Cc xoodrew@… added
comment:17 SergeyBiryukov — 8 weeks ago
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.
SergeyBiryukov — 8 weeks ago
comment:18 johnbillion — 5 weeks ago
Related to this, we should get rid of the annoying and unnecessary title attribute on the post format selectors.
comment:19 kovshenin — 2 weeks ago
- Keywords needs-refresh added
comment:20 DrewAPicture — 2 weeks ago
- Keywords needs-refresh removed
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.