Given the proposed workaround, I'd say we don't fix that.

Thanks, applied.

I did the changes as suggested and fixed the typos you mentioned. I also removed
some old cruft. Thanks.

D67: 194_gnupg2_de_po_081206.diff

Found 3 typos after the update. Can you accept them without the disclaimer? Diff
attached.

I cannot reproduce this problem anymore. Neither with the test case
script, nor during ssh authentication with several card-reinsertions.

Right, this seems to be a charset problem. As per rfc4880 (ans also 2440),
OpenPGP specified all text to be UTF-8 encoded. However PGP used to ignore any
character sets and thus implicitly assumed Latin-1. Except for the rarely used
charset clearsign header (which gnupg does not support) there is no way to know
the charset. Further there is often a conflict between the MIME stated charset
and the assumed one of a clearsigned message

Is this still an an issue (2.0.4 is pretty old)?

According to the changelog fixed on 2008-01-30 and thus released with 1.4.9.

Redirect stdin from /dev/null seems to work as a workaround and I will change
my application to call it like that. But it was my understanding that the --
batch flag explicitly means that the program should never expect input on
stdin. Allowing the program to hang waiting for stdin seems to go against the
point of that option.

Moritz, this should be fixed in the current SVN of 2.0.10. Would you mind to
test it?

Duplicate of T949

It seems that I can close this bug.

I see the problem but it is sill a lot of work to fix that.

I am sorry, but the sample file is not useful for me. It requires the use of
the IDEA algorithm. I can't use this.

I have fixed and updated the translation myself.

This would be too complicated to fix. It is not just --passphrase but also
--use-agent which gets into the game.

Fixed in svn revision 4881. Might needpo file updates. That will be done at
the time of the release.

Thanks. I configured a redirect.

I noticed the word and I tried to check this carefully. I found no reference for
a word "anlisten" (Duden, Canoo, dict.leo.org ... even $search-engine only
listed a few references). Seems this is a word creation and therefor I changed it.

You should coordinate with the designated translator before changing the syle of
the translation. I have not checked whether you have filed the required
copyright disclaimer with the FSF.

Just as a quick follow-up to this script I wrote:

Moritz Schulte created a test case for this or a similar problem:

Admin PIN via pinpad are enabled since 2.0.9.

And here a fix for the stable version.

D68: 183_gnupg_1_4_de_po.diff

When doing an external key listing, gpgsm asks the configured LDAP servers to
return matching certificates. All returned certificates are shown. Given that
there is no common rule on how to search LDAP servers for certain certificate
attributes, Dirmngr uses a very general filter to do the search. This yields
more certifciates than the internal search implemented in GnuPG.

Fixed in my working copy.

Changed in GnuPG trunk 4849.

Checking the text from T960 (wk on Oct 13 2008, 10:45 AM / Roundup):
I think the text is a significant improvement.

Okay, I change the man page to read: