Mailing List Archive

Support open source code!


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

Re: Japanese input (was RE: tlug: Japanese)




-----Original Message-----
From: Matthew J. Francis <asbel@example.com>
To: tlug@example.com <tlug@example.com>

>  Anyway, If you've used Windows at all, perhaps you've
come across a
>little free Japanese word processor called (strangely
enough) JWP; it has

I've heard of it, but I've never used it or seen it myself.

>builtin EDICT searching and several useful sorts of
character-lookup
>method, but perhaps what I liked about it most is that the
input works
>sensibly, as you describe. Kanji could be input without
losing
>editability, and without focus gratuitously jumping around
the place.

Japanese input works this way in all proprietary OSes too,
and I confess that they spoil you.  The main reason that I
spend as much time under Windows as I do is simply because
Japanese input works so well, and even works in a lot of
English applications.  For example, my computer at home has
the English version of Outlook Express, but it has
absolutely no trouble with reading Japanese or accepting
Japanese input, with the exception that it doesn't take
Japanese input correctly in subject lines.  The localized
version has no problem with that.  Overall, it's very nicely
internationalized.  If I were working only in English, I
would have no reason to use Windows except for those times
when I need to produce an English version of a document that
was created in MS Office, which is what's used in my
company.  At home, I would just need it for Internet Phone.

Because I'm spoiled by the quality of the Japanese input
front-ends and conversion engines on <insert proprietary OS
here>, I do find myself often hoping that something just as
good will one day emerge on Linux/Unix.

>  With that thought, one of the first items on my list of
things to
>attempt to add into Yudit was JWP-like
"never-leave-the-spot" Kanji
>entry. Yudit does already support Canna and KInput2, but I
can't see
>a really obvious way of making KInput2 behave right
either - so
>essentially I was looking at adding a direct interface to
Canna without
>going through KInput2.

Here's a "think big" suggestion/idea:  one of the problems
that I see in the general world of Unix Japanese input is
that there are too many different ways of doing it: Kinput2,
Canna, Wnn, SKK, Egg, etc., (I must be leaving out
something), whereas the proprietary OSes essentially have
just one for each platform.  Atok is available as an
aftermarket item, but it is apparently fully compatible with
the ones from MS/Apple/IBM, since you can just install it
and use it.  I'm confused as to why anyone buys it when the
ones that are included standard seem perfectly satisfactory,
but people do.  Anyway, I think that Unix needs what the
other guys have got: just one way to do it.

Do I hope that there will be such a one way anytime soon?
Not a chance :-(  But what would be very good for the
general course of Japanese development for Linux/Unix would
be for all of the parties with a stake in this to form a
group for the purpose of establishing one input standard and
convesion engine standard.  They could each write their own
product, but it would have to conform to the specification,
so that if someone writes an application that uses the Linux
Japanese Input System (as an example name for it), it should
function with any of the input/conversion products that
conform to the standard.  Alternatively, the group could
jointly just write one new input/conversion system to
replace all previous ones and jointly distribute it.

Because of the great fragmentation that exists in Linux, I
don't really expect anything like this to happen soon, and
most likely not ever (the cooperative development model is a
good one, but there is a dark side of the force, and that
fragmentation is it), but it would be a great thing if it
did.  So if your group comes up with a really nice
never-leave-the-spot Japanese input method that talks to
Canna (preferably, since Wnn 6 costs about 9000 yen), it
could be the start of something like that.

This may well be an idea that is nearly impossible, but I do
dream of the day when the rich internationalization
capabilities of Linux will be supported by language input
systems as good (no, better! :-)  ) than the competition.

Cheers,

Jonathan

--------------------------------------------------------------
Next TLUG Meeting: 13 June Sat, Tokyo Station Yaesu gate 12:30
Featuring Stone and Turnbull on .rpm and .deb packages
Next Nomikai: 17 July, 19:30 Tengu TokyoEkiMae 03-3275-3691
After June 13, the next meeting is 8 August at Tokyo Station
--------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links