This is included in test installers since some time already.

This change is also used for VSD 3.3

Gpg4win-Beta-75: works

Name of the window is now "GnuPG Configuration Overview" and "gpgconf -X" is preselected and executed in the window.

Works, you now get an error message that the card can not be found.

This has been backported for VSD 3.3 and Gpg4win

This symptom can be explained by the nPth bug of T7386.

I guess it's now ready for testing

All changes have been backported for VSD 3.3

I added this to gpg4win master. I assume that this branch will be used for VSD 3.3 and Gpg4win 4.4.

All missing translations mentioned in the original description should now be there (once a new kleopatra snapshot is created).

With Gpg4win-Beta-75+

Forget the explanation. msgcat --use-first works correctly. We didn't use it correctly for our purposes. msgcat --use-first took the first translation of the context-less messages. This happened to be marked-as-obsolete messages in the main po file (because KDE keeps obsolete messages for easier recovery). And since they were marked as obsolete they were dropped when the po file were compiled. The script now removes obsolete messages before merging in additional po files. This way non-obsolete messages in the additional po files don't get shadowed anymore by obsolete messages in the main po files.

I agree, this is done, follow up Tasks will get new tickets

I see. Thanks for explaining. we can of course contact the gettext author (whom I happen to know).

Andre's comment was "Use use first to avoid double translations that confuse it.".

FWIW, Andre had to introduce --use-first to fix another problem.

I have removed the --use-first from the msgcat command that merges the combined messages from KDE's svn and the po file in our repo with the local l10n files for libkleo and kleopatra in gpg4win/packages.

Gpg4win-Beta-75:
This works in principle. That some TCOS cards seem to have a high chance of causing a hang-up of scdaemon is not Kleopatra's fault and that issue is tracked somewhere else. I'm not sure where, probably T7378 or T7379?

The problem seems to be that the msgcat commands in gen-tarball.sh (gpg4win repo) are used with --use-first and that seems to ignore msgctxt when looking for duplicate msgids.

6. "GnuPG VS-Desktop Audit Log Viewer" (nur Fenstertitel unübersetzt)

1. "Valid until (between %1 and %2):" (Schlüsselgenerierung, Erweiterte Einstellungen)

2. Unter Extras -> Zwischenablage: 4 von 5 Unterpunkten nicht übersetzt
3. Lookup on server (nur im Fenstertitel unübersetzt)
4. "Publish on keyserver afterwards" (im Fenster Beglaubigung)
5. "Enter a message to encrypt or decrypt…" Notepad-Placeholdertext

Should be ready for testing

Backported for VSD 3.3

This bugfix shall be backported for VSD 3.3 as discussed with ebo

Latest changes backported for VSD 3.3

Backported for VSD 3.3

And backported for VSD 3.3.

Fixed.

Gpg4win-Beta-75:
Works. The filters are also applied to groups now and match groups even if not all certificates in them conform to the filter rule.
Tested with OpenPGP ans S/MIME filters.

For the record, I add the info here too (was: just in xmpp).

And to make commands run only once when Enter is pressed: https://invent.kde.org/pim/kleopatra/-/merge_requests/320

Hmm, calling QProcess::setStandardInputFile(QProcess::nullDevice()) before start() may be even better than calling closeWriteChannel() after start().

On the Cli, gpg does not give an error but an info message informing that the subkey already exists so there is no error message for Kleopatra to act on.

Fix for the crash https://invent.kde.org/pim/kleopatra/-/merge_requests/318

It works in Gpg4win-Beta-75 to add the ADSK to more than one Key.

The QProcesses we start should be configured with closed stdin so that the started process don't hang waiting for input, e.g. by calling closeWriteChannel() immediately after start(). Or by calling start() with QIODeviceBase::ReadOnly, but, sadly, the documentation of QProcess doesn't document what effect that has.

Gpg4win-Beta-75, works:

Gpg4win-Beta-75: This is in principle ok. Even adding further commands to
C:\Program Files (x86)\Gpg4win\etc\xdg\kleopatradebugcommandsrc works:

@ebo @ikloecker Let me explain my thoughts. If you have time, please help me doing some tests in your environment.

This shell script running gpg-connect-agent should run successfully:

gpg4win-Beta-75:
German tooltip translations are all complete

Gpg4win-Beta-75:
Looks good, I see no "EXCEPTION_ACCESS_VIOLATION" after quitting any more.
Instead only: "process started at 14:11:03.007 has terminated with exit code 0"

Gpg4win-Beta-75: This does not work.

Gpg4win-Beta-75:
Checked the property details of some files in "Progams (X86)" and found several without product name, E.g. libgpg-error-0.dll and other dlls located at C:\Program Files (x86)\GnuPG\bin.
Or gpgolconfig.exe at C:\Program Files (x86)\Gpg4win\bin and the examble from above, libKF5JobWidgets.dll, shows no product name either.

Gpg4win-Beta-75: Symbol is there.

The umlauts are ok again!

Ok with me. setting this to resolved, then.

I like it better than the very long tool tip.

Changed in https://invent.kde.org/pim/kleopatra/-/merge_requests/316

Testing the removal of the appearance flag from this filter leads to this situation:

Hm, probably I would be for the html-tags, then. Is there an example where one could see how narrow tool tips really get with that option?

We shouldn't have to add explicit line breaks. Explicit line breaks will lead to bad formatting (German: Flattersatz) for people who use huge font sizes (a11y!) and Qt will wrap long tool tips so that they won't become wider than the screen. Alternatively, we wrap the tool tips (in the code that sets the tool tips) into <html> tags. Then (for whatever reason) Qt will make the tool tips much narrower. (Some people think too narrow, but we have to die one death.)

Fixed in https://invent.kde.org/pim/libkleo/-/merge_requests/163

setting this to open for the small fix in the tooltip.
I suggest as new text:
"Disabled certificates are not offered when selecting a certificate to sign with or to encrypt for.\nThey are not shown in the certificate list with most filters."
And I think there should be an additional newline somewhere, as I was shown a much too long tool tip. The German text is not that much longer…

Removing the appearance filter won't fix own disabled certificates not being bold; the problem here is that the "My certificates" filter doesn't trigger at all anymore for disabled certificates

Agree with removing the appearance filter

Yeah. so lets ditch that appearance filter. But that's for ticket T7217. So I'm setting this ticket to done for 4win.