Merge pull request #7148 from softark/docs-guide-ja-runtime-rev

docs/guide-ja/input-tabular-input.md

@@ -60,8 +60,6 @@ class SettingsController extends Controller
 
 次に、`update` ビューにあるフォームです。
 
-Now the form that's in `update` view:
-
 ```php
 <?php
 use yii\helpers\Html;

docs/guide-ja/runtime-bootstrapping.md

@@ -17,10 +17,8 @@
 4. [[yii\base\Application::init()|init()]] が呼ばれます。
    そして `init()` が [[yii\base\Application::bootstrap()|bootstrap()]] を呼んで、ブートストラップコンポーネントを走らせます。
    - エクステンションマニフェストファイル `vendor/yiisoft/extensions.php` をインクルードします。
-   - エクステンションによって宣言された [ブートストラップコンポーネント](structure-extensions.md#bootstrapping-classes) を作成して走らせます。
-   - アプリケーションの [bootstrap プロパティ](structure-applications.md#bootstrap) に宣言されている
-     [アプリケーションコンポーネント](structure-application-components.md) および/または
-     [モジュール](structure-modules.md) を作成して走らせます。
+   - エクステンションによって宣言された [ブートストラップコンポーネント](structure-extensions.md#bootstrapping-classes) を作成して実行します。
+   - アプリケーションの [bootstrap プロパティ](structure-applications.md#bootstrap) に宣言されている [アプリケーションコンポーネント](structure-application-components.md) および/または [モジュール](structure-modules.md) を作成して実行します。
 
 ブートストラップの仕事は *全て* のリクエストを処理する前に、毎回しなければなりませんので、この過程を軽いものに保って可能な限り最適化することは非常に重要なことです。
 
@@ -29,10 +27,10 @@
 例えば、モジュールが追加の URL 解析規則を登録する必要がある場合は、モジュールを [bootstrap プロパティ](structure-applications.md#bootstrap) のリストに挙げなければなりません。
 なぜなら、URL 規則を使ってリクエストが解決される前に、新しい URL 規則を有効にしなければならないからです。
 
-実運用モードにおいては、[PHP OPCache] や [APC]  など、バイトコードキャッシュを有効にして、PHP ファイルをインクルードして解析するのに要する時間を最小化してください。
+本番運用モードにおいては、[PHP OPCache] や [APC]  など、バイトコードキャッシュを有効にして、PHP ファイルをインクルードして解析するのに要する時間を最小化してください。
 
 [PHP OPcache]: http://php.net/manual/ja/book.opcache.php
 [APC]: http://php.net/manual/ja/book.apc.php
 
 大規模なアプリケーションには、多数の小さな構成情報ファイルに分割された、非常に複雑なアプリケーション [構成情報](concept-configurations.md) を持つものがあります。
-そのような場合には、構成情報配列全体をキャッシュしておき、エントリスクリプトでアプリケーションのインスタンスを作成する前には、構成情報配列をキャッシュからロードするという方法を考慮してください。
+そのような場合には、構成情報配列全体をキャッシュしておき、エントリスクリプトでアプリケーションのインスタンスを作成する前に構成情報をロードするときには、配列全体を直接にキャッシュからロードするという方法を考慮してください。

docs/guide-ja/runtime-handling-errors.md

@@ -2,7 +2,7 @@
 ==========
 
 Yii は、エラー処理を従来よりはるかに快適な経験にしてくれる、内臓の [[yii\web\ErrorHandler|エラーハンドラ]] を持っています。
-具体的には、Yii のエラーハンドラはエラー処理を向上させるために、次のことを行います。
+具体的には、Yii のエラーハンドラはエラー処理をより良くするために、次のことを行います。
 
 * 致命的でない全ての PHP エラー (警告や通知) は捕捉可能な例外に変換されます。
 * 例外と致命的な PHP エラーは、デバッグモードでは、詳細なコールスタック情報とソースコード行とともに表示されます。
@@ -46,8 +46,8 @@ try {
 // 実行を継続 ...
 ```
 
-ユーザに対して、リクエストが無効であったり予期しないものであったりすることを知らせるエラーページを表示したい場合は、単に [[yii\web\NotFoundHttpException]] のような [[yii\web\HttpException|HTTP 例外]] を投げるだけで済ませることが出来ます。
-エラーハンドラがレスポンスの HTTP ステータスコードを正しく設定し、適切なエラービューを使ってエラーメッセージを表示してくれます。
+リクエストが無効または予期しないものであることをユーザに知らせるエラーページを表示したい場合は、単に [[yii\web\NotFoundHttpException]] のような [[yii\web\HttpException|HTTP 例外]] を投げるだけで済ませることが出来ます。
+そうすれば、エラーハンドラがレスポンスの HTTP ステータスコードを正しく設定し、適切なエラービューを使ってエラーメッセージを表示してくれます。
 
 ```php
 use yii\web\NotFoundHttpException;
@@ -59,8 +59,8 @@ throw new NotFoundHttpException();
 ## エラー表示をカスタマイズする <span id="customizing-error-display"></span>
 
 [[yii\web\ErrorHandler|エラーハンドラ]] は、定数 `YII_DEBUG` の値に従って、エラー表示を調整します。
-`YII_DEBUG` が true である (デバッグモードである) 場合は、エラーハンドラは、デバッグがより容易になるように、詳細なコールスタック情報とソースコード行とともに例外を表示します。
-そして、`YII_DEBUG` が false のときは、アプリケーションに関する公開できない情報を開示することを防ぐために、エラーメッセージだけが表示されます。
+`YII_DEBUG` が true である (デバッグモードである) 場合は、エラーハンドラは、デバッグがより容易になるように、例外とともに、詳細なコールスタック情報とソースコード行を表示します。
+そして、`YII_DEBUG` が false のときは、アプリケーションに関する公開できない情報の開示を防ぐために、エラーメッセージだけが表示されます。
 
 > Info|情報: 例外が [[yii\base\UserException]] の子孫である場合は、`YII_DEBUG` の値の如何にかかわらず、コールスタックは表示されません。
 これは、この種の例外はユーザの誤操作によって引き起こされるものであり、開発者は何も修正する必要がないと考えられるからです。
@@ -90,7 +90,7 @@ return [
 ```
 
 [[yii\web\ErrorHandler::errorAction|errorAction]] プロパティは、アクションへの [ルート](structure-controllers.md#routes) を値として取ります。
-上記の構成は、エラーをコールスタック情報なしで表示する必要がある場合は、`site/error` アクションが実行されるべきであることを記述しています。
+上記の構成は、エラーをコールスタック情報なしで表示する必要がある場合は、`site/error` アクションが実行されるべきことを記述しています。
 
 `site/error` アクションは次のようにして作成することが出来ます。
 
@@ -133,17 +133,16 @@ public function actionError()
 
 * `name`: エラーの名前。
 * `message`: エラーメッセージ。
-* `exception`: 例外オブジェクト。これを通じて、更に有用な情報、例えば、HTTP ステータスコード、
-エラーコード、エラーコールスタックなどにアクセス出来ます。
+* `exception`: 例外オブジェクト。これを通じて、更に有用な情報、例えば、HTTP ステータスコード、エラーコード、エラーコールスタックなどにアクセスすることが出来ます。
 
 > Info|情報: あなたが [ベーシックアプリケーションテンプレート](start-installation.md) または [アドバンストアプリケーションテンプレート](tutorial-advanced-app.md) を使っている場合は、エラーアクションとエラービューは、既にあなたのために定義されています。
 
 
 ### エラーのレスポンス形式をカスタマイズする <span id="error-format"></span>
 
-エラーハンドラは、[レスポンス](runtime-responses.md) の形式の設定に従ってエラーを表示します。
+エラーハンドラは、[レスポンス](runtime-responses.md) 形式の設定に従ってエラーを表示します。
 [[yii\web\Response::format|レスポンス形式]] が `html` である場合は、直前の項で説明したように、エラービューまたは例外ビューを使ってエラーを表示します。
-その他のレスポンス形式の場合は、エラーハンドラは例外の配列表現を [[yii\web\Response::data]] プロパティに代入し、次に `data` プロパティがレスポンス形式に応じて様々な形式に変換されます。
+その他のレスポンス形式の場合は、エラーハンドラは例外の配列表現を [[yii\web\Response::data]] プロパティに代入し、次に `data` プロパティをレスポンス形式に応じて様々な形式に変換します。
 例えば、レスポンス形式が `json` である場合は、次のようなレスポンスになります。
 
 ```

docs/guide-ja/runtime-logging.md

@@ -2,12 +2,12 @@
 ========
 
 Yii は高度なカスタマイズ性と拡張性を持った強力なロギングフレームワークを提供しています。
-このフレームワークを使用すると、さまざまな種類のメッセージを記録し、フィルタして、ファイル、データベース、メールなど、さまざまなターゲットに収集することが簡単に出来ます。
+このフレームワークを使用すると、さまざまな種類のメッセージを記録し、それをフィルタして、ファイル、データベース、メールなど、さまざまなターゲットに収集することが簡単に出来ます。
 
 Yii のロギングフレームワークを使うためには、下記のステップを踏みます。
  
 * コードのさまざまな場所で [ログメッセージ](#log-messages) を記録する。
-* アプリケーションの構成情報で [ログターゲット](#log-targets) を構成して、ログメッセージをフィルタしてエクスポートする。
+* ログメッセージをフィルタしてエクスポートするために、アプリケーションの構成情報で [ログターゲット](#log-targets) を構成する。
 * さまざまなターゲット (例えば [Yii デバッガ](tool-debugger.md)) によって、フィルタされエクスポートされたログメッセージを調査する。
 
 この節では、主として最初の二つのステップについて説明します。
@@ -17,7 +17,7 @@ Yii 縺ｮ繝ｭ繧ｮ繝ｳ繧ｰ繝輔Ξ繝ｼ繝繝ｯ繝ｼ繧ｯ繧剃ｽｿ縺◆繧√↓縺ｯ縲∽ｸ玖ｨ倥繧ｹ繝
 
 ログメッセージを記録することは、次のログ記録メソッドのどれかを呼び出すだけの簡単なことです。
 
-* [[Yii::trace()]]: コードの断片がどのように走るかをトレースするメッセージを記録します。主として開発のために使用します。
+* [[Yii::trace()]]: コードの断片がどのように走ったかをトレースするメッセージを記録します。主として開発のために使用します。
 * [[Yii::info()]]: 何らかの有用な情報を伝えるメッセージを記録します。
 * [[Yii::warning()]]: 何か予期しないことが発生したことを示す警告メッセージを記録します。
 * [[Yii::error()]]: 出来るだけ早急に調査すべき致命的なエラーを記録します。
@@ -48,8 +48,7 @@ Yii::trace('蟷ｳ蝮庶逶翫險育ｮ励ｒ髢句ｧ', __METHOD__);
 
 > Info|情報: 上記で説明したメソッドは、実際には、[[yii\log\Logger|ロガーオブジェクト]] の [[yii\log\Logger::log()|log()]] メソッドへのショートカットです。
 [[yii\log\Logger|ロガーオブジェクト]] は `Yii::getLogger()` という式でアクセス可能なシングルトンです。
-ロガーオブジェクトは、十分な量のメッセージが記録されたとき、または、アプリケーションが終了するときに、[[yii\log\Dispatcher|メッセージディスパッチャ]]
-を呼んで、登録された [ログターゲット](#log-targets) に記録されたログメッセージを送信します。
+ロガーオブジェクトは、十分な量のメッセージが記録されたとき、または、アプリケーションが終了するときに、[[yii\log\Dispatcher|メッセージディスパッチャ]] を呼んで、登録された [ログターゲット](#log-targets) に記録されたログメッセージを送信します。
 
 
 ## ログターゲット <span id="log-targets"></span>
@@ -59,8 +58,7 @@ Yii::trace('蟷ｳ蝮庶逶翫險育ｮ励ｒ髢句ｧ', __METHOD__);
 例えば、[[yii\log\DbTarget|データベースターゲット]] は、フィルタされたログメッセージをデータベーステーブルにエクスポートし、[[yii\log\EmailTarget|メールターゲット]] は、ログメッセージを指定されたメールアドレスにエクスポートします。
 
 一つのアプリケーションの中で複数のログターゲットを登録することが出来ます。
-そのためには、次のように、
-アプリケーションの構成情報の中で、`log` [アプリケーションコンポーネント](structure-application-components.md) によってログターゲットを構成します。
+そのためには、次のように、アプリケーションの構成情報の中で、`log` [アプリケーションコンポーネント](structure-application-components.md) によってログターゲットを構成します。
 
 ```php
 return [
@@ -81,7 +79,7 @@ return [
                     'message' => [
                        'from' => ['log@example.com'],
                        'to' => ['admin@example.com', 'developer@example.com'],
-                       'subject' => 'Database errors at example.com',
+                       'subject' => 'example.com で、データベースエラー発生',
                     ],
                 ],
             ],
@@ -96,7 +94,7 @@ return [
 上記のコードでは、二つのログターゲットが [[yii\log\Dispatcher::targets]] プロパティに登録されています。
 
 * 最初のターゲットは、エラーと警告のメッセージを選択して、データベーステーブルに保存します。
-* 第二のターゲットは、名前が `yii\db\` で始まるカテゴリの下のエラーメッセージを選んで、`admin@example.com` と `developer@example.com` の両方にメールで送信します。
+* 第二のターゲットは、名前が `yii\db\` で始まるカテゴリのエラーメッセージを選んで、`admin@example.com` と `developer@example.com` の両方にメールで送信します。
 
 Yii は下記のログターゲットをあらかじめ内蔵しています。
 その構成方法と使用方法を学ぶためには、これらのクラスの API ドキュメントを参照してください。
@@ -111,8 +109,7 @@ Yii 縺ｯ荳玖ｨ倥繝ｭ繧ｰ繧ｿ繝ｼ繧ｲ繝ヨ繧偵≠繧峨°縺倥ａ蜀鳩縺励※縺∪縺吶
   
 ### メッセージのフィルタリング <span id="message-filtering"></span>
 
-全てのログターゲットについて、それぞれ、[[yii\log\Target::levels|levels]] と [[yii\log\Target::categories|categories]]
-のプロパティを構成して、ターゲットが処理すべきメッセージの重要性レベルとカテゴリを指定することが出来ます。
+全てのログターゲットについて、それぞれ、[[yii\log\Target::levels|levels]] と [[yii\log\Target::categories|categories]] のプロパティを構成して、ターゲットが処理すべきメッセージの重要性レベルとカテゴリを指定することが出来ます。
 
 [[yii\log\Target::levels|levels]] プロパティは、次のレベルの一つまたは複数からなる配列を値として取ります。
 
@@ -133,13 +130,10 @@ Yii 縺ｯ荳玖ｨ倥繝ｭ繧ｰ繧ｿ繝ｼ繧ｲ繝ヨ繧偵≠繧峨°縺倥ａ蜀鳩縺励※縺∪縺吶
 
 [[yii\log\Target::categories|categories]] プロパティを指定しない場合は、ターゲットが *全ての* カテゴリのメッセージを処理することを意味します。
 
-カテゴリを [[yii\log\Target::categories|categories]] プロパティでホワイトリストとして登録する以外に、一定のカテゴリを [[yii\log\Target::except|except]]
-プロパティによってブラックリストとして登録することも可能です。
+カテゴリを [[yii\log\Target::categories|categories]] プロパティでホワイトリストとして登録する以外に、一定のカテゴリを [[yii\log\Target::except|except]] プロパティによってブラックリストとして登録することも可能です。
 カテゴリの名前がこの配列にあるか、または配列にあるパターンに合致する場合は、メッセージはターゲットによって処理されません。
 
-次のターゲットの構成は、ターゲットが、`yii\db\*` または `yii\web\HttpException:*`
-に合致するカテゴリ名を持つエラーおよび警告のメッセージだけを処理すべきこと、ただし、`yii\web\HttpException:404`
-は除外すべきことを指定するものです。
+次のターゲットの構成は、ターゲットが、`yii\db\*` または `yii\web\HttpException:*` に合致するカテゴリ名を持つエラーおよび警告のメッセージだけを処理すべきこと、ただし、`yii\web\HttpException:404` は除外すべきことを指定するものです。
 
 ```php
 [
@@ -193,7 +187,7 @@ Yii 縺ｯ荳玖ｨ倥繝ｭ繧ｰ繧ｿ繝ｼ繧ｲ繝ヨ繧偵≠繧峨°縺倥ａ蜀鳩縺励※縺∪縺吶
 メッセージ前置情報以外にも、ログターゲットは、一群のログメッセージごとに一定のコンテキスト情報を追加します。
 デフォルトでは、その情報には、次のグローバル PHP 変数、すなわち、`$_GET`、`$_POST`、`$_FILES`、`$_COOKIE`、`$_SESSION` および `$_SERVER` の値が含まれます。
 ログターゲットに含ませたいグローバル変数の名前を [[yii\log\Target::logVars]] プロパティに設定することによって、この動作を調整することが出来ます。
-例えば、次のログターゲットの構成は、`$_SERVER` の値だけがログメッセージに追加されるように指定するものです。
+例えば、次のログターゲットの構成は、`$_SERVER` の値だけをログメッセージに追加するように指定するものです。
 
 ```php
 [
@@ -263,8 +257,7 @@ return [
 
 デフォルトの状態では、吐き出しとエクスポートの間隔の設定のために、`Yii::trace()` やその他のログ記録メソッドを呼んでも、ただちには、ログメッセージはログターゲットに出現しません。
 このことは、長時間にわたって走るコンソールアプリケーションでは、問題になる場合もあります。
-各ログメッセージがただちにログターゲットに出現するようにするためには、下記のように、[[yii\log\Dispatcher::flushInterval|flushInterval]]
-と [[yii\log\Target::exportInterval|exportInterval]] の両方を 1 に設定しなければなりません。
+各ログメッセージがただちにログターゲットに出現するようにするためには、下記のように、[[yii\log\Dispatcher::flushInterval|flushInterval]] と [[yii\log\Target::exportInterval|exportInterval]] の両方を 1 に設定しなければなりません。
 
 ```php
 return [
@@ -295,7 +288,8 @@ return [
 Yii::$app->log->targets['file']->enabled = false;
 ```
 
-上記のコードを使うためには、下記のように、`targets` の配列で文字列のキーを使って、ターゲットを `file` という名前にする必要があります。
+上記のコードでは、ターゲットが `file` という名前であることが必要とされています。
+下記のように、`targets` の配列で文字列のキーを使ってターゲットの名前を指定して下さい。
 
 ```php
 return [
@@ -318,7 +312,7 @@ return [
 
 ### 新しいターゲットを作る <span id="new-targets"></span>
 
-新しいログターゲットを作ることは非常に単純なことです。
+新しいログターゲットを作ることは非常に簡単です。
 必要なことは、主として、[[yii\log\Target::messages]] 配列の中身を指定された媒体に送出する [[yii\log\Target::export()]] メソッドを実装することです。
 各メッセージに書式を設定するためには、[[yii\log\Target::formatMessage()]] を呼ぶことが出来ます。
 詳細については、Yii リリースに含まれているログターゲットクラスのどれか一つを参照してください。
@@ -342,7 +336,7 @@ return [
 ここで `myBenchmark` はコードブロックを特定するユニークなトークンを表します。
 後でプロファイリング結果を検査するときに、このトークンを使って、対応するコードブロックによって消費された時間を調べます。
 
-`beginProfile` と `endProfile` のペアが適正な入れ子になっているように確認することは、非常に重要なことです。
+`beginProfile` と `endProfile` のペアが適正な入れ子になっていることを確認することが非常に重要なことです。
 例えば、
 
 ```php
@@ -357,8 +351,7 @@ return [
 \Yii::endProfile('block1');
 ```
 
-`\Yii::endProfile('block1')` を忘れたり、`\Yii::endProfile('block1')` と `\Yii::endProfile('block2')`
-の順序を入れ替えたりすると、パフォーマンスプロファイリングは機能しません。
+`\Yii::endProfile('block1')` を忘れたり、`\Yii::endProfile('block1')` と `\Yii::endProfile('block2')` の順序を入れ替えたりすると、パフォーマンスプロファイリングは機能しません。
 
 プロファイルされるコードブロックの全てについて、おのおの、重大性レベルが `profile` であるログメッセージが記録されます。
 そのようなメッセージを集めてエクスポートする [ログターゲット](#log-targets) を構成してください。

docs/guide-ja/runtime-overview.md

 概要
 ====
 
-Yii のアプリケーションがリクエストを処理するときは、毎回、同じような作業の流れを経験します。
+Yii のアプリケーションがリクエストを処理するときは、毎回、同じようなワークフローになります。
 
 1. ユーザが [エントリスクリプト](structure-entry-scripts.md) `web/index.php` にリクエストをします。
 2. エントリスクリプトは、アプリケーションの [構成情報](concept-configurations.md) をロードして、リクエストを処理するための [アプリケーション](structure-applications.md) のインスタンスを作成します。

docs/guide-ja/runtime-requests.md

@@ -58,7 +58,7 @@ $param = $request->getBodyParam('id');
 ## リクエストメソッド <span id="request-methods"></span>
 
 現在のリクエストに使用された HTTP メソッドは、`Yii::$app->request->method` という式によって取得することが出来ます。
-現在のメソッドが特定のタイプであるかどうかをチェックするための、一連の真偽値のプロパティも提供されています。
+現在のメソッドが特定のタイプであるかどうかをチェックするための、一揃いの真偽値のプロパティも提供されています。
 例えば、
 
 ```php
@@ -80,8 +80,8 @@ if ($request->isPut)  { // リクエストメソッドは PUT }
 * [[yii\web\Request::absoluteUrl|absoluteUrl]]: `http://example.com/admin/index.php/product?id=100` を返します。
   ホスト情報の部分を含んだ URL です。
 * [[yii\web\Request::hostInfo|hostInfo]]: `http://example.com` を返します。URL のホスト情報の部分です。
-* [[yii\web\Request::pathInfo|pathInfo]]: `/product` を返します。エントリスクリプトの後、かつ、クエスチョンマーク (クエリ文字列) の前の部分です。
-* [[yii\web\Request::queryString|queryString]]: `id=100` を返します。クエスチョンマークの後の部分です。
+* [[yii\web\Request::pathInfo|pathInfo]]: `/product` を返します。エントリスクリプトの後、疑問符 (クエリ文字列) の前の部分です。
+* [[yii\web\Request::queryString|queryString]]: `id=100` を返します。疑問符の後の部分です。
 * [[yii\web\Request::baseUrl|baseUrl]]: `/admin` を返します。ホスト情報の後、かつ、エントリスクリプトの前の部分です。
 * [[yii\web\Request::scriptUrl|scriptUrl]]: `/admin/index.php` を返します。パス情報とクエリ文字列を省略した URL です。
 * [[yii\web\Request::serverName|serverName]]: `example.com` を返します。URL の中のホスト名です。
@@ -90,7 +90,7 @@ if ($request->isPut)  { // リクエストメソッドは PUT }
 
 ## HTTP ヘッダ <span id="http-headers"></span> 
 
- [[yii\web\Request::headers]] プロパティによって返される [[yii\web\HeaderCollection|header コレクション]] を通じて、HTTP ヘッダ情報を取得することが出来ます。例えば、
+[[yii\web\Request::headers]] プロパティによって返される [[yii\web\HeaderCollection|header コレクション]] を通じて、HTTP ヘッダ情報を取得することが出来ます。例えば、
 
 ```php
 // $headers は yii\web\HeaderCollection のオブジェクト

docs/guide-ja/runtime-responses.md

@@ -5,8 +5,7 @@
 レスポンスオブジェクトは、HTTP ステータスコード、HTTP ヘッダ、HTTP ボディなどの情報を含みます。
 ウェブアプリケーション開発の最終的な目的は、本質的には、さまざまなリクエストに対してそのようなレスポンスオブジェクトを作成することにあります。
 
-ほとんどの場合は、主として `response` [アプリケーションコンポーネント](structure-application-components.md) を使用すべきです。
-このコンポーネントは、デフォルトでは、[[yii\web\Response]] のインスタンスです。
+ほとんどの場合は、主として、デフォルトでは [[yii\web\Response]] のインスタンスである `response` [アプリケーションコンポーネント](structure-application-components.md) を使用すべきです。
 しかしながら、Yii は、以下で説明するように、あなた自身のレスポンスオブジェクトを作成してエンドユーザに送信することも許容しています。
 
 この節では、レスポンスを構成してエンドユーザに送信する方法を説明します。
@@ -22,7 +21,7 @@
 Yii::$app->response->statusCode = 200;
 ```
 
-けれども、たいていの場合、ステータスコードを明示的に設定する必要はありません。
+ただし、たいていの場合、ステータスコードを明示的に設定する必要はありません。
 これは、[[yii\web\Response::statusCode]] のデフォルト値が 200 であるからです。
 そして、リクエストが失敗したことを示したいときは、下記のように、適切な HTTP 例外を投げることが出来ます。
 
@@ -100,7 +99,7 @@ $response->data = ['message' => 'hello world'];
 
 Yii は下記の形式を初めからサポートしています。
 それぞれ、[[yii\web\ResponseFormatterInterface|フォーマッタ]] クラスとして実装されています。
-[[yii\web\Response::formatters]] プロパティを構成することで、これらのフォーマッタをカスタマイズしたり、または、新しいフォーマッタを追加することが出来ます。
+[[yii\web\Response::formatters]] プロパティを構成することで、これらのフォーマッタをカスタマイズしたり、新しいフォーマッタを追加したりすることが出来ます。
 
 * [[yii\web\Response::FORMAT_HTML|HTML]]: [[yii\web\HtmlResponseFormatter]] によって実装
 * [[yii\web\Response::FORMAT_XML|XML]]: [[yii\web\XmlResponseFormatter]] によって実装
@@ -177,7 +176,7 @@ public function actionOld()
 上記のコードでは、アクションメソッドが `redirect()` メソッドの結果を返しています。
 前に説明したように、アクションメソッドによって返されるレスポンスオブジェクトが、エンドユーザに送信されるレスポンスとして使用されることになります。
 
-アクションメソッド以外の場所では、[[yii\web\Response::redirect()]] を直接に呼び出し、メソッドチェーンで [[yii\web\Response::send()]] メソッドを呼んで、レスポンスに余計なコンテントが追加されないことを保証すべきです。
+アクションメソッド以外の場所では、[[yii\web\Response::redirect()]] を直接に呼び出し、メソッドチェーンで [[yii\web\Response::send()]] メソッドを呼んで、レスポンスに余計なコンテントが追加されないことを保証しなければなりません。
 
 ```php
 \Yii::$app->response->redirect('http://example.com/new', 301)->send();
@@ -191,7 +190,7 @@ public function actionOld()
 この問題を解決するために、[[yii\web\Response::redirect()]] メソッドは `X-Redirect` ヘッダにリダイレクト先 URL を値としてセットします。
 そして、クライアントサイドで、このヘッダの値を読み、それに応じてブラウザをリダイレクトする JavaScript を書くことが出来ます。
 
-> Info|情報: Yii には `yii.js` という JavaScript ファイルが付いています。
+> Info|情報: Yii には `yii.js` という JavaScript ファイルが付属しています。
 これは、よく使われる一連の JavaScript 機能を提供するもので、その中には `X-Redirect` ヘッダに基づくブラウザのリダイレクトも含まれています。
 従って、あなたが ([[yii\web\YiiAsset]] アセットバンドルを登録して) この JavaScript ファイルを使うつもりなら、AJAX のリダイレクトをサポートするためには、何も書く必要がなくなります。
 
@@ -216,7 +215,7 @@ public function actionDownload()
 }
 ```
 
-ファイル送信メソッドをアクションメソッド以外の場所で呼ぶ場合は、その後で [[yii\web\Response::send()]] メソッドも呼んで、レスポンスに余計なコンテントが追加されないことを保証すべきです。
+ファイル送信メソッドをアクションメソッド以外の場所で呼ぶ場合は、その後で [[yii\web\Response::send()]] メソッドも呼んで、レスポンスに余計なコンテントが追加されないことを保証しなければなりません。
 
 ```php
 \Yii::$app->response->sendFile('path/to/file.txt')->send();
@@ -254,5 +253,5 @@ public function actionDownload()
 [[yii\web\Response::send()]] メソッドが一度呼び出された後では、このメソッドに対する更なる呼び出しは無視されます。
 このことは、いったんレスポンスが送出された後では、それにコンテントを追加することは出来なくなる、ということを意味します。
 
-ごらんのように、the [[yii\web\Response::send()]] メソッドはいくつかの有用なイベントをトリガします。
+ごらんのように、[[yii\web\Response::send()]] メソッドはいくつかの有用なイベントをトリガします。
 これらのイベントに反応することによって、レスポンスを調整したり修飾したりすることが出来ます。

docs/guide-ja/runtime-routing.md

@@ -6,12 +6,11 @@ Yii 縺ｮ繧｢繝励Μ繧ｱ繝ｼ繧ｷ繝ｧ繝ｳ縺後Μ繧ｯ繧ｨ繧ｹ繝医＆繧後◆ URL 縺ｮ蜃ｦ逅ｒ髢句ｧ
 このプロセスの全体が *ルーティング* と呼ばれます。
 
 ルーティングの逆のプロセスが *URL 生成* と呼ばれます。
-これは、与えられたルートとそれに結び付いたクエリパラメータからURL を生成するものです。
-生成された URL が後でリクエストされたとき、ルーティングのプロセスは、その URL を解決して、元のルートとクエリパラメータに戻すことが出来ます。
+これは、与えられたルートとそれに結び付けられたクエリパラメータから URL を生成するものです。
+生成された URL が後でリクエストされたときには、ルーティングのプロセスがその URL を解決して元のルートとクエリパラメータに戻すことが出来ます。
 
-ルーティングと URL 生成について責任を持つ主要コンポーネントが [[yii\web\UrlManager|URL マネージャ]] であり、`urlManager` アプリケーションコンポーネントとして登録されているものです。
-[[yii\web\UrlManager|URL マネージャ]] は、入ってくるリクエストをルートとそれに結び付いたクエリパラメータとして解析するための [[yii\web\UrlManager::parseRequest()|parseRequest()]] メソッドと、
-与えられたルートとそれに結び付いたクエリパラメータから URL を生成するための [[yii\web\UrlManager::createUrl()|createUrl()]] メソッドを提供するものです。
+ルーティングと URL 生成について主たる役割を果たすのが `urlManager` アプリケーションコンポーネントとして登録されている [[yii\web\UrlManager|URL マネージャ]] です。
+[[yii\web\UrlManager|URL マネージャ]] は、入ってくるリクエストをルートとそれに結び付けられたクエリパラメータとして解析するための [[yii\web\UrlManager::parseRequest()|parseRequest()]] メソッドと、与えられたルートとそれに結び付けられたクエリパラメータから URL を生成するための [[yii\web\UrlManager::createUrl()|createUrl()]] メソッドを提供します。
 
 アプリケーション構成情報の `urlManager` コンポーネントを構成することによって、既存のアプリケーションコードを修正することなく、任意の URL 形式をアプリケーションに認識させることが出来ます。
 例えば、`post/view` アクションのための URL を生成するためには、次のコードを使うことが出来ます。
@@ -23,8 +22,8 @@ use yii\helpers\Url;
 $url = Url::to(['post/view', 'id' => 100]);
 ```
 
-このコードによって生成される URL は、`urlManager` の構成に応じて、下記の形式のうちの一つ (またはその他の形式) になります。
-そしてまた、生成された URL が後でリクエストされたときには、解析されて元のルートとクエリパラメータに戻されます。
+このコードによって生成される URL は、`urlManager` の構成に応じて、下記のどれか (またはその他) になります。
+そして、こうして生成された URL が後でリクエストされた場合には、解析されて元のルートとクエリパラメータの値に戻されます。
 
 ```
 /index.php?r=post/view&id=100
@@ -37,21 +36,20 @@ $url = Url::to(['post/view', 'id' => 100]);
 
 [[yii\web\UrlManager|URL マネージャ]] は二つの URL 形式、すなわち、デフォルトの URL 形式と、綺麗な URL 形式をサポートします。
 
-デフォルトの URL 形式は、`r` というクエリパラメータを使用してルートを表し、通常のクエリパラメータを使用してルートに結び付いたクエリパラメータを表します。
+デフォルトの URL 形式は、`r` というクエリパラメータを使用してルートを表し、通常のクエリパラメータを使用してルートに結び付けられたクエリパラメータを表します。
 例えば、`/index.php?r=post/view&id=100` という URL は、`post/view` というルートと、`id` というクエリパラメータが 100 であることを表します。
 デフォルトの URL 形式は、[[yii\web\UrlManager|URL マネージャ]] についての構成を何も必要とせず、ウェブサーバの設定がどのようなものでも動作します。
 
-綺麗な URL 形式は、エントリスクリプトの名前に続く追加のパスを使用して、ルートとそれに結び付いたクエリパラメータを表します。
+綺麗な URL 形式は、エントリスクリプトの名前に続く追加のパスを使用して、ルートとそれに結び付けられたクエリパラメータを表します。
 例えば、`/index.php/post/100` という URL の追加のパスは `/post/100` ですが、適切な [[yii\web\UrlManager::rules|URL 規則]] があれば、この URL が `post/view` というルートと `id` というクエリパラメータが 100 であることを表すことが出来ます。
 綺麗な URL 形式を使用するためには、URL をどのように表現すべきかという実際の要求に従って、一連の [[yii\web\UrlManager::rules|URL 規則]] を設計する必要があります。
 
-この二つの URL 形式は、[[yii\web\UrlManager|URL マネージャ]] の [[yii\web\UrlManager::enablePrettyUrl|enablePrettyUrl]]
-プロパティを ON/OFF することによって、他のアプリケーションコードを少しも変えることなく、切り替えることが出来ます。
+この二つの URL 形式は、[[yii\web\UrlManager|URL マネージャ]] の [[yii\web\UrlManager::enablePrettyUrl|enablePrettyUrl]] プロパティを ON/OFF することによって、他のアプリケーションコードを少しも変えることなく、切り替えることが出来ます。
 
 
 ## ルーティング <span id="routing"></span>
 
-ルーティングは二つのステップを含みます。最初のステップでは、入ってくるリクエストが解析されて、ルートとそれに結び付いたクエリパラメータに分解されます。
+ルーティングは二つのステップを含みます。最初のステップでは、入ってくるリクエストが解析されて、ルートとそれに結び付けられたクエリパラメータに分解されます。
 そして、第二のステップでは、解析されたルートに対応する [コントローラアクション](structure-controllers.md) がリクエストを処理するために生成されます。
 
 デフォルトの URL 形式を使っている場合は、リクエストからルートを解析することは、`r` という名前の `GET` クエリパラメータを取得するだけの簡単なことです。
@@ -62,21 +60,21 @@ $url = Url::to(['post/view', 'id' => 100]);
 
 いったんリクエストからルートが解析されたら、今度はルートによって特定されるコントローラアクションを生成する番です。
 ルートはその中にあるスラッシュによって複数の部分に分けられます。例えば、`site/index` は `site` と `index` に分割されます。
-その各部分がモジュール、コントローラ、アクションを参照する ID となります。
-アプリケーションは、ルートの中の最初の部分から始めて、下記のステップを踏んで、モジュール (もし有れば)、コントローラ、アクションを生成します。
+その各部分は、モジュール、コントローラ、または、アクションを参照する ID です。
+アプリケーションは、ルートの最初の部分の ID から始めて、下記のステップを踏んで、モジュール (もし有れば)、コントローラ、アクションを生成します。
 
 1. アプリケーションをカレントモジュールとして設定します。
-2. カレントモジュールの [[yii\base\Module::controllerMap|コントローラマップ]] がカレント ID を含むかどうかを調べます。
-   もしそうであれば、マップの中で見つかったコントローラのオブジェクトが構成情報に従って生成されます。
-   そして、ルートの残りの部分を処理するために、ステップ 5 に飛びます。
-3. ID がカレントモジュールの [[yii\base\Module::modules|modules]] プロパティのリストに挙げられたモジュールを指すかどうかを調べます。
-   もしそうであれば、モジュールのリストで見つかったモジュールが構成情報に従って生成されます。
-   そして、ステップ 2 に戻って、新しく生成されたモジュールのコンテキストのもとで、ルートの次の部分を処理します。
-4. ID をコントローラ ID として扱ってコントローラオブジェクトを生成します。
+2. カレントモジュールの [[yii\base\Module::controllerMap|コントローラマップ]] が現在の ID を含むかどうかを調べます。
+   含んでいる場合は、マップの中で見つかった構成情報に従ってコントローラのオブジェクトが生成されます。
+   そして、ステップ 5 に跳んで、ルートの残りの部分を処理します。
+3. 現在の ID がカレントモジュールの [[yii\base\Module::modules|modules]] プロパティのリストに挙げられたモジュールを指すものかどうかを調べます。
+   もしそうであれば、モジュールのリストで見つかった構成情報に従ってモジュールが生成されます。
+   そして、新しく生成されたモジュールのコンテキストのもとで、ステップ 2 に戻って、ルートの次の部分を処理します。
+4. 現在の ID をコントローラ ID として扱ってコントローラオブジェクトを生成します。
    そしてルートの残りの部分を持って次のステップに進みます。
-5. コントローラは、[[yii\base\Controller::actions()|アクションマップ]] の中にカレント ID があるかどうかを調べます。
-   もし有れば、マップの中で見つかったアクションを構成情報に従って生成します。
-   もし無ければ、カレント ID に対応するアクションメソッドによって定義されるインラインアクションを生成しようと試みます。
+5. コントローラは、[[yii\base\Controller::actions()|アクションマップ]] の中に現在の ID があるかどうかを調べます。
+   もし有れば、マップの中で見つかった構成情報に従ってアクションを生成します。
+   もし無ければ、現在の ID に対応するアクションメソッドで定義されるインラインアクションを生成しようと試みます。
 
 上記のステップの中で、何かエラーが発生すると、[[yii\web\NotFoundHttpException]] が投げられて、ルーティングのプロセスが失敗したことが示されます。
 
@@ -109,14 +107,12 @@ $url = Url::to(['post/view', 'id' => 100]);
 
 上記の構成によって、入ってくる全てのリクエストを処理するために `site/offline` アクションが使われるようになります。
 
-`catchAll` プロパティは配列を取り、最初の要素はルートを指定し、残りの要素 (「名前-値」のペア) は
-[アクションのパラメータ](structure-controllers.md#action-parameters) を指定するものでなければなりません。
+`catchAll` プロパティは配列を取り、最初の要素はルートを指定し、残りの要素 (「名前-値」のペア) は [アクションのパラメータ](structure-controllers.md#action-parameters) を指定するものでなければなりません。
 
 
 ## URL を生成する <span id="creating-urls"></span>
 
-Yii は、与えられたルートとそれに結び付けられるクエリパラメータからさまざまな URL を生成する
-[[yii\helpers\Url::to()]] というヘルパメソッドを提供しています。例えば、
+Yii は、与えられたルートとそれに結び付けられたクエリパラメータからさまざまな URL を生成する [[yii\helpers\Url::to()]] というヘルパメソッドを提供しています。例えば、
 
 ```php
 use yii\helpers\Url;
@@ -171,9 +167,7 @@ echo Url::to(['/post/index']);
 echo Url::to(['@posts']);
 ```
 
-[[yii\helpers\Url::to()]] メソッドは、[[yii\web\UrlManager|URL マネージャ]] の
-[[yii\web\UrlManager::createUrl()|createUrl()]] メソッド、および、[[yii\web\UrlManager::createAbsoluteUrl()|createAbsoluteUrl()]]
-を呼び出すことによって実装されています。
+[[yii\helpers\Url::to()]] メソッドは、[[yii\web\UrlManager|URL マネージャ]] の [[yii\web\UrlManager::createUrl()|createUrl()]] メソッド、および、[[yii\web\UrlManager::createAbsoluteUrl()|createAbsoluteUrl()]] を呼び出すことによって実装されています。
 次に続くいくつかの項では、[[yii\web\UrlManager|URL マネージャ]] を構成して、生成される URL の形式をカスタマイズする方法を説明します。
 
 [[yii\helpers\Url::to()]] メソッドは、特定のルートとの関係を持たない URL の生成もサポートしています。
@@ -238,11 +232,11 @@ echo Url::previous();
 その他のプロパティはオプションですが、上記で示されている構成が最もよく用いられているものです。
 
 * [[yii\web\UrlManager::showScriptName|showScriptName]]: このプロパティは、生成される URL にエントリスクリプトを含めるべきかどうかを決定します。
-例えば、このプロパティを false にすると、`/index.php/post/100` という URL を生成する代りに、`/post/100` という URL を生成することが出来ます。
+  例えば、このプロパティを false にすると、`/index.php/post/100` という URL を生成する代りに、`/post/100` という URL を生成することが出来ます。
 * [[yii\web\UrlManager::enableStrictParsing|enableStrictParsing]]: このプロパティは、厳密なリクエスト解析を有効にするかどうかを決定します。
   厳密な解析が有効にされた場合、リクエストされた URL が有効なリクエストとして扱われるためには、それが [[yii\web\UrlManager::rules|rules]] の少なくとも一つに合致しなければなりません。
   そうでなければ、[[yii\web\NotFoundHttpException]] が投げられます。
-  厳密な解析が無効にされると、リクエストされた URL が [[yii\web\UrlManager::rules|rules]] のどれにも合致しない場合は、URL のパス情報の部分がリクエストされたルートとして扱われます。
+  厳密な解析が無効にされた場合は、リクエストされた URL が [[yii\web\UrlManager::rules|rules]] のどれにも合致しない場合は、URL のパス情報の部分がリクエストされたルートとして扱われます。
 * [[yii\web\UrlManager::rules|rules]]: このプロパティが URL を解析および生成するための一連の規則を含みます。
   このプロパティが、アプリケーションの固有の要求を満たす形式を持つ URL を生成するために、あなたが主として使うプロパティです。
 
@@ -257,10 +251,9 @@ URL 隕丞援縺ｯ [[yii\web\UrlRule]] 縺ｾ縺溘縺昴蟄舌け繝ｩ繧ｹ縺ｮ繧､繝ｳ繧ｹ繧ｿ繝ｳ
 URL 規則は、パターンがリクエストされた URL と合致する場合に、リクエストの解析に使用することが出来ます。
 また、URL 規則は、ルートとクエリパラメータ名が与えられたものと合致する場合に、URL の生成に使用することが出来ます。
 
-綺麗な URL 形式が有効にされている場合、[[yii\web\UrlManager|URL マネージャ]] は、その [[yii\web\UrlManager::rules|rules]]
-プロパティに宣言されている URL 規則を使って、入ってくるリクエストの解析と URL の生成を行います。
+綺麗な URL 形式が有効にされている場合、[[yii\web\UrlManager|URL マネージャ]] は、その [[yii\web\UrlManager::rules|rules]] プロパティに宣言されている URL 規則を使って、入ってくるリクエストの解析と URL の生成を行います。
 具体的に言えば、入ってくるリクエストを解析するためには、[[yii\web\UrlManager|URL マネージャ]] は宣言されている順に規則を調べて、リクエストされた URL に合致する *最初の* 規則を探します。
-そして、その合致する規則を使って URL を解析して、ルートとそれと結合されたパラメータを得ます。
+そして、その合致する規則を使って URL を解析して、ルートとそれに結び付けられたパラメータを得ます。
 同じように、URL を生成するためには、[[yii\web\UrlManager|URL マネージャ]] は、与えられたルートとパラメータに合致する最初の規則を探して、それを使って URL を生成します。
 
 [[yii\web\UrlManager::rules]] は、パターンをキーとし、それに対応するルートを値とする配列として構成することが出来ます。
@@ -280,7 +273,7 @@ URL 隕丞援縺ｯ縲√ヱ繧ｿ繝ｼ繝ｳ縺後Μ繧ｯ繧ｨ繧ｹ繝医＆繧後◆ URL 縺ｨ蜷郁縺吶ｋ蝣ｴ蜷
 例えば、`/index.php/post/100?source=ad` のパス情報は `post/100` であり (先頭と末尾のスラッシュは無視します)、これは `post/(\d+)` というパターンに合致します。
 
 URL 規則は、「パターン - ルート」のペアとして宣言する以外に、構成情報配列として宣言することも出来ます。
-すべての構成情報配列が、それぞれ、一つの URL 規則のオブジェクトを構成するために使われます。
+構成情報の一つの配列が、それぞれ、一つの URL 規則のオブジェクトを構成するために使われます。
 この形式は、URL 規則の他のプロパティを構成したい場合に、よく必要になります。
 例えば、
 
@@ -296,7 +289,7 @@ URL 隕丞援縺ｯ縲√後ヱ繧ｿ繝ｼ繝ｳ - 繝ｫ繝ｼ繝医阪繝壹い縺ｨ縺励※螳｣險縺吶ｋ莉･
 ]
 ```
 
-規則の構成情報で `class` を指定しない場合は、デフォルトとして、[[yii\web\UrlRule]] が使われます。
+URL 規則の構成情報で `class` を指定しない場合は、デフォルトとして、[[yii\web\UrlRule]] が使われます。
 
 
 ### 名前付きパラメータ <span id="named-parameters"></span>
@@ -305,10 +298,10 @@ URL 隕丞援縺ｯ縲√ヱ繧ｿ繝ｼ繝ｳ縺ｮ荳ｭ縺ｧ `<ParamName:RgExp>` 縺ｮ蠖｢蠑上〒謖ｮ壹＆
 ここで、`ParamName` はパラメータ名を指定し、`RegExp` はパラメータの値との照合に使われるオプションの正規表現を指定するものです。
 `RegExp` が指定されていない場合は、パラメータの値がスラッシュを含まない文字列であるべきことを意味します。
 
-> Note|注意: 正規表現はパラメータに対してのみ指定できます。パターンの残りの部分は平文テキストであると見なされます。
+> Note|注意: 正規表現はパラメータに対してのみ指定できます。パターンの残りの部分はプレーンテキストとして解釈されます。
 
-規則が URL の解析に使われるときには、結び付けられたパラメータに、URL の対応する部分に合致する値が入れられます。
-そして、これらのパラメータは、後に `request` アプリケーションコンポーネントによって、`$_GET` に入れられて利用できるようになります。
+規則が URL の解析に使われるときには、URL の対応する部分に合致した値が、結び付けられたパラメータに入れられます。
+そして、そのパラメータは、後に `request` アプリケーションコンポーネントによって、`$_GET` に入れられて利用できるようになります。
 規則が URL の生成に使われるときは、提供されたパラメータの値を受けて、パラメータが宣言されている所にその値が挿入されます。
 
 名前付きパラメータの動作を説明するためにいくつかの例を挙げましょう。次の三つの URL 規則を宣言したと仮定してください。
@@ -361,11 +354,11 @@ URL 隕丞援縺ｮ繝ｫ繝ｼ繝医↓縺ｯ繝代Λ繝｡繝ｼ繧ｿ蜷阪ｒ蝓九ａ霎ｼ繧縺薙→縺悟譚･縺ｾ
 > Info|情報: ルートをパラメータ化することによって、URL 規則の数を大幅に減らすことが可能になり、[[yii\web\UrlManager|URL マネージャ]] のパフォーマンスを目に見えて改善することが出来ます。
   
 デフォルトでは、規則の中で宣言されたパラメータは必須となります。
-リクエストされた URL が特定のパラメータを含まない場合や、URL が特定のパラメータなしで生成される場合には、規則は適用されません。
+リクエストされた URL が特定のパラメータを含まない場合や、特定のパラメータなしで URL を生成する場合には、規則は適用されません。
 パラメータのどれかをオプション扱いにしたい場合は、規則の [[yii\web\UrlRule::defaults|defaults]] プロパティを構成することが出来ます。
-このプロパティのリストに挙げられたパラメータはオプション扱いとなり、規定されなかった場合は指定された値を取るようになります。
+このプロパティのリストに挙げられたパラメータはオプション扱いとなり、提供されなかった場合は指定された値を取るようになります。
 
-次の規則の宣言においては、`page` と `tag` のパラメータは両方ともオプション扱いで、規定されなかった場合は、それぞれ、1 と空文字列を取ります。
+次の規則の宣言においては、`page` と `tag` のパラメータは両方ともオプション扱いで、提供されなかった場合は、それぞれ、1 と空文字列を取ります。
 
 ```php
 [
@@ -438,8 +431,7 @@ URL 隕丞援縺ｮ繝代ち繝ｼ繝ｳ縺ｫ縺ｯ縲√え繧ｧ繝悶し繝ｼ繝仙錐繧貞性繧縺薙→縺悟譚･
 ]
 ```
 
-上記の構成によって、[[yii\web\UrlManager|URL マネージャ]] は、接尾辞として `.html` の付いた URL
-を認識し、また、生成するようになります。
+上記の構成によって、[[yii\web\UrlManager|URL マネージャ]] は、接尾辞として `.html` の付いた URL を認識し、また、生成するようになります。
 
 > Tip|ヒント: URL が全てスラッシュで終るようにするためには、URL 接尾辞として `/` を設定することが出来ます。
 

docs/guide-ja/runtime-sessions-cookies.md

 セッションとクッキー
 ====================
 
-セッションとクッキーは、データが複数のユーザリクエストを超えて持続することを可能にします。
+セッションとクッキーは、データが複数回のユーザリクエストにまたがって持続することを可能にします。
 素の PHP では、それぞれ、グローバル変数 `$_SESSION` と `$_COOKIE` によってアクセスすることが出来ます。
 Yii はセッションとクッキーをオブジェクトとしてカプセル化し、オブジェクト指向の流儀でアクセスできるようにするとともに、有用な機能強化を追加しています。
 
@@ -42,27 +42,27 @@ $session->destroy();
 ```php
 $session = Yii::$app->session;
 
-// セッション変数を取得する。次の三つの用法は同義。
+// セッション変数を取得する。次の三つの用法は等価。
 $language = $session->get('language');
 $language = $session['language'];
 $language = isset($_SESSION['language']) ? $_SESSION['language'] : null;
 
-// セッション変数を設定する。次の三つの用法は同義。
+// セッション変数を設定する。次の三つの用法は等価。
 $session->set('language', 'en-US');
 $session['language'] = 'en-US';
 $_SESSION['language'] = 'en-US';
 
-// セッション変数を削除する。次の三つの用法は同義。
+// セッション変数を削除する。次の三つの用法は等価。
 $session->remove('language');
 unset($session['language']);
 unset($_SESSION['language']);
 
-// セッション変数が存在するかどうかをチェックする。次の三つの用法は同義。
+// セッション変数が存在するかどうかをチェックする。次の三つの用法は等価。
 if ($session->has('language')) ...
 if (isset($session['language'])) ...
 if (isset($_SESSION['language'])) ...
 
-// 全てのセッション変数をたどる。次の二つの用法は同義。
+// 全てのセッション変数をたどる。次の二つの用法は等価。
 foreach ($session as $name => $value) ...
 foreach ($_SESSION as $name => $value) ...
 ```
@@ -116,7 +116,7 @@ $session['captcha.lifetime'] = 3600;
 ```
 
 パフォーマンスとコードの可読性を高めるためには、最後の回避策を推奨します。
-すなわち、配列を一つのセッション変数として保存する代りに、配列の個々の要素を他の要素と同じキー接頭辞を共有する一つのセッション変数として保存することです。
+すなわち、配列を一つのセッション変数として保存する代りに、配列の個々の要素を他の要素と同じキー接頭辞を共有する一個ずつのセッション変数として保存することです。
 
 
 ### カスタムセッションストレージ <span id="custom-session-storage"></span>
@@ -133,7 +133,7 @@ Yii 縺ｯ縲√∪縺溘√＆縺ｾ縺悶∪縺ｪ繧ｻ繝す繝ｧ繝ｳ繧ｹ繝医Ξ繝ｼ繧ｸ繧貞ｮ溯｣☆繧倶
 その結果として、セッションを使用するアプリケーションコードを修正することなしに、セッションストレージクラスを切り替えることが出来ます。
 
 > Note|注意: カスタムセッションストレージを使っているときに `$_SESSION` を通じてセッションデータにアクセスしたい場合は、セッションが [[yii\web\Session::open()]] によって既に開始されていることを確認しなければなりません。
-  これは、カスタムセッションストレージのハンドラが、このメソッドの中で登録されるからです。
+  これは、カスタムセッションストレージのハンドラは、この `open()` メソッドの中で登録されるからです。
 
 これらのコンポーネントクラスの構成方法と使用方法については、それらの API ドキュメントを参照してください。
 下記の例は、アプリケーションの構成情報において、データベーステーブルをセッションストレージとして使うために [[yii\web\DbSession]] を構成する方法を示すものです。
@@ -223,7 +223,7 @@ $alerts = $session->getFlash('alerts');
 
 Yii は個々のクッキーを [[yii\web\Cookie]] のオブジェクトとして表します。
 [[yii\web\Request]] と [[yii\web\Response]] は、ともに、`cookies` という名前のプロパティによって、クッキーのコレクションを保持します。
-後者のクッキーコレクションはリクエストの中で送信されたクッキーを表し、一方、後者のクッキーコレクションは、ユーザに送信されることになるクッキーを表します。
+後者のクッキーコレクションはリクエストの中で送信されてきたクッキーを表し、一方、後者のクッキーコレクションは、これからユーザに送信されるクッキーを表します。
 
 
 ### クッキーを読み出す <span id="reading-cookies"></span>
@@ -288,9 +288,9 @@ unset($cookies['language']);
 アプリケーションは、サインを見て、クッキーがクライアントサイドで修正されたかどうかを知ることが出来ます。
 もし、修正されていれば、そのクッキーは `request` コンポーネントの [[yii\web\Request::cookies|クッキーコレクション]] からはアクセスすることが出来なくなります。
 
-> Note|注意: クッキー検証はクッキーの値が修正されるのを防止するだけです。
-  クッキーが検証に失敗した場合でも、`$_COOKIE` を通じてそれにアクセスすることは引き続いて可能です。
-  これは、サードパーティのライブラリが、クッキー検証を含まない、ライブラリ自体の方法でクッキーを操作し得るためです。
+> Note|注意: クッキー検証は値が修正されたクッキーの読み込みを防止するだけです。
+  検証に失敗した場合でも、`$_COOKIE` を通じてそのクッキーにアクセスすることは引き続いて可能です。
+  これは、サードパーティのライブラリが、クッキー検証を含まない独自の方法でクッキーを操作することが出来るようにするするためです。
 
 クッキー検証はデフォルトで有効になっています。
 [[yii\web\Request::enableCookieValidation]] プロパティを false に設定することによって無効にすることが出来ますが、無効にしないことを強く推奨します。