Re: japanese environment problems

[Tomohiro KUBOTA <tkubota@riken.go.jp>]

Hi,

At Tue, 1 May 2001 10:17:36 +0900,
helary@niji.or.jp wrote:

> > Please tell me which version of user-ja you are using.  And, please
> > tell me which shell you are using.  (user-ja supports bash and tcsh
> > only.  No support for zsh and so on.)
> 
> i tried to read the man page under kon but it comes with a huge number of 
> mojibake. the only thing that reads well enough is the date : 1998/10/26. i 
> use bash.

Well, I wanted to know the package version of user-ja.
Please try dpkg -s user-ja.


> i have installed canna and canna supporting nvi. as root nvi works all right, 
> as user, nvi does not accept the input toggle method that works under root 
> (once you have nvi running, type ^o and nvi shifts to japanese input mode). 
> it says ^o is not a vi command (if you type in command mode) or it just types 
> ^o on the screen without toggling anything... :-(
> 
> the .nexrc in root directory and in user directory have the same info (except 
> that i added manually 'set cannakey=^o' for user.

Though I don't know what version of user-ja you are using, recent user-ja
(language-env) uses ^k as toggling key.  And more, "vi" or "nvi" may be
an alias to change $NEXINIT.  All of them depend on the version of user-ja.



> i understand this problem. i was just wondering whether it was possible to 
> properly configure lynx ox mutt so that they understand what character set to 
> display according to the document char-set. my problem is that i do not 
> understand the problems associated with displaying a non-ascii character on 
> the console so i don't know why mutt and lynx need -ja versions to work 
> properly.

Problems have to divided into two parts:  First, how lynx and so on can
recognize the encoding of the documents?  Next, what encoding lynx and
so on should use to display the documents?  In HTML, encoding of documents
are given by the header.  Encoding for terminal/console should be determined
by LC_CTYPE locale but so far no terminals are locale-sensible (I am working
on xterm and rxvt to support locale-sensibility.  Though they are almost
finished, they are development versions and it will need some time for
them to get into Debian.)


> for ex, on my mac (under os 8.1 ja) i can read french on the web or french 
> emails. so the display is independant on the environment. why can't it be so 
> under kon/mutt or kon/lynx or kon/ee ?

If you are really interested in these problems, I recommend you to
join development.  (Since most developers who are interested in i18n
work for X environment, i18n of console is a "Noosphere" to be
"homesteaded".)  If you are interested in i18n development,
please read my document "Introduction to I18N"
http://www.debian.org/doc/manuals/intro-i18n/


> > I don't know about UTF-8-based internationalized terminal which
> > support Japanese.  (You know, unicode_start in console-tools
> > package doesn't support Japanese.)  
> 
> why ?

Because we lack human resources for development.


> so, basically, you say that i should dump lynx and mutt and use emacs, 
> properly configured, to do anything... :-( i suppose if i can't find another 
> solution that is what i will have to do. but is am not such an extensive user 
> that i need emacs. most of my editing is simple and ee is fine. emacs seems 
> way too big for me !

Sorry, this situation is what Japanese-speaking people are located.
I am really dreaming all softwares will be able to handle Japanese
and I am working on i18n development, but I am not almighty and there
are many softwares which cannot handle Japanese.

If you think emacs20 is too big, try mule2.  It is a multilingual
extension to emacs19 and a bit smaller than emacs20.


---
Tomohiro KUBOTA <kubota@debian.org>
http://www.debian.or.jp/~kubota/
"Introduction to I18N"  http://www.debian.org/doc/manuals/intro-i18n/