This interacts with the way that apps are started.

• Starting kleopatra from a terminal Window where LANG is set, that setting is respected.
• LANG is also respected when starting ministart from the terminal, and launching kleopatra from that.
• Starting from the dock / Apps menu, the used language is always(?) English
• Settings->Configure Language seems to show German in all of the above cases, even if some other language is currently used.

My interpretion is, that the dialog expects the detection to work properly, as there is no explicit distinction between "use system default" and "set the same language as the system default". Adding a "Default" or "System Language" option in the Dropdown might also solve this. Not sure if this is an option here. I added @ikloecker for an opinion.

I'll have to look closer, but I think this is Qt and ki18n using different rules on how to select the effective language. My guess is that we'll have to patch ki18n to use the "MacOS UI configured default" (whereever that is set) in the absence of LANG.

I understand that the problem is that KDE's language switcher shows the wrong current (or default) language. If the (override) language has been set in Kleopatra then it seems to work (if one used the workaround described by @timegrid to make the language switcher accept the language).

From what both of you wrote it seems that everything else works, i.e. Kleopatra uses the language it's supposed to use (be it the system default, the app-specific override language (if properly set), or LANG). I have fixed related problems in ki18n (and for tier 1 KF modules in similar code injected by ECM) quite some time ago for Windows and Mac. (I never tested my fixes on Mac, but as far as I remember kdenlive reported that the problems they had on Windows and Mac were solved.)

By the way, one should always use LANGUAGE to force a language via an environment value because that's what ki18n/kxmlgui uses internally to set the language override. LANG isn't respected by Qt on Windows and, as far as I remember, the same is true for Mac because in both cases the native localization API is used.

Not quite. In a Mac where language is set to German via the MacOS system settings:

• When launching kleopatra via Apps / Dock:
  • Most kleopatra strings (and all in the main Window) are in English
  • Even buttons in file dialogs are in English (Sing/Encrypt, Decrypt/Verify)
  • A few select strings are in German, e.g. in the Settings Menu: "Werkzeugleiste anzeigen", "Sprache einrichten"
  • Selecting Settings->Configure Language, the primary (only) language is shown as "Deutsch (de)", the dialog buttons are in German.
• In a regular Terminal session without further user config, env shows:
  • LANG=de_DE.UTF-8
  • No LANGUAGE, LC_MESSAGES or similar vars are set
• Launching kleopatra from that, i.e. with LANG
  • gives a consistently German UI
  • Settings->Configure Language behaves as expected
• If LANGUAGE is set, language behaves as expected, too, and seems to override LANG, if that is present.

In summary:

• If LANGUAGE is set, that is used, consistently.
• Failing that, if LANG is set, that is used, consistently.
• However, we cannot assume either to be present, and in this case the system setting is only respected in a few select places.

Can you try Kate or some other KDE app that's build by KDE for MacOS?

It looks like this may have been a complex interaction involving the version of Qt and lookup of resource files. I did not properly diagnose this, but after adjusting to a change in the behavior of QLibraryInfo::DataPath on MacOS (in Qt 6.12 it now returns the bundle's "Resources" subfolder, which makes a lot of sense), things now seem to work as expected.