Re: What about empty msgctxt?

[Bruno Haible]

Hello Chusslove,

Chusslove Illich wrote:
> As it is now, if the code contains pgettext call with empty context, the
> resulting POT will contain empty msgctxt field.

Yes, sure.

> this will then confuse 
> PO processing tools which make no difference between no context and empty
> context (which I find to be natural assumption

The gettext documentation
  <http://www.gnu.org/software/gettext/manual/html_node/PO-Files.html>
says "Note that an empty CONTEXT string and an absent 'msgctxt' line do not
mean the same thing." Therefore you can report this as a bug to the maintainers
of such PO processing tools.

> So I'm wondering if empty contexts should be, and to what extent, prevented
> already on the level of Gettext's own tools.

The spec is clear about it; see above. In
  <http://www.gnu.org/software/gettext/manual/html_node/Contexts.html>
we explain that the choice of the semantics of the context is a decision
that the programmer has to make. I don't see a good enough reason to make
this decision harder by disallowing empty contexts. (We have enough trouble
already with empty msgids.)

> I'd personally crack on empty 
> contexts hard: xgettext to issue warnings and not extract such calls at all,
> and msgfmt and msgmerge to consider empty msgctxt field a fatal error (in
> case xgettext was not used to extract POT).

On the contrary, generally, it's good if programs handle the extreme cases
fine. Would you like, say, "ls" to generate an error message if the current
directory contains 0 files? Just because 0 is an abstract entity that some
people cannot grasp?

> a problem of this kind iced two unrelated PO processors

Please have them fixed.

Bruno