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

[debian-devel:10311] Re: Draft 1 (Re: I18N Document)

From: Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx>
Subject: [debian-devel:10295] Draft 1 (Re: I18N Document)
> Draft 1 in Japanese です。
> こんなの出すのめちゃくちゃ恥ずかしいんですが。

いえいえ、楽しみに待っておりました :)

> L10N (localization)
> 	英語以外の特定の言語のサポートだけを追加すること。
> 	たとえば、Nemacs (Nihongo Emacs) は英語と日本語を扱える。

私はこの定義だけで良いのかどうか知らないのですが、
日本向けのワープロソフトの l10n としては、例えば
「ルビを正しく扱えること」なども含まれるのではない
のでしょうか?

> I18N (internationalization)
> 	多くの言語を扱えるようにすること。ただし、LANG 環境変数
> 	などによって、起動時に言語を指定しなければならない。
> 	同時に扱えるのは英語ともう一つである。LOCALE や gettext
> 	に基づくプログラムは、このアプローチである。

「LANG 環境変数」は POSIX で規定されているものですので、
その辺りの規格まで突込んで紹介できると良いですね。

> M17N (multilingualization)
> 	多くの言語を同時に扱えるようにすること。いまのところ、
> 	じゅうぶんにこれを達成しているのは Mule (MULtilingual
> 	enhancement of GNU Emacs) くらいのものである。

これは、application におけるコード系の扱いのことを
さしているのでしょうか?
意味する部分が少し曖昧な気がします。

> I18N は、C だと locale や wchar_t などの枠組を用いることで
> 達成することができる。特定のコーディングシステムについての
> 知識を使うべきではないが、locale などのような枠組が存在しない
> 分野では使わざるを得ない (たとえばコンソールでの文字入力)。

何を達成できるかが不透明な気がします。
また POSIX locale を完全サポートしたことが
すなわち i18n であるといえるのかが、難しいところですね。

> ここでは、I18N を中心に述べることにする。しかし、
> I18N では、たとえば日本語と韓国語を両方含むようなテキストを
> 扱うことができないことに注意せよ。この場合には M17N が必要で
> あるが、それはこの文書の範囲を超えている。

例えば、日本語 JIS コードでは、日本語文字・アルファベット・
ギリシア文字・キリル文字が表現できますよね。

i18n とグリフと言語とコード系は、イコールで
結ばれるものではないと思いますが、いかがでしょうか。
また、それぞれの関係が記述されるとより一層
詳しく説明できそうですね。

> 2.6.1.3. Conclusion and Information for Programmers
> 
> 通常は、EUC-JP のみをサポートすればいい。あるいは、EUC-JP のサブセット
> (ASCII and JIS X 0208) のみをサポートすればいい。この場合、
> 0x21 - 0x7e は ASCII と同じで、0xa0 - 0xff のバイトは JIS X 0208 
> 日本文字で必ず 2 バイトで 1 文字である。日本語表示可能なコンソール
> (kon, kterm, krxvt) では日本文字は 2 カラムを占有する。

メールなどでは、ISO-2022 をサポートすべきですね。
対応するアプリケーションによって EUC-JP のみサポート
すればいいのか、そうでないのかは違うので、
「EUC-JP のみサポートがいいかは場合による」と思います。

> 「入力」に関しては、Canna, Wnn などの個々の変換エンジンに直接
> 接続するしか方法はない。これに関しては、I18N の基板となる
> standard は存在しないので、言語別に個別に対応しなければならない。

変換エンジンを必要とするのは、多くは
「仮名混じり漢字」表記を行う日本語であって、
様々な言語を考えたときには、特殊な例で
あると思います。

「日本語に限ってみると、現状では
コンソールで日本語の入力を行うためには
アプリケーション側から直接かな漢字変換サーバー
などに接続して独自に処理を行わなければならない。」
でどうでしょうか。

> 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回操作しなければならない。これを間違えると、入力した文字列が
> 壊れてしまい、復旧できなくなる。

後半の文章は随分古い説明ですね…。
アプリケーション側がマルチバイト文字を扱っている
ことを認識していれば、また正しく wcsmbs が扱える
libc を使っていれば問題がないと思います。

From: Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx>
Subject: [debian-devel:10305] Re: Draft 1 (Re: I18N Document)
> > Windowsやglibcや次のバージョンのGTK+やQt-i18nの、内部コード
> > として使用されています(おそらく)。
> 
> えっ、glibc でも使われてるんですか？
> Windows 95/NT の内部で使われている (昔、Windows 95 を買ってまずやったのが、
> VFAT の解析でした。UNICODE で記録されるので、勢いで SHIFT-JIS と UNICODE の
> 対応表を作ってしまいました) のは知ってますが。

glibc では、内部 UCS-4 として扱われます。

> Canna や Wnn だと、I18N どころか L10N でしかないと思うのです。
> X でいう XIM みたいな標準ができればいいのですが。あるいは、XIM
> って私は名前だけしか知らないのですが、X なしで XIM サーバーだけを
> インストールし、コンソールからそれを使うような仕組みって実現可能
> なんでしょうか？それか、コンソール上の多国語入力の標準をつくろう
> という動きはないでしょうか？

あるといいですね。実際標準を作るのは大変そうですが。

あと、Wnn は日本語以外に韓国語(kWnn)と中国語(cWnn)を
扱うことができるバージョンが存在します。

--
後藤 正徳