Summary: | LANGUAGE environment variable is sometimes empty | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Franz <calcifer> |
Component: | Startup process | Assignee: | Plasma Bugs List <plasma-bugs> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | caslav.ilic, kde, kde, nate, nl6720, null |
Priority: | NOR | ||
Version: | 5.27.0 | ||
Target Milestone: | 1.0 | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Franz
2009-06-29 10:29:13 UTC
I'm not seeing this as a KDE issue. Its presumably part of the distro setup. This is NOT a distro setup issue, because it is NOT set by any distro scripts. I don't have any scripts setting LANGUAGE in /etc or ~/ Additionally. When I start any non-kde terminal (tested: urxvt, xterm) I DON'T have LANGUAGE set. I only get my LANG=de_DE.UTF-8 Okay, now to the point why this is rather a bug than a wish: I have (in Konsole) $ env | grep -i lang LANG=de_DE.UTF-8 LANGUAGE= But because LANGUAGE has higher precedence (and is empty) some locale-aware programs think I don't have a language set. In particular "ruby-locale" has this impression. I also want to note though, that other tools ignore the empty LANGUAGE. My test-case are the above set LANG=de_DE.UTF-8 from me and LANGUAGE= from kdelibs and ruby-locale: http://rubyforge.org/projects/locale/ in Konsole: $ irb irb(main):001:0> require 'locale' => true irb(main):002:0> Locale.current => [] in xterm: $ irb irb(main):001:0> require 'locale' => true irb(main):002:0> Locale.current => [#<Locale::Tag::Posix: de_DE.UTF-8>] Both logged in with the same user in fluxbox (only using KDE apps like Konsole) and both use bash. Also note an older bugreport for Konsole (which is not responsible): http://bugs.kde.org/show_bug.cgi?id=149300 There somebody notes that this (was) set during the KApplication constructor in KCatalogPrivate::changeBindings() But that was before KDE4. I am using KDE 4.3.3 at the moment in Arch Linux. Yes, ruby-locale can change the behavior, but there is also no reason for KDE to set an empty LANGUAGE. It would be fine if the language set in KDE would get used (I set german, english) ruby-locale should change the behavior, because LANGUAGE is used by GNU extensions in gettext(3), and has nothing to do with locales. The man page states that LANGUAGE is used only if not empty, so this is part of specified behavior of gettext(3). KDE sets LANGUAGE to empty only if it wasn't in the environment at all, and otherwise preserves its value. So this cannot really be called a bug. On the other hand, I acknowledge that touching environment in this way is not the cleanest thing to do on the outside, and internally it's even worse. It is compromise to achieve the desired functionality (internal control of gettext(3)) without extensive additional code needed for proper solution (replacement of gettext(3)), or another simple but dirty solution which would be less portable and worse for peformance. So I'm confirming this as wishlist item. From the looks of it, the LANGUAGE environment variable is set by https://invent.kde.org/plasma/plasma-workspace/-/blob/master/startkde/startplasma.cpp . Yep Since this was closed as "FIXED", which commit fixed it and which release will have the fix? With plasma-workspace 5.90.0-2 on Arch Linux, I still get an empty LANGUAGE variable. Looking at the code, there are conditions under which it gets set, and conditions under which it doesn't. I would recommend submitting a new bug report in which you describe the problem you're seeing which is caused by LANGUAGE not being set, and also include the output of `env`, I don't understand why I would need to create a new bug report if I'm having this exact issue exactly as the original reporter described it more than 14 years ago. This bug has obviously survived through multiple generations of KDE. $ cat /etc/locale.conf LANG=lv_LV.UTF-8 $ cat ~/.config/plasma-localerc [Formats] LANG=lv_LV.UTF-8 $ printenv | grep -E '^(LANG|LC_)' LANG=lv_LV.UTF-8 LANGUAGE= Ok, fair enough. |