Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: kinput and kterm SOLVED!!!!!



Martin Baehr <mbaehr@example.com> writes:

> On Mon, Oct 22, 2001 at 02:58:21PM +0200, Mike Fabian wrote:
> > > > |en_US ISO-8859-1
> > > > |en_US.UTF-8 UTF-8
> > > > |ja_JP.EUC-JP EUC-JP
> > > > |ja_JP EUC-JP
> > > > |ja_JP.UTF-8 UTF-8
> > > kinput still doesn't work, but the errormessage is gone,
> > You wrote in another mail:
> > MB> $ Warning: locale not supported by C library, locale unchanged
> > MB> Couldn't set locale: ja_JP.eucJP,ja_JP.ujis,ja_JP.EUC,japanese.euc,Japanese-EUC,ja,japan
> > None of the locales you did set in /etc/locale.gen is on the list of
> > locales which kterm tries. Put ja_JP.eucJP as well in /etc/locale.gen.
> 
> no, read again, adding the above locales DID fix the error.
> 
> and as it turned out, when i tried again at home also kinput DID work.

> > > and kterms menues are now in japanese 
> > > (not sure i want that, as i can't actually read it ;-)
> > Or, if you want to change it globally, you may remove the global
> > Japanese app-defaults file.
> 
> no need for any of that, as it turns out, all that is really necesary is
> to set 
> XMODIFIERS="@example.com=kinput2"
> and i guess the generated locales as well.
> (i don't know what to delete to test 
> if having the locales makes a difference)
> 
> nothing else.
> kinput happily works with all my locale stuff set to C,
> allowing me to keep english menues without having to move stuff around.

kterm behaves quite weird with setlocale. Internally, it tries to set
all locales from the above list, no matter what locale you have set in
your environment. I.e. even if you have your locale set to C,
kterm ignores this and tries to set the locales from the above
list subsequently

    setlocale(LC_CTYPE,"ja_JP.eucJP")
    setlocale(LC_CTYPE,"ja_JP.ujis")
    setlocale(LC_CTYPE,"ja_JP.EUC")
    ...

and stops after the first sucessfull call to setlocale(). I.e, even if
you have you locale set to C, but you have a locale ja_JP.eucJP
available, kterm will use ja_JP.eucJP internally. This often forces
kterm to work correctly with Japanese even if you have set a
non-Japanese locale in your environment. But, depending on the version
of your libc, this sometimes seems to cause problems. You don't see
any error message because the kterm internal setlocale() call is
successfull, but something still doesn't work right. That was what I
suspected when you wrote:

> ahh, i set these:
> 
> > |en_US ISO-8859-1
> > |en_US.UTF-8 UTF-8
> > |ja_JP.EUC-JP EUC-JP
> > |ja_JP EUC-JP
> > |ja_JP.UTF-8 UTF-8
> 
> kinput still doesn't work, but the errormessage is gone,

I have observed exactly the behaviour you describe here with some
versions of glibc. I.e. kterms way of changing the locale again
internally does really cause problems in some environments. 

Anyway, I think kterms way of changing the localle internally
behind the back of the user is a very weird, non-standard behaviour,
therefore I patched this in the SuSE kterm rpm to use

    setlocale(LC_CTYPE,"")

instead, i.e. use the locale set in the environment. Then of course,
you *must* start kterm with a Japanese locale otherwise XIM
won't work. But then kterm will also load Japanese app-defaults,
as it should be. To get English menus, you have to use English
app-defaults for kterm (preferably in your home directory). 

-- 
Mike Fabian   <mfabian@example.com>   http://www.suse.de/~mfabian
睡眠不足はいい仕事の敵だ。

Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links