Merge pull request #6563 from softark/docs-guide-ja-update

docs/guide-ja update [ci skip]

Merge pull request #6563 from softark/docs-guide-ja-update
2e664764 · Alexander Makarov · 33101c05 · dce067ed · 2e664764 · 2e664764
Commit 2e664764 authored Dec 18, 2014 by Alexander Makarov
Show whitespace changes
Inline Side-by-side

Showing with 81 additions and 81 deletions

README.md docs/guide-ja/README.md +9 -9

input-validation.md docs/guide-ja/input-validation.md +72 -72

No files found.
--- a/docs/guide-ja/README.md
+++ b/docs/guide-ja/README.md
@@ -60,15 +60,15 @@ All Rights Reserved.
 鍵となる概念
 ------------

-* **翻訳中** [コンポーネント](concept-components.md)
-* **翻訳中** [プロパティ](concept-properties.md)
-* **翻訳中** [イベント](concept-events.md)
-* **翻訳中** [ビヘイビア](concept-behaviors.md)
-* **翻訳中** [構成情報](concept-configurations.md)
-* **翻訳中** [エイリアス](concept-aliases.md)
-* **翻訳中** [クラスのオートロード](concept-autoloading.md)
-* **翻訳中** [サービスロケータ](concept-service-locator.md)
-* **翻訳中** [依存注入コンテナ](concept-di-container.md)
+* [コンポーネント](concept-components.md)
+* [プロパティ](concept-properties.md)
+* [イベント](concept-events.md)
+* [ビヘイビア](concept-behaviors.md)
+* [構成情報](concept-configurations.md)
+* [エイリアス](concept-aliases.md)
+* [クラスのオートロード](concept-autoloading.md)
+* [サービスロケータ](concept-service-locator.md)
+* [依存注入コンテナ](concept-di-container.md)


 データベースの取り扱い

--- a/docs/guide-ja/input-validation.md
+++ b/docs/guide-ja/input-validation.md
@@ -4,8 +4,8 @@
 大まかに言うなら、エンドユーザから受信したデータは決して信用せず、利用する前に検証しなければならない、ということです。

 [モデル](structure-models.md) にユーザの入力が投入されたら、モデルの [[yii\base\Model::validate()]] メソッドを呼んで入力を検証することが出来ます。
-このメソッドは検証が成功したか否かを示す真偽値を返します。
-検証が失敗した場合は、[[yii\base\Model::errors]] プロパティからエラーメッセージを取得することが出来ます。
+このメソッドはバリデーションが成功したか否かを示す真偽値を返します。
+バリデーションが失敗した場合は、[[yii\base\Model::errors]] プロパティからエラーメッセージを取得することが出来ます。
 例えば、

 ```php
@@ -17,16 +17,16 @@ $model->attributes = \Yii::$app->request->post('ContactForm');
 if ($model->validate()) {
    // 全ての入力が有効
 } else {
-    // 検証が失敗。$errors はエラーメッセージを含む配列
+    // バリデーションが失敗。$errors はエラーメッセージを含む配列
    $errors = $model->errors;
 }
 ```

 ## 規則を宣言する <a name="declaring-rules"></a>

-`validate()` を現実に動作させるためには、検証する予定の属性に対して検証規則を宣言しなければなりません。
+`validate()` を現実に動作させるためには、検証する予定の属性に対してバリデーション規則を宣言しなければなりません。
 規則は [[yii\base\Model::rules()]] メソッドをオーバーライドすることで宣言します。
