Opened 16 years ago

Closed 14 years ago

#7050 closed (fixed)

make-messages should be able to ignore apps that have their own locale directory

Reported by: Italo Maia Owned by: Marc Garcia
Component: Internationalization Version: dev
Severity: Keywords:
Cc: flosch, Jannis Leidel Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no


Just as the title says. I like to place my apps and apps avaiable on the net inside my project,
so, this functionality would be the most welcomed!

Attachments (2)

7916.diff (1005 bytes ) - added by Marc Garcia 15 years ago.
Patch 1 from duplicated ticket
7916_v2.diff (1021 bytes ) - added by Marc Garcia 15 years ago.
Patch 2 from duplicated ticket

Download all attachments as: .zip

Change History (14)

comment:1 by anonymous, 16 years ago

whoops, i meant apps...ignore apps.

comment:2 by Malcolm Tredinnick, 16 years ago

Keywords: make messages removed
Summary: make-messages should be able to ignore projects that have their own localemake-messages should be able to ignore apps that have their own locale directory
Triage Stage: UnreviewedAccepted

Good idea. This should be the default behaviour.

In fact, ideally, if an application has a locale/ directory and make-messages is run from the top-level project directory, the strings in that app should update the app's own locale/ directory, rather than the project's directory. That will make it easy to update all the strings under a single directory and not accidentally forget any.

comment:3 by Ramiro Morales, 16 years ago

#7916 was a duplicate and contained a patch implementing the feature described by the OP.

comment:4 by Malcolm Tredinnick, 16 years ago

Although I'm not completely in line with Marc's thinking in #7916, it does point out one problem with the approach I suggested: updating third-party apps may not actually be possible (e.g. they're installed in a read-only directory) or not desired (because they're not our responsibility). The second case is of more concern, since it might involve writing to a file we don't want to. How to control this without making things too complicated needs some thought (or maybe we just don't worry too much, since it can always be cleaned up afterwards in both cases).

By the way, the main concern I have with the #7916 approach (update the main file unless a file exists for that language in the app) is that it seems to lead to maintenance problems down the road and is violating the separation of responsibilities. If an app says "I am doing translations", then that app should be responsible for its own translations , all those translations in one place (not having some of them in another file), and encouraging people to translate the app, rather than putting the translation into their project-level file. However, from the perspective of "I just want the strings translated", I can understand Marc's approach (i'm not saying I think it's the ideal solution, but I understand the wish to just get the thing translated). I want to think about this a bit more and will definitely keep the other patch in mind.

Anybody else with a good idea should pipe up (here or on django-i18n if it looks like it's getting complicated).

comment:5 by Marc Garcia, 16 years ago

If I'm understanding well, what you think my second patch does, it isn't exactly like that. The patch doesn't translate missing strings from an incomplete language on a application. It just translates languages that doesn't exist in the application. Of course it would be better (more organized) to translate none or all language inside the application, but if it isn't possible or desired, then IMHO the best is including that language in the project catalog.

A "real" example could make it clearer. I install transdb application in my project as external, and transdb is translated to english and catalan but not spanish. My project will be available in english, catalan and spanish, so what I need is to translate my own code, and also translate transdb to spanish. I did it, but after some weeks transdb author hasn't updated his project with my translation. I prefer not to modify transdb code, because I update it often and I don't want conflicts (should never happen). So the best would be include as well as my own code translation, translations from transdb in spanish catalog. For cases where it's possible to add translations directly to applications (making translations reusable) the patch will work well too.

Btw, thanks ramiro, I couldn't found this one before opening new ticket.

comment:6 by anonymous, 16 years ago

Cc: flosch added

comment:7 by Jannis Leidel, 16 years ago

Cc: Jannis Leidel added

comment:8 by Marc Garcia, 15 years ago

Owner: changed from nobody to Marc Garcia
Status: newassigned

by Marc Garcia, 15 years ago

Attachment: 7916.diff added

Patch 1 from duplicated ticket

by Marc Garcia, 15 years ago

Attachment: 7916_v2.diff added

Patch 2 from duplicated ticket

comment:9 by Marc Garcia, 15 years ago

Has patch: set
Patch needs improvement: set

Just uploaded patches on ticket 7916, that is a duplicate of this one.

comment:10 by Marc Garcia, 15 years ago

Needs documentation: set

Probably it's worth mentioning the new behavior on

comment:11 by Marc Garcia, 15 years ago

Note that I created a thread on django-i18n to discuss about this ticket

comment:12 by Jannis Leidel, 14 years ago

Resolution: fixed
Status: assignedclosed

(In [12444]) Fixed #7050 - Allow the makemessages command to optionally ignore paths when examining source code and templates for translation strings.

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