Activation: b-a-s problems.

[Richard Hult]

ons 2004-01-07 klockan 16.51 skrev Mark McLoughlin:

Hi,

>   - Multiple languages
> 
> 	If a client running under language A activates a service and it has
> already been activated under language B, we always want a new instance
> of the service running under language B ... assuming that the service
> provided is actually language specific and/or it cannot provide that
> service for multiple languages.
> 
> 	At first glance, it might seem like per-language service activation is
> the right way to go, but we do have at least one example of service that
> can serve multiple languages - gconfd. So:
> 
> LANG=en_US clock
> LANG=en_GB clock
> 
> 	should not cause two gconfds to be started, but rather gconfd will
> correctly hand out the default value for the "hour_format" preference in
> both cases (i.e. 12-hour in en_US and 24-hour in en_GB).
> 
> 	On the other hand, if you do:
> 
> LANG=en_US gnome-terminal
> LANG=en_GB gnome-terminal
> 
> 	there should be two gnome-terminal processes - one which lets you
> configure the terminal "colors" and the other which (correctly) lets you
> configure the terminal "colours".

Are there any useful real world use cases for this? I can imagine that
some applications don't work correctly in some locales, and therefore
you'd want to run them in e.g. English. If so, then I guess that's good
enough reason for having per-language services.

(I tried to find bugs in GNOME bugzilla addressing locale problems, but
I didn't really find a lot of reports. One person wanted to run
evolution in English under a Russian locale, and the other problem
seemed more like badly setup locale variables causing some trouble with
panel applets.)

If we do go for per-language services, then we should probably not
consider all the LC_* variables, but only LANG, or otherwise it could
quickly become a big mess...

Thanks,
Richard

-- 
Richard Hult                    richard@imendio.com
Imendio                         http://www.imendio.com