-次の例は、`ContactForm` モデルに対して検証規則を宣言する方法を示すものです。
+次の例は、`ContactForm` モデルに対してバリデーション規則を宣言する方法を示すものです。

 ```php
 public function rules()
@@ -50,7 +50,7 @@ public function rules()
    ['属性1', '属性2', ...],

    // 必須。この規則のタイプを指定する。
-    // クラス名、バリデータのエイリアス、または、検証メソッドの名前。
+    // クラス名、バリデータのエイリアス、または、バリデーションメソッドの名前。
    'バリデータ',

    // オプション。この規則が適用されるべき一つまたは複数のシナリオを指定する。
@@ -69,7 +69,7 @@ public function rules()

 * コアバリデータのエイリアス。例えば、`required`、`in`、`date`、等々。
  コアバリデータの完全なリストは [コアバリデータ](tutorial-core-validators.md) を参照してください。
-* モデルクラス内の検証メソッドの名前、または無名関数。詳細は、[インラインバリデータ](#inline-validators) の項を参照してください。
+* モデルクラス内のバリデーションメソッドの名前、または無名関数。詳細は、[インラインバリデータ](#inline-validators) の項を参照してください。
 * 完全修飾のバリデータクラス名。詳細は [スタンドアロンバリデータ](#standalone-validators) の項を参照してください。

 一つの規則は、一つまたは複数の属性を検証するために使用することが出来ます。
@@ -77,21 +77,21 @@ public function rules()
 `on` オプションを指定することで、規則を特定の [シナリオ](structure-models.md#scenarios) においてのみ適用することが出来ます。
 `on` オプションを指定しない場合は、規則が全てのシナリオに適用されることになります。

-`validate()` メソッドが呼ばれると、次のステップを踏んで検証が実行されます。
+`validate()` メソッドが呼ばれると、次のステップを踏んでバリデーションが実行されます。

 1. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::scenarios()]] から属性のリストを取得し、どの属性が検証されるべきかを決定します。
   検証されるべき属性が *アクティブな属性* と呼ばれます。
-2. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::rules()]] から規則のリストを取得し、どの検証規則が使用されるべきかを決定します。
+2. 現在の [[yii\base\Model::scenario|シナリオ]] を使って [[yii\base\Model::rules()]] から規則のリストを取得し、どのバリデーション規則が使用されるべきかを決定します。
   使用されるべき規則が *アクティブな規則* と呼ばれます。
 3. 全てのアクティブな規則を一つずつ使って、その規則に関連付けられた全てのアクティブな属性を一つずつ検証します。
-   検証規則はリストに挙げられている順に評価されます。
+   バリデーション規則はリストに挙げられている順に評価されます。

-属性は、上記の検証ステップに従って、`scenarios()` でアクティブな属性であると宣言されており、かつ、`rules()` で宣言された一つまたは複数のアクティブな規則と関連付けられている場合に、また、その場合に限って、検証されます。
+属性は、上記のバリデーションのステップに従って、`scenarios()` でアクティブな属性であると宣言されており、かつ、`rules()` で宣言された一つまたは複数のアクティブな規則と関連付けられている場合に、また、その場合に限って、検証されます。


 ### エラーメッセージをカスタマイズする <a name="customizing-error-messages"></a>

-たいていのバリデータはデフォルトのエラーメッセージを持っていて、属性の検証が失敗した場合にそれを検証対象のモデルに追加します。
+たいていのバリデータはデフォルトのエラーメッセージを持っていて、属性のバリデーションが失敗した場合にそれを検証の対象であるモデルに追加します。
 例えば、[[yii\validators\RequiredValidator|required]] バリデータは、このバリデータを使って `username` 属性を検証したとき、規則に合致しない場合は「ユーザ名は空ではいけません。」というエラーメッセージをモデルに追加します。

 規則のエラーメッセージは、次に示すように、規則を宣言するときに `message` プロパティを指定することによってカスタマイズすることが出来ます。
@@ -105,25 +105,25 @@ public function rules()
 }
 ```

-バリデータの中には、検証を失敗させたさまざまな原因をより詳しく説明するための追加のエラーメッセージをサポートしているものがあります。
-例えば、[[yii\validators\NumberValidator|number]] バリデータは、検証される値が大きすぎたり小さすぎたりしたときに検証の失敗を説明するために、それぞれ、[[yii\validators\NumberValidator::tooBig|tooBig]] および [[yii\validators\NumberValidator::tooSmall|tooSmall]] のメッセージをサポートしています。
-これらのエラーメッセージも、バリデータの他のプロパティと同様、検証規則の中で構成することが出来ます。
+バリデータの中には、バリデーションを失敗させたさまざまな原因をより詳しく説明するための追加のエラーメッセージをサポートしているものがあります。
+例えば、[[yii\validators\NumberValidator|number]] バリデータは、検証される値が大きすぎたり小さすぎたりしたときにバリデーションの失敗を説明するために、それぞれ、[[yii\validators\NumberValidator::tooBig|tooBig]] および [[yii\validators\NumberValidator::tooSmall|tooSmall]] のメッセージをサポートしています。
+これらのエラーメッセージも、バリデータの他のプロパティと同様、バリデーション規則の中で構成することが出来ます。


