たちばなまさしです。
本当はスレッドを変えるべきなのですが・・。
jp-patch 1.04 をつくりました。
1.03 の残された問題に対処しました。これで、機能的には 5.0 以前に
用意したパッチと同等（というかそれ以上）のものになりました。
致命的なバグがない限り、 5.01 用はこれで最後にします。
それから、5.02 以降のパッチの設計のはなしです。
>> 将来的に「メッセージは韓国語なんだけど、日本語で行なわれた検索ワード
>> もちゃんと拾える」ような環境をつくろうとしたときに、きっとたいへんに
>> なるだろうっていうのが一番の理由です。
>
>これだと韓国語も日本語も読める人のみに意味のあるプログラムでは？
>実用的に考えると1国内に数コードある場合の対応を考えれば良いのでは？
これは、国際化対応をどう考えるかっていう問題で、これが答えっていう
ものはないのが本当だと思います。が、僕は、1つのドキュメントのなかに
異なる言語を共存させる i18n のポリシーには共感しています（きちんと
理解してるかとか、どこまで協力する気があるのかとかはあやしいですが）。
utf-8 ができた背景もこれだし、世の中の動きとしても、ソフトウェアの
対応はなるべくなら多言語を前提にしようね！っていう考え方が評価され
つつあるように思います。
で、analog について。複数の言語を同時にサポートしても仕方がないと
いう考え方は理解できます。が、複数の言語でホームページを作っている
人は、結構いっぱいいます。松木さんが考えているほど無意味なことでは
ないように思うのです。なので、できることなら、ターナーがきちんと
「フレームワークは用意したから、あなたの言語にきちんと対応したかっ
たら、ここにコードを足しなよ」っていうふうにしてくれるのが理想かなあ
と思います（彼はしないだろうけど）。
でも、日本語化パッチが存在してるだけでも、いろいろと影響を与えて
いけるんだろうなあとは思います。
・・えらそうなことを言っていますが、僕はかなりいいかげんな人で、
特に崇高な思想とかを持っているわけではなくて、むしろ流されてコロ
コロと考え方が変わります。念のため。
>> ちなみに、実装が難しいというのは本当に難しいのではなくて、「改造箇所
>> が増えて、スマートなパッチにならない」という意味です。何かいいアイデア
>> はないですか？
>
>よく使う手は、以前にこのMLで出た関数のキャストを使えば、分岐が楽になる
>と思うのですが。
これは無数にある if 文関数分岐をすっきりさせるのには確かに有効だと思い
ます。が、いま困っているのはもうちょっと根本的なところです。
日本語文字列の変換自体は、 input.c のなかの fread() まわりをちょっと
直して、文字処理関数を呼び出せばすっきりといくと思います。
悩むのは、システム環境に合わせて自動的に適切な文字コードで出力する方法
（もちろん、文字コードの指定もできるようにする！）です。
たとえば、「LANGUAGE JAPANESE ってしておいて、 LANGFILE に AUTO って
書いておけば、自動的に適切な設定ができるようにしたらどうだろう」とか、
そういうことです。
何かいいアイデアはないかなあ。
-----------------------------------------
たちばなまさし
moomin@happymusic.com
http://www.happymusic.com/moomin/
-----------------------------------------