Description of problem: The environment variables set by localedrake in the file ~/.i18n don't seem to be picked up by the system at all. Here's my ~/.i18n: [ruben@localhost ~]$ cat .i18n # Fitxer de sistema: /etc/sysconfig/i18n # Localedrake reescriu aquest fitxer! LC_TELEPHONE=ca_AD.UTF-8 LC_CTYPE=ca_AD.UTF-8 # LANGUAGE=ca:es_ES:es LANGUAGE=ca:eo:en LC_MONETARY=ca_AD.UTF-8 LC_ADDRESS=ca_AD.UTF-8 LC_COLLATE=ca_AD.UTF-8 LC_PAPER=ca_AD.UTF-8 C_NAME=ca_AD.UTF-8 LC_NUMERIC=ca_AD.UTF-8 LC_MEASUREMENT=ca_AD.UTF-8 LC_TIME=ca_AD.UTF-8 LANG=ca_AD.UTF-8 LC_IDENTIFICATION=ca_AD.UTF-8 LC_MESSAGES=ca_AD.UTF-8 GTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus # Cal descomentar això perquè Ibus s'engegui a l'inici de sessió XIM_PROGRAM="ibus-daemon -d -x" However, the variables aren't read: [ruben@localhost ~]$ echo $LANGUAGE ca:es_ES:es [ruben@localhost ~]$ echo $XMODIFIERS @im=none Version-Release number of selected component (if applicable): How reproducible: Always, either through localedrake or editing ~/.i18n by hand. Steps to Reproduce: 1. Run localedrake as a regular user, either from the menu entry or from terminal. 2. Change your language to one of the installed ones, or set an input method like Ibus or Scim. 3. Log out and back in. Nothing has changed. Reproducible: Steps to Reproduce:
Your shell is expected to read it. (through /etc/profile.d/10lang.sh) What's your desktop?
CC: (none) => thierry.vignaudWhiteboard: (none) => version
I'm using LXDE. My display manager is LXDM too. Is that the problem?
Actually, it seems other people has encountered that problem when using LXDM and Ibus: http://translate.google.com/translate?sl=zh-CN&tl=en&js=n&prev=_t&hl=ca&ie=UTF-8&u=http%3A%2F%2Fwww.ubuntu-tw.org%2Fmodules%2Fnewbb%2Fviewtopic.php%3Ftopic_id%3D52594 Also, I use autologin.
BUMP! Any news on this?
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD
I think this one is still right. @Olav, Nicolas: is there a way to configure gnome/kde/plasma locale per user now?
Status: RESOLVED => REOPENEDCC: (none) => mageia, mageia, olavVersion: 3 => CauldronResolution: OLD => (none)
This should be used: http://www.freedesktop.org/wiki/Software/systemd/localed/
This alters the _system_ setting, not the _user_ setting. Previously we could have system in English, user A in French, user B in Spanish, ... For now, that's no more possible...
(In reply to Thierry Vignaud from comment #8) > This alters the _system_ setting, not the _user_ setting. > Previously we could have system in English, user A in French, user B in > Spanish, ... > For now, that's no more possible... FWIW, this was discussed recently at various hackfests. There are plans to make localed work in the user session on the user bus too (and inface the systemd-consoled for text console logins makes some progress towards this). So while fixing this in the short term is good, longer term, this will very much be possible.
inface = in fact
Is this bug still present in latest cauldron? Adding NEEDINFO whiteboard marker.
Keywords: (none) => NEEDINFO
(In reply to Samuel VERSCHELDE from comment #11) > Is this bug still present in latest cauldron? Adding NEEDINFO whiteboard > marker. (keyword, actually)
Version: Cauldron => 5
I'm now on Mageia 5 (still with LXDE and LXDM) and after a year and half and two Mageia versions this is still not working. The user desktop doesn't pick up any change to ~/.i18n. In fact, Mageia's management of multiple languages seems screwed up from the ground up. LXDM doesn't let me change languages either. What's the point of allowing the installation of multiple languages then? Just using up disk space? I teach immigrant kids and I want to make things easier on them by installing their languages on our laptops. If I can't do it, Linux is no better than Windows. Or maybe I should be trying a better distro? I hope not, after using this one since the Mandriva 2007 times.
(In reply to Rubén Fernández from comment #13) > I'm now on Mageia 5 (still with LXDE and LXDM) and after a year and half and > two Mageia versions this is still not working. The user desktop doesn't pick > up any change to ~/.i18n. CC'ing the LXDE maintainer, in case there's something he can do (In reply to Colin Guthrie from comment #9) > (In reply to Thierry Vignaud from comment #8) > > Previously we could have system in English, user A in French, user B in > > Spanish, ... > > For now, that's no more possible... > > FWIW, this was discussed recently at various hackfests. > > There are plans to make localed work in the user session on the user bus too > (and in fact the systemd-consoled for text console logins makes some progress > towards this). > @ Colin Is there any news?
Keywords: NEEDINFO => (none)CC: (none) => marja11, nicolas.salgueroAssignee: bugsquad => mageiaSource RPM: drakxtools-15.54.1-3.mga3.src.rpm => drakxtools, systemdWhiteboard: version => (none)
Created attachment 7471 [details] A patched version of initscripts-mgaconf.patch Hi, I did some tests and found that, whether you use autologin or not, a login shell (i.e. which sources /etc/profile, then /etc/profile.d/10lang.sh) is launched when no user is already defined. So, the code: """ for langfile in "$HOME/.i18n" /etc/locale.conf /etc/sysconfig/i18n ; do [ -f $langfile -a "$LC_SOURCED" != 1 ] && . $langfile && LC_SOURCED=1 && export LC_SOURCED done """ skips "$HOME/.i18n" and sets LC_SOURCED to 1 for /etc/locale.conf. When the user logs into LXDE, LC_SOURCED=1 and the above code is not executed anymore (and "$HOME/.i18n" is ignored even if it exists). The solution is to do "unset LC_SOURCED" at the beginning of the script in all cases. Best regards, Nico.
Keywords: (none) => PATCH
(In reply to Nicolas Salguero from comment #15) > Created attachment 7471 [details] > A patched version of initscripts-mgaconf.patch > Hi Nico, Thanks for your patch and sorry if nothing was done with it. Do you know whether this bug is still valid for Mga6 and Cauldron? (Reassigning to the basesystem maintainers, in case this report needs to stay open for a supported Mageia version)
Assignee: mageia => basesystem
Maybe this did get fixed, but I want to be absolutely sure, so changing Version: to Cauldron and setting MGA6TOO until it is proven this got fixed.
Whiteboard: (none) => MGA6TOOCC: (none) => mageiatoolsHardware: i586 => AllVersion: 5 => Cauldron