-### 検証のイベント <a name="validation-events"></a>
+### バリデーションのイベント <a name="validation-events"></a>

-[[yii\base\Model::validate()]] は、呼び出されると、検証プロセスをカスタマイズするためにオーバーライドできる二つのメソッドを呼び出します。
+[[yii\base\Model::validate()]] は、呼び出されると、バリデーションプロセスをカスタマイズするためにオーバーライドできる二つのメソッドを呼び出します。

 * [[yii\base\Model::beforeValidate()]]: 既定の実装は [[yii\base\Model::EVENT_BEFORE_VALIDATE]] イベントをトリガするものです。
-  このメソッドをオーバーライドするか、または、イベントに反応して、検証が実行される前に、何らかの前処理 (例えば入力されたデータの正規化) をすることが出来ます。
-  このメソッドは、検証を続行すべきか否かを示す真偽値を返さなくてはなりません。
+  このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが実行される前に、何らかの前処理 (例えば入力されたデータの正規化) をすることが出来ます。
+  このメソッドは、バリデーションを続行すべきか否かを示す真偽値を返さなくてはなりません。
 * [[yii\base\Model::afterValidate()]]: 既定の実装は [[yii\base\Model::EVENT_AFTER_VALIDATE]] イベントをトリガするものです。
-  このメソッドをオーバーライドするか、または、イベントに反応して、検証が完了した後に、何らかの後処理をすることが出来ます。
+  このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが完了した後に、何らかの後処理をすることが出来ます。


-### 条件付きの検証 <a name="conditional-validation"></a>
+### 条件付きバリデーション <a name="conditional-validation"></a>

-特定の条件が満たされる場合に限って属性を検証したい場合、例えば、ある属性の検証が他の属性の値に依存する場合には、[[yii\validators\Validator::when|when]] プロパティを使って、そのような条件を定義することが出来ます。
+特定の条件が満たされる場合に限って属性を検証したい場合、例えば、ある属性のバリデーションが他の属性の値に依存する場合には、[[yii\validators\Validator::when|when]] プロパティを使って、そのような条件を定義することが出来ます。
 例えば、

 ```php
@@ -145,7 +145,7 @@ public function rules()
 function ($model, $attribute)
 ```

-クライアント側でも条件付きの検証をサポートする必要がある場合は、[[yii\validators\Validator::whenClient|whenClient]] プロパティを構成しなければなりません。
+クライアント側でも条件付きバリデーションをサポートする必要がある場合は、[[yii\validators\Validator::whenClient|whenClient]] プロパティを構成しなければなりません。
 このプロパティは、規則を適用すべきか否かを返す JavaScript 関数を表す文字列を値として取ります。
 例えば、

@@ -164,7 +164,7 @@ function ($model, $attribute)

 ユーザ入力をフィルタまたは前処理する必要があることがよくあります。
 例えば、`username` の入力値の前後にある空白を除去したいというような場合です。
-この目的を達するために検証規則を使うことが出来ます。
+この目的を達するためにバリデーション規則を使うことが出来ます。

 次の例では、入力値の前後にある空白を除去して、空の入力値を null に変換することを、[trim](tutorial-core-validators.md#trim) および [default](tutorial-core-validators.md#default) のコアバリデータで行っています。

@@ -176,7 +176,7 @@ function ($model, $attribute)
 ```

 もっと汎用的な [filter](tutorial-core-validators.md#filter) バリデータを使って、もっと複雑なデータフィルタリングをすることも出来ます。
-お判りのように、これらの検証規則は実際には入力を検証しません。そうではなくて、検証される属性の値を処理して書き戻すのです。
+お分かりかと思いますが、これらのバリデーション規則は実際には入力を検証しません。そうではなくて、検証される属性の値を処理して書き戻すのです。


 ### 空の入力値を扱う <a name="handling-empty-inputs"></a>
@@ -208,15 +208,15 @@ HTML フォームから入力データが送信されたとき、入力値が空
 ```

 > Note|注意: たいていのバリデータは、[[yii\base\Validator::skipOnEmpty]] プロパティがデフォルト値 `true` を取っている場合は、空の入力値を処理しません。
-  そのようなバリデータは、関連付けられた属性が空の入力値を受け取ったときは、検証の過程ではスキップされるだけになります。
+  そのようなバリデータは、関連付けられた属性が空の入力値を受け取ったときは、バリデーションの過程ではスキップされるだけになります。
  [コアバリデータ](tutorial-core-validators.md) の中では、`captcha`、`default`、`filter`、`required`、そして `trim` だけが空の入力値を処理します。


-## 臨時の検証 <a name="ad-hoc-validation"></a>
+## アドホックなバリデーション <a name="ad-hoc-validation"></a>

-時として、何らかのモデルに結び付けられていない値に対する *臨時の検証* を実行しなければならない場合があります。
+時として、何らかのモデルに結び付けられていない値に対する *アドホックなバリデーション* を実行しなければならない場合があります。

-実行する必要がある検証が一種類 (例えば、メールアドレスの検証) だけである場合は、使いたいバリデータの [[yii\validators\Validator::validate()|validate()]] メソッドを次のように呼び出すことが出来ます。
+実行する必要があるバリデーションが一種類 (例えば、メールアドレスの検証) だけである場合は、使いたいバリデータの [[yii\validators\Validator::validate()|validate()]] メソッドを次のように呼び出すことが出来ます。

 ```php
 $email = 'test@example.com';
@@ -229,10 +229,10 @@ if ($validator->validate($email, $error)) {
 }
 ```

-> Note|注意: 全てのバリデータがこの種の検証をサポートしている訳ではありません。
+> Note|注意: 全てのバリデータがこの種のバリデーションをサポートしている訳ではありません。
  その一例が [unique](tutorial-core-validators.md#unique) コアバリデータであり、これはモデルとともに使用されることだけを念頭にして設計されています。

-いくつかの値に対して複数の検証を実行する必要がある場合は、属性と規則の両方をその場で宣言することが出来る [[yii\base\DynamicModel]] を使うことが出来ます。
+いくつかの値に対して複数のバリデーションを実行する必要がある場合は、属性と規則の両方をその場で宣言することが出来る [[yii\base\DynamicModel]] を使うことが出来ます。
 これは、次のような使い方をします。

 ```php
@@ -244,16 +244,16 @@ public function actionSearch($name, $email)
    ]);

    if ($model->hasErrors()) {
-        // 検証が失敗
+        // バリデーションが失敗
    } else {
-        // 検証が成功
+        // バリデーションが成功
    }
 }
 ```

 [[yii\base\DynamicModel::validateData()]] メソッドは `DynamicModel` のインスタンスを作成し、与えられた値 (この例では `name` と `email`) を使って属性を定義し、そして、与えられた規則で [[yii\base\Model::validate()]] を呼び出します。

-別の選択肢として、次のように、もっと「クラシック」な構文を使って、臨時のデータ検証を実行することも出来ます。
+別の選択肢として、次のように、もっと「クラシック」な構文を使って、アドホックなデータバリデーションを実行することも出来ます。

 ```php
 public function actionSearch($name, $email)
@@ -264,14 +264,14 @@ public function actionSearch($name, $email)
        ->validate();

    if ($model->hasErrors()) {
-        // 検証が失敗
+        // バリデーションが失敗
    } else {
-        // 検証が成功
+        // バリデーションが成功
    }
 }
 ```

-検証を実行した後は、通常のモデルで行うのと同様に、検証が成功したか否かを [[yii\base\DynamicModel::hasErrors()|hasErrors()]] メソッドを呼んでチェックして、[[yii\base\DynamicModel::errors|errors]] プロパティから検証エラーを取得することが出来ます。
+検証を実行した後は、通常のモデルで行うのと同様に、バリデーションが成功したか否かを [[yii\base\DynamicModel::hasErrors()|hasErrors()]] メソッドを呼んでチェックして、[[yii\base\DynamicModel::errors|errors]] プロパティからバリデーションエラーを取得することが出来ます。
 また、このモデルのインスタンスによって定義された動的な属性に対しても、例えば `$model->name` や `$model->email` のようにして、アクセスすることが出来ます。


@@ -294,7 +294,7 @@ Yii のリリースに含まれている [コアバリデータ](tutorial-core-v
 function ($attribute, $params)
 ```

-属性が検証に失敗した場合は、メソッド/関数 は [[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存し、後で読み出してエンドユーザに示ことが出来るようにしなければなりません。
+属性がバリデーションに失敗した場合は、メソッド/関数 は [[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存し、後で読み出してエンドユーザに示ことが出来るようにしなければなりません。

 下記にいくつかの例を示します。

@@ -330,7 +330,7 @@ class MyForm extends Model
 }
 ```

-> Note|注意: 既定では、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかの検証規則に失敗したりしている場合には、適用されません。
+> Note|注意: 既定では、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかのバリデーション規則に失敗したりしている場合には、適用されません。
 > 規則が常に適用されることを保証したい場合は、規則の宣言において [[yii\validators\Validator::skipOnEmpty|skipOnEmpty]] および/または [[yii\validators\Validator::skipOnError|skipOnError]] のプロパティを false に設定することが出来ます。
 > 例えば、
 >
@@ -345,7 +345,7 @@ class MyForm extends Model

 スタンドアロンバリデータは、[[yii\validators\Validator]] またはその子クラスを拡張するクラスです。
 [[yii\validators\Validator::validateAttribute()]] メソッドをオーバーライドすることによって、その検証ロジックを実装することが出来ます。
-[インラインバリデータ](#inline-validators) でするのと同じように、属性が検証に失敗した場合は、[[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存します。
+[インラインバリデータ](#inline-validators) でするのと同じように、属性がバリデーションに失敗した場合は、[[yii\base\Model::addError()]] を呼んでエラーメッセージをモデルに保存します。
 例えば、

 ```php
@@ -365,26 +365,26 @@ class CountryValidator extends Validator
 ```


-あなたのバリデータで、モデル無しの値の検証をサポートしたい場合は、[[yii\validators\Validator::validate()]] もオーバーライドしなければなりません。
+あなたのバリデータで、モデル無しの値のバリデーションをサポートしたい場合は、[[yii\validators\Validator::validate()]] もオーバーライドしなければなりません。
 または、`validateAttribute()` と `validate()` の代りに、[[yii\validators\Validator::validateValue()]] をオーバーライドしても構いません。
 と言うのは、前の二つは、デフォルトでは、`validateValue()` を呼び出すことによって実装されているからです。


-## クライアント側での検証 <a name="client-side-validation"></a>
+## クライアント側でのバリデーション <a name="client-side-validation"></a>

-エンドユーザが HTML フォームで値を入力する際には、JavaScript に基づくクライアント側での検証が提供されることが望まれます。
-というのは、クライアント側での検証は、ユーザが入力のエラーを早く見つけることが出来るようにすることによって、より良いユーザ体験を提供するものだからです。
-あなたも、サーバ側での検証 *に加えて* クライアント側での検証をサポートするバリデータを使用したり実装したりすることが出来ます。
+エンドユーザが HTML フォームで値を入力する際には、JavaScript に基づくクライアント側でのバリデーションを提供することが望まれます。
+というのは、クライアント側でのバリデーションは、ユーザが入力のエラーを早く見つけることが出来るようにすることによって、より良いユーザ体験を提供するものだからです。
+あなたも、サーバ側でのバリデーション *に加えて* クライアント側でのバリデーションをサポートするバリデータを使用したり実装したりすることが出来ます。

-> Info|情報: クライアント側での検証は望ましいものですが、不可欠なものではありません。
+> Info|情報: クライアント側でのバリデーションは望ましいものですが、不可欠なものではありません。
  その主たる目的は、ユーザにより良い体験を提供することにあります。
-  エンドユーザから来る入力値と同じように、クライアント側での検証を決して信用してはいけません。
-  この理由により、これまでの項で説明したように、常に [[yii\base\Model::validate()]] を呼び出してサーバ側での検証を実行しなければなりません。
+  エンドユーザから来る入力値と同じように、クライアント側でのバリデーションを決して信用してはいけません。
+  この理由により、これまでの項で説明したように、常に [[yii\base\Model::validate()]] を呼び出してサーバ側でのバリデーションを実行しなければなりません。


-### クライアント側での検証を使う <a name="using-client-side-validation"></a>
+### クライアント側でのバリデーションを使う <a name="using-client-side-validation"></a>

-多くの [コアバリデータ](tutorial-core-validators.md) は、そのままで、クライアント側での検証をサポートしています。
+多くの [コアバリデータ](tutorial-core-validators.md) は、そのままで、クライアント側でのバリデーションをサポートしています。
 あなたがする必要があるのは、[[yii\widgets\ActiveForm]] を使って HTML フォームを作るということだけです。
 例えば、下の `LoginForm` は二つの規則を宣言しています。
 一つは、[required](tutorial-core-validators.md#required) コアバリデータを使っていますが、これはクライアント側とサーバ側の両方でサポートされています。
@@ -434,16 +434,16 @@ class LoginForm extends Model
 <?php yii\widgets\ActiveForm::end(); ?>
 ```

-舞台裏では、[[yii\widgets\ActiveForm]] がモデルで宣言されている検証規則を読んで、クライアント側の検証をサポートするバリデータのために適切な JavaScript コードを生成します。
-ユーザが入力フィールドの値を変更したりフォームを送信したりすると、クライアント側の検証の JavaScript が起動されます。
+舞台裏では、[[yii\widgets\ActiveForm]] がモデルで宣言されているバリデーション規則を読んで、クライアント側のバリデーションをサポートするバリデータのために適切な JavaScript コードを生成します。
+ユーザが入力フィールドの値を変更したりフォームを送信したりすると、クライアント側バリデーションの JavaScript が起動されます。

-クライアント側の検証を完全に無効にしたい場合は、[[yii\widgets\ActiveForm::enableClientValidation]] プロパティを false に設定することが出来ます。
-また、個々の入力フィールドごとにクライアント側の検証を無効にしたい場合は、入力フィールドの [[yii\widgets\ActiveField::enableClientValidation]] プロパティを false に設定することも出来ます。
+クライアント側のバリデーションを完全に無効にしたい場合は、[[yii\widgets\ActiveForm::enableClientValidation]] プロパティを false に設定することが出来ます。
+また、個々の入力フィールドごとにクライアント側のバリデーションを無効にしたい場合は、入力フィールドの [[yii\widgets\ActiveField::enableClientValidation]] プロパティを false に設定することも出来ます。


-### クライアント側の検証を実装する <a name="implementing-client-side-validation"></a>
+### クライアント側バリデーションを実装する <a name="implementing-client-side-validation"></a>

-クライアント側の検証をサポートするバリデータを作成するためには、クライアント側での検証を実行する JavaScript コードを返す [[yii\validators\Validator::clientValidateAttribute()]] メソッドを実装しなければなりません。
+クライアント側バリデーションをサポートするバリデータを作成するためには、クライアント側でのバリデーションを実行する JavaScript コードを返す [[yii\validators\Validator::clientValidateAttribute()]] メソッドを実装しなければなりません。
 その JavaScript の中では、次の事前定義された変数を使用することが出来ます。

 - `attribute`: 検証される属性の名前。
@@ -452,7 +452,7 @@ class LoginForm extends Model
 - `deferred`: Deferred オブジェクトをプッシュして入れることが出来る配列 (次の項で説明します)。

 次の例では、既存のステータスのデータに含まれる有効な値が入力されたかどうかを検証する `StatusValidator` を作成します。
-このバリデータは、サーバ側とクライアント側の両方の検証をサポートします。
+このバリデータは、サーバ側とクライアント側の両方のバリデーションをサポートします。

 ```php
 namespace app\components;
@@ -489,9 +489,9 @@ JS;
 }
 ```

-> Tip|ヒント: 上記のコード例の主たる目的は、クライアント側の検証をサポートする方法を説明することにあります。
+> Tip|ヒント: 上記のコード例の主たる目的は、クライアント側バリデーションをサポートする方法を説明することにあります。
 > 実際の仕事では、[in](tutorial-core-validators.md#in) コアバリデータを使って、同じ目的を達することが出来ます。
-> 次のように検証規則を書けばよいのです。
+> 次のようにバリデーション規則を書けばよいのです。
 >
 > ```php
 > [
@@ -499,10 +499,10 @@ JS;
 > ]
 > ```

-### Deferred な検証 <a name="deferred-validation"></a>
+### Deferred バリデーション <a name="deferred-validation"></a>

-非同期のクライアント側検証をサポートする必要がある場合は、[Defered オブジェクト](http://api.jquery.com/category/deferred-object/) を作成することが出来ます。
-例えば、AJAX による特別な検証を実行するために、次のコードを使うことが出来ます。
+非同期のクライアント側バリデーションをサポートする必要がある場合は、[Defered オブジェクト](http://api.jquery.com/category/deferred-object/) を作成することが出来ます。
+例えば、AJAX によるカスタムバリデーションを実行するために、次のコードを使うことが出来ます。

 ```php
 public function clientValidateAttribute($model, $attribute, $view)
@@ -547,7 +547,7 @@ JS;
 ```

 > Note|注意: 属性が検証された後に、`resolve()` メソッドを呼び出さなければなりません。
-  そうしないと、主たるフォームの検証が完了しません。
+  そうしないと、主たるフォームのバリデーションが完了しません。

 簡潔に記述できるように、`deferred` 配列はショートカットメソッド `add()` を装備しており、このメソッドを使うと、自動的に Deferred オブジェクトを作成して `deferred` 配列に追加することが出来ます。
 このメソッドを使えば、上記の例は次のように簡潔に記すことが出来ます。
@@ -575,14 +575,14 @@ JS;
 ```


-### AJAX 検証 <a name="ajax-validation"></a>
+### AJAX バリデーション <a name="ajax-validation"></a>

 場合によっては、サーバだけが必要な情報を持っているために、サーバ側でしか検証が実行できないことがあります。
 例えば、ユーザ名がユニークであるか否かを検証するためには、サーバ側で user テーブルを調べることが必要になります。
-このような場合には、AJAX ベースの検証を使うことが出来ます。
-AJAX 検証は、通常のクライアント側での検証と同じユーザ体験を保ちながら、入力値を検証するためにバックグラウンドで AJAX リクエストを発行します。
+このような場合には、AJAX ベースのバリデーションを使うことが出来ます。
+AJAX バリデーションは、通常のクライアント側でのバリデーションと同じユーザ体験を保ちながら、入力値を検証するためにバックグラウンドで AJAX リクエストを発行します。

-AJAX 検証をフォーム全体に対して有効にするためには、[[yii\widgets\ActiveForm::enableAjaxValidation]] プロパティを `true` に設定して、`id` にフォームを特定するユニークな ID を設定しなければなりません。
+AJAX バリデーションをフォーム全体に対して有効にするためには、[[yii\widgets\ActiveForm::enableAjaxValidation]] プロパティを `true` に設定して、`id` にフォームを特定するユニークな ID を設定しなければなりません。

 ```php
 <?php $form = yii\widgets\ActiveForm::begin([
@@ -591,9 +591,9 @@ AJAX 検証をフォーム全体に対して有効にするためには、[[yii\
 ]); ?>
 ```

-個別の入力フィールドについても、[[yii\widgets\ActiveField::enableAjaxValidation]] プロパティを設定して、AJAX 検証を有効にしたり無効にしたりすることが出来ます。
+個別の入力フィールドについても、[[yii\widgets\ActiveField::enableAjaxValidation]] プロパティを設定して、AJAX バリデーションを有効にしたり無効にしたりすることが出来ます。

-また、サーバ側では、AJAX 検証のリクエストを処理できるように準備しておく必要があります。
+また、サーバ側では、AJAX バリデーションのリクエストを処理できるように準備しておく必要があります。
 これは、コントローラのアクションにおいて、次のようなコード断片を使用することで達成できます。

 ```php
@@ -604,7 +604,7 @@ if (Yii::$app->request->isAjax && $model->load(Yii::$app->request->post())) {
 ```

 上記のコードは、現在のリクエストが AJAX であるかどうかをチェックします。
-もし AJAX であるなら、リクエストに応えて検証を実行し、エラーを JSON 形式で返します。
+もし AJAX であるなら、リクエストに応えてバリデーションを実行し、エラーを JSON 形式で返します。

-> Info|情報: AJAX 検証を実行するためには、[Deferred な検証](#deferred-validation) を使うことも出来ます。
-  しかし、ここで説明された AJAX 検証の機能の方がより体系化されており、コーディングの労力も少なくて済みます。
+> Info|情報: AJAX バリデーションを実行するためには、[Deferred バリデーション](#deferred-validation) を使うことも出来ます。
+  しかし、ここで説明された AJAX バリデーションの機能の方がより体系化されており、コーディングの労力も少なくて済みます。