Bug 149300 - konsole sets LANGUAGE for no apparent reason
Summary: konsole sets LANGUAGE for no apparent reason
Alias: None
Product: konsole
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Konsole Developer
: 170492 (view as bug list)
Depends on:
Reported: 2007-08-28 13:06 UTC by Mike FABIAN
Modified: 2014-03-07 19:18 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description Mike FABIAN 2007-08-28 13:06:36 UTC
Version:           1.9.2 (using KDE Devel)
Installed from:    Compiled sources
OS:                Linux

See also: http://bugzilla.novell.com/show_bug.cgi?id=305210
Comment 1 Mike FABIAN 2007-08-28 13:06:56 UTC
I am running in ja_JP.UTF-8 locale

    mfabian@magellan:~$ locale

with LANGUAGE not set, but when starting the konsole from KDE4
(/usr/bin/konsole) it sets LANGUAGE to ‘en_US’ which gives me English
messages from programs started from konsole.

Stefan Seifried had the same problem that konsole set LANGUAGE=de
for him which surprisingly overrode his LC_MESSAGES=en_US.UTF-8.

I don’t understand why konsole does this and I think it shouldn’t.
Comment 2 Robert Knight 2007-08-28 22:13:18 UTC
Confirmed.  It seems that this is not specific to Konsole, 'LANGUAGE'
is being set during the KApplication constructor in
KCatalogPrivate::changeBindings() so presumably it affects all KDE 4
applications.  Looks like a bug.

Konsole passes its own environment onto the newly started shell
process which is where 'LANGUAGE' is coming from there.

Until this is fixed,  you can work around the problem by setting the
'LANGUAGE' variable to the correct one for your locale by going to
Settings -> Edit Current Profile -> Edit Environment... (on the first
tab of the dialog).  This will override the value set on Konsole'


On 28 Aug 2007 11:06:36 -0000, Mike FABIAN <mfabian@suse.de> wrote:
[bugs.kde.org quoted mail]
Comment 3 Robert Knight 2007-09-09 00:38:16 UTC
Fixed (commit 710022), but the current solution is not very elegant.  LANGUAGE will still be set in the child process's environment but it will be a null string.

The problem, I believe, occurs when LANG is set to a language which a Konsole translation is not available for.  Internally the language gets set to a default (en_US) and then at a later point, the LANGUAGE environment variable is set to that (for gettext according to the comments in the code).
Comment 4 Mike FABIAN 2007-09-24 22:55:45 UTC
It is not necessary to set LANGUAGE if LANG is already set.

For example, if LANG=en_US.UTF-8, and LANGUAGE is unset (and no other
LC_* variables are set), English messages will be used. The priority of
variables which are checked by gettext to choose the language of the
messages is:


The first variable of these which is set determines which language
is used for the messages. LANG and LC_MESSAGES can only be set to 
*one* language. I.e. with these two variables, it is not possible
to say: "I want German messages, but if these are not available Italian",
because one can only set LANG=de_DE.UTF-8 *or* LANG=it_IT.UTF-8, not both
at the same time. For that reason, LANGUAGE (which is a GNU extension)
was invented, it is possible to set it for example like


and that would use German messages if possible and Italian if not.

If you don't to use this feature to specify a fallback list of languages to
use for the messages, you don't need to set LANGUAGE at all. If only
one locale/language is used it is enough to set only LANG and neither LANGUAGE
nor any of the LC_* variables. 
In that case, better don't set LANGUAGE!

There is no need for konsole to fiddle with the locale environment
variables at all, I think konsole should just leave all of them as they are.
Then gettext will work as expected, gettext will already fall back to 
English when the language requested with the environment variables is not

Comment 5 Robert Knight 2007-09-24 23:42:02 UTC
> There is no need for konsole to fiddle with the locale environment 
> variables at all

Konsole doesn't have anything to do with the locale setup, that is done by the locale/translation setup code in kdelibs which is run on startup of all KDE applications.  The LANGUAGE variable was being set there and inadvertently passed to the child processes.

I'm really not the best person to talk to about translation/locale issues, it would be better to email kde-core-devel@kde.org directly to get the attention of someone who understands this better than I do. 
Comment 6 Mike FABIAN 2007-09-25 12:04:54 UTC
Then I think kdelibs does something wrong. 

I'll try to ask on kde-core-devel@kde.org. Thank you!
Comment 7 Eike Hein 2008-09-23 15:57:28 UTC
*** Bug 170492 has been marked as a duplicate of this bug. ***
Comment 8 Vasiliy Glazov 2014-03-07 09:51:10 UTC
The bug now present in KDE 4.12.3.
Comment 9 Kevin Kofler 2014-03-07 18:08:43 UTC
No, what you're seeing is a completely different issue, not in Konsole, but probably in yum. (See https://bugzilla.redhat.com/show_bug.cgi?id=1073338 for details.)
Comment 10 Vasiliy Glazov 2014-03-07 19:18:39 UTC
Not in yum.
In konsole I see output only in english, but in Ctrl+Alt+F2 console I see normal output in russian.