#10004 closed (fixed)
Enable -c switch in xgettext call to collect translator comments
| Reported by: | Claude Paroz | Owned by: | |
|---|---|---|---|
| Component: | Internationalization | Version: | 1.0 |
| Severity: | Keywords: | makemessages | |
| Cc: | clouserw@…, martinb | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
gettext infrastructure provides for translator comments in source code (just on the line before the string to translate) to be copied into po files. However, this required the -c (--add-comment) option to be passed to xgettext. Please add this in makemessages.py ("xgettext -c -d ...").
Attachments (4)
Change History (23)
comment:1 by , 16 years ago
| Component: | django-admin.py → Internationalization |
|---|---|
| Owner: | changed from to |
| Status: | new → assigned |
comment:2 by , 16 years ago
| Owner: | removed |
|---|---|
| Status: | assigned → new |
Whoops. Didn't mean to assign this to me. Anybody can do this with care and research.
comment:3 by , 16 years ago
| Triage Stage: | Unreviewed → Accepted |
|---|
comment:5 by , 15 years ago
| Cc: | added |
|---|
comment:6 by , 15 years ago
--add-comments accepts an optional tag which would filter the current comments and prevent needing to go through them all manually. If you set a standard prefix for developer comments it makes extraction easy. For example:
# L10n: This variable is a button
would be extracted with
xgettext --add-comments=L10n
by , 15 years ago
| Attachment: | makemessages.py.diff added |
|---|
Patch for makemessages.py: Call xgettext with -c/--add-comments
comment:7 by , 15 years ago
| Cc: | added |
|---|
The patch I just added is not tested nor do I have any idea whether this is the way to go. Could please somebody have a look at it? TIA.
follow-up: 9 comment:8 by , 15 years ago
I haven't tested it either (it looks ok) but your help text is unclear to me. "place comment block with TAG (or those preceding keyword lines) in output file" - That sounds like it'll grab comments with the tag from anywhere, whereas the comment still needs to be directly before the call to gettext. Might just be the way I'm reading it, but I think this is more clear: Include comments directly before gettext calls in output file. If TAG is specified only comments matching TAG will be included.
comment:9 by , 15 years ago
Replying to clouserw:
I haven't tested it either (it looks ok) but your help text is unclear to me.
I stole this text directly from the xgettext manual page (or help output?) without change.
Include comments directly before gettext calls in output file. If TAG is specified only comments matching TAG will be included.
Yes, this sounds better.
comment:10 by , 15 years ago
| milestone: | → 1.2 |
|---|
comment:11 by , 15 years ago
| milestone: | 1.2 → 1.3 |
|---|
This feels too much like a feature request to be on the 1.2 milestone at this point.
by , 14 years ago
| Attachment: | comment-extraction.patch added |
|---|
Add comment extraction to makemessages with L10n keyword
comment:12 by , 14 years ago
| Has patch: | set |
|---|---|
| Needs documentation: | set |
When reviewing martinb's patch, I wonder what value we add in making the addcomments switch optional and the extraction keyword configurable.
I have proposed a new patch, much simpler, which simply extract comments with the L10n keyword. Extracting translator comments should never be optional IMHO.
About tests, it's slightly messed up in the patch because I reorganized them to not require a new class for each type of test. The only real new test is the test_comments_extractor method.
follow-up: 14 comment:13 by , 14 years ago
I certainly think this is a neat idea, but don't really like the literal that triggers the comment adoption, "L10n". Not having seen this elsewhere, is this again a standard somehow?
The reorganization of the tests isn't really necessary and actually makes it harder to backport single tests to 1.2.X. I'd appreciate it if that could be reverted.
comment:14 by , 14 years ago
I certainly think this is a neat idea, but don't really like the literal that triggers the comment adoption, "L10n". Not having seen this elsewhere, is this again a standard somehow?
There is no standard that I know of. The goal is something short, unique, and relevant; "L10n" fits the bill. We started using it at Mozilla years ago and continue to do so.
by , 14 years ago
| Attachment: | comment-extraction-2.patch added |
|---|
Comment extraction without tests refactoring
comment:15 by , 14 years ago
Patch revised. I have no personal preference for the comment keyword, and I don't think there is any standard about it. I've seen "xgettext:" (don't like it at all), "Translators:" (a bit verbose?).
by , 14 years ago
| Attachment: | comment-extraction-3.patch added |
|---|
Comment extraction with documentation
comment:16 by , 14 years ago
| Needs documentation: | unset |
|---|
comment:17 by , 14 years ago
Looks good to me, maby "l10n" for the keyword would be better, e.g. Pootle uses it here: https://translate.svn.sourceforge.net/svnroot/translate/src/trunk/Pootle/local_apps/pootle_app/management/commands/makepropermessages.py
comment:18 by , 14 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
I thought there was already a ticket open for this, but I can't find it now. So maybe it's just one of those things that's been on my TODO list for ages. We should certainly do something like this. We need to specify (and document) a tag to mark the comments to include, since there are lots of places where there are comments preceding translation calls that are not at all relevant to the localisation process.