#16084 closed New feature (fixed)
makemessages command doesn't respect LOCALE_PATHS setting
Reported by: | heylinus | Owned by: | nobody |
---|---|---|---|
Component: | Internationalization | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | em@… | Triage Stage: | Ready for checkin |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
The makemessages command won't check the paths in LOCALE_PATHS as compilemessages command does.
core/management/commands/makemessages.py:134-142
core/management/commands/compilemessages.py:15-21
It only generates .po file in the locale folder that is located in project root.
If a locale folder exists in project root, a deprecation warning will appear:
utils/translation/__init__.py:64: DeprecationWarning: Translations in the project directory aren't supported anymore. Use the LOCALE_PATHS setting instead.
If locale folder is removed from project root, makemessage will throw out command error:
Error: This script should be run from the Django SVN tree or your project or app tree. If you did indeed run it from the SVN checkout or your project or application, maybe you are just missing the conf/locale (in the django tree) or locale (for project and application) directory? It is not created automatically, you have to create it by hand if you want to enable i18n for your project or application.
Change History (16)
comment:1 by , 14 years ago
Summary: | makemessage command doesn't respect LOCALE_PATHS setting at all → makemessages command doesn't respect LOCALE_PATHS setting at all |
---|
comment:2 by , 14 years ago
Version: | SVN → 1.3 |
---|
comment:3 by , 14 years ago
Resolution: | → invalid |
---|---|
Status: | new → closed |
Type: | Bug → New feature |
comment:4 by , 13 years ago
Resolution: | invalid |
---|---|
Status: | closed → reopened |
Summary: | makemessages command doesn't respect LOCALE_PATHS setting at all → makemessages command doesn't respect LOCALE_PATHS setting |
Triage Stage: | Unreviewed → Accepted |
Yes, this is something that isn't completely easy to use after the changes that start deprecation of a locale/ subdir of the project dir. We need to give users the ability to specify an output directory when running makemessages
, or similar solution. Reopening.
comment:6 by , 13 years ago
Version: | 1.3 → 1.4 |
---|
comment:7 by , 12 years ago
Cc: | added |
---|
I would characterize this as a bug, not a new feature.
Reason: These are the options a 1.4 user has:
1) Use a directory called "locale", without a init.py, like you did with Django 1.3. You will now get a DeprecationWarning each time you use manage.py. Annoying.
2) Use a directory with a non-locale name, such as "translations", and reference that path with the new LOCALE_PATHS setting. Now the makemessages command won't work. Unacceptable.
3) Use a directory called "locale" and point to it using the LOCALE_PATHS setting. Now you'll get an ImportWarning that the locale directory is missing a init.py file. But if you add a file like this you get other import errors, since gettext imports a package called locale, and stops working if there's a local importable directory called locale. Unacceptable.
So unless I'm missing something basic (I have before, so please point it if so), it seems we're stuck with an annoying DeprecationWarning until this bug is fixed.
comment:8 by , 12 years ago
I'm having the same problem.
I'm overriding some of Django's builtin date/time formats for different locales and at first put the formats.py files under locale/XX/. And that of course gave me the gettext import errors described in Emil's 3rd point. So I renamed my 'locale' dir to 'locales' and now I have the problem number 2.
I don't want two subdirs for the same thing either ('locale' for translations and e.g. 'locales' for the custom formats). So I'm probably going to have to duplicate the makemessages cmd and change the hardcoded path until the proper fix.
comment:9 by , 12 years ago
I have a patch that allows you to always run makemessages
at project level, and which dispatches strings in various pot files depending on their file location.
For example, strings from myapp/myfile.txt
will go to myapp/locale/....po
if myapp/locale
exists, else they will go to LOCALE_PATHS[0]
, and if LOCALE_PATHS
is empty, a CommandError
is raised. Backwards compatibility should be kept, unless I missed a use case.
For Django itself, we could simply remove the line self.ignore_patterns += ['contrib/*']
and all contrib po files would be handled with a single makemessages
call. I'd vote for it.
comment:11 by , 12 years ago
Status: | reopened → new |
---|
comment:12 by , 11 years ago
I've just updated the patch to current master and created a pull request: https://github.com/django/django/pull/1706
comment:13 by , 11 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
I plan to commit the patch in the next days.
comment:14 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:15 by , 9 years ago
Hello, commenting an old fixed ticket.
If an app has 'locale' named folder under its static folder (/app_name/static/app_name/locale/foobar.js), makemessages does not pick the files in that folder (here foobar.js). Is that intentional?
Here's the relevant code: https://github.com/django/django/blob/master/django/core/management/commands/makemessages.py#L413
comment:16 by , 9 years ago
It's probably not intentional. We would need to find some heuristics to detect if dirname is a 'locale' directory containing translations or any other sort of 'locale'-named directory. Please open a new ticket for this issue.
Currently,
makemessages
doesn't handle multiplelocale
folders at all. It is hardcoded to run:./conf/locale
, except those from the contrib apps,./locale
, and it requires this directory to exist, so you must create it manually before you runmakemessages
for the first language.The proper way to run
makemessages
is :cd yourapp; django-admin.py makemessages ...
. That raises no warningsI agree it's a bit tedious if you maintain one set of translation set per app, like I do.
But it works as documented on https://docs.djangoproject.com/en/1.3/howto/i18n/ (search for "To create message files..."). So we can't count this as a bug.
Let's imagine an improved
makemessages
that would look forlocale
directories in the whole subtree, and for each of them, run the equivalent of the currentmakemessages
from the containing directory. There are some edge cases: what if you havefoo/locale/bar/locale
?. And this still doesn't handleLOCALE_PATHS
, because when django just gets a catalog fromLOCALE_PATHS
, it has no way to know where the corresponding source files are.To sum up, there is no bug, and making
makemessages
smarter would be hard, enough to require a discussion on the django-developers mailing list. As a consequence, I will close the ticket. If you want to improvemakemessages
, could you elaborate your proposal on the mailing list?