.resxvsデータベースvsローカリゼーション/グローバリゼーションを提供するためのカスタムソリューション
私のオフィスでは、ローカリゼーション/グローバリゼーションとその処理方法について長年の議論がありました。一方はASP.NETに組み込まれているリソース（.resx）ファイルルートをプッシュし、もう一方はデータベース駆動型ソリューションをプッシュします。 3番目のグループは、カスタムソリューションのローリングを信じています。
もちろん、それぞれの方法には独自の長所と短所があります。実際の合意に達することなく、何度も何度も議論してきました。
それで、私はそれをコミュニティに提起します：あなたの経験では、アプリケーションが成長するにつれて、どの方法が以下の最良の組み合わせを提供しますか？
- 保守性
- 拡張性
- パフォーマンス/スケーラビリティ
単なるアドバイスに加えて、質問を単純化するのに役立つ可能性のあるオープンソースプロジェクトにも関心があります。ありがとう！
Rick Strahl（MS MVP）には、DBを介してローカリゼーションを管理するための優れたツールキットがあります。制御された環境を通じてオンデマンドで更新および変更する機能を提供し、手間のかかる作業の多くを実行します。 Histoolkitは次の機能を提供します。
データドリブンローカリゼーションリソースプロバイダー
- データベース駆動型ローカリゼーションを使用すると、SQLServerデータベースにリソースを格納できます。
- インタラクティブなWebベースのリソース管理は、アプリの実行中にリソースを編集および更新できるライブWebベースの管理を提供します
- リソース編集コントロールは、アイコンをローカライズ可能な各コントロールに関連付け、現在のリソースIDとロケールが選択された状態で管理フォームに直接ジャンプできるようにします。
- Resx Import and Exportを使用すると、既存のResxリソースをインポートし、データドリブンプロバイダーでインタラクティブに編集してから、Resxリソースとしてエクスポートして戻すことができます。
- JavaScriptリソースハンドラーなどのローカリゼーションユーティリティ、ローカライズされたスクリプト値を埋め込む関数など。
彼はまた、問題を非常にうまく要約しています ここ （私はここにいくつかの良いビットを貼り付けました-私自身の仕事ではありません！）
Resxするかしないか
.NETのデフォルトのリソースストレージメカニズムは、Resxベースのリソースを使用します。 Resxは、.NETにネイティブなリソースの生の入力として機能するXMLファイルのファイル拡張子を指します。 XMLは、Visual Studioおよび.Resxファイルに表示される入力ストレージ形式ですが、最終的なリソース形式は、コンパイラーによって.NETアセンブリにコンパイルされるバイナリ形式（.Resources）です。これらのコンパイル済みリソースは、コードと一緒にバイナリアセンブリに保存することも、リソースを提供することを唯一の目的とするリソースサテライトアセンブリに単独で保存することもできます。通常、.NETでは、不変のカルチャリソースは、カルチャ固有のサブディレクトリに格納されているサテライトアセンブリに格納されている他のカルチャとともにベースアセンブリに埋め込まれます。
Visual Studioを使用している場合、リソースのコンパイルプロセスはほぼ自動です。プロジェクトに.Resxファイルを追加すると、VS.NETはリソースを自動的にコンパイルしてアセンブリに埋め込み、必要なディレクトリ構造とともにサテライトアセンブリを作成します。サポートされている各ロケール。 ASP.NET 2.0は、リソースサービスモデルをさらに自動化し、App_GlobalResourcesおよびApp_LocalResourcesで見つかったResxリソースを自動的にコンパイルし、ASP.NETに固有のリソースプロバイダーを使用してアプリケーションで利用できるようにすることで、この基本プロセスを拡張します。リソースプロバイダーは、ASP.NETアプリ内からのリソースアクセスをより簡単かつ一貫性のあるものにします。
.NETフレームワーク自体は.Resxリソースを使用してローカライズされたコンテンツを提供するため、フレームワークが提供するツールによって、この同じモデルを提供するためのリソース作成ツールが利用可能になるのは当然のことのようです。
Resxは十分に機能しますが、実際にリソースを編集する場合はあまり柔軟性がありません。 VSは複数のロケール間でリソースを相互参照する簡単な方法を提供しないため、VisualStudioでのツールサポートはローカリゼーションをサポートするには実際にはまったく不十分です。また、ASP.NETのデザインエディターは、[ローカルリソースの生成]ツールを使用して、ページ上のすべてのコントロールのリソースを最初に生成するのに役立ちますが、デフォルトのInvariant CultureResxファイルのデータでのみ機能します。
Resxリソースも静的です-結局、それらはアセンブリにコンパイルされます。リソースに変更を加える場合は、それらの変更を確認するために再コンパイルする必要があります。 ASP.NET 2.0には、サーバーに格納でき、動的に更新できるグローバルリソースとローカルリソースが導入されています。ASP.NETコンパイラは、実際に実行時にそれらをコンパイルできます。ただし、プリコンパイルされたWebデプロイメントモデルを使用する場合、リソースは静的であり、実行時に変更することはできません。したがって、コンパイルが完了すると、リソースが修正されます。
実行時にリソースを変更することは大したことではないように思われるかもしれませんが、リソースのローカリゼーションプロセス中には非常に便利です。実行時にリソースを編集し、変更を加えて、実際にその変更をUIですぐに確認できたら素晴らしいと思いませんか？
データベースリソースの使用
これにより、リソースをデータベースに保存することができます。データベースは本質的により動的であり、アプリケーションを再コンパイルしなくてもデータベース内のデータに変更を加えることができます。さらに、データベースデータは複数の開発者やローカライザー間でより簡単に共有されるため、チーム環境でリソースを簡単に変更できます。
リソースの編集について考えるとき、それは基本的にデータ入力タスクです。個々のリソース値を調べ、さまざまな言語のバリエーションをすべて確認してから、さまざまなロケールごとに値を追加して編集する必要があります。これはすべて、ResxファイルのXMLを使用して直接行うことができますが、実際には、XMLファイルがいたるところに散らばっているよりもデータベースのフロントエンドを構築する方がはるかに簡単です。データベースを使用すると、リソースデータをさまざまなビューで表示する柔軟性が大幅に向上し、バッチ更新やキーと値の名前変更などを簡単に実行できます。
幸いなことに、.NETのリソーススキームは固定されておらず、拡張することができます。 .NETおよびASP.NET2.0を使用すると、カスタムリソースマネージャー（コア.NETランタイム）およびリソースプロバイダー（ASP.NET 2.0）を作成して、データベース外を含むどこからでもリソースを提供できます。
ご存知かもしれませんが、.Netアプリケーションをローカライズするためのデフォルトの方法（実際には業界のベストプラクティス）は、リソースファイル（この場合は.resx）を使用しています。データベースを使用する場合は、独自のResourceManagerを作成する必要があります。
このことから、答えは明白であるはずです。標準を使用し、車輪の再発明をしないでください。
リソースファイルを介したローカリゼーションが業界全体の標準になった理由を疑問に思われるかもしれません。さて、多くの理由があります（ここで言及するには多すぎます）、それらのほとんどはローカリゼーションプロセスに関するものです。重要なのは、データベース駆動型ローカリゼーションの翻訳を更新（修正またはインストール）するのが非常に難しいことです。それをインストールするために必要なもの、つまりSQLスクリプトについて考えてみてください。これを翻訳のために送るとどうなるか知っていますか？それとも誤って更新しますか？これらの種類のファイルは安全に操作できないため（非常に大きくなる傾向があります）、何らかのジェネレーターを作成する必要があります（リソースのようなファイルを入力として使用すると、目的が完全に失われます... ）または、非常に注意する必要があります（そして、翻訳者がファイルを壊さないように祈ってください）。
つまり、データベース駆動型のローカリゼーションが唯一の賢明な方法である場合があります。これは、ユーザーが複数の言語で物事を翻訳したりコンテンツを追加したりできる、いわゆる動的ローカリゼーションを実装する必要がある場合です。
静的ローカリゼーション（一般的なシナリオ）の場合は、リソースファイルを使用します。
resxを使用することは、アプリのUIを介して操作する必要がない一部の静的な値に最適なアプローチですが、値を更新する必要がある場合は、DB駆動型が最適です。私にとっては、それでもケースバイケースです。しかし、私がインターネットで見たブログの1つは、resxファイルをユーザーインターフェイスを介して更新可能にしました。 http://sandblogaspnet.blogspot.com/2009/11/updating-resource-file.html 。 。これがお役に立てば幸いです。
ローカライズユーザーインターフェイスはデータベースに保存しないでください。標準のresxメソッドを使用することをお勧めします。これにより、バックエンドやストアを変更することなく、クライアント/展開ごとにフロントエンドのユーザーインターフェイスを柔軟にカスタマイズできます。データベース内の各クライアントのカスタマイズに関する多くのデータ。
データ（バイリンガルデータまたはマルチリンガルデータ）については、データベースに保存し、コンテキストに適した手法（言語ごとのテーブル、または言語ごとの重複列）を使用します。
上記のすべてが当てはまるので、いくつかの洞察を追加したいと思います。
特定のユーザーグループに焦点を当てたダッシュボードやその他の小さなWebサイトなどの "static"プロジェクト/ Webサイトで作業する場合は、.resxベースのローカリゼーションを使用する傾向があります。
ショップやサービス提供など、より大規模でより多くの "dynamic"プロジェクトに取り組む場合（特に、コンテンツがローカライズされる場合-ラベルだけでなく）、データベースのローカリゼーションを使用するのが好きです。
大規模なプロジェクトで開発している場合、各言語は、必ずしもプロジェクト（特にコミュニティプロジェクト）に参加しているとは限らない別の人によって維持されます。したがって、異なる言語の保守は非常に面倒になります。一方、ユーザーに言語を更新するための優れた/簡単なUIを提供することも、時間のかかる作業です。だからあなたのプロジェクトのための良い道を見つけるようにしてください。