この質問には単純な答えがないように感じます。Cultureフォーマットとそうでないものについては、英国英語の場合は「en-GB」、米国英語の場合は「en-US」のようなものを常に使用する必要がありますUICulture（はい、違いがあります）。すべての .Net はそれを中心に構築されているため、特に考えなくてもローカル フォーマットを使用できます。
詳細については、System.Globalization 名前空間も確認してください:
http://msdn.microsoft.com/en-us/library/system.globalization%28v=vs.110%29.aspx
文化が由来するべきかどうかについては、少なくとも私たちの会社では、ポリシーは常にクエリ文字列から例外なくあります。その理由は、たとえば IP ローカリゼーションを使用している場合、スペイン語のユーザーが日本でスペイン語のサイトを見ていて、日本語版に切り替えられた場合、正確に間違っているわけではありませんが、それがスペイン語の直接リンクか何かであることをクライアントに伝えます。つまり、クエリ文字列でカルチャが定義されていない場合、IP を使用してユーザーが使用したい言語を推測することは悪い考えではありませんが、実際にはクライアントのニーズに依存します。
翻訳を取得する場合は、リソースと DB の両方に浮き沈みがあります。したがって、DB の主な利点は、アプリケーション間で簡単に共有できることと、何らかの理由でフレーズを更新する必要がある場合、1 つの DB エントリですべてを更新できることですが、これも欠点になる可能性があります。一部のフレーズには二重の意味があり、同じ文が英語で使用されていても、他の言語ではまったく異なる方法で翻訳できます。DB のもう 1 つの大きな問題は、ある程度 (ただし、これは実装によって異なります)、VS でフレーズのインテリジェンスが失われることです。
もちろん、リソースには適切なインテリジェンスがありますが、使用している Web アプリケーションに対してかなり静的であり、アプリケーション間でリソースを共有することはできません...正確にはそうではありませんが、多かれ少なかれ共有することはできません。その静的な性質もプラスですが、すべてのリソースがアプリケーション内に含まれており、外部の影響がアプリケーションに影響を与えないことがわかっているためです。
実際には、プロジェクトによって異なります。あなたは単にあなた自身の長所と短所に道を譲り、あなた自身で決める必要があります...申し訳ありません。しかし、少しでもお役に立てれば、私の会社の状況をお伝えできます。さまざまな Web アプリケーション全体で同じフレーズを共有するいくつかのアプリケーションを作成します。以前はデータベースにそれを持っていましたが、翻訳が配列され続けたということは、クライアントが 1 つのアプリについてスペイン語でより良い翻訳を求めたということでしたが、他のアプリではまったく意味がありませんでした。それはあなたが思っている以上に起こりました。次に、リソースに移動しましたが、そこで起こったことは、1 つのアプリの翻訳が更新されたときに、他のアプリを更新することを誰も覚えておらず、実際には 3 つの異なるアプリが同じ用語を 3 つの異なる方法で翻訳したということでした。結局、DBに戻ることにしました。
一般に、他にも長所と短所がありますが、上記と比較すると、それらはすべてかなり無関係です. 翻訳をどのように使用しているかを実際に尋ねる必要があります。一般的な編集 (上記の点を除く) については、補助アプローチも同様に機能し、両方のアプローチで翻訳を簡単に変更、編集、または拡張できます。
とはいえ、DB と DB 呼び出しの設計が不適切な場合は、リソースを使用して新しい言語を簡単に追加できます。リソース ファイルをコピーし、名前にカルチャ拡張を追加し、リソースに翻訳を追加するだけで完了ですが、繰り返しますが、完全に DB の設計にかかっているため、DB を設計する際に留意すべき点であり、DB に翻訳を保持することについてはほとんど何も言いません。
翻訳を共有する必要がある場合、DB には明らかな利点がありますが、概して、リソースは使いやすく、保守と拡張が非常に簡単です (そして、それらは既に .NET に組み込まれています)。したがって、推奨される方法はリソースを使用することだと言わざるを得ませんが、DBにはその場所があり、プロジェクトによって異なります。