`pygettext` generates output even when there should be none

[StanFromIreland]

Bug report

Bug description:

This occurs in two cases:

• 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.

I will send a pr soon, once other tests are merged.

cc @tomasr8

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

[StanFromIreland]

Can this please be added to the gettext project so it is fully triaged? :-)

[tomasr8]

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]

@picnixz Unrelated to this issue, but I've seen you throw the triaged label on a few things. What criteria should we follow for adding that label?

[StanFromIreland]

I’ve asked that before ;-)

He does it for tools as there is no label for them.

[ZeroIntensity]

Ah. I assume he's been shot down on a topic-tools label before?

[StanFromIreland]

Yes, he tried in core-workflow but his issue was closed as a duplicate of a closed issue where no conclusion was reached. :-(

[tomasr8]

It's a shame GH only shows the labels and not projects on the issues page :/

[picnixz]

I use "triaged" whenever I want to indicate to myself "hey don't look at this issue again, you've already checked it..."