Mailing List Archive


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

Re: [tlug] Japanese Input on CentOS / KDE



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, Aug 10, 2005 at 01:23:47PM +0900, Stephen J. Turnbull wrote:
> >>>>> "Scott" == Scott Robbins <scottro@example.com> writes:
> 
>     Scott> Also, I'd like to know what parts you find confusing.
>     Scott> Obviously, it's a bug in my documentation, since one of the
>     Scott> main purposes of the page is to allow the newcomer to
>     Scott> easily use Japanese.
> 
> I found it rather breathless.
> 
> It is clearly out of date in two ways.
> 
>   o Most modern Linux distros are moving to IIIMF-based input
>     methods.  I don't think you need to discuss them, but you should
>     point out that what you're describing is not the politically
>     correct way to do things, at least on recent Linux.
> 
>   o Most modern Linux distros default to .UTF8 locales.  They do work,
>     mostly, nowadays.  However, it's not obvious to me that they'll
>     work with the setup you describe (specifically, I don't think any
>     of Canna, FreeWnn, or kinput2 knows about UTF-8).  I think that's
>     all you really need to update about that.


Canna does, at least in FreeBSD.

Yes, it does need a complete rewrite, incorporating most, if not all, of
your suggestions.  It was originally written when I knew far less, and
only used RH and then Gentoo.  As I added to it over the years, it
became, as you say, breathless, and the asides that were more excusable
in a shorter article have to be eliminated.   


> 
> Here's a minor point about luit.
> 
>   o luit is trivial, you just run it at the prompt in a terminal emulator.
>     uxterm is a shell script that uses the -u8 flag to xterm to put it
>     into UTF-8 mode.  So if you want an xterm that displays EUC, you
>     do "uxterm -e luit -encoding EUC-JP".
> 
>     I believe that modern xterms are supposed to run luit
>     automagically, giving it the encoding part of the current locale
>     (I'm not sure which LC_ variable is relevant).

I just checked this--with UTF-8 just for fun.  Exporting XMODIFIERS, it
worked as you described.  That will be something to possibly add at the
end, though, for the reasons you give below.


> 
> I suspect that for newbies you shouldn't mention luit at all.  It's
> clearly intended for expert use in special circumstances, not as a
> general solution.
> 

> When I wrote "breathless" above, I meant that the general organization
> is somewhat scattered.  It's not a very good way to write a HOWTO.
> 

See above--it's like a building where they add various things as
afterthoughts.  

I'm snipping most of your points, but all are, of course, good ones, and
will almost all be followed.

> 
> 
> What I would suggest is to rewrite it by first describing the
> procedures for the distros you know best (in this context).  I would
> guess that's RH 7, ArchLinux, and FreeBSD.  Next, a short section
> explaining that you've tried it on a bunch of others, and here are the
> variations for those distros you know less well.  This is the place to
> acknowledge that they're not your favorites, and that they may have
> changed since you tried them.  Finally, the procedures for those
> distros.
> 
This sounds good, though I think I will keep the Linux ones and BSDs in
their own sections.



> 
> If you're not interested in making that much effort, simply removing
> all cross-references to other implementations (either for a given
> class of app or among distros) after the first time would go a long
> way to improving clarity, I bet.


I'll have to play with this idea.  It's not going to be an overnight
thing (It's actually three AM here and one of the cats tried to fool me
into thinking it's time for his breakfast) but yes, the page needs a
complete rewrite.  UTF-8 works far better than it used to work, but I
still have difficulty getting scim-anthy to work with as wide a range of
applications as I do with kinput2.  

It definitely deserves mention though, as you point out, that it is
becoming the method of choice.  I played with Berry Linux recently, and
saw how it works, when properly implemented (Arch doesn't, AFAICT, have
it properly implemented yet, though Damir has been looking at Berry to
see how they do it).  SCIM also works with canna--FreeBSD has a
scim-canna port.  
> 
> HTH.


Yes, it does, though you're pointing it out means work.  :)

Sigh, yes, looking at it, it REALLY needs to be rewritten from the
ground up.  


- -- 

Scott Robbins

PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

Xander: Calm may work for Locutus of the Borg here, but I'm
 freaked out, and I intend to stay that way. 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

iD8DBQFC+ac/+lTVdes0Z9YRAhq7AKC1e73bxeQvIuMrLfY4NE/xACnzfQCgl7FW
nPt+VN+++2G6eO9klH5ntG0=
=o+WM
-----END PGP SIGNATURE-----


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links