blocktrans plural to fail on untranslated languages

[rgaudin@…]

Reproduce:

• Pick a language with a different plural system then English. The language must exists in Django core. Arabic for example.
• Set your browser to it.
• Add a plural blocktrans {% blocktrans count nb_users=5 %}{{ nb_users }} user{% plural %}{{ nb_users }} users{% endblocktrans %}
• Don't add translation for it.
• Browse it.

It will fail with TemplateSyntaxError: Caught TypeError while rendering: not all arguments converted during string formatting

I believe what happens is:

• Django finds a translation in django core and consider the language supported.
• Django sets its internal plural mechanism to Arabic.
• Django can't find a matching plural translation in the nonexistent Arabic translation NOR in the default English as the plural system is different.

If this assumption is true, the problem might be in gettext itself.

[Ramiro Morales]

Are you actually using Django 1.3? Can you test with a newer versions like 1.4 and 1.5c1?

Also, what are the values of the LANGUAGES and LANGUAGE_CODE settings?

[anonymous]

OK, I tested with 1.4.3 and it's the same.

LANGUAGE_CODE = 'ar'
LANGUAGES = [('ar', u'Arabic'), ('az', u'Azerbaijani'), ('bg', u'Bulgarian'), ('bn', u'Bengali'), ('bs', u'Bosnian'), ('ca', u'Catalan'), ('cs', u'Czech'), ('cy', u'Welsh'), ('da', u'Danish'), ('de', u'German'), ('el', u'Greek'), ('en', u'English'), ('en-gb', u'British English'), ('eo', u'Esperanto'), ('es', u'Spanish'), ('es-ar', u'Argentinian Spanish'), ('es-mx', u'Mexican Spanish'), ('es-ni', u'Nicaraguan Spanish'), ('et', u'Estonian'), ('eu', u'Basque'), ('fa', u'Persian'), ('fi', u'Finnish'), ('fr', u'French'), ('fy-nl', u'Frisian'), ('ga', u'Irish'), ('gl', u'Galician'), ('he', u'Hebrew'), ('hi', u'Hindi'), ('hr', u'Croatian'), ('hu', u'Hungarian'), ('id', u'Indonesian'), ('is', u'Icelandic'), ('it', u'Italian'), ('ja', u'Japanese'), ('ka', u'Georgian'), ('kk', u'Kazakh'), ('km', u'Khmer'), ('kn', u'Kannada'), ('ko', u'Korean'), ('lt', u'Lithuanian'), ('lv', u'Latvian'), ('mk', u'Macedonian'), ('ml', u'Malayalam'), ('mn', u'Mongolian'), ('nb', u'Norwegian Bokmal'), ('ne', u'Nepali'), ('nl', u'Dutch'), ('nn', u'Norwegian Nynorsk'), ('pa', u'Punjabi'), ('pl', u'Polish'), ('pt', u'Portuguese'), ('pt-br', u'Brazilian Portuguese'), ('ro', u'Romanian'), ('ru', u'Russian'), ('sk', u'Slovak'), ('sl', u'Slovenian'), ('sq', u'Albanian'), ('sr', u'Serbian'), ('sr-latn', u'Serbian Latin'), ('sv', u'Swedish'), ('sw', u'Swahili'), ('ta', u'Tamil'), ('te', u'Telugu'), ('th', u'Thai'), ('tr', u'Turkish'), ('tt', u'Tatar'), ('uk', u'Ukrainian'), ('ur', u'Urdu'), ('vi', u'Vietnamese'), ('zh-cn', u'Simplified Chinese'), ('zh-tw', u'Traditional Chinese')]

LANGUAGES here displayed in English for readiness, it's actually in Arabic.

[Ramiro Morales]

I can't reproduce this neither on trunk nor on 1.4.3 with the attached patch for Django i18n tests. Note how I reproduced exactly the setup you described.

I'm closing the ticket as 'worksforme' because it is our procedure given the above but if you could dedicate some more time to this and submit a modified version of that test case such that it makes the issue show itself we will be very grateful.

Also, please try to concentrate on reproducing the exact conditions you have on your environment and because of which you encounter this issue. We have time to make hypothesis about the reason of the observed failure afterwards.

[Ramiro Morales]

Patch for i18n tests with test case that doesn't fail