Locale settings in shell initialization not used by GNOME session

confirmed. Came to report it myself and found this.

I have this issue on Ubuntu 8.04 as well. This is a recent problem (within the last month).

Affects a wider range of environment variables and also 8.04

I am regularly setting my application language to something different to test translation work I am doing. This is not respected either since approximately the same time as above bug was reported

e.g (on Ubuntu 8.10, en_UK locale for main gnome session)

export LC_ALL=ar_EG; gnomesword

Error message : (gnomesword:15597): Gtk-WARNING **: Locale not supported by C library.
 Using the fallback 'C' locale.

And

export LC_ALL=ar_EG; locale
gives:

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_GB.UTF-8
LC_CTYPE="ar_EG"
LC_NUMERIC="ar_EG"
LC_TIME="ar_EG"
LC_COLLATE="ar_EG"
LC_MONETARY="ar_EG"
LC_MESSAGES="ar_EG"
LC_PAPER="ar_EG"
LC_NAME="ar_EG"
LC_ADDRESS="ar_EG"
LC_TELEPHONE="ar_EG"
LC_MEASUREMENT="ar_EG"
LC_IDENTIFICATION="ar_EG"
LC_ALL=ar_EG

refdoc writes:

> export LC_ALL=ar_EG; gnomesword

> Error message : (gnomesword:15597): Gtk-WARNING **: Locale not supported by C library.
> Using the fallback 'C' locale.

Well, I'd expect that result if the ar_EG locale is in fact not fully and correctly installed on your machine (and that's not exactly a common locale, you must admit).

Question #1) Does the shell command

    locale -a

output a list of locales that includes ar_EG ?

Question #2) How exactly did you add this locale data (for ar_EG) to your system? I would have expected

    sudo locale-gen ar_EG

but please confirm/correct me on this!

I am unable to confirm the issue with the ar_EG locale at all:

   sudo locale-gen ar_EG
   LC_ALL=ar_EG locale

works for me.

At this point, my suspicion is that the bug as originally reported may be related to how early GNOME stuff is started up, and that the corrupted locale issue is some sort of installation issue or problem with the process by which the ar_EG locale was installed onto your system.

Jonathan

$ locale -a
ar_AE.utf8
ar_BH.utf8
ar_DZ.utf8
ar_EG.utf8
ar_IN
ar_IQ.utf8
ar_JO.utf8
ar_KW.utf8
ar_LB.utf8
ar_LY.utf8
ar_MA.utf8
ar_OM.utf8
ar_QA.utf8
ar_SA.utf8
ar_SD.utf8
ar_SY.utf8
ar_TN.utf8
ar_YE.utf8

refdoc:

Your locale list includes ar_EG.utf8, but not ar_EG.
These are two different locales.

Please try:

    # Create and install the ar_EG locale
    sudo locale-gen ar_EG
    # Test it
    LC_ALL=ar_EG locale

I think this will fix your issue, which is not the bug described by the submitter, but something else.

Jonathan

Jonathan Marsden wrote:
> refdoc:
>
> Your locale list includes ar_EG.utf8, but not ar_EG.
> These are two different locales.
>
> Please try:
>
> # Create and install the ar_EG locale
> sudo locale-gen ar_EG
> # Test it
> LC_ALL=ar_EG locale
>
> I think this will fix your issue, which is not the bug described by the
> submitter, but something else.
>
> Jonathan
>
Correct. I am sorry to have confused the issue

Changed summary back. To be clear, I am using ZSH as my shell, not Bash; this problem is not Bash-specific.

Jonathan, do you have any idea what may be at fault here? I'm interested in filing this upstream but I'm not sure which Gnome package to target.

Andrew:

> Jonathan, do you have any idea what may be at fault here?
> I'm interested in filing this upstream but I'm not sure which Gnome package to target.

The more I look at this, the more I think there may well be no real bug here at all.

My change to the summary line was trying (apparently inadequately, since you undid it!) to suggest that the issue is not really "locale settings not respected by Gnome". Locale settings most definitely *are* respected by Gnome, when they are set in /etc/environment, or when set from the gdm login screen. I have multiple languages installed on this machine (English, French, German and Spanish), and I can log in using any one of them, and get appropriate menus, and clock date/time format, spell checking, etc. Locales *are* being respected. Unlike English, French, German and Spanish, I don't speak any Egyptian Arabic, so I've not tried logging in in that language :)

