You say that this creates all kinds of problems, but you one cite one case,
which is a fixed bug in zsh. Can you give me a few more examples so that I can
better understand the problem and decide on the best solution. Thanks.

Just run a search about "non-breaking space" and you'll see. Now I'm wondering why
you are asking: is that non-breaking space meant to be there? in case yes, I'd be
curious about the case it serves. I just quickly assumed it is a bug. Ciao

I was actually wrong (my French is too rusty) "phrase" is a French word.

The non-breaking spaces are contained into .po translated files for French and
Czeck languages for GnuPG-2. If you don't agree well then I'd recommend
consistency across all .po files, using non-breaking spaces also in other
translations and specify this choice in GnuPG's documentation.

Either way I'd be happy to contribute myself a patch for this issue, on top of
current git HEAD.

Removing non-breaking spaces is a regression. Their appropriate use improves
readability. See, for instance, the following discussion:
https://tex.stackexchange.com/questions/15547/when-should-i-use-non-breaking-space
. If you have patches to improve the use of non-breaking spaces (adding them
where appropriate and removing them when they aren't as per the above), these
would be welcome.

As far as I can tell, this output shouldn't really be parsed anyways: it's only
intended for humans. Please feel free to ask on gnupg-devel how to
appropriately do what you are trying to do.

Thanks.

I fully agree and I can only repea: Do not parse the output intended for humans
but use the --status-fd option. There is no excuse in not doing so.

Sure. The issue of consistency across translations is just nitpicking.

The issue of parsing is solved as +notabug for gnupg, since the bug was actually in
ZSh - and is now fixed. Even in older Zsh version can be avoided by decoupling stdin
and stderr in the parsing, basically using --status-fd. I should have done that in the
first place. Apologies for emphasizing this here, as Gnupg offers all the correct
facilities to decouple the output streams.

Unrelated with the issue above, I still think that normalization of white-space usage
across different translations would be an improvement, but since doing it requires a
semantic analysis that is contextual to the language, its quite hard to realize now.
Perhaps a good idea that documentation for translators include a note about white-
space usage. But again, this is nitpicking. Feel free to close the issue.

I'm marking this issue as resolved.