Re: [tlug] Japanese Input on CentOS / KDE

["Stephen J. Turnbull" <stephen@example.com>]

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

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

  o In discussing various terminal emulators, you mention that you
    prefer aterm and rxvt over and over again.  This is redundant and
    distracting.

  o Ditto for comparing distros when discussing installation
    instructions for a particular distro.

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.

When there's a class of app that you have strong preferences for (eg,
terminal emulators), recurse and do a similar structure (HOWTO
favorites, consumer reports comparison, HOWTO others for each app
category) in your favorite distros.  When you get to the distros
you're less familiar with, omit the implementation comparison section.

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.

HTH.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.