#24159 closed New feature (fixed)
compilemessages does not behave the same as makemessages
Reported by: | Matthew Somerville | Owned by: | Matthew Somerville |
---|---|---|---|
Component: | Internationalization | Version: | dev |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
makemessages was upgraded in Django 1.7 so that it would automatically put app strings in app specific locale files and other strings in the first LOCALE_PATHS entry, as explained in the "Changed in Django 1.7" part of https://docs.djangoproject.com/en/1.7/topics/i18n/translation/#message-files. This was ticket #16084.
Ticket #20451 was marked as a duplicate of this ticket, but ticket #16084 only improved makemessages, it didn't change compilemessages at all. compilemessages, when run from the same directory as manage.py, will only compile 'conf/locale', 'locale' and the LOCALE_PATHS .po files, it will not compile any app specific locale files that were created by a call to makemessages.
The documentation on compilemessages does not appear to tell you this, https://docs.djangoproject.com/en/1.7/topics/i18n/translation/#compiling-message-files says "This tool runs over all available .po files and creates .mo files". It then says you should run it "In the same directory from which you ran django-admin.py makemessages" which I think is referring to the pre-1.7 behaviour of having to run it in more than one place.
I'm not sure whether it would be better for compilemessages to have the same behaviour as makemessages or for the documentation to update to point out you still need to run it in each app if they have separate locale entries.
Change History (14)
comment:1 by , 10 years ago
Triage Stage: | Unreviewed → Accepted |
---|---|
Type: | Uncategorized → New feature |
comment:3 by , 10 years ago
I have made a pull request for this at https://github.com/django/django/pull/4521
It uses the same algorithm makemessages is doing, walking down the tree and looking for directories named 'locale'.
comment:4 by , 10 years ago
Has patch: | set |
---|
comment:5 by , 10 years ago
Needs documentation: | set |
---|---|
Version: | 1.7 → master |
Code looks okay to me, but needs documentation as noted on the pull request.
comment:6 by , 10 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Will work on at DjangoCon EU sprint :)
comment:7 by , 10 years ago
Needs documentation: | unset |
---|
comment:8 by , 10 years ago
Patch needs improvement: | set |
---|
comment:9 by , 10 years ago
Patch needs improvement: | unset |
---|
comment:10 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
Claude, may I ask for your review?
comment:13 by , 7 years ago
Hi.
I'm using buildout. Both commands, compilemessages (after #24159 patch) and makemessages, introduced new issues. They scan all nested directories, they're reading (makemessages) and creating (compilemessages) files in external eggs and cloned repositories, even in django itself and unused but stored on disk packages. There is no possibility to exclude or include directories to search. And any broken locale file in any package can break compilation process.
comment:14 by , 7 years ago
Please open appropriate tickets with your issues.
And any broken locale file in any package can break compilation process.
This is fixed in master (through #24384).
Good point. Unless you see major drawbacks, I think
compilemessages
should mirrormakemessages
behavior with regard to affected files.