1

.NET アプリケーションのローカライズに関する質問がここで何度も尋ねられたことを知っています。

しかし、大規模な .NET アプリケーションをローカライズするためにリソースとサード パーティのリソース編集ツールを使用するアプローチの有効性については疑問があります。

私は以下のアプローチのいずれかにとどまることを考えています：

  1. すべてのソリューション フォームに対して Localizable=True を設定し、サード パーティのリソース エディター (例: Zeta Resource Editor) を使用して、リソースを編集および管理します。短所:

    • 私たちのソリューションには最大 100 のフォームがあり、30 の追加言語には 30*100 = 3000 個の新しい resx ファイルがあります!
    • 翻訳者とやり取りするための多くの労力: 製品を更新するたびに平文の Excel ファイルを翻訳者に送信し、言語が変更されるたびにプロジェクト リソースを手動で更新する必要があります。
    • 翻訳者は製品のリリース後に作業を行う可能性があり、プロジェクトを再コンパイルしないと翻訳者の変更を含めることができないため、言語ファイルの一部 (ほとんど?) は常に古くなっています。

  2. カスタム Dictionary ベースのクラス (GNU GetText など) を使用して、翻訳を含む昔ながらの ini ファイルをロードします。短所: 翻訳者の ini ファイルを編集するためのヘルパー ツールを作成するなど、余分な作業が必要です。利点: 新しい言語バージョンは、製品のリリース後に別の ini ファイルとして公開される場合があります。

残念ながら、両方の方法のパフォーマンスを比較することはできません。

どちらのアプローチが優れていますか? あなたの経験を共有してください！

4

3 に答える 3

2

標準の .NET ローカリゼーション システム ( ) に固執する必要がありますResourceManager。

抱えている問題 (さまざまな言語の多数の .resx ファイルのソリューションへのインポートの管理、翻訳の配信の遅延への対処) に対処する 1 つの方法は、解決しますが、ローカリゼーションを有効にしておいてください。したがって、今後は、英語のリソースのみを使用してソリューションを構築しますが、サテライト アセンブリが存在する場合はそれを読み込むことができます。

次に、英語リソースのさまざまな言語への翻訳を管理することのみを目的として、別のプロジェクト (ローカリゼーション プロジェクトと呼びます) をセットアップできます。英語の resx ファイルをメイン ソリューションからローカリゼーション プロジェクトに定期的に同期する必要があります (ただし、これにより制御された方法でこれを行うことができ、翻訳者とのやり取りに役立ちます)。受け取った翻訳は、このプロジェクトのソース管理システムにチェックインされます。

次に、ローカリゼーション プロジェクトからサテライト アセンブリをビルドするための何かを記述し、それらを英語のみのビルドにドロップして、すべてのローカリゼーションを含むビルドを作成する必要があります。resx ファイルからサテライト アセンブリをビルドするには、Resgen.exe (.resources ファイルを作成する) とAl.exe (dll ファイルを作成する) を使用します。

于 2012-05-10T15:19:07.637 に答える
1

最初の列にキーがあり、言語ごとに 1 列の大きな Excel ファイルを使用します。Excel ドキュメント内の小さなスクリプトは、必要な resx ファイル (言語ごとに 1 つ) を吐き出し、これらの resx ファイルはソース ツリーにチェックインされます。

翻訳アセンブリのみがサテライト アセンブリを持ち、アプリケーション全体の翻訳を処理します。したがって、他のすべてのアセンブリ (UI など) にはサテライト アセンブリはありません。

フォームでは、キーを (ラベル、ボタン、キャプションの) テキストとして使用し、フォームが表示されるときに再帰的に翻訳します。コントロール以外のテキストの場合、単一の静的クラスを使用して、コードでリソース キーが指定された翻訳済みテキストを取得します。

この「単一ファイル」の翻訳データベースは非常にうまく機能します。翻訳者はおそらく既にインストール済みで使い慣れているため、Excel を使用すると便利です。

于 2012-05-10T15:25:56.760 に答える
0

もちろん、ここで話題を逸らしたくはありませんが、実行する必要があることを実行するスクリプトは、合理的な定義から見て単純または自明ではありません。関連する問題はあまりにも広範です。最も些細なスクリプトでさえ、書くコストは、本格的な翻訳アプリを購入するコストをはるかに超えます. そして、そのアプリはほぼ確実に、スクリプトよりもはるかに多くのことを実行します (重要な機能のみを参照する場合でも)。

于 2012-05-11T21:33:05.350 に答える