Exported jsi18n ngettext() function doesn't check existence of plural translation before attempting to access it

[Mohamed Moustafa]

In ​https://docs.djangoproject.com/en/2.0/_modules/django/views/i18n/ the following exported javascript function

django.ngettext = function(singular, plural, count) {
      var value = django.catalog[singular];
      if (typeof(value) == 'undefined') {
        return (count == 1) ? singular : plural;
      } else {
        return value[django.pluralidx(count)];
      }
    };

doesn't check the existence of value[1] or value[2] before attempting to access them if value itself is defined. Therefore will return undefined if user attempts to access plural translation, when none is defined.

• If user provides no translations at all for singular or plural strings it will return formatted un-translated string (Works as expected)
• If user provides translations for singular and plural strings it will return formatted translated string (Works as expected)
• If user provides singular translation BUT no plural translation it will return undefined (Unexpected and extremely difficult to debug)

This function should rather fallback to singular translation OR use un-translated plural string in cases where a singular translation is provided but no plural translation is provided.

[Simon Charette]

Do you think it could be related to #29825, ​https://github.com/django/django/pull/10506

[Mohamed Moustafa]

Replying to Simon Charette:

Do you think it could be related to #29825, ​https://github.com/django/django/pull/10506

Yeah, they both concern the same function but that's a different failure mode.

[Serhiy Martynenko]

Do you have example of part of translation file? I tried to reproduce bug and it looks like JS array with translations as plural has empty string instead of undefined.

[Ramiro Morales]

A question we need to ask the reported is how a translation literal which is malformed i.e. with quantity of plural forms not obeying what the locale's plural forms formula has reached the translation catalog in the first place.

AFAIC the compilemessages/msgfmt stage should have rejected the literal when trying to convert the .po file to .mo.

[Ramiro Morales]

I'm closing this for now setting the 'We need more information' flag.

Please reopen if you can answer question in comment:8