🚀 go-pugleaf

If you have been following the discussion on the INSOFT-L
Internationalization of Software mailing list about Ken Lunde's upcoming
book _Understanding Japanese Information Processing_, then you will
understand the context of the message from Chiaki Ishikawa that follows.

If not, please see the "INSOFT-L List Manager's Notes" that I will
distribute today, which provides new information about Ken's book, and
see INSOFT-L's archives for the previous messages in this discussion.


Jeff
INSOFT-L List Manager

*========================================================================*
 Jeff Bowyer                         EMail:
 Computing Center		     jbowyer@cis.vutbr.cz
 Technical University of Brno
 Udolni 19, 602 00 BRNO
 Czech Republic
*========================================================================*

Forwarded message:
> From pmcgw!personal-media.co.jp!ishikawa@uunet.UU.NET Fri Jul  2 16:29:56 1993
> Date: Fri, 2 Jul 93 21:50:24 JST
> From: pmcgw!personal-media.co.jp!ishikawa@uunet.UU.NET (Chiaki Ishikawa)
> Message-Id: <9307021250.AA16327@sun00.personal-media.co.jp>
> To: lunde@mv.us.adobe.com
> Cc: uunet.!cis.vutbr.cz!jbowyer@pmcgw.personal-media.co.jp
> In-Reply-To: <9306251306.AA16990@lithos.mv.us.adobe.com> "pmcgw!uunet!mv.us.adobe.com!lunde"
> Subject: re: comments...
> Reply-To: pmcgw!personal-media.co.jp!ishikawa@uunet.UU.NET (or ishikawa%pmcgw@uunet.uu.net outside Japan)
>
> PMC e-mail id: 1117
>
> Dear Ken,
>
> Thank you for taking time to read my comments. I didn't know exactly
> what JAPAN.INF is when I wrote the original comment, but now I know that
> you are working on a book. Good luck! I know how it is difficult to
> produce a thick, and yet easy to read, information-packed tomb.
>
> Here is just a short comment to clarify my original comment.
>
> >	I include Asian character sets and encodings in Chapters 3 & 4
> >for the sake of comparison. It lets the readers know that Japan is not
> >alone in how it encodes its characters, and that other Asian countries
> >have a similar number of characters for use on computers.
>
> I understand. I believe the readers will find the comparsion useful
> for gaining perspective on Asian characters.
>
> >	Th Sun keyboard must be a QWERTY keyboard. I am not interested
> >in keys outside the standard Roman characters, such as function keys.
>
> 	Yes. Sun keyboard *IS* a QWERTY keyboard. Well, sort of.
> The *Japanese* Sun keyboard has a set of keys indispensable for
> Japanese input using kana/kanji henkan (transform in Japanese) on top
> of ordinary keys we find on US keyboard.  (Because of these changes to
> the keyboard, MIT X11 distribution usually doesn't compile and run on
> Japanese's Sun workstations. We always need a patch to keyboard
> handling routine, which is a pain when you forget to apply it.)
> I agree that function keys such as F1, F2, ..., L1, L2, ... are not
> interesting for the book. However, won't the special keys for Japanese
> input be of interest to your readers? Again, I am not sure if the page
> limit allows such detailed treatment.
>
> Even if we omit the discussion of these special keys,
> I would think if you can just include the high-quality pictures of
> this and other keyboards so that the readers can read the variety of
> layouts and the way special keys are arranged on these different
> keyboards, the readers will find it easy to understand the `confusion'
> faced by the Japanese users and developers alike.
> At least, they will be amusing to look at.
>
> (My personal experience is that I always find it amusing and
> refreshing to see other country keyboard and find unfamiliar symbols
> here and there. Although just looking at them certainly is not useful
> for immediate programming purposes, but at leat it motivates me enough
> to keep studying and paying attention to i18n issues. Am I keyboard
> fetish? :-))
>
> >	The TRON keyboard, as far as I recall, is actually NEC's M-style
> >keyboard array (this *is* covered in great detail).
>
> To a cusory observer, physically NEC M-style keyboard and TRON
> keyboard may look alike.  However, its logical keyboard layout is very
> much different. Again, if a large photo of such keyboard is
> incorporated so that the readers can see where each key is assigned,
> that may be of interest to your readers even without description.
>
> [I hate to plug TRON keyboard since a version of a TRON keyboard is
> marketed by a division of the company I work for. If you need more
> info, IEEE MICRO had a feature article on the TRON project a few years
> ago, and you can find a good article of it in there.]
>
> >	Tcode is covered in Input by Association. Tcode is actually input
> >by *unassociation*, and is mentioned as such in that section.
>
> I see. It just happend that I didn't see Tcode input method mentioned
> whereas Tcode-based input software was mentioned.
>
> I knew Prof. Yamada, the original inventor of T-code, personally when
> I was a college student.  The data in the technical reports Prof.
> Yamada published was so favorable that I have been meaning to learn
> T-code once a new version of EMACS editor has Japanese and T-code
> support for a long time now. Current kana/kanji-transform method is so
> *slow* for my taste.  Retraining for T-code input even at the age of
> thrity-something seems worthy to me. Well, the problem is that T-code
> is NOT popular, and I will have a tough time if I want to use somebody
> else's computer system once I switch to use T-code.  (This is probably
> akin to the problem faced by a DVORAK keyboard user faces when he/she
> tries to use somebody else's computer.)
>
> >	Creating your own fonts can also mean making a limited set of
> >external characters (yes, I mean gaiji) that can be added to a font.
> >Adobe Type Composer, which is just being release, and is described in
> >Chapter 6, lets you do this to a PS font.
>
> I believe this Chapter 6 will be a very useful information to developers
> who would like to incorporate such character font in their application
> that uses Adobe PS. I hope such chapters clarifies any remaining
> questions a developer can have about Japanese PS font.
>
> >	Chapter 8 is not designed to provide a complete listing of
> >available software -- I just give a few descriptions to let readers
> >know what sort of software is out there, and what features to expect.
> >Sun's JLE is mentioned in that section, but not described.
>
> I agree that covering all the Japanese software is impossible.
> Mentioning Sun's JLE, and possibly list Nihon Sun's contact address
> may be enough. (I admit that I am biased in favor of Sun since I have
> been using Sun workstation for 5-7 years. However, I have used HP and
> DEC workstation and its Japanese software at our office, and used Sony
> and IBM workstation when such machines were rented for porting
> purposes, I believe that I am not so ignorant of what other vendors
> do. BTW, isn't it a pity that nobody from Japan except me had a
> comment on your table of contents yet on the ISOFT-L mailijg list?
> Other Japanese subscribers can remedy my bias if any. I wonder how
> many Japanese subscribe to INSOFT-L.)
>
> >	Also, the section on OSs in Chapter 8 is designed more to show
> >how to *Japanize* non-Japanese hardware. I mention Japanese PCs in
>
>                                 ^^^^^^^^ (Is this actually software???)
>
> >that section, but describe that they are already Japanized in hardware
> >(and software).
>
> I see. Windows API can hide the underlying hardware differences very
> much (maybe not completely), so as long as the readers are made aware
> that the underlying systems are quite different, I think it is OK.
>
> >	I also mention that machine translation software today is more
> >like machine-aided -- there is always pre- and post-editing required.
> 	
> 	I agree with this definately. When you deal with machine
> translation system today, pre- and post-editing is necessary.
> This is an accepted wisdom among translation practioners, I think.
>
> The name of the game is that we have to pre- and post-edit the draft
> and translation even if we deal with professional *human* translators
> actually. No human being can be completely versed in the target field
> (e.g., computers, hardware, software) and both languages, and thus we
> need to check the result of translation ourselves even it is done by a
> human.  The good thing about machine translation system (and don't
> laugh about this!) is that you can correct the lousy translation done
> by a machine system to your heart content, but when you begin to
> correct a translation done by a human translator, you have so much
> psychological blocks to do so and it takes time and consumes you much.
>
> Eg.
>
> "Wait a second, if a competetant translator translates the sentence
> this way, it must be correct. However, I, as a professional in the
> field, think the translation doesn't sound quite right.  Maybe I
> should re-phrase the translation, or the translator misunderstood the
> subtle nuance in the original draft. Let me check... Well, this looks
> right, but won't my changing this way bruise the ego of the
> translator?  Hmm..."
>
> 	v.s.
>
> "Aha, dummy machine translation system botched again. Let me
> correct this way to make it sound right. Done. Let's move on to the
> next page."
>
> This was observed by someone at Japane NCR office who has done a large
> amount of translation of computer manuals. His office is a Sharp duet
> user now. After hearing him describe the mental block he feels, I
> suddely realized this is indeed the case with me, too.
> It certainly is easier to correct lousy machine translation. When I am
> correcting human translation, I spend too much time to try to salvage
> and use as much old translation as possible. This is actually
> counter-productive.
>
> >The systems that I mention are priced reasonably. There are other
> >systems that run on platforms such as UNIX, but they are incredibly
> >expensive.
>
> Again, I have to agree with this. Sharp DUET system was very highly
> priced when we bought it. (However, their new version running on UNIX
> laptop computer is just half as expensive as the original DUET system
> that runs on Sharp's MC68K-based UNIX box.) The price of these
> EWS-based system *is* coming down although they are still very high
> compared with the systems mentioned in the table.
>
> (Regarding Sharp DUET, we feel that the price was mainly for the user
> support fee.  I personally send about 40 full pages of minor problems
> (with listings attached) o Sharp via FAX and got almost similar or
> more pages of answers in a couple of months when we started to use the
> system. Again, it is not my intention to push one particular system
> over others. Just take note that an inexpensive system CAN be used to
> translate computer manuals or can aid translators in translating them
> with a much greater speed.)
>
> Anyway, the translation systems varies in price very much.
> And its capability varies much, too. High-price doesn't mean high
> quality translation automatically, and low-price doesn't mean
> low-quality either.
>
> Please advise your readers to ask for a refrence and check the system
> with a native Japanese user or two and be sure to perform a
> demonstration translation with your favorite document before purchase.
> I was personally bewildered with the shoddy translation quality of
> some brand-name comapanies systems when I shopped for a translation
> system about 3 years ago. How can you expect that a company
> is making serious efforts when their demo uses gramatically incorrect
> English draft to begin with? (I won't name names names here :-))
>
> [DISCLAIMER: I am in NO WAY related to Sharp DUET marketing division.
> I am just a user of it, and SHARP DUET does have some software bugs,
> etc. as any system does.]
>
> Anyway, again good luck with your project.  The world needs such a
> book on Japanese handling now.  I will wait for your book, and
> recommend it people who I meet on business when they show interest in
> i18n. I had a short writeup of my own about Japanese handling, but now
> I can safely delete the writeup from my disk system once your book
> hits the market.
>
> Best Regards,
>
> [To: Jeff, please feel free to post this to INSOFT-L. I was away from
> my office on a private trip for a week, and have tough time to keep up
> with many e-mails right now. Actually I am busy preparing an
> overflowed mailbox file :-(
>
> I noticed that you kindly reposted Ken's mail to the mailing list with
> my original comment. Could you repost this mail of mine, too?]
>
>
> ------------------------------------------------------------------
>     Chiaki Ishikawa                       Phone:+81-3-5702-0351
>   Personal Media Corp.                      FAX:+81-3-5702-0359
>  MY Bldg, 1-7-7 Hiratsuka,   UUNET: ... uunet!pmcgw!ishikawa, or
>  Shinagawa-ku, Tokyo 142                ishikawa%pmcgw@uunet.uu.net, or
>         JAPAN               (in Japan)  ishikawa@personal-media.co.jp
> ------------------------------------------------------------------
>