WCF サービスがあり、複数のクライアントが複数の言語であるとしましょう。リソース ファイルとサテライト アセンブリを使用して、ローカライズされたリソース文字列を提供することが適切です。
これらのリソース文字列がブランド化された場合、たとえば、同じ国、同じ言語の 2 つのクライアントが異なる用語を使用している場合、別のサテライト アセンブリを使用して別の resx ファイルを作成しますか、それとも何か不足していますか?
そのクライアントにブランド化されたサテライト アセンブリを追加すると、ブランド化されていないリソース文字列に多くの冗長性が生じます。しかし同時に、すべてのリソース文字列をブランド化できるようにする必要があります。
私たちは同じ問題に直面し（顧客は最初に提供された翻訳を適応させることができました）、衛星アセンブリは私たちの問題を解決しませんでした。リソースとアセンブリは、安定したコンテンツに適しています。
最終的に、これらすべてのリソース文字列をデータベースに保存し、アプリケーションの最初の起動時にそれらをロードしてキャッシュしました。
あるプロジェクトでこの問題に直面しました。リソース コンパイラへの入力ファイルと同じ形式の XML ファイルから文字列を読み取る独自のコードを作成することになりました。次に、顧客ごとに、順番に試す「メッセージ」ファイルのリストを用意しました。それを含む最初のファイルからのメッセージを使用しました。(リソース ファイル形式を使用すると、翻訳者は使い慣れたツールを使用できます。)
もちろん、これはすべて、メッセージ ファイルが初めてアクセスされた後、メモリ内のデータ キャッシュで行われました。