Code

#19667 closed Bug (worksforme)

blocktrans plural to fail on untranslated languages

Reported by: rgaudin@… Owned by: nobody
Component: Internationalization Version: 1.3
Severity: Normal Keywords: i18n locale
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (1)

19667.diff (918 bytes) - added by ramiro 16 months ago.
Patch for i18n tests with test case that doesn't fail

Download all attachments as: .zip

Change History (4)

comment:1 Changed 18 months ago by ramiro

  • Component changed from Translations to Internationalization
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

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?

comment:2 Changed 18 months ago by 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.

comment:3 Changed 16 months ago by ramiro

  • Resolution set to worksforme
  • Status changed from new to closed

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.

Changed 16 months ago by ramiro

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.