In the past I have also seen quite often that the Qt Translations with standard actions like OK and Cancel were translated differently then KDE Strings. So there is also some difference with that on Windows.

KConfig uses the default locale instead of the system locale by default it seems:
https://invent.kde.org/frameworks/kconfig/-/blob/master/src/core/kconfig.cpp?ref_type=heads#L118
This should probably also use a copy of ki18n's getSystemLocale() instead. Or we set Qt's default locale to this value to get KConfig to use it.

Don't change the existing KDE behavior for loading the correct Qt translations which is the same as gettext's behavior. It took quite some time to get it right on Windows for KDE. The important bits for making the language configured by the user work are in
https://invent.kde.org/frameworks/kxmlgui/-/blob/master/src/kswitchlanguagedialog_p.cpp?ref_type=heads#L64
where the user-configured languages are prepended to LANGUAGE and in
https://invent.kde.org/frameworks/ki18n/-/blob/master/src/i18n/main.cpp?ref_type=heads#L65
where we make sure that we load the correct Qt translations also on non-Linux systems (where Qt doesn't respect LANGUAGE).

checked with Gpg4win-4.3.2-beta41:

With debug output I have confirmed that KConfig uses the defaultLocale at this point to read the VS-NfD name. So one issue here is that KConfig needs to use the Language configured for translations when reading out the config from which we take the VS-NfD name.

I am a bit wary about making this configurable, mostly because this means quite a bit more complexity in the code as the view need to handle two different modes. For the basic usecase of having only one profile/password store, we probably should not show the store name.

We decided how it should be implemented.

I like the idea, but others might not.
Maybe the behavior could be made configurable?

• Rename to "GnuPG Configuration Dump"
• Change file extension to .txt
• Add Close button
• Set window title

as this is a regression, I would like to have a fix in the upcoming release

The garbled data might be due to a bug in dumpasn1 (version 2021-02-12).

looks fine, gpg4win-Beta41

Try it. It does not do what you think ;-)
You will revoke the certification of the User-Id and not remove that one certification. I should have taken a better example for the screenshot:

I'd say having the "Remove Certification" action when a certification is selected does make sense.

Icon is there in GnuPG-VS-Desktop-3.2.93.32-Beta

and an additional patch to remove the groups button from the toolbar if groups are disabled: https://invent.kde.org/pim/kleopatra/-/merge_requests/261

I created a merge request here https://invent.kde.org/carlschwan/gpgpass/-/merge_requests/3

We have solved this now by showing a configurable error message in that case instead of hard failure with a cryptic error in T6683: GpgOL: Configurable error if sign is selected and prefer_smime

Noticed this again that it was very slow. I guess how fast it is depends on your wine configuration. I worked it around by disabling winepath for me again. But do we want to change anything here or just move this to wontfix?

tested with Version VS-Desktop-3.2.93.32-Beta

works

done (gpg4win -Beta41)

Followup: Using edge and a restart did not trigger the installation of of CN=ISRG Root X1,O=Internet Security Research Group,C=US.

I notices this again, even though my display language is german and Kleopatra is german the GnuPG system is using english (gpg-error --locale says en_IE). en_IE was set by virtualbox during windows installation. No environment variables are set related to language.

Looks good, gpg4win-Beta41:

Done, checked with Gpg4win-Beta41