Looks like gpg 2.2 doesn't emit a canceled status log message, but gpg 2.4 does if the problem only occurs with VSD but not with Gpg4win.

Actually I would like to remove the option to install gpg4win at non-standard places because this is somewhat troublesome. However some users rely on this and thus we better don't remove i.

Works, tested with VS-Desktop-3.2.94.474-Beta

What components of Gpg4win other than GnuPG do you use?

Yes, that's by design. GnuPG is always installed in $INSTDIR\..\GnuPG by the gpg4win installer.

Yeah that is a messed up environment mixing elf and windows binaries. There is no which on windows. It is called where. So if your terminal is able to execute which then this is some kind of Linux environment on Windows. The winpty error comes from the terminal. Please use cmd.exe for all tests.

The layout is totally different now in VS-Desktop-3.2.94.474-Beta but the "generate new key" action is now hidden for the slots (while still there in Gpg4win 4.4).

I just tried to call pinentry directly on Windows cmd prompt:

Works. Tested with VS-Desktop-3.2.94.474-Beta and Gpg4win 4.4

Thanks for the comments. This is a regular git for Windows install which afaik uses mingw64. The messup with the binaries brought in by git has always been this way. I am using aliases to differentiate between the different versions. One might think that this may cause things to break, however all used to work well with 4.x versions.

gpg: [stdin]: clear-sign failed: No pinentrysrc/libwinpty/winpty.cc, line 924

Here you are:

This problem has gone in libgpg-error 1.51, since the implementation doesn't use environ any more.

Installing language-pack-tr-base fixed the issue. Closing. Sorry for the noise.

Works. Tested with VS-Desktop-3.2.94.474-Beta and Gpg4win 4.4 by moving only the signature key to a smartcard and then changing the password of the certificate via the context menu.

In T7454#196228, @werner wrote:

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

LANGUAGE= LANG= LC_MESSAGES=de_DE gpg

Thus this should work. But it did only work when I used

LANGUAGE= LANG= LC_MESSAGES=de_DE.UTF8 gpg

Thus the whole thing is related to the configuration of locale.alias and on whether LANGUAGE is set in the environment (for me it is set to en_US:en

Actually not a bug: In my tests I forgot to unset LANGUAGES and LANG before calling gpg.

I can replicate this. A quick strace with LC_MESSAGES=de_DE shows (gnupg master)

Backported for VSD 3.3.

Another data point:

$ locale
LANG=de_DE.UTF-8
LC_CTYPE=en_US.UTF-8
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Are you sure that the translations for gnupg are installed? On Tumbleweed translations are usually in a separate package. After installing the gpg2-lang package I get this when I force the Turkish translation:

$ LANGUAGE=tr_TR gpg --version
gpg (GnuPG) 2.5.2
libgcrypt 1.11.0
Copyright (C) 2024 g10 Code GmbH
License GNU GPL-3.0-or-later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.