FS#71978 - [glibc] Weird interactions in gettext between LANGUAGE and LC_MESSAGES
Attached to Project:
Arch Linux
Opened by Konrad (cloud-oak) - Wednesday, 01 September 2021, 10:09 GMT
Last edited by freswa (frederik) - Monday, 14 February 2022, 16:49 GMT
Opened by Konrad (cloud-oak) - Wednesday, 01 September 2021, 10:09 GMT
Last edited by freswa (frederik) - Monday, 14 February 2022, 16:49 GMT
|
Details
Description:
When both LANGUAGE and LC_MESSAGES are both set, the output of gettext-based localizations is wrong (English locales listed in LANGUAGE are skipped). Steps to reproduce: env --ignore-environment LANGUAGE=en:es:fr tar # English Output env --ignore-environment LC_MESSAGES=de_DE.UTF-8 tar # German Output env --ignore-environment LANGUAGE=en:es:fr LC_MESSAGES=de_DE.UTF-8 tar # Spanish Output, but English output would be expected gettext(3) states that if LC_MESSAGES is set to a valid locale other than "C", LANGUAGE will take precedence over LC_MESSAGES and is assumed to contain a colon-separated list of locale names that are then tried in order. For some reason on Arch, english locales are skipped in this colon-separated list, leading to the behaviour described above. Versions: glibc: 2.33-5 This issue appears to be specific to Arch, I cannot reproduce it in KDE Neon (glibc 2.31-0ubuntu9.2) or OpenSuSE Tumbleweed (glibc 2.33-9.1). |
This task depends upon
Closed by freswa (frederik)
Monday, 14 February 2022, 16:49 GMT
Reason for closing: Fixed
Additional comments about closing: glibc 2.35
Monday, 14 February 2022, 16:49 GMT
Reason for closing: Fixed
Additional comments about closing: glibc 2.35
First guess would be that English is missing and Spanish exists. If that's the case here, your first example gives English output because it uses the default C locale (which is English in most applications and libraries).