[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)
奈良先端科学技術大学院大学