Another issue (but I'll comment here because it's related to this issue):


$ env | grep LANG
LANG=en_GB.UTF-8
GDM_LANG=en_GB.UTF-8

$ env | grep LC
LC_PAPER=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_MONETARY=fi_FI.UTF-8
LC_NUMERIC=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_COLLATE=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
LC_CTYPE=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8


Then, I connect with ssh to a server running Debian etch (latest stable):

$ env | grep LANG
LANG=en_US.ISO-8859-15
LANGUAGE=en_FI:en_US:en_GB:en

$ env | grep LC
LC_PAPER=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_MONETARY=fi_FI.UTF-8
LC_NUMERIC=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_COLLATE=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
LC_CTYPE=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8

This causes:

$ locale
LANG=en_US.ISO-8859-15
LANGUAGE=en_FI:en_US:en_GB:en
LC_CTYPE=fi_FI.UTF-8
LC_NUMERIC=fi_FI.UTF-8
LC_TIME="en_US.ISO-8859-15"
LC_COLLATE=fi_FI.UTF-8
LC_MONETARY=fi_FI.UTF-8
LC_MESSAGES="en_US.ISO-8859-15"
LC_PAPER=fi_FI.UTF-8
LC_NAME=fi_FI.UTF-8
LC_ADDRESS=fi_FI.UTF-8
LC_TELEPHONE=fi_FI.UTF-8
LC_MEASUREMENT=fi_FI.UTF-8
LC_IDENTIFICATION=fi_FI.UTF-8
LC_ALL=


This happens because we send and the server accepts. :) I know this can be
thought as a bug on the server side shell profile scripts (because it should
either use the settings from the client or from the server - not to mix them),
but this is the real world. This is happening now with almost all servers...
I've already sent patches to Fedora's initscripts maintainer about handling this
properly in Fedora, but we can't fix all the distros out there... :)

Of course if the client only defines LANG, things will work properly. But that
can't be the "solution" to this problem. The LC_* variables are here to stay and
they should be handled properly.

Because of this, I wonder if it's a good choise to set the system to send the
locale related variables to the remote server by default. It might be a better
solution to disable sending them by default and add e.g. a host specific example
to the ssh_config file so that the administrator can define host specific
SendEnvs when needed.

I'm not sure which is better, but I wanted to bring this to your attention so
that you can decide how it is handled best.


The problem with mixing these variables is that when mixing different encodings,
weird things start to happen. Without the encoding issue, this would not be a
real world problem.

Actually passing locale settings is a really good thing after all! I can see
this especially when using a real terminal. Without passing the encoding
information, the terminal doesn't work properly. Of course the server side needs
to have the passed locale installed and there are perhaps issues when only some
of the LC_* variables are sent, but in general it's still much better to send
the locale settings than not to send them. (Because the client always "talks" to
the server in its own encoding by default.)

So I'd just ignore the thought that sometimes this causes problems (especially
when the server overrides the sent settings). We don't live in a perfect world.
In this case sending the locale settings by default in ssh_config is the better
compromise than not to send them. :)


I noticed that sometimes variables LESSCHARSET and LESSCHARDEF are also used
(usually unnecessarily, but hey... sometimes the server administrators set them
"just in case" - which then causes problems when the encodings differ between
the client and the server...). Perhaps those should also be sent and accepted by
ssh_config and sshd_config. They are character set related, and therefore locale
related - like the LANGUAGE variable is language related (and therefore locale
related).

I think all character set and language related variables should be sent and
accepted to prevent these encoding and language setting mix situations. Perhaps
the configuration should be like this (* character can be used, so there's
actually no need to list them all explicitly):

ssh_config: SendEnv LANG LC_* LANGUAGE LESSCHAR*

sshd_config: AcceptEnv LANG LC_* LANGUAGE LESSCHAR*

LESSCHAR* are apparently old variables (coming from the days when less didn't
support the locale system). As the servers out there in the real world don't
have them in AcceptEnv at the moment, it's more like a cosmetic thing if they
are added. Perhaps they should be added, but that doesn't matter much in real
life, so I don't mind if it's decided that they are not added. (One reason not
to add them might be that we perhaps don't want to support using these old and
unnecessary variables used by only one software... :))

