Opened 9 years ago

Closed 7 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: master
Severity: Keywords:
Cc: flosch, Jannis Leidel Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: no Patch needs improvement: yes
Easy pickings: UI/UX:


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 7 years ago.
Patch 1 from duplicated ticket
7916_v2.diff (1021 bytes) - added by Marc Garcia 7 years ago.
Patch 2 from duplicated ticket

Download all attachments as: .zip

Change History (14)

comment:1 Changed 9 years ago by anonymous

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

whoops, i meant apps...ignore apps.

comment:2 Changed 8 years ago by Malcolm Tredinnick

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 Changed 8 years ago by Ramiro Morales

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

comment:4 Changed 8 years ago by Malcolm Tredinnick

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 Changed 8 years ago by Marc Garcia

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 Changed 8 years ago by anonymous

Cc: flosch added

comment:7 Changed 8 years ago by Jannis Leidel

Cc: Jannis Leidel added

comment:8 Changed 7 years ago by Marc Garcia

Owner: changed from nobody to Marc Garcia
Status: newassigned

Changed 7 years ago by Marc Garcia

Attachment: 7916.diff added

Patch 1 from duplicated ticket

Changed 7 years ago by Marc Garcia

Attachment: 7916_v2.diff added

Patch 2 from duplicated ticket

comment:9 Changed 7 years ago by Marc Garcia

Has patch: set
Patch needs improvement: set

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

comment:10 Changed 7 years ago by Marc Garcia

Needs documentation: set

Probably it's worth mentioning the new behavior on

comment:11 Changed 7 years ago by Marc Garcia

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

comment:12 Changed 7 years ago by Jannis Leidel

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