I18N locale per app resolving - documentation incorrect and bug
|Reported by:||Klaas van Schelven||Owned by:||nobody|
|Cc:||Triage Stage:||Ready for checkin|
|Has patch:||yes||Needs documentation:||no|
|Needs tests:||yes||Patch needs improvement:||no|
At runtime, Django looks for translations by following this algorithm:
- First, it looks for a locale directory in the application directory of the view that’s being called. If it finds a translation for the selected language, the translation will be installed.
- Next, it looks for a locale directory in the project directory. If it finds a translation, the translation will be installed.
- Finally, it checks the Django-provided base translation in django/conf/locale.
However, this has not been my experience. I also do not see anything
in the django source code or tests that responds to the above.
In django/utils/translation/trans_real.py I see the following:
def translation(language): [......] for appname in settings.INSTALLED_APPS: apppath = os.path.join(get_apppath(appname), 'locale') if os.path.isdir(apppath): res = _merge(apppath)
_merge (and deeper down "merge") is defined as a dictionary update in
the same file.
I see two problems here:
- the documented behavior is not implemented
- the implemented behavior has the opposite order-of-preference for apps as the rest of Django. (Normally, the higher up in your INSTALLED_APPS you put an app, the more likely it's templates, etc. will be called. Here we're using a dict update, so the lowest app has preference)
Also: I think the documented behavior is not desirable. Changing
translations per-view makes for hard to debug once-in-a-while bugs.
This means the bug '2' is still a problem. I suggest either reversing
158 for appname in settings.INSTALLED_APPS:
or making the update of a 'merge' non-destructive.
Reported before on Django-Developers, but I got no response:
Change History (16)
comment:6 follow-up: 7 Changed 6 years ago by
|Component:||Uncategorized → Internationalization|
|Triage Stage:||Unreviewed → Accepted|