Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#13673 closed defect (bug) (fixed)

Missing plural form

Reported by: pavelevap's profile pavelevap Owned by: nbachiyski's profile nbachiyski
Milestone: 3.0 Priority: normal
Severity: normal Version: 3.0
Component: I18N Keywords: reporter-feedback i18n-change has-patch
Focuses: Cc:


Show on Screen settings:

10 Plugins (you can choose number).

String "Plugins" is only for one plural form, but for example in Czech there are two forms for 2 - 4 items and for 5 and more items...

Not only Plugins, but also Posts, etc.

Attachments (2)

13673-label_per_page.diff (2.0 KB) - added by zeo 14 years ago.
Use x per page:
13673-use-_nx.diff (3.1 KB) - added by zeo 14 years ago.
use _nx in wp-admin/includes/template.php

Download all attachments as: .zip

Change History (24)

#1 @nacin
14 years ago

We wouldn't customize this based on the number the user has entered. It should be whatever the maximum plural form is, if I had to guess.

#2 @nacin
14 years ago

  • Milestone changed from 3.0 to Unassigned

#3 @pavelevap
14 years ago

  • Milestone changed from Unassigned to 3.0

Yes, it can be maximum plural form, but this string is used several times and there is problem with inflection.

In Czech there are "Příspěvky" as string (plural form) for post type general name, but we also need for example "10 Příspěvků". And there is only one string :-(

#4 follow-up: @nacin
14 years ago

So perhaps _x( 'Plugins', 'plural for screen options' ) ?

#5 in reply to: ↑ 4 @westi
14 years ago

  • Keywords reporter-feedback added

Replying to nacin:

So perhaps _x( 'Plugins', 'plural for screen options' ) ?

That could be good enough.

__('Plugins') appears in 7 places:

  • Screen Options
  • Menu for Plugins page
  • Page Title for Plugins page
  • about plugins for TinyMCE
  • Dashboard widget for installing plugins
  • Multisite enable of Plugins menu
  • Plugin updater

Are there any more of these that need context?

#6 @pavelevap
14 years ago

Sorry for delaying, yes, it could be enough.

There are some of them: Posts, Pages, Categories, Tags, Comments, etc. Everything what can be set (with number) in Screen Options.

#7 @nacin
14 years ago

Is it just screen options, or the various other areas as westi points out? This is hardly a new issue. I strongly suggest 3.1 at this point instead of changing a bunch of strings.

#8 @pavelevap
14 years ago

I noticed this problem only in Screen Options. Problem is hidden in fact that where "Plugins" (and other strings) is the first word of context then it is OK. But when there are something (like number in Screen Options) before "Plugins" then for many languages inflection makes problem (Pluginy x 10 Pluginů). And for Czech language it is great nonsense...

#9 @pavelevap
14 years ago

P.S. These strings are very easy for translators. Some changed words is easier then one sentence in many context help strings which were added some days ago :-)

#10 @westi
14 years ago

  • Keywords i18n-change added

#11 @westi
14 years ago

@pavelevap: Are there a lot of these that need context - is it every one of the screen options where we have a free-text number and then a string?

#12 @pavelevap
14 years ago

Yes, every string where it begins with number.
I found Posts, Pages, Categories, Tags, Comments and Plugins but maybe missed something.

Except Media items (seems that there is unique string for Screen Options).

Better solution was in 2.9.2 for translators, there were following strings:

Posts per page:
Pages per page:
Comments per page:
Media items per page:
Categories per page:
Tags per page:
Plugins per page:

14 years ago

Use x per page:

#13 @zeo
14 years ago

  • Keywords has-patch added

#14 @zeo
14 years ago

  • Keywords changed from reporter-feedback, i18n-change, has-patch to reporter-feedback i18n-change has-patch

14 years ago

use _nx in wp-admin/includes/template.php

#16 @nacin
14 years ago

We wouldn't want to use _nx() here as it is a value the user can enter.

I believe we just need to add context, or a translator's string here, and leave it at that. That way they know that they need to expect a user-inputted value and thus they should use whichever plural form is customary for that.

#17 @nacin
14 years ago

I accidentally committed this in I rolled it back in [15200] but that is my current patch as it stands.

Needs i18n review.

#18 @nacin
14 years ago

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

#19 @pavelevap
14 years ago

  • Resolution fixed deleted
  • Status changed from closed to reopened

Some comments above I mentioned also some more important strings with the same problem: Posts, Pages, Categories and Tags.

#20 @ocean90
14 years ago

pavelevap, I think we have them already, see get_taxonomy_labels() and get_post_type_labels().

#21 @nacin
14 years ago

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

Yeah, unless we start offering more than one type of plural form as part of the post type/taxonomy registration process, this is as far as we're going to go at this point.

Nikolay reviewed those processes, so I'm going to consider this fixed for 3.0 and we can review at a later point. Try the wp-polyglots list?

Note: See TracTickets for help on using tickets.