Make WordPress Core

Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#16406 closed defect (bug) (fixed)

Admin bar localization

Reported by: pavelevap Owned by: nacin
Milestone: 3.2 Priority: normal
Severity: normal Version: 3.1
Component: I18N Keywords: has-patch needs-testing commit
Focuses: Cc:


Admin bar is not localized correctly for many languages (example in Czech).

"Add New" - can be translated as "Vytvořit" or "Přidat".
But it is not possible to use simple singular nouns as "Page", because this is "Stránka" (alone), but "Vytvořit Stránka" is nonsense. In Czech it should be "Vytvořit stránku" or "Vytvořit Stránku).

So, we need not only one string "Page" in this case, but also the same string "Page" (in English) which has another case in Czech (related on meaning and inflexion).

The same problem was also in ticket 13673 - http://core.trac.wordpress.org/ticket/13673 which was closed, but partly not resolved.

Attachments (3)

16406.patch (1.4 KB) - added by SergeyBiryukov 5 years ago.
16406.diff (1.5 KB) - added by nacin 4 years ago.
16406.2.diff (2.1 KB) - added by nacin 4 years ago.

Download all attachments as: .zip

Change History (30)

comment:2 @SergeyBiryukov5 years ago

Same for Russian. Perhaps post type labels can have accusative case name in addition to singular_name?

comment:3 @ocean905 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.1

So we need _x() here?

comment:4 @pavelevap5 years ago

There are two similar problems:

1) Screen options (ticket 13673) - missing accusative case name for numbers of items.

2) Admin bar (this ticket) - also missing accusative case name for nouns "Page", etc.

But I am not sure if _x() can resolve this problem...

comment:5 @garyc405 years ago

Right now wp_admin_bar_new_content_menu() is using singular name label of post type objects. As a result, the default value is _x('Post', 'post type singular name') .

Perhaps we should add another label type for this case, however add_new and add_new_item are already taken:

'add_new' => array( _x('Add New', 'post'), _x('Add New', 'page') ),
'add_new_item' => array( __('Add New Post'), __('Add New Page') ),

comment:6 @westi5 years ago

I'm not sure we should rush a fix for this.

We have a number of other similar i18n issues which we need to resolve and I think that this could wait for 3.2 so we can spend the time to understand all the issues we need to resolve and do it carefully.

@SergeyBiryukov5 years ago

comment:7 @SergeyBiryukov5 years ago

  • Keywords 3.2-early has-patch added; needs-patch removed

comment:8 @waclawjacek5 years ago

I don't know if I understand this right, but how about not translating this directly, but in some other way? Such as:

- New
  - item 1
  - item 2

comment:9 @scribu5 years ago

  • Milestone changed from 3.1 to Future Release

comment:10 @pavelevap4 years ago

With adding new items (User, Theme, Plugin) to admin bar in WP 3.2 there are more and more problems for translators.

Word "Add" for all items is good in English, but in Czech there are different meanings for "Add" in different cases. "Add" can be "Vytvořit" for Post, "Instalovat" for Theme, etc. Also using for translation only "New" instead of "Add" cannot be used because "New" is "Nový" for Post and "Nová" for Theme.

Please, make translation for admin bar more flexible...

comment:11 follow-up: @scribu4 years ago

Couldn't we just re-use the 'Install Themes' string?

Also, do we really need a theme install button on the admin bar in the first place?

@nacin4 years ago

comment:12 @nacin4 years ago

  • Keywords 3.2-early removed
  • Milestone changed from Future Release to 3.2

Patch attached. Doesn't deal with post types, but it's a start.

Closed #17742 as a duplicate.

comment:13 in reply to: ↑ 11 @waclawjacek4 years ago

Replying to scribu:

Couldn't we just re-use the 'Install Themes' string?

Also, do we really need a theme install button on the admin bar in the first place?

I guess "Install Themes" can be a bit too long in some translations. A thing that I've noticed over time is that the more separation, the better.


comment:14 @ryan4 years ago

In [18233]:

Disambiguation for Add New links in admin bar. Props nacin. see #16406

comment:15 @nacin4 years ago

