Pygettext: Support translator comments

[tomasr8]

Feature or enhancement

Proposal:

Most gettext extraction tools such as xgettext or pybabel allow one to extract additional comments written by
the programmer which are meant to be read by the translator. These are prefixed with #. in the PO file.

The comments typically look something like this:

# i18n: Translator comment
_('foo')

This can be extracted with e.g. xgettext using xgettext --add-comments=i18n:

#. i18n: Translator comment
msgid "foo"
msgstr ""

Since this is a pretty widely used feature I propose we add this to pygettext as well.

Has this already been discussed elsewhere?

This is a minor feature, which does not need previous discussion elsewhere

Links to previous discussion of this feature:

No response

Linked PRs

• gh-130057: Pygettext: Support translator comments #130061

[serhiy-storchaka]

There are few more differences from xgettext:

• xgettext only supports one tag. If you use --add-comments several times, only the last one has effect. The documentation is not clear about this. In Python, implementing either behavior is equally easy, but in C supporting multiple tags would add much complexity.
• xgettext looks not for a prefix, but for a substring. So --add-comments=8n: will find strings with the "i18n:" prefix and then remove "i1". This is weird, and this contradicts the documentation.
• xgettext strips initial whitespaces from the tag for some reasons. I think this is the part of the above wart. I do not see reasons for this.

[tomasr8]

xgettext only supports one tag. If you use --add-comments several times, only the last one has effect. The documentation is not clear about this. In Python, implementing either behavior is equally easy, but in C supporting multiple tags would add much complexity.

Yes, xgettext doesn't allow this, and it's quite confusing since it doesn't warn when you specify --add-comments multiple times. I think we should support multiple tags (as babel does) since it's quite easy to do so.

xgettext looks not for a prefix, but for a substring. So --add-comments=8n: will find strings with the "i18n:" prefix and then remove "i1". This is weird, and this contradicts the documentation.

Definitely strange, the docs say: "place comment blocks starting with TAG and preceding keyword lines in output file". Again, I think sticking with a prefix is the best option here.

xgettext strips initial whitespaces from the tag for some reasons. I think this is the part of the above wart. I do not see reasons for this.

Do you mean whitespace between # and the tag? e.g.

#       i18n: lots of space
_('foo')

[serhiy-storchaka]

Do you mean whitespace between # and the tag?

No, whitespaces at the start of the argument. --add-comments=" i18n:" is the same as --add-comments=i18n:.

[serhiy-storchaka]

I think we should support multiple tags (as babel does) since it's quite easy to do so.

Well, if babel does this, it is an argument for implementing such behavior.