Make WordPress Core

Opened 14 years ago

Closed 13 years ago

Last modified 13 years ago

#16406 closed defect (bug) (fixed)

Admin bar localization

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

Description

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 14 years ago.
16406.diff (1.5 KB) - added by nacin 13 years ago.
16406.2.diff (2.1 KB) - added by nacin 13 years ago.

Download all attachments as: .zip

Change History (30)

#2 @SergeyBiryukov
14 years ago

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

#3 @ocean90
14 years ago

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

So we need _x() here?

#4 @pavelevap
14 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...

#5 @garyc40
14 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') ),

#6 @westi
14 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.

#7 @SergeyBiryukov
14 years ago

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

#8 @waclawjacek
14 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

#9 @scribu
14 years ago

  • Milestone changed from 3.1 to Future Release

#10 @pavelevap
13 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...

#11 follow-up: @scribu
13 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?

@nacin
13 years ago

#12 @nacin
13 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.

#13 in reply to: ↑ 11 @waclawjacek
13 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.

WJ

#14 @ryan
13 years ago

In [18233]:

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

#15 @nacin
13 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?

@nacin
13 years ago

#16 @nacin
13 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?

#17 @nacin
13 years ago

  • Keywords commit added

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

#18 @ryan
13 years ago

Seems sane and works well so far with light testing.

#19 @nacin
13 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.

#20 @pavelevap
13 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.

Example:
"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.

#21 @nacin
13 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.

#22 @pavelevap
13 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...

#23 @nacin
13 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.

#24 @pavelevap
13 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...

#25 @nacin
13 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.

#26 follow-up: @scribu
13 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.

#27 in reply to: ↑ 26 @nacin
13 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.