WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

#6261 closed defect (bug) (fixed)

Modifiy a dozen strings to allow for plural form

Reported by: xibe Owned by:
Milestone: 2.5 Priority: low
Severity: minor Version: 2.5
Component: I18N Keywords: has-patch needs-review
Focuses: Cc:

Description

The "Published (xx)" string should use ngettext(), since it can take different values. It would not impact english, but would in French for instance :

Publié (0)
Publié (1)
Publiés (2)

Right now we are pretty much forced to use "Publié(s) (xx)".

Same for these I guess:

Scheduled (%s)
Pending Review (%s)
Draft (%s)
Private (%s)

These could also be useful:

Already pinged: -> Already pinged: %s
Done! <strong>%1$s</strong> categories imported.
Done! <strong>%1$s</strong> users imported.
imported %s
ignored %s
There are currently %1$s comments identified as spam.

...and maybe more :)

Thanks for changing these in time for 2.5 :)

Attachments (1)

late-plurals.diff (10.1 KB) - added by nbachiyski 6 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 ionfish6 years ago

  • Keywords needs-patch added
  • Milestone 2.5 deleted

comment:2 lloydbudd6 years ago

  • Milestone set to 2.7

ionfish, I prefer every ticket to have a milestone or be closed. 2.6 was the default milestone, as 2.5 is almost here, I'm changing it to 2.7 .

comment:3 follow-up: mdawaffe6 years ago

Are we in string lock? We should put this as 2.6 at least, 2.5 if we can still accept string patches.

comment:4 follow-up: mdawaffe6 years ago

Actually - the post status strings mentioned ( Published (%s), etc. ) are kind of strange.

We can move wp_count_posts() up above the $post_stati definition (e.g. in wp-admin/edit-pages.php) so that we know how many of each there are, but I'm not sure what

__ngettext( 'Published (%s)', 'Published (%s)', $number );

will do.

Are those two identical strings separately addressable during translation?

comment:5 in reply to: ↑ 3 lloydbudd6 years ago

Replying to mdawaffe:

Are we in string lock? We should put this as 2.6 at least, 2.5 if we can still accept string patches.

An enhancement (as opposed to a bug) without a patch, I generally always put out to farthest milestone. With a patch, you guys can have a more meaningful discussion about what milestone it should be.

comment:6 in reply to: ↑ 4 nbachiyski6 years ago

  • Keywords has-patch needs-review added; needs-patch removed
  • Milestone changed from 2.7 to 2.5
  • Priority changed from normal to low
  • Type changed from enhancement to defect

Replying to mdawaffe:

Actually - the post status strings mentioned ( Published (%s), etc. ) are kind of strange.

We can move wp_count_posts() up above the $post_stati definition (e.g. in wp-admin/edit-pages.php) so that we know how many of each there are, but I'm not sure what

No need to do that. I added __ngettext_noop function, which makes sure the strings will get into the POT file and doesn't need number. The actual number-matching is done when the string is displayed, then we can use __ngettext.

__ngettext( 'Published (%s)', 'Published (%s)', $number );

will do.

If there is no translation, it will return the first string if $number is 1 or the second otherwise. It is completely safe.

Are those two identical strings separately addressable during translation?

Yes, they are separately addressable. Translators will just see the same string for English plural and English singular, which is fine with them.

About the string freeze: since we don't expect international versions to be released at the same time we release 2.5 it is ok not to have string freeze. Translators can catch up in the days after the release, if there are lots of changed strings. Usually they just have to update a few strings, which costs minutes.

Back to the ticket topic: the patch is attached, but it's not trivial. I have tested it and I am setting its milestone to 2.5, but if anybody thinks it is too complex to get that late into development, it is ok to be left for 2.6. I am not really sure if it should stay as an enhancement, because in some languages these messages can sound very strange in singular.

nbachiyski6 years ago

comment:7 xibe6 years ago

Thank you so much for your patch, Nikolay!

since we don't expect international versions to be released at the same time we release 2.5

Actually, we are aiming at a H+6 release ourselves (fr_FR), and our recent 2.5-RC1 release comfort us that this can be done. Ok, not everyone will do this, obviously, but just to let you know.

Translators can catch up in the days after the release

But wouldn't that make it for 2.5.1?

in some languages these messages can sound very strange in singular

Agreed. And we're not even talking about feminine form :) (i.e., in French, Post is translated to Article, masculine word, and Page to Page, feminine word. Double that with plurals, and you've got yet another level of problems :) But that's for another major release, I'd say...)

comment:8 ryan6 years ago

Can we add ntraslate() to use in place of ngettext() in the places where we have to pass variables instead of literal strings. I'd rather not have those variables making there way into the catalog.

comment:9 nbachiyski6 years ago

ryan, xgettext takes only literal strings from the source. Even in the gettext documentation it is written like that.

comment:10 ryan6 years ago

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

(In [7397]) ngettext fixes from nbachiyski. fixes #6261

Note: See TracTickets for help on using tickets.