Page MenuHome GnuPG

Kleopatra, Libgpg-error: Let the GUI change the language on Windows
Open, NormalPublic

Description

This task description has been updated by aheinecke.

The GnuPG System and GpgOL / GpgEX detect the language through GetThreadLocale or Environment variables on Windows (libgpg-error is responsible for that). This might not be the configured display language and it might also differ from Kleopatra which has a dedicated setting.

A good fix could be that Kleopatra would write a registry Key that notes "it's" Language and that libgpg-error "my_nl_locale_name" would read / respect that language. This would also make it easier for admins to globally configure languages.

Original report was: "Wrong Display Language":
Hi
GPGOL shows the wrong display language. My OS and Office is English and the GPGOL is always german.


Thanks
Martin

Details

Version
gpgol 2.0.6-beta9

Event Timeline

Mak created this object in space S1 Public.
aheinecke added a subscriber: aheinecke.

GpgOL should use the same language detection code that GnuPG also uses. If you open a command line (cmd) and run "gpg" in that command line is it also in german?

Hi @aheinecke
Its also german:

C:\WINDOWS\system32>dism /online /get-intl

Deployment Image Servicing and Management tool
Version: 10.0.16299.15

Image Version: 10.0.16299.125

Reporting online international settings.

Default system UI language : en-GB
The UI language fallback is : en-US
System locale : de-CH
Default time zone : W. Europe Standard Time
Active keyboard(s) : 0807:00000807, 0809:00000807, 100c:0000100c
Keyboard layered driver : PC/AT Enhanced Keyboard (101/102-Key)

Installed language(s): de-DE
  Type : Partially localized language, MUI type.
  Fallback Languages en-US
Installed language(s): en-GB
  Type : Partially localized language, MUI type.
  Fallback Languages en-US

The operation completed successfully.
aheinecke lowered the priority of this task from Low to Wishlist.Jan 12 2018, 8:48 AM
System locale : de-CH

For windows we either look at the standard POSIX environment variables (LC_ALL, LANG etc.) and if they are not set we use "GetThreadLocale"

The most "unsurprising" behavior would probably be if the gnupg system and GpgOL / GpgEX would also switch the language if Kleopatra's language is changed. I'll update the task description accordingly.

aheinecke renamed this task from Wrong display language to Kleopatra, Libgpg-error: Let the GUI change the language on Windows.Jan 12 2018, 8:52 AM
aheinecke claimed this task.
aheinecke updated the task description. (Show Details)
aheinecke edited projects, added gpg4win, gpgrt; removed gpgol.

Thanks. In the meantime GpgOL takes it's language from the Outlook configured display language setting. I'll add support for override locale to gpgol so that the locale is set accordingly

Use that function as early as possible. The gpg-error tool has also be enahnced on Windows:

gpg-error --locale

prints the used locale in XPG form (e.g. de_DE) and

gpg-error --locate 0x200c

prints "fr_RE". If the given language is not supported by libgpg-error, "C" is printed.

I don't think this works for me in that way.

I'm calling everything through GPGME and so it does not help much if my gpgrt locale inside of gpgol is different. E.g. for gpgconf this does not change the output of the configuration options.

I think I have to look into the GPGME locale override and then we would need to pass it somehow. I wonder: Why don't I just setenv("LANG " ... early in my program?

Note: If you want to set this early in your program you need to make sure that there is only one thread running.

ebo raised the priority of this task from Wishlist to Normal.Nov 28 2023, 9:14 AM
ebo added projects: vsd33, Restricted Project.
ebo added a subscriber: ebo.

Raising prio in reaction to some customer feedback

Some technical details:

  • KDE's ki18n uses the LANGUAGE variable to set/get the language to use. On Unix, we simply use QLocale::system(), but on Windows and macOS we look directly at the LANGUAGE variable because Qt ignores this variable on those systems. See https://invent.kde.org/frameworks/ki18n/-/blob/kf5/src/i18n/main.cpp#L63
  • KDE's kxmlgui reads the application-specific override language from the file QStandardPaths::GenericConfigLocation + "/klanguageoverridesrc" and sets the LANGUAGE variable accordingly (which is then picked up by ki18n). Example from my system:
[Language]
kmymoney=@ByteArray(de)

Regarding the format, =de would probably also work.
See https://invent.kde.org/frameworks/kxmlgui/-/blob/kf5/src/kswitchlanguagedialog_p.cpp#L64

In GpgOL at least I have an API call to query the display language of outlook. I just need to pass it through to gpgme early and forgot about it. Also I don't think this would actually help completely if gpg-agent is running already.

On Linux, gpgme already passes the locale (set with gpgme_set_locale) to gpg which should pass it with every session to gpg-agent. No idea if this also happens on Windows because there are some ifdef's. The gpgme documentation mentions that the locale should be set immediately after gpgme has been initialized and that gpgme doesn't do it itself because it wouldn't be thread safe.