🚀 go-pugleaf

阿部@オブジェクトディメンションです。レスポンスが遅くて申し訳ありませ
ん。
BSI JWORKS for Macの開発に関与していました。

From: Hiroyasu Nakatani <dirac@meiji.trad.pfu.co.jp>
Date: 15 May 1996 17:21:53 GMT

>Localeのメソッド：getLocaleName の<primitive 471>が、
>
>漢字Talkの場合は、'11-14'
>+ JLK の場合は、  '0-0'  (英語版と同じ、日本語登録しても同様)
>ScriptSwitcher等による場合は、'11-0' 
>
>をそれぞれ返すのが直接の原因になっているようです。

開発の際には、漢字Talk 7.5のみを対象とし、JLKなどは考慮していませんで
した。
<primitive: 471>は、2.5 Beta以前のMac版VMではフェイルしており、やむを
得ず決め打ちで強制的に日本語のロケールに切り替えていました。ところが、
2.5からは漢字Talk上で'11-14'を返すようになったため、これ幸いとロケール
の識別に用いました。しかし、その意味は解釈していません。

>  （'11-14' や　'11-0' などの、最初の数値が各国語のIDを表しているのは
分
>    かるのですが、後ろの数値の意味は分かりません。）   

憶測ですが、14はlocalization codeかもしれません。MacFont>>
initializeInternationalNamesの内容と一致します(偶然かも知れません)。
MacFontのコメントによると、これは「region code + 1」のようです。

>Localeのクラスメソッド: installJapaneseSJISLocaleMacintoshに手を入れ
て、
>辞書：LocaleMap に、これらに対応する新しい key を追加することも考えま
し
>たが、それでは、JLKに対応させた場合に、JLKの入っていない英語版システ
ムを
>区別できなくなるのでどうも気がすすみません。決めうちでJ-Localeにして
しま
>うのは、同じ意味でもっと気がすすみません。

そうですね。

>　本来、MAC-OS上のプログラムが、両システムを区別できないとは思えない
ので、
>バーチャルマシンのプリミティブが正しく作られていないという事でしょう
か？

そうかもしれません。他にもMac版を日本語対応にしようとして、不完全な状
態で止っているらしい箇所があります。例えば、Screen>>
primListFontNamesで使われている<primitive: 977>は、フォント名の一覧を
返しますが(正確にはフォント名をByteArrayにしたものの一覧)、この中の
script codeが信用できません。そのため、JWORKSでは、余計なクラス変数
KnownKanjiFamiryを入れたり、MacFont class>>parse:の実装が汚くなってい
ます。

現在、ParcPlace-DigitalkはMac版の2.5Jを出す予定は無いようなので、これ
らのプリミティブの実装について、文句を言っても、改善は期待できないかも
知れません。

>あるいは、正しく区別するプリミティブが別にあるのでしょうか？

外しているかも知れませんが、前述の<primitive: 977>で返るフォントの情報
にはlocalization codeが含まれています。これが、漢字TalkやJLKなどの環境
によって変化するならば、ロケールの識別に使えるかも知れません。
現在、Mac版のVisualWorks 2.5を使える環境を持っていないため、確認はでき
ませんでした。

Inside Macintoshを読んで、Cで書いて、UDPかDLL and C Connectで呼べば確
実なのでしょうが、面倒そうですね。

//abee
--
阿部 和広  (株)オブジェクトディメンション
EMAIL PEC01001@niftyserve.or.jp