Make a brittle i18n test more reliable

[Julien Phalip]

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 ​https://github.com/django/django/commit/16bb9c594c), 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.

[Ramiro Morales]

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/tests.py", 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?

[Ramiro Morales]

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.

[Claude Paroz]

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.

[Claude Paroz]

Reset translation global variables with setting_changed

[Claude Paroz <claude@…>]

In [32a4df6c55f2efd020b7fbc44c858f61b07da17d]:

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