[ruby-list:16807] Re: RD and internationalization

あおきです。

  In mail "[ruby-list:16793] RD and internationalization"
    [e-mail] wrote:

> 青山です。

> > プログラムの文字列の場合は、スキャンを通すのは簡単です。即値の
> > 埋め込みにこだわる必要はありませんから、文字列を加工した形で
> > 保持し、プログラム中で明示的/暗黙的に元の形を復元することが
> > できます。
> 
> RD の話の流れとしては同意しますが、実際にそのようなコードを書く場合に
> はなかなか面倒だと思われます。RD を base64 で埋め込むのがあまり評判が
> 良くなかったように、プログラム中の文字列であっても、デコードしなければ
> 読めないデータが含まれるのは不便でしょう。
> 
> また、書く方にしても、一々何かで書いて、エンコードして、それを埋め込む
> となると、書くのもデバッグも大変です。

プログラムリソースでは、en/deコードする必要はないです。
例えば、リソースを別ファイルにまとめて格納したとして、File.open....
で読みこめば、Rubyインタプリタがスキャン・パースする必要はまったく
ありません。またリソースは人間が直接読むためにあるわけではなく、
気軽に編集できる必要もないものです。英語環境で開いて「画面が壊れた」
とか言われても相手にする必要はありません。つまり、エンコードする
必要はない。

また、キーとなる文字列はASCIIであればなんでもいいのですから、
ソース埋め込みの文字列は英語で書いてもいいわけです。例えば、

  puts t 'Hello, World'

のようにソースを書いて、

  こんにちわ世界

のように表示されるようにするのはたいして難しいことではないでしょう。

そして前回のメールで一番言いたかったのは、どんな方法を使うとしても
それはすべて開発者側で解決できる問題であって、使う側の環境や
努力を要求しないということです。もちろん、LANG=ja_JP.euc のような
設定だとか、それに合ったフォントは必要ですが、個々のプログラムごとに
いろいろ考えたり、起動するごとに特別なツールを使ったりする必要は
ないということです。


> > 一方で、ソース埋め込みのRDはASCIIに限ることにすれば、RDのスキャンには
> > 問題はなくなります。使われる可能性のあるすべてのキャラクタセットに
> > 対応することは不可能ですから、この妥協は現状ではやむを得ないと思います。
> 
> 私もそのように思っていたのですが、=begin, =end 内は ASCII 以外も入れて
> 大丈夫そうな気がして来ました。=end が来るまではどのようなデータでも無
> 視されるようですから、例えユニコードが入ったとしても、偶然にも行頭で
> =end にマッチするような状況の発生する確立はほぼ無視して良いレベルにな
> りそうですから。

=begin =end のスキャンには対応できても、ASCII以外の文字が入っていると
ASCII環境では端末が壊れることがあります。


> ただ、その後ででも、プログラム中の文字列リテラルについてもぜひ検討して
> いきたいと思います。

そうですね。
これはぼくも当然そうあってほしい(じゃなきゃ困る)と思います。
(某書によると「国際化を真剣に考えているのは日本人だけ」らしいので…)
-------------------------------------------------------------------
あおきみねろう