name_admin_bar simply cannot default to Page and Post in get_post_type_labels(), it would cause duplicate items in the bar.

We need a good way to handle name_admin_bar as a new string, while allowing singular_name to override it if missing, while also preventing a generic name from making its way into the object. Need to choose practicality over translations here.

We've already made special cases in _get_custom_object_labels() for menu_name, all_items, etc. -- but this one requires a bit more, as it does require defaults (so it may be applied to the post/page post types themselves), but we simply cannot use the defaults.

Can anyone come up with a patch?

@nacin4 years ago

comment:16 @nacin4 years ago

  • Keywords needs-testing added

Okay, I came up with something. New patch works around the issues I had described.

New name_admin_bar labels are defined specifically for posts and pages. They are specifically not used as defaults.

Instead, name_admin_bar defaults to singular_name if present (which in turn defaults to name or ->label if present), and defaults to object->name (the internal slug) directly if not.

This is unique from other areas of core. If you don't specify any labels for a post type, you'll literally get "Posts" and "Post" (or "Pages" and "Page") everywhere. That doesn't work if they all appear in the same menu.

I would think that any post type of show_ui = true and show_in_menu = true (could even be a public = true check there) would also have labels.

Suggest commit, except that there's been no testing on this. Can someone please kick the tires?

comment:17 @nacin4 years ago

  • Keywords commit added

Marking as a commit candidate based on sweep. Needs a check on the logic.

comment:18 @ryan4 years ago

Seems sane and works well so far with light testing.

comment:19 @nacin4 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [18261]:

Introduce name_admin_bar label and the show_in_admin_bar (Add New menu) argument for post types. Allows for proper translations of these strings and provides for consolidated logic. fixes #16406.

comment:20 @pavelevap4 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

These fixes solved only one part of this issue, see my initial description. Now I can handle with words "Page", "Plugin", etc but I cannot work with "Add New" string.

"Add New" is "Vytvořit" or "Přidat" for "Post" or "Page" but "Instalovat" for "Plugin", etc. It is not possible to use only one word for "Add New" string in Czech. I tried to translate it only as "New" to avoid these problems, but this is also dynamic word in Czech (and other languages), for example "Nový" for "Post" and "Plugin" but also "Nová" for "Page" and "Theme", etc.

comment:21 @nacin4 years ago

We're not functionally changing the admin bar for localization purposes, sorry.

_x( 'Add New', 'admin bar menu group label' )

That's what's in core. You should be able to do something with the context there. Try "Add New Item," translating it for Item. They'll figure out the different items.

comment:22 @pavelevap4 years ago

Yes, I understand it, but there are many strings "Add New ..." with different context in core which solve this issue in administration. Admin bar is kind of special, maybe some kind of plus (+) icon instead of string "Add New" and then using whole strings "Add New Plugin" in the future? I did not find other solution (except plus sign instead of "Add New" string). Czech is not very flexible regarding this issue...

comment:23 @nacin4 years ago

If you wanted do, since these all have specific context, you could translate the top item as "Add New Post" (since that's what it links to) and then expand the other submenus to "Add New Plugin," "Add New User," etc.

That's what I'd suggest, anyway.

comment:24 @pavelevap4 years ago

Yes, it is also one of possible "dirty" solutions. But I wanted avoid duplicating menu and first submenu items (as it was changed for example for 3.2 in core left admin menu)... I understand that this issue is probably "wontfix" because there would be needed some changes to current admin bar structure...

comment:25 @nacin4 years ago

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

Not that dirty -- the Czech language clearly isn't flexible. You need to work around that in whichever way makes the most sense.

comment:26 follow-up: @scribu4 years ago

It would have been nice if the new label was 'admin_bar_name', to be consistent with 'singular_name' and 'menu_name'. Too late now.

comment:27 in reply to: ↑ 26 @nacin4 years ago

Replying to scribu:

It would have been nice if the new label was 'admin_bar_name', to be consistent with 'singular_name' and 'menu_name'. Too late now.

Yeah, no idea why I didn't do that. We could probably slip it in, though.

Note: See TracTickets for help on using tickets.