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

[Gaspar Sinai <gsinai@example.com>]

Hi,
irst of all I would like to thank Craig - his contribution to this
thread was very constructive by offering up some server space for
development.

There was a heated discussion about input methods on

         netscape.public.mozilla.i18n

and a status report was made (if my database works alright) with

Messsage ID 35521F02.48069182@example.com
Subject: Last week status report about Mozilla Language Enabling project.

I think some general guidelines about i18n can be found in

        http://www.mozilla.org/docs/refList/i18n/scripts.html

It may contain something bout input methods as well.

But let me reveal my own ideas.

On Tue, 9 Jun 1998, Stephen J. Turnbull wrote:

[...]

> Manuel Chakravarti got it right in his discussion of the
> "ease-of-networking" issue.  MS makes the easy things slick.  However, 
> in the MS world, you can't scale a network (Manny's point) and you
> can't communicate with people whose systems don't work in your locale
> _except by ignoring the MIME information_.  And that's exactly what MS 
> programs do.

OK. I got into the right mailing list :) 

> And Manny and I are being perverse about it, not because we don't want
> it too, but because we're afraid (well, I am, and I think Manny is
> too) that what will happen is that people will rush in with a fix.
> For text input, it will quite possibly be tuned to Japanese, and make
> most people happy, but fail to be truly multilingual (if it is
> multilingual) or be monolingual in Unicode.
> 
> There is such a thing as UCS-4, of course, but as far as I know it is
> 100% empty except for the BMP and private space and the reserved
> non-characters at FFFF and FFFE in every plane.  This means that the
> system you are putting in place now must be completely flexible with
> respect to the standards that will undoubtedly evolve for the use of
> UCS-4.

I think UTF8 is a perfect choice, because it can encode UCS4. But I also
feel that MS-biased Unicode Consortium will never put any practical
meaning into UCS4 as MS-NT only supports UCS2 and it would be a lot of
work for them. 


>     Matt> This seems so right to me on so many levels; from an
>     Matt> aesthetic point of view. From a code-reuse point of view; if
>     Matt> one thing must do it, it should be a program. If everything
>     Matt> should do it, it should be abstracted to a library. Even, in
>     Matt> a certain way, from a viral point of view - anything that
>     Matt> helps to spread The Source must be good, and making things
>     Matt> work better around the world definitely falls in this
>     Matt> category in my book.
> 
> Sure.  Dreams are nice.
> 
> Only question is, can it work in practice?  I can and do dream
> dreams.  However, I respect that fact that some people who are smarter 
> than I in combination with some people with much more experience than
> I and some people with both, with the help (and admittedly, sometimes
> the obstruction) of hundreds of others have brought us to the current
> sorry state of affairs.
> 
> Microsoft applications work because they don't care if it
> interoperates.  The seriously multilingual people I know (ie, people
> who use multiple non-ISO8859 locales) are not happy with Windows at
> all; changing from one locale to another requires rebooting.  They're
> not much happier with the Mac.  They're all lyrical poet-types, so
> they're even less happy with Un*x.

I don't think simple things like character input need a genious.
Moreover, when people are too capable they use up their energy by
over-complicating things. 

Just take X11 for example. It does not say how  to make graphical
intefaces and it  tries to be very general. Result: no drag and drop 
support, different look-and feel, and simple things are impossible to
accomplish - for one: try to make a cursor with more than two
colors in X11 -- impossible.  

People try to defend input methods in X11. But here comes multi-language
input. It turns out that you have to throw away all the library routines
in X11 that are supposed to help you, to make it work with X11. Sometimes
I think that GGI and Berlin is the only way to go. But still X11 is usable
we just need to tweak it at the right place.

o We need an input conversion server, with a standardized communication
method that does not need X11 running.

o X11 input methods like kinput2 could be modified to handle this
protocol. Old apps won't notice a thing.

o Languages to be added dynamically to the input conversion server.

Drawbacks:
You need to display the converted caracters - but wait a minute - all
apps CAN display this.

When I ported Canna and kinput2 to alpha (64 bit)I worked day and night
for more than a week. I dont feel much attached to the "heritage" here.
Old codes are not even 64 bit clean - easier to rewrite than port. 

I think what is really needed is an open environment and open standard,
that is decided by us.

> The answer is 42.  I don't know what it means, though ;-)
> 
>     >> Why don't you join the campaign to world domination of Japanese
>     >> input instead? :-) That way you could do loads to make sure it
>     >> worked exactly the way you wanted it to while you dominated the
>     >> world :-)
> 
> I have.  But my preferred OS for this development is not Linux; it's
> Emacs.  XEmacs at the moment, as you know.

[...]

Emacs is very powerful. But it is too complicated for the occasional user.
I would like to make Linux available for all users - non-professional
users are in still in majority....

Cheers,
gaspar

--------------------------------------------------------------
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