Modifiy a dozen strings to allow for plural form

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 .

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

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?

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.

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.

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...)

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.

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

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