en_US users see en_GB strings all over?

[Ka-Hing Cheung]

Applications launched from panel (launcher or menu) does not use the locale
setup during install (in my case, en_US), instead they uses some UK locale (for
example, colour instead of color).
From a shell, echo $LANG prints en_US.

[Sebastien Bacher (seb128)]

which locale is selected in gdm ?

[Ka-Hing Cheung (kahing)]

I never changed it, so I assume it should be "System Default", which should be
en_US? Actually I never noticed the language setting, and if I set it to
American English then programs launched from panel honor it.
However, since Ubuntu knows enough to set my $LANG to en_US, shouldn't it also
default the gdm language to the same thing?

[Sebastien Bacher (seb128)]

could you paste the result of "locales" in a real console ?

[Ka-Hing Cheung (kahing)]

I have a powerbook, and fn-ctrl-alt-f1 used to switch to vt1 in debian ppc, but
somehow this doesn't work in ubuntu. Would the output be the same as this?
$ su - $USER
$ locale
LANG=POSIX
LC_CTYPE="POSIX"
LC_NUMERIC="POSIX"
LC_TIME="POSIX"
LC_COLLATE="POSIX"
LC_MONETARY="POSIX"
LC_MESSAGES="POSIX"
LC_PAPER="POSIX"
LC_NAME="POSIX"
LC_ADDRESS="POSIX"
LC_TELEPHONE="POSIX"
LC_MEASUREMENT="POSIX"
LC_IDENTIFICATION="POSIX"
LC_ALL=

For reference, in gnome-terminal the output is (same before/after setting the
gdm language, as I remember):
LANG=en_US
LC_CTYPE="en_US"
LC_NUMERIC="en_US"
LC_TIME="en_US"
LC_COLLATE="en_US"
LC_MONETARY="en_US"
LC_MESSAGES="en_US"
LC_PAPER="en_US"
LC_NAME="en_US"
LC_ADDRESS="en_US"
LC_TELEPHONE="en_US"
LC_MEASUREMENT="en_US"
LC_IDENTIFICATION="en_US"
LC_ALL=

[Sebastien Bacher (seb128)]

no the output is probably not the same or you would not have this bug ...

do you export the LANG in the ~/.bashrc file ?

[Ka-Hing Cheung (kahing)]

Nope.
I just greped around and I found the file /etc/environment:
LANGUAGE="en_GB:en_US:en"

LANG=en_US

Note that I never modified this file. Could this be it?

[Sebastien Bacher (seb128)]

yes, that's it, LANGUAGE is used and set to en_GB

[Colin Watson (cjwatson)]

From what CD image did you install this system?

[Ka-Hing Cheung (kahing)]

The PPC one.

[Luis Villa (luis-villa)]

Ah-ha. I'm seeing the same problem. I assume that if I remove the offending
en_GB I'll get the 'right' value? [And no, I didn't put it there either...]

[Luis Villa (luis-villa)]

Note (if it matters) that I did not see this problem until I upgraded from warty
to hoary and ran the command:

bash:~$ sudo dpkg-reconfigure locales

as recommended in:
http://www.ubuntulinux.org/wiki/GuideToHoary

[Ka-Hing Cheung (kahing)]

For what it's worth, I had this problem when I was still on warty.

[Luis Villa (luis-villa)]

Retitling to make it sound more drastic, because, well, it is drastic for US
users. It is going to be very irritating to have to explain why their trash can
is a 'wastebasket', and why their days and months are wrong in their panel
clock, to every american who I want to set up with Ubuntu.

[Matt Zimmerman (mdz)]

I use en_US, and I can't reproduce this bug. I have never had such a problem
with Warty installs, Hoary installs, or Warty-Hoary upgrades.

[Jeff Waugh (jdub)]

This bug really needs a reproduction process, if you can find one...

[Luis Villa (luis-villa)]

The reproduction process for my last install was pretty simple: grab Jan. 31st
daily install CD, choose 'English' as language, 'US' as location, and 'American
English' as keyboard. When the install completed, I logged in as the initial
user and had a wastebasket instead of a trash can. No other defaults were
touched during the install.

I am currently booting a liveCD based on the gnoppix liveCD based on an ubuntu
pull just a little while ago (Jeff may know the date; it is 2.9.90-based) and it
does /not/ appear to have the problem. I'll try the straight ubuntu CD next, I
guess...

[Matt Zimmerman (mdz)]

I installed using the Array 4 install CD last week, and this problem does not
exhibit itself on that system. /etc/environment looks like this:

LANGUAGE="en_US:en_GB:en"
LANG=en_US.UTF-8

I also booted the Array 4 live CD a few minutes ago, and confirmed that I do not
see the problem there either. On the live CD, I get this /etc/environment:

LANG="en_US.UTF-8"
LANGUAGE="en_US:en_GB:en"

for some reason they are not identical, but they are equivalent, and in neither
case do I see any en_GB strings.

Install and Live editions of Array 4 can be found here:

http://cdimage.ubuntu.com/releases/hoary/array-4/

Please use those in your testing, not Gnoppix.

[Luis Villa (luis-villa)]

I'll try with array 4 when I have a chance; as I said, though, I duplicated this
with the 1/31 ubuntu daily install cd, not gnoppix.

