Bug#631237: libreoffice works with ibus in sarge/wheezy/jessie
Dear Aoki-san,
Thank you again for your response and for your patience.
Discussion with you is very helpful to me.
>> Thank you for your response. As you say, this issue may
>> well be due to ibus.
>
> Excuse me, I do not understand this response. I meant to say that
> you are creating problem by using ibus under the wrong environment
> due to misconfiguration.
I see. I now understand your position.
>> > What locale you are running ibus mini-window and X matters.
>> > I do not have reference now but pretty sure it has to be UTF-8
>> > locale.
>>
>> I'm not disagreeing with you, but it's strange that ibus should
>> depend on a locale.
>
> It is natural for me.
And your reason? Ibus is a multilingual program by nature.
Why is it "natural" for it to depend on LANG?
>> It's plugin-based and designed to handle
>> all sorts of languages (and other phonetic alphabets)
>> AT THE SAME TIME. You can input Russian, International
>> Phonetic Alphabet, Korean, Japanese, etc. using ibus
>> in a single text box without restarting ibus.
>> Then, what locale should you set for it? Or is there any
>> "generic" UTF-8 locale? like "C.UTF-8" or "anylanguage.UTF-8"
>> or some such thing?
>
> There was a discussion to create non standard C.UTF-8 to avoid
> this kind of breakage by d-i folks as I understand.
> It did not happen.
Thanks for the information. But as I said above, this issue is
more than just "avoid this kind of breakage". In principle,
multilingual programs shouldn't depend on language-specific
settings (except for the language to display
error messages and menu items in).
By the way, I see
$ locale -a
C
C.UTF-8
POSIX
en_US.utf8
ja_JP
ja_JP.eucjp
ja_JP.ujis
ja_JP.utf8
japanese
japanese.euc
$
"C.UTF-8" looks like what you mention and may be
what I'm looking for. I'll give it a try.
> If you need to set environment for your shell prompt, set it with
> their startup code location for your shell such as ~/.bashrc or
> ~/.profile (Please make sure the gdm/kdm/.. like program which you
> use does not read .profile if you use it to set locale. kdm had such
> bug once).
I don't think that is a "proper" solution. (Again, I'm NOT
attacking your or complaining to you. I just want to discuss.)
I write my scripts for "/bin/sh". Remember that it used
be a symlink to bash? It's now a link to dash. Who knows what
the next change will be? But, that should NOT matter as long as
your script is Bourne-shell compatible. For this reason,
it's not a "proper" solution to rely on things like "~/.bashrc".
The Bourne shell doesn't read any startup script except
it reads ~/.profile if invoked as a login shell.
Moreover, it is extremely hard to find out all changes you have
to make. To have to modify gdm, kdm, etc. so that it won't read
your ~/.profile is one example. BUT, I NEED OTHER ENVIRONMETAL
VARIABLES in ~/.profile for my desktop system!! What should I do?
(For example, I often invoke LaTeX from within emacs,
and for LaTeX I need some env. vars., which are set
in my .profile. I suppose LaTeX in that case inherits
env. vars. from the desktop system if emacs is invoked
from the desktop start menu.)
I sometimes do "su -". What care should I take to avoid
getting LANG=en_US.UTF-8 as root? What about "sux"?
What about "ssh remotemachine somescript"? I sometimes
invoke emacs from the start menu of my desktop environment
and within emacs I sometimes invoke a shell. What environment
does it get? I sometimes use eshell? Does it depend on
LANG or not?
This is like solving a big puzzle. I know you would
eventually find answers to all these questions, but
there are simply too many things to worry about if you have
a system-wide default LANG setting, and you will be hit by
another problem in the future when something changes or when
you start to use something new. Or, when you create a new
user and log in to it, you have to remember everything
you have to change to avoid the problem of "rm [A-Z]*".
This is insane, don't you think?
For these reasons, our desktop system should not rely on
a system-wide LANG setting. Or if it does, there should
be a language-neutral setting such as C.utf8, which doesn't
affect the critical behaviors of the shell and traditional
shell tools (ls, grep, etc.).
Cheers,
Ryo
Reply to: