Code

Opened 3 years ago

Closed 5 months 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.

Attachments (0)

Change History (14)

comment:1 Changed 3 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Summary changed from makemessage command doesn't respect LOCALE_PATHS setting at all to makemessages command doesn't respect LOCALE_PATHS setting at all

comment:2 Changed 3 years ago by anonymous

  • Version changed from SVN to 1.3

comment:3 Changed 3 years ago by aaugustin

  • Resolution set to invalid
  • Status changed from new to closed
  • Type changed from Bug to New 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 Changed 3 years ago by ramiro

  • Resolution invalid deleted
  • Status changed from closed to reopened
  • Summary changed from makemessages command doesn't respect LOCALE_PATHS setting at all to makemessages command doesn't respect LOCALE_PATHS setting
  • Triage Stage changed from Unreviewed to 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.

Last edited 3 years ago by ramiro (previous) (diff)

comment:5 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:6 Changed 2 years ago by anonymous

  • Version changed from 1.3 to 1.4

comment:7 Changed 20 months ago by EmilStenstrom

  • 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 Changed 19 months ago by 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.

comment:9 Changed 15 months ago by claudep

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 Changed 15 months ago by aaugustin

Sounds great!

comment:11 Changed 13 months ago by aaugustin

  • Status changed from reopened to new

comment:12 Changed 7 months ago by claudep

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

comment:13 Changed 5 months ago by claudep

  • Triage Stage changed from Accepted to Ready for checkin

I plan to commit the patch in the next days.

comment:14 Changed 5 months ago by Claude Paroz <claude@…>

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

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.

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.