国際化対応のためのメカニズムとしてDelphi/C++Builder(Ver3以降)にはローカライズリソースDLL(localized resource DLL)があります。これは拡張子".EXE"、".DLL"、"BPL"のファイルについて、実行時にこれらのファイルからのリソース(フォームデータ、リソース文字列、その他の埋め込みリソース)のロードをローカライズリソースDLLからのものに置き換えてしまう、というものです。
この動作はSystem.pasのLoadResourceModule関数で処理されますが、ここではまず"HKCU\Software\CodeGear\Locales"(Delphi 2009 or later)、"HKLM\Software\CodeGear\Locales"(Delphi 2009 or later)、"HKCU\Software\Borland\Locales"(Delphi 4 or later)、"HKLM\Software\Borland\Locales"(Delphi 6-2007)、"HKCU\Software\Borland\Delphi\Locales"(Delphi 3 or later)の順にレジストリキーの存在を確認し、いずれかが存在したら次に実行ファイルのフルパス名の登録があるかどうかを見て、登録されていたら代替ロケール識別子として取得します。次に実行プログラムのロケール識別子を実行ロケール識別子として取得します。その上で実行ファイルのフルパス名の拡張子を代替ロケール識別子(登録されていれば)、実行ロケール識別子、実行ロケール識別子の先頭2文字だけ、の順で置き換えてWin32APIのLoadLibraryExを呼び出し、成功したらそのモジュールハンドルを以後のリソースの取得に使用します。いずれも失敗した場合はもともとの実行ファイルのモジュールハンドルからリソースを取得することになります。
ここでロケール識別子はGetLocaleInfoのLCTYPEにLOCALE_SABBREVLANGNAMEを指定して取得される3文字の英字で、最初の2文字が言語簡略名(ISO 639)を、3文字目がサブ言語タイプ(主に地域)を示します。詳細なリストはMSDNのNational Language Support (NLS) API Referenceにあります。
ということは、実行ロケールがJPN(ロケールID=0x0411/日本語版Windows)かつ実行ファイルのロケールがJPN以外(例えばENU=0x0409)の状況でローカライズリソースDLLとして.JPNファイルが存在する場合、実行ファイルのリソースを使用する方法がない(.JPNファイルを削除するしかない)わけです。どーりでレジストリに何を指定しても駄目なわけだ…。
元ねたは"Source\RTL\SYS\System.pas"。
2009/09/06追記: 新井さんによるとDelphi 2010ではこの選択メカニズムに一部変更があったとのことです。
Embarcadero Discussion Forums: Delphi2010 国際化対応について ...
Delphi 2010を入手したら検証してみたいと思います。
2011/05/04追記: forums.codegear.comのリンクをforums.embarcadero.comのものに差し替え。
2009年6月16日
登録:
コメントの投稿 (Atom)
2 件のコメント:
FT やってるなら問題提起位しろよ
この件についてってことですか?仕様だといえば仕様だし。それにFTerだからとかそういう話でもないでしょ。
Tiburon FTはもう終息状態だし、Weaver FTはどうも選んでいただけなかったみたいだし、なんか考えてQCにでも出しますか。
コメントを投稿