You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
pygettext generates output even when there should be none #133049
Output is still generated when there is no input. Whereas xgettext:
$ xgettext
xgettext: no input file given
Try 'xgettext --help' for more information.
And the second case follows on from this (but can also occur with input files)
In xgettext, no output is generated if there are no messages. In pygettext output is still generate even if no messages are found, the header is still sent.
We should fix it to work like xgettext and not produce "empty" output.
Commenting here as well. I think the input file should be required, I think that one is clear.
As for not producing any output if there are no messages, I'm not so sure. There's nothing wrong with an empty po file and it might just be the case that your sources happen to have no gettext calls that can be extracted. So I lean more towards keeping this behaviour.
I'd like to fix only the first case: no input files given.
Plan:
If no input files are given, print pygettext: no input file given / Try 'pygettext --help' for more information. to stderr and exit 1, like xgettext.
Update the existing tests that run pygettext without an input file (test_header, test_POT_Creation_Date, test_output_option), add a test for the new error, and add a NEWS entry.
I'd leave the second case (no output when no messages are found) out, since @tomasr8 leaned toward keeping the empty .pot.
Activity
StanFromIreland commentedon Apr 27, 2025
tomasr8 commentedon Apr 27, 2025
Commenting here as well. I think the input file should be required, I think that one is clear.
As for not producing any output if there are no messages, I'm not so sure. There's nothing wrong with an empty po file and it might just be the case that your sources happen to have no gettext calls that can be extracted. So I lean more towards keeping this behaviour.
ZeroIntensity commentedon Apr 27, 2025
@picnixz Unrelated to this issue, but I've seen you throw the
triagedlabel on a few things. What criteria should we follow for adding that label?StanFromIreland commentedon Apr 27, 2025
I’ve asked that before ;-)
He does it for tools as there is no label for them.
ZeroIntensity commentedon Apr 27, 2025
Ah. I assume he's been shot down on a
topic-toolslabel before?StanFromIreland commentedon Apr 27, 2025
Yes, he tried in core-workflow but his issue was closed as a duplicate of a closed issue where no conclusion was reached. :-(
tomasr8 commentedon Apr 27, 2025
It's a shame GH only shows the labels and not projects on the issues page :/
picnixz commentedon Apr 27, 2025
I use "triaged" whenever I want to indicate to myself "hey don't look at this issue again, you've already checked it..."
maheshrijal commentedon Oct 25, 2026
I'd like to fix only the first case: no input files given.
Plan:
pygettext: no input file given/Try 'pygettext --help' for more information.to stderr and exit 1, likexgettext.test_header,test_POT_Creation_Date,test_output_option), add a test for the new error, and add a NEWS entry.I'd leave the second case (no output when no messages are found) out, since @tomasr8 leaned toward keeping the empty .pot.