[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:10320] Re: Draft 1 (Re: I18N Document)
久保田です。
岡さん:
> JISやSJIS(やUNICODE)は排除できるものではないですね。日本での
> ICQクライアントの事実上の標準はSJISですし、Windows向きに焼か
> れてしまったJolietなCD-ROMはUNICODEです。
なるほど。それはきちんと押さえておいたほうがいいですね。
こんなかんじでどうでしょう？
-----
以下の例外を除き、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 で書かれている。
-----
以下、もっと例があれば増やす。（挙げてほしい例を募集します)。
岡さん:
>> 存在します。でも、日本人でさえ知らないようなコードですからね...
>> とりあえず、EUC は日本語は 2 バイトだというのは間違った表現
>> なので変えます。
> 以下のようになっています。
SS3 以下は JIS X 0212 だと思ってたんですけど。「Linux/FreeBSD
日本語環境の構築と活用」（いまのところ主要な資料にしています。
まえに読んだので）では、そうなっていたと思います。（いま手元にない）
岡さん:
> きちんとI18N化できてなくて支障を来しているソフトウェアの例。
> gettextです。msgmergeを使うと、しばしばEUCの日本語でさえ1バ
> イト目と2バイト目の間で分断されてしまいます。wchar化すれば解
> 決します(が、コード全体を一掃しなければならない)。
では、いまのところ、msgmerge を使うプログラムがやるべきことは
何ですか？（岡さんは、私はそんなこと百も承知だろうと思っていませんか？
私は、ほんとうに無知なのです）。
分断ってどういうふうに起こるのですか？ EUC だと " とか \ とか % は
出てこないから、8 ビットクリーン化だけで十分な気がするんですが。
(ただ、日本語はそれでもいいけど、他の言語がどうかわからないから、
wchar 化は必須だとは思います。日本語でも ISO-2022-JP とか SHIFT-JIS
だとだめですし)。
gettext を使ったプログラムは多いし、これからも増えてくると思うので、
もしなにか問題があるのなら、きちんと押さえておくべきだと思います。
というわけで、ぜひ取り込みたいので、教えてください。
後藤さん:
>> L10N (localization)
>> 英語以外の特定の言語のサポートだけを追加すること。
>> たとえば、Nemacs (Nihongo Emacs) は英語と日本語を扱える。
> 私はこの定義だけで良いのかどうか知らないのですが、
> 日本向けのワープロソフトの l10n としては、例えば
> 「ルビを正しく扱えること」なども含まれるのではない
> のでしょうか?
なるほど、日本語にはルビというのがありましたね。言語ごとの各論の
ところに入れておきます。（こんなところ - introduction - に書いたら、
I18N じゃなくて Japanization の文書になってしまう）。ただし、
テキストファイルの範囲ではルビは扱えない、というのも書く必要がありますね。
でも優先準位からいうとルビよりも縦書きのほうが重要な気がします。そうすると、
一部縦書き用フォントが必要になって (「ー」とか)... だれかが標準を
作らないとだめですね。
後藤さん:
> 「LANG 環境変数」は POSIX で規定されているものですので、
> その辺りの規格まで突込んで紹介できると良いですね。
そのへんは、ポインタを示すだけでいいと思っています。
私は全然知らなかったのですが、draft を公開してから、いろんな
資料が Web 上にはあるということを、この ML 上で紹介して
もらいましたので。
後藤さん:
>> M17N (multilingualization)
>> 多くの言語を同時に扱えるようにすること。いまのところ、
>> じゅうぶんにこれを達成しているのは Mule (MULtilingual
>> enhancement of GNU Emacs) くらいのものである。
> これは、application におけるコード系の扱いのことを
> さしているのでしょうか?
> 意味する部分が少し曖昧な気がします。
どこが曖昧でしょうか？ 私がいまこの文書について反省しているのは、
ここでは機能の話をすべきであって、実装の話をすべきではない、という
ことです。つまり、機能上の分類では L10N, I18N, M17N があり、一方
実装上の分類では standard や library や OS の機能を使うことで特定の
言語の知識に依存しなくて済むコーディングと、その反対に特定の（1個とは
限らない）言語の知識を使ったコーディングです。いまのところ、
standard は I18N の分野にしか存在しないので、M17N を目指すには
特定の言語の知識を使わざるを得ない。
後藤さん:
>> I18N は、C だと locale や wchar_t などの枠組を用いることで
>> 達成することができる。特定のコーディングシステムについての
>> 知識を使うべきではないが、locale などのような枠組が存在しない
>> 分野では使わざるを得ない (たとえばコンソールでの文字入力)。
>
> 何を達成できるかが不透明な気がします。
> また POSIX locale を完全サポートしたことが
> すなわち i18n であるといえるのかが、難しいところですね。
具体的には、なにが足りないのですか。それを知りたいです。そんなことを
書いても、I18N を目指すプログラマの気分を萎えさせるだけだと思います。
後藤さん:
> 例えば、日本語 JIS コードでは、日本語文字・アルファベット・
> ギリシア文字・キリル文字が表現できますよね。
JIS X 0208 コード中のアルファベット・ギリシア文字・キリル文字については、
あえて無視しています。ギリシア・キリル文字はともかく、アルファベットは
同じ文字に二重にコードが割り振られるという問題を生じさせるので
（JIS X 0201 カタカナがいけない理由 [のひとつ] とおなじ。もうひとつは、
濁点と半濁点が独立の文字になっていること）、使わないべきです。
「存在するけど、使わないべき」というふうな表記なら、取り込んでもいいです。
後藤さん:
> i18n とグリフと言語とコード系は、イコールで
> 結ばれるものではないと思いますが、いかがでしょうか。
> また、それぞれの関係が記述されるとより一層
> 詳しく説明できそうですね。
すみません、私は詳しくないので分かりません。
ところで、ひとつ質問があります。たとえば「ISO-2022-JP という
coding system は、ASCII、JIS X 0201、JIS X 0208、JIS X 0212
の各 coding system を切り替えて使う」という文において、
coding system という語が2回出てきますが、あきらかに、1回目と
2回目では意味が違いますよね。正しく表現するにはどうすればいいでしょう？
だれか教えてください。
後藤さん:
> 変換エンジンを必要とするのは、多くは
> 「仮名混じり漢字」表記を行う日本語であって、
> 様々な言語を考えたときには、特殊な例で
> あると思います。
日本語以外の言語ではどうなってるのか、という議論は、
Debian JP では議論したくないです。Debian でやったほうがいいに
決まってるから。
それに、全く変換エンジンなしで入力できるのは ASCII 文字
だけなのでは？普通の意味での変換なしに入力できる文字
（たとえば JIS 配列キーボードにおける かな など）でさえ、
システム (のどこの部分でもいいけど、どこか) が JIS 配列を
知っている必要がありますよね。ローマ字入力だと変換エンジンが
必要です。
後藤さん:
> glibc では、内部 UCS-4 として扱われます。
わかりました。これは、glibc における LOCALE の実装の特性を知る上で
重要な点なので、どこかに入れておきたいと思います。しかし、一方で、
glibc の LOCALE の実装がじつは UCS-4 だ、という知識に依存したような
プログラムは、当然のことながら書くべきではないですよね。（というのが
理想）。
それで、これはぜひとも書きたいのですが、glibc のLOCALE の実装が
中途半端だというのは、具体的には何なのですか？
LOCALE という枠組みそのものが中途半端だ、という意見は、具体的な
事例付きで紹介されているのですが。
後藤さん:
> あと、Wnn は日本語以外に韓国語(kWnn)と中国語(cWnn)を
> 扱うことができるバージョンが存在します。
日本語 Wnn で日本語入力が可能なように作ったプログラムは、
kWnn や cWnn を使った入力も可能ですか？
岡さん:
>> 私は理想が低すぎるのでしょうか...
>> もっときちんとした I18N (or M17N) を要求しろという意見が多いですね...
>> すこしだけ、軌道修正することにします。
> 高い意識で私達の国の言葉を守ろう、ということです。
私に向かってそれを言うととめどもない framewar になるので、
やめてください。私達の言葉を守ろうだったらまだ OK ですが
（自分の利益を守ることがたまたま隣人の利益を守ることにも
なってる、ということだから）、私達の国の言葉なんて
言われると嫌悪感がします。私は、「日本人」という言葉さえ、
存在を認めてないですから。
(文脈によって日本国籍保有者とか日本語話者(日本語人)とかいう
言葉を使いわけろ、って思います。ちなみに、国籍なんて、
ほんの紙一枚の重さであるべき）。
話が過熱しないうちにやめます。
岡さん:
> というか、EUC-JPにベッタリ依存すると絶対後で痛い目に遭いそう
> です。コード非依存に記述できる抽象化を行うライブラリを通して
> 処理できる必要があり、wcstombs的な関数群はある程度これをサポー
> トしていると言えますが、たぶん全然足りないと思います。
じゃあどうすればいいんですか。コード非依存にしようと思えば、
せいぜい I18N、それも中途半端な I18N どまりで、M17N などは絶対に
実現できない、というのが現状なんですよね？その現状の中でできることは
何か、を考えなきゃならないと思うんですが。その一方で、コード非依存で
M17N ができるための枠組み作りというのも重要になってくるでしょうが、
それのための指針が示せるような文書を書くつもりは全然ありません。
それだけの技術力がないですから。読む人の M17N の枠組み作りへの
意欲をかきたてるような文書、というのなら、まだしも...。
岡さん:
> Xの場合に限るとXFontStructとXFontSetに集約されるわけですが、
> 一般化して下さい。
えっと、それは目次の項目づけに対する意見ですね。私は X とコンソールで
分類することが必要だと思ったから分類したのですが、ごっちゃにすると
どうなるか、ちょっと想像もつきません。
岡さん:
>> フォントではなくて(コードセットごとの)フォントの集合を扱う
>> 必要がある、ということでしょうか？
> 最終的にはそのようです。が、フォントセットを選択するようなダ
> イアログは考えただけでも鬱陶しいので、選択するのはフォント、
> ダイアログか何かがそこからフォントセットを推論するというのが
> 妥当なのかもしれません(それも最適かどうか疑問)。
この場合の、「それも最適かどうか疑問」というのは、技術的な問題
というよりは、すぐれたユーザーインターフェースはどうあるべきか、
という問題ですね。ところで、技術的な問題はこれで解決と考えて
いいのでしょうか？（つまり、そうすれば文字化けはしない）
おおくまさん:
> そちらの成果である System1 については賛否あるようですが、
System1 ってなんですか？
おおくまさん:
> また UNICODE については「現在のバージョンでは CJK では×だけど
> ISO-8859-* を統合するには○、次のバージョンではなんか変わるかも」
> などといったトレンドについても触れておくとよいかも知れません。
> (が正確には僕もよく知りません)
CJK は×というのはなぜですか？
・各国で広く使われている文字コードを無視している
・似た文字を（細かい違いを無視して）統合してしまっている
という2点でよろしいでしょうか？
前田さん:
> この観点(ブラウザが判別を間違えること)から言えば、どちらかと言う
> とISO-2022-JPを使うことよりも、ヘッダできちんとcharsetを指定する
> ことの方が重要だと思います。
理想を言えばそうですけどね。どちらにせよ、ブラウザはあらゆる
coding system を認識すべきですね。それに加えて、自動判別とか、
自動判別が間違えたときに手動で指定できたりとかする必要がありますね。
/***********************************************************
* 久保田智広 Tomohiro KUBOTA
* tkubota@xxxxxxxxxxx / kubota@debian.or.jp
***********************************************************/