ローカリゼーション機能に組み込まれた.NETで遊んでいますが、それらはすべてresxファイルにデータを入れることに依存しているようです。
しかし、ほとんどのシステムはデータベース駆動であるため、これに依存することはできません。では、この問題をどのように解決しますか？組み込みの .NET の方法がありますか、それとも SQL で変換テーブルを作成し、すべて手動で行いますか? また、ほとんどのサイトでこれを行う必要がある場合、ローカリゼーションに resx を使用する理由はありますか?
たとえば、自分のサイトに FAQ リストがあります。このリストをデータベースに保持しているので、簡単に追加/削除できますが、データベースに入れることで、この情報を複数の言語に翻訳する良い方法がありません。 .
私の意見では、動的コンテンツ（FAQなど）のローカライズは、データベース内で行う必要があります。質問の保存方法によっては、おそらく「ロケール」列を作成し、データベースからFAQ質問を選択するときにそれを使用します。たくさんのテーブルをローカライズし始めたときに、これが非常にうまくスケーリングするかどうかはわかりません。
静的コンテンツ（フォームフィールドラベル、静的テキスト、アイコンなど）の場合、ファイルベースのリソースを使用すればおそらく問題ありません。ただし、本当に必要な場合は、これを処理できるカスタムリソースプロバイダーの実装を作成するのはそれほど難しくないようです。
関連するリンクは次のとおりです。
私はカナダに住んでいるので、多言語対応は大したことではありません。私は2つのアプローチを見てきました。最初のオプションは、特定のレコードのすべてのローカライズされたデータを別のテーブルに格納し、主キーとロケールによって元のテーブルにリンクすることです。2 番目のオプションは最初のオプションと似ていますが、ロケールごとに異なるテーブルがあり、ロケールがテーブル名の接尾辞として使用される点が異なります。
オプション A
Item (ItemID, ...)
ItemLocal (ItemID,LocaleID,....)
オプション B
Item (ItemID, ...)
Item_ENUS (ItemID,....)
Item_ENGB (ItemID,....)
Item_FR (ItemID,....)
私が最近考えた 3 番目のオプションは、データベースがそれをネイティブにサポートしていれば本当にいいと思いますが、すべてのローカルの値を同じフィールドに格納することです。また、フィールドが varchar-multilocal として設定されている場合は、言語を指定するパラメーターを渡してアクセスする必要があります。私が知っている限り、このようなものは存在しませんが、それは本当に物事をより簡単にし、より流動的にすると思います.
データ モデル内の特定のアイテムについて、説明部分をロケール ID 列 (LCID) を持つローカライズされたテーブルに分割します。
そのため、Product のテーブルには、実際には製品の説明や名前は含まれず、ハードで高速な値 (ProductId、EAN、NumberInStock、NextStockData、IsActive、IsPublished) などのみが含まれます。
ProductDescription には、ProductId、Name、Description、LCID が含まれます。
RESX ファイルと Kibbee の応答のオプション A を組み合わせて使用します。RESX ファイルをオンラインで管理するためのシンプルなツールを作成しました: http://blog.lavablast.com/post/2008/02/RESX-file-Web-Editor.aspx
現在、翻訳は自動的にできるものではありません。最良の方法は、誰かに翻訳してもらい、Nick の方法を使用して適切な言語を示すことです。