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 reporter is how a translation literal which is malformed i.e. with quantity of plural forms not obeying the locale's plural forms formula has reached the translation catalog in the first place.

AFAICT 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