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

[debian-devel:10293] Re: I18N Document



岡@奈良先端です。


At Mon, 6 Sep 1999 21:41:35 +0900,
Ken N. <kenn@xxxxxxxxxxx> wrote:
> 
> 方向としては、国際化に関するトピックを集めて、それをこんな感じで
> 分類してまとめていくよ、というくらいでいいとおもいます。つまり、
> どちらかというとFAQリストを作っていくイメージ。
> 
> その程度の軽さのニュアンスで、もう、あっちに出してしまってはどう
> でしょう。同時に、今疑問に思っていることを質問項目として出しても
> らう。できるだけ箇条書で。

もう一つ偉大な資料がありました。確かナットシェルハンドブック
の日本語情報処理とかいう本の付録(?)です。

 ftp.ora.com/pub/examples/nutshell/cjkv/

以下の膨大な資料。なぜか英語の資料の方が沢山あるような気がし
ますが、あちらの方に伝えるには好都合です。

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

例えばpTeXは参考になります。日本語特有の禁則処理
(prohibition ruleだっけ)、ルビ(ruby)、アルファベットと2バイ
ト文字間のカーニング規則(kerning rule)、縦書きとそのためのフォ
ントセットおよびフォント機構など。

これから比べると、ブラウザのレイアウトエンジンに満足している
のは少し妥協しすぎです。日本語の文字間に謎のスペースが入って
いるのはHTMLを書く人が悪いというより、ブラウザがそういう風に
解釈するのが問題だと考えるべきです。

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

これは表示枠組としてm17nな機構を実装した上でコンテンツのl10n
化(翻訳)しないと綺麗には実現できませんよね。

--
岡 充 (Mitsuru Oka)
奈良先端科学技術大学院大学