Make WordPress Core

Opened 18 months ago

#57588 new defect (bug)

The picking of plural form #0 is hard-coded for singular strings

Reported by: jaanise's profile jaanise Owned by:
Milestone: Awaiting Review Priority: normal
Severity: minor Version: 6.1
Component: I18N Keywords:
Focuses: template Cc:


If a translation with plural forms exist, but a simple (without count) message is requested, the plural form with index 0 is returned regardless of the MO file's Plural-Forms definition.

For example, if there is a PO file with the following Plural-Forms:

"Plural-Forms: nplurals=3; plural=n%10==0||( n%100 >= 11 && n%100<=19)? 0 :(n%10==1 && n%100!=11 ? 1 : 2);\n"

(You can see that one item would be in plural form ID=1, not ID=0.)

And this translation entry:

msgid "Product"
msgid_plural "Products"
msgstr[0] "Prod 0,10,11"
msgstr[1] "Prod 1,21,31"
msgstr[2] "Prod 2,3,4"

And you have this PHP code:

  esc_html_e('Product', 'my_payment');
  echo _n('Product', 'Product', 2,'my_payment');
  echo _n('Product', 'Product', 1,'my_payment');

You will get this output:

Prod 0,10,11
Prod 2,3,4
Prod 1,21,31

As you can see, the first message is incorrectly selected for count 1.
The following ones are correctly selected for counts 2 and 1.

The selection of the hardcoded plural form ID=0 happens here:

If a not-counted message is requested and the available translation turns out to be count-dependable, translate should probably either forward the call to translate_plural passing count 1, or return the untranslated fallback or an empty string (with a notice) if this is considered as a non-existing translation.

Although asking for a not-counted string but having count-dependable translations is not a correct situation in itself, it can easily occur also due sloppy programming in third party themes or plugins, or maybe occur during changes to translation files or translatable strings.

Change History (0)

Note: See TracTickets for help on using tickets.