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 -- To UNSUBSCRIBE, email to debian-openoffice-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131218.110945.234355979.fu...@hawaii.edu
