GNOME Bugzilla – Bug 60701
activation does not pass LANG, other locale-related variables.
Last modified: 2005-02-03 09:22:05 UTC
Real life-example: on my system, $LANG is set to "ru". I want to start Evolution-0.11 with English locale, so I run it in bash as following LANG=en evolution (killing all user processes before it, so no active components would be running, and then logging in to gnome and running 'killev' 5 times). But I get evolution components running under "ru" locale (they have interface displayed in russian) - it seems it's because bonobo components are activated by oafd (or whatever) that was started under "ru" locale. So when component is being activated, environment variables of the client processes should be exported to the component before starting it. Probably even if the component is on remote computer, all environment variables need to be exported to it. Or the ones from the list of variables either hardcoded into oaf or listed in configuration file (the later is much more preferable!). It's very critical bug that violates all locale concepts for bonobo-enabled programs. PS: Dan Winship said it's oaf problem, not an Evolution's one.
This seems very similar to a problem that I'm having with gnome-terminal. If the system locale is set to a different locale than the session locale set in gdm, when a gnome-terminal is launched without the factory then it gets the system not the session locale. Reproduction Path: 1. Login from gdm with a locale different than the system locale. For example, my system locale is en_US, and the gdm session locale is ru_RU.KOI8-R. 2. Open a gnome-terminal from the gnome menu (verify that it uses the factory, i.e. gnome-terminal --use-factory --start-factory-server) 3. Check the Language environment variable. bash# echo $LANG yields : ru_RU.KOI8-R 4. Set the LANG to another valid language. bash# LANG=en_US.ISO8859-1 5. Launch another gnome-terminal from the terminal changed in 4. bash# gnome-terminal & 6. Check the LANG variable in the new terminal. bash# echo $LANG yields: en_US (the system wide locale). It seems that the second gnome-terminal should inherit the locale from it's parent. It seems as though it is not inheriting the LANG environment variable from the parent. For some reason when the factory is used (see step 2) the LANG variable in the terminal is set correctly otherwise. I'm not really well versed in how environment variables are managed in gnome. Since this bug seems to address a similar issue so I'm posting this here, however if the issues are separate, please let me know and I'll be happy to write this up against the gnome-terminal.
I will make oaf pass the LANG environment variable and all the LC_* variables. Note that it still won't be possible to run evolution in two different locales at once as the same user; but it will at least be possible to run it in different locales serially.
Hi, Maciej! Thank you for paying attention to this problem! It seems to me that all GTK_* and GDK_* variables needs to be passed too (so user will be able to run evo with different GTK theme). Also please pass LD_PRELOAD too - this way various special extensions can be used. Also ESPEAKER can matter IMHO. Also it would be nice to pass MM_CHARSET and LESSCHARSET - these are charset-related variables too. At the end you'll conclude that it will be much easier to load a list of variables from file in /etc/ or somewhere :) I hope you'll reach this point, seriously. To everybody reading this ticket's comments: may be anybody can add some more names of variables to pass? Thanks.
Reassigning bonobo-activation bugs to michael.
*** Bug 81403 has been marked as a duplicate of this bug. ***
So if one has the env. set up correctly at login, one gets a reasonably sane environment, then, Michael?
Yes; as long as you use 1 language, and you setup LANG at login time - perhaps gdm or something - and assuming that bonobo-activation-server has quit cleanly ( all it's components quit cleanly ) last session, it should be fine.
In gnome2.2, applets get LC_ALL which look like: LC_ALL=LC_CTYPE=ru_RU.UTF-8;LC_NUMERIC=C;LC_TIME=ru_RU.UTF-8;LC_COLLATE=ru_RU.UTF-8;LC_MONETARY=ru_RU.UTF-8;LC_MESSAGES=ru_RU.UTF-8;LC_PAPER=ru_RU.UTF-8;LC_NAME=ru_RU.UTF-8;LC_ADDRESS=ru_RU.UTF-8;LC_TELEPHONE=ru_RU.UTF-8;LC_MEASUREMENT=ru_RU.UTF-8;LC_IDENTIFICATION=ru_RU.UTF-8 After that point, noone can deal with this LC_ALL properly ("...not supported by C library"...). So applet i18n is broken in 2.2:(
I would be very suprised if this was the case. The applet will inherit its LANG settings from the bonobo-activation-server's context - which it inherits when it runs for the first time. Possibly your activation-server is not exiting cleanly since some app that is using it is similarly not quitting cleanly.
Just checked 2 environments (in proc): bonobo-activation-server and gswitchit-applet. See attachments. LC_ALL is missing at all for bonobo-activation-server (which is ok for me). There are LANG and LC_NUMERIC (and CHARSET if it related:). For the applet, LANG and LC_NUMERIC are ok - and there is some funny LC_ALL as well.
Created attachment 15089 [details] Bonobo-activation env
Created attachment 15090 [details] applet env
How are you extracting these env dumps ? AFAIK we make no effort to special case any of this - so it should be simply inherited from the starting process that forks bonobo-activation-server. This is a design feature. The problem is that it's really not feasible to have a mixed language desktop with out of process components - since gettext is _fundamentally_ a single language per process translation tool. So ... I think this is a wontfix. Sorry; why is it that you want to run the apps in different languages anyway ?
WONTFIX? Don't you know that applets are not propertly localized - the applet I18N is BROKEN. Try to start gnome session with any non-english language and add any applet which is not shlib - you will see _English_ UI, not localized. For example, try multiload applet. The envs I got from /proc/{procid}/environ.
> The problem is that it's really not feasible to have a mixed language > desktop with out of process components - since gettext is > _fundamentally_ a single language per process translation tool. I'm sorry, but how gettext affects us here? It's OK to have different locales in different processes for gettext. As why one may need to run programs in different locales on the same desktop: 1) a buggy program can just crash/misbehave if run in non-english locale or behave differently. 2) Translation may be too bad or very incomplete so poweruser may wish to work with app with e.g. english UI rather than semi-english-semi-something. 3) User may have to work with files with names in different encoding than desktop's one - so user have to start the app with locale for the same language but different encoding. 4) Translator may be wishing to check how app looks in english while translating to other language. 5) Just for studying foreign languages people try to work with familiar apps with different language of UI. There are a lot of reasons, in fact.. So it definitely shouldn't be WONTFIX .
Sergey; If you can do a killall -9 bonobo-activation-server; a bonobo-slay, and log-in in a different locale, and repeat this localization problem - then there is indeed a bug; and I'm interested in it. Otherwise - there is nothing we can do. If there is a bonobo-activation-server left running between sessions - this is due to a badly behaved bonobo component, that has not quit cleanly. The component needs fixing - check to see what is still running after quitting a session. There is _NO_ way that we can make gettext produce different translations in different contexts. Consider that an applet / component may be rendering text to 10 completely different apps, each in different locales - it may then call a library method to get a translated string _How_ does that library method know which locale to return the string in ? That is one half of the problem; the other half is that applications except to get a handle to the same process irrespective of locale in many cases; otherwise we could simply spawn a new component per locale. Indeed - it would be nice to do this - but it requires server extensions etc. and the server is currently pretty unmaintainable / extensible. It's furthermore not clear that that is the right way to go. SO I think this is a combination of some badly behaved random component; and a rather more fundamental problem.
Just tested - logged out. Killed all process running from my account (svu). There was no bonobo-activation-daemon there, BTW. And logged in into Greek locale. The applets were still using English UI strings. Is this what you asked for?
If I run the applet from gnome-terminal (/usr/libexec/multiload-appplet-2) and then add it to panel - I see normal localized strings in the applet. But if I add it from panel menu - English only.
Back to our original problem. I think that ideally a new process with component should be started if values of user-defined combination of "important" env vars of the app requesting component is different from the ones of already running components. User may wish to declare the following vars to be important: LC_*, LANG, GTK_RC_FILES and a lot of others. Since it's difficult currently to implement this, I propose to start only one instance of the component (as it's done now) BUT with locale-related vars of the invoking process. Even this will solve a lot of problems because most of the time the components are used by only one process (e.g. evolution), and that mostly powerusers use locale different from desktop's one for apps (and if needed, powerusers will be able to kill the processes with components manually if they need to start the app in yet another locale).
The applet localisation problem doesn't seem to be there for me at least. Is this problem still relevant, and can you clearly point out what the remaining problems are? Maybe closing this bug and opening a new one with less confusing comments would be an idea :)
Kjartan, which locale are you working with? Could you try to add any OUT-PROC (this is essential) applet to the panel and look at its properties. For example, try gnome-pilot applet. Is it localized? I see English UI only:(
This is a really vicious bug; if in fact it does exist. The only bug I'm interested in fixing is: Log out / ensure that b-a-s is dead (killall -9 bonobo-activation-server / bonobo-slay) / re-login in a different locale; the applets should inherit the new LANG. I can't quite see how they could not really; but I havn't tested it recently.
The problem is that OUT-PROC applets are not localized at all (IN-PROC are ok). So you can login and relogin under ANY locale - you'll see only English (non-localized) UI. At least that it the way it works for me. Could anyone please try any OUT-PROC (be sure of that!) applet and confirm (or deny:) it is not my wrecked system.
Ok; so I re-tested this, and it works fine. I was using bonobo-2.2.1.1 Screenshot attached for the doubting Thomas' out there.
Created attachment 16484 [details] proof positive - at least for me.
Created attachment 16485 [details] This is what I see in popup when insert applet in usual (bonobo-activation based) way
Created attachment 16486 [details] That's what I see when I run /usr/libexec/battstat-applet-2 from console (and then add it to the panel) - you see, it is localized
I would be happy to agree with you but... my panel behaves in a different way (see my 2 attachments). libbonobo 2.3.1 (it does not matter, it was same with fresh RH9 installation). Vlad, could you please check your system - do you see russian localization properly? I don't even know where I could look for tuning or something...
Unfortunately I don't have either RH9 or gnome2-loaded on any machines I can reach today and tomorrow.. Sergey, could you please post a cry for testing help on gnome-cyr@ in russian wrt this - I hope a lot of people will try to help.. (Also - did you install your RH9 from scratch or upgraded RH8 to RH9? May be that can matter..)
I found the possible cause. In my system, I had /etc/sysconfin/i18n LANG="ru_RU.UTF-8" CHARSET="utf-8" LC_NUMERIC=POSIX SUPPORTED="en_US.UTF-8:en_US:en:ru_RU.UTF-8:ru_RU:ru:en_IE:en_IE@euro:en_IE.utf8:en_IE.utf8@euro" And gnome session used DEFAULT language of the system. When I cleaned up /etc/sysconfig/i18n (rebooted after that) and chosen RUSSIAN language for the gnome session - applets are localized OK. Now, I do not know how to interpret this info - is this still bug or not? If system locale is RUSSIAN and gnome session is DEFAULT - should applets be localized?
Sergey: yes, it seems applets should be localized in this case. I'm reopening this bug (the original issue was not fixed). Please do not make it resolved until the original issue is not dealt with. Current proposed solution - start a single out-proc instance with "important" env vars of the caller. Ideally an instance should be started for every combination of invoker's "important" environment variables.
Vlad - you're smoking crack. I'm trying to get to fixing this bug in HEAD; however the oafd behavior is relied on by evolution-mail for it's locking, so you would badly shaft your mail if this was 'fixed' in oaf. It's easy to propose a solution; it's harder to do the work.
If I understood cerrectly I'm suffering from this problem: brain, ~ > env | grep LC_ LC_CTYPE=ru_RU.KOI8-R LC_COLLATE=ru_RU.KOI8-R brain, ~ > env | grep LANG brain, ~ > Everything is as I expect (english UI with ability to type russian), but appplets do have russian UI. If this bug is my case then are there any plans on fixing it?
I think the new libbonobo 2.6.x "bonobo:environment" oaf_info property takes care of this... Of course, applications now need to make use of this property in order to get fixed.
Think this was just fixed in bug #164303 *** This bug has been marked as a duplicate of 164303 ***