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

[debian-devel:10285] Re: I18N Document



In <19990906114423J.kubota@xxxxxxxxxxxxxxxxxxxxx> (Sep.06 1999 11:44 JST),
``[debian-devel:10281] Re: I18N Document'',
kubota@xxxxxxxxxxxxxxxxxxxxx says:
=
=   ところで、いまのところ、目次だけを公開していますが、
=   目次を見て、なにか意見とかありますか?
=   (目次だけじゃあ分からないかも知れませんが)

先に目次を作ってしまうと、中身を埋めた頃には一冊の本になってしま
います ;-)

方向としては、国際化に関するトピックを集めて、それをこんな感じで
分類してまとめていくよ、というくらいでいいとおもいます。つまり、
どちらかというとFAQリストを作っていくイメージ。

その程度の軽さのニュアンスで、もう、あっちに出してしまってはどう
でしょう。同時に、今疑問に思っていることを質問項目として出しても
らう。できるだけ箇条書で。

こちらも「はやめにリリース、しょっちゅうリリース」でいきましょう ;-)


=   >     http://java-house.etl.go.jp/ml/topics/topics.html#i18n-unicode
=   
=   しらべておきます。って、これってメーリングリストアーカイブですね。

そう、鵜飼さんのトピックスページ同様のページです。アーカイブへの
リンク集にもなっています。


=   いっちまーんえーん!買いました。きのう。:-)

ほかになにかないもんですかね。あと思い付くのは、あの、「日本語情
報処理」ってほんくらい。私は個人的には ISO 2022 についてちゃんと
解説してあるようなのがほしいんですが。それから、m17nな文脈での
「スクリプト」の概念も、私はいまいちちゃんと把握できていない。


=   そういや、システムに備わっている(べき) I18N のためのしくみ
=   (LOCALE, XIM, などなど) にかんする章がないなあ...

General topics的なものは、それじゃあ、私なにか書いてみます。


=   でも、現状の glibc2.1 の LOCALE の問題点とか、
=   (問題だ、って話はよく聞くのですが、なにが問題なのですか?

locale一般についての問題点ということなら:

1.  基本的に、「切替えて」使用するものだ、という点です。同時に
    複数の「地域化情報」を統合して扱うような設計になっていない。
    多国語混在データを扱うとき、かなりの部分(場合によっては全部)
    をアプリケーション側で作り込まなくてはなりません。

2.  「情報の論理的地域性」とでもいったものを取り扱うカテゴリが
    ありません。例えば、man でマニュアルを読むときのことを考え
    てみてください。あるシステムについて「日本に特化した部分の
    機能説明」を「フランス語」で読みたい、というような場合、
    ``LANG=fr_JP''などという指定は役にたちません。

3.  非常に誤解されやすい点ですが、locale指定は「環境」であり、
    個々の情報に追加される属性ではないということがいえます。た
    とえば、あるアプリケーション内で取り扱うデータが、``100''
    という数値で、しかもこれは金額をあらわすものであるとき、
    LC_MONETARY の指定はその金額データの意味内容とは無関係です。
    それが日本円なら、LC_MONETARYがなんであろうと「100円」なの
    であり、「100米ドル」も「100ドイツマルク」も意味しないので
    す。LC_CTYPEについても同様のことが言えます。

ほかにも例えば、日中韓混在データをソートする場合など、まずまち
がいなくアプリケーション依存の処理をアプリケーション内部に作り
込む必要があるだろう、ということなどがあげられますが、これは、
このような場合に利用できる system-wideなフレームワークというも
のが存在していないことを意味しています。

#以上はどこかに書いておいてください ;-)


=   ワイド文字くらいは触れたいしなあ... (ワイド文字に付いては、
=   いま、いっちまーんえーん!を読みながら10行ぐらいの
=   小さなテストプログラムを作って勉強中です。)

wide characterの説明では、「固定長」であることを強調するべきで
しょうね。つまり、記憶効率を無視して内部処理の簡素化を図ってい
るわけです。multibyte character では、たとえステートレスなcodeset
であっても、「文字境界の判別」というのが、まずまちがいなく、た
いていのアプリケーションで、必要な処理になってきますから。

#なお、追記、修正、コメント歓迎。Let's do ``the Bazaar'' ;-)


 -.- . -. -.
Ken Nakagaki (kenn@xxxxxxxxxxx is NOT for private E-Mail)
「人は船ではない。人は会社ではない」-- Gerry Spence