Namazu-devel-ja(旧)


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MKNMZ_SEGMENT (Re: NMZ_MESSAGE andNMZ_CTYPE)



<3B55326E.83376C20@xxxxxxxxxxxxxxx>の記事において
yw3t-trns@xxxxxxxxxxxxxxxさんは書きました。

>> >   filter を考えると確かに問題ですね... 将来の可能性としては、少なくと
>> > も filter に利用可能なソフトウェアに制限がない以上、locale に依存した
>> > ものを利用する場面は増えるかもしれません。とはいえ、これは filter で吸
>> > 収すべき問題である気もします。 
>> 
>> これは、簡単に filter で吸収できる問題なのでしょうか。

  わかりません ^^; 現状の枠組だけ(日本語 or ASCII)で考えれば、適切な
locale で呼びだすようにする、ぐらいしかできないだろうなとは思っていま
す。

# 多分 deb.pl も islang("ja") が真のときは C locale で呼びだすようにし
# ないといけないような...

>> >   となると、あとは Namazu そのものについてのみ考慮すれば良いように思う
>> 
>> filterやfilter 以外 (nkf, KAKASI, ChaSen)があっての Namazu だと
>> 思います。ですので、Namazu のみ考慮すれば、本当に良いのでしょうか。

  あ、これは

* filter が呼び出すコマンドは filter で locale の面倒をみる
* nkf, KAKASI, ChaSen が locale に依存しない

  という前提があってのことなので、そうでなければもちろん考える必要はあ
るでしょう。

>> > のですが... 個人的には国際化だけでなく多国語化の可能性もさぐってゆきた
>> 
>> Namazu における多国化とは、どのような可能性をさぐろうと考えて
>> おられますか?

  一つには、ある directory にいろいろな言語で書かれたデータ(ただし一つ
のファイルに複数言語は含まれないとする)が含まれるような状況で、それぞ
れの言語に適した処理が行なえるような作りにしたい、ということを考えてい
ます。

# Apache の content negotiation を利用した web contents が含まれるよう
# な directory は実際にこのケースに当てはまるでしょう。

  それ以外にも、一つのファイルに複数の言語で書かれた文章が入っているよ
うな場合において、それを適切に処理する、ということも考えています。これ
はさすがに今すぐどうすればよいかを思いつけません。
  Unicode Version 3 はこの辺を考慮したものらしいので、その枠組とあわせ
て考えてゆけば、将来実現可能かもしれないとは思っています。

# YARPC 19001 で田村さんの XML と Unicode に関する講演を聞いただけで、
# なんとなくできそうかなと思っただけなんですが ^^;

>> Namazu だけ多国化しても、filter や filter 以外 (nkf, KAKASI, ChaSen)
>> が多国化できなければ、あまりメリットはないのではないかと思いますが
>> いかがなものでしょう。

  もちろん、その時にはそれらも考慮する必要があると思います。現状だとそ
れらを言語ごとに選択することすらできませんから、そこから手をつける必要
があるでしょうね。
-- 
野首 貴嗣
E-mail: knok@xxxxxxxxxxxxx
	knok@xxxxxxxxxx / knok@xxxxxxxxxx