I think whether --disable-nls is exclusively related to the software may be a
matter of interpretation.

Why? Why not to use --charset to set encoding? Why escaping is needed if this
mode (with-colons) is not appointed to diplay( isn't it?) but to get keys
information to applications?

Your keyring is corrupted. You better get a backup.

we don't have any tr directory. It is anyway planned to switch the whole site
over to only use utf-8.

I tried to descrypt with different versions of gpg. But all failed. The only one
working is 1.4.2.1 from the cygwin package. Then I reinstalled version 1.4.5
from gpg4win 1.0.6 package. Typing in the passphrase constantly fails, but when
the passphrase is stored in an environment variable and piped into gpg (called
with --passphrase-fd 0) then decryption works fine. My passphrase contains some
special characters of the iso88591 characterset for security reasons. But this
should not make any difference. But I suspect it's a matter of charactersets
when reading the passphrase. I suppose it's not being read from stdin (fd 0)...

I had no other idea how to narrow down the problem. Decryption used to work with
WinPT. Because it no longer worked as of version 1.0 I tried to decrypt directly
calling gpg that came along with gpg4win (which didn't work either). So I tried
to use an older version of gpg in order to proof if the keyrings are ok and working.
I had no copy of gpg version 1.4.4. As far as I remember it worked up to and
including gpg 1.4.4. Cygwin's gpg proved that the keyring's and the passphrase
are working.
Hence I concluded that it must be a problem of gpg 1.4.5