これは一般的な質問で、意見を募集しています。私は、Windows MFC アプリケーションおよび関連ユーティリティの文字列リソースのローカライズを設計するための良い方法を模索しています。私の希望は次のとおりです。
- コード内の文字列リテラルを保持する必要がある（マクロ#defineリソースIDに置き換えるのではなく）。これにより、メッセージはインラインで読み取り可能になります。
- ローカライズされた文字列リソースを許可する必要があります (当然)
- 追加のランタイム環境制限を課してはなりません (例: .NET への依存など)
- 既存のコードへの干渉は最小限に抑える必要があります（変更が少ないほど良い）
- デバッグ可能であること
- 一般的なツールで編集可能なリソースファイルを生成する必要があります（つまり、一般的な形式）。
- コード内のリテラル文字列を保存するためにコピー/ペーストコメントブロックを使用しないでください。また、非同期化の可能性を生じさせるその他のものも使用しないでください。
- すべての「表記された」文字列がリソースファイル内にあるかどうかを静的（コンパイル時）にチェックできるようにすると良いでしょう。
- 言語間のリソース文字列プーリングを許可すると便利です (さまざまな言語のコンポーネント、例: ネイティブ C++ と .NET)
静的チェックを除いて、私の希望をある程度満たす方法はありますが、それを実現するにはカスタム コードを少し開発する必要がありました (制限もあります)。この問題を特に優れた方法で解決した人はいるでしょうか。
編集: 現在私が持っている解決策は次のようになります:
ShowMessage( RESTRING( _T("Some string") ) );
ShowMessage( RESTRING( _T("Some string with variable %1"), sNonTranslatedStringVariable ) );
次に、'RESTRING' ブロック内から文字列を解析してローカライズ用の .resx ファイルに格納するカスタム ユーティリティと、ローカライズされたリソース ファイルからフォールバックで文字列を読み込む別の C# COM オブジェクトを用意します。C# オブジェクトが利用できない (または読み込めない) 場合は、コード内の文字列にフォールバックします。マクロは、COM オブジェクトを呼び出して書式設定などを行うテンプレート クラスに展開されます。
とにかく、参考までに今持っているものを追加しておくと便利だと思いました。
ベストアンサー1
ID として英語の文字列を使用します。
国際リソース オブジェクト (インストールされた I18N dll からロードされる) からの検索に失敗した場合は、デフォルトで ID 文字列が使用されます。
コードは次のようになります:
doAction(I18N.get("Press OK to continue"));
ビルド プロセスの一部として、すべてのソースを解析して文字列定数を探す Perl スクリプトがあります。このスクリプトは、アプリケーション内のすべての文字列の一時ファイルを作成し、各ローカルのリソース文字列と比較して、文字列が存在するかどうかを確認します。不足している文字列がある場合は、適切な翻訳チームに電子メールが送信されます。
各ローカルごとに複数の dll を持つことができます。dll の名前は RFC 3066
language[_territory][.codeset][@modifier]に基づいています。
I18N dll をロードするときに、マシンからロケールを抽出し、できるだけ具体的にしようとしますが、より具体的なバージョンが存在しない場合は、あまり具体的でないローカル バリエーションにフォールバックします。
例：
英国では、現地の人がen_GB.UTF-8
(dll という用語を、Windows 特有の意味ではなく、広い意味で使用しています)。
まず最初にI18N.en_GB.UTF-8dll。このdllが存在しない場合は、日本語このDLLが存在しない場合は、日本語このDLLが存在しない場合は、I18N.デフォルト
このルールの唯一の例外は、簡体字中国語 (zh_CN) の場合で、フォールバックは米国英語 (en_US) になります。マシンが簡体字中国語をサポートしていない場合、完全な中国語をサポートしている可能性は低いです。