[Matt Zimmerman (mdz)]

Unreproducible, awaiting confirmation with a recent build

[Ted Anderson (tanderson92+ubuntu-deactivatedaccount)]

Here's your confirmation on a newer release. I did a completely new install of
Ubuntu 5.04-preview last night. The only options I selected were English, US,
and American English keyboard. I have a wastebasket, colour, and dates like
11/3/05 for today's date (11 March). I am brand new to Ubuntu and have been
looking around for a GUI locale chooser--I guess there isn't one. In
/etc/environment I have:

LANGUAGE="en_US:en_GB:en"

LANG=en_US.UTF-8

[Matt Zimmerman (mdz)]

What do you have in /etc/locale.gen?

[Matt Zimmerman (mdz)]

I can reproduce this on a Hoary preview install, oddly enough.

Perhaps the issue is that we ship en_GB .mo files, but no en_US ones?

mdz@max:~$ cat /etc/environment
LANGUAGE="en_US:en_GB:en"
LANG=en_US.UTF-8
mdz@max:~$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE=C
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
mdz@max:~$ ls --invalid-option
ls: unrecognised option `--invalid-option'
Try `ls --help' for more information.
mdz@max:~$ LC_ALL=C !!
LC_ALL=C ls --invalid-option
ls: unrecognized option `--invalid-option'
Try `ls --help' for more information.

[Martin Pitt (pitti)]

(In reply to comment #22)
> I can reproduce this on a Hoary preview install, oddly enough.
>
> Perhaps the issue is that we ship en_GB .mo files, but no en_US ones?

Exactly. language-pack-en-base contains heaps of en_GB translations, but only
one (gcalctool) for en_US. I assume that the vast majority of C strings are
already in en_US, so that upstreams generally don't ship en_US po files.

So actually you exactly get what you asked for with

  LANGUAGE="en_US:en_GB:en"

So if this is really annoying for English users, maybe GB should not be a
fallback for US (and vice versa), but rather C should be the general fallback?

[Matt Zimmerman (mdz)]

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

[Colin Watson (cjwatson)]

localechooser (0.04.0ubuntu9) hoary; urgency=low

  * Set default $LANGUAGE for English installs to just "en" rather than
    "en_US:en_GB:en" (it will be prefixed with the appropriate en_* for the
    selected country), since fallbacks from American to British English and
    vice versa are too annoying (closes: Ubuntu #4271).
  * Add Xhosa, xh_ZA (thanks, Adi Attar).
  * Don't try to install localization-config, since it's not in Ubuntu.

 -- Colin Watson <email address hidden> Thu, 17 Mar 2005 18:36:27 +0000

[Matt Zimmerman (mdz)]

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

[Daniel Holbach (dholbach)]

It seems the bug has re-surfaced again - see recent duplicates.

[Carthik Sharma (carthik)]

Confirming this:

Using Dapper Latest, I get:

carthik@umberto:~$ cat /etc/environment
LANGUAGE="en_US:en_GB:en"
LANG="en_US.UTF-8"
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11:/usr/games"
carthik@umberto:~$ locale
LANG=en_US.UTF-8
LANGUAGE=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=

[Hezekiah Carty (hez)]

I can confirm this as well, I have this problem on two up-to-date Dapper systems.

[Colin Watson (cjwatson)]

localechooser (0.27ubuntu18) dapper; urgency=low

  * Set default $LANGUAGE for English installs to just "en" rather than
    "en_US:en_GB:en" (it will be prefixed with the appropriate en_* for the
    selected country), since fallbacks from American to British English and
    vice versa are too annoying (closes: Malone #10822). Previously fixed in
    localechooser 0.04.0ubuntu9, but lost in localechooser 0.22ubuntu1.

 -- Colin Watson <email address hidden> Wed, 3 May 2006 10:36:40 +0100

[Kyle Smith (kylesm)]

(In reply to comment #23)

So because there aren't an en_US translations for all those packages, there are all sorts of failed opens when I strace GNOME/GTK apps. For example (taken from an strace of gnome-terminal):

open("/usr/share/locale/en.UTF-8/LC_MESSAGES/libgnome-2.0.mo", O_RDONLY) = -1 ENOENT (No such file or directory)

Is there something I should set my locale to to prevent it from trying to open all these non-existent translations? Seems like it could be quite a performance hit if it's not fixed.

[Luis Villa (luis-villa)]

Bizarrely, with up-to-date dapper, I'm seeing en_GB right now for Abiword, and en_US for everything else I can find. Don't know if this is an abi-specific bug, but throwing it in there in hopes it can be of use to someone.

[Andrew Jorgensen (ajorg)]

I can confirm what Luis is seeing but I don't think it can be related to this bug. At least it doesn't have anything to do with the LANG or LANGUAGE variables because I have manually fixed mine.

[Andrew Jorgensen (ajorg)]

I've marked this as needing to be fixed in language-selector because manually switching your locale to another language or variant and then back to en_US will make LANGUAGE="en_US:en_GB:en" again.

localechooser is only part of the installer, right?

[Colin Watson (cjwatson)]

Andrew: correct, localechooser is only part of the installer.

[Michael Vogt (mvo)]

Thanks for the bugreport.

This is fixed with the latest langauge-selector upload.

Cheers,
 Michael