Bug 149300

I am running in ja_JP.UTF-8 locale

    mfabian@magellan:~$ locale
    LANG=ja_JP.UTF-8
    LC_CTYPE="ja_JP.UTF-8"
    LC_NUMERIC="ja_JP.UTF-8"
    LC_TIME="ja_JP.UTF-8"
    LC_COLLATE="ja_JP.UTF-8"
    LC_MONETARY="ja_JP.UTF-8"
    LC_MESSAGES="ja_JP.UTF-8"
    LC_PAPER="ja_JP.UTF-8"
    LC_NAME="ja_JP.UTF-8"
    LC_ADDRESS="ja_JP.UTF-8"
    LC_TELEPHONE="ja_JP.UTF-8"
    LC_MEASUREMENT="ja_JP.UTF-8"
    LC_IDENTIFICATION="ja_JP.UTF-8"
    LC_ALL=
    mfabian@magellan:~$ 

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.

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'
startup.

Regards,
Robert.

On 28 Aug 2007 11:06:36 -0000, Mike FABIAN <mfabian@suse.de> wrote:
[bugs.kde.org quoted mail]

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).

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:

     LANGUAGE
     LC_ALL
     LC_MESSAGES
     LANG

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

    LANGUAGE=de_DE.UTF-8:it_IT.UTF-8

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
available. 

> 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. 

Then I think kdelibs does something wrong. 

I'll try to ask on kde-core-devel@kde.org. Thank you!

*** Bug 170492 has been marked as a duplicate of this bug. ***

The bug now present in KDE 4.12.3.

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.)

Not in yum.
In konsole I see output only in english, but in Ctrl+Alt+F2 console I see normal output in russian.