異なる言語(つまり、http://acme.com/en/faq、http://acme.com/de/faqなど)の別のURLを持つ多言語のASP.NET MVC3パワードサイトを実装します。ルーティングを使用したASP.NET MVCによるローカライゼーション
this articleの方法はまだASP.Net MVC3と一緒に行く方法ですか?
異なる言語(つまり、http://acme.com/en/faq、http://acme.com/de/faqなど)の別のURLを持つ多言語のASP.NET MVC3パワードサイトを実装します。ルーティングを使用したASP.NET MVCによるローカライゼーション
this articleの方法はまだASP.Net MVC3と一緒に行く方法ですか?
を変更するのではい、何もルーティングの観点から変更していない。
私はブログの著者のようにルートハンドラを使用していませんが、それは良い考えのようです。
私は通常、ルートにパラメータとして言語を追加します。
routes.MapRoute("someroute", "{language}/some/path/{p1}/{p2}",
new { controller = "SomeController", action = "SomeAction"});
あなたはルート定義上で右そこに言語のパラメータをデフォルトすることができますが、私は(それがでてくるユーザーがブラウザの設定で定義されていることを言語にデフォルトで指定しようとするので、私は通常、ベースコントローラでそれを行いますHTTPリクエスト)
ブログ記事に記載されているアプローチの1つは、主な「CurrentCulture」を変更することです。すべてのリクエストでメインの「CurrentCulture」を変更したくない場合は、「CurrentUICulture」を変更するだけです。メインの "CurrentCulture"を変更すると、サーバーの動作に影響を与えます。たとえば、データベースと会話するときには、ユーザーのカルチャーを使用しますが、それはおそらくあなたが望むものではありません。
人は主要なCurrentCultureを変更して日付と数字の書式を取得する傾向がありますが、これはいくつかの副作用があることを認識していません。代わりに、あなたの数とフォーマット機能に、ユーザーの文化に合格する必要がありますメインCultureThread(例えばsomeDate.ToString(フォーマット、文化)
グッドキャッチアップアップ –
HTTPヘッダーを受け入れるための+1 Accept-Language –
私はあなたの議論に変わりはありませんCurrentCulture:訪問者のカルチャーではないカルチャーに依存する処理があるあなたはそれを使用していますか? –