[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:10327] Draft 2
久保田です。
Draft 2 in Japanese and partially English です。
1. と 2. が大幅に変更されています。
変更のなかった部分から、順次英訳してます。
3. 以降はほとんど手を付けていません。
指摘のあった X Window System のフォントの話なども、
そのままです。
「読みやすい」差分ファイルが作れなかったので、原文のまま
流します。
INTRODUCTION TO I18N
CONTENTS
1. Introduction
2. Coding Systems
2.1. General Discussion
2.1.1. Character / Character Set / Coded Character Set (or Codeset)
2.1.2. Stateless and Stateful
2.1.3. Number of Bytes, Number of Characters, and Number of Columns
2.2. ASCII and ISO 646
2.3. ISO 8859-*
2.4. ISO 2022-*
2.5. ISO/IEC 10646 (UCS-4, UCS-2), UNICODE, UTF-8, UTF-16
2.6. Current Situation in Each Country
2.6.1. Japanese
3. Output to Display
3.1. Console Programs
3.1.1. Invoked in the Console
3.1.2. Invoked in a Terminal Emulator
3.2. X Clients
4. Input from Keyboard
4.1. Console Programs
4.1.1. Invoked in the Console
4.1.2. Invoked in a Terminal Emulator
4.2. X Clients
5. Internal Processing and File I/O
6. Other Special Topics
6.1. Tcl/Tk Programs
6.2. Perl Scripts
6.3. Shell Scripts
7. Examples of I18N
1. Introduction
Debian system includes many softwares. Though many of them
have faculty to process, output, and input text data, a part
of these programs assume text as written in English (ASCII).
For people who use non-English language these programs are
hardly usable.
従来は、英語を使わない人々は、コンピュータとはそのようなもの
であるとして、あきらめてきた。しかし、今はそのような間違った考えを
捨てるべきである。コンピュータを使いたい人はまず英語を学習
しなければならないというのはナンセンスだ。
There are a few approaches for softwares to be able to handle
non-English languages. What we need to do at first is to know
the differences between these approaches and to choose one
approach for each case.
a. L10N (localization)
This approach is to support two languages or character sets,
English (ASCII) and another specified one. An example is
Nemacs (Nihongo Emacs, an ancestor of MULE, MULtilingual Emacs).
プログラマは特定の言語圏に属するので、自分自身の必要を
満たすために書かれた、さまざまなソフトウェアに対する
L10N パッチやさまざまな L10N ソフトウェアが存在する。
b. I18N (internationalization)
This approach is to support many languages but only two
of them, English (ASCII) and another one, at the same time.
One have to specify the 'another' language by LANG environmental
variable or so on. LOCALE and GETTEXT is categolized
into I18N.
c. M17N (multilingualization)
This approach is to support many languages at the same time.
For example, Mule (MULtilingual enhancement of GNU Emacs) and
Emacs 20 can treat a text file which contains multiple languages,
for example, a paper on difference between Korean and Chinese
whose main text is written in Finnish.
L10N より I18N のほうが、I18N より M17N のほうが望ましい。
すなわち、文字データを扱うソフトウェアは、多くの言語を同時に
扱えるほうが優れていると言える。
非英語のサポートに対するアプローチを、別の側面から分類してみよう。
A. それぞれの言語にかんする知識を用いない実装
LOCALE、wchar_t、gettext など、OS やライブラリによって提供される
標準化された手段を用いることにより、それぞれの言語に関する知識を
用いない実装が可能になる。このアプローチの利点は、OS やライブラリが
バージョンアップしたときに自動的に新しい言語のサポートが
付け加わること、実装者の手間が大幅に減少することである。
しかし、欠点は、標準化された手段が存在する範囲のみに限定されて
しまうということである。現在のところ、標準化された手段が
提供されるのは、LOCALE や gettext などの I18N にかんする
分野だけであり、M17N にかんしては、そのような
手段がまったく存在しない。また、文字が占有するカラム数、
コンソール上で非英語文字を入力する方法（変換エンジンとの
インターフェース）についても、標準が存在しない。
B. それぞれの言語にかんする知識を用いた実装
プログラマや各国の contributer の知識に基づき、各言語ごとの
サポートを行うというのが、このアプローチである。L10N は
ほぼ必ずこのアプローチをとることになる。このアプローチの利点は、
標準的な手段が存在する範囲を超えて、きめ細かな実装が可能に
なる点である。言語ごとの特有の問題も完全に解決することが
可能となる。欠点は、サポートする言語の数が、そのプログラムに
かかわっているプログラマや contributer の関心や技術力によって
制限されてしまうことと、それぞれのプログラムごとに実装を
行わなければならないので労力の無駄が生じるということである。
ただし、このアプローチを強力に推進することによって、
Mule のような壮大な M17N ソフトウェアを生み出すこともできる。
A. B. の分類を用いて、プログラマの観点から L10N, I18N, M17N を
見てみよう。
L10N can be realized only using his/her own knowledge on his/her
language. For example, all what you have to do is to implement
your knowledge on SHIFT-JIS coding system. これはたいてい、
プログラマ自身の必要を満たすために行われるので、第3の言語を
サポートできるための拡張性などはしばしば考慮されない。すなわち、
A ではなく B のアプローチが用いられるのが普通である。
Though L10N-ed softwares are basically useful for people who
speaks the same language to the programmer, it is sometimes
useful for other people whose coding system is similar to
the programmer's. For example, a software which
doesn't recognize EUC-JP but doesn't break EUC-JP, does not
break EUC-KR also.
I18N の主要な部分は、C なら LOCALE や wchar_t や gettext のような
標準化された手法を用いることによって可能になる。すなわち、
LOCALE のような手法は、LANG などの環境変数によって動作を変えるように
設計されているので、I18N である。このように、I18N では A の
アプローチが重点を占める。しかし、標準化された手法が
提供されないような分野では、B のアプローチをとらざるを得ない。
その場合でも、インターフェースと個別言語サポート部分とを
適切に設計することで、新たな言語サポートを追加しやすくしておくべきである。
あるいは、そのような分野でも標準化が進められるべきである。
いまのところ、M17N を達成するために利用可能な、標準化された
手法は残念ながら存在しない。例外として、ISO-2022-INT* および
UNICODE という coding system は M17N のための手法となりうるが、
ISO-2022-INT* は stateful な coding system であるために実装が
難しく、一方 UNICODE は、CJK 統一漢字が、中国・日本・韓国の
現存する coding system との連続性を欠いた乱暴な coding system
であるなどの問題がある。いずれにせよ、unversal な coding system が
存在するだけでは M17N は達成できない。したがって、M17N は B の
アプローチをとらざるを得ない。もちろん、さまざまな分野において、
M17N のための標準化された手法を作るための努力がなされるべきである。
Mule は私が知る限り、唯一 M17N を達成したソフトウェアである。
This document is focused on I18N. Note that a software cannot
process a text file which contains more than three languages,
for examile, English, Japanese, and Korean (a paper written in
English, on comparson of Japanese and Korean). M17N is needed
for such a case. M17N が真の目標である。I18N は妥協にすぎない。
この点を忘れないでほしい。
For people using non-Latin letters, I18N does not include
messages written in their languages nor file names written
their languages. Yes, it is true they should be achieved.
However, on considering our current state, we can say these
requires are too much luxury. Our true necesity is,
for example, that characters in our languages are displayed
using correct font without destroying the screen, that
a way for our characters to be inputted is supplied, and
that our languages can be inputted correctly. It would be
fine if text-processing softwares such as perl and grep
processes our languages correctly.
Regarding such circumstance on which we stand, the auther
concentrate on the problems which is truely needed rather
than right and ideal I18N/M17N. In other words, this document
is concentrated on the way how characters should be displayed,
inputed, and processed without destroying them, not on the
time-displaying format, currency symbol, or so on.
2. Coding Systems
ここでは、まず、文字コードについて説明する。
この章の最後では、個別の言語について、
文字コードにまつわる現状について
説明している。この部分は、それぞれの言語圏に属する人からの
contribution を期待したい。
2.1. General Discussion
2.1.1. Character / Character Set / Coded Character Set (or Codeset)
文字コード (character code) は、文字 (character) をコンピュータ内部で
扱うためのビットの組合せのことである。character code を定めるには、
まず encoding の対象となる文字の集合 (set) を定めなければならない。
この文字の集合を、文字集合 (character set) と呼ぶ。世界中にはさまざまな
character set の規格がある。たとえば、JIS X 0208 は日本で用いられている
主要な文字が納められている。character set は、たんに文字を集めた
だけではなく、ひとつひとつの文字にコードが割り振られているのが普通
である。
次に、1 つまたは複数の character set を選択する。たとえば、
ASCII と JIS X 0208。選択した character set(s) に含まれる
それぞれの character に対して、character code を割り当てて行く。
この割り当ての方法を、encoding と呼ぶ。
encoding された文字の集合全体を、coded character set あるいは
codeset と呼ぶ。たとえば、ISO-2022-JP は、ASCII, JIS X 0201,
JIS X 0208, JIS X 0212 の 4 つの character set を含む codeset である。
複数の character set を含む codeset では、encoding は、
各々の character set 内部でと、character set の組合せの
2 段階で行われるのが普通である。
1 つの character set だけを持つ codeset では、character set と
codeset の区別を考える必要はない。たとえば、ASCII は
character set でもあるし、codeset でもある。しかし、character set
と codeset の区別を考えなくてすむ言語を用いているプログラマは、
この区別になじんでいないであろうから、注意すべきである。
2.1.2. Stateless and Stateful
複数の character set を含む codeset は、encoding の際、
それぞれの character set の組合せの方法を決めなければならない。
これには、2 通りの方法がある。ひとつは、すべての character set
中のそれぞれの charcter がユニーク (一意) な character code を
持つようにする方法。もうひとつは、異なる character set に含まれる
character が同一の character code を持つことを許し、シフト状態
(shift state) をエスケープシーケンスで切替えることによって
コードの衝突を防ぐ方法である。
ここで、シフト状態が存在する codeset は stateful であると
形容される。シフト状態が存在しない codeset は stateless である。
2.1.3. Number of Bytes, Number of Characters, and Number of Columns
ASCII 文字は、1 文字は必ず 1 バイトで表現され、
かつ、1 文字はコンソール上や X の固定幅フォントでは
必ず 1 カラムを占有する。I18N では、このような
仮定に基づくべきではない。バイト数、文字数、カラム数の
うちのどれを扱っているのかを意識してプログラミング
しなければならない。
2.2. ASCII and ISO 646-*
ASCII は、character set でもあるし、codeset でもある。
7 ビットであり、0x21 - 0x7e の範囲に表示可能文字が含められている。
これについては説明は不要だろう。
ASCII コードに基づいて決められたのが ISO 646 BCT (Basic Code Table)
である。ASCII コードのうち、0x23, 0x24, 0x40, 0x5b, 0x5c, 0x5d,
0x5e, 0x60, 0x7b, 0x7c, 0x7d, 0x7e の文字は、国ごとに違う文字を
割り当ててもよい。たとえば日本では、0x5c にはバックスラッシュでは
なく円の通貨記号があてはめられている。
私の知る限り、世界中の全ての codeset は、ASCII あるいは ISO 646 を
character set として含んでいる。
0x00 - 0x1f の範囲は制御コードである。
2.3. ISO 8859-*
ASCII, ISO 646 が 7 ビットしか使わなかったのに対し、8 ビットすべてを
使うのが ISO 8859 である。ISO-8859-1, ISO-8859-2, ... と複数の
バリエーションがある。0x21 - 0x7e の範囲は ASCII と同一である。
0x80 - 0x9f の範囲は制御コードであり、実際に文字が割り当てられて
いるのは 0xa0 - 0xff の範囲である。
2.4. ISO 2022
日本語、韓国語、中国語などは、非常に多くの文字を持つので、
ISO 8859 のような単純な方法で文字を扱うことができない。
そこで用いられているのが、ISO 2022 である。ISO 2022 では、
ISO 646-* のような1バイト character set と日本語のような
multibyte character set を含む複数の character set を
切り替えながら扱う codeset である。
ISO 2022 は、非常に複雑な規格であり、ここですべて説明
することはできないが、簡単に説明する。
ISO 2022 は、複数の character set を切替えて使うための仕組みに
ついて定義している。7 ビット版と 8 ビット版がある。まず、
7 ビット版について説明する。
まず、各々の言語の character set には、
0x21 - 0x7e の範囲の 1 バイトのコードまたは、
0x21 - 0x7e の範囲の複数バイトのコードが与えられる。
例えば、ASCII は 1 バイト、JIS X 0208 (日本語) は 2 バイト。
次に、G0, G1, G2, G3 の 4 つの buffer を考える。その 4 つの
buffer に、各々の character set を "designate" (指示する) する。
それには、ESC で始まる 3 または 4 バイトのコードを用いる。
最後に、実際の 7 ビット空間に、G0, G1, G2, G3 のいずれかを
"invoke" (呼び出す) する。それには、1 バイトのコードを用いる。
8 ビット版は、7 ビット版の拡張である。8 ビット空間は 7 ビット
空間の倍の広さがあるので、最上位ビットが 0 である「左」と
1 である「右」とで、別々の buffer (G0, G1, G2, G3) を
"呼び出す" ことができる。
ISO 2022 は非常に複雑なので、そのサブセットがよく用いられる。
たとえば、ISO-2022-JP、ISO-2022-INT-1、EUC (Extended Unix Code)-JP、
Compound Text がその例である。
これらのサブセットでは、character set に制限があったり、designate や
invoke に制限があったりする。
たとえば、Compound Text は X での文字データのやりとりに用いられる
codeset であるが、「左」には G0, 「右」には G1 を
invoke した状態で固定されている。
2.5. ISO/IEC 10646 (UCS-4, UCS-2), UNICODE, UTF-8, UTF-16
2.6. Current Situation in Each Country
それぞれの言語についての各論である。
さまざまな言語圏の人々からの contribution を期待する。
そのとき、
1. コンピュータには関係なく、character の種類と数
2. standarize されている character set の説明
3. 用いられている codeset の種類、仕様、使用頻度、使用目的。
それらの codeset のうち、どんな場面でどれをサポートすべきか。
4. 文字のカラム数 (左→右？右→左？、合成文字？なども含む)
5. LANG 環境変数はふつうどんな文字列に設定されているか？
6. 入力方法はどんなものか？ YES/NO を各言語で入力したいと思うか？
7. 禁則処理はどうか？
8. その他特別に考慮すべき項目はあるか？
を含むようにしてほしい。また、文字の合成が可能な codeset や、
左から右へ以外の表記法を持つ言語圏の著者は、
それについて、どのように解決しているのかの説明もしてほしい。
2.6.1. Japanese
2.6.1.1. Characters used in Japan
日本語で使われている文字には、ひらがな、かたかな、漢字の3種類がある。
ひらがなとかたかなは表音文字で、alphabet の upper case と lower case
のように一対一の対応がある。漢字は表意文字で、いくつあるかは
誰も知らない。日本人の大人は通常 several thousands の漢字を知っている。
よく知られているように、漢字は中国起源であるが、長い歴史の中で、
中国のものとは字形や意味が若干変化している。
2.6.1.2. Character Sets
JIS (Japan Industrial Standards) is an organization responsible
for character sets and codesets used in Japan.
The major character sets in Japan are:
JIS X 0201 (about 60 characters including KATAKANA),
JIS X 0208 (about 7000 characters including HIRAGANA, KATAKANA, and KANJI),
and
JIS X 0212 (about 6000 characters including KANJI).
JIS X 0201 は 8 ビットコンピュータ時代の産物であり、
JIS X 0208 includes all characters of JIS X 0201 であるので、
obsolate である。
JIS X 0212 はほとんど使われていない。したがって、JIS X 0208 のみを
サポートすれば、たいがいの用は足りる。
なお、JIS X 0208 には HIRAGANA, KATAKANA and KANJI だけではなく、
non-literal symbols, English alphabets, Greek characters,
and Russian characters も含んでいる。しかし、それを意識した
プログラミングをする必要はまずないはずである。
JIS X 0208 は、ISO-2022 の枠組に従うように、0x21 - 0x7e の範囲の
バイト 2 つによってできている。
JIS X 0212 も、JIS X 0208 と同様、0x21 - 0x7e の範囲のバイト 2 つ
によってできている。
2.6.1.3. Codesets
3つの popular codesets がある。まず、それぞれの特徴について述べる。
* ISO-2022-JP (aka JIS code)
- stateful
- subset of ISO-2022
- 7bit
- ASCII, JIS X 0201, JIS X 0208, JIS X 0212 can be used.
- used for e-mail and net-news and preferred for HTML.
* EUC-JP (Extended UNIX Code)
- stateless
- subset of ISO-2022
- 8bit
- ASCII, JIS X 0201, JIS X 0208, JIS X 0212 can be used.
- preferred code for UNIX. For example, almost all Japanese
message catalogs for gettext is written in EUC-JP.
- Japanese code is mapped in 0xa0 - 0xff. This is important
for programmer because one doesn't need to care there are
fake '\' or '/' (which can be treated in a special way in
many context) in the Japanese code.
* SHIFT-JIS (aka Microsoft Kanji Code)
- stateless
- NOT subset of ISO-2022
- 8bit
- ASCII, JIS X 0201, and JIS X 0208 can be expressed, but
JIS X 0212 cannot.
- Windows/Macintosh supports this code only. This makes
SHIFT-JIS the most popular code in Japan. Though MS
is thinking about transition to UNICODE, it is suspicious
that it can be done successfully.
*** ここに各 codeset の具体的な encoding を書く ***
UNICODE is not popular in Japan at all.
2.6.1.4. How These Codesets Are Used --- Information for Programmers
以下の例外を除き、EUC-JP をサポートすべきである。もちろんこれは、
EUC-JP の知識を直接に使ってコーディングせよという意味ではない。
wchar_t などを使うことによって特定コードに関する知識を使わずに
コーディングできるのなら、そのほうが望ましい。また、以下の例外に
含まれない場合でも、EUC-JP 以外の日本語コード (ISO-2022-JP、
SHIFT-JIS) をもサポートしたほうがいいのは言うまでもない。
・メール・ネットニュースを扱うプログラムは ISO-2022-JP を
扱わなければならない。
・ICQ クライアントの事実上の標準は SHIFT-JIS である。
・WWW ブラウザのレンダリングエンジンは、すべてのコードに
対応できるべきである。（I18N では全く不充分で、M17N を
目指すべきである）。
・Windows/Macintosh とデータのやりとりを行うプログラムは、
SHIFT-JIS を使うべきである。
・BBS では SHIFT-JIS が広く使われている。
・Windows で使われている、Joliet 形式の CD-ROM は、
ファイル名が UNICODE で書かれている。
2.6.1.5. Columns
日本語表示可能なコンソール (kon, kterm, krxvt) では JIS X 0201 は
1 カラム、JIS X 0208 と JIS X 0212 は 2 カラムを占有する。
2.6.1.6. LANG variable
EUC-JP
LANG=ja_JP.ujis (major for Linux)
LANG=ja_JP.eucJP (major for *BSD)
LANG=ja_JP
LANG=ja
ISO-2022-jp
LANG=ja_JP.jis
SHIFT-JIS
LANG=js_JP.sjis
2.6.1.7. Input from Keyboard
日本語の文字はキーボードから直接入力できないので、
English Alphabet の入力を日本語に変換するためのソフトウェアが
必要である。フリーなものでは Wnn と Canna がある。
これらはサーバー/クライアントモデルを採用していて、
独自のプロトコルを実装している。X Window System 上では、
これらの独自のプロトコルと XIM (X Input Method) とを
仲介する kinput2 というソフトウェアが使われる。
表音文字であるひらがなのうち、大部分は１文字で母音＋子音を表すので、
English Alphabet 2 文字を入力することでひらがな 1 文字を入力する。
一部のひらがなについては、Alphabet 1 文字や 3 文字が
ひらがな 1 文字に対応する。
漢字は、ひらがなをさらに変換することで得る。日本語の単語には
漢字が複数並んだものがたくさんあるが、単語は一度に変換できるのが
通常である。優れた辞書や文法解析能力を持つ変換ソフトウェアを使うと、
もっと長いフレーズや文全体を一度に変換できる。ただし、日本語の単語には
同じ音を持つが違う漢字を用いる (意味も違う) ものが多数あるので、
複数の候補の中から選ぶことが、しばしば必要になる。
2.6.1.8. Layout of Characters
ここでは、ブラウザのレンダリングエンジンのようなソフトウェアを
作る際に有用な情報を記す。
日本語では、英語とは異なり、単語を空白で区切るようなことはしない。
また、行を折り返すとき、単語の途中で行を折り返しても構わない。
ただし、記号に付いては若干の注意が必要である。英語では
open parentheses は行の最後には決して現れないし、close parentheses
は行の先頭には決して現れない。日本語にも parentheses に相当する
記号があり、英語の場合と同じ規則が適用される。また、
英語では、comma や period は行の先頭には決して現れない。
日本語にも comma や period に相当する記号があり、
英語の場合と同じく、行の先頭には決して現れない。
英語の場合、単語と単語の間でしか行の折り返しができないので、
parentheses, comma, and period にかんする規則は自動的に守られるが、
日本語の場合は、特別に考慮しなければならない。
2.6.1.9. More Detailed Discussion
・ルビ
・縦書き
3. Output to Display
Here 'Output to Display' does not mean I18N of messages using gettext.
I will concern on whether characters are correctly outputted so that
we can read it. For example, install libcanna1g package and display
/usr/doc/libcanna1g/README.jp.gz on console or xterm (of course after
ungzipping). This text file is written in Japanese but even Japanese
people can not read such a row of strange characters. Which you would
prefer if you were a Japanese, an English message which can be read
with a dictionary or such a row of strange characters which is
a result of gettext-ization? (Yes, there IS a way to display Japanese
characters correctly -- kon for console and kterm for X, and Japanese
people are happy with gettext-ized Japanese messages.)
Problems on displaying non-English characters are discussed below.
Since the mother tongue of the author is Japanese, the content may
be biased to Japanese.
3.1. Softwares Running on the Console
Softwares running on the console are not responsible for displaying.
The console itself is responsible. There are terminal emulators
which can display non-English languages such as kterm (Japanes),
krxvt, grxvt, and crxvt (Japanese, Greek, and Chinese, included
in rxvt-ml package), cxterm (Chinese), and so on and softwares
with which non-English characters can be displayed on console
such as kon (Japanese) and
コンソール上で動くプログラムは、「表示」は自分自身の責任ではなく、
コンソールの責任である。そして、X Window System 上では各国語が
表示できる kterm、krxvt、cterm、hanterm などのターミナルエミュレータ
が存在するし、コンソール画面上でも、kon2 というプログラムがある。
だから、表示に関して言えば、quick hack として、8ビットクリーン化
だけでいい場合もある。ただし、(私が手を加える以前の
minicom のように) 1文字表示するたびに位置指定コードを送るプログラム
は、2バイト文字を分断させてしまうので、直さなければならない。
フォントの「幅」についてはいかなる standard も存在しない。
これが、ncurses などを使って画面のレイアウトを行うプログラムでは
問題になる。これには正しい解決法は存在しない。日本語の場合、韓国語の
場合、というように個別に対応する必要がある。私は Mule (MULtilingual
Emacs, GNU Emacs20 は Mule を取り込んでいる) がどんな実装をしているか
興味があるが、残念ながらソースを読む時間も能力もない。なお、
日本語フォントは、必ず 2 columns を占有する (JIS X 0201 は
1 column しか占有しないが、これは obsolate である)。
韓国語と中国語も ASCII の倍の幅がある。したがって、EUC を使う場合、
2 バイト文字は 1 バイト文字の倍の幅があるので、2 バイト文字のために
特別な処理をしなくても「偶然にも」レイアウトを崩さずに表示できる。
ただしそのときでさえ、1文字を表す2バイトを分断させないように、
注意を払わなければならない。
たとえば、行の折り返しによって文字が分断される可能性がある。
文字がある場所に別の文字を上書きするとき、もとの文字の半分が残ってしまうと
画面が崩れる原因になる。このとき、「カラム数が偶数なら大丈夫」とか
「上書きするときにカラム位置が偶数なら大丈夫」というのは誤りである。
なぜなら、2カラムを占有する文字と1カラムを占有する文字とが
混在しているからである。
3.2. X Window System
X は国際化されているので、フォントさえ用意してやれば、日本語や
その他の言語を表示することができる。そして、フォントを用意するのは
ユーザーの責任であり、プログラムの責任ではない。プログラムの側で
必要なことは、
* LOCALE を使うことを宣言すること。setlocale()
* X の国際化機能を有効にすること?
* フォントの指定に注意すること (たとえば、-adobe-* に合致する
日本語フォントは存在しない)。
* i18n された Widget を使うこと。たとえば、Athena Widget や GTK++ は
i18n されている。
私は X Window System 上のプログラミングの経験は (Tcl/Tk script 以外には)
まったくないので、どなたか詳しい説明に置き換えて欲しい。
4. Input from Keyboard
キーボード入力の I18N は、画面出力の I18N を前提とする。
Yes/No を入力すればいいだけのような場合、I18N は必要ではない。
入力のために変換を必要とする日本語で Y/N を答えるのは煩わしい
ことであると、ほとんどの日本人は考えている。韓国人や中国人も
同様であろう。
4.1. コンソールプログラム
4.1.1. Invoked in the Console
「入力」に関しては、Canna, Wnn などの個々の変換エンジンに直接
接続するしか方法はない。これに関しては、I18N の基板となる
standard は存在しないので、言語別に個別に対応しなければならない。
いくつかのプログラムは直接 Canna などの変換エンジンと接続できる
ように作られている。nvi-m17n-canna など。これに関しても、GNU
Emacs 20 はコンソール上でさまざまな言語を入力できる機能を
持っていて、興味が持てる。もし GNU Emacs 20 の入力部分が
ライブラリとして利用可能なら、それはすばらしいことだと思う。
4.1.2. Invoked in X Terminal Emulator
X Window System には XIM という標準があり、一方、Canna や Wnn などの
個々の変換エンジンと XIM との仲介を行う kinput2 という
プログラムがあるので、ターミナルエミュレータの中で使うのであれば、
quick hack として8ビットクリーン化だけでいい。この意味でなら、
bash (libreadlineg2) (2.02.1-1.6) や tcsh (6.08.01-3) でさえ
2バイト文字の入力を受け付ける。
ただし、この段階では、2バイト文字を意識していないので、2バイト
文字をまたいでカーソル移動したり、2バイト文字を消去したりするときは、
ユーザーは2回操作しなければならない。これを間違えると、入力した文字列が
壊れてしまい、復旧できなくなる。
4.2. X Clinents
必要なことは、
* XIM からの入力を受け付けること。On-the-Spot (その場変換) を
受け付けるのが望ましいが必須ではない。
* Compound Text を含むペーストを受け付けること。
である。
5. Internal Processing and File I/O
ユーザーの立場からみれば、入出力さえ正しくできるなら、
内部ではどのような処理が行われようとも構わない。