Problem with translations when the settings module is a folder

[vbmendes]

My settings module is a folder with some kind of organization, to make things more clean and mantainable. The fact is that django allways gets the project path by the settings module path, so my project path is always wrong: real_project_path/settings.

When I try to create my own translations in my project, django don't recognize it, becouse it looks in real_project_path/settings/locale instead of real_project_path/locale.

I make a very simple patch that fixes this problem, but the better way is to create a simple constant to store the project path. Maybe settings.PROJECT_ROOT_PATH, or something like this. I already have this constant in all my projects, and know of many people with this same practice.

[vbmendes]

Patch to fix the problem

[Malcolm Tredinnick]

This patch isn't a very nice way to go about this. Hardcoding things like the string __init__.py looks ugly and a bit fragile. The comments are also a bit uncertain (and we shouldn't be using words like "folder" in comments when there are more accurate Python terms). "Project level" stuff is always a bit tricky in Django, so maybe it's something that simply doesn't work if you aren't using a simple module for settings.

There should be a better solution here with respect to specifying a non-app translation directory. This patch isn't it, but the problem is possibly valid.

[Ramiro Morales]

In [15441]:

Fixed #5494, #10765, #14924 -- Modified the order in which translations are read when composing the final translation to offer at runtime.

This is slightly backward-incompatible (could result in changed final translations for literals appearing multiple times in different .po files but with different translations).

Translations are now read in the following order (from lower to higher priority):

For the 'django' gettext domain:

• Django translations
• INSTALLED_APPS apps translations (with the ones listed first having higher priority)
• settings/project path translations (deprecated, see below)
• LOCALE_PATHS translations (with the ones listed first having higher priority)

For the 'djangojs' gettext domain:

• Python modules whose names are passed to the javascript_catalog view
• LOCALE_PATHS translations (with the ones listed first having higher priority, previously they weren't included)

Also, automatic loading of translations from the 'locale' subdir of the settings/project path is now deprecated.

Thanks to vanschelven, vbmendes and an anonymous user for reporting issues, to vanschelven, Claude Paroz and an anonymous contributor for their initial work on fixes and to Jannis Leidel and Claude for review and discussion.