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

[Mitsuru Oka <oka@debian.or.jp>]

岡＠奈良先端です。


At Wed, 8 Sep 1999 17:14:34 +0900,
Tomohiro KUBOTA <kubota@xxxxxxxxxxxxxxxxxxxxx> wrote:
> 
> 久保田です。

> SS3 以下は JIS X 0212 だと思ってたんですけど。「Linux/FreeBSD
> 日本語環境の構築と活用」（いまのところ主要な資料にしています。
> まえに読んだので）では、そうなっていたと思います。（いま手元にない）

ほんとだ。先のメールの内容はどっかの資料をメモしていたので怪
しかったようです。


> 岡さん:
> > きちんとI18N化できてなくて支障を来しているソフトウェアの例。
> > gettextです。msgmergeを使うと、しばしばEUCの日本語でさえ1バ
> > イト目と2バイト目の間で分断されてしまいます。wchar化すれば解
> > 決します(が、コード全体を一掃しなければならない)。
> 
> では、いまのところ、msgmerge を使うプログラムがやるべきことは
> 何ですか？（岡さんは、私はそんなこと百も承知だろうと思っていませんか？
> 私は、ほんとうに無知なのです）。
> 
> 分断ってどういうふうに起こるのですか？ EUC だと " とか \ とか % は
> 出てこないから、8 ビットクリーン化だけで十分な気がするんですが。
> (ただ、日本語はそれでもいいけど、他の言語がどうかわからないから、
> wchar 化は必須だとは思います。日本語でも ISO-2022-JP とか SHIFT-JIS
> だとだめですし)。

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

  [図1]
  app.pot       \    msgmerge
                | ----------------> (new) ja.po
  (old) ja.po   /

  [図2] 変換成功例
  msgstr ""
  "@DESCRIPTION=全ての値および引数リストで参照されているセルの標準偏差を計算します。これは分散(VARIANCE)の平方根と同等です。\n"
    ↓
  msgstr ""
  "@DESCRIPTION=全ての値および引数リストで参照されているセル"
  "の標準偏差を計算します。これは分散(VARIANCE)の平方根と同"
  "等です。\n"

そのため、EUCに特化した折り畳み規則を適用するパッチを作成し
ています。いわゆるその場しのぎというやつです。最初はwchar化
を考えていましたが、gettext全部直す必要がありそうだったので、
「問題回避」に終わりました。

  http://www.aist-nara.ac.jp/~mitsu-o/junkbox/message.diff

当然本家とマージできるような代物ではないので放置しています。
翻訳する人は比較的小数なので、このパッチでしのいでいるようです。

> 後藤さん:
> > i18n とグリフと言語とコード系は、イコールで
> > 結ばれるものではないと思いますが、いかがでしょうか。
> > また、それぞれの関係が記述されるとより一層
> > 詳しく説明できそうですね。
> 
> すみません、私は詳しくないので分かりません。
> 
> ところで、ひとつ質問があります。たとえば「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

> 岡さん:
> > 高い意識で私達の国の言葉を守ろう、ということです。
> 
> 私に向かってそれを言うととめどもない framewar になるので、
> やめてください。私達の言葉を守ろうだったらまだ OK ですが
> （自分の利益を守ることがたまたま隣人の利益を守ることにも
> なってる、ということだから）、私達の国の言葉なんて
> 言われると嫌悪感がします。私は、「日本人」という言葉さえ、
> 存在を認めてないですから。
> (文脈によって日本国籍保有者とか日本語話者(日本語人)とかいう
> 言葉を使いわけろ、って思います。ちなみに、国籍なんて、
> ほんの紙一枚の重さであるべき）。
> 
> 話が過熱しないうちにやめます。

過熱しないようにしますが、何か勘違いされてるようです。

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

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

> 岡さん:
> > というか、EUC-JPにベッタリ依存すると絶対後で痛い目に遭いそう
> > です。コード非依存に記述できる抽象化を行うライブラリを通して
> > 処理できる必要があり、wcstombs的な関数群はある程度これをサポー
> > トしていると言えますが、たぶん全然足りないと思います。
> 
> じゃあどうすればいいんですか。コード非依存にしようと思えば、
> せいぜい I18N、それも中途半端な I18N どまりで、M17N などは絶対に
> 実現できない、というのが現状なんですよね？その現状の中でできることは
> 何か、を考えなきゃならないと思うんですが。その一方で、コード非依存で
> M17N ができるための枠組み作りというのも重要になってくるでしょうが、
> それのための指針が示せるような文書を書くつもりは全然ありません。
> それだけの技術力がないですから。読む人の M17N の枠組み作りへの
> 意欲をかきたてるような文書、というのなら、まだしも...。

今できていることと、できていないことを分類することにも価値が
あると思うのですが。

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

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

> 岡さん:
> > Xの場合に限るとXFontStructとXFontSetに集約されるわけですが、
> > 一般化して下さい。
> 
> えっと、それは目次の項目づけに対する意見ですね。私は X とコンソールで
> 分類することが必要だと思ったから分類したのですが、ごっちゃにすると
> どうなるか、ちょっと想像もつきません。

いえ。久保田さんがXFontStructなどの言葉を直接使わず一般化し
て書きたいと書かれていたので、こう書きました。そんなに気にし
ないで下さい。

> 岡さん:
> >> フォントではなくて(コードセットごとの)フォントの集合を扱う
> >> 必要がある、ということでしょうか？
> > 最終的にはそのようです。が、フォントセットを選択するようなダ
> > イアログは考えただけでも鬱陶しいので、選択するのはフォント、
> > ダイアログか何かがそこからフォントセットを推論するというのが
> > 妥当なのかもしれません(それも最適かどうか疑問)。
> 
> この場合の、「それも最適かどうか疑問」というのは、技術的な問題
> というよりは、すぐれたユーザーインターフェースはどうあるべきか、
> という問題ですね。ところで、技術的な問題はこれで解決と考えて
> いいのでしょうか？（つまり、そうすれば文字化けはしない）

はい、そうです。
# 文章に雑音が多くて申し訳ありません。
--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学