makemessages command doesn't respect LOCALE_PATHS setting

[heylinus]

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.

[Aymeric Augustin]

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?

[Ramiro Morales]

agree this is something that isn't completely eas 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.

[Aymeric Augustin]

Change UI/UX from NULL to False.

[EmilStenstrom]

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.

[rivolaks@…]

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.

[Claude Paroz]

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

[Aymeric Augustin]

Sounds great!

[Claude Paroz]

I've just updated the patch to current master and created a pull request: ​https://github.com/django/django/pull/1706

[Claude Paroz]

I plan to commit the patch in the next days.

[Claude Paroz <claude@…>]

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.

[termopetteri]

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

[Claude Paroz]

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.