Opened 13 years ago

Closed 11 years ago

Last modified 9 years ago

#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 anonymous, 13 years ago

Summary: makemessage command doesn't respect LOCALE_PATHS setting at allmakemessages command doesn't respect LOCALE_PATHS setting at all

comment:2 by anonymous, 13 years ago

Version: SVN1.3

comment:3 by Aymeric Augustin, 13 years ago

Resolution: invalid
Status: newclosed
Type: BugNew feature

Currently, makemessages doesn't handle multiple locale folders at all. It is hardcoded to run:

  • from django's source tree: it will gather all translations in ./conf/locale, except those from the contrib apps,
  • from a project's or an app's source tree: it will gather all translations in ./locale, and it requires this directory to exist, so you must create it manually before you run makemessages for the first language.

The proper way to run makemessages is : cd yourapp; django-admin.py makemessages .... That raises no warnings

I 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 for locale directories in the whole subtree, and for each of them, run the equivalent of the current makemessages from the containing directory. There are some edge cases: what if you have foo/locale/bar/locale?. And this still doesn't handle LOCALE_PATHS, because when django just gets a catalog from LOCALE_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 improve makemessages, could you elaborate your proposal on the mailing list?

comment:4 by Ramiro Morales, 13 years ago

Resolution: invalid
Status: closedreopened
Summary: makemessages command doesn't respect LOCALE_PATHS setting at allmakemessages command doesn't respect LOCALE_PATHS setting
Triage Stage: UnreviewedAccepted

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.

Last edited 13 years ago by Ramiro Morales (previous) (diff)

comment:5 by Aymeric Augustin, 13 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:6 by anonymous, 13 years ago

Version: 1.31.4

comment:7 by EmilStenstrom, 12 years ago

Cc: em@… 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 rivolaks@…, 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 Claude Paroz, 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.

https://github.com/claudep/django/compare/16084

comment:10 by Aymeric Augustin, 12 years ago

Sounds great!

comment:11 by Aymeric Augustin, 12 years ago

Status: reopenednew

comment:12 by Claude Paroz, 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 Claude Paroz, 11 years ago

Triage Stage: AcceptedReady for checkin

I plan to commit the patch in the next days.

comment:14 by Claude Paroz <claude@…>, 11 years ago

Resolution: fixed
Status: newclosed

In 50a8ab7cd1e611e6422a148becaec02218577d67:

Enabled makemessages to support several translation directories

Thanks Rémy Hubscher, Ramiro Morales, Unai Zalakain and
Tim Graham for the reviews.
Also fixes #16084.

comment:15 by termopetteri, 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 Claude Paroz, 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.

Note: See TracTickets for help on using tickets.
Back to Top