Rephrasing a bit: the issue being reported is (as I understand it, and now we are clear that refdoc's locale issue is clearly not a part of this specific issue): Gnome does not use locale settings which are set in the user's shell initialization file.

The question then becomes: Should Gnome in fact examine and use such settings, since Gnome does not itself necessarily use any per-session shell at all! Why would Gnome be expected to look in a user's shell initialization file? Is there documentation out there that says it should or will do so?

Especially since Ubuntu 8.10 has the "fast session switching" capability, allowing one to have multiple sessions open (logged in as different users) in different locales, I am not sure there is really much of a case for saying that Gnome *should* be parsing shell initialization files to look for locale settings -- is there? I'm open to hearing the argument that it should really do that, but trying to look at this from the user's viewpoint, I don't (yet?) see why it should.

The shell respects the locale settings set in the global environment and its initialization file(s); Gnome respects the locale settings in the global environment and it is own initialization files. (For example, have you considered setting locale-related variables in ~/.xsession, if you want to explore this kind of thing? Maybe in ~/.dmrc ??)

Logically, if you are using a GUI, then you set its locale at GUI session startup, just as you would set a shell's locale at shell startup. Each has a different way to specify its initial settings (though of course both respect the global environment).

Does this make sense?

Jonathan

Changing status to incomplete: unclear if this is really a bug, and earlier confirmation from refdoc turned out to be a different issue.

On Sun, Feb 8, 2009 at 00:39, Jonathan Marsden <email address hidden> wrote:

> My change to the summary line was trying (apparently inadequately, since
> you undid it!) to suggest that the issue is not really "locale settings
> not respected by Gnome". Locale settings most definitely *are*
> respected by Gnome, when they are set in /etc/environment, or when set
> from the gdm login screen.
>
> Rephrasing a bit: the issue being reported is (as I understand it[...]):
> Gnome does not use locale settings which are set
> in the user's shell initialization file.

Sorry! I've updated the status to reflect that. I was simply trying to say
that the problem is not Bash-specific. But I see your point....

> The question then becomes: Should Gnome in fact examine and use such
> settings, since Gnome does not itself necessarily use any per-session
> shell at all! Why would Gnome be expected to look in a user's shell
> initialization file? Is there documentation out there that says it
> should or will do so?

Good question. I've simply been assuming, intuitively, that my shell
initialization is where I put all environment variables, commands to be run
on login, etc.

(A quick test showed that my `echo "foobar" >> Desktop/filename` that I
added to ~/.zshrc was run once when logging into Gnome, so I don't think my
assumption is too far off? That discovery is confusing.)

I am not sure there is really
> much of a case for saying that Gnome *should* be parsing shell
> initialization files to look for locale settings -- is there? I'm open
> to hearing the argument that it should really do that, but trying to
> look at this from the user's viewpoint, I don't (yet?) see why it
> should.

I think the point isn't that Gnome should look for locale settings, but that
it should parse anything in the shell's initialization file once and only
once.

> The shell respects the locale settings set in the global environment and
> its initialization file(s); Gnome respects the locale settings in the
> global environment and it is own initialization files. (For example,
> have you considered setting locale-related variables in ~/.xsession, if
> you want to explore this kind of thing? Maybe in ~/.dmrc ??)

No, I haven't tried any of this; I've researched the topic a half dozen
times over the years and have found scant documentation/explanation. I even
brought it up on the seemingly ignored gnome-list—and, of course, got no
answers:
http://mail.gnome.org/archives/gnome-list/2008-September/msg00003.html.

Logically, if you are using a GUI, then you set its locale at GUI
> session startup, just as you would set a shell's locale at shell
> startup. Each has a different way to specify its initial settings
> (though of course both respect the global environment).
>
> Does this make sense?

Yes, I suppose. But that leaves the question: where do I put environment
variables that apply to "me", i.e. in a graphical setting and a terminal
one? /etc/environment is not appropriate (I'm only changing the locale
settings for my username) and I've never heard about anything else other
than what you mention above. :) If you have any ideas, I'd love to hear
them!

I'm reopening th...

I am not a GNOME i18n expert, at all. But I do know that if you use GNOME the way it was intended, i18n generally "just works" and you do not need to mess with manually setting locale variables in .bashrc or .dmrc or anywhere else.

Set a language at the gdm screen, and when prompted, tell it to make this new language/locale the default for your user, and it adds information to that effect to your ~/.dmrc Then, next time that user logs in, they get that chosen language/locale. Such a user will find that their shell locale is correct, too, when they open up a terminal window. Job done. User does not need to care where the info is stored or how it works. User never edits a ~/.anything file! It just works.

I think you are trying to "mess with" the guts of how GNOME does things, and (lacking detailed info on exactly how it works) that attempt is apparently confusing you. Since your end users are unlikely to do this kind of thing, your testing should probably do it the way your users will, for maximum fidelity. For one-time quick tests during development, you can of course always do

  LC_ALL=whatever LC_TIME=foobar gnomesword &

type of things, this sets the locale vars for that one process (and its subprocesses) only. The shell has allowed this for many years, probably decades, and this is not GNOME or Ubuntu specific in any way. If you want to test GNOME menus, then I think you need to be starting GNOME the way end users will, not trying to manually tweak it, if you want the tests to be valid for real life users.

Do you really truly need more that this? Is there really a bug here? If so, what exactly is the bug?

I'd suggest closing this as NOTABUG at this point. But that's just my opinion.

If you have a question (as opposed to a bug), then you could try using LaunchPad "Answers" to ask it, and see if you get a solid answer to it there. It might be good to phrase the question in terms of the user requirement "how do I achieve result X", rather than in terms of the method "how do I get GNOME to read locale settings from shell initialization file Y", for best results.

Jonathan

On Wed, Feb 11, 2009 at 13:46, Jonathan Marsden <email address hidden>wrote:

> Set a language at the gdm screen, and when prompted, tell it to make
> this new language/locale the default for your user, and it adds
> information to that effect to your ~/.dmrc Then, next time that user
> logs in, they get that chosen language/locale. Such a user will find
> that their shell locale is correct, too, when they open up a terminal
> window. Job done. User does not need to care where the info is stored
> or how it works. User never edits a ~/.anything file! It just works.

Right, the problem is when you want to "mix and match" locales. In my
situation, I simply want to change my time to 24-hour and my "first weekday"
to Monday, but retain everything else in en_US. Since GNOME does not offer
any way to do this, shell environment variables are the only way I know how
to do this.

Do you really truly need more that this? Is there really a bug here?
> If so, what exactly is the bug?

That I cannot customize my locale settings within a language (specifically
changing the time mode and first weekday, but I could not change any other
setting either).

> If you have a question (as opposed to a bug), then you could try using
> LaunchPad "Answers" to ask it, and see if you get a solid answer to it
> there. It might be good to phrase the question in terms of the user
> requirement "how do I achieve result X", rather than in terms of the
> method "how do I get GNOME to read locale settings from shell
> initialization file Y", for best results.

I'm inclined to think there's a bug (as I mentioned above) mainly because no
one seems to know how to do this in GNOME. Missing/undiscoverable
functionality is still a bug.

But fair enough; I should exhaust all resources:
https://answers.launchpad.net/gnome-common/+question/60699

Interestingly, I found this question, which doesn't really shed any light at
all: https://answers.launchpad.net/gnome-common/+question/6311

If no further information comes to light in the next 48 hours, I will report
this upstream and work with other GNOME BugSquad members to triage it.

i think the original bug report is not a bug because gnome should not read the shell initialization files.

gnome (gdm) reads the .profile (see /etc/gdm/Xsession) so any LC_* settings is best put there. see also my anser at https://answers.launchpad.net/questions/60699

This isn't a bug. ~/.bashrc is just that - a configuration file for the Bash shell. It is not the responsibility of gnome-session to read this file.

The session is started with /bin/sh, which is a symlink to /bin/dash on Ubuntu anyway, so Bash preferences will not work here.