Code

Opened 6 years ago

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

Description

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

Download all attachments as: .zip

Change History (14)

comment:1 Changed 6 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

whoops, i meant apps...ignore apps.

comment:2 Changed 6 years ago by mtredinnick

  • Keywords make, messages removed
  • Summary changed from make-messages should be able to ignore projects that have their own locale to make-messages should be able to ignore apps that have their own locale directory
  • Triage Stage changed from Unreviewed to Accepted

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 6 years ago by ramiro

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

comment:4 Changed 6 years ago by mtredinnick

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 6 years ago by garcia_marc

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

  • Cc flosch added

comment:7 Changed 6 years ago by jezdez

  • Cc jezdez added

comment:8 Changed 5 years ago by garcia_marc

  • Owner changed from nobody to garcia_marc
  • Status changed from new to assigned

Changed 5 years ago by garcia_marc

Patch 1 from duplicated ticket

Changed 5 years ago by garcia_marc

Patch 2 from duplicated ticket

comment:9 Changed 5 years ago by garcia_marc

  • Has patch set
  • Patch needs improvement set

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

comment:10 Changed 5 years ago by garcia_marc

  • Needs documentation set

Probably it's worth mentioning the new behavior on http://docs.djangoproject.com/en/dev/topics/i18n/#message-files

comment:11 Changed 5 years ago by garcia_marc

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

http://groups.google.com/group/Django-I18N/browse_thread/thread/e24ccc3bfc0c8ac3

comment:12 Changed 4 years ago by jezdez

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

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

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.