あおきです。

  In mail "[ruby-list:16794] Re: RD and internationalization"
    wakou / fsinet.or.jp wrote:

> 青山です。

> > ユーザの立場
> > 
> > いまだASCII環境が標準であることを考えると、少なくともソースコードは
> > ASCIIのみで構成されているのが望ましい。しかし、例えば日本語の
> > ドキュメントが欲しい人もたくさんいる。また、RDの大きな利点は、
> > ソースにドキュメントが埋めこまれていることなので、できれば日本語でも
> > そうしたい。
> 
> この件に関しては、=begin, =end 内はバイナリであろうと、何であろうと構
> 文解析時には無視してもらうという事で、日本語等をそのまま埋め込む事も許
> 容する方向が便利な気もします。(そのかわりに、何が埋め込まれているかを
> 示す為に、LANG= を追加してみたのでした)

Rubyがスキャンできても、読むときに問題が起きると思います。
読めないだけならいいですが、端末が壊れたりするので、やはり日本語を
そのまま含めるのはやめたほうがいいでしょう。


> > 1  読む側の多国語化は、ツールを介さない方法でなんとかできる。
> 
> これは、次の部分に相当する問題でしょうか。
>
> > ユーザの手に渡る前に「必ず」ひと段階置く必要があります。
> 
> もしそうであれば、これは問題無いです。=begin RD LANG=en のままで配布す
> れば良いだけなので。
>
> 日本語で書いた場合にも =begin RD LANG=ja 等のままで良いでしょう。

いえ、そういう問題ではないです。
最終結果をそのまま作ろうとすると、どうしても途中で rd のようなツールが
必要になりますよね。普通のエディタとビューアだけでは作れない。
それがいやなひとがいるということです。

そして、ファイルフォーマットを変えなくとも、ドキュメント入れ換えを
行うことは(確実性には欠けても)可能ですから、ドキュメント入れ換えの
ために特定のツールを使うことを強いる必要はないということです。


> このヘッダの提案は、配布する場合には RD を削除すべきという提案ではなく、
> どのような言語で書かれているかの情報を読む人に提供する為のものです。
> 
> つまり、LANG=ja のようにあれば、そこは日本語とわかりますから、日本語の
> 読めない環境の人はそこを無視すれば良いわけです。

われわれはそう思っても、非日本語環境の人はそう思わないと思います。
端末が壊れることがありますから。

(余談)
ぼくも iso-8859(だかなんだか)で書かれたファイルを開いたときに、
あるところまでいくと画面がぐちゃぐちゃになって、いらいらした覚えがあります。
viでは大丈夫だったので読んでみると、

「完全なiso-8859(？)環境があるところでは私の名前がちゃんと表示されます」

と書いてありました。アクセント記号みたいなのがついた文字を使っていた
ようです(ちなみに、cdrecord というプログラムのREADME)。


> > 2  ドキュメント入れ換えツールは、データベースを作らなくても
> >    作ることができる。
> 
> 確かに可能ですが、各言語間での整合性のチェックを人間が行うのはとても面
> 倒だと思います。
> 
> たとえ同じ順番で書くだけの事としても、少し話にも出たように、その順番が
> 入れ替わったりした場合には、すべての言語について手作業でチェックする事
> になり、これはもう、あきらかに爆発するであろう問題を含める事になると思
> われます。

まず、フォーマットに混乱が生じても、交換ができなくなるだけなので、
致命的な打撃にはなりません。ぼくはドキュメントの交換はできて
ほしいと思いますが、そうできるようにドキュメントを書くことを強制は
したくないですし、しませんし、できませんから、それでも構いません。
別の言い方をすると、「機構としてできない」のは許せないが、
「作るひとがやらない」のならしょうがないということです。

また、常に同じフォーマットを保ちたいと思ったら、それこそ独自ツールを
作ったりして工夫すればいいと思います。青山さんの方法もその一つですが、
そのために書く時のフォーマットを統一する必然性はないでしょう。
また、書く時の利点のために読む人にツールを使うことを強いるのも
違うと思います。

さらに、ドキュメント入れ換えが行われるのは読む側であって、書く側で
いちいち入れ換えながら作成する必要はまったくないはずです。


> 今回のサンプルコードでは pstore.rb を利用しましたが、データをテキスト
> で保存する事も可能でしょう。もしバイナリである事が問題ならば、そのよう
> な対応もあります。

いえ、そうではありません。
ツールを使わなければ個々のドキュメントをとりだせないことが最大の
問題です。
たとえプレーンテキストであったとしても、複数の文字コードが混在する
ことになるので、ビューアが役にたちません。


> > 3  書く側にとっては、もっと便利なフォーマットがある。
> 
> これは何かありましたっけ？  今回の私の提案では LANG を追加しただけなの
> で、特に書く側での不便さは無いと思っていましたが。

それぞれが重視する要求に応じて、ツール(とフォーマット)を作るほうが
結局は楽をできるということです。


> > 4  「最終結果」を直接作りたいと思う書き手の要求を満たせない。
> 
> １つの言語のドキュメントのみの場合はまったく何のツールも必要としません。
> また、当然ながら現在と同じく、最終結果を直接作る事になります。

日本人の場合、二つ以上用意することは普通なので解決にならないと
思います。
また、言語の追加のためには、コピーして編集、程度で十分ものになるし、
もっと便利にしたければ自分専用のツールを用意することでもっと
うまく(かつ便利に)やれると思います。


> > またこの問題に対するぼくの結論は、
> > 「ソースコードには英語(ASCII)でドキュメントに埋め込み、
> >   他の言語(charset)はそれぞれ別ファイル
> >   任意の言語をソースに埋め込むことはドキュメント入れ換え
> >   ツールを用意して代替手段とする」
> > です。
> 
> 結論は同じですね。食い違っているのは、その別ファイルの扱いの部分でしょ
> うか。

ぼくの提案は「それぞれ」別ファイルです。
ですから、

  言語それぞれが別のファイルに入っていて
  ビューアでそのまま読めて
  rd2htmlのようなものがそのまま使える

フォーマットならば、賛成します。
でもこれを満たすうちでは、結局最初にまつもとさんが言われたような
方法(ソースに英語、それ以外は ***.rd.ja のように格納)が楽で単純ですよね。
ぼくが別の方式を提案したのは、ドキュメントを入れかえてしまうという
考え、その方法が浮かばなかったからです。でも途中でその方法も思いついたし、
現実的な確率で交換ができるとわかったので納得(妥協)したんです。


> また、上記のように、LANG を追加する事によって、ASCII 以外も認めるのは
> ありかなと思います。(英語のドキュメントは後から、という場合に便利です
> よね。)

前述のように、環境によって端末が壊れることがあるので賛成できません。
-------------------------------------------------------------------
あおきみねろう