Then there is also that locale and language related environment variable
LINGUAS. I'd say it's more related to the configuration on the actual host being
used though, so I'd not add that to the list of passed variables. It would cause
gray hair and a behavior which would just surprise the users in a bad way. :)

LANGUAGE is a different variable in its purpose. It's clearly related to the
locale configuration as it controls the same thing as LC_MESSAGES and LANG (the
language of the messages). Therefore I think LANGUAGE should be passed perhaps.

Or... Is LANGUAGE considered as a _local_ override for LC_MESSAGES? Have I
understood its purpose the wrong way? If it's considered as a local override,
this bug can be closed with NOTABUG or course.

It's just that when LANG is passed and used, that already contains the language
information - as does LC_MESSAGES... Therefore it all comes to this question: Is
LANGUAGE a local override or just a list of preferred languages which should be
used always and everywhere? Is it a preference list for the local system or for
all systems in the user's session? I've thought it's a list for the whole
session for the user, but I'm not 100 % sure anymore. It depends on how it's
usually used - for what purpose.

I'm trying to search the web about the real and intended official purpose of the
LANGUAGE variable...

Well one thing I found is the gettext documentation saying this: "you still need
to have LANG (or LC_ALL) set to the primary language". So my bug report is
invalid in its example. :D I'm not supposed to set LANG/LC_MESSAGES/LC_ALL and
the first occurrence in LANGUAGE to different values - which I did.

http://www.gnu.org/software/gettext/manual/html_node/The-LANGUAGE-variable.html

Based on the gettext documentation, LANGUAGE is not meant to be used as an
override for the primary language. It seems to be more like a preference list to
support also secondary language selection - not an overriding totally different
value for LANG or LC_MESSAGES. So... If it's not used as a local override, I
think it's then logical to pass it between systems when using ssh. It could be
helpful and logical if the list is passed to the remote end also (user hopes to
use e.g. sv:de:en - remote doesn't have sv, but has de --> user gets what she
wants --> without passing LANGUAGE user would get the remote end's primary
language which can be something totally different).

The LESSCHAR* is not really needed and perhaps it's better not to support
variables which are used only by one software. I know LANGUAGE is also for "one
software" (gettext), but gettext is used by many programs and is a low level
thing. So it's still different than the LESSCHAR* case.

--> Okay... So although the "unexpected behaviour" is a bit exaggerated, I still
think adding LANGUAGE is a good idea. I would not add LESSCHAR* after all (I
changed my mind), so my original request about adding LANGUAGE is valid - and I
think we only need to add LANGUAGE after all.

And LANGUAGE can be overridden on the remote end in ~/.18n, /etc/profile or
.bash_profile etc. anyway, so passing it through ssh does not take away the
option of doing local overrides with it. Therefore I think adding LANGUAGE only
brings more to the table. It should be added. It's clearly related to
LC_MESSAGES and LANG. It's language related --> locale related. And we already
pass locale variables. --> We should pass LANGUAGE also.


So this is my request - as originally (although this is not about primary
language like I thought, but supporting the preference list feels like the
logical thing to do anyway - especially because supporting it doesn't take away
anything, but adds support for reading the language preference list from the
client side):

One new line to ssh_config: SendEnv LANGUAGE
One new line to sshd_config: AcceptEnv LANGUAGE

My opinion is that adding LANGUAGE is the right thing to do. When passing
language already in LANG, LC_MESSAGES and LC_ALL, it its the most logical thing
to do to pass also LANGUAGE. This is what the user expects to happen.


PS. Sorry for the long comment. This stuff is hard to figure out because it's
different to configure your own system then to think about what kind of default
configuration should be shipped with the package. In this case I think LANGUAGE
should be there by default. That is the most logical way because I don't see it
as a local-only variable.


If the upstream ships this kind of configuration, they should be notified to add
LANGUAGE also. I guess thought that they don't they being famous of shipping
everything disabled by default. :)

Upstream doesn't enable anything like this. I think that we can add
SendEnv/AcceptEnv LANGUAGE to rawhide.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

openssh-5.0p1-3.fc9 has been submitted as an update for Fedora 9

openssh-5.0p1-3.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update openssh'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-4356

openssh-5.0p1-3.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.