Code

Opened 5 years ago

Closed 3 years ago

#10765 closed (fixed)

Problem with translations when the settings module is a folder

Reported by: vbmendes Owned by: nobody
Component: Internationalization Version: 1.0
Severity: Keywords: translation settings project path
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

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.

Attachments (1)

settings_folder_problem.diff (1.0 KB) - added by vbmendes 5 years ago.
Patch to fix the problem

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by vbmendes

Patch to fix the problem

comment:1 Changed 5 years ago by anonymous

  • Component changed from Uncategorized to Internationalization
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 5 years ago by anonymous

  • Has patch set

comment:3 Changed 5 years ago by mtredinnick

  • Has patch unset
  • Triage Stage changed from Unreviewed to Design decision needed

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.

comment:4 Changed 3 years ago by ramiro

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

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.

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.