私の現在のプロジェクトに, 一部のユーザーは旅行、世界の別の目的地に到着します。, 時に、便利なマシンを使用します。. ゲスト マシンの Windows を実行してインストールし、ローカルのロケール用に構成されました。. (私はちょうどゲスト マシンに適した言語パックいない可能性がありますを実現しました。… たぶん won't します。, 実際… 今のところは、1 つを駐車午前).
SharePoint は、ユーザーが各自の優先言語を選択して MOSS のユーザーは、MOSS をアクセスする方法に関係なく、その言語の名誉が、というメカニズムを提供する必要があります。. 他の言葉で, どんなブラウザーが IIS/モスを指示を無視して、代わりにその言語を見て、それを使用.
我々 は 2 つのアプローチを調査するつもりです。:
- HTTP ハンドラー: MOSS のユーザーのプロファイルを IIS にインストールされているカスタム HTTP ハンドラーになります, お好みの言語を把握し、間切りモスに制御を渡す前に、必要に応じての周り HTTP ヘッダー.
- global.asax: 同じことを行うに global.asax が変更します。. 我々 は何を変更可能性があります。, しかし、アイデアは、我々 がロケールの切り替えロジックを挿入することができますいくつかの場所を見つける.
他の複雑な要因は、私たちする必要があります 60 k のサポート ユーザー, について 1,000 同時にアクセスできるコケのピーク時の負荷します。.
HTTP ハンドラーは、かなり抜本的なと思われる, IIS レベルと全知ではないのでコードを配置する可能性がある最高の場所が、. それは仕事の良い 1 つの点.
我々 は global.asax 型アプローチに傾いています。, 私たちを信じているために主にその時点でデータをキャッシュするためのより多くのオプションがあります。.
さらに学習ブログこのテーマで多くをするよ.
ある場合このことについて何かを知っています。, コメントを投稿してください 🙂
</終了>
私は Twitter の上に従ってください。 http://www.twitter.com/pagalvin
Technorati のタグ: 多言語, SharePoint ソリューションの設計
私はテストしていないこの場合は動作かはよくわからないので.
Page クラスは、InitializeCulture() オーバーライドできるメソッド. あなたのカスタムの masterpage の背後にあるコードでこれを行う場合, 線に沿って何かを行うことができます。:
保護されたオーバーライドが無効に InitializeCulture()
{
// InitializeCulture 仮想メソッドをオーバーライドします() ユーザーの言語設定がプロファイルに含まれているかどうかをチェックするには
文字列の UserCulture = GetCultureFromUserProfile();
場合 ( UserCulture != "")
{
// プロファイルにユーザーの言語設定があります。: それに切り替える
Thread.CurrentThread.CurrentUICulture = 新しい CultureInfo(UserCulture);
Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(UserCulture);
}
}
このメソッドの実装にいくつかのキャッシュを構築することができます明らかに.
ソース: http://quickstarts.asp.net/QuickStartv20/util/srcview.aspx?path=~/aspnet/samples/localization/LocalizePers.src&ファイル = LocalizePers_cs\LocalizePers_cs.aspx&lang = C # ソース
HTTP ハンドラーは、以下のフローを考えています:
1. リクエストが来る, 言語の優先順位のセッション クッキーのためのクッキーを確認してください。 (セッション cookie は、ブラウザーを閉じたとき有効期限が切れる)
2. ASPX ページの要求が確認してください。, されていない場合, 要求をスキップします。
3. Cookie が存在する場合, 言語ヘッダーを指定された値に設定します。. あなたが行っています。!
4. ないクッキー, 認証資格情報を取るし、SPS のユーザーを調べる, 言語の優先順位を見つける
5. Cookie ヘッダーおよび言語の HTTP ヘッダーを設定します。. 行わ.
APX の最初のページ要求 SPS 参照のオーバーヘッドがすべての要求とその時からないルックアップ ネイティブ速度となりますので. セッション キャッシュまたはあまりにもセッション cookie を使用してその他のオーバーヘッドが不要. ブラウザーが閉じられた後, セッション cookie が消える. 彼らを閉じ、再度それを有効にするためのブラウザーを開く必要があるユーザーは SPS で彼らの言語好みを変更した場合.
http ハンドラーは、iis レベルではない実際に…アプリケーション レベルでは (ISAPI フィルターは IIS レベル)…紀元前 SP は独自のハンドラーを慎重になるだろう…必ずそれをテストするには…前にそれをやったが、持っていた SP ハンドラーといくつかの競合.
HTTPHandler を使用する傾向があるだろう, 唯一の理由は SharePoint のファイルに触れるか好まない. プラスそれは、HttHandler を展開する SharePoint ソリューションを作成する簡単です。 ( SPWebConfig API を使用して、web.config を変更). ユーザーの負荷を持っているか, かなりのファームがある想像するだろう, 本当にたくない変えたり各サーバー上のファイルを移動するには.
悪い考えはソリューション経由で global.asa ファイルを展開します。, それを撤回する場合, 元のファイルがなくなっています。 …
またソリューションをすぐに撤回する機能を持つ良いアイデアかもしれない, ハンドラーの perf を持つうまく行かない場合.