Opened 3 years ago

Closed 3 years ago

#18395 closed Bug (fixed)

Make a brittle i18n test more reliable

Reported by: julien Owned by: nobody
Component: Internationalization Version: 1.4
Severity: Normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


While working on #18393, I've noticed that if the try/except clause was removed from the blocktrans tag's code (which was introduced in, then the test i18n.TranslationTests.test_bad_placeholder would correctly fail if run on its own, however there would be no failure if running the entire i18n suite. I'm not sure why that is at this stage.

While nothing is broken per-se right now, the test is too brittle and may not catch regressions when the entire test suite is run. So the test should be made more reliable.

Attachments (1)

18395-1.diff (686 bytes) - added by claudep 3 years ago.
Reset translation global variables with setting_changed

Download all attachments as: .zip

Change History (6)

comment:1 Changed 3 years ago by ramiro

The problematic test seems to be regressiontests.i18n.contenttypes.ContentTypeTests.test_verbose_name()

The problem persists if you comment the translation.override('en') call, if comment the translation.override('fr') call things work as expected.

Also, if you run both methods in the reverse order things work as expected in i18n.TranslationTests.test_bad_placeholder but fail in test_verbose_name() like if no French translation was installed:

FAIL: test_verbose_name (regressiontests.i18n.contenttypes.tests.ContentTypeTests)
Traceback (most recent call last):
  File "/home/ramiro/django/git/tests/regressiontests/i18n/contenttypes/", line 28, in test_verbose_name
    self.assertEqual(unicode(company_type), u'Société')
AssertionError: u'Company' != u'Soci\xe9t\xe9'
- Company
+ Soci\xe9t\xe9

All this seem to point to a problem when there are two calls to translation.override('xx) with the same value of 'xx' in the same test run (thread/process), the second one has no effect. Maybe the underlying django.utils.translation.activate('xx') function has this limitation?

comment:2 Changed 3 years ago by ramiro

Maybe we need to munge with the internals of trans_real (_active, _translations) like it is already done in other tests in the same file?.

Or better yet, create testing tools that allow to flush that kind of cached values as it has been discussed a few times already.

comment:3 Changed 3 years ago by claudep

  • Has patch set

Ramiro, I suspect we are reaching here the same issue described in ticket:17980#comment:15 (trans_real._default caching). In your specific case, the problem is maybe more related to _translations caching than _default. When LOCALE_PATHS setting is changed, the _translations global dictionary should probably be reset.

Changed 3 years ago by claudep

Reset translation global variables with setting_changed

comment:4 Changed 3 years ago by jezdez

  • Triage Stage changed from Accepted to Ready for checkin

comment:5 Changed 3 years ago by Claude Paroz <claude@…>

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

In [32a4df6c55f2efd020b7fbc44c858f61b07da17d]:

Fixed #18395 -- Reset language-related global variables with setting_changed

Note: See TracTickets for help on using tickets.
Back to Top