[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[debian-devel:10340] Re: Draft 1 (Re: I18N Document)
久保田です。
喜瀬さん:
> ヘッダで指定した場合、たとえば日本語と英語までなら混在しても大丈夫
> ですが、さらに別の言語を追加することはできそうにないと思いますが、
> どうでしょうか。マルチパートみたいなことをする?
Arena-i18n のページ
http://www.wg.omron.co.jp/~shin/Arena-jwwwc-95/
によると、
1. ISO 2022-INT-* という、ISO 2022-JP を拡張したようなコードを使う。
2. UNICODE を使う。
だそうです。ところで、Arena-i18n は W3C の Arena を Omron が
拡張したもので、Mule みたいに多国語同時表示ができます。
http://www.wg.omron.co.jp/~shin/Arena-CJK-doc/ (英語)
によると、
ftp://www.wg.omron.co.jp/(以下略)
で取得できるそうですが、そんな名前のホストは存在しないって
言われてしまいます。
大石さん:
> 「ISO-2022-JP を拡張した ISO-2022-JP-1 や ISO-2022-JP-2 では
> JIS X 0212 も扱うことができる」といった表現ではどうでしょう。
ISO 2022 シリーズは、UNICODE 以外で唯一、3つ以上の言語を同時に
扱えるコードなので、きちんと説明したほうがいいかもしれませんね。
おおくまさん:
> ただフリーでないにせよ、論文はちゃんと出ているわけで、マルチスクリ
> プトがはるか遠い目標ということでもない、という意味で refer してお
> く価値はあると思います。
論文が出ているということがどれほどすごいことなのかはあまりよく
分かりませんが... 実装があるのは重要ですね。でも、英語で紹介
している Web ページとかはありませんか？
おおくまさん:
> 包接概念というのは、どの「文字」とどの「文字」を同じとみなすか、と
> いう考えですね。よくある話でははしご高と口高を同じとみなすか、とい
> った話です。
# これは同じとみなすべきなのですか？別々とみなすべきなのですか？
# 人名とかはきちっと表示できるほうがいいけど、一般的な文書の
# 場合、grep なんかにひっかからなくなるし。
おおくまさん:
> 時間なかったらパスしてもいいと思います。UNICODE 回りはあれこれ言っ
> てもあんまり意味ないような気もしてきたので・・・
私は、きちんと押さえておいたほうがいいような気がします。
UNICODE さえサポートすれば I18N は終わりだと思っている人が
いますし。私自身は UNICODE は多言語を表現できる唯一の stateless な
コードとしての役割があると思っていますので、数多くある
コードのひとつ、という位置づけなら OK だと思っています。
岡さん:
>> # そういえば、噂に聞く多言語 Web ブラウザ arena-i18n って
>> # どこにあるのでしょう？ だれか Debianize しないかな...
> arena - an HTML 3.0 compliant WWW browser for X
Debian パッケージになっているのは i18n ではない arena
じゃありませんでしたっけ？
岡さん:
>> ところで、そのパッチ作成の話、実例としてコードもまじえて、
>> 第7章の実例のところに contribute してもらえないでしょうか？
>ライセンスをつけるようなレベルの代物でないので、御自由にお使
>い下さい。間違っている可能性はあります。
># 悪い例として使うといいかも。
岡さん自身に書いてもらいたかったのですが... 無理でしょうか。
それに、それを悪い例なんて言われたら、私の立場がないです。
岡さん:
> EUC依存なこととカラム数依存なことは別物です。カラム数依存で
> あってもまだコードセットに依存していなければ十分価値のあるコー
> ドを保てています。gettextのような重要度の高いツールを汚した
> くなかったのです。
カラム数を扱うためには、個々の文字コードに関する知識を直接
実装するしかないと思うのですが。ドキュメントにもそう書いた
ので、もし文字コードに関する知識を直接実装しなくてもいい方法が
あるのなら、嘘を書いたことになるので、教えてもらえないでしょうか。
岡さん:
> # カラム数依存はgettextの機構には影響ありません。主にEmacs
> # でメッセージを翻訳する時にやり易いだけです。
# それだとよけい、折り畳みをデフォルトでは無効にしてくれ、なんて
# 要求ができるのではないでしょうか？たんにやり易いということの
# ためだけに、2バイトコードが破壊されるのを受け入れるなんてのは
# ナンセンスだと思います。
岡さん:
> メールソフトでEUC-JP→JISやJIS→EUC-JPに変換することなんかも、
> メールソフト側がフィルタ的プラブイン機構を提供することで国際
> 化の一環として実装できそうです。これのEUC-JP <-> JISプラグイ
> ンを書くことが地域化。
>
> 言い換えると、「国際化」に収まらなかったものが「地域化」にし
> わ寄せされているように思います。
各論になってしまいますが、それでも重要なことですね。
メール・ニュースについては、第6章に独立した項目を設けることにします。
岡さん:
> FontとFontSetの対応はたいてい以下のようになるようです。
> # 他にもありますが割愛。
>
> Font | FontSet
> ==================+====================
> XFontStruct | XFontSet
> ------------------+--------------------
> XLoadFont() | XCreateFontSet()
> ------------------+--------------------
> XUnloadFont() | XFreeFontSet()
> ------------------+--------------------
> XQueryFont() | XFontsOfFontSet()
> ------------------+--------------------
> XDrawString() | XmbDrawString()
> XDrawString16() | XwcDrawString()
> ------------------+--------------------
> XDrawText() | XmbDrawText()
> XDrawText16() | XwcDrawText()
> ------------------+--------------------
この表、そのまま引用してかまわないですか？ 私には理解できませんが、
必要な人ならちょっと勉強すれば理解できるだろう、ということで...
ようするに、左側を使っているような場合は右側を使うように
書き換えろ、ってことですよね。
岡さん:
> で、Xはこれだけでいいかと言うと、そうじゃないような気がして
> きました。例えばAthenaやMotifやGTK+やQtによって全然違うプロ
> グラミングインファフェースがあるわけですから、内部的にこれを
> 使っていようと表面的なプログラマには関係無い話です(Qtについ
> ては上記の関数すら使ってないと思います)。
>
> そういうわけで、主要なものを全部書くか、一般化した表現に留め
> るかだと思います。
さっきの一覧表を書いておいて、「ツールキットを使う場合も同じ問題が
あるのでそれぞれのツールキットについて各自調べろ」と書くように
すればいいでしょうか。
/***********************************************************
* 久保田智広 Tomohiro KUBOTA
* tkubota@xxxxxxxxxxx / kubota@debian.or.jp
***********************************************************/