This has already been fixed by Tobias, but the fix needs to be backported (because this also happens in the branch VSD 3.3 is built from).

The latest commit cannot be backported for VSD 3.3 because it depends on changes made for T7153: Kleopatra: Show all search results (from different origins)/T7155: Kleopatra: Show additional columns in search results by default.

Backported for VSD 3.3

Backported for VSD 3.3

Backported for VSD 3.3

Done. Unit tests verify the API. End-to-end testing will be done with T7234: Kleopatra: add disable/enable certificate in context menu. Hence, setting to Resolved.

Setting this to testing. Could be tested as described in https://dev.gnupg.org/T7188#188093 by verifying that the logged debug messages also use correct encoding.

"Holder" doesn't exist for anything but OpenPGP cards and many people may not set it. Hence, I think it makes little sense to show this in a prominent location if it's empty for most users who don't juggle with loads of OpenPGP cards.

Okay. Done in gpgme for gpgrt >= 1.51 (T7188).

Now even the error descriptions that are logged by background threads should have readable umlauts (see T7188).

Screenshots of current state:

Mark for backport. In the past all columns were resized to fit their contents when a single column was made visible.

Mark for backport

@werner Would it be okay to call gettext_use_utf8 (3) in gpgme's do_subsystem_inits where we currently call gettext_use_utf8 (1)? See https://dev.gnupg.org/source/gpgme/browse/master/src/version.c$77

Actually, it seems to be spelled "smart card" in English (e.g. in Merriam Webster and Oxford English Dictionary). Two words. It's just us ignorant Germans who like to glue words together as if there's no tomorrow.

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

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).

All tables should now show the keygrip without spacing.

This task only dealt with the lower pane. It added the warning icon and the tool tip "This certificate cannot be used for encryption." For the upper pane see T6722.

Yes, we can phase it out in master which is what Nico is talking about and which uses Qt 6/KF6. Nobody is going to remove KIconLoader from KF5.

Daniel wrote a migration tool which was merged in January (https://invent.kde.org/pim/akonadi/-/merge_requests/154), i.e. a few weeks after he wrote the documentation. He foresaw that the documentation "will go out-of-date quickly". ;-)

Unfortunately, sentence like UIs are a nightmare for translators. The only thing that works for all languages is self-contained text fragments.

The latest changes have been backported for VSD 3.3.

Let's not make the filtering more complex. It's already complex enough with the search field and the filter drop down. If we want more flexible filtering then this should be solved in a general way and not as Sonderlocke for "disabled". "disabled" is really a niche feature and, in my opinion, doesn't deserve a prominent UI element in the main UI.

In T7089#188733, @ebo wrote:

What I see is: If the status of a certificate is "certified" or "not certified" before disabling it, then Kleo shows "disabled" in the User-ID column. If it was "revoked" or "expired", those are not changed. The same is true for the "Status" info in the details.
Is this distinction on purpose? What is the reason?

Closing.

I cannot reproduce this with Version 3.2.2.2405000+git20240712T143635~6033869e1. I open the Details window, go to Subkeys, right-click table header, select Keygrip, close Details window, open it again, go to Subkeys, Keygrip column is still shown. Even after restarting Kleopatra.

The easiest solution would be a setting for gnupg. Then Kleopatra would just error out. But, as Andre rightfully points out, people will work around this restriction. Users are incredibly creative.

Just to clarify: I didn't say that we should remove the coloring/font style of certificates. I just said that I vote for removing the UI for changing the colors and font style.

I vote for removing the UI for configuring the appearance of the certificate categories completely from Kleopatra. This would solve all usability problems in an instant. People who want to go crazy with colors can edit the rc file.

The high-contrast modes disable all colors, but for normal dark modes we might have a problem with some of the predefined colors.