Opened 10 years ago

Closed 9 years ago

Last modified 6 years ago

#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 Claude Paroz, 10 years ago

Triage Stage: UnreviewedAccepted
Type: UncategorizedNew feature

Good point. Unless you see major drawbacks, I think compilemessages should mirror makemessages behavior with regard to affected files.

comment:2 by Claude Paroz, 10 years ago

#24647 was closed as a duplicate

comment:3 by Matthew Somerville, 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 Tim Graham, 10 years ago

Has patch: set

comment:5 by Tim Graham, 9 years ago

Needs documentation: set
Version: 1.7master

Code looks okay to me, but needs documentation as noted on the pull request.

comment:6 by Matthew Somerville, 9 years ago

Owner: changed from nobody to Matthew Somerville
Status: newassigned

Will work on at DjangoCon EU sprint :)

comment:7 by Matthew Somerville, 9 years ago

Needs documentation: unset

comment:8 by Tim Graham, 9 years ago

Patch needs improvement: set

comment:9 by Matthew Somerville, 9 years ago

Patch needs improvement: unset

comment:10 by Tim Graham, 9 years ago

Triage Stage: AcceptedReady for checkin

Claude, may I ask for your review?

comment:11 by Claude Paroz, 9 years ago

Good to go!

comment:12 by Tim Graham <timograham@…>, 9 years ago

Resolution: fixed
Status: assignedclosed

In 40f0a84c:

Fixed #24159 -- Made compilemessages run across all apps.

Updated the command to match the documentation, which states it
runs over all .po files.

comment:13 by Marcin Nowak, 6 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 Claude Paroz, 6 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).

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