Yes, the function to load the user-configured language on application start is very well hidden in kxmlgui. :-)

I mean the system configuration of Windows is just strange and messy. I am only noticing this now more because for my latest Test VMs I used VIrtual Box unattended installation, which installs the system according to the Hosts locale and then you can change the language for your user in Windows. And I ended up with this setting here where the preferred languages differ from the Windows UI language. And we are not alone in a confusion, on this system also Paint is in english, and the Microsoft Calculator, but not Powershell or CMD 🙄 But as GetUserPreferredUILanguages should return (and does according to my tests) the display langue chosen in the drop down as Language[0] and the others with lower priority I think the correct behavior here is to be in German.

In T3733#189355, @ikloecker wrote:

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.

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.