Re: XIM, kinput2 & Tk

[Mike Fabian <mike.fabian@example.com>]

jwb@example.com (Jim Breen) writes:

> >> From: "Stephen J. Turnbull" <turnbull@example.com>
> >> >>>>> "B0Ti" == B0Ti  <9915104t@example.com> writes:
> >>     B0Ti> Jim Breen wrote:
> >>     >> And to follow up my previous partially rhetorical question, if
> >>     >> a Swede wants to run a kterm, while still getting messages
> >>     >> etc. in Swedish,
> >>     >> (a) what does he/she set variables to?
> >>     >> (b) how should kterm respond to which which variables?
> >> 
> >> However, in theory, you simply set LANG=se_SE.ctext.  Then what
> >> happens is that the application spits out Japanese output in
> >> ISO-2022-JP, while kterm's messages are in ISO-8859-1.  This only
> >> works because of the definition of the X Compound Text encoding and
> >> the assumption that the app is capable of producing ISO-2022-JP.
> 
> Won't this stop kterm calling up "kinput2 -xim", because LANG is not set
> to Japanese?

No, you can start kterm with

   ~$ LANG=ja_JP kterm

and then, in the shell within kterm, set LANG to something else.

Setting LANG in the shell running in kterm does not affect kterm
itself anymore, but all the applications you start from the shell
running in kterm.  For example, you can get the messages from a tool
like "ls" running in kterm in any language you want. If this language
needs characters outside of ASCII and Japanese, you may have problems
to display these characters in kterm though. If you can set a locale
which uses iso-2022-jp encoding (as Stephen suggests) it will probably
work in kterm because kterm can deal with iso-2022-jp. But I don't
remember whether iso-2022-jp locales (like Stephens example
"se_SE.ctext") are currently available in Linux. 

-- 
Mike Fabian   <mike.fabian@example.com>