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

[Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx>]

久保田です。


おおくまさん:
>> System1 ってなんですか？
> まじめな多言語処理系です。
> http://www.mling.waseda.ac.jp/index-old.html などを御覧下さい。
> 場合によっては↓というわけでもないんです。
>> せいぜい I18N、それも中途半端な I18N どまりで、M17N などは絶対に
>> 実現できない、というのが現状なんですよね？その現状の中でできることは

System1 って、free software ですか？
(もちろん、ここでの free とは、DFSG free のことです)。
その Web ページを見ても、よくわかりませんでした。
ダウンロードして自分でコンパイルして試したりもできるのでしょうか？
おおくまさんは、試されたことがありますか？
フリーでないものを紹介しても仕方がないので。

フリーなのなら、文書で紹介するよりも、Debianize して、
Debian なり Debian JP なりに登録して実物を示すほうが、
ずっといいと思うのです。...って、「OS と X Window System の
部分的置換」が必要なら、ちょっと困難ですね。

# そういえば、噂に聞く多言語 Web ブラウザ arena-i18n って
# どこにあるのでしょう？ だれか Debianize しないかな...




おおくまさん:
>> CJK は×というのはなぜですか？
>> ・各国で広く使われている文字コードを無視している
>> ・似た文字を（細かい違いを無視して）統合してしまっている
>> という2点でよろしいでしょうか？
>一言で言えば「特に包接概念を持たないことによって、何についてのコードなのか
>が不明になっている」ということでいいのではないかと思います。

う〜ん、包接概念ってなんでしょう？ UNICODE は文字についてのコードなのでは
ないのですか？




おおくまさん:
> もし UNICODE ダメ論でいくなら、「日本語が危ない」などで指摘されている
> ポイントを羅列しておけばよいかと思います。

いえ、私はそんなに反対論にかたまってるわけじゃないんですが
(Tcl/Tk 8.2 はすなおにすごいって思ったし)、たんに私が UNICODE
について知らないので、知ってる人はどう思っているのか、問題が
あるならきちんと盛り込んでおかないと、と考えているのです。




岡さん:
>> SS3 以下は JIS X 0212 だと思ってたんですけど。「Linux/FreeBSD
>> 日本語環境の構築と活用」（いまのところ主要な資料にしています。
>> まえに読んだので）では、そうなっていたと思います。（いま手元にない）
> ほんとだ。先のメールの内容はどっかの資料をメモしていたので怪
> しかったようです。

それでは、とりあえず SS3 以下は JIS X 0212 として書き進めることにします。
もしそれに反するような資料を見つけたときには知らせてください。




岡さん:
> 基本的には8ビットクリーンでEUCではどうにか機能していますが、
> msgmergeプログラムだけはうまくいかないのです。古いバージョン
> の翻訳済みメッセージカタログ(ja.po)と新たな生のメッセージカ
> タログ(app.pot)から新しいバージョンの翻訳用のカタログ(ja.po)
> を生成する際[図1]、msgmergeは体裁を整えるために文字列を複数
> 行に折り畳むことがあります。その時にテキストが破壊されるのです。

そうだった! 折りたたみのことをすっかり忘れてました。




岡さん:
> そのため、EUCに特化した折り畳み規則を適用するパッチを作成し
> ています。いわゆるその場しのぎというやつです。最初はwchar化
> を考えていましたが、gettext全部直す必要がありそうだったので、
> 「問題回避」に終わりました。
> 当然本家とマージできるような代物ではないので放置しています。
> 翻訳する人は比較的小数なので、このパッチでしのいでいるようです。

# 私だったら「マージしてくれ」って言ってたかも。こわいもの知らずだし。
## それくらい自信過剰じゃなかったら、I18N についての文書を
## 書くぞ、なんて私は絶対に言い出さなかったはず。
# でも、gettext ってたしか GNU ですよね。GNU が相手なら
# やめてるかな... (「伽藍とバザール」の「伽藍」ですしね。)
# ところで意地悪な質問していいですか？そのパッチは、JIS X 0212
# (SS3 + 2バイト) に対応してました？

ところで、そのパッチ作成の話、実例としてコードもまじえて、
第7章の実例のところに contribute してもらえないでしょうか？

# いま思いつきましたが、折り畳みを無効にするコマンドオプションを
# 追加して、文字セットが ASCII と ISO-8859-* 以外なら自動的に
# それが有効になるようにしておくとかなら、マージできるのでは？
# gettext は GNU ツールだし、1行の長さに制限はないのでしょう？
# それに、どうせ折り畳みは「カラム数」という、文字コードの規格には
# ない概念をもとにした考え方であり、ようするに考え方そのものが
# 美しくないのだから、それの実装が美しくできるはずがない。
# というわけで、EUC べったりな実装とかでもいいんじゃない？




岡さん:
>> ところで、ひとつ質問があります。たとえば「ISO-2022-JP という
>> coding system は、ASCII、JIS X 0201、JIS X 0208、JIS X 0212
>> の各 coding system を切り替えて使う」という文において、
>> coding system という語が2回出てきますが、あきらかに、1回目と
>> 2回目では意味が違いますよね。正しく表現するにはどうすればいいでしょう？
>> だれか教えてください。
> 「ISO-2022-JP という (coded character set|codeset)  は、
> ASCII、JIS X 0201、JIS X 0208、JIS X 0212 の各 character set
> を切り替えて使う」
>  文字集合、キャラクタセット = character set
>  符号化文字集合 = coded character set
>  コードセット   = codeset
> #「国際化プログラミング」p53〜p54

ありがとうございます。このへん、私自身が混同していたところなので、
きちっと勉強しなおして盛り込みたいと思います。





岡さん:
> ごく事務的に言うなら、隣人と利益を共有するための仕組みが
> 「国」で、そんなに煙たいものじゃないと思います。
> JIS規格なんてのも言ってみれば国家的財産なわけでしょう。
> そういう意味で国と書きました。

# 「隣人」の範囲を恣意的に決めるのが「国」です。
# いやべつに「世界はひとつ」でなきゃ、と言いたいんじゃなくて、
# 時と場合によって「隣人」の範囲なんて変わってくるし。
# その範囲がたまたま現在の「国」に一致する場合もあるだろうけど。
# もちろん「世界はひとつ」の場合もあるだろうし。
#
# 「国」とは「仕組み」だ、という見方には賛成します。
# いや、「仕組み」であるべきだ、と言うべきかな。


岡さん:
> # でも日本ってそんな悪いイメージなのかなぁ...。
> # とても特徴的な国なのに。

# 日本という「国」つまり「仕組み」は特徴的だ、という意味ですか？




岡さん:
>> じゃあどうすればいいんですか。コード非依存にしようと思えば、
(略)
> 今できていることと、できていないことを分類することにも価値が
> あると思うのですが。

すみません、ちょっと過熱してました。分類することにも価値がある、
ということには、同意します。
たぶん、私は、美しさや拡張性や正しさを重視するか、それとも
いますぐとりあえず何とかなることを重視するか、というバランスが、
他の人よりもずいぶんと「いますぐ」のほうに傾いているんです。

# だから、gettext の quick hacking でも、マージすりゃいいのに、
# って考えるのです。だれかがそれに刺激されてきちんとした I18N
# を実装するかもしれないですしね。

ただ、プログラマやパッケージメンテナに向けた文書なのだから、
じゃあ今やるべきこと/できることは何か、ということまで書かないと
惑わせてしまうだけだと思うのです。それが「わからない」のなら
「わからない」で、正直に「わからない」と書けばいいんですけど。
ただ、Debian JP のメンバーは、私も含めて Debian でさんざん、
I18N はおまえらが考えるよりずっと難しいんだ、なんてことを言って
きたので、それなりにしっかりしたものを出さないと、とも思うのです。




岡さん:
> それから、足りないと書いたのは「I18Nでは足りない」と書いたの
> ではなくて、「wcstombs的な関数群」だけではI18Nをするには足り
> ないと書いたつもりです。ここではM17Nの事は一切関係ありません。

はい。それでは、何が足りないのか、意見を聞かせてください。

# 今やっと気がつきましたが、私が関心があるのは文字だけで、
# ほかの部分、たとえば通貨とか日付フォーマットには関心がないです。
# 文字についても、ワープロ的な機能にはあまり興味がなくて、
# というか、荷が重過ぎます。テキストファイルで表現できる範囲に
# 重点を置きたい。それ以上のことについては、そういうものがある、
# 程度の扱いになりそう。
# そういう文書になってもいいでしょうか？ >all
# もちろん、Introduction にはそのような旨を書かないといけませんね。




岡さん:
># 作業、大変だと思いますが、感情的に深読みしないようにして下
># さい。話が複雑になってしまいます。

おっけーです。ただ、あまりみなさんの志が高すぎて、
私にはついていけなかったのです。それから、私の
知識レベルが、高く見られすぎているのを感じています。
私は私のプログラミングのスキルでものを考えてるので...




岡さん:
>> えっと、それは目次の項目づけに対する意見ですね。私は X とコンソールで
>> 分類することが必要だと思ったから分類したのですが、ごっちゃにすると
>> どうなるか、ちょっと想像もつきません。
> いえ。久保田さんがXFontStructなどの言葉を直接使わず一般化し
> て書きたいと書かれていたので、こう書きました。そんなに気にし
> ないで下さい。

そんなこと言いましたっけ？すみません、意見が変わりました。X 全般について
そのふたつの関数だけでほとんど話がついてしまうくらいその関数が重要
なのなら、具体的に書きたいと思います... って、XFontStruct って、
関数じゃなくて構造体だったんですね。じゃあ話が長くなるかも...




岡さん:
>> >> フォントではなくて(コードセットごとの)フォントの集合を扱う
>> >> 必要がある、ということでしょうか？
>> > 最終的にはそのようです。が、フォントセットを選択するようなダ
(略)
>はい、そうです。
># 文章に雑音が多くて申し訳ありません。

わかりました。それでは、コードセットごとのフォントを集合を扱え、
というふうに書くことにします。


/***********************************************************
 * 久保田智広  Tomohiro KUBOTA
 * tkubota@xxxxxxxxxxx / kubota@debian.or.jp
 ***********************************************************/