After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 573950 - Locale settings in shell initialization not used by GNOME session
Locale settings in shell initialization not used by GNOME session
Status: RESOLVED NOTGNOME
Product: gnome-session
Classification: Core
Component: gnome-session
2.25.x
Other Linux
: Normal normal
: ---
Assigned To: Session Maintainers
Session Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-03-03 17:53 UTC by Andrew Conkling
Modified: 2009-03-25 12:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.25/2.26



Description Andrew Conkling 2009-03-03 17:53:18 UTC
Originally reported downstream: https://bugs.launchpad.net/ubuntu/+source/meta-gnome2/+bug/306591

I want to manually control my LC_TIME settings independent of my LANG, so I...

1. Added 'export LC_TIME="en_DK.UTF-8"' (sans quotes) to my ~/.bashrc and my ~/.zshrc. (I use ZSH as my shell, but it didn't work if I switched to Bash either.)
2. Start an application from GNOME Terminal or Run (e.g. `zenity --calendar`, `date`): locale setting is used.
3. Start an application from the GNOME Panel, look at the Panel's date applet, etc.: locale setting is not used.

(It's very possible these steps are not the canonical way to make these changes in GNOME, but for the life of me I cannot find the correct way. Believe me, I've tried!)

My workaround thus far: append 'LC_TIME="en_DK.UTF-8"' (sans quotes) to /etc/environment, and the setting is used by all applications, no matter how they are launched.

So it would seem that user-set locale settings are not being picked up by GNOME properly.
Comment 1 Ray Strode [halfline] 2009-03-03 17:57:08 UTC
This is probably a problem with your distro Xsession file not invoking gnome-session through a login shell.
Comment 2 Vincent Untz 2009-03-03 22:50:37 UTC
I fail to see how this could be a gnome-session bug. Ray is probably right. The other solution would be to use ~/.xsession
Comment 3 Andrew Conkling 2009-03-07 00:01:07 UTC
(In reply to comment #2)
> I fail to see how this could be a gnome-session bug. Ray is probably right. The
> other solution would be to use ~/.xsession

So it sounds like I'm not crazy in expecting this to work. I definitely never claimed to be right about gnome-session though; is it possible this is a bug in a different product?

Ultimately, I don't want to have to "roll my own" ~/.xsession, so if the problem is squarely downstream I will continue trying to figure it out there.

But, just so it's clear, if only for posterity, the following files will not affect this change: ~/.gnomerc, ~/.environment, ~/.xsession, ~/.gdmrc, ~/.dmrc, ~/.xsession. One would think that one of them would, but alas.

And is it this more of an issue with how Ubuntu starts X/GNOME or is there a GNOME-ish way of passing environment variables for the session of which I'm not aware?
Comment 4 Vincent Untz 2009-03-25 01:54:18 UTC
(In reply to comment #3)
> And is it this more of an issue with how Ubuntu starts X/GNOME or is there a
> GNOME-ish way of passing environment variables for the session of which I'm not
> aware?

The X startup scripts are really distribution-specific. You should raise the issue in launchpad, I guess.
Comment 5 Andrew Conkling 2009-03-25 12:14:14 UTC
(In reply to comment #4)
> The X startup scripts are really distribution-specific.

Gotcha, thanks for clarifying.

> You should raise the issue in launchpad, I guess.

Yeah, I had originally, as I mentioned in the original bug. No one there seems to know. :P

(In reply to comment #0)
> Originally reported downstream:
> https://bugs.launchpad.net/ubuntu/+source/meta-gnome2/+bug/306591

If you follow the thread of links from this bug, you'll see I've asked just about everywhere and no one seems to know the answer.

I'm beginning to think this isn't possible, at least in Ubuntu. :P