22

これはちょっと一般的な質問で、意見を受け付けています。私は、Windows MFC アプリケーションおよび関連ユーティリティの文字列リソースをローカライズするための優れた設計方法を考え出そうとしています。私のウィッシュリストは次のとおりです。

  • メッセージをインラインで読み取ることができるように、コード内の文字列リテラルを保持する必要があります (マクロ #define リソース ID で置き換えるのではなく)。
  • ローカライズされた文字列リソースを許可する必要があります (duh)
  • 追加のランタイム環境制限を課してはなりません (例: .NET への依存など)。
  • 既存のコードへの干渉を最小限にする必要があります (変更が少ないほど良い)
  • デバッグ可能であるべき
  • 一般的なツールで編集可能なリソース ファイルを生成する必要があります (つまり、一般的な形式)。
  • コード内のリテラル文字列を保持するために、コピー アンド ペースト コメント ブロックを使用しないでください。
  • すべての「表記された」文字列がリソース ファイルにあることを静的 (コンパイル時) チェックできるようにするとよいでしょう。
  • クロス言語のリソース文字列プーリングを許可するとよいでしょう (さまざまな言語のコンポーネント用、たとえばネイティブ C++ および .NET)。

静的チェックを除いて、すべてのウィッシュリストをある程度満たす方法がありますが、それを実現するために少しカスタムコードを開発する必要がありました (そして制限があります)。誰かがこの問題を特に良い方法で解決したかどうか疑問に思っています。

編集:私が現在持っている解決策は次のようになります:

ShowMessage( RESTRING( _T("Some string") ) );
ShowMessage( RESTRING( _T("Some string with variable %1"), sNonTranslatedStringVariable ) );

次に、「RESTRING」ブロック内から文字列を解析してローカライズ用の .resx ファイルに配置するカスタム ユーティリティと、ローカライズされたリソース ファイルからフォールバックで読み込む別の C# COM オブジェクトがあります。C# オブジェクトが使用できない (または読み込めない) 場合は、コード内の文字列にフォールバックします。マクロは、COM オブジェクトを呼び出して書式設定などを行うテンプレート クラスに展開されます。

とにかく、参考までに今持っているものを追加すると便利だと思いました。

4

7 に答える 7

4

英語の文字列を 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
の場合 (特定の Windows の意味ではなく、大まかに dll という用語を使用します)。

最初にI18N.en_GB.UTF-8 dllを探します。この dll が存在しない場合は、I18N.en_GBにフォールバックします。この dll が存在しない場合はI18N.enにフォールバックしますこの dll が存在しない場合はI18N.defaultにフォールバックします

この規則の唯一の例外は、簡体字中国語 (zh_CN) で、フォールバックは米国英語 (en_US) です。マシンが簡体字中国語をサポートしていない場合、完全な中国語をサポートする可能性は低くなります。

于 2008-10-08T23:30:50.007 に答える
2

簡単な方法は、コード内で文字列 ID のみを使用することです。リテラル文字列は使用しません。その後、言語ごとに異なるバージョンの .rc ファイルを生成し、リソースのみの DLL を作成するか、単に異なる言語ビルドを作成することができます。

rc ファイルのローカライズに役立つシェアウェア ユーティリティがいくつかあります。これは、長い単語を含む言語のダイアログ要素のサイズ変更を処理し、翻訳の欠落について警告します。

より複雑な問題は単語の順序です。printf に複数の数字があり、言語の文法によって順序が異なる必要がある場合です。codeproject にはいくつかの拡張された printf クラスがあり、printf("word %1s and %2s",var1,var2) などを指定できるため、必要に応じて %1s と %2s を切り替えることができます。

于 2008-10-24T02:41:19.710 に答える
1

意見は自由なので、私のやり方はこうです。

ローカライズされたテキスト ファイルは、Excel に読み込んで編集できる単純なタブ区切りのテキスト ファイルです。最初の列は定義用で、右側の各列は後続の言語です。次に例を示します。

ID              ENGLISH      FRENCH    GERMAN
STRING_YES      YES          OUI       YA
STRING_NO       NO           NON       NEIN

次に、makefile には、strings.h ファイルと strings.dat を生成するカスタム ビルド ステップがあります。私の場合、文字列 ID の列挙リストを作成し、テキストのオフセットを含むバイナリ ファイルを作成します。私のアプリでは、ユーザーはいつでも言語を変更できるため、それらはすべてメモリ内にありますが、必要に応じて、プリプロセッサで言語ごとに異なる出力ファイルを簡単に生成できます。

この設計で私が気に入っているのは、文字列が欠落している場合はコンパイル エラーが発生するのに対し、実行時に文字列が検索された場合は、コードのほとんど使用されない部分で文字列が欠落していることに後で気付く可能性があることです。

于 2008-10-09T02:25:13.070 に答える
1

これが Windows で通常どのように行われるかについてはよくわかりませんが、Apple のCocoa フレームワークでローカライズされた文字列が処理される方法はかなりうまく機能します。これらには、翻訳者に送信できる非常に基本的なテキスト形式のファイルと、ファイルから値を取得するためのいくつかのプリプロセッサ マクロがあります。

コードでは、文字列が不透明な ID ではなく、母国語で表示されます。

于 2008-10-08T23:20:14.833 に答える
1

あなたのソリューションは、Unix/Linux の " " ソリューションと非常によく似ていgettextます。実際、抽出ルーチンを作成する必要はありません。

_RESTRING マクロで複数の引数を処理する理由がわかりません。私のコード (wxWidgets の gettext のサポートを使用) は次のようになりますMyString.Format(_("Some string with variable %ls"), _("variable"));。つまり、String::Format(...) は 2 つの個別に変換された引数を取得します。後から考えると、Boost::Format のほうがよかったのですが、それでも可能でした。boost::format(_("Some string with variable %1")) % _("variable");

(_()簡潔にするためにマクロを使用します)

于 2008-10-10T15:13:35.050 に答える
0

あなたは、私がいつも書きたいと思っていたが、時間がなかった高度なユーティリティが欲しい. そのようなツールが見つからない場合は、リソース テーブルから文字列を非常に簡単に取得できる CMsg() および CFMsg() ラッパー クラスにフォールバックすることをお勧めします。(CFMsg は FormatMessage ワンライナー ラッパーも提供します。そうです、探しているツールがない場合は、文字列のコピーをコメントに保持するのが良い解決策です。コメントの非同期化に関しては、文字列リテラルはめったに変更されません。

http://www.codeproject.com/KB/string/stringtable.aspx

ところで、ネイティブの Win32 プログラムと .NET プログラムでは、リソース ストレージの管理がまったく異なります。両方に共通の解決策を見つけるのは難しいでしょう。

于 2008-10-09T18:45:24.450 に答える
0

10 以上の言語にローカライズしたあるプロジェクトでは、ローカライズするすべてのものを単一のリソースのみの dll に入れました。インストール時に、ユーザーはアプリケーションと共にインストールされる dll を選択しました。

英語版の dll をローカリゼーション チームに渡すだけで済みました。彼らは、私がビルドに含めた言語ごとに、ローカライズされた dll を私に返しました。

完璧ではないことはわかっていますが、うまくいきました。

于 2008-10-08T23:16:52.063 に答える