リソース ファイルは、ラベルやメッセージのローカライズに適しているように見えますが、完璧なのでしょうか?
例えば：
1. 大量のリソースがある場合、より良い解決策はありますか? .resx ファイル内の 100,000 個の文字列のように? （理論的には、実際にはこの問題はありません）
Java プロジェクトの代替コンテンツ リポジトリとして Alfresco を使用しました。RESX ファイルは、メンテナンスの観点から (私が推測するエンコーディングの問題のため)、本当に悪臭を放つ可能性があります。
2. これは、画像、アイコン、オーディオ ファイル、通常のファイルなど、他の種類のデータを保存するのに適した方法ですか?
画像で動作するのを見てきましたが、それだけです。(他のメディア/ファイルについては不明)
3. 更新やコンパイルを容易にするために、.resx ファイルをスタンドアロン プロジェクトに保存することはベスト プラクティスですか?
私はしませんが、ライブ サイトで resx ファイルを編集することはできます。確かにそれは開発中の仕組みです（グローバルresxを除いて、私は思います）
4. .resx ファイルを使用する際に遭遇したその他の問題はありますか?
維持するのが本当に面倒なことに加えて、ビジュアルスタジオはそれらを操作するための最も優れたツールを提供していないという事実...いいえ。
比較的大きな .NET Windows Forms アプリケーション (500 を超えるさまざまなフォーム、フォームごとに約 20 のリソース文字列) でリソース ファイルを使用してきましたが、.resx ファイルのリソースに関してパフォーマンスの問題はありませんでした。翻訳を管理するためのツールとして、Babylon.NET を使用しています (翻訳者専用の無料バージョンがあります)。プロジェクトが Web アプリケーションかデスクトップ アプリケーションかを指定していません。リソース ファイルがデスクトップ アプリケーションに提供する機能の 1 つは、コントロールの位置とサイズをローカライズする機能です。これは、他のツールでは不可能です (自動サイズ変更機能を持つ DevExpress レイアウト コントロールのようなものを使用している場合を除く)。
私はリソース ファイルに関して 2 つの問題を抱えていました。どちらも、文字列検索の速度ではなく、翻訳者(人) のパフォーマンスに関するものです。
翻訳者を担当した統括オフィスの営業スタッフは、XML の編集や新しいツールの学習に対応できませんでした。
そのため、彼らは翻訳を編集するために Excel を使用しただけです。したがって、翻訳された文字列を CVS ファイルとして保存して、翻訳された文字列をリソース ファイルにコピーする必要がないようにすることもできます。
翻訳の効果を確認するには、新しいビルドを行う必要があります。
ここでも、翻訳された文字列が CSV ファイルとして保存されていれば、ASP.NET キャッシュにキャッシュできました。その後、翻訳に対する変更は、次のページの読み込み時に表示されます。
したがって、リソース プロバイダーのカスタム実装を使用して、標準の ASP.NET リソース ルックアップ システムを維持することもできます。または、標準のリソース ルックアップ システムが役に立たない場合は無視してください。ページの作成方法によって異なります。
ある時点で、単一の customerの文字列を上書きできるようにしたい場合があるかもしれません。その場合、多段階のルックアップ システムが必要になります。そうしないと、新しいバージョンのシステムを出荷するたびに、顧客のカスタム文字列を翻訳済み文字列とマージする必要があります。
ポイント＃4の場合。
私は、多くの言語にローカライズする必要があり、それらに大きな問題がない、サイト上のすべての文字列に.resxファイルを使用しています。
このテキストを検索可能にするかどうかを検討する必要があります。私が取り組んでいるサイトの中には、検索可能である必要があるローカライズされたリソースがいくつかあるため、それらをデータベースに保持する必要があります。ただし、選択肢がある場合は、上記と同様の理由で.resxファイルを使用します。
リソースをデータベースに格納するには、リソース プロバイダー (メンバーシップ プロバイダーのようなプロバイダー モデル) のカスタム実装を探す (または所有している) 必要があることを簡単に付け加えておきます。それが私たちが CMS で行ったことであり、非常に便利です。
最初に例を探したとき、Creating a Data Driven ASP.NET Localization Resource Provider and Editorを見つけました。
リソースファイルに関する私の見解は次のとおりです。
大量の文字列がある場合、データベースを使用することがデータの検索と並べ替えを可能にする最良の方法であると思います。リソーステーブルで複数の言語を説明することはおそらくそれほど難しくなく、速度は最高に速いはずです.
これは、静的リソース、またはクライアントによって変更される可能性のあるものを格納するのに適した方法だと思います。動的リソースに関しては、データベースを単独で使用するか、ファイル システムと組み合わせて使用する方がよい場合があります。新しい SQL Server には、データベースとファイル システムを使用する最適なハイブリッドである新しいタイプがあると思います。
リソースが変更されたときにプロジェクト全体を再コンパイルする必要がないため、外部プロジェクトでリソースファイルを使用することは良い習慣であるという別の質問を読みました（どちらかわかりません）。リソース プロジェクトを再コンパイルするだけです。これにより、クライアントが (かなり) 簡単に編集できるようになり、リソース プロジェクトの "ソース コード" のみが必要になり、他の実際のコード (API コードなど) は不要になります。
リソース ファイルの信頼性、拡張性、またはそれらを使用する際に発生する可能性のある問題について主張できるほどリソース ファイルを使用していません。
カスタム正規表現言語を使用してプロキシを通過するときに文字列を置き換える以前のプロキシ サーバーをダンプした後、.net カミソリ ページ アプリでリソース ファイルを使用しています。
プロキシ メソッドは、大きな文字列 (段落) により適していて、すべての動的なフラグメントやものにはかなり扱いにくいため、破棄しました。
まったく問題はなく、これまでのところプロキシ サーバーよりも高速です。すべてのターゲット ページ、コメント、名前、en、およびその他の使用可能なすべての言語を DB に保存します。簡単なことで、新しい言語の新しい列を追加します。
これまでに、複数の resx ファイルに約 5,000 のエントリがあります
次に、ビルダー プロセスを使用してすべての resx ファイルを作成し、何かが更新されるたびに正しいローカル フォルダーとグローバル フォルダーに配置します。
翻訳者がページ、言語、コメント、名前などを検索して更新するためのシンプルなインターフェースを非常に簡単に構築できます。変更時にresxファイルを自動再構築しないことを選択しましたが、翻訳者を信頼していれば可能です;)
また、翻訳者が翻訳する新しいフラグメント/テキストを追加することもできますが、それらを自動的に含める方法についての明るいアイデアはまだありません。ソース ファイル内の文字列を手動で置き換えて再コンパイルする必要があります。
resx ファイルの編集には、ゼータを使用しました。
https://www.zeta-resource-editor.com/index.html
これにより、すべての言語を一度に開くことができ、プレースホルダーの違いや欠落している翻訳が強調表示されます。すべての言語を 1 行で編集し、すべてのファイルを一度に保存できます。すべてがDBにあるため、現在は使用していませんが、推奨しています。