MVC 2：完全なローカリゼーションガイド

この記事では、ASP.NET MVCに基づいてWebアプリケーションをローカライズするすべての側面を検討します。 このトピックの執筆時点では、最新のMVC 2 RC 2バージョンを使用しています。



始める前に、MVCチームに感謝したいと思います。すばらしい仕事をしてくれた皆さん、このフレームワークを使用するときにWebアプリケーションを作成するプロセスを楽しんでいます。 Ruby on Railsで少し経験した後、このタイプのフレームワークを探していました。



次の問題を検討します。

1. 検証を表示
2. シンプルな作物切り替えメカニズム
3. モデル検証メッセージのローカライズ
4. DisplayName属性のローカライズ
5. キャッシュとローカリゼーション

作業するには、Visual Studio 2008 ExpressとASP.NET MVC 2 RC2が必要です。また、新しいMVC 2 Webプロジェクトを作成する必要があります。

ローカライズを表示

もちろん、ローカライズされたテキストの場合、リソースファイルが使用されますが、ストレージには標準のasp.netフォルダーは使用されません。



次のディレクトリ構造をお勧めします。







ビュー -aspxページのリソースファイル。 モデル -ビューモデルをローカライズするためのリソースファイル。



Viewsディレクトリには、リソースファイルが配置されている各コントローラーのサブフォルダーが含まれています（ファイルの数は、サポートされている言語のセットによって異なります）。



モデルには、ビューモデルの各グループのサブディレクトリが含まれます。 生成されたアカウントモデル（LogOn、Register、ChangePassword）には、各言語カルチャのAccountフォルダーとリソースファイルがあります。

リソースファイル

リソースファイルの命名規則に関するいくつかの言葉。 リソースファイルの名前の形式は次のとおりです。

[リソース名]。[文化] .resx



リソース名-ファイル名。 絶対に何でも構いません。 同じリソース名を持つ複数のリソースファイルがある場合にグループ化するために使用されます-それらはCULTUREで指定された異なるカルチャを持つ単一のリソースを構成します。



CULTURE-リソースファイルカルチャのインジケータ。 文化には、 中立と正確の 2つのタイプがあります。 ニュートラルカルチャは、言語コード（ en 、 ru 、 deなど）のみで構成されます。 正確なカルチャは、言語コードと地域コードで構成されます（ en-US 、 en-UK ）



また、カルチャが定義されていないリソースファイルには特別な意味があり、「デフォルト」または「フォールバック」カルチャと呼ばれます。 名前から推測できるように、特定のカルチャリソースファイルでテキストが見つからなかった場合、または特定のカルチャのファイルがない場合、リソースファイルに使用されます。 特にユーザーがサポートされていないカルチャを何らかの方法でインストールできる場合は、基本的なリソースファイルを使用することを強くお勧めします。



リソースファイルのいくつかの例：



MyStrings.en-US.resx-英語アメリカ



MyStrings.en-UK.resx-イギリス英語



MyStrings.en.resx-ニュートラル英語（英語のデフォルト）



MyStrings.ru.resx-中立ロシア語



MyStrings.resxはベースリソースファイルです。



これで、何かをローカライズして、それがどのように機能するかを確認する準備ができました。 作成されたWebアプリケーションでのヘッダーのローカライズの小さな例を示します。 この例では、英語（デフォルト）と中立ロシア語の2つの言語を使用しますが、他の言語も使用できます。



まず、フォルダー構造を作成します。上記で説明したように、Site.Masterの親ページのリソースファイルが必要になります。 Resources \ Viewsに 共有ディレクトリを作成し、2つのリソースファイルを追加します。



SharedStrings.resx-英語のデータを含む基本的なリソースファイル。



SharedStrings.ru.resx-ロシア語のデータを含む基本的なリソースファイル。



両方のファイルに「タイトル」プロパティを追加して入力します。







重要！ 各リソースファイルのアクセス修飾子がpublicに設定されていることを確認します。 また、リソースツールにPublicResXFileCodeGeneratorのカスタムツールプロパティ値があることを確認します。 そうしないと、リソースファイルはコンパイルされず、利用できません。











リソースファイルの名前空間について少し説明します。 この方法で作成されたファイルには、次の形式の名前空間があります。



[プロジェクト名] .Resources.Views.Shared



読みやすさと命名規則への準拠を改善するために、リソースファイルのカスタムツール名前空間プロパティをViewRes （ビューリソースファイル用）に変更しました。



Site.Masterページに変更を加えるときが来ました。

< div id ="title" >



< h1 > My MVC Application </ h1 >

</ div >

に置き換える

< div id ="title" >



< h1 > <% =ViewRes.SharedStrings.Title %> </ h1 >



</ div >

アプリケーションを実行して、すべてが正常に機能し、ヘッダーが正しい場所に表示されることを確認します（リソースファイルから読み取る必要があります）。 すべてがうまくいったら、文化を変える方法を示しましょう。



カルチャを変更するには、リクエストごとに CurrentThreadオブジェクトのCurrentCultureおよびCurrentUICultureプロパティを変更する必要があります!!! これを行うには、カルチャを変更するコードをApplication_AcquireRequestState Global.asaxメソッドに配置します（このメソッドはイベントハンドラーであり、リクエストごとに呼び出されます）



Global.asax.csファイルに次のコードを追加します。

protected void Application_AcquireRequestState( object sender, EventArgs e)

{

//Create culture info object

CultureInfo ci = new CultureInfo( "en" );



System.Threading.Thread.CurrentThread.CurrentUICulture = ci;

System.Threading.Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(ci.Name);

}



アプリケーションを再度起動し、機能することを確認します。 次に、CulturInfoコンストラクターの文字列パラメーターを変更し（私の場合は「ru」になります）、プロジェクトを再起動します。 次のものが必要です。











以上です。 Site.Masterヘッダーをローカライズしたため、任意のテキストでこれを行うことができます。

シンプルな作物切り替えメカニズム

前の章では、アプリケーションタイトルのローカライズに成功しましたが、リアルタイムでカルチャを変更する方法はありませんでした。 次に、文化的環境をリアルタイムで制御するのに役立つ何らかのメカニズムを作成します。



ユーザーが選択したカルチャのリポジトリ、セッションオブジェクトを使用します。 文化を変えるために、各言語のリンクをマスターページに配置します。 リンクをクリックすると、アカウントコントローラーでアクションが発生し、セッション値が適切なカルチャに変更されます。



次のコードをAccountControllerクラスに追加します。

public ActionResult ChangeCulture( string lang, string returnUrl)

{

Session[ "Culture" ] = new CultureInfo(lang);

return Redirect(returnUrl);

}

これで、2つのパラメーターを持つアクションメソッドが作成されました。1つ目はカルチャコード、2つ目はユーザーを元のページにリダイレクトするためのアドレスです。 セッションコレクションに新しいカルチャを設定する必要がありますが、サポートされていないカルチャのインストールを防ぐために、受信したユーザーデータのチェックを追加することを忘れないでください。



次に、文化的な参照を含む単純なユーザーコントロールを作成します。 Views \ Sharedディレクトリに新しい部分ビューを追加し、ファイルにCultureChooserUserControl.ascxという名前を付けて、次のファイルを貼り付けます。

<% = Html.ActionLink( "English" , "ChangeCulture" , "Account" ,

new { lang = "en" , returnUrl = this .Request.RawUrl }, null ) %>

<% = Html.ActionLink( "" , "ChangeCulture" , "Account" ,

new { lang = "ru" , returnUrl = this .Request.RawUrl }, null ) %>



そこで、2つのリンクを作成しました。1つは英語用で、2つ目はロシア語用です。 Site.Materページにこのコントロールを配置するときが来ました。 ログインフォームの横に追加します。



<div id = "logindisplay">コードを見つけて次のコードに置き換えます。

< div id ="logindisplay" >

<% Html.RenderPartial( "LogOnUserControl" ); %>

<% Html.RenderPartial( "CultureChooserUserControl" ); %>

</ div >

他に何をする必要がありますか？ そして、最も重要なことは残っています。私たちは文化に関する情報のオブジェクトをセッションに配置しますが、それをどこにも使用しません。 Global.asax.csファイルメソッドApplication_AcquireRequestStateを再度変更します。

protected void Application_AcquireRequestState( object sender, EventArgs e)

{

//

if ( HttpContext .Current.Session != null )

{

CultureInfo ci = (CultureInfo) this .Session[ "Culture" ];

// ,

//

//

if (ci == null )

{

// -

string langName = "en" ;

// HTTP

if ( HttpContext .Current.Request.UserLanguages != null && HttpContext .Current.Request.UserLanguages.Length != 0)

{

//

langName = HttpContext .Current.Request.UserLanguages[0].Substring(0, 2);

}

ci = new CultureInfo(langName);

this .Session[ "Culture" ] = ci;

}

//

Thread.CurrentThread.CurrentUICulture = ci;

Thread.CurrentThread.CurrentCulture = CultureInfo.CreateSpecificCulture(ci.Name);

}

}

アプリケーションを起動すると、次のページが表示されます。リンクをクリックすると、選択したカルチャでページがオーバーロードされます。

モデル検証メッセージのローカライズ

Phil Haackが発行したこの問題に対する優れた解決策を見つけましたが、この記事は完全なガイドであるため、この問題に触れざるを得ず、明確にしたい特定の曖昧さもあります。 しかし、まず第一に、 Phil Haackの投稿を読むことをお勧めします



アカウントモデル、特にRegistrationModelの検証メッセージをローカライズする方法を説明します。 また、AccountControllerコードに直接記述されたメンバーシップ検証メッセージをローカライズする方法についても説明します。



そこで、 Resources \ Models \ AccountフォルダーにValidationStrings.resxとValidationStrings.ru.resxを作成しましょう（アクセス修飾子がパブリックであることを確認してください）。 ご想像のとおり、これらのファイルに検証メッセージを保存します。



両方のファイルに次のプロパティを作成しました（英語の例）：







モデルを次のように変更する必要があります（RegisterModelの例）：

[PropertiesMustMatch( "Password" , "ConfirmPassword" ,

ErrorMessageResourceName = "PasswordsMustMatch" ,

ErrorMessageResourceType = typeof (ValidationStrings))]

public class RegisterModel

{

[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[DisplayName( "Username" )]

public string UserName { get ; set ; }

[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.EmailAddress)]

[DisplayName( "Email" )]



public string Email { get ; set ; }

[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[ValidatePasswordLength(ErrorMessageResourceName = "PasswordMinLength" ,ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.Password)]

[DisplayName( "Password" )]

public string Password { get ; set ; }



[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.Password)]

[DisplayName( "Confirm password" )]

public string ConfirmPassword { get ; set ; }

}

ErrorMessageResourceNameプロパティとErrorMessageResourceTypeプロパティをRequired 、 PropertiesMustMatch、 ValidatePasswordLength属性に追加します。ここで、 ErrorMessageResourceTypeはメッセージが保存されるリソースクラスのタイプで、 ErrorMessageResourceNameはプロパティの名前です。 残念ながら、プロパティを読み取るための厳密に型指定されたバージョンはありません。したがって、これらの魔法の行が正しい値を持っていることを確認してください。



私たちはほとんどそこにいます、詳細はまだ残っています。 独自の検証属性PropertiesMustMatchAttributeおよびValidatePasswordLenghtAttributeが2つあり、 FormatErrorMessageメソッドのCultureInfo.CurrentUICultureをCultureInfo.CurrentCultureに変更する必要があります。変更しない場合、何も機能しません。



アプリケーションを起動し、登録ページに移動し、カルチャを変更するための言語を選択し、空のフォームを送信するときにおよそ以下を取得します。







ああ、お気づきのように、プレゼンテーションモデルのプロパティ名をローカライズするのを忘れて、少し混乱しました。 これを行うには、DisplayName属性の値をローカライズする必要がありますが、それは一見したほど簡単ではありません。 これについては次の章で説明しますが、残りの詳細は終了しましょう。 これは、Membership APIの検証メッセージのローカライズです。



AccountControllerを開いてファイルの末尾に移動すると、ErrorCodeToStringメソッドが存在するはずです。このメソッドは、ユーザー登録が失敗した場合にエラーメッセージを作成します。 すべてのメッセージはコードにハードコーディングされています。 必要なのは、既に作成されたValidationStringsリソースファイル内の各メッセージに適切なプロパティを作成し、ErrorCodeToStringメソッド内のテキストの代わりにそれらを配置することだけです。



検証モデルはこれですべてです。 DisplayNameの時間です！

DisplayName属性のローカライズ

前の章で述べたように、DisplayName値は、フォーマットにパラメーターを使用する検証メッセージに含まれます。 DisplayName属性について考えるもう1つの理由は、HTMLフォームのテキストフィールドラベルです。これらはDisplayName値の参加によって作成されます。



本当の問題は、DisplayNameがローカライズをサポートしていないことです。これは、値を取得する場所からリソースファイルに関連付ける方法がありません。



これは、DisplayNameAttributeを拡張し、DisplayNameプロパティを書き換えて、ローカライズされた名前を返す必要があることを意味します。 継承クラスを作成し、LocalizedDisplayNameと呼びました。

public class LocalizedDisplayNameAttribute : DisplayNameAttribute

{

private PropertyInfo _nameProperty;

private Type _resourceType;



public LocalizedDisplayNameAttribute( string displayNameKey)

: base (displayNameKey)

{



}



public Type NameResourceType

{

get

{

return _resourceType;

}

set

{

_resourceType = value ;

// nameProperty, set'

_nameProperty = _resourceType.GetProperty( base .DisplayName, BindingFlags.Static | BindingFlags.Public);

}

}



public override string DisplayName

{

get

{

//,nameProperty null

if (_nameProperty == null )

{

return base .DisplayName;

}



return ( string )_nameProperty.GetValue(_nameProperty.DeclaringType, null );

}

}

}

重要な詳細は、要求されるたびにプロパティの値を読み取る必要があるという理解です。したがって、GetValueメソッドは、コンストラクターではなくDisplayNameプロパティのget'erで呼び出されます。



表示名を保存するために、 Resources \ Models \ AccountフォルダーにNames.resxおよびNames.ru.resxリソースファイルを作成し、次のプロパティを作成しました。







次に、DisplayName属性をLocalizedDisplayNameに置き換えて、リソースクラスのタイプを指定する必要があります。 変更されたRegisterModelコードは次のようになります。

[PropertiesMustMatch( "Password" , "ConfirmPassword" ,

ErrorMessageResourceName = "PasswordsMustMatch" ,

ErrorMessageResourceType = typeof (ValidationStrings))]

public class RegisterModel

{

[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[LocalizedDisplayName( "RegUsername" , NameResourceType = typeof (Names))]

public string UserName { get ; set ; }



[Required(ErrorMessageResourceName = "Required" ,ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.EmailAddress)]

[LocalizedDisplayName( "RegEmail" , NameResourceType = typeof (Names))]

public string Email { get ; set ; }



[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[ValidatePasswordLength(ErrorMessageResourceName = "PasswordMinLength" ,

ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.Password)]

[LocalizedDisplayName( "RegPassword" , NameResourceType = typeof (Names))]

public string Password { get ; set ; }



[Required(ErrorMessageResourceName = "Required" , ErrorMessageResourceType = typeof (ValidationStrings))]

[DataType(DataType.Password)]

[LocalizedDisplayName( "RegConfirmPassword" , NameResourceType = typeof (Names))]

public string ConfirmPassword { get ; set ; }



}

* This source code was highlighted with Source Code Highlighter .

アプリケーションを実行し、動作していることを確認してください。次のようになります。

キャッシュとローカリゼーション

奇妙な章ですよね？ キャッシングとローカリゼーションを組み合わせる方法を考えていますか？ OK、次のシナリオを想像してみましょう。HomeControllerを開き、OutputCache属性をIndexアクションメソッドに追加します。

[OutputCache(Duration=3600, VaryByParam= "none" )]

public ActionResult Index()

{

ViewData[ "Message" ] = "Welcome to ASP.NET MVC!" ;



return View();

}

アプリケーションを起動し、[インデックス]ページで言語を変更して、ヘッダーがまだローカライズされていることを確認します。



なんてこった！ キャッシングとローカリゼーションを一緒に使用することはできないとお考えですか？ 心配しないでください、この問題の解決策が存在します:)



OutputCacheについて何を知っていますか、VaryByCustomプロパティについて何を知っていますか？ それを使用する時間です。



インデックスページを初めて要求すると、OutputCacheがページをキャッシュします。 2番目のリクエスト（言語選択リンクをクリックしたとき）で、OutputCacheは何も変更されていないと判断し、キャッシュから結果を返すため、ページは再作成されません。 そのため、言語の選択が機能しませんでした。 この問題を解決するには、ページのバージョンが変更されたことを何らかの方法でOutputCacheに伝える必要があります（アクションが特定のパラメーターを受け取り、VaryByParamプロパティに渡す場合など）。



VaryByCustomはこの問題の解決策の理想的な候補であり、Global.asax.csファイルのSystem.Web.HttpApplicationクラスに特別なメソッドがあります。 このメソッドの標準実装を書き直します。

public override string GetVaryByCustomString( HttpContext context, string value )

{

if ( value .Equals( "lang" ))

{

return Thread.CurrentThread.CurrentUICulture.Name;

}

return base .GetVaryByCustomString(context, value );

}

まず、このメソッドはパラメーター値が「lang」（特別な値なし、VaryByCustomの値として使用される単純な文字列）に一致するかどうかを確認し、一致する場合は現在のカルチャの名前を返します。 それ以外の場合は、標準実装の値を返します。



次に、ローカライズを使用する各OutputCache属性に値「lang」を持つVaryByCustomプロパティを追加します。これがすべてです。 更新されたインデックスアクションメソッドは次のとおりです。

[OutputCache(Duration=3600,VaryByParam= "none" , VaryByCustom= "lang" )]

public ActionResult Index()

{

ViewData[ "Message" ] = "Welcome to ASP.NET MVC!" ;

return View();

}

もう一度アプリケーションを実行してみて、作業の切り替えを楽しんでください。



最後の章は終わりましたが、何も見逃していないことを願っています。