Merge pull request #6330 from softark/docs-guide-ja-structure-revised

docs/guide-ja/README.md

-決定版 Yii 2.0 ガイド
-=====================
+Yii 2.0 決定版ガイド
+====================
 
 このチュートリアルは [Yii ドキュメント規約](http://www.yiiframework.com/doc/terms/) の下にリリースされています。
 
@@ -54,7 +54,7 @@ All Rights Reserved.
 * [レスポンス](runtime-responses.md)
 * [セッションとクッキー](runtime-sessions-cookies.md)
 * [エラー処理](runtime-handling-errors.md)
-* [ログ](runtime-logging.md)
+* [ロギング](runtime-logging.md)
 
 
 鍵となる概念

docs/guide-ja/structure-application-components.md

@@ -3,11 +3,10 @@
 
 アプリケーションは [サービスロケータ](concept-service-locator.md) です。
 アプリケーションは、リクエストを処理するためのいろいろなサービスを提供する一連のオブジェクト、いわゆる *アプリケーションコンポーネント* をホストします。
-例えば、`urlManager` がウェブリクエストを適切なコントローラにルーティングする役割を負い、
-`db` コンポーネントが DB 関連のサービスを提供する、等々です。
+例えば、`urlManager` がウェブリクエストを適切なコントローラにルーティングする役割を負い、`db` コンポーネントが DB 関連のサービスを提供する、等々です。
 
 全てのアプリケーションコンポーネントは、それぞれ、同一のアプリケーション内で他のアプリケーションコンポーネントから区別できるように、ユニークな ID を持ちます。
-アプリケーションコンポーネントには、次の式によってアクセス出来ます:
+アプリケーションコンポーネントには、次の式によってアクセス出来ます。
 
 ```php
 \Yii::$app->componentID
@@ -20,7 +19,7 @@
 二度目以降のアクセスでは、同じコンポーネントのインスタンスが返されます。
 
 どのようなオブジェクトでも、アプリケーションコンポーネントとすることが可能です。
-[アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で [[yii\base\Application::components]] プロパティを構成することによって、アプリケーションコンポーネントを登録することが出来ます。
+[アプリケーションの構成情報](structure-applications.md#application-configurations) の中で [[yii\base\Application::components]] プロパティを構成することによって、アプリケーションコンポーネントを登録することが出来ます。
 例えば、
 
 ```php
@@ -29,7 +28,7 @@
         // クラス名を使って "cache" コンポーネントを登録
         'cache' => 'yii\caching\ApcCache',
 
-        // コンフィギュレーション配列を使って "db" コンポーネントを登録
+        // 構成情報の配列を使って "db" コンポーネントを登録
         'db' => [
             'class' => 'yii\db\Connection',
             'dsn' => 'mysql:host=localhost;dbname=demo',
@@ -46,20 +45,19 @@
 ```
 
 > Info|情報: 必要なだけ多くのアプリケーションコンポーネントを登録することが出来ますが、慎重にしなければなりません。
-  アプリケーションコンポーネントはグローバル変数のようなものです。あまり多くのアプリケーションコンポーネントを使うと
-  コードのテストと保守が困難になるおそれがあります。
+  アプリケーションコンポーネントはグローバル変数のようなものです。
+  あまり多くのアプリケーションコンポーネントを使うと、コードのテストと保守が困難になるおそれがあります。
   多くの場合、必要なときにローカルなコンポーネントを作成して使用するだけで十分です。
 
 
 ## コンポーネントをブートストラップに含める<a name="bootstrapping-components"></a>
 
 上述のように、アプリケーションコンポーネントは最初にアクセスされた時に初めてインスタンスが作成されます。
-リクエストの間に全くアクセスされなかった時は、インスタンスは作成されません。けれども、場合によっては、
-明示的にアクセスされないときでも、リクエストごとにアプリケーションコンポーネントのインスタンスを作成する必要がある
-ことがあります。そうするためには、アプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストに
-そういうコンポーネントの ID を挙げることが出来ます。
+リクエストの間に全くアクセスされなかった時は、インスタンスは作成されません。
+けれども、場合によっては、明示的にアクセスされないときでも、リクエストごとにアプリケーションコンポーネントのインスタンスを作成したいことがあります。
+そうするためには、アプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストにそのコンポーネントの ID を挙げることが出来ます。
 
-例えば、次のアプリケーションコンフィギュレーションは、`log` コンポーネントが常にロードされることを保証するものです:
+例えば、次のアプリケーション構成情報は、`log` コンポーネントが常にロードされることを保証するものです。
 
 ```php
 [
@@ -68,7 +66,7 @@
     ],
     'components' => [
         'log' => [
-            // "log" コンポーネントのコンフィギュレーション
+            // "log" コンポーネントの構成情報
         ],
     ],
 ]
@@ -77,43 +75,43 @@
 
 ## コアアプリケーションコンポーネント<a name="core-application-components"></a>
 
-Yii は固定の ID とデフォルトのコンフィギュレーションを持つ一連の *コア* アプリケーションコンポーネントを定義しています。
-例えば、[[yii\web\Application::request|request]] コンポーネントは、ユーザリクエストに関する情報を収集し、
-それを [ルート](runtime-routing.md) として解決します。
-[[yii\base\Application::db|db]] コンポーネントは、それを通じてデータベースクエリを実行できるデータベース接続を表現します。
-Yii のアプリケーションがユーザリクエストを処理することが出来るのは、まさにこれらのコアアプリケーションコンポーネントの助力によります。
+Yii は固定の ID とデフォルトの構成情報を持つ一連の *コア* アプリケーションコンポーネントを定義しています。
+例えば、[[yii\web\Application::request|request]] コンポーネントは、ユーザリクエストに関する情報を収集して、それを [ルート](runtime-routing.md) として解決するために使用されます。
+また、[[yii\base\Application::db|db]] コンポーネントは、それを通じてデータベースクエリを実行できるデータベース接続を表現します。
+Yii のアプリケーションがユーザリクエストを処理出来るのは、まさにこれらのコアアプリケーションコンポーネントの助けがあってこそです。
+
 下記が事前に定義されたコアアプリケーションコンポーネントです。
 通常のアプリケーションコンポーネントに対するのと同様に、これらを構成し、カスタマイズすることが出来ます。
-コアアプリケーションコンポーネントを構成するときは、クラスを指定しなければ、デフォルトのクラスが使用されます。
+コアアプリケーションコンポーネントを構成するときは、クラスを指定しない場合は、デフォルトのクラスが使用されます。
 
 * [[yii\web\AssetManager|assetManager]]: アセットバンドルとアセットの発行を管理します。
-  更なる詳細は [アセットを管理する](structure-assets.md) の節を参照してください。
+  詳細は [アセット](structure-assets.md) の節を参照してください。
 * [[yii\db\Connection|db]]: データベース接続を表します。これを通じて、DB クエリを実行することが出来ます。
   このコンポーネントを構成するときは、コンポーネントのクラスはもちろん、
   [[yii\db\Connection::dsn]] のような必須のコンポーネントプロパティを指定しなければならないことに注意してください。
-  更なる詳細は [データアクセスオブジェクト (DAO)](db-dao.md) の節を参照してください。
+  詳細は [データアクセスオブジェクト](db-dao.md) の節を参照してください。
 * [[yii\base\Application::errorHandler|errorHandler]]: PHP のエラーと例外を処理します。
-  更なる詳細は [エラー処理](runtime-handling-errors.md) の節を参照してください。
+  詳細は [エラー処理](runtime-handling-errors.md) の節を参照してください。
 * [[yii\i18n\Formatter|formatter]]: エンドユーザに表示されるデータに書式を設定します。
   例えば、数字が3桁ごとの区切りを使って表示されたり、日付が長い書式で表示されたりします。
-  更なる詳細は [データの書式設定](output-formatter.md) の節を参照してください。
+  詳細は [データの書式設定](output-formatter.md) の節を参照してください。
 * [[yii\i18n\I18N|i18n]]: メッセージの翻訳と書式設定をサポートします。
-  更なる詳細は [国際化](tutorial-i18n.md) の節を参照してください。
-* [[yii\log\Dispatcher|log]]: ログの対象を管理します。
-  更なる詳細は [ログ](runtime-logging.md) の節を参照してください。
+  詳細は [国際化](tutorial-i18n.md) の節を参照してください。
+* [[yii\log\Dispatcher|log]]: ログターゲットを管理します。
+  詳細は [ロギング](runtime-logging.md) の節を参照してください。
 * [[yii\swiftmailer\Mailer|mail]]: メールの作成と送信をサポートします。
-  更なる詳細は [メール](tutorial-mailing.md) の節を参照してください。
+  詳細は [メール](tutorial-mailing.md) の節を参照してください。
 * [[yii\base\Application::response|response]]: エンドユーザに送信されるレスポンスを表現します。
-  更なる詳細は [レスポンス](runtime-responses.md) の節を参照してください。
+  詳細は [レスポンス](runtime-responses.md) の節を参照してください。
 * [[yii\base\Application::request|request]]: エンドユーザから受信したリクエストを表現します。
-  更なる詳細は [リクエスト](runtime-requests.md) の節を参照してください。
+  詳細は [リクエスト](runtime-requests.md) の節を参照してください。
 * [[yii\web\Session|session]]: セッション情報を表現します。
   このコンポーネントは、[[yii\web\Application|ウェブアプリケーション]] においてのみ利用できます。.
-  更なる詳細は [セッションとクッキー](runtime-sessions-cookies.md) の節を参照してください。
+  詳細は [セッションとクッキー](runtime-sessions-cookies.md) の節を参照してください。
 * [[yii\web\UrlManager|urlManager]]: URL の解析と生成をサポートします。
-  更なる詳細は [URL の解析と生成](runtime-url-handling.md) の節を参照してください。
+  詳細は [ルーティング と URL 生成](runtime-routing.md) の節を参照してください。
 * [[yii\web\User|user]]: ユーザの認証情報を表現します。
   このコンポーネントは、[[yii\web\Application|ウェブアプリケーション]] においてのみ利用できます。.
-  更なる詳細は [認証](security-authentication.md) の節を参照してください。
+  詳細は [認証](security-authentication.md) の節を参照してください。
 * [[yii\web\View|view]]: ビューのレンダリングをサポートします。
-  更なる詳細は [ビュー](structure-views.md) の節を参照してください。
+  詳細は [ビュー](structure-views.md) の節を参照してください。

docs/guide-ja/structure-applications.md

@@ -4,36 +4,35 @@
 アプリケーションは Yii アプリケーションシステム全体の構造とライフサイクルを統制するオブジェクトです。
 全ての Yii アプリケーションシステムは、それぞれ、[エントリスクリプト](structure-entry-scripts.md) において作成され、`\Yii::$app` という式でグローバルにアクセス可能な、単一のアプリケーションオブジェクトを持ちます。
 
-> Info|情報: ガイドの中で「アプリケーション」という言葉は、文脈に応じて、
-アプリケーションオブジェクトを意味したり、アプリケーションシステムを意味したりします。
+> Info|情報: ガイドの中で「アプリケーション」という言葉は、文脈に応じて、アプリケーションオブジェクトを意味したり、アプリケーションシステムを意味したりします。
 
-二種類のアプリケーションがあります: すなわち、[[yii\web\Application|ウェブアプリケーション]] と [[yii\console\Application|コンソールアプリケーション]] です。
+二種類のアプリケーション、すなわち、[[yii\web\Application|ウェブアプリケーション]] と [[yii\console\Application|コンソールアプリケーション]] があります。
 名前が示すように、前者は主にウェブのリクエストを処理し、後者はコンソールコマンドのリクエストを処理します。
 
 
-## アプリケーションのコンフィギュレーション<a name="application-configurations"></a>
+## アプリケーションの構成情報<a name="application-configurations"></a>
 
-[エントリスクリプト](structure-entry-scripts.md) は、アプリケーションを作成するときに、
-下記のように、[コンフィギュレーション](concept-configurations.md) を読み込んで、それをアプリケーションに適用します:
+[エントリスクリプト](structure-entry-scripts.md) は、アプリケーションを作成するときに、下記のように、[構成情報](concept-configurations.md)
+を読み込んで、それをアプリケーションに適用します。
 
 ```php
 require(__DIR__ . '/../vendor/autoload.php');
 require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
 
-// アプリケーションのコンフィギュレーションを読み込む
+// アプリケーションの構成情報を読み込む
 $config = require(__DIR__ . '/../config/web.php');
 
-// アプリケーションのインスタンスを作成し、コンフィギュレーションを適用する
+// アプリケーションのインスタンスを作成し、構成情報を適用する
 (new yii\web\Application($config))->run();
 ```
 
-通常の [コンフィギュレーション](concept-configurations.md) と同じように、アプリケーションのコンフィギュレーションは、アプリケーションオブジェクトのプロパティをどのように初期化するかを規定するものです。
-アプリケーションのコンフィギュレーションは、たいていは非常に複雑なものですから、通常は、上記の例の `web.php` ファイルのように、[コンフィギュレーションファイル](concept-configurations.md#configuration-files) に保管されます。
+通常の [構成情報](concept-configurations.md) と同じように、アプリケーションの構成情報は、アプリケーションオブジェクトのプロパティをどのように初期化するかを指定するものです。
+アプリケーションの構成情報は、たいていは非常に複雑なものですから、通常は、上記の例の `web.php` ファイルのように、[構成情報ファイル](concept-configurations.md#configuration-files) に保管されます。
 
 
 ## アプリケーションのプロパティ<a name="application-properties"></a>
 
-アプリケーションのコンフィギュレーションで構成すべき重要なアプリケーションのプロパティは数多くあります。
+アプリケーションの構成情報で構成すべき重要なアプリケーションのプロパティは数多くあります。
 それらのプロパティの典型的なものは、アプリケーションが走る環境を記述するものです。
 例えば、アプリケーションは、どのようにして [コントローラ](structure-controllers.md) をロードするか、また、どこにテンポラリファイルを保存するかなどを知らなければなりません。
 以下において、それらのプロパティを要約します。
@@ -41,7 +40,7 @@ $config = require(__DIR__ . '/../config/web.php');
 
 ### 必須のプロパティ<a name="required-properties"></a>
 
-どのアプリケーションでも、最低二つのプロパティは構成しなければなりません:
+どのアプリケーションでも、最低二つのプロパティは構成しなければなりません。
 すなわち、[[yii\base\Application::id|id]] と [[yii\base\Application::basePath|basePath]] です。
 
 
@@ -49,7 +48,7 @@ $config = require(__DIR__ . '/../config/web.php');
 
 [[yii\base\Application::id|id]] プロパティは、アプリケーションを他のアプリケーションから区別するユニークな ID を規定します。
 このプロパティは主としてプログラム的に使われます。
-必須ではありませんが、最良の相互運用性を確保するために、アプリケーション ID を規定するときに英数字だけを使うことが推奨されます。
+必須ではありませんが、最良の相互運用性を確保するために、アプリケーション ID を指定するときに英数字だけを使うことが推奨されます。
 
 
 #### [[yii\base\Application::basePath|basePath]] <a name="basePath"></a>
@@ -71,7 +70,7 @@ $config = require(__DIR__ . '/../config/web.php');
 
 ### 重要なプロパティ<a name="important-properties"></a>
 
-この項で説明するプロパティは、アプリケーションが異なるごとに異なってくるものであるため、たいてい、構成する必要が生じます。
+この項で説明するプロパティは、アプリケーションごとに異なってくるものであるため、たいてい、構成する必要が生じます。
 
 
 #### [[yii\base\Application::aliases|aliases]] <a name="aliases"></a>
@@ -89,21 +88,21 @@ $config = require(__DIR__ . '/../config/web.php');
 ]
 ```
 
-このプロパティが提供されているのは、[[Yii::setAlias()]] メソッドを呼び出す代りに、アプリケーションのコンフィギュレーションを使ってエイリアスを定義することが出来るようにするためです。
+このプロパティが提供されているのは、[[Yii::setAlias()]] メソッドを呼び出す代りに、アプリケーションの構成情報を使ってエイリアスを定義することが出来るようにするためです。
 
 
 #### [[yii\base\Application::bootstrap|bootstrap]] <a name="bootstrap"></a>
 
 これは非常に有用なプロパティです。
-これによって、アプリケーションの [[yii\base\Application::bootstrap()|ブートストラップの過程]] において走らせるべきコンポーネントを配列として規定することが出来ます。
-例えば、ある [モジュール](structure-modules.md) に [URL 規則](runtime-url-handling.md) をカスタマイズさせたいときに、モジュールの ID をこのプロパティの要素として挙げることが出来ます。
+これによって、アプリケーションの [[yii\base\Application::bootstrap()|ブートストラップの過程]] において走らせるべきコンポーネントを配列として指定することが出来ます。
+例えば、ある [モジュール](structure-modules.md) に [URL 規則](runtime-routing.md) をカスタマイズさせたいときに、モジュールの ID をこのプロパティの要素として挙げることが出来ます。
 
-このプロパティに挙げるコンポーネントは、それぞれ、以下の形式のいずれかによって規定することが出来ます:
+このプロパティに挙げるコンポーネントは、それぞれ、以下の形式のいずれかによって指定することが出来ます。
 
-- [components](#components) によって規定されるアプリケーションコンポーネントの ID。
-- [modules](#modules) によって規定されるモジュールの ID。
+- [components](#components) によって指定されているアプリケーションコンポーネントの ID。
+- [modules](#modules) によって指定されているモジュールの ID。
 - クラス名。
-- コンフィギュレーション配列。
+- 構成情報の配列。
 - コンポーネントを作成して返す無名関数。
 
 例えば、
@@ -117,7 +116,7 @@ $config = require(__DIR__ . '/../config/web.php');
         // クラス名
         'app\components\Profiler',
 
-        // コンフィギュレーション配列
+        // 構成情報の配列
         [
             'class' => 'app\components\Profiler',
             'level' => 3,
@@ -132,7 +131,7 @@ $config = require(__DIR__ . '/../config/web.php');
 ```
 
 > Info|情報: モジュール ID と同じ ID のアプリケーションコンポーネントがある場合は、ブートストラップの過程ではアプリケーションコンポーネントが使われます。
-  代りにモジュールを使いたいときは、次のように、無名関数を使って指定することが出来ます:
+  代りにモジュールを使いたいときは、次のように、無名関数を使って指定することが出来ます。
 > ```php
 [
     function () {
@@ -144,12 +143,12 @@ $config = require(__DIR__ . '/../config/web.php');
 ブートストラップの過程で、各コンポーネントのインスタンスが作成されます。
 そして、コンポーネントクラスが [[yii\base\BootstrapInterface]] を実装している場合は、その [[yii\base\BootstrapInterface::bootstrap()|bootstrap()]] メソッドも呼び出されます。
 
-もう一つの実用的な例が [ベーシックアプリケーションテンプレート](start-installation.md) のアプリケーションのコンフィギュレーションの中にあります。
+もう一つの実用的な例が [ベーシックアプリケーションテンプレート](start-installation.md) のアプリケーションの構成情報の中にあります。
 そこでは、アプリケーションが開発環境で走るときには `debug` モジュールと `gii` モジュールがブートストラップコンポーネントとして構成されています。
 
 ```php
 if (YII_ENV_DEV) {
-    // 'dev' 環境のためのコンフィギュレーションの調整
+    // 'dev' 環境のための構成情報の調整
     $config['bootstrap'][] = 'debug';
     $config['modules']['debug'] = 'yii\debug\Module';
 
@@ -166,10 +165,10 @@ if (YII_ENV_DEV) {
 #### [[yii\web\Application::catchAll|catchAll]] <a name="catchAll"></a>
 
 このプロパティは [[yii\web\Application|ウェブアプリケーション]] においてのみサポートされます。
-これは、全てのユーザリクエストを処理すべき [コントローラアクション](structure-controllers.md) を規定します。
+これは、全てのユーザリクエストを処理すべき [コントローラアクション](structure-controllers.md) を指定するものです。
 これは主としてアプリケーションがメンテナンスモードにあって、入ってくる全てのリクエストを単一のアクションで処理する必要があるときに使われます。
 
-コンフィギュレーションは配列の形を取り、最初の要素はアクションのルートを指定します。
+構成情報は配列の形を取り、最初の要素はアクションのルートを指定します。
 そして、配列の残りの要素 (キー・値のペア) は、アクションに渡されるパラメータを指定します。
 例えば、
 
@@ -186,7 +185,8 @@ if (YII_ENV_DEV) {
 
 #### [[yii\base\Application::components|components]] <a name="components"></a>
 
-これが唯一最重要なプロパティです。これによって、[アプリケーションコンポーネント](structure-application-components.md) と呼ばれる一連の名前付きのコンポーネントを登録して、それらを他の場所で使うことが出来るようになります。
+これこそが、唯一最重要なプロパティです。
+これによって、[アプリケーションコンポーネント](structure-application-components.md) と呼ばれる一連の名前付きのコンポーネントを登録して、それらを他の場所で使うことが出来るようになります。
 例えば、
 
 ```php
@@ -204,12 +204,12 @@ if (YII_ENV_DEV) {
 ```
 
 全てのアプリケーションコンポーネントは、それぞれ、配列の中で「キー・値」のペアとして規定されます。
-キーはコンポーネントの ID を示し、値はコンポーネントのクラス名または [コンフィギュレーション](concept-configurations.md) を示します。
+キーはコンポーネントの ID を示し、値はコンポーネントのクラス名または [構成情報](concept-configurations.md) を示します。
 
 どのようなコンポーネントでもアプリケーションとともに登録することが出来ます。
 そして登録されたコンポーネントは、後で、`\Yii::$app->ComponentID` という式を使ってグローバルにアクセスすることが出来ます。
 
-詳細は [アプリケーションコンポーネント](structure-application-components.md) の節を呼んでください。
+詳細は [アプリケーションコンポーネント](structure-application-components.md) の節を読んでください。
 
 
 #### [[yii\base\Application::controllerMap|controllerMap]] <a name="controllerMap"></a>
@@ -218,8 +218,7 @@ if (YII_ENV_DEV) {
 既定では、Yii は [規約](#controllerNamespace) に基づいてコントローラ ID をコントローラクラスに割り付けます
 (例えば、`post` という ID は `app\controllers\PostController` に割り付けられます)。
 このプロパティを構成することによって、特定のコントローラに対する規約を破ることが出来ます。
-下記の例では、`account` は `app\controllers\UserController` に割り付けられ、
-`article` は `app\controllers\PostController` に割り付けられることになります。
+下記の例では、`account` は `app\controllers\UserController` に割り付けられ、`article` は `app\controllers\PostController` に割り付けられることになります。
 
 ```php
 [
@@ -235,22 +234,21 @@ if (YII_ENV_DEV) {
 ]
 ```
 
-このプロパティの配列のキーはコントローラ ID を表し、配列の値は対応するコントローラクラスの名前または [コンフィギュレーション](concept-configurations.md) を表します。
+このプロパティの配列のキーはコントローラ ID を表し、配列の値は対応するコントローラクラスの名前または [構成情報](concept-configurations.md) を表します。
 
 
 #### [[yii\base\Application::controllerNamespace|controllerNamespace]] <a name="controllerNamespace"></a>
 
 このプロパティは、コントローラクラスが配置されるべき既定の名前空間を指定するものです。
 デフォルト値は `app\controllers` です。
-コントローラ ID が `post` である場合、規約によって対応するコントローラの (名前空間を略した) クラス名は `PostController` となり、
-完全修飾クラス名は `app\controllers\PostController` となります。
+コントローラ ID が `post` である場合、規約によって対応するコントローラの (名前空間を略した) クラス名は `PostController`
+となり、完全修飾クラス名は `app\controllers\PostController` となります。
 
 コントローラクラスは、この名前空間に対応するディレクトリのサブディレクトリに配置されても構いません。
 例えば、コントローラ ID として `admin/post` を仮定すると、対応するコントローラの完全修飾クラス名は `app\controllers\admin\PostController` となります。
 
-完全修飾のコントローラクラスが [オートロード可能](concept-autoloading.md) でなければならず、
-コントローラクラスの実際の名前空間がこのプロパティと合致していなければならない、
-ということは非常に重要なことです。
+重要なことは、完全修飾されたコントローラクラスが [オートロード可能](concept-autoloading.md) でなければならず、
+コントローラクラスの実際の名前空間がこのプロパティと合致していなければならない、ということです。
 そうでないと、アプリケーションにアクセスしたときに "ページがみつかりません" というエラーを受け取ることになります。
 
 上述の規約を破りたい場合は、[controllerMap](#controllerMap) プロパティを構成することが出来ます。
@@ -268,15 +266,15 @@ if (YII_ENV_DEV) {
 言語を指定するのには、[IETF 言語タグ](http://ja.wikipedia.org/wiki/IETF%E8%A8%80%E8%AA%9E%E3%82%BF%E3%82%B0) に従うことが推奨されます。
 例えば、`en` は英語を意味し、`en-US` はアメリカ合衆国の英語を意味します。
 
-このプロパティに関する更なる詳細は [国際化](tutorial-i18n.md) の節で読むことが出来ます。
+このプロパティに関する詳細は [国際化](tutorial-i18n.md) の節で読むことが出来ます。
 
 
 #### [[yii\base\Application::modules|modules]] <a name="modules"></a>
 
 このプロパティはアプリケーションが含む [モジュール](structure-modules.md) を規定します。
 
-このプロパティは、モジュールのクラスまたは [コンフィギュレーション](concept-configurations.md) の配列であり、
-その配列のキーはモジュールの ID です。例えば、
+このプロパティは、モジュールの ID をキーとする、モジュールのクラスまたは [構成情報](concept-configurations.md) の配列です。
+例えば、
 
 ```php
 [
@@ -284,7 +282,7 @@ if (YII_ENV_DEV) {
         // モジュールクラスで規定された "booking" モジュール
         'booking' => 'app\modules\booking\BookingModule',
 
-        // コンフィギュレーション配列で規定された "comment" モジュール
+        // 構成情報の配列で規定された "comment" モジュール
         'comment' => [
             'class' => 'app\modules\comment\CommentModule',
             'db' => 'db',
@@ -298,9 +296,8 @@ if (YII_ENV_DEV) {
 
 #### [[yii\base\Application::name|name]] <a name="name"></a>
 
-このプロパティはアプリケーション名を規定します。これは、エンドユーザに対して表示されるかも知れません。
-[[yii\base\Application::id|id]] プロパティがユニークな値でなければならないのとは違って、このプロパティの値は
-主として表示目的であり、ユニークである必要はありません。
+このプロパティはアプリケーション名を規定します。これは、エンドユーザに対して表示されるかも知れません。[[yii\base\Application::id|id]]
+プロパティがユニークな値でなければならないのとは違って、このプロパティの値は主として表示目的であり、ユニークである必要はありません。
 
 コードで使わないのであれば、このプロパティを構成する必要はありません。
 
@@ -308,9 +305,8 @@ if (YII_ENV_DEV) {
 #### [[yii\base\Application::params|params]] <a name="params"></a>
 
 このプロパティは、グローバルにアクセス可能なアプリケーションパラメータの配列を規定します。
-コードの中のいたる処でハードコードされた数値や文字列を使う代りに、それらをアプリケーションパラメータとして
-一ヶ所で定義し、必要な場所ではそのパラメータを使うというのが良い慣行です。
-例えば、次のように、サムネール画像のサイズをパラメータとして定義することが出来ます:
+コードの中のいたる処でハードコードされた数値や文字列を使う代りに、それらをアプリケーションパラメータとして一ヶ所で定義し、必要な場所ではそのパラメータを使うというのが良い慣行です。
+例えば、次のように、サムネール画像のサイズをパラメータとして定義することが出来ます。
 
 ```php
 [
@@ -320,15 +316,14 @@ if (YII_ENV_DEV) {
 ]
 ```
 
-そして、このサイズの値を使う必要があるコードにおいては、ただ単に下記のようなコードを使うことが出来ます:
+そして、このサイズの値を使う必要があるコードにおいては、下記のようなコードを使うだけで済ませることが出来ます。
 
 ```php
 $size = \Yii::$app->params['thumbnail.size'];
 $width = \Yii::$app->params['thumbnail.size'][0];
 ```
 
-後でサムネールのサイズを変更すると決めたときは、アプリケーションのコンフィギュレーションにおいてのみサイズを修正すればよく、
-これに依存するコードには少しも触れる必要がありません。
+後でサムネールのサイズを変更すると決めたときは、アプリケーションの構成情報においてのみサイズを修正すればよく、これに依存するコードには少しも触れる必要がありません。
 
 
 #### [[yii\base\Application::sourceLanguage|sourceLanguage]] <a name="sourceLanguage"></a>
@@ -339,7 +334,7 @@ $width = \Yii::$app->params['thumbnail.size'][0];
 [language](#language) プロパティと同様に、このプロパティは [IETF 言語タグ](http://ja.wikipedia.org/wiki/IETF%E8%A8%80%E8%AA%9E%E3%82%BF%E3%82%B0) に従って構成すべきです。
 例えば、`en` は英語を意味し、`en-US` はアメリカ合衆国の英語を意味します。
 
-このプロパティに関する更なる詳細は [国際化](tutorial-i18n.md) の節で読むことが出来ます。
+このプロパティに関する詳細は [国際化](tutorial-i18n.md) の節で読むことが出来ます。
 
 
 #### [[yii\base\Application::timeZone|timeZone]] <a name="timeZone"></a>
@@ -363,27 +358,26 @@ $width = \Yii::$app->params['thumbnail.size'][0];
 
 ### 有用なプロパティ <a name="useful-properties"></a>
 
-この項で説明されるプロパティは通常は構成されません。というのは、そのデフォルト値が通常の規約を規定するものだからです。
+この項で説明されるプロパティは通常は構成されません。というのは、そのデフォルト値が通常の規約を指定しているからです。
 しかしながら、規約を破る必要がある場合には、これらのプロパティを構成することが出来ます。
 
 
 #### [[yii\base\Application::charset|charset]] <a name="charset"></a>
 
-このプロパティはアプリケーションが使う文字セットを規定します。デフォルト値は `'UTF-8'` であり、
-あなたのアプリケーションが多数の非ユニコードデータを使うレガシーシステムと連携するのでなければ、
-そのままにしておくべきです。
+このプロパティはアプリケーションが使う文字セットを規定します。
+デフォルト値は `'UTF-8'` であり、あなたのアプリケーションが多数の非ユニコードデータを使うレガシーシステムと連携するのでなければ、そのままにしておくべきです。
 
 
 #### [[yii\base\Application::defaultRoute|defaultRoute]] <a name="defaultRoute"></a>
 
-このプロパティは、リクエストがルートを指定していないときにアプリケーションが使用すべき [route](runtime-routing.md) を規定します。
+このプロパティは、リクエストがルートを指定していないときにアプリケーションが使用すべき [ルート](runtime-routing.md) を規定します。
 ルートは、チャイルドモジュール ID、コントローラ ID、および/または アクション ID を構成要素とすることが出来ます。
 例えば、`help`、`post/create`、`admin/post/create` などです。
 アクション ID が与えられていない場合は、[[yii\base\Controller::defaultAction]] で規定されるデフォルト値を取ります。
 
-[[yii\web\Application|ウェブアプリケーション]] では、このプロパティのデフォルト値は `'site'` であり、
-その意味するところは、`SiteController` コントローラとそのデフォルトアクションが使用されるべきである、ということです。
-結果として、ルートを指定せずにアプリケーションにアクセスすると、`app\controllers\SiteController::actionIndex()` の結果が表示されます。
+[[yii\web\Application|ウェブアプリケーション]] では、このプロパティのデフォルト値は `'site'` であり、その意味するところは、`SiteController`
+コントローラとそのデフォルトアクションが使用されるべきである、ということです。結果として、ルートを指定せずにアプリケーションにアクセスすると、`app\controllers\SiteController::actionIndex()`
+の結果が表示されます。
 
 [[yii\console\Application|コンソールアプリケーション]] では、デフォルト値は `'help'` であり、コアコマンドの [[yii\console\controllers\HelpController::actionIndex()]] が使用されるべきであるという意味です。
 結果として、引数を与えずに `yii` というコマンドを走らせると、ヘルプ情報が表示されることになります。
@@ -396,7 +390,7 @@ $width = \Yii::$app->params['thumbnail.size'][0];
 `extensions.php` は、[Composer](http://getcomposer.org) を使ってエクステンションをインストールすると、自動的に生成され保守されます。
 ですから、たいていの場合、このプロパティをあなたが構成する必要はありません。
 
-エクステンションを手作業で保守したいという特殊なケースにおいては、次のようにしてこのプロパティを構成することが出来ます:
+エクステンションを手作業で保守したいという特殊なケースにおいては、次のようにしてこのプロパティを構成することが出来ます。
 
 ```php
 [
@@ -404,7 +398,7 @@ $width = \Yii::$app->params['thumbnail.size'][0];
         [
             'name' => 'extension name',
             'version' => 'version number',
-            'bootstrap' => 'BootstrapClassName',  // オプション、コンフィギュレーション配列でもよい
+            'bootstrap' => 'BootstrapClassName',  // オプション、構成情報の配列でもよい
             'alias' => [  // optional
                 '@alias1' => 'to/path1',
                 '@alias2' => 'to/path2',
@@ -419,17 +413,16 @@ $width = \Yii::$app->params['thumbnail.size'][0];
 
 見て分かるように、このプロパティはエクステンションの仕様を示す配列を取ります。
 それぞれのエクステンションは、`name` と `version` の要素を含む配列によって規定されます。
-エクステンションが [ブートストラップ](runtime-bootstrapping.md) の過程で走る必要がある場合には、
-`bootstrap` 要素をブートストラップのクラス名または [コンフィギュレーション](concept-configurations.md) 配列によって規定することが出来ます。
-また、エクステンションはいくつかの [エイリアス](concept-aliases.md) を定義することも出来ます。
+エクステンションが [ブートストラップ](runtime-bootstrapping.md) の過程で走る必要がある場合には、`bootstrap` 要素をブートストラップのクラス名または [構成情報](concept-configurations.md)
+の配列によって規定することが出来ます。また、エクステンションはいくつかの [エイリアス](concept-aliases.md) を定義することも出来ます。
 
 
 #### [[yii\base\Application::layout|layout]] <a name="layout"></a>
 
 このプロパティは、[ビュー](structure-views.md) をレンダリングするときに使われるべきデフォルトのレイアウトを規定します。
 デフォルト値は `'main'` であり、[レイアウトパス](#layoutPath) の下にある `main.php` というファイルが使われるべき事を意味します。
-[レイアウトパス](#layoutPath) と [ビューパス](#viewPath) の両方がデフォルト値を取る場合、
-デフォルトのレイアウトファイルは `@app/views/layouts/main.php` というパスエイリアスとして表すことが出来ます。
+[レイアウトパス](#layoutPath) と [ビューパス](#viewPath) の両方がデフォルト値を取る場合、デフォルトのレイアウトファイルは
+`@app/views/layouts/main.php` というパスエイリアスとして表すことが出来ます。
 
 滅多には無いことですが、レイアウトをデフォルトで無効にしたい場合は、このプロパティを `false` として構成することが出来ます。
 
@@ -483,7 +476,7 @@ Yii 繝ｪ繝ｪ繝ｼ繧ｹ縺ｫ蜷ｫ縺ｾ繧後※縺ｋ繧ｳ繧｢繧ｳ繝槭Φ繝峨ｒ譛牙柑縺ｫ縺吶∋縺阪°
 ## アプリケーションのイベント<a name="application-events"></a>
 
 アプリケーションはリクエストを処理するライフサイクルの中でいくつかのイベントをトリガします。
-これらのイベントに対して、下記のようにして、アプリケーションのコンフィギュレーションの中でイベントハンドラを取り付けることが出来ます。
+これらのイベントに対して、下記のようにして、アプリケーションの構成情報の中でイベントハンドラをアタッチすることが出来ます。
 
 ```php
 [
@@ -493,9 +486,9 @@ Yii 繝ｪ繝ｪ繝ｼ繧ｹ縺ｫ蜷ｫ縺ｾ繧後※縺ｋ繧ｳ繧｢繧ｳ繝槭Φ繝峨ｒ譛牙柑縺ｫ縺吶∋縺阪°
 ]
 ```
 
-`on eventName` という構文の使い方については、[コンフィギュレーション](concept-configurations.md#configuration-format) の節で説明されています。
+`on eventName` という構文の使い方については、[構成情報](concept-configurations.md#configuration-format) の節で説明されています。
 
-別の方法として、アプリケーションのインスタンスが生成された後、[ブートストラップの過程](runtime-bootstrapping.md) の中でイベントハンドラを取り付けることも出来ます。
+別の方法として、アプリケーションのインスタンスが生成された後、[ブートストラップの過程](runtime-bootstrapping.md) の中でイベントハンドラをアタッチすることも出来ます。
 例えば、
 
 ```php
@@ -545,8 +538,7 @@ Yii 繝ｪ繝ｪ繝ｼ繧ｹ縺ｫ蜷ｫ縺ｾ繧後※縺ｋ繧ｳ繧｢繧ｳ繝槭Φ繝峨ｒ譛牙柑縺ｫ縺吶∋縺阪°
 ]
 ```
 
-同じ `beforeAction` イベントが、[モジュール](structure-modules.md) と [コントローラ](structure-controllers.md)
-からもトリガされることに注意してください。
+同じ `beforeAction` イベントが、[モジュール](structure-modules.md) と [コントローラ](structure-controllers.md) からもトリガされることに注意してください。
 アプリケーションオブジェクトが最初にこのイベントをトリガし、次に (もし有れば) モジュールが、そして最後にコントローラがこのイベントをトリガします。
 イベントハンドラが [[yii\base\ActionEvent::isValid]] を `false` にセットすると、後続のイベントはトリガされません。
 
@@ -571,8 +563,7 @@ Yii 繝ｪ繝ｪ繝ｼ繧ｹ縺ｫ蜷ｫ縺ｾ繧後※縺ｋ繧ｳ繧｢繧ｳ繝槭Φ繝峨ｒ譛牙柑縺ｫ縺吶∋縺阪°
 ]
 ```
 
-同じ `afterAction` イベントが、[モジュール](structure-modules.md) と [コントローラ](structure-controllers.md)
-からもトリガされることに注意してください。
+同じ `afterAction` イベントが、[モジュール](structure-modules.md) と [コントローラ](structure-controllers.md) からもトリガされることに注意してください。
 これらのオブジェクトは、`beforeAction` の場合とは逆の順でイベントをトリガします。
 すなわち、コントローラオブジェクトが最初にこのイベントをトリガし、次に (もし有れば) モジュールが、そして最後にアプリケーションがこのイベントをトリガします。
 
@@ -581,18 +572,17 @@ Yii 繝ｪ繝ｪ繝ｼ繧ｹ縺ｫ蜷ｫ縺ｾ繧後※縺ｋ繧ｳ繧｢繧ｳ繝槭Φ繝峨ｒ譛牙柑縺ｫ縺吶∋縺阪°
 
 ![アプリケーションのライフサイクル](images/application-lifecycle.png)
 
-[エントリスクリプト](structure-entry-scripts.md) が実行されて、リクエストが処理されるとき、
-アプリケーションは次のようなライフサイクルを経ます:
+[エントリスクリプト](structure-entry-scripts.md) が実行されて、リクエストが処理されるとき、アプリケーションは次のようなライフサイクルを経ます。
 
-1. エントリスクリプトがアプリケーションのコンフィギュレーションを配列として読み出す。
-2. エントリスクリプトがアプリケーションの新しいインスタンスを作成する:
+1. エントリスクリプトがアプリケーションの構成情報を配列として読み出す。
+2. エントリスクリプトがアプリケーションの新しいインスタンスを作成する。
   * [[yii\base\Application::preInit()|preInit()]] が呼び出されて、[[yii\base\Application::basePath|basePath]]
     のような、優先度の高いアプリケーションプロパティを構成する。
   * [[yii\base\Application::errorHandler|エラーハンドラ]] を登録する。
   * アプリケーションのプロパティを構成する。
   * [[yii\base\Application::init()|init()]] が呼ばれ、そこから更に、ブートストラップコンポーネントを
     走らせるために、[[yii\base\Application::bootstrap()|bootstrap()]] が呼ばれる。
-3. エントリスクリプトが [[yii\base\Application::run()]] を呼んで、アプリケーションを走らせる:
+3. エントリスクリプトが [[yii\base\Application::run()]] を呼んで、アプリケーションを走らせる。
   * [[yii\base\Application::EVENT_BEFORE_REQUEST|EVENT_BEFORE_REQUEST]] イベントをトリガする。
   * リクエストを処理する: リクエストを [ルート](runtime-routing.md) とそれに結び付くパラメータとして解決する;
     ルートによって指定されたモジュール、コントローラ、および、アクションを作成する; そしてアクションを走らせる。

docs/guide-ja/structure-assets.md

 アセット
 ========
 
-Yii では、アセットは、ウェブページで参照できるファイルを意味します。CSS ファイルであったり、JavaScript ファイルであったり、
-画像やビデオのファイルであったりします。アセットはウェブでアクセス可能なディレクトリに配置され、
-ウェブサーバによって直接に提供されます。
-
-たいていの場合、アセットはプログラム的に管理する方が望ましいものです。例えば、ページの中で [[yii\jui\DatePicker]]
-ウィジェットを使うとき、ウィジェットが必要な CSS と JavaScript のファイルを自動的にインクルードします。あなたに対して、
-手作業で必要なファイルを探してインクルードするように要求したりはしません。そして、ウィジェットを新しいバージョンに
-アップグレードしたときは、ウィジェットが自動的に新しいバージョンのアセットファイルを使用するようになります。
+Yii では、アセットは、ウェブページで参照できるファイルを意味します。
+アセットは CSS ファイルであったり、JavaScript ファイルであったり、画像やビデオのファイルであったりします。
+アセットはウェブでアクセス可能なディレクトリに配置され、ウェブサーバによって直接に提供されます。
+
+たいていの場合、アセットはプログラム的に管理する方が望ましいものです。
+例えば、ページの中で [[yii\jui\DatePicker]] ウィジェットを使うとき、ウィジェットが必要な CSS と JavaScript のファイルを自動的にインクルードします。
+あなたに対して、手作業で必要なファイルを探してインクルードするように要求したりはしません。
+そして、ウィジェットを新しいバージョンにアップグレードしたときは、ウィジェットが自動的に新しいバージョンのアセットファイルを使用するようになります。
 このチュートリアルでは、Yii によって提供される強力なアセット管理機能について説明します。
 
 
 ## アセットバンドル <a name="asset-bundles"></a>
 
-Yii はアセットを *アセットバンドル* を単位として管理します。アセットバンドルは、単にあるディレクトリの下に集められた
-一群のアセットに過ぎません。[ビュー](structure-views.md) の中でアセットバンドルを登録すると、バンドルの中の CSS や
-JavaScript のファイルがレンダリングされるウェブページに挿入されます。
+Yii はアセットを *アセットバンドル* を単位として管理します。アセットバンドルは、簡単に言えば、あるディレクトリの下に集められた一群のアセットです。
+[ビュー](structure-views.md) の中でアセットバンドルを登録すると、バンドルの中の CSS や JavaScript のファイルがレンダリングされるウェブページに挿入されます。
 
 
 ## アセットバンドルを定義する <a name="defining-asset-bundles"></a>
 
-アセットバンドルは [[yii\web\AssetBundle]] から拡張された PHP クラスとして定義されます。バンドルの名前は、対応する PHP
-クラスの完全修飾名 (先頭のバックスラッシュを除く) です。アセットバンドルクラスは [オートロード可能](concept-autoloading.md)
-でなければなりません。アセットバンドルクラスは、通常、アセットがどこに置かれているか、バンドルがどういう CSS や JavaScript
-のファイルを含んでいるか、そして、バンドルが他のバンドルにどのように依存しているかを定義します。
+アセットバンドルは [[yii\web\AssetBundle]] から拡張された PHP クラスとして定義されます。
+バンドルの名前は、対応する PHP クラスの完全修飾名 (先頭のバックスラッシュを除く) です。
+アセットバンドルクラスは [オートロード可能](concept-autoloading.md) でなければなりません。
+アセットバンドルクラスは、通常、アセットがどこに置かれているか、バンドルがどういう CSS や JavaScript のファイルを含んでいるか、そして、バンドルが他のバンドルにどのように依存しているかを定義します。
 
-以下のコードは [ベーシックアプリケーションテンプレート](start-installation.md) によって使用されているメインのアセットバンドルを定義するものです:
+以下のコードは [ベーシックアプリケーションテンプレート](start-installation.md) によって使用されているメインのアセットバンドルを定義するものです。
 
 ```php
 <?php
@@ -51,35 +50,33 @@ class AppAsset extends AssetBundle
 }
 ```
 
-上の `AppAsset` クラスは、アセットファイルが `@webroot` ディレクトリの下に配置されており、それが URL `@web` に対応することを
-定義しています。バンドルは一つだけ CSS ファイル `css/site.css` を含み、JavaScript ファイルは含みません。バンドルは、
-他の二つのバンドル、すなわち [[yii\web\YiiAsset]] と [[yii\bootstrap\BootstrapAsset]] に依存しています。
+上の `AppAsset` クラスは、アセットファイルが `@webroot` ディレクトリの下に配置されており、それが URL `@web` に対応することを定義しています。
+バンドルは一つだけ CSS ファイル `css/site.css` を含み、JavaScript ファイルは含みません。
+バンドルは、他の二つのバンドル、すなわち [[yii\web\YiiAsset]] と [[yii\bootstrap\BootstrapAsset]] に依存しています。
 以下、[[yii\web\AssetBundle]] のプロパティに関して、更に詳細に説明します。
 
 * [[yii\web\AssetBundle::sourcePath|sourcePath]]: このバンドルのアセットファイルを含むルートディレクトリを指定します。
-  ルートディレクトリがウェブからアクセス可能でない場合はこのプロパティをセットしなければなりません。ウェブからアクセス可能な場合は、
-  かわりに [[yii\web\AssetBundle::basePath|basePath]] と [[yii\web\AssetBundle::baseUrl|baseUrl]] のプロパティをセットすべきです。
+  ルートディレクトリがウェブからアクセス可能でない場合に、このプロパティをセットしなければなりません。
+  ルートディレクトリがウェブからアクセス可能な場合は、このプロパティではなく、[[yii\web\AssetBundle::basePath|basePath]] と [[yii\web\AssetBundle::baseUrl|baseUrl]] のプロパティをセットすべきです。
   [パスエイリアス](concept-aliases.md) をここで使うことが出来ます。
 * [[yii\web\AssetBundle::basePath|basePath]]: このバンドルのアセットファイルを含むウェブからアクセス可能なディレクトリを指定します。
-  [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティをセットした場合は、[アセットマネージャ](#asset-manager) がバンドルに
-  含まれるファイルをウェブからアクセス可能なディレクトリに発行して、その結果に応じてこのプロパティを上書きします。
+  [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティをセットした場合は、[アセットマネージャ](#asset-manager) がバンドルに含まれるファイルをウェブからアクセス可能なディレクトリに発行して、その結果、このプロパティを上書きします。
   アセットファイルが既にウェブからアクセス可能なディレクトリにあり、アセットの発行が必要でない場合に、このプロパティをセットすべきです。
   [パスエイリアス](concept-aliases.md) をここで使うことが出来ます。
 * [[yii\web\AssetBundle::baseUrl|baseUrl]]: [[yii\web\AssetBundle::basePath|basePath]] ディレクトリに対応する URL を指定します。
-  [[yii\web\AssetBundle::basePath|basePath]] と同じように、[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティをセットした場合は、
-  [アセットマネージャ](#asset-manager) がアセットを発行して、その結果に応じてこのプロパティを上書きします。
+  [[yii\web\AssetBundle::basePath|basePath]] と同じように、[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティをセットした場合は、[アセットマネージャ](#asset-manager) がアセットを発行して、その結果、このプロパティを上書きします。
   [パスエイリアス](concept-aliases.md) をここで使うことが出来ます。
-* [[yii\web\AssetBundle::js|js]]: このバンドルに含まれる JavaScript ファイルをリストする配列です。ディレクトリの区切りとして
-  フォワードスラッシュ "/" だけを使うべきことに注意してください。それぞれの JavaScript ファイルは、以下の二つの形式のどちらかによって
-  指定することが出来ます。
-  - ローカルの JavaScript ファイルを表す相対パス (例えば `js/main.js`)。実際のファイルのパスは、この相対パスの前に
-    [[yii\web\AssetManager::basePath]] を付けることによって決定されます。また、実際の URL は、この相対パスの前に
-    [[yii\web\AssetManager::baseUrl]] を付けることによって決定されます。
-  - 外部の JavaScript ファイルを表す絶対 URL。例えば、
-    `http://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js` や
+* [[yii\web\AssetBundle::js|js]]: このバンドルに含まれる JavaScript ファイルをリストする配列です。
+  ディレクトリの区切りとしてフォワードスラッシュ "/" だけを使うべきことに注意してください。
+  それぞれの JavaScript ファイルは、以下の二つの形式のどちらかによって指定することが出来ます。
+  - ローカルの JavaScript ファイルを表す相対パス (例えば `js/main.js`)。
+    実際のファイルのパスは、この相対パスの前に [[yii\web\AssetManager::basePath]] を付けることによって決定されます。
+    また、実際の URL は、この相対パスの前に [[yii\web\AssetManager::baseUrl]] を付けることによって決定されます。
+  - 外部の JavaScript ファイルを表す絶対 URL。
+    例えば、`http://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js` や
     `//ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js` など。
-* [[yii\web\AssetBundle::css|css]]: このバンドルに含まれる CSS ファイルをリストする配列です。この配列の形式は、
-  [[yii\web\AssetBundle::js|js]] の形式と同じです。
+* [[yii\web\AssetBundle::css|css]]: このバンドルに含まれる CSS ファイルをリストする配列です。
+  この配列の形式は、[[yii\web\AssetBundle::js|js]] の形式と同じです。
 * [[yii\web\AssetBundle::depends|depends]]: このバンドルが依存しているアセットバンドルの名前をリストする配列です
    (バンドルの依存関係については、すぐ後で説明します)。
 * [[yii\web\AssetBundle::jsOptions|jsOptions]]: [[yii\web\View::registerJsFile()]] メソッドに渡されるオプションを指定します。
@@ -93,7 +90,7 @@ class AppAsset extends AssetBundle
 
 ### アセットの配置場所 <a name="asset-locations"></a>
 
-アセットは、配置場所を基準にして、次のように分類することが出来ます:
+アセットは、配置場所を基準にして、次のように分類することが出来ます。
 
 * ソースアセット: アセットファイルは、ウェブ経由で直接にアクセスすることが出来ない PHP ソースコードと一緒に配置されています。
   ページの中でソースアセットを使用するためには、ウェブディレクトリにコピーして、いわゆる発行されたアセットに変換しなければなりません。
@@ -101,35 +98,30 @@ class AppAsset extends AssetBundle
 * 発行されたアセット: アセットファイルはウェブディレクトリに配置されており、したがってウェブ経由で直接にアクセスすることが出来ます。
 * 外部アセット: アセットファイルは、あなたのウェブアプリケーションをホストしているのとは別のウェブサーバ上に配置されています。
 
-アセットバンドルクラスを定義するときに、[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティを指定した場合は、
-相対パスを使ってリストに挙げられたアセットは全てソースアセットであると見なされます。このプロパティを指定しなかった場合は、
-アセットは発行されたアセットであることになります (したがって、[[yii\web\AssetBundle::basePath|basePath]] と
-[[yii\web\AssetBundle::baseUrl|baseUrl]] を指定して、アセットがどこに配置されているかを Yii に知らせなければなりません)。
+アセットバンドルクラスを定義するときに、[[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティを指定した場合は、相対パスを使ってリストに挙げられたアセットは全てソースアセットであると見なされます。
+このプロパティを指定しなかった場合は、アセットは発行されたアセットであることになります
+(したがって、[[yii\web\AssetBundle::basePath|basePath]] と [[yii\web\AssetBundle::baseUrl|baseUrl]] を指定して、アセットがどこに配置されているかを Yii に知らせなければなりません)。
 
 アプリケーションに属するアセットは、不要なアセット発行プロセスを避けるために、ウェブディレクトリに置くことが推奨されます。
-前述の例において `AppAsset` が [[yii\web\AssetBundle::sourcePath|sourcePath]] ではなく [[yii\web\AssetBundle::basePath|basePath]]
-を指定しているのは、これが理由です。
+前述の例において `AppAsset` が [[yii\web\AssetBundle::sourcePath|sourcePath]] ではなく [[yii\web\AssetBundle::basePath|basePath]] を指定しているのは、これが理由です。
 
-[エクステンション](structure-extensions.md) の場合は、アセットがソースコードと一緒にウェブからアクセス出来ないディレクトリに
-配置されているため、アセットバンドルクラスを定義するときには [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティを
-指定しなければなりません。
+[エクステンション](structure-extensions.md) の場合は、アセットがソースコードと一緒にウェブからアクセス出来ないディレクトリに配置されているため、
+アセットバンドルクラスを定義するときには [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティを指定しなければなりません。
 
 > Note|注意: `@webroot/assets` を [[yii\web\AssetBundle::sourcePath|ソースパス]] として使ってはいけません。
-  このディレクトリは、既定では、[[yii\web\AssetManager|アセットマネージャ]] がソースの配置場所から発行されたアセットファイルを
-  保存する場所として使われます。このディレクトリの中のファイルはすべて一時的なものと見なされており、削除されることがあります。
+  このディレクトリは、既定では、[[yii\web\AssetManager|アセットマネージャ]] がソースの配置場所から発行されたアセットファイルを保存する場所として使われます。
+  このディレクトリの中のファイルはすべて一時的なものと見なされており、削除されることがあります。
 
 
 ### アセットの依存関係 <a name="asset-dependencies"></a>
 
-ウェブページに複数の CSS や JavaScript ファイルをインクルードするときは、オーバーライドの問題を避けるために、
-一定の順序に従わなければなりません。例えば、ウェブページで jQuery UI ウィジェットを使おうとするときは、jQuery JavaScript
-ファイルが jQuery UI JavaScript ファイルより前にインクルードされることを保証しなければなりません。
+ウェブページに複数の CSS や JavaScript ファイルをインクルードするときは、オーバーライドの問題を避けるために、一定の順序に従わなければなりません。
+例えば、ウェブページで jQuery UI ウィジェットを使おうとするときは、jQuery JavaScript ファイルが jQuery UI JavaScript ファイルより前にインクルードされることを保証しなければなりません。
 このような順序付けをアセット間の依存関係と呼びます。
 
-アセットの依存関係は、主として、[[yii\web\AssetBundle::depends]] プロパティによって指定されます。`AppAsset` の例では、
-このアセットバンドルは他の二つのアセットバンドル、すなわち、[[yii\web\YiiAsset]] と [[yii\bootstrap\BootstrapAsset]] に依存しています。
-このことは、`AppAsset` の CSS と JavaScript ファイルが、依存している二つのアセットバンドルにあるファイルの *後に*
-インクルードされることを意味します。
+アセットの依存関係は、主として、[[yii\web\AssetBundle::depends]] プロパティによって指定されます。
+`AppAsset` の例では、このアセットバンドルは他の二つのアセットバンドル、すなわち、[[yii\web\YiiAsset]] と [[yii\bootstrap\BootstrapAsset]] に依存しています。
+このことは、`AppAsset` の CSS と JavaScript ファイルが、依存している二つのアセットバンドルにあるファイルの *後に* インクルードされることを意味します。
 
 アセットの依存関係は中継されます。つまり、バンドル A が B に依存し、B が C に依存していると、A は C にも依存していることになります。
 
@@ -137,21 +129,20 @@ class AppAsset extends AssetBundle
 ### アセットのオプション <a name="asset-options"></a>
 
 [[yii\web\AssetBundle::cssOptions|cssOptions]] および [[yii\web\AssetBundle::jsOptions|jsOptions]] のプロパティを指定して、
-CSS と JavaScript ファイルがページにインクルードされる方法をカスタマイズすることが出来ます。これらのプロパティの値は、
-[ビュー](structure-views.md) が CSS と JavaScript ファイルをインクルードするために、[[yii\web\View::registerCssFile()]] および
+CSS と JavaScript ファイルがページにインクルードされる方法をカスタマイズすることが出来ます。
+これらのプロパティの値は、[ビュー](structure-views.md) が CSS と JavaScript ファイルをインクルードするために、[[yii\web\View::registerCssFile()]] および
 [[yii\web\View::registerJsFile()]] メソッドを呼ぶときに、それぞれ、オプションとして引き渡されます。
 
 > Note|注意: バンドルクラスでセットしたオプションは、バンドルの中の *全て* の CSS/JavaScript ファイルに適用されます。
-  いろいろなファイルに別々のオプションを使用したい場合は、別々のアセットバンドルを作成して、個々のバンドルの中では、
-  一組のオプションを使うようにしなければなりません。
+  いろいろなファイルに別々のオプションを使用したい場合は、別々のアセットバンドルを作成して、個々のバンドルの中では、一組のオプションを使うようにしなければなりません。
 
-例えば、IE9 以下のブラウザに対して CSS ファイルを条件的にインクルードするために、次のオプションを使うことが出来ます:
+例えば、IE9 以下のブラウザに対して CSS ファイルを条件的にインクルードするために、次のオプションを使うことが出来ます。
 
 ```php
 public $cssOptions = ['condition' => 'lte IE9'];
 ```
 
-こうすると、バンドルの中の CSS ファイルは下記の HTML タグを使ってインクルードされるようになります:
+こうすると、バンドルの中の CSS ファイルは下記の HTML タグを使ってインクルードされるようになります。
 
 ```html
 <!--[if lte IE9]>
@@ -159,7 +150,7 @@ public $cssOptions = ['condition' => 'lte IE9'];
 <![endif]-->
 ```
 
-生成された CSS のリンクタグを `<noscript>` の中に包むためには、次のように `cssOptions` を構成することが出来ます:
+生成された CSS のリンクタグを `<noscript>` の中に包むためには、次のように `cssOptions` を構成することが出来ます。
 
 ```php
 public $cssOptions = ['noscript' => true];
@@ -172,10 +163,9 @@ JavaScript 繝輔ぃ繧､繝ｫ繧偵繝ｼ繧ｸ縺ｮ head 繧ｻ繧ｯ繧ｷ繝ｧ繝ｳ縺ｫ繧､繝ｳ繧ｯ繝ｫ繝ｼ繝
 public $jsOptions = ['position' => \yii\web\View::POS_HEAD];
 ```
 
-既定では、アセットバンドルが発行されるときは、[[yii\web\AssetBundle::sourcePath]] で指定されたディレクトリの中にある
-全てのコンテンツが発行されます。[[yii\web\AssetBundle::publishOptions|publishOptions]] プロパティを構成することによって
-この振る舞いをカスタマイズすることが出来ます。例えば、[[yii\web\AssetBundle::sourcePath]] の一個または数個のサブディレクトリ
-だけを発行するために、アセットバンドルクラスの中で下記のようにすることが出来ます:
+既定では、アセットバンドルが発行されるときは、[[yii\web\AssetBundle::sourcePath]] で指定されたディレクトリの中にある全てのコンテンツが発行されます。
+[[yii\web\AssetBundle::publishOptions|publishOptions]] プロパティを構成することによって、この振る舞いをカスタマイズすることが出来ます。
+例えば、[[yii\web\AssetBundle::sourcePath]] の一個または数個のサブディレクトリだけを発行するために、アセットバンドルクラスの中で下記のようにすることが出来ます。
 
 ```php
 <?php
@@ -201,32 +191,30 @@ class FontAwesomeAsset extends AssetBundle
 }  
 ```
 
-上記の例は、["fontawesome" パッケージ](http://fontawesome.io/) のためのアセットバンドルを定義するものです。`beforeCopy`
-という発行オプションを指定して、`fonts` と `css` サブディレクトリだけが発行されるようにしています。
+上記の例は、["fontawesome" パッケージ](http://fontawesome.io/) のためのアセットバンドルを定義するものです。
+`beforeCopy` という発行オプションを指定して、`fonts` と `css` サブディレクトリだけが発行されるようにしています。
 
 
 ### Bower と NPM のアセット <a name="bower-npm-assets"></a>
 
 ほとんどの JavaScript/CSS パッケージは、[Bower](http://bower.io/) および/または [NPM](https://www.npmjs.org/) によって管理されています。
-あなたのアプリケーションやエクステンションがそのようなパッケージを使っている場合は、以下のステップに従って
-ライブラリの中のアセットを管理することが推奨されます。
+あなたのアプリケーションやエクステンションがそのようなパッケージを使っている場合は、以下のステップに従って、ライブラリの中のアセットを管理することが推奨されます。
 
 1. アプリケーションまたはエクステンションの `composer.json` ファイルを修正して、パッケージを `require` のエントリに入れます。
-   ライブラリを参照するのに、`bower-asset/PackageName` (Bower パッケージ) または `npm-asset/PackageName` (NPM パッケージ)
-   を使わなければなりません。
+   ライブラリを参照するのに、`bower-asset/PackageName` (Bower パッケージ) または `npm-asset/PackageName` (NPM パッケージ) を使わなければなりません。
 2. アセットバンドルクラスを作成して、アプリケーションまたはエクステンションで使う予定の JavaScript/CSS ファイルをリストに挙げます。
    [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティは、`@bower/PackageName` または `@npm/PackageName` としなければなりません。
    これは、Composer が Bower または NPM パッケージを、このエイリアスに対応するディレクトリにインストールするためです。
 
-> Note|注意: パッケージの中には、全ての配布ファイルをサブディレクトリに置くものがあります。その場合には、そのサブディレクトリを
-  [[yii\web\AssetBundle::sourcePath|sourcePath]] の値として指定しなければなりません。例えば、[[yii\web\JqueryAsset]] は
-  `@bower/jquery` ではなく `@bower/jquery/dist` を使います。
+> Note|注意: パッケージの中には、全ての配布ファイルをサブディレクトリに置くものがあります。
+  その場合には、そのサブディレクトリを [[yii\web\AssetBundle::sourcePath|sourcePath]] の値として指定しなければなりません。
+  例えば、[[yii\web\JqueryAsset]] は `@bower/jquery` ではなく `@bower/jquery/dist` を使います。
 
 
 ## アセットバンドルを使う <a name="using-asset-bundles"></a>
 
-アセットバンドルを使うためには、[[yii\web\AssetBundle::register()]] メソッドを呼んでアセットバンドルを [ビュー](structure-views.md)
-に登録します。例えば、次のようにしてビューテンプレートの中でアセットバンドルを登録することが出来ます:
+アセットバンドルを使うためには、[[yii\web\AssetBundle::register()]] メソッドを呼んでアセットバンドルを [ビュー](structure-views.md) に登録します。
+例えば、次のようにしてビューテンプレートの中でアセットバンドルを登録することが出来ます。
 
 ```php
 use app\assets\AppAsset;
@@ -236,25 +224,23 @@ AppAsset::register($this);  // $this 縺ｯ繝薙Η繝ｼ繧ｪ繝悶ず繧ｧ繧ｯ繝医ｒ陦ｨ縺
 > Info|情報: [[yii\web\AssetBundle::register()]] メソッドは、[[yii\web\AssetBundle::basePath|basePath]] や
   [[yii\web\AssetBundle::baseUrl|baseUrl]] など、発行されたアセットに関する情報を含むアセットバンドルオブジェクトを返します。
 
-他の場所でアセットバンドルを登録しようとするときは、必要とされるビューオブジェクトを提供しなければなりません。例えば、
-[ウィジェット](structure-widgets.md) クラスの中でアセットバンドルを登録するためには、`$this->view` によってビューオブジェクトを
-取得することが出来ます。
+他の場所でアセットバンドルを登録しようとするときは、必要とされるビューオブジェクトを提供しなければなりません。
+例えば、[ウィジェット](structure-widgets.md) クラスの中でアセットバンドルを登録するためには、`$this->view` によってビューオブジェクトを取得することが出来ます。
 
-アセットバンドルがビューに登録されるとき、舞台裏では、Yii が依存している全てのアセットバンドルを登録します。
-そして、アセットバンドルがウェブからはアクセス出来ないディレクトリに配置されている場合は、アセットバンドルはウェブディレクトリに発行されます。
-その後、ビューがページをレンダリングするときに、登録されたバンドルのリストに挙げられている CSS と JavaScript ファイルのための
-`<link>` タグと `<script>` タグが生成されます。これらのタグの順序は、登録されたバンドル間の依存関係、および、
-[[yii\web\AssetBundle::css]] と [[yii\web\AssetBundle::js] のプロパティのリストに挙げられたアセットの順序によって決定されます。
+アセットバンドルがビューに登録されるとき、舞台裏では、依存している全てのアセットバンドルが Yii によって登録されます。
+そして、アセットバンドルがウェブからはアクセス出来ないディレクトリに配置されている場合は、アセットバンドルがウェブディレクトリに発行されます。
+その後、ビューがページをレンダリングするときに、登録されたバンドルのリストに挙げられている CSS と JavaScript ファイルのための `<link>` タグと `<script>` タグが生成されます。
+これらのタグの順序は、登録されたバンドル間の依存関係、および、[[yii\web\AssetBundle::css]] と [[yii\web\AssetBundle::js] のプロパティのリストに挙げられたアセットの順序によって決定されます。
 
 
 ### アセットバンドルをカスタマイズする <a name="customizing-asset-bundles"></a>
 
-Yii は、[[yii\web\AssetManager]] によって実装されている `assetManager` という名前のアプリケーションコンポーネントを通じて
-アセットバンドルを管理します。[[yii\web\AssetManager::bundles]] プロパティを構成することによって、アセットバンドルの振る舞いを
-カスタマイズすることが出来ます。例えば、デフォルトの [[yii\web\JqueryAsset]] アセットバンドルはインストールされた jQuery の
-Bower パッケージにある `jquery.js` ファイルを使用します。あなたは、可用性とパフォーマンスを向上させるために、
-Google によってホストされたバージョンを使いたいと思うかも知れません。次のように、アプリケーションのコンフィギュレーションで
-`assetManager` を構成することによって、それが達成できます。
+Yii は、[[yii\web\AssetManager]] によって実装されている `assetManager` という名前のアプリケーションコンポーネントを通じてアセットバンドルを管理します。
+[[yii\web\AssetManager::bundles]] プロパティを構成することによって、アセットバンドルの振る舞いを
+カスタマイズすることが出来ます。
+例えば、デフォルトの [[yii\web\JqueryAsset]] アセットバンドルはインストールされた jQuery の Bower パッケージにある `jquery.js` ファイルを使用します。
+あなたは、可用性とパフォーマンスを向上させるために、Google によってホストされたバージョンを使いたいと思うかも知れません。
+次のように、アプリケーションの構成情報で `assetManager` を構成することによって、それが達成できます。
 
 ```php
 return [
@@ -274,12 +260,11 @@ return [
 ];
 ```
 
-複数のアセットバンドルも同様に [[yii\web\AssetManager::bundles]] によって構成することが出来ます。配列のキーは、
-アセットバンドルのクラス名 (最初のバックスラッシュを除く) とし、配列の値は、
-対応する [コンフィギュレーション配列](concept-configurations.md) とします。
+複数のアセットバンドルも同様に [[yii\web\AssetManager::bundles]] によって構成することが出来ます。
+配列のキーは、アセットバンドルのクラス名 (最初のバックスラッシュを除く) とし、配列の値は、対応する [構成情報配列](concept-configurations.md) とします。
 
-> Tip|ヒント: アセットバンドルの中で使うアセットを条件的に選択することが出来ます。次の例は、開発環境では
-> `jquery.js` を使い、そうでなければ `jquery.min.js` を使う方法を示すものです:
+> Tip|ヒント: アセットバンドルの中で使うアセットを条件的に選択することが出来ます。
+> 次の例は、開発環境では `jquery.js` を使い、そうでなければ `jquery.min.js` を使う方法を示すものです。
 >
 > ```php
 > 'yii\web\JqueryAsset' => [
@@ -290,9 +275,9 @@ return [
 > ```
 
 無効にしたいアセットバンドルの名前に `false` を結びつけることによって、一つまたは複数のアセットバンドルを無効にすることが出来ます。
-無効にされたアセットバンドルをビューに登録した場合は、依存するバンドルは一つも登録されません。また、ビューがページを
-レンダリングするときも、バンドルの中のアセットは一つもインクルードされません。例えば、[[yii\web\JqueryAsset]] を無効化するためには、
-次のコンフィギュレーションを使用することが出来ます:
+無効にされたアセットバンドルをビューに登録した場合は、依存するバンドルは一つも登録されません。
+また、ビューがページをレンダリングするときも、バンドルの中のアセットは一つもインクルードされません。
+例えば、[[yii\web\JqueryAsset]] を無効化するために、次の構成情報を使用することが出来ます。
 
 ```php
 return [
@@ -312,10 +297,9 @@ return [
 ### アセットマッピング <a name="asset-mapping"></a>
 
 時として、複数のアセットバンドルで使われている 正しくない/互換でない アセットファイルパスを「修正」したい場合があります。
-例えば、バンドル A がバージョン 1.11.1 の `jquery.min.js` を使い、バンドル B がバージョン 2.1.1 の `jquery.js` を使っている
-ような場合です。それぞれのバンドルをカスタマイズすることで問題を修正することも出来ますが、それよりも簡単な方法は、
-*アセットマップ* 機能を使って、正しくないアセットを望ましいアセットに割り付けることです。そうするためには、以下のように
-[[yii\web\AssetManager::assetMap]] プロパティを構成します:
+例えば、バンドル A がバージョン 1.11.1 の `jquery.min.js` を使い、バンドル B がバージョン 2.1.1 の `jquery.js` を使っているような場合です。
+それぞれのバンドルをカスタマイズすることで問題を修正することも出来ますが、それよりも簡単な方法は、*アセットマップ* 機能を使って、正しくないアセットを望ましいアセットに割り付けることです。
+そうするためには、以下のように [[yii\web\AssetManager::assetMap]] プロパティを構成します。
 
 ```php
 return [
@@ -331,27 +315,24 @@ return [
 ```
 
 [[yii\web\AssetManager::assetMap|assetMap]] のキーは修正したいアセットの名前であり、値は望ましいアセットのパスです。
-アセットバンドルをビューに登録するとき、[[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] の配列に含まれる
-すべてのアセットファイルの相対パスがこのマップと突き合わせて調べられます。キーのどれかがアセットファイルのパス (利用できる場合は、
-[[yii\web\AssetBundle::sourcePath]] が前置されます) の最後の部分と一致した場合は、対応する値によってアセットが置き換えられ、
-ビューに登録されます。例えば、`my/path/to/jquery.js` というアセットファイルは `jquery.js` というキーにマッチします。
+アセットバンドルをビューに登録するとき、[[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] の配列に含まれるすべてのアセットファイルの相対パスがこのマップと突き合わせて調べられます。
+キーのどれかがアセットファイルのパス (利用できる場合は、[[yii\web\AssetBundle::sourcePath]] が前置されます) の最後の部分と一致した場合は、対応する値によってアセットが置き換えられ、ビューに登録されます。
+例えば、`my/path/to/jquery.js` というアセットファイルは `jquery.js` というキーにマッチします。
 
-> Note|注意: 相対パスを使って指定されたアセットだけがアセットマッピングの対象になります。そして、置き換える側のアセットのパスは
-  絶対 URL であるか、[[yii\web\AssetManager::basePath]] からの相対パスであるかの、どちらかでなければなりません。
+> Note|注意: 相対パスを使って指定されたアセットだけがアセットマッピングの対象になります。
+  そして、置き換える側のアセットのパスは、絶対 URL であるか、[[yii\web\AssetManager::basePath]] からの相対パスであるかの、どちらかでなければなりません。
 
 
 ### アセット発行 <a name="asset-publishing"></a>
 
-既に述べたように、アセットバンドルがウェブからアクセス出来ないディレクトリに配置されている場合は、バンドルがビューに登録されるときに、
-アセットがウェブディレクトリにコピーされます。このプロセスは *アセット発行* と呼ばれ、[[yii\web\AssetManager|アセットマネージャ]]
-によって自動的に実行されます。
+既に述べたように、アセットバンドルがウェブからアクセス出来ないディレクトリに配置されている場合は、バンドルがビューに登録されるときに、アセットがウェブディレクトリにコピーされます。
+このプロセスは *アセット発行* と呼ばれ、[[yii\web\AssetManager|アセットマネージャ]] によって自動的に実行されます。
 
 既定では、アセットが発行されるディレクトリは `@webroot/assets` であり、`@web/assets` という URL に対応するものです。
-この場所は、[[yii\web\AssetManager::basePath|basePath]] と [[yii\web\AssetManager::baseUrl|baseUrl]] のプロパティを構成して
-カスタマイズすることが出来ます。
+この場所は、[[yii\web\AssetManager::basePath|basePath]] と [[yii\web\AssetManager::baseUrl|baseUrl]] のプロパティを構成してカスタマイズすることが出来ます。
 
 ファイルをコピーすることでアセットを発行する代りに、OS とウェブサーバが許容するなら、シンボリックリンクを使うことを考慮しても良いでしょう。
-この機能は [[yii\web\AssetManager::linkAssets|linkAssets]] を true にセットすることで有効にすることが出来ます:
+この機能は [[yii\web\AssetManager::linkAssets|linkAssets]] を true にセットすることで有効にすることが出来ます。
 
 ```php
 return [
@@ -364,38 +345,35 @@ return [
 ];
 ```
 
-上記のコンフィギュレーションによって、アセットマネージャはアセットバンドルを発行するときにソースパスへのシンボリックリンクを
-作成するようになります。この方がファイルのコピーより速く、また、発行されたアセットが常に最新であることを保証することも出来ます。
+上記の構成によって、アセットマネージャはアセットバンドルを発行するときにソースパスへのシンボリックリンクを作成するようになります。
+この方がファイルのコピーより速く、また、発行されたアセットが常に最新であることを保証することも出来ます。
 
 
 ## よく使われるアセットバンドル <a name="common-asset-bundles"></a>
 
-コアの Yii コードは多くのアセットバンドルを定義しています。その中で、下記のバンドルはよく使われるものであり、あなたの
-アプリケーションやエクステンションのコードでも参照することが出来るものです。
+コアの Yii コードは多くのアセットバンドルを定義しています。
+その中で、下記のバンドルはよく使われるものであり、あなたのアプリケーションやエクステンションのコードでも参照することが出来るものです。
 
-- [[yii\web\YiiAsset]]: 主として `yii.js` ファイルをインクルードするためのバンドルです。このファイルはモジュール化された
-  JavaScript のコードを組織化するメカニズムを実装しています。また、`data-method` と `data-confirm` の属性に対する特別な
-  サポートや、その他の有用な機能を提供します。
+- [[yii\web\YiiAsset]]: 主として `yii.js` ファイルをインクルードするためのバンドルです。
+  このファイルはモジュール化された JavaScript のコードを組織化するメカニズムを実装しています。
+  また、`data-method` と `data-confirm` の属性に対する特別なサポートや、その他の有用な機能を提供します。
 - [[yii\web\JqueryAsset]]: jQuery の bower パッケージから `jquery.js` ファイルをインクルードします。
 - [[yii\bootstrap\BootstrapAsset]]: Twitter Bootstrap フレームワークから CSS ファイルをインクルードします。
-- [[yii\bootstrap\BootstrapPluginAsset]]: Bootstrap JavaScript プラグインをサポートするために、Twitter Bootstrap
-  フレームワークから JavaScript ファイルをインクルードします。
+- [[yii\bootstrap\BootstrapPluginAsset]]: Bootstrap JavaScript プラグインをサポートするために、Twitter Bootstrap フレームワークから JavaScript ファイルをインクルードします。
 - [[yii\jui\JuiAsset]]: jQuery UI ライブラリから CSS と JavaScript のファイルをインクルードします。
 
-あなたのコードが、jQuery や jQuery UI または Bootstrap に依存する場合は、自分自身のバージョンを作るのではなく、これらの
-定義済みのアセットバンドルを使用すべきです。これらのバンドルのデフォルトの設定があなたの必要を満たさない時は、
-[アセットバンドルをカスタマイズする](#customizing-asset-bundles) の項で説明したように、それをカスタマイズすることが出来ます。
+あなたのコードが、jQuery や jQuery UI または Bootstrap に依存する場合は、自分自身のバージョンを作るのではなく、これらの定義済みのアセットバンドルを使用すべきです。
+これらのバンドルのデフォルトの設定があなたの必要を満たさない時は、[アセットバンドルをカスタマイズする](#customizing-asset-bundles) の項で説明したように、それをカスタマイズすることが出来ます。
 
 
 ## アセット変換 <a name="asset-conversion"></a>
 
-直接に CSS および/または JavaScript のコードを書く代りに、何らかの拡張構文を使って書いたものを特別なツールを使って
-CSS/JavaScript に変換する、ということを開発者はしばしば行います。例えば、CSS コードのためには、[LESS](http://lesscss.org/) や
-[SCSS](http://sass-lang.com/) を使うことが出来ます。また、JavaScript のためには、[TypeScript](http://www.typescriptlang.org/)
-を使うことが出来ます。
+直接に CSS および/または JavaScript のコードを書く代りに、何らかの拡張構文を使って書いたものを特別なツールを使って CSS/JavaScript に変換する、ということを開発者はしばしば行います。
+例えば、CSS コードのためには、[LESS](http://lesscss.org/) や [SCSS](http://sass-lang.com/) を使うことが出来ます。
+また、JavaScript のためには、[TypeScript](http://www.typescriptlang.org/) を使うことが出来ます。
 
-拡張構文を使ったアセットファイルをアセットバンドルの中の [[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]]
-のリストに挙げることが出来ます。例えば、
+拡張構文を使ったアセットファイルをアセットバンドルの中の [[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] のリストに挙げることが出来ます。
+例えば、
 
 ```php
 class AppAsset extends AssetBundle
@@ -415,9 +393,8 @@ class AppAsset extends AssetBundle
 }
 ```
 
-このようなアセットバンドルをビューに登録すると、[[yii\web\AssetManager|アセットマネージャ]] が自動的にプリプロセッサツールを
-走らせて、認識できた拡張構文のアセットを CSS/JavaScript に変換します。最終的にビューがページをレンダリングするときには、
-ビューは元の拡張構文のアセットではなく、変換後の CSS/JavaScript ファイルをページにインクルードします。
+このようなアセットバンドルをビューに登録すると、[[yii\web\AssetManager|アセットマネージャ]] が自動的にプリプロセッサツールを走らせて、認識できた拡張構文のアセットを CSS/JavaScript に変換します。
+最終的にビューがページをレンダリングするときには、ビューは元の拡張構文のアセットではなく、変換後の CSS/JavaScript ファイルをページにインクルードします。
 
 Yii はファイル名の拡張子を使って、アセットが使っている拡張構文を識別します。デフォルトでは、下記の構文とファイル名拡張子を認識します。
 
@@ -427,11 +404,10 @@ Yii 縺ｯ繝輔ぃ繧､繝ｫ蜷阪諡｡蠑ｵ蟄舌ｒ菴ｿ縺｣縺ｦ縲√い繧ｻ繝ヨ縺御ｽｿ縺｣縺ｦ縺ｋ
 - [CoffeeScript](http://coffeescript.org/): `.coffee`
 - [TypeScript](http://www.typescriptlang.org/): `.ts`
 
-Yii はインストールされたプリプロセッサツールに頼ってアセットを変換します。例えば、[LESS](http://lesscss.org/) を使うためには、
-`lessc` プリプロセッサコマンドをインストールしなければなりません。
+Yii はインストールされたプリプロセッサツールに頼ってアセットを変換します。
+例えば、[LESS](http://lesscss.org/) を使うためには、`lessc` プリプロセッサコマンドをインストールしなければなりません。
 
-下記のように [[yii\web\AssetManager::converter]] を構成することで、プリプロセッサコマンドとサポートされる拡張構文を
-カスタマイズすることが出来ます:
+下記のように [[yii\web\AssetManager::converter]] を構成することで、プリプロセッサコマンドとサポートされる拡張構文をカスタマイズすることが出来ます。
 
 ```php
 return [
@@ -450,38 +426,34 @@ return [
 ```
 
 上記においては、サポートされる拡張構文が [[yii\web\AssetConverter::commands]] プロパティによって定義されています。
-配列のキーはファイルの拡張子 (先頭のドットは省く) であり、配列の値は結果として作られるアセットファイルの拡張子と
-アセット変換を実行するためのコマンドです。コマンドの中の `{from}` と `{to}` のトークンは、ソースのアセットファイルのパスと
-ターゲットのアセットファイルのパスに置き換えられます。
+配列のキーはファイルの拡張子 (先頭のドットは省く) であり、配列の値は結果として作られるアセットファイルの拡張子とアセット変換を実行するためのコマンドです。
+コマンドの中の `{from}` と `{to}` のトークンは、ソースのアセットファイルのパスとターゲットのアセットファイルのパスに置き換えられます。
 
-> Info|情報: 上記で説明した方法の他にも、拡張構文のアセットを扱う方法はあります。例えば、[grunt](http://gruntjs.com/)
-  のようなビルドツールを使って、拡張構文のアセットをモニターし、自動的に変換することが出来ます。この場合は、元のファイルではなく、
-  結果として作られる CSS/JavaScript ファイルをアセットバンドルのリストに挙げなければなりません。
+> Info|情報: 上記で説明した方法の他にも、拡張構文のアセットを扱う方法はあります。
+  例えば、[grunt](http://gruntjs.com/) のようなビルドツールを使って、拡張構文のアセットをモニターし、自動的に変換することが出来ます。
+  この場合は、元のファイルではなく、結果として作られる CSS/JavaScript ファイルをアセットバンドルのリストに挙げなければなりません。
 
 
 ## アセットを結合して圧縮する <a name="combining-compressing-assets"></a>
 
-ウェブページは数多くの CSS および/または JavaScript ファイルをインクルードすることがあり得ます。HTTP リクエストの数と
-これらのファイルの全体としてのダウンロードサイズを削減するためによく用いられる方法は、複数の CSS/JavaScript ファイルを
-結合して圧縮し、一つまたはごく少数のファイルにまとめることです。そして、ウェブページでは元のファイルをインクルードする
-代りに、圧縮されたファイルをインクルードする訳です。
+ウェブページは数多くの CSS および/または JavaScript ファイルをインクルードすることがあり得ます。
+HTTP リクエストの数とこれらのファイルの全体としてのダウンロードサイズを削減するためによく用いられる方法は、複数の CSS/JavaScript ファイルを結合して圧縮し、一つまたはごく少数のファイルにまとめることです。
+そして、ウェブページでは元のファイルをインクルードする代りに、圧縮されたファイルをインクルードする訳です。
  
-> Info|情報: アセットの結合と圧縮は、通常はアプリケーションが実運用モードにある場合に必要になります。開発モードにおいては、
-  たいていは元の CSS/JavaScript ファイルを使う方がデバッグのために好都合です。
+> Info|情報: アセットの結合と圧縮は、通常はアプリケーションが実運用モードにある場合に必要になります。
+  開発モードにおいては、たいていは元の CSS/JavaScript ファイルを使う方がデバッグのために好都合です。
 
 次に、既存のアプリケーションコードを修正する必要なしに、アセットファイルを結合して圧縮する方法を紹介します。
 
 1. アプリケーションの中で、結合して圧縮する予定のアセットバンドルを全て探し出す。
 2. これらのバンドルを一個か数個のグループにまとめる。どのバンドルも一つのグループにしか属することが出来ないことに注意。
 3. 各グループの CSS ファイルを一つのファイルに結合/圧縮する。JavaScript ファイルに対しても同様にこれを行う。
-4. 各グループに対して新しいアセットバンドルを定義する:
-   * [[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] のプロパティを、それぞれ、結合された CSS ファイルと
-     JavaScript ファイルにセットする。
-   * 各グループに属する元のアセットバンドルをカスタマイズして、[[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]]
-     のプロパティを空っぽにし、[[yii\web\AssetBundle::depends|depends]] プロパティにグループのために作られた新しいバンドルを指定する。
+4. 各グループに対して新しいアセットバンドルを定義する。
+   * [[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] のプロパティに、それぞれ、結合された CSS ファイルと JavaScript ファイルをセットする。
+   * 各グループに属する元のアセットバンドルをカスタマイズして、[[yii\web\AssetBundle::css|css]] と [[yii\web\AssetBundle::js|js]] のプロパティを空っぽにし、[[yii\web\AssetBundle::depends|depends]] プロパティにグループのために作られた新しいバンドルを指定する。
 
-この方法を使うと、ビューでアセットバンドルを登録したときに、元のバンドルが属するグループのための新しいアセットバンドルが自動的に
-登録されるようになります。そして、結果として、結合/圧縮されたアセットファイルが、元のファイルの代りに、ページにインクルードされます。
+この方法を使うと、ビューでアセットバンドルを登録したときに、元のバンドルが属するグループのための新しいアセットバンドルが自動的に登録されるようになります。
+そして、結果として、結合/圧縮されたアセットファイルが、元のファイルの代りに、ページにインクルードされます。
 
 
 ### 一例 <a name="example"></a>
@@ -492,28 +464,25 @@ return [
 ページ Y はアセットバンドル B、C、D を使用します。
 
 これらのアセットバンドルを分割する方法は二つあります。一つは単一のグループを使用して全てのアセットバンドルを含める方法です。
-もう一つは、A をグループ X に入れ、D をグループ Y に入れ、そして、B と C をグループ S に入れる方法です。どちらが良いでしょう?
-場合によります。最初の方法の利点は、二つのページが同一の結合された CSS と JavaScript のファイルを共有するため、HTTP キャッシュの
-効果が高くなることです。その一方で、単一のグループが全てのバンドルを含むために、結合された CSS と JavaScript のファイルは
-より大きくなり、従って最初のファイル転送時間はより長くなります。この例では話を簡単にするために、最初の方法、すなわち、
-全てのバンドルを含む単一のグループを使用することにします。
+もう一つは、A をグループ X に入れ、D をグループ Y に入れ、そして、B と C をグループ S に入れる方法です。どちらが良いでしょう? 場合によります。
+最初の方法の利点は、二つのページが同一の結合された CSS と JavaScript のファイルを共有するため、HTTP キャッシュの効果が高くなることです。
+その一方で、単一のグループが全てのバンドルを含むために、結合された CSS と JavaScript のファイルはより大きくなり、従って最初のファイル転送時間はより長くなります。
+この例では話を簡単にするために、最初の方法、すなわち、全てのバンドルを含む単一のグループを使用することにします。
 
-> Info|情報: アセットバンドルをグループに分けることは些細な仕事ではありません。通常、そのためには、いろいろなページの
-  さまざまなアセットの現実世界での転送量を分析することが必要になります。とりあえず、最初は、簡単にするために、
-  単一のグループから始めて良いでしょう。
+> Info|情報: アセットバンドルをグループに分けることは些細な仕事ではありません。
+  通常、そのためには、いろいろなページのさまざまなアセットの現実世界での転送量を分析することが必要になります。
+  とりあえず、最初は、簡単にするために、単一のグループから始めて良いでしょう。
 
-既存のツール (例えば [Closure Compiler](https://developers.google.com/closure/compiler/) や
-[YUI Compressor](https://github.com/yui/yuicompressor/)) を使って、全てのバンドルにある CSS と JavaScript のファイルを
-結合して圧縮します。ファイルは、バンドル間の依存関係を満たす順序に従って結合しなければならないことに注意してください。
-例えば、バンドル A が B に依存し、B が C と D の両方に依存している場合は、アセットファイルの結合順は、最初に C と D、
-次に B、そして最後に A としなければなりません。
+既存のツール (例えば [Closure Compiler](https://developers.google.com/closure/compiler/) や [YUI Compressor](https://github.com/yui/yuicompressor/)) を使って、全てのバンドルにある CSS と JavaScript のファイルを結合して圧縮します。
+ファイルは、バンドル間の依存関係を満たす順序に従って結合しなければならないことに注意してください。
+例えば、バンドル A が B に依存し、B が C と D の両方に依存している場合は、アセットファイルの結合順は、最初に C と D、次に B、そして最後に A としなければなりません。
 
-結合と圧縮が完了すると、一つの CSS ファイルと一つの JavaScript ファイルが得られます。それらは、`all-xyz.css` および
-`all-xyz.js` と命名されたとしましょう。ここで `xyz` は、ファイル名をユニークにして HTTP キャッシュの問題を避ける
-ために使用されるタイムスタンプまたはハッシュを表します。
+結合と圧縮が完了すると、一つの CSS ファイルと一つの JavaScript ファイルが得られます。
+それらは、`all-xyz.css` および `all-xyz.js` と命名されたとしましょう。
+ここで `xyz` は、ファイル名をユニークにして HTTP キャッシュの問題を避けるために使用されるタイムスタンプまたはハッシュを表します。
 
-いよいよ最終ステップです。アプリケーションのコンフィギュレーションの中で、[[yii\web\AssetManager|アセットマネージャ]]
-を次のように構成します:
+いよいよ最終ステップです。
+アプリケーションの構成情報の中で、[[yii\web\AssetManager|アセットマネージャ]] を次のように構成します。
 
 ```php
 return [
@@ -537,15 +506,15 @@ return [
 ];
 ```
 
-[アセットバンドルをカスタマイズする](#customizing-asset-bundles) の項で説明したように、上記のコンフィギュレーションによって
-元のバンドルは全てデフォルトの振る舞いを変更されます。具体的にいえば、バンドル A、B、C、D は、もはやアセットファイルを
-一つも持っていません。この4つは、それぞれ、結合された `all-xyz.css` と `all-xyz.js` ファイルを持つ `all` バンドルに依存するように
-なりました。結果として、ページ X では、バンドル A、B、C から元のソースファイルをインクルードする代りに、これら二つの結合された
-ファイルがインクルードされます。同じことはページ Y でも起ります。
+[アセットバンドルをカスタマイズする](#customizing-asset-bundles) の項で説明したように、上記の構成によって元のバンドルは全てデフォルトの振る舞いを変更されます。
+具体的にいえば、バンドル A、B、C、D は、もはやアセットファイルを一つも持っていません。
+この4つは、それぞれ、結合された `all-xyz.css` と `all-xyz.js` ファイルを持つ `all` バンドルに依存するようになりました。
+結果として、ページ X では、バンドル A、B、C から元のソースファイルをインクルードする代りに、これら二つの結合されたファイルだけがインクルードされます。
+同じことはページ Y でも起ります。
 
-最後にもう一つ、上記の方法をさらにスムーズに運用するためのトリックがあります。アプリケーションのコンフィギュレーションファイルを
-直接修正する代りに、バンドルのカスタマイズ用の配列を独立したファイルに置いて、条件によってそのファイルをアプリケーションの
-コンフィギュレーションにインクルードすることが出来ます。例えば、
+最後にもう一つ、上記の方法をさらにスムーズに運用するためのトリックがあります。
+アプリケーションの構成情報ファイルを直接修正する代りに、バンドルのカスタマイズ用の配列を独立したファイルに置いて、条件によってそのファイルをアプリケーションの構成情報にインクルードすることが出来ます。
+例えば、
 
 ```php
 return [
@@ -557,42 +526,40 @@ return [
 ];
 ```
 
-つまり、アセットバンドルのコンフィギュレーション配列は、実運用モードのためのものは `assets-prod.php` に保存し、
-開発モードのためのものは `assets-dev.php` に保存するという訳です。
+つまり、アセットバンドルの構成情報配列は、実運用モードのためのものは `assets-prod.php` に保存し、開発モードのためのものは `assets-dev.php` に保存するという訳です。
 
 
 ### `asset` コマンドを使う <a name="using-asset-command"></a>
 
 Yii は、たった今説明した方法を自動化するための `asset` という名前のコンソールコマンドを提供しています。
 
-このコマンドを使うためには、最初にコンフィギュレーションファイルを作成して、どのアセットバンドルが結合されるか、そして、
-それらがどのようにグループ化されるかを記述しなければなりません。`asset/template` サブコマンドを使って最初にテンプレートを生成し、
-それをあなたの要求に合うように修正することが出来ます。
+このコマンドを使うためには、最初に構成情報ファイルを作成して、どのアセットバンドルが結合されるか、そして、それらがどのようにグループ化されるかを記述しなければなりません。
+`asset/template` サブコマンドを使って最初にテンプレートを生成し、それをあなたの要求に合うように修正することが出来ます。
 
 ```
 yii asset/template assets.php
 ```
 
-上記のコマンドは、カレントディレクトリに `assets.php` というファイルを生成します。このファイルの内容は以下のようなものです:
+上記のコマンドは、カレントディレクトリに `assets.php` というファイルを生成します。このファイルの内容は以下のようなものです。
 
 ```php
 <?php
 /**
- * "yii asset" コンソールコマンドのためのコンフィギュレーションファイル
+ * "yii asset" コンソールコマンドのための構成情報ファイル
  * コンソール環境では、'@webroot' や '@web' のように、パスエイリアスが存在しない場合があることに注意してください。
  * これらの欠落したパスエイリアスは手作業で定義してください。
  */
 return [
-    // JavaScript ファイルの圧縮のためのコマンド/コールバックを調整:
+    // JavaScript ファイルの圧縮のためのコマンド/コールバックを調整。
     'jsCompressor' => 'java -jar compiler.jar --js {from} --js_output_file {to}',
-    // CSS ファイルの圧縮のためのコマンド/コールバックを調整:
+    // CSS ファイルの圧縮のためのコマンド/コールバックを調整。
     'cssCompressor' => 'java -jar yuicompressor.jar --type css {from} -o {to}',
-    // 圧縮するアセットバンドルのリスト:
+    // 圧縮するアセットバンドルのリスト。
     'bundles' => [
         // 'yii\web\YiiAsset',
         // 'yii\web\JqueryAsset',
     ],
-    // 圧縮出力用のアセットバンドル:
+    // 圧縮出力用のアセットバンドル。
     'targets' => [
         'all' => [
             'class' => 'yii\web\AssetBundle',
@@ -602,36 +569,31 @@ return [
             'css' => 'css/all-{hash}.css',
         ],
     ],
-    // アセットマネージャのコンフィギュレーション:
+    // アセットマネージャの構成情報
     'assetManager' => [
     ],
 ];
 ```
 
 このファイルを修正して、どのバンドルを結合するつもりであるかを `bundles` オプションで指定しなければなりません。
-`targets` オプションでは、バンドルがどのようにグループに分割されるかを指定しなければなりません。既に述べたように、
-一つまたは複数のグループを定義することが出来ます。
+`targets` オプションでは、バンドルがどのようにグループに分割されるかを指定しなければなりません。
+既に述べたように、一つまたは複数のグループを定義することが出来ます。
 
-> Note|注意: パスエイリアス `@webroot` および `@web` はコンソールアプリケーションでは利用できませんので、これらは
-  コンフィギュレーションの中で明示的に定義しなければなりません。
+> Note|注意: パスエイリアス `@webroot` および `@web` はコンソールアプリケーションでは利用できませんので、これらは構成情報の中で明示的に定義しなければなりません。
 
-JavaScript ファイルは結合され、圧縮されて `js/all-{hash}.js` に保存されます。ここで {hash} は、結果として作られたファイルの
-ハッシュで置き換えられるものです。
+JavaScript ファイルは結合され、圧縮されて `js/all-{hash}.js` に保存されます。ここで {hash} は、結果として作られたファイルのハッシュで置き換えられるものです。
 
-`jsCompressor` と `cssCompressor` のオプションは、JavaScript と CSS の結合/圧縮を実行するコンソールコマンドまたは PHP
-コールバックを指定するものです。既定では、Yii は JavaScript ファイルの結合に [Closure Compiler](https://developers.google.com/closure/compiler/) 
-を使い、CSS ファイルの結合に [YUI Compressor](https://github.com/yui/yuicompressor/) を使用します。
+`jsCompressor` と `cssCompressor` のオプションは、JavaScript と CSS の結合/圧縮を実行するコンソールコマンドまたは PHP コールバックを指定するものです。
+既定では、Yii は JavaScript ファイルの結合に [Closure Compiler](https://developers.google.com/closure/compiler/) を使い、CSS ファイルの結合に [YUI Compressor](https://github.com/yui/yuicompressor/) を使用します。
 あなたの好みのツールを使うためには、手作業でツールをインストールしたり、オプションを調整したりしなければなりません。
 
-このコンフィギュレーションファイルを使い、`asset` コマンドを走らせて、アセットファイルを結合して圧縮し、同時に
-新しいアセットバンドルのコンフィギュレーションファイル `assets-prod.php` を生成することが出来ます:
+この構成情報ファイルを使い、`asset` コマンドを走らせて、アセットファイルを結合して圧縮し、同時に、新しいアセットバンドルの構成情報ファイル `assets-prod.php` を生成することが出来ます。
  
 ```
 yii asset assets.php config/assets-prod.php
 ```
 
-直前の項で説明したように、この生成されたコンフィギュレーションファイルをアプリケーションのコンフィギュレーションに
-インクルードすることが出来ます。
+直前の項で説明したように、この生成された構成情報ファイルをアプリケーションの構成情報にインクルードすることが出来ます。
 
 
 > Info|情報: `asset` コマンドを使うことは、アセットの結合・圧縮のプロセスを自動化する唯一の選択肢ではありません。

docs/guide-ja/structure-controllers.md

@@ -3,9 +3,8 @@
 
 コントローラは [MVC](http://ja.wikipedia.org/wiki/Model_View_Controller) アーキテクチャの一部を成すものです。
 これは [[yii\base\Controller]] を拡張したクラスのオブジェクトであり、リクエストの処理とレスポンスの生成について責任を負うものです。
-具体的には、[アプリケーション](structure-applications.md) から制御を引き継いだ後、コントローラは入ってきたリクエストのデータを分析し、
-それを [モデル](structure-models.md) に引き渡して、モデルが生成した結果を [ビュー](structure-views.md) に投入し、
-最終的に外に出て行くレスポンスを生成します。
+具体的には、[アプリケーション](structure-applications.md) から制御を引き継いだ後、コントローラは入ってきたリクエストのデータを分析し、それを [モデル](structure-models.md) 
+に引き渡して、モデルが生成した結果を [ビュー](structure-views.md) に投入し、最終的に外に出て行くレスポンスを生成します。
 
 
 ## アクション<a name="actions"></a>
@@ -14,7 +13,7 @@
 アクションは、エンドユーザがアドレスを指定して実行をリクエストできる最も基本的な構成単位です。
 コントローラは一つまたは複数のアクションを持ち得ます。
 
-次の例は、`view` と `create` という二つのアクションを持つ `post` コントローラを示すものです:
+次の例は、`view` と `create` という二つのアクションを持つ `post` コントローラを示すものです。
 
 ```php
 namespace app\controllers;
@@ -53,8 +52,7 @@ class PostController extends Controller
 }
 ```
 
-`view` アクション (`actionView()` メソッドで定義されます) において、
-コードは最初に、リクエストされたモデルの ID に従って [モデル](structure-models.md) を読み出します。
+`view` アクション (`actionView()` メソッドで定義されます) において、コードは最初に、リクエストされたモデルの ID に従って [モデル](structure-models.md) を読み出します。
 モデルの読み出しが成功したときは、`view` という名前の [ビュー](structure-views.md) を使ってモデルを表示します。
 失敗したときは例外を投げます。
 
@@ -69,32 +67,32 @@ class PostController extends Controller
 エンドユーザは、いわゆる *ルート* によって、アクションのアドレスを指定します。
 ルートは、次の部分からなる文字列です。
 
-* モジュール ID: この部分は、コントローラがアプリケーションではなく [モジュール](structure-modules.md) に属する場合にのみ存在します;
+* モジュール ID: この部分は、コントローラがアプリケーションではなく [モジュール](structure-modules.md) に属する場合にのみ存在します。
 * コントローラ ID: 同じアプリケーション (または、コントローラがモジュールに属する場合は、同じモジュール)
-  に属する全てのコントローラの中から、特定のコントローラを指定するユニークな文字列;
+  に属する全てのコントローラの中から、特定のコントローラを指定するユニークな文字列。
 * アクション ID: 同じコントローラに属する全てのアクションの中から、特定のアクションを指定するユニークな文字列。
 
-ルートは次の形式を取ります:
+ルートは次の形式を取ります。
 
 ```
 ControllerID/ActionID
 ```
 
-または、コントローラがモジュールに属する場合は、次の形式を取ります:
+または、コントローラがモジュールに属する場合は、次の形式を取ります。
 
 ```php
 ModuleID/ControllerID/ActionID
 ```
 
 ですから、ユーザが `http://hostname/index.php?r=site/index` という URL でリクエストをした場合は、`site` コントローラの中の `index` アクションが実行されます。
-どのようにしてルートがアクションとして解決されるかについて、更なる詳細は [ルーティングと URL 生成](runtime-routing.md) の節を参照してください。
+ルートがどのようにしてアクションとして解決されるかについての詳細は、[ルーティングと URL 生成](runtime-routing.md) の節を参照してください。
 
 
 ## コントローラを作成する<a name="creating-controllers"></a>
 
-[[yii\web\Application|ウェブアプリケーション]] では、コントローラは [[yii\web\Controller]] またはその子クラスから派生させるべきです。
-同様に、[[yii\console\Application|コンソールアプリケーション]] では、コントローラは [[yii\console\Controller]] またはその子クラスから派生させるべきです。
-次のコードは `site` コントローラを定義するものです:
+[[yii\web\Application|ウェブアプリケーション]] では、コントローラは [[yii\web\Controller]] またはその子クラスから派生させるべきものです。
+同様に、[[yii\console\Application|コンソールアプリケーション]] では、コントローラは [[yii\console\Controller]] またはその子クラスから派生させるべきものです。
+次のコードは `site` コントローラを定義するものです。
 
 ```php
 namespace app\controllers;
@@ -113,43 +111,41 @@ class SiteController extends Controller
 この理由により、たいていはコントローラが処理するリソースの型を示す名詞をコントローラの ID として使います。
 例えば、記事データを処理するコントローラの ID としては、`article` を使うことが出来ます。
 
-既定では、コントローラの ID は、以下の文字のみを含むべきものです: すなわち、小文字の英字、数字、アンダースコア、ダッシュ、
-および、フォワードスラッシュ。
+既定では、コントローラの ID は、小文字の英字、数字、アンダースコア、ダッシュ、および、フォワードスラッシュのみを含むべきものです。
 例えば、`article` と `post-comment` はともに有効なコントローラの ID ですが、`article?`、`PostComment`、`admin\post` は有効ではありません。
 
-コントローラの ID は、サブディレクトリの接頭辞を含んでも構いません。例えば、`admin/article` は、
-[[yii\base\Application::controllerNamespace|コントローラ名前空間]] の下の `admin` サブディレクトリにある `article` コントローラを表します。
-サブディレクトリの接頭辞として有効な文字は以下を含みます: 小文字または大文字の英字、数字、アンダースコア、そして、
-フォワードスラッシュ。フォワードスラッシュは、複数レベルのサブディレクトリの区切り文字として使われます (例えば、`panels/admin`)。
+コントローラの ID は、サブディレクトリの接頭辞を含んでも構いません。例えば、`admin/article` は、[[yii\base\Application::controllerNamespace|コントローラ名前空間]]
+の下の `admin` サブディレクトリにある `article` コントローラを表します。
+サブディレクトリの接頭辞として有効な文字は、小文字または大文字の英字、数字、アンダースコア、そして、
+フォワードスラッシュです。
+フォワードスラッシュは、複数レベルのサブディレクトリの区切り文字として使われます (例えば、`panels/admin`)。
 
 
 ### コントローラクラスの命名規則<a name="controller-class-naming"></a>
 
-コントローラクラスの名前は下記の規則に従ってコントローラの ID から導出することが出来ます:
+コントローラクラスの名前は下記の規則に従ってコントローラの ID から導出することが出来ます。
 
-* ダッシュで区切られた各単語の最初の文字を大文字に変える。コントローラ ID がスラッシュを含む場合、
-  この規則は ID の最後のスラッシュの後ろの部分にのみ適用されることに注意。
+* ダッシュで区切られた各単語の最初の文字を大文字に変える。
+  コントローラ ID がスラッシュを含む場合、この規則は ID の最後のスラッシュの後ろの部分にのみ適用されることに注意。
 * ダッシュを削除し、フォワードスラッシュを全てバックワードスラッシュに置き換える。
 * 接尾辞 `Controller` を追加する。
 * そして、[[yii\base\Application::controllerNamespace|コントローラ名前空間]] を頭に付ける。
 
-以下は、[[yii\base\Application::controllerNamespace|コントローラ名前空間]] がデフォルト値 `app\controllers` を取っていると
-仮定したときの、いくつかの例です:
+以下は、[[yii\base\Application::controllerNamespace|コントローラ名前空間]] がデフォルト値 `app\controllers` を取っていると仮定したときの、いくつかの例です。
 
-* `article` から `app\controllers\ArticleController` が導出される;
-* `post-comment` から `app\controllers\PostCommentController` が導出される;
-* `admin/post-comment` から `app\controllers\admin\PostCommentController` が導出される;
+* `article` から `app\controllers\ArticleController` が導出される。
+* `post-comment` から `app\controllers\PostCommentController` が導出される。
+* `admin/post-comment` から `app\controllers\admin\PostCommentController` が導出される。
 * `adminPanels/post-comment` から `app\controllers\adminPanels\PostCommentController` が導出される。
 
-コントローラクラスは [オートロード可能](concept-autoloading.md) でなければなりません。この理由により、
-上記の例の `aritcle` コントローラクラスは [エイリアス](concept-aliases.md) が `@app/controllers/ArticleController.php` である
-ファイルに保存されるべきものとなります。一方、`admin/post2-comment` コントローラは `@app/controllers/admin/Post2CommentController.php`
+コントローラクラスは [オートロード可能](concept-autoloading.md) でなければなりません。
+この理由により、上記の例の `aritcle` コントローラクラスは [エイリアス](concept-aliases.md) が `@app/controllers/ArticleController.php`
+であるファイルに保存されるべきものとなります。一方、`admin/post2-comment` コントローラは `@app/controllers/admin/Post2CommentController.php`
 というエイリアスのファイルに保存されるべきものとなります。
 
-> Info|情報: 最後の例である `admin/post2-comment` は、どうすれば [[yii\base\Application::controllerNamespace|コントローラ名前空間]] の
-  サブディレクトリにコントローラを置くことが出来るかを示しています。
-  この方法は、コントローラをいくつかのカテゴリに分けて組織したい、けれども [モジュール](structure-modules.md) は使いたくない、
-  という場合に役立ちます。
+> Info|情報: 最後の例である `admin/post2-comment` は、どうすれば [[yii\base\Application::controllerNamespace|コントローラ名前空間]]
+  のサブディレクトリにコントローラを置くことが出来るかを示しています。
+  この方法は、コントローラをいくつかのカテゴリに分けて整理したい、けれども [モジュール](structure-modules.md) は使いたくない、という場合に役立ちます。
 
 
 ### コントローラマップ<a name="controller-map"></a>
@@ -157,7 +153,7 @@ class SiteController extends Controller
 [[yii\base\Application::controllerMap|コントローラマップ]] を構成すると、上で述べたコントローラの ID とクラス名の制約を乗り越えることが出来ます。
 これは、主として、クラス名に対する制御が及ばないサードパーティのコントローラを使おうとする場合に有用です。
 
-[[yii\base\Application::controllerMap|コントローラマップ]] は [アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で、次のように構成することが出来ます:
+[[yii\base\Application::controllerMap|コントローラマップ]] は [アプリケーションの構成情報](structure-applications.md#application-configurations) の中で、次のように構成することが出来ます。
 
 ```php
 [
@@ -165,7 +161,7 @@ class SiteController extends Controller
         // クラス名を使って "account" コントローラを宣言する
         'account' => 'app\controllers\UserController',
 
-        // コンフィギュレーション配列を使って "article" コントローラを宣言する
+        // 構成情報配列を使って "article" コントローラを宣言する
         'article' => [
             'class' => 'app\controllers\PostController',
             'enableCsrfValidation' => false,
@@ -182,7 +178,7 @@ class SiteController extends Controller
 [[yii\web\Application|ウェブアプリケーション]] では、この値は `'site'` であり、一方、[[yii\console\Application|コンソールアプリケーション]] では、`help` です。
 従って、URL が `http://hostname/index.php` である場合は、`site` コントローラがリクエストを処理することになります。
 
-次のように [アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) を構成して、デフォルトコントローラを変更することが出来ます:
+次のように [アプリケーションの構成情報](structure-applications.md#application-configurations) を構成して、デフォルトコントローラを変更することが出来ます。
 
 ```php
 [
@@ -196,7 +192,7 @@ class SiteController extends Controller
 アクションの作成は、コントローラクラスの中にいわゆる *アクションメソッド* を定義するだけの簡単なことです。
 アクションメソッドとは、`action` という語で始まる名前を持つ *public* メソッドのことです。
 アクションメソッドの返り値がエンドユーザに送信されるレスポンスデータを表します。
-次のコードは、`index` と `hello-world` という二つのアクションを定義するものです:
+次のコードは、`index` と `hello-world` という二つのアクションを定義するものです。
 
 ```php
 namespace app\controllers;
@@ -220,52 +216,51 @@ class SiteController extends Controller
 
 ### アクション ID<a name="action-ids"></a>
 
-アクションは、たいてい、あるリソースについて特定の操作を実行するように設計されます。この理由により、
-アクション ID は、通常、`view`、`update` などのような動詞になります。
+アクションは、たいてい、あるリソースについて特定の操作を実行するように設計されます。
+この理由により、アクション ID は、通常、`view`、`update` などのような動詞になります。
 
-既定では、アクション ID は次の文字のみを含むべきものです: すなわち、小文字の英字、数字、アンダースコア、そして、ダッシュ。
-アクション ID の中のダッシュは単語を分けるために使われます。例えば、
-`view`、`update2`、`comment-post` は全て有効なアクション ID ですが、`view?`、`Update` は有効ではありません。
+既定では、アクション ID は、小文字の英字、数字、アンダースコア、そして、ダッシュのみを含むべきものです。
+アクション ID の中のダッシュは単語を分けるために使われます。
+例えば、`view`、`update2`、`comment-post` は全て有効なアクション ID ですが、`view?`、`Update` は有効ではありません。
 
-アクションは二つの方法で作成することが出来ます: すなわち、インラインアクションとスタンドアロンアクションです。
+アクションは二つの方法で作成することが出来ます。すなわち、インラインアクションとスタンドアロンアクションです。
 インラインアクションはコントローラクラスのメソッドとして定義されるものであり、一方、スタンドアロンアクションは
 [[yii\base\Action]] またはその子クラスから派生させたクラスです。
 インラインアクションは作成するのにより少ない労力を要し、アクションを再利用する意図がない場合によく推奨されます。
-もう一方で、スタンドアロンアクションは、主として、さまざまなコントローラの中で使われることや、
-[エクステンション](structure-extensions.md) として再配布されることを意図して作成されます。
+もう一方で、スタンドアロンアクションは、主として、さまざまなコントローラの中で使われることや、[エクステンション](structure-extensions.md)
+として再配布されることを意図して作成されます。
 
 
 ### インラインアクション<a name="inline-actions"></a>
 
 インラインアクションは、たった今説明したように、アクションメソッドとして定義されるアクションを指します。
 
-アクションメソッドの名前は、次の基準に従って、アクション ID から導出されます:
+アクションメソッドの名前は、次の基準に従って、アクション ID から導出されます。
 
-* アクション ID に含まれる各単語の最初の文字を大文字に変換する;
-* ダッシュを削除する;
-* 前置辞 `action` を前に付ける。
+* アクション ID に含まれる各単語の最初の文字を大文字に変換する。
+* ダッシュを削除する。
+* 接頭辞 `action` を前に付ける。
 
 例えば、`index` は `actionIndex` となり、`hello-world` は `actionHelloWorld` となります。
 
-> Note|注意: アクションメソッドの名前は、*大文字と小文字を区別* します。`ActionIndex` という名前のメソッドがあっても、
-  それはアクションメソッドとは見なされず、結果として、`index` アクションに対するリクエストは例外に帰結します。
-  アクションメソッドが public でなければならない事にも注意してください。private や protected なメソッドが
-  インラインアクションを定義することはありません。
+> Note|注意: アクションメソッドの名前は、*大文字と小文字を区別* します。`ActionIndex`
+  という名前のメソッドがあっても、  それはアクションメソッドとは見なされず、結果として、`index`
+  アクションに対するリクエストは例外に帰結します。
+  アクションメソッドが public でなければならない事にも注意してください。
+  private や protected なメソッドがインラインアクションを定義することはありません。
 
 
-アクションは、作成するのにほとんど労力を要さないため、たいていの場合、インラインアクションとして定義されます。
-しかしながら、同じアクションを別の場所で再利用する計画があったり、また、アクションを再配布したいと思ったりする場合は、
-*スタンドアロンアクション* として定義することを考慮すべきです。
+インラインアクションは作成するのにほとんど労力を要さないため、たいていのアクションはインラインアクションとして定義されます。
+しかし、同じアクションを別の場所で再利用する計画を持っていたり、また、アクションを再配布したいと思っていたりする場合は、アクションを *スタンドアロンアクション* として定義することを考慮すべきです。
 
 
 ### スタンドアロンアクション<a name="standalone-actions"></a>
 
 スタンドアロンアクションは、[[yii\base\Action]] またはその子クラスを拡張したクラスとして定義されるものです。
-例えば、Yii のリリースに [[yii\web\ViewAction]] と [[yii\web\ErrorAction]] が含まれていますが、これらは両方とも
-スタンドアロンアクションです。
+例えば、Yii のリリースに [[yii\web\ViewAction]] と [[yii\web\ErrorAction]] が含まれていますが、これらは両方ともスタンドアロンアクションです。
 
-スタンドアロンアクションを使用するためには、下記のように、コントローラの [[yii\base\Controller::actions()]] メソッドを
-オーバーライドして、スタンドアロンアクションを *アクションマップ* の中で宣言します:
+スタンドアロンアクションを使用するためには、下記のように、コントローラの [[yii\base\Controller::actions()]]
+メソッドをオーバーライドして、スタンドアロンアクションを *アクションマップ* の中で宣言します。
 
 ```php
 public function actions()
@@ -274,7 +269,7 @@ public function actions()
         // クラス名を使って "error" アクションを宣言する
         'error' => 'yii\web\ErrorAction',
 
-        // コンフィギュレーション配列を使って "view" アクションを宣言する
+        // 構成情報配列を使って "view" アクションを宣言する
         'view' => [
             'class' => 'yii\web\ViewAction',
             'viewPrefix' => '',
@@ -283,10 +278,8 @@ public function actions()
 }
 ```
 
-見ると分かるように、`actions()` メソッドは、キーがアクション ID であり、値が対応するアクションのクラス名または
-[コンフィギュレーション](concept-configurations.md) である配列を返すべきものです。
-インラインアクションと違って、スタンドアロンアクションのアクション ID は、`actions()` メソッドにおいて宣言される
-限りにおいて、任意の文字を含むことが出来ます。
+見ると分かるように、`actions()` メソッドは、キーがアクション ID であり、値が対応するアクションのクラス名または [構成情報](concept-configurations.md) である配列を返すべきものです。
+インラインアクションと違って、スタンドアロンアクションのアクション ID は、`actions()` メソッドにおいて宣言される限りにおいて、任意の文字を含むことが出来ます。
 
 
 スタンドアロンアクションクラスを作成するためには、[[yii\base\Action]] またはその子クラスを拡張して、
@@ -316,14 +309,12 @@ class HelloWorldAction extends Action
 
 返り値は、エンドユーザにレスポンスとして送信される [レスポンス](runtime-responses.md) オブジェクトとすることが出来ます。
 
-* [[yii\web\Application|ウェブアプリケーション]] では、返り値を、[[yii\web\Response::data]] に割り当てられ、
-  さらにレスポンスの本文を表す文字列へと変換される任意のデータとすることも出来ます。
-* [[yii\console\Application|コンソールアプリケーション]] では、返り値をコマンド実行の [[yii\console\Response::exitStatus|終了ステータス]]
-  を示す整数とすることも出来ます。
+* [[yii\web\Application|ウェブアプリケーション]] では、[[yii\web\Response::data]] に割り当てられて後にレスポンスの本文を表す文字列へと変換される、任意のデータとすることも出来ます。
+* [[yii\console\Application|コンソールアプリケーション]] では、返り値をコマンド実行の [[yii\console\Response::exitStatus|終了ステータス]] を示す整数とすることも出来ます。
 
 これまでに示した例においては、アクションの結果はすべて文字列であり、エンドユーザに送信されるレスポンスの本文として扱われるものでした。
 次の例では、アクションがレスポンスオブジェクトを返すことによって、ユーザのブラウザを新しい URL にリダイレクトすることが出来る様子が示されています
-([[yii\web\Controller::redirect()|redirect()]] メソッドの返り値はレスポンスオブジェクトです):
+([[yii\web\Controller::redirect()|redirect()]] メソッドの返り値はレスポンスオブジェクトです)。
 
 ```php
 public function actionForward()
@@ -336,13 +327,12 @@ public function actionForward()
 
 ### アクションパラメータ<a name="action-parameters"></a>
 
-インラインアクションのアクションメソッドと、スタンドアロンアクションの `run()` メソッドは、
-*アクションパラメータ* と呼ばれる引数を取ることが出来ます。
+インラインアクションのアクションメソッドと、スタンドアロンアクションの `run()` メソッドは、*アクションパラメータ* と呼ばれる引数を取ることが出来ます。
 パラメータの値はリクエストから取得されます。
 [[yii\web\Application|ウェブアプリケーション]] では、各アクションパラメータの値は `$_GET` からパラメータ名をキーとして読み出されます。
 [[yii\console\Application|コンソールアプリケーション]] では、アクションパラメータはコマンドライン引数に対応します。
 
-次の例では、`view` アクション (インラインアクションです) は、二つのパラメータを宣言しています: すなわち、`$id` と `$version` です。
+次の例では、`view` アクション (インラインアクションです) は、二つのパラメータ、すなわち、`$id` と `$version` を宣言しています。
 
 ```php
 namespace app\controllers;
@@ -358,18 +348,15 @@ class PostController extends Controller
 }
 ```
 
-アクションパラメータは、次のように、さまざまなリクエストに応じて値を投入されます:
+アクションパラメータは、次のように、さまざまなリクエストに応じて値を投入されます。
 
-* `http://hostname/index.php?r=post/view&id=123`: `$id` パラメータには `'123'` という値が入れられますが、
-  `version` というクエリパラメータが無いので、`$version` は null のままになります。
-* `http://hostname/index.php?r=post/view&id=123&version=2`: `$id` および `$version` パラメータに、それぞれ、
-  `'123'` と `'2'` が入ります。
-* `http://hostname/index.php?r=post/view`: 必須の `$id` パラメータがリクエストで提供されていないため、
-  [[yii\web\BadRequestHttpException]] 例外が投げられます。
-* `http://hostname/index.php?r=post/view&id[]=123`: `$id` パラメータが予期しない配列値 `['123']` を受け取ろうとするため、
-  [[yii\web\BadRequestHttpException]] 例外が投げられます。
+* `http://hostname/index.php?r=post/view&id=123`: `$id` パラメータには `'123'` という値が入れられますが、`version`
+  というクエリパラメータは無いので、`$version` は null のままになります。
+* `http://hostname/index.php?r=post/view&id=123&version=2`: `$id` および `$version` パラメータに、それぞれ、`'123'` と `'2'` が入ります。
+* `http://hostname/index.php?r=post/view`: 必須の `$id` パラメータがリクエストで提供されていないため、 [[yii\web\BadRequestHttpException]] 例外が投げられます。
+* `http://hostname/index.php?r=post/view&id[]=123`: `$id` パラメータが予期しない配列値 `['123']` を受け取ろうとするため、[[yii\web\BadRequestHttpException]] 例外が投げられます。
 
-アクションパラメータに配列値を受け取らせたい場合は、以下のように、パラメータに `array` の型ヒントを付けなければなりません:
+アクションパラメータに配列値を受け取らせたい場合は、以下のように、パラメータに `array` の型ヒントを付けなければなりません。
 
 ```php
 public function actionView(array $id, $version = null)
@@ -378,13 +365,11 @@ public function actionView(array $id, $version = null)
 }
 ```
 
-このようにすると、リクエストが `http://hostname/index.php?r=post/view&id[]=123` である場合、`$id` パラメータは
-`['123']` という値を受け取るようになります。
-リクエストが `http://hostname/index.php?r=post/view&id=123` である場合も、スカラ値 `'123'` が自動的に配列に変換されるため、
-`$id` パラメータは引き続き同じ配列値を受け取ります。
+このようにすると、リクエストが `http://hostname/index.php?r=post/view&id[]=123` である場合、`$id` パラメータは `['123']` という値を受け取るようになります。
+リクエストが `http://hostname/index.php?r=post/view&id=123` である場合も、スカラ値 `'123'` が自動的に配列に変換されるため、`$id` パラメータは引き続き同じ配列値を受け取ります。
 
 上記の例は主としてウェブアプリケーションでのアクションパラメータの動作を示すものです。
-コンソールアプリケーションについては、[コンソールコマンド](tutorial-console.md) の節で更なる詳細を参照してください。
+コンソールアプリケーションについては、[コンソールコマンド](tutorial-console.md) の節で詳細を参照してください。
 
 
 ### デフォルトアクション<a name="default-action"></a>
@@ -393,7 +378,7 @@ public function actionView(array $id, $version = null)
 [ルート](#ids-routes) がコントローラ ID のみを含む場合は、指定されたコントローラのデフォルトアクションがリクエストされたことを意味します。
 
 既定では、デフォルトアクションは `index` と設定されます。
-このデフォルト値を変更したい場合は、以下のように、コントローラクラスでこのプロパティをオーバーライドするだけです:
+このデフォルト値を変更したい場合は、以下のように、コントローラクラスでこのプロパティをオーバーライドするだけです。
 
 ```php
 namespace app\controllers;
@@ -414,40 +399,34 @@ class SiteController extends Controller
 
 ## コントローラのライフサイクル<a name="controller-lifecycle"></a>
 
-リクエストを処理するときに、[アプリケーション](structure-applications.md) はリクエストされた [ルート](#routes)に基いてコントローラを作成します。
-そして、次に、コントローラはリクエストに応じるために以下のライフサイクルを経過します:
+リクエストを処理するときに、[アプリケーション](structure-applications.md) はリクエストされた [ルート](#routes) に基いてコントローラを作成します。
+そして、次に、コントローラはリクエストに応じるために以下のライフサイクルを経過します。
 
 1. コントローラが作成され構成された後、[[yii\base\Controller::init()]] メソッドが呼ばれる。
-2. コントローラは、リクエストされたアクション ID に基いて、アクションオブジェクトを作成する:
+2. コントローラは、リクエストされたアクション ID に基いて、アクションオブジェクトを作成する。
    * アクション ID が指定されていないときは、[[yii\base\Controller::defaultAction|デフォルトアクション ID]] が使われる。
-   * アクション ID が [[yii\base\Controller::actions()|アクションマップ]] の中に見つかった場合は、
-     スタンドアロンアクションが作成される。
+   * アクション ID が [[yii\base\Controller::actions()|アクションマップ]] の中に見つかった場合は、スタンドアロンアクションが作成される。
    * アクション ID に合致するアクションメソッドが見つかった場合は、インラインアクションが作成される。
    * アクションが見つからないと、[[yii\base\InvalidRouteException]] 例外が投げられる。
-3. コントローラは、アプリケーション、(コントローラがモジュールに属する場合は) モジュール、そしてコントローラの
-   `beforeAction()` メソッドをこの順で呼び出す:
-   * どれか一つの呼び出しが false を返した場合は、残りのまだ呼ばれていない `beforeAction()` はスキップされ、
-     アクションの実行はキャンセルされる。
-   * 既定では、それぞれの `beforeAction()` メソッドは、ハンドラを取り付けることが出来る `beforeAction` イベントをトリガする。
-4. コントローラがアクションを走らせる:
+3. コントローラは、アプリケーション、(コントローラがモジュールに属する場合は) モジュール、そしてコントローラの `beforeAction()` メソッドをこの順で呼び出す。
+   * どれか一つの呼び出しが false を返した場合は、残りのまだ呼ばれていない `beforeAction()` はスキップされ、アクションの実行はキャンセルされる。
+   * 既定では、それぞれの `beforeAction()` メソッドは、ハンドラをアタッチすることが可能な `beforeAction` イベントをトリガする。
+4. コントローラがアクションを走らせる。
    * リクエストデータが解析されて、アクションパラメータにデータが投入される。
-5. コントローラは、コントローラ、(コントローラがモジュールに属する場合は) モジュール、そしてアプリケーションの
-   `afterAction()` メソッドをこの順で呼び出す。
-   * 既定では、それぞれの `afterAction()` メソッドは、ハンドラを取り付けることが出来る `afterAction` イベントをトリガする。
+5. コントローラは、コントローラ、(コントローラがモジュールに属する場合は) モジュール、そしてアプリケーションの `afterAction()` メソッドをこの順で呼び出す。
+   * 既定では、それぞれの `afterAction()` メソッドは、ハンドラをアタッチすることが可能な `afterAction` イベントをトリガする。
 6. アプリケーションはアクションの結果を受け取り、それを [レスポンス](runtime-responses.md) に割り当てる。
 
 
 ## 最善の慣行<a name="best-practices"></a>
 
-良く設計されたアプリケーションでは、コントローラはたいてい非常に軽いものになり、
-それぞれのアクションは数行のコードしか含まないものになります。
-あなたのコントローラが少々複雑になっている場合、そのことは、通常、コントローラをリファクタして、
-コードの一部を他のクラスに移動すべきことを示すものです。
+良く設計されたアプリケーションでは、コントローラはたいてい非常に軽いものになり、それぞれのアクションは数行のコードしか含まないものになります。
+あなたのコントローラが少々複雑になっている場合、そのことは、通常、コントローラをリファクタして、コードの一部を他のクラスに移動すべきことを示すものです。
 
 要約すると、コントローラは、
 
-* [リクエスト](runtime-requests.md) データにアクセスすることが出来ます;
-* リクエストデータを使って [モデル](structure-models.md) や他のサービスコンポーネントのメソッドを呼ぶことが出来ます;
-* [ビュー](structure-views.md) を使ってレスポンスを構成することが出来ます;
-* リクエストされたデータの処理をするべきではありません - データは [モデル](structure-models.md) において処理されるべきです;
+* [リクエスト](runtime-requests.md) データにアクセスすることが出来ます。
+* リクエストデータを使って [モデル](structure-models.md) や他のサービスコンポーネントのメソッドを呼ぶことが出来ます。
+* [ビュー](structure-views.md) を使ってレスポンスを構成することが出来ます。
+* リクエストされたデータの処理をするべきではありません - データは [モデル](structure-models.md) において処理されるべきです。
 * HTML を埋め込むなどの表示に関わるコードは避けるべきです - 表示は [ビュー](structure-views.md) で行う方が良いです。

docs/guide-ja/structure-entry-scripts.md

@@ -3,30 +3,27 @@
 
 エントリスクリプトは、アプリケーションのブートストラップ過程のチェーンにおける最初の環です。
 アプリケーションは (ウェブアプリケーションであれ、コンソールアプリケーションであれ）単一のエントリスクリプトを持ちます。
-エンドユーザはエントリスクリプトに対してリクエストを発行し、エントリスクリプトはアプリケーションのインスタンスを作成して、
-それにリクエストを送付します。
+エンドユーザはエントリスクリプトに対してリクエストを発行し、エントリスクリプトはアプリケーションのインスタンスを作成して、それにリクエストを送付します。
 
-ウェブアプリケーションのエントリスクリプトは、エンドユーザからアクセス出来るように、
-ウェブからのアクセスが可能なディレクトリの下に保管されなければなりません。
-大抵は `index.php` と名付けられますが、ウェブサーバが見つけることが出来る限り、どのような名前を使っても構いません。
+ウェブアプリケーションのエントリスクリプトは、エンドユーザからアクセス出来るように、ウェブからのアクセスが可能なディレクトリの下に保管されなければなりません。
+たいていは `index.php` と名付けられますが、ウェブサーバが見つけることが出来る限り、どのような名前を使っても構いません。
 
-コンソールアプリケーションのエントリスクリプトは、通常は、アプリケーションの [ベースパス](structure-applications.md) の
-下に保管され、`yii` と名付けられます (`.php` の拡張子を伴います) 。
+コンソールアプリケーションのエントリスクリプトは、通常は、アプリケーションの [ベースパス](structure-applications.md) の下に保管され、`yii` と名付けられます (`.php` の拡張子を伴います) 。
 これは、ユーザが `./yii <route> [引数] [オプション]` というコマンドによってコンソールアプリケーションを走らせることが出来るようにするためのスクリプトであり、実行可能なパーミッションを与えられるべきものです。
 
-エントリスクリプトは主として次の仕事をします:
+エントリスクリプトは主として次の仕事をします。
 
 * グローバルな定数を定義する;
-* [Composer のオートローダ](http://getcomposer.org/doc/01-basic-usage.md#autoloading) を登録する;
-* [[Yii]] クラスファイルをインクルードする;
-* アプリケーションのコンフィギュレーションを読み出す;
-* [アプリケーション](structure-applications.md) のインスタンスを生成して構成する;
+* [Composer のオートローダ](http://getcomposer.org/doc/01-basic-usage.md#autoloading) を登録する。
+* [[Yii]] クラスファイルをインクルードする。
+* アプリケーションの構成情報を読み出す。
+* [アプリケーション](structure-applications.md) のインスタンスを生成して構成する。
 * [[yii\base\Application::run()]] を呼んで、受け取ったリクエストを処理する。
 
 
 ## ウェブアプリケーション<a name="web-applications"></a>
 
-次に示すのが、[ベーシックウェブアプリケーションテンプレート](start-installation.md) のエントリスクリプトです:
+次に示すのが、[ベーシックウェブアプリケーションテンプレート](start-installation.md) のエントリスクリプトです。
 
 ```php
 <?php
@@ -40,7 +37,7 @@ require(__DIR__ . '/../vendor/autoload.php');
 // Yii クラスファイルをインクルード
 require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
 
-// アプリケーションのコンフィギュレーションを読み出す
+// アプリケーションの構成情報を読み出す
 $config = require(__DIR__ . '/../config/web.php');
 
 // アプリケーションを作成し、構成して、走らせる
@@ -75,7 +72,7 @@ require(__DIR__ . '/vendor/autoload.php');
 // Yii クラスファイルをインクルード
 require(__DIR__ . '/vendor/yiisoft/yii2/Yii.php');
 
-// アプリケーションのコンフィギュレーションを読み出す
+// アプリケーションの構成情報を読み出す
 $config = require(__DIR__ . '/config/console.php');
 
 $application = new yii\console\Application($config);
@@ -90,23 +87,22 @@ exit($exitCode);
 Yii は下記の三つの定数をサポートしています:
 
 * `YII_DEBUG`: アプリケーションがデバッグモードで走るかどうかを規定します。
-  デバッグモードにおいては、アプリケーションはより多くのログ情報を保持し、
-  例外が投げられたときに、より詳細なエラーのコールスタックを表示します。
+  デバッグモードにおいては、アプリケーションはより多くのログ情報を保持し、例外が投げられたときに、より詳細なエラーのコールスタックを表示します。
   この理由により、デバッグモードは主として開発時に使用されるべきものとなります。
   `YII_DEBUG` の既定値は false です。
 * `YII_ENV`: どういう環境でアプリケーションが走るかを規定します。
-  詳細については、[コンフィギュレーション](concept-configurations.md#environment-constants) の節で説明されます。
+  詳細については、[構成情報](concept-configurations.md#environment-constants) の節で説明されます。
   `YII_ENV` の既定値は `'prod'` です。これはアプリケーションが実運用環境で走ることを意味します。
 * `YII_ENABLE_ERROR_HANDLER`: Yii によって提供されるエラーハンドラを有効にするかどうかを規定します。
   この定数の既定値は true です。
 
-定数を定義するときには、しばしば次のようなコードを用います:
+定数を定義するときには、しばしば次のようなコードを用います。
 
 ```php
 defined('YII_DEBUG') or define('YII_DEBUG', true);
 ```
 
-これは下記のコードと同じ意味のものです:
+これは下記のコードと同じ意味のものです。
 
 ```php
 if (!defined('YII_DEBUG')) {

docs/guide-ja/structure-extensions.md

 エクステンション
 ================
 
-エクステンションは、Yii のアプリケーションで使われることに限定して設計され、そのまますぐに使える機能を提供する
-再配布可能なソフトウェアパッケージです。例えば、[yiisoft/yii2-debug](tool-debugger.md) エクステンションは、
-あなたのアプリケーションにおいて、全てのページの末尾に便利なデバッグツールバーを追加して、ページが生成される過程を
-より容易に把握できるように手助けしてくれます。エクステンションを使うと、あなたの開発プロセスを加速することが出来ます。
+エクステンションは、Yii のアプリケーションで使われることに限定して設計され、そのまますぐに使える機能を提供する再配布可能なソフトウェアパッケージです。
+例えば、[yiisoft/yii2-debug](tool-debugger.md) エクステンションは、あなたのアプリケーションにおいて、全てのページの末尾に便利なデバッグツールバーを追加して、ページが生成される過程をより容易に把握できるように手助けしてくれます。
+エクステンションを使うと、あなたの開発プロセスを加速することが出来ます。
 また、あなたのコードをエクステンションとしてパッケージ化すると、あなたの優れた仕事を他の人たちと共有することが出来ます。
 
 > Info|情報: 「エクステンション」という用語は Yii に限定されたソフトウェアパッケージを指すものとして使用します。
@@ -12,25 +11,24 @@
 
 ## エクステンションを使う <a name="using-extensions"></a>
 
-エクステンションを使うためには、先ずはそれをインストールする必要があります。ほとんどのエクステンションは [Composer](https://getcomposer.org/)
-のパッケージとして配布されていて、次の二つの簡単なステップをふめばインストールすることが出来ます:
+エクステンションを使うためには、先ずはそれをインストールする必要があります。
+ほとんどのエクステンションは [Composer](https://getcomposer.org/) のパッケージとして配布されていて、次の二つの簡単なステップをふめばインストールすることが出来ます。
 
 1. アプリケーションの `composer.json` ファイルを修正して、どのエクステンション (Composer パッケージ) をインストールしたいかを指定する。
 2. `composer install` コマンドを走らせて指定したエクステンションをインストールする。
 
 [Composer](https://getcomposer.org/) を持っていない場合は、それをインストールする必要があることに注意してください。
 
-既定では、Composer は [Packagist](https://packagist.org/) に登録されたパッケージをインストールします。Packagist は
-オープンソース Composer パッケージの最大のレポジトリであり、そこでエクステンションを探すことが出来ます。
-また、[自分自身のレポジトリを作成](https://getcomposer.org/doc/05-repositories.md#repository) して、それを使うように
-Composer を構成することも出来ます。これは、あなたがプライベートなエクステンションを開発していて、
-それを自分のプロジェクト間でのみ共有したい場合に役に立つ方法です。
+既定では、Composer は [Packagist](https://packagist.org/) に登録されたパッケージをインストールします。
+Packagist はオープンソース Composer パッケージの最大のレポジトリであり、そこでエクステンションを探すことが出来ます。
+また、[自分自身のレポジトリを作成](https://getcomposer.org/doc/05-repositories.md#repository) して、それを使うように Composer を構成することも出来ます。
+これは、あなたがプライベートなエクステンションを開発していて、それを自分のプロジェクト間でのみ共有したい場合に役に立つ方法です。
 
-Composer によってインストールされるエクステンションは `BasePath/vendor` ディレクトリに保存されます。ここで `BasePath`
-は、アプリケーションの [ベースパス](structure-applications.md#basePath) を指します。Composer は依存関係を管理するものですから、
-パッケージをインストールするときには、それが依存している全てのパッケージをも同時にインストールします。
+Composer によってインストールされるエクステンションは `BasePath/vendor` ディレクトリに保存されます。
+ここで `BasePath` は、アプリケーションの [ベースパス](structure-applications.md#basePath) を指します。
+Composer は依存関係を管理するものですから、あるパッケージをインストールするときには、それが依存する全てのパッケージも同時にインストールします。
 
-例えば、`yiisoft/yii2-imagine` エクステンションをインストールするためには、あなたの `composer.json` を次のように修正します:
+例えば、`yiisoft/yii2-imagine` エクステンションをインストールするためには、あなたの `composer.json` を次のように修正します。
 
 ```json
 {
@@ -44,8 +42,8 @@ Composer 縺ｫ繧医▲縺ｦ繧､繝ｳ繧ｹ繝医繝ｫ縺輔ｌ繧九お繧ｯ繧ｹ繝Φ繧ｷ繝ｧ繝ｳ縺ｯ `Bas
 }
 ```
 
-インストール完了後には、`BasePath/vendor` の下に `yiisoft/yii2-imagine` ディレクトリが作られている筈です。それと同時に、
-`imagine/imagine` という別のディレクトリも作られて、依存するパッケージがそこにインストールされている筈です。
+インストール完了後には、`BasePath/vendor` の下に `yiisoft/yii2-imagine` ディレクトリが作られている筈です。
+それと同時に、`imagine/imagine` という別のディレクトリも作られて、依存するパッケージがそこにインストールされている筈です。
 
 > Info|情報: `yiisoft/yii2-imagine` は Yii 開発チームによって開発され保守されるコアエクステンションの一つです。
   全てのコアエクステンションは [Packagist](https://packagist.org/) でホストされ、`yiisoft/yii2-xyz` のように名付けられます。
@@ -53,7 +51,7 @@ Composer 縺ｫ繧医▲縺ｦ繧､繝ｳ繧ｹ繝医繝ｫ縺輔ｌ繧九お繧ｯ繧ｹ繝Φ繧ｷ繝ｧ繝ｳ縺ｯ `Bas
 
 これであなたはインストールされたエクステンションをあなたのアプリケーションの一部であるかのように使うことが出来ます。
 次の例は、`yiisoft/yii2-imagine` エクステンションによって提供される `yii\imagine\Image` クラスをどのようにして使うことが
-出来るかを示すものです:
+出来るかを示すものです。
 
 ```php
 use Yii;
@@ -70,17 +68,18 @@ Image::thumbnail('@webroot/img/test-image.jpg', 120, 120)
 ### エクステンションを手作業でインストールする <a name="installing-extensions-manually"></a>
 
 あまり無いことですが、いくつかまたは全てのエクステンションを Composer に頼らずに手作業でインストールしたい場合があるかもしれません。
-そうするためには、次のようにしなければなりません:
+そうするためには、次のようにしなければなりません。
 
 1. エクステンションのアーカイブファイルをダウンロードして、`vendor` ディレクトリに解凍する。
 2. もし有れば、エクステンションによって提供されているクラスオートローダをインストールする。
 3. 指示に従って、依存するエクステンションを全てダウンロードしインストールする。
 
-エクステンションがクラスオートローダを持っていなくても、[PSR-4 標準](http://www.php-fig.org/psr/psr-4/) に従っている場合は、
-Yii によって提供されているクラスオートローダを使ってエクステンションのクラスをオートロードすることが出来ます。必要なことは、
-エクステンションのルートディレクトリのための [ルートエイリアス](concept-aliases.md#defining-aliases) を宣言することだけです。
-例えば、エクステンションを `vendor/mycompany/myext` というディレクトリにインストールしたと仮定します。そして、エクステンションの
-クラスは `myext` 名前空間の下にあるとします。その場合、アプリケーションのコンフィギュレーションに下記のコードを含めれば良いのです:
+エクステンションがクラスオートローダを持っていなくても、[PSR-4 標準](http://www.php-fig.org/psr/psr-4/)
+に従っている場合は、Yii によって提供されているクラスオートローダを使ってエクステンションのクラスをオートロードすることが出来ます。
+必要なことは、エクステンションのルートディレクトリのための [ルートエイリアス](concept-aliases.md#defining-aliases) を宣言することだけです。
+例えば、エクステンションを `vendor/mycompany/myext` というディレクトリにインストールしたと仮定します。
+そして、エクステンションのクラスは `myext` 名前空間の下にあるとします。
+その場合、アプリケーションのコンフィギュレーションに下記のコードを含めれば良いのです。
 
 ```php
 [
@@ -94,26 +93,27 @@ Yii 縺ｫ繧医▲縺ｦ謠蝉ｾ帙＆繧後※縺ｋ繧ｯ繝ｩ繧ｹ繧ｪ繝ｼ繝医Ο繝ｼ繝繧剃ｽｿ縺｣縺ｦ繧ｨ
 ## エクステンションを作成する <a name="creating-extensions"></a>
 
 あなたの優れたコードを他の人々と共有する必要があると感じたときは、エクステンションを作成することを考慮するのが良いでしょう。
-エクステンションは、ヘルパークラス、ウィジェット、モジュールなど、どのようなコードでも含むことが出来ます。
+エクステンションは、ヘルパクラス、ウィジェット、モジュールなど、どのようなコードでも含むことが出来ます。
 
-エクステンションは、[Composer パッケージ](https://getcomposer.org/) の形式で作成することが推奨されます。そうすれば、
-直前の項で説明したように、いっそう容易に他のユーザによってインストールされ、使用されることが出来ます。
+エクステンションは、[Composer パッケージ](https://getcomposer.org/) の形式で作成することが推奨されます。
+そうすれば、直前の項で説明したように、いっそう容易に他のユーザによってインストールされ、使用されることが出来ます。
 
 以下は、エクステンションを Composer のパッケージとして作成するために踏む基本的なステップです。
 
-1. エクステンションのためのプロジェクトを作成して、[github.com](https://github.com) などの VCS レポジトリ上でホストする。
+1. エクステンションのためのプロジェクトを作成して、[github.com](https://github.com) などの VCS レポジトリ上でホストします。
    エクステンションに関する開発と保守の作業はこのレポジトリ上でなされなければならない。
-2. プロジェクトのルートディレクトリに、Composer によって要求される `composer.json` という名前のファイルを作成する。
-   更なる詳細については、次の項を参照。
-3. エクステンションを [Packagist](https://packagist.org/) などの Composer レポジトリに登録する。そうすると、他のユーザが
-   エクステンションを見つけて Composer を使ってインストールすることが出来るようになる。
+2. プロジェクトのルートディレクトリに、Composer によって要求される `composer.json` という名前のファイルを作成します。
+   詳細については、次の項を参照してください。
+3. エクステンションを [Packagist](https://packagist.org/) などの Composer レポジトリに登録します。
+   そうすると、他のユーザがエクステンションを見つけて Composer を使ってインストールすることが出来るようになります。
 
 
 ### `composer.json` <a name="composer-json"></a>
 
-全ての Composer パッケージは、ルートディレクトリに `composer.json` というファイルを持たなければなりません。このファイルは
-パッケージに関するメタデータを含むものです。このファイルに関する完全な仕様は [Composer Manual](https://getcomposer.org/doc/01-basic-usage.md#composer-json-project-setup)
-に記載されています。次の例は、`yiisoft/yii2-imagine` エクステンションのための `composer.json` ファイルを示すものです:
+全ての Composer パッケージは、ルートディレクトリに `composer.json` というファイルを持たなければなりません。
+このファイルはパッケージに関するメタデータを含むものです。
+このファイルに関する完全な仕様は [Composer Manual](https://getcomposer.org/doc/01-basic-usage.md#composer-json-project-setup) に記載されています。
+次の例は、`yiisoft/yii2-imagine` エクステンションのための `composer.json` ファイルを示すものです。
 
 ```json
 {
@@ -159,8 +159,8 @@ Yii 縺ｫ繧医▲縺ｦ謠蝉ｾ帙＆繧後※縺ｋ繧ｯ繝ｩ繧ｹ繧ｪ繝ｼ繝医Ο繝ｼ繝繧剃ｽｿ縺｣縺ｦ繧ｨ
 #### パッケージ名 <a name="package-name"></a>
 
 全ての Composer パッケージは、他の全てパッケージに対して唯一のものとして特定できるような名前を持たなければなりません。
-パッケージ名の形式は `vendorName/projectName` です。例えば、`yiisoft/yii2-imagine` というパッケージ名の中では、
-ベンダー名とプロジェクト名は、それぞれ、`yiisoft` と `yii2-imagine` です。
+パッケージ名の形式は `vendorName/projectName` です。
+例えば、`yiisoft/yii2-imagine` というパッケージ名の中では、ベンダー名とプロジェクト名は、それぞれ、`yiisoft` と `yii2-imagine` です。
 
 ベンダー名として `yiisoft` を使ってはいけません。これは Yii のコアコードに使うために予約されています。
 
@@ -170,27 +170,24 @@ Yii 縺ｫ繧医▲縺ｦ謠蝉ｾ帙＆繧後※縺ｋ繧ｯ繝ｩ繧ｹ繧ｪ繝ｼ繝医Ο繝ｼ繝繧剃ｽｿ縺｣縺ｦ繧ｨ
 
 #### パッケージタイプ <a name="package-type"></a>
 
-パッケージがインストールされたときに Yii のエクステンションとして認識されるように、エクステンションのパッケージタイプを
-`yii2-extension` と指定することは重要なことです。
+パッケージがインストールされたときに Yii のエクステンションとして認識されるように、エクステンションのパッケージタイプを `yii2-extension` と指定することは重要なことです。
 
-ユーザが `composer install` を走らせてエクステンションをインストールすると、`vendor/yiisoft/extensions.php` というファイルが
-自動的に更新されて、新しいエクステンションに関する情報を含むようになります。このファイルから、Yii のアプリケーションは
-どんなエクステンションがインストールされているかを知ることが出来ます (その情報には、[[yii\base\Application::extensions]]
-を通じてアクセス出来ます)。
+ユーザが `composer install` を走らせてエクステンションをインストールすると、`vendor/yiisoft/extensions.php` というファイルが自動的に更新されて、新しいエクステンションに関する情報を含むようになります。
+このファイルから、Yii のアプリケーションはどんなエクステンションがインストールされているかを知ることが出来ます
+(その情報には、[[yii\base\Application::extensions]] を通じてアクセス出来ます)。
 
 
 #### 依存パッケージ <a name="dependencies"></a>
 
-あなたのエクステンションは Yii に依存します (当然ですね)。ですから、`composer.json` の `require` エントリのリストに
-それ (`yiisoft/yii2`) を挙げなければなりません。あなたのエクステンションがその他のエクステンションやサードパーティの
-ライブラリに依存する場合は、それらもリストに挙げなければなりません。それぞれの依存パッケージについて、適切なバージョン制約
-(例えば `1.*` や `@stable`) を指定することも忘れてはなりません。あなたのエクステンションを安定バージョンとしてリリースする場合は
-安定した依存パッケージを使ってください。
+あなたのエクステンションは Yii に依存します (当然ですね)。
+ですから、`composer.json` の `require` エントリのリストにそれ (`yiisoft/yii2`) を挙げなければなりません。
+あなたのエクステンションがその他のエクステンションやサードパーティのライブラリに依存する場合は、それらもリストに挙げなければなりません。
+それぞれの依存パッケージについて、適切なバージョン制約 (例えば `1.*` や `@stable`) を指定することも忘れてはなりません。
+あなたのエクステンションを安定バージョンとしてリリースする場合は、安定した依存パッケージを使ってください。
 
-たいていの JavaScript/CSS パッケージは、Composer ではなく、[Bower](http://bower.io/) および/または [NPM](https://www.npmjs.org/)
-を使って管理されています。Yii は [Composer アセットプラグイン](https://github.com/francoispluchino/composer-asset-plugin)
-を使って、この種のパッケージを Composer によって管理することを可能にしています。あなたのエクステンションが Bower パッケージに
-依存している場合でも、次のように、`composer.json` に依存パッケージをリストアップすることが簡単に出来ます:
+たいていの JavaScript/CSS パッケージは、Composer ではなく、[Bower](http://bower.io/) および/または [NPM](https://www.npmjs.org/) を使って管理されています。
+Yii は [Composer アセットプラグイン](https://github.com/francoispluchino/composer-asset-plugin) を使って、この種のパッケージを Composer によって管理することを可能にしています。
+あなたのエクステンションが Bower パッケージに依存している場合でも、次のように、`composer.json` に依存パッケージをリストアップすることが簡単に出来ます。
 
 ```json
 {
@@ -201,19 +198,18 @@ Yii 縺ｫ繧医▲縺ｦ謠蝉ｾ帙＆繧後※縺ｋ繧ｯ繝ｩ繧ｹ繧ｪ繝ｼ繝医Ο繝ｼ繝繧剃ｽｿ縺｣縺ｦ繧ｨ
 }
 ```
 
-上記のコードは、エクステンションが `jquery` Bower パッケージに依存することを述べています。一般に、`composer.json` の中で
-Bower パッケージを指すためには `bower-asset/PackageName` を使うことが出来ます。そして、NPM パッケージを指すためには
-`npm-asset/PackageName` を使うことが出来ます。Composer が Bower または NPM のパッケージをインストールする場合は、既定では、
-それぞれ、`@vendor/bower/PackageName` および `@vendor/npm/Packages` というディレクトリの下にパッケージの内容がインストールされます。
+上記のコードは、エクステンションが `jquery` Bower パッケージに依存することを述べています。
+一般に、`composer.json` の中でBower パッケージを指すためには `bower-asset/PackageName` を使うことが出来ます。
+そして、NPM パッケージを指すためには `npm-asset/PackageName` を使うことが出来ます。
+Composer が Bower または NPM のパッケージをインストールする場合は、既定では、それぞれ、`@vendor/bower/PackageName` および `@vendor/npm/Packages` というディレクトリの下にパッケージの内容がインストールされます。
 この二つのディレクトリは、`@bower/PackageName` および `@npm/PackageName` という短いエイリアスを使って参照することも可能です。
 
-アセット管理に関する更なる詳細については、[アセット](structure-assets.md#bower-npm-assets) の節を参照してください。
+アセット管理に関する詳細については、[アセット](structure-assets.md#bower-npm-assets) の節を参照してください。
 
 
 #### クラスのオートロード <a name="class-autoloading"></a>
 
-エクステンションのクラスが Yii のクラスオートローダまたは Composer のクラスオートローダによってオートロードされるように、
-下記に示すように、`composer.json` ファイルの `autoload` エントリを指定しなければなりません:
+エクステンションのクラスが Yii のクラスオートローダまたは Composer のクラスオートローダによってオートロードされるように、下記に示すように、`composer.json` ファイルの `autoload` エントリを指定しなければなりません。
 
 ```json
 {
@@ -229,8 +225,7 @@ Bower 繝代ャ繧ｱ繝ｼ繧ｸ繧呈欠縺吶◆繧√↓縺ｯ `bower-asset/PackageName` 繧剃ｽｿ縺
 
 一つまたは複数のルート名前空間と、それに対応するファイルパスをリストに挙げることが出来ます。
 
-エクステンションがアプリケーションにインストールされると、Yii は列挙されたルート名前空間の一つ一つに対して、
-名前空間に対応するディレクトリを指す [エイリアス](concept-aliases.md#extension-aliases) を作成します。
+エクステンションがアプリケーションにインストールされると、Yii は列挙されたルート名前空間の一つ一つに対して、名前空間に対応するディレクトリを指す [エイリアス](concept-aliases.md#extension-aliases) を作成します。
 例えば、上記の `autoload` の宣言は、`@yii/imagine` という名前のエイリアスに対応することになります。
 
 
@@ -242,23 +237,21 @@ Bower 繝代ャ繧ｱ繝ｼ繧ｸ繧呈欠縺吶◆繧√↓縺ｯ `bower-asset/PackageName` 繧剃ｽｿ縺
 
 #### 名前空間 <a name="namespaces"></a>
 
-名前の衝突を避けて、エクステンションの中のクラスをオートロード可能にするために、名前空間を使うべきであり、
-エクステンションの中のクラスに [PSR-4 標準](http://www.php-fig.org/psr/psr-4/) または
-[PSR-0 標準](http://www.php-fig.org/psr/psr-0/) に従った名前を付けるべきです。
+名前の衝突を避けて、エクステンションの中のクラスをオートロード可能にするために、名前空間を使うべきであり、エクステンションの中のクラスに
+[PSR-4 標準](http://www.php-fig.org/psr/psr-4/) または [PSR-0 標準](http://www.php-fig.org/psr/psr-0/) に従った名前を付けるべきです。
 
-あなたのクラスの名前空間は `vendorName\extensionName` で始まるべきです。ここで `extensionName` は、`yii2-`
-という前置辞を含むべきでないことを除けば、パッケージ名におけるプロジェクト名と同じものです。例えば、`yiisoft/yii2-imagine`
-エクステンションでは、`yii\imagine` をエクステンションのクラスの名前空間として使っています。
+あなたのクラスの名前空間は `vendorName\extensionName` で始まるべきです。
+ここで `extensionName` は、`yii2-` という接頭辞を含むべきでないことを除けば、パッケージ名におけるプロジェクト名と同じものです。
+例えば、`yiisoft/yii2-imagine` エクステンションでは、`yii\imagine` をエクステンションのクラスの名前空間として使っています。
 
 `yii`、`yii2` または `yiisoft` をベンダー名として使ってはいけません。これらの名前は、Yii のコアコードに使うために予約されています。
 
 
 #### ブートストラップクラス <a name="bootstrapping-classes"></a>
 
-場合によっては、アプリケーションが [ブートストラップ](runtime-bootstrapping.md) の段階にある間に、エクステンションに何らかの
-コードを実行させたい場合があるでしょう。例えば、エクステンションをアプリケーションの `beginRequest` イベントに反応させて、
-何らかの環境設定を調整したいことがあります。エクステンションのユーザに対して、エクステンションの中にあるイベントハンドラを
-`beginRequest` イベントに明示的にアタッチするように指示することも出来ますが、より良い方法は、それを自動的に行うことです。
+場合によっては、アプリケーションが [ブートストラップ](runtime-bootstrapping.md) の段階にある間に、エクステンションに何らかのコードを実行させたい場合があるでしょう。
+例えば、エクステンションをアプリケーションの `beginRequest` イベントに反応させて、何らかの環境設定を調整したいことがあります。
+エクステンションのユーザに対して、エクステンションの中にあるイベントハンドラを `beginRequest` イベントに明示的にアタッチするように指示することも出来ますが、より良い方法は、それを自動的に行うことです。
 
 この目的を達するためには、[[yii\base\BootstrapInterface]] を実装する、いわゆる *ブートストラップクラス* を作成します。
 例えば、
@@ -292,18 +285,17 @@ class MyBootstrapClass implements BootstrapInterface
 }
 ```
 
-このエクステンションがアプリケーションにインストールされると、すべてのリクエストのブートストラップの過程において、毎回、
-Yii が自動的にブートストラップクラスのインスタンスを作成し、その [[yii\base\BootstrapInterface::bootstrap()|bootstrap()]]
-メソッドを呼びます。
+このエクステンションがアプリケーションにインストールされると、すべてのリクエストのブートストラップの過程において、毎回、Yii
+が自動的にブートストラップクラスのインスタンスを作成し、その [[yii\base\BootstrapInterface::bootstrap()|bootstrap()]] メソッドを呼びます。
 
 
 #### データベースを扱う <a name="working-with-databases"></a>
 
-あなたのエクステンションはデータベースにアクセスする必要があるかも知れません。エクステンションを使うアプリケーションが
-常に `Yii::$db` を DB 接続として使用すると仮定してはいけません。その代りに、DB アクセスを必要とするクラスのために `db`
-プロパティを宣言すべきです。このプロパティによって、エクステンションのユーザは、エクステンションにどの DB 接続を使わせるかを
-カスタマイズすることが出来るようになります。その一例として、[[yii\caching\DbCache]] クラスを参照して、それがどのように
-`db` プロパティを宣言して使っているかを見ることが出来ます。
+あなたのエクステンションはデータベースにアクセスする必要があるかも知れません。
+エクステンションを使うアプリケーションが常に `Yii::$db` を DB 接続として使用すると仮定してはいけません。
+その代りに、DB アクセスを必要とするクラスのために `db` プロパティを宣言すべきです。
+このプロパティによって、エクステンションのユーザは、エクステンションにどの DB 接続を使わせるかをカスタマイズすることが出来るようになります。
+その一例として、[[yii\caching\DbCache]] クラスを参照して、それがどのように `db` プロパティを宣言して使っているかを見ることが出来ます。
 
 あなたのエクステンションが特定の DB テーブルを作成したり、DB スキーマを変更したりする必要がある場合は、次のようにするべきです。
 
@@ -314,78 +306,69 @@ Yii 縺瑚蜍慕噪縺ｫ繝悶繝医せ繝医Λ繝繧ｯ繝ｩ繧ｹ縺ｮ繧､繝ｳ繧ｹ繧ｿ繝ｳ繧ｹ繧剃ｽ懈
 
 #### アセットを使う <a name="using-assets"></a>
 
-あなたのエクステンションがウィジェットかモジュールである場合は、動作するために何らかの [assets](structure-assets.md)
-が必要である可能性が高いでしょう。例えば、モジュールは、画像、JavaScript、そして CSS を含むページをいくつか表示するでしょう。
-エクステンションのファイルは、全て、アプリケーションにインストールされるときに、ウェブからアクセス出来ない同じディレクトリ
-の下に配置されます。そのため、次のどちらかの方法を使って、アセットファイルをウェブから直接アクセス出来るようにしなければなりません。
+あなたのエクステンションがウィジェットかモジュールである場合は、動作するために何らかの [アセット](structure-assets.md) が必要である可能性が高いでしょう。
+例えば、モジュールは、画像、JavaScript、そして CSS を含むページをいくつか表示するでしょう。
+エクステンションのファイルは、全て、アプリケーションにインストールされるときに、ウェブからアクセス出来ない同じディレクトリの下に配置されます。
+そのため、次のどちらかの方法を使って、アセットファイルをウェブから直接アクセス出来るようにしなければなりません。
 
 - アセットファイルをウェブからアクセス出来る特定のフォルダに手作業でコピーするように、エクステンションのユーザにお願いする。
-- [アセットバンドル](structure-assets.md) を宣言し、アセット発行メカニズムに頼って、アセットバンドルにリスとされているファイルを
-  ウェブからアクセス出来るフォルダに自動的にコピーする。
+- [アセットバンドル](structure-assets.md) を宣言し、アセット発行メカニズムに頼って、アセットバンドルにリストされているファイルをウェブからアクセス出来るフォルダに自動的にコピーする。
 
 あなたのエクステンションが他の人々にとってより一層使いやすいものになるように、第二の方法をとることを推奨します。
-アセットの取り扱い一般に関する更なる詳細は [アセット](structure-assets.md) の節を参照してください。
+アセットの取り扱い一般に関する詳細は [アセット](structure-assets.md) の節を参照してください。
 
 
 #### 国際化と地域化 <a name="i18n-l10n"></a>
 
-あなたのエクステンションは、さまざまな言語をサポートするアプリケーションによって使われるかもしれません。従って、
-あなたのエクステンションがエンドユーザにコンテンツを表示するものである場合は、それを [国際化](tutorial-i18n.md)
-するように努めるべきです。具体的には、
+あなたのエクステンションは、さまざまな言語をサポートするアプリケーションによって使われるかもしれません。
+従って、あなたのエクステンションがエンドユーザにコンテンツを表示するものである場合は、それを [国際化](tutorial-i18n.md) するように努めるべきです。
+具体的には、
 
-- エクステンションがエンドユーザに向けたメッセージを表示する場合は、翻訳することが出来るようにメッセージを `Yii::t()`
-  で包むべきです。開発者に向けられたメッセージ (内部的な例外のメッセージなど) は翻訳される必要はありません。
+- エクステンションがエンドユーザに向けたメッセージを表示する場合は、翻訳することが出来るようにメッセージを `Yii::t()` で包むべきです。
+  開発者に向けられたメッセージ (内部的な例外のメッセージなど) は翻訳される必要はありません。
 - エクステンションが数値や日付などを表示する場合は、[[yii\i18n\Formatter]] を適切な書式化の規則とともに使って書式設定すべきです。
 
-更なる詳細については、[国際化](tutorial-i18n.md) の節を参照してください。
+詳細については、[国際化](tutorial-i18n.md) の節を参照してください。
 
 
 #### テスト <a name="testing"></a>
 
-あなたは、あなたのエクステンションが他の人々に問題をもたらすことなく完璧に動作することを望むでしょう。この目的を達するためには、
-あなたのエクステンションを公開する前にテストすべきです。
+あなたは、あなたのエクステンションが他の人々に問題をもたらすことなく完璧に動作することを望むでしょう。
+この目的を達するためには、あなたのエクステンションを公開する前にテストすべきです。
 
 手作業のテストに頼るのではなく、あなたのエクステンションのコードをカバーするさまざまなテストケースを作成することが推奨されます。
-あなたのエクステンションの新しいバージョンを公開する前には、毎回、単にそれらのテストケースを走らせれば、全てが良い状態にあることを
-確認することが出来ます。Yii はテストのサポートを提供しており、それよって、ユニットテスト、機能テスト、承認テストを書くことが
-一層簡単に出来るようになっています。更なる詳細については、[テスト](test-overview.md) の節を参照してください。
+あなたのエクステンションの新しいバージョンを公開する前には、毎回、単にそれらのテストケースを走らせれば、全てが良い状態にあることを確認することが出来ます。
+Yii はテストのサポートを提供しており、それよって、ユニットテスト、機能テスト、承認テストを書くことが一層簡単に出来るようになっています。
+詳細については、[テスト](test-overview.md) の節を参照してください。
 
 
 #### バージョン管理 <a name="versioning"></a>
 
 エクステンションのリリースごとにバージョン番号 (例えば `1.0.1`) を付けるべきです。
-どのようなバージョン番号を付けるべきかを決定するときは、[セマンティックバージョニング](http://semver.org) 
-の慣行に従うことを推奨します。
+どのようなバージョン番号を付けるべきかを決定するときは、[セマンティックバージョニング](http://semver.org) の慣行に従うことを推奨します。
 
 
 #### リリース(公開) <a name="releasing"></a>
 
 他の人々にあなたのエクステンションを知ってもらうためには、それをリリース(公開)する必要があります。
 
-エクステンションをリリースするのが初めての場合は、[Packagist](https://packagist.org/) などの Composer レポジトリに
-エクステンションを登録するべきです。その後は、あなたがしなければならない仕事は、エクステンションの VCS レポジトリでリリースタグ
-(例えば `v1.0.1`) を作成して Composer レポジトリに新しいリリースについて通知するだけのことになります。そして、
-人々が新しいリリースを見出すことが出来るようになり、Composer レポジトリを通じてエクステンションをインストールしたり
-アップデートしたりするようになります。
+エクステンションをリリースするのが初めての場合は、[Packagist](https://packagist.org/) などの Composer レポジトリにエクステンションを登録するべきです。
+その後は、あなたがしなければならない仕事は、エクステンションの VCS レポジトリでリリースタグ (例えば `v1.0.1`) を作成することと、Composer レポジトリに新しいリリースについて通知するだけのことになります。
+そうすれば、人々が新しいリリースを見出すことが出来るようになり、Composer レポジトリを通じてエクステンションをインストールしたりアップデートしたりするようになります。
 
-エクステンションのリリースには、人々があなたのエクステンションについて知ったり、エクステンションを使ったりするのを助けるために、
-コードファイル以外に下記のものを含めることを考慮すべきです。
+エクステンションのリリースには、コードファイル以外に、人々があなたのエクステンションについて知ったり、エクステンションを使ったりするのを助けるために、下記のものを含めることを考慮すべきです。
 
-* パッケージのルートディレクトリに readme ファイル: あなたのエクステンションが何をするものか、そして、
-  どのようにインストールして使うものかを説明するものです。[Markdown](http://daringfireball.net/projects/markdown/)
-  形式で書いて、`readme.md` という名前にすることを推奨します。
+* パッケージのルートディレクトリに readme ファイル: あなたのエクステンションが何をするものか、そして、どのようにインストールして使うものかを説明するものです。
+  [Markdown](http://daringfireball.net/projects/markdown/) 形式で書いて、`readme.md` という名前にすることを推奨します。
 * パッケージのルートディレクトリに changelog ファイル: それぞれのリリースで何が変ったかを一覧表示するものです。
   このファイルは Markdown 形式で書いて `changelog.md` と名付けることが出来ます。
 * パッケージのルートディレクトリに upgrade ファイル: エクステンションの古いリリースからのアップグレード方法について説明するものです。
   このファイルは Markdown 形式で書いて `upgrade.md` と名付けることが出来ます。
-* チュートリアル、デモ、スクリーンショットなど: あなたのエクステンションが readme ファイルでは十分にカバーできないほど
-  多くの機能を提供するものである場合は、これらが必要になります。
+* チュートリアル、デモ、スクリーンショットなど: あなたのエクステンションが readme ファイルでは十分にカバーできないほど多くの機能を提供するものである場合は、これらが必要になります。
 * API ドキュメント: あなたのコードは、他の人々が読んで理解することがより一層容易に出来るように、十分な解説を含むべきです。
-  [Object のクラスファイル](https://github.com/yiisoft/yii2/blob/master/framework/base/Object.php) を参照すると、
-  コードに解説を加える方法を学ぶことが出来ます。
+  [Object のクラスファイル](https://github.com/yiisoft/yii2/blob/master/framework/base/Object.php) を参照すると、コードに解説を加える方法を学ぶことが出来ます。
 
-> Info|情報: コードのコメントを Markdown 形式で書くことが出来ます。`yiisoft/yii2-apidoc` エクステンションは、
-  コードのコメントに基づいて綺麗な API ドキュメントを生成するツールを提供しています。
+> Info|情報: コードのコメントを Markdown 形式で書くことが出来ます。`yiisoft/yii2-apidoc` エクステンションは、コードのコメントに基づいて綺麗な API ドキュメントを生成するツールを提供しています。
 
 > Info|情報: これは要求ではありませんが、あなたのエクステンションも一定のコーディングスタイルを守るのが良いと思います。
   [コアフレームワークコードスタイル](https://github.com/yiisoft/yii2/wiki/Core-framework-code-style) を参照してください。
@@ -394,8 +377,7 @@ Yii 縺瑚蜍慕噪縺ｫ繝悶繝医せ繝医Λ繝繧ｯ繝ｩ繧ｹ縺ｮ繧､繝ｳ繧ｹ繧ｿ繝ｳ繧ｹ繧剃ｽ懈
 ## コアエクステンション <a name="core-extensions"></a>
 
 Yii は下記のコアエクステンションを提供しています。これらは Yii 開発チームによって開発され保守されているものです。
-全て [Packagist](https://packagist.org/) に登録され、[エクステンションを使う](#using-extensions) の項で説明したように、
-簡単にインストールすることが出来ます。
+全て [Packagist](https://packagist.org/) に登録され、[エクステンションを使う](#using-extensions) の項で説明したように、簡単にインストールすることが出来ます。
 
 - [yiisoft/yii2-apidoc](https://github.com/yiisoft/yii2-apidoc):
   拡張可能で高性能な API ドキュメント生成機能を提供します。コアフレームワークの API ドキュメントを生成するためにも使われています。
@@ -406,30 +388,31 @@ Yii 縺ｯ荳玖ｨ倥繧ｳ繧｢繧ｨ繧ｯ繧ｹ繝Φ繧ｷ繝ｧ繝ｳ繧呈署萓帙＠縺ｦ縺∪縺吶ゅ％繧後
 - [yiisoft/yii2-codeception](https://github.com/yiisoft/yii2-codeception):
   [Codeception](http://codeception.com/) に基づくテストのサポートを提供します。
 - [yiisoft/yii2-debug](https://github.com/yiisoft/yii2-debug):
-  Yii アプリケーションのデバッグのサポートを提供します。このエクステンションが使われると、全てのページの末尾にデバッガツールバーが
-  表示されます。このエクステンションは、より詳細なデバッグ情報を表示する一連のスタンドアロンページも提供します。
+  Yii アプリケーションのデバッグのサポートを提供します。
+  このエクステンションが使われると、全てのページの末尾にデバッガツールバーが表示されます。
+  このエクステンションは、より詳細なデバッグ情報を表示する一連のスタンドアロンページも提供します。
 - [yiisoft/yii2-elasticsearch](https://github.com/yiisoft/yii2-elasticsearch):
-  [Elasticsearch](http://www.elasticsearch.org/) の使用に対するサポートを提供します。基本的なクエリ/サーチのサポートを
-  含むだけでなく、Elasticsearch にアクティブレコードを保存することを可能にする [アクティブレコード](db-active-record.md)
-  パターンをも実装しています。
+  [Elasticsearch](http://www.elasticsearch.org/) の使用に対するサポートを提供します。
+  基本的なクエリ/サーチのサポートを含むだけでなく、Elasticsearch にアクティブレコードを保存することを可能にする [アクティブレコード](db-active-record.md) パターンをも実装しています。
 - [yiisoft/yii2-faker](https://github.com/yiisoft/yii2-faker):
   ダミーデータを作る [Faker](https://github.com/fzaninotto/Faker) を使うためのサポートを提供します。
 - [yiisoft/yii2-gii](https://github.com/yiisoft/yii2-gii):
-  拡張性が非常に高いウェブベースのコードジェネレータを提供します。これを使って、モデル、フォーム、モジュール、CRUD
-  などを迅速に生成することが出来ます。
+  拡張性が非常に高いウェブベースのコードジェネレータを提供します。これを使って、モデル、フォーム、モジュール、CRUD などを迅速に生成することが出来ます。
 - [yiisoft/yii2-imagine](https://github.com/yiisoft/yii2-imagine):
   [Imagine](http://imagine.readthedocs.org/) に基づいて、使われることの多い画像操作機能を提供します。
 - [yiisoft/yii2-jui](https://github.com/yiisoft/yii2-jui):
   [JQuery UI](http://jqueryui.com/) のインタラクションとウィジェットをカプセル化した一連のウィジェットを提供します。
 - [yiisoft/yii2-mongodb](https://github.com/yiisoft/yii2-mongodb):
-  [MongoDB](http://www.mongodb.org/) の使用に対するサポートを提供します。基本的なクエリ、アクティブレコード、マイグレーション、
-  キャッシュ、コード生成などの機能を含みます。
+  [MongoDB](http://www.mongodb.org/) の使用に対するサポートを提供します。
+  基本的なクエリ、アクティブレコード、マイグレーション、キャッシュ、コード生成などの機能を含みます。
 - [yiisoft/yii2-redis](https://github.com/yiisoft/yii2-redis):
-  [redis](http://redis.io/) の使用に対するサポートを提供します。基本的なクエリ、アクティブレコード、キャッシュなどの機能を含みます。
+  [redis](http://redis.io/) の使用に対するサポートを提供します。
+  基本的なクエリ、アクティブレコード、キャッシュなどの機能を含みます。
 - [yiisoft/yii2-smarty](https://github.com/yiisoft/yii2-smarty):
   [Smarty](http://www.smarty.net/) に基づいたテンプレートエンジンを提供します。
 - [yiisoft/yii2-sphinx](https://github.com/yiisoft/yii2-sphinx):
-  [Sphinx](http://sphinxsearch.com) の使用に対するサポートを提供します。基本的なクエリ、アクティブレコード、コード生成などの機能を含みます。
+  [Sphinx](http://sphinxsearch.com) の使用に対するサポートを提供します。
+  基本的なクエリ、アクティブレコード、コード生成などの機能を含みます。
 - [yiisoft/yii2-swiftmailer](https://github.com/yiisoft/yii2-swiftmailer):
   [swiftmailer](http://swiftmailer.org/) に基づいたメール送信機能を提供します。
 - [yiisoft/yii2-twig](https://github.com/yiisoft/yii2-twig):

docs/guide-ja/structure-filters.md

@@ -5,16 +5,14 @@
 例えば、アクセスコントロールフィルタはアクションの前に走って、アクションが特定のエンドユーザだけにアクセスを許可するものであることを保証します。
 また、コンテンツ圧縮フィルタはアクションの後に走って、レスポンスのコンテンツをエンドユーザに送出する前に圧縮します。
 
-フィルタは、前フィルタ (アクションの *前* に適用されるフィルタのロジック) および/または 後フィルタ (アクションの *後*
-に適用されるフィルタ) から構成されます。
+フィルタは、前フィルタ (アクションの *前* に適用されるフィルタのロジック) および/または 後フィルタ (アクションの *後* に適用されるフィルタ) から構成されます。
 
 
 ## フィルタを使用する <a name="using-filters"></a>
 
-フィルタは、本質的には特別な種類の [ビヘイビア](concept-behaviors.md) です。したがって、フィルタを使うことは
-[ビヘイビアを使う](concept-behaviors.md#attaching-behaviors) ことと同じです。下記のように、
-[[yii\base\Controller::behaviors()|behaviors()]] メソッドをオーバーライドすることによって、コントローラの中で
-フィルタを宣言することが出来ます:
+フィルタは、本質的には特別な種類の [ビヘイビア](concept-behaviors.md) です。
+したがって、フィルタを使うことは [ビヘイビアを使う](concept-behaviors.md#attaching-behaviors) ことと同じです。
+下記のように、[[yii\base\Controller::behaviors()|behaviors()]] メソッドをオーバーライドすることによって、コントローラの中でフィルタを宣言することが出来ます。
 
 ```php
 public function behaviors()
@@ -33,19 +31,17 @@ public function behaviors()
 ```
 
 既定では、コントローラクラスの中で宣言されたフィルタは、そのコントローラの *全て* のアクションに適用されます。
-しかし、[[yii\base\ActionFilter::only|only]] プロパティを構成することによって、フィルタがどのアクションに適用されるべきかを
-明示的に指定することも出来ます。上記の例では、 `HttpCache` フィルタは、`index` と `view` のアクションに対してのみ適用されています。
+しかし、[[yii\base\ActionFilter::only|only]] プロパティを構成することによって、フィルタがどのアクションに適用されるべきかを明示的に指定することも出来ます。
+上記の例では、 `HttpCache` フィルタは、`index` と `view` のアクションに対してのみ適用されています。
 また、[[yii\base\ActionFilter::except|except]] プロパティを構成して、いくつかのアクションをフィルタされないように除外することも可能です。
 
-コントローラのほかに、[モジュール](structure-modules.md) または [アプリケーション](structure-applications.md)
-でもフィルタを宣言することが出来ます。
-そのようにした場合、[[yii\base\ActionFilter::only|only]] と [[yii\base\ActionFilter::except|except]] のプロパティを
-上で説明したように構成しない限り、そのフィルタは、モジュールまたはアプリケーションに属する *全て* のコントローラアクションに適用されます。
+コントローラのほかに、[モジュール](structure-modules.md) または [アプリケーション](structure-applications.md) でもフィルタを宣言することが出来ます。
+そのようにした場合、[[yii\base\ActionFilter::only|only]] と [[yii\base\ActionFilter::except|except]] のプロパティを上で説明したように構成しない限り、
+そのフィルタは、モジュールまたはアプリケーションに属する *全て* のコントローラアクションに適用されます。
 
-> Note|注意: モジュールやアプリケーションでフィルタを宣言する場合、[[yii\base\ActionFilter::only|only]] と
-  [[yii\base\ActionFilter::except|except]] のプロパティでは、アクション ID ではなく、[ルート](structure-controllers.md#routes)
-  を使うべきです。なぜなら、モジュールやアプリケーションのスコープでは、アクション ID だけでは完全にアクションを指定することが
-  出来ないからです。
+> Note|注意: モジュールやアプリケーションでフィルタを宣言する場合、[[yii\base\ActionFilter::only|only]] と [[yii\base\ActionFilter::except|except]]
+のプロパティでは、アクション ID ではなく、[ルート](structure-controllers.md#routes) を使うべきです。
+なぜなら、モジュールやアプリケーションのスコープでは、アクション ID だけでは完全にアクションを指定することが出来ないからです。
 
 一つのアクションに複数のフィルタが構成されている場合、フィルタは下記で説明されている規則に従って適用されます。
 
@@ -63,13 +59,13 @@ public function behaviors()
 
 ## フィルタを作成する <a name="creating-filters"></a>
 
-新しいアクションフィルタを作成するためには、[[yii\base\ActionFilter]] を拡張して、
-[[yii\base\ActionFilter::beforeAction()|beforeAction()]] および/または [[yii\base\ActionFilter::afterAction()|afterAction()]]
-メソッドをオーバーライドします。前者はアクションが走る前に実行され、後者は走った後に実行されます。
+新しいアクションフィルタを作成するためには、[[yii\base\ActionFilter]] を拡張して、[[yii\base\ActionFilter::beforeAction()|beforeAction()]]
+および/または [[yii\base\ActionFilter::afterAction()|afterAction()]] メソッドをオーバーライドします。
+前者はアクションが走る前に実行され、後者は走った後に実行されます。
 [[yii\base\ActionFilter::beforeAction()|beforeAction()]] の返り値が、アクションが実行されるべきか否かを決定します。
 返り値が false である場合、このフィルタの後に続くフィルタはスキップされ、アクションは実行を中止されます。
 
-次の例は、アクションの実行時間をログに記録するフィルタを示すものです:
+次の例は、アクションの実行時間をログに記録するフィルタを示すものです。
 
 ```php
 namespace app\components;
@@ -99,14 +95,15 @@ class ActionTimeFilter extends ActionFilter
 
 ## コアのフィルタ <a name="core-filters"></a>
 
-Yii はよく使われる一連のフィルタを提供しており、それらは、主として `yii\filters` 名前空間の下にあります。以下では、
-それらのフィルタを簡単に紹介します。
+Yii はよく使われる一連のフィルタを提供しており、それらは、主として `yii\filters` 名前空間の下にあります。
+以下では、それらのフィルタを簡単に紹介します。
 
 
 ### [[yii\filters\AccessControl|AccessControl]] <a name="access-control"></a>
 
 AccessControl は、一組の [[yii\filters\AccessControl::rules|規則]] に基づいて、シンプルなアクセスコントロールを提供するものです。
-具体的に言うと、アクションが実行される前に、AccessControl はリストされた規則を調べて、現在のコンテキスト変数 (例えば、ユーザの IP アドレスや、ユーザのログイン状態など) に最初に合致するものを見つけます。
+具体的に言うと、アクションが実行される前に、AccessControl はリストされた規則を調べて、現在のコンテキスト変数
+(例えば、ユーザの IP アドレスや、ユーザのログイン状態など) に最初に合致するものを見つけます。
 そして、合致した規則によって、リクエストされたアクションの実行を許可するか拒否するかを決定します。
 合致する規則がなかった場合は、アクセスは拒否されます。
 
@@ -135,7 +132,7 @@ public function behaviors()
 }
 ```
 
-アクセスコントロール一般について、更なる詳細は [権限](security-authorization.md) の節を参照してください。
+アクセスコントロール一般についての詳細は [権限](security-authorization.md) の節を参照してください。
 
 
 ### 認証メソッドフィルタ <a name="auth-method-filters"></a>
@@ -145,8 +142,8 @@ public function behaviors()
 これらのフィルタクラスはすべて `yii\filters\auth` 名前空間の下にあります。
 
 次の例は、[[yii\filters\auth\HttpBasicAuth]] の使い方を示すもので、HTTP Basic 認証に基づくアクセストークンを使ってユーザを認証しています。
-これを動作させるためには、あなたの [[yii\web\User::identityClass|ユーザアイデンティティクラス]] が
-[[yii\web\IdentityInterface::findIdentityByAccessToken()|findIdentityByAccessToken()]] 
+これを動作させるためには、あなたの [[yii\web\User::identityClass|ユーザアイデンティティクラス]]
+が [[yii\web\IdentityInterface::findIdentityByAccessToken()|findIdentityByAccessToken()]] 
 メソッドを実装していなければならないことに注意してください。
 
 ```php
@@ -162,18 +159,16 @@ public function behaviors()
 }
 ```
 
-認証メソッドフィルタは RESTful API を実装するときに使われるのが通例です。詳細については、
-RESTful の [認証](rest-authentication.md) の節を参照してください。
+認証メソッドフィルタは RESTful API を実装するときに使われるのが通例です。
+詳細については、RESTful の [認証](rest-authentication.md) の節を参照してください。
 
 
 ### [[yii\filters\ContentNegotiator|ContentNegotiator]] <a name="content-negotiator"></a>
 
 ContentNegotiator は、レスポンス形式のネゴシエーションとアプリケーション言語のネゴシエーションをサポートします。
-このフィルタは `GET` パラメータと `Accept` HTTP ヘッダを調べることによって、レスポンス形式 および/または
-言語を決定しようとします。
+このフィルタは `GET` パラメータと `Accept` HTTP ヘッダを調べることによって、レスポンス形式 および/または 言語を決定しようとします。
 
-次の例では、ContentNegotiator はレスポンス形式として JSON と XML をサポートし、(合衆国の)英語とドイツ語を
-言語としてサポートするように構成されています。
+次の例では、ContentNegotiator はレスポンス形式として JSON と XML をサポートし、(合衆国の)英語とドイツ語を言語としてサポートするように構成されています。
 
 ```php
 use yii\filters\ContentNegotiator;
@@ -198,9 +193,9 @@ public function behaviors()
 ```
 
 レスポンス形式と言語は [アプリケーションのライフサイクル](structure-applications.md#application-lifecycle)
-のもっと早い段階で決定される必要があることがよくあります。このため、ContentNegotiator はフィルタの他に、
-[ブートストラップコンポーネント](structure-applications.md#bootstrap) としても使うことができるように設計されています。
-例えば、次のように、ContentNegotiator を [アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で構成することが出来ます。
+のもっと早い段階で決定される必要があることがよくあります。
+このため、ContentNegotiator はフィルタの他に、[ブートストラップコンポーネント](structure-applications.md#bootstrap) としても使うことができるように設計されています。
+例えば、次のように、ContentNegotiator を [アプリケーションの構成情報](structure-applications.md#application-configurations) の中で構成することが出来ます。
 
 ```php
 use yii\filters\ContentNegotiator;
@@ -250,15 +245,14 @@ public function behaviors()
 }
 ```
 
-HttpCache に関する更なる詳細は [HTTP キャッシュ](caching-http.md) の節を参照してください。
+HttpCache に関する詳細は [HTTP キャッシュ](caching-http.md) の節を参照してください。
 
 
 ### [[yii\filters\PageCache|PageCache]] <a name="page-cache"></a>
 
-PageCache はサーバサイドにおけるページ全体のキャッシュを実装するものです。次の例では、PageCache が
-`index` アクションに適用されて、最大 60 秒間、または、`post` テーブルのエントリ数が変化するまでの間、
-ページ全体をキャッシュしています。さらに、このページキャッシュは、選択されたアプリケーションの言語に従って、
-違うバージョンのページを保存するようにしています。
+PageCache はサーバサイドにおけるページ全体のキャッシュを実装するものです。
+次の例では、PageCache が `index` アクションに適用されて、最大 60 秒間、または、`post` テーブルのエントリ数が変化するまでの間、ページ全体をキャッシュしています。
+さらに、このページキャッシュは、選択されたアプリケーションの言語に従って、違うバージョンのページを保存するようにしています。
 
 ```php
 use yii\filters\PageCache;
@@ -283,7 +277,7 @@ public function behaviors()
 }
 ```
 
-PageCache の使用に関する更なる詳細は [ページキャッシュ](caching-page.md) の節を参照してください。
+PageCache の使用に関する詳細は [ページキャッシュ](caching-page.md) の節を参照してください。
 
 
 ### [[yii\filters\RateLimiter|RateLimiter]] <a name="rate-limiter"></a>
@@ -296,8 +290,8 @@ RateLimiter は [リーキーバケットアルゴリズム](http://ja.wikipedia
 ### [[yii\filters\VerbFilter|VerbFilter]] <a name="verb-filter"></a>
 
 VerbFilter は、HTTP リクエストメソッドがリクエストされたアクションによって許可されているかどうかをチェックするものです。
-許可されていない場合は、HTTP 405 例外を投げます。次の例では、VerbFilter が宣言されて、
-CRUD アクションに対して許可されるメソッドの典型的なセットを規定しています。
+許可されていない場合は、HTTP 405 例外を投げます。
+次の例では、VerbFilter が宣言されて、CRUD アクションに対して許可されるメソッドの典型的なセットを規定しています。
 
 ```php
 use yii\filters\VerbFilter;
@@ -321,12 +315,10 @@ public function behaviors()
 
 ### [[yii\filters\Cors|Cors]] <a name="cors"></a>
 
-クロスオリジンリソース共有 [CORS](https://developer.mozilla.org/ja/docs/HTTP_access_control) とは、
-ウェブページにおいて、さまざまなリソース (例えば、フォントや JavaScript など) を、
-それを生成するドメイン以外のドメインからリクエストすることを可能にするメカニズムです。
+クロスオリジンリソース共有 [CORS](https://developer.mozilla.org/ja/docs/HTTP_access_control) とは、ウェブページにおいて、さまざまなリソース
+(例えば、フォントや JavaScript など) を、それを生成するドメイン以外のドメインからリクエストすることを可能にするメカニズムです。
 特に言えば、JavaScript の AJAX 呼出しが使用することが出来る XMLHttpRequest メカニズムです。
-このような「クロスドメイン｣のリクエストは、このメカニズムに拠らなければ、
-同一生成元のセキュリティポリシーによって、ウェブブラウザから禁止されるはずのものです。
+このような「クロスドメイン｣のリクエストは、このメカニズムに拠らなければ、同一生成元のセキュリティポリシーによって、ウェブブラウザから禁止されるはずのものです。
 CORS は、ブラウザとサーバが交信して、クロスドメインのリクエストを許可するか否かを決定する方法を定義するものです。
 
 [[yii\filters\Cors|Cors フィルタ]] は、CORS ヘッダが常に送信されることを保証するために、Authentication / Authorization のフィルタよりも前に定義されなければなりません。
@@ -347,14 +339,17 @@ public function behaviors()
 
 Cors のフィルタリングは `cors` プロパティを使ってチューニングすることが出来ます。
 
-* `cors['Origin']`: 許可される生成元を定義するのに使われる配列。`['*']` (すべて) または `['http://www.myserver.net'、'http://www.myotherserver.com']` などが設定可能。デフォルトは `['*']`。
-* `cors['Access-Control-Request-Method']`: 許可されるメソッドの配列。たとえば、`['GET', 'OPTIONS', 'HEAD']`。デフォルトは `['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'HEAD', 'OPTIONS']`。
-* `cors['Access-Control-Request-Headers']`: 許可されるヘッダの配列。全てのヘッダを意味する `['*']` または特定のヘッダを示す `['X-Request-With']` が設定可能。デフォルトは `['*']`。
+* `cors['Origin']`: 許可される生成元を定義するのに使われる配列。
+  `['*']` (すべて) または `['http://www.myserver.net'、'http://www.myotherserver.com']` などが設定可能。デフォルトは `['*']`。
+* `cors['Access-Control-Request-Method']`: 許可されるメソッドの配列。
+  たとえば、`['GET', 'OPTIONS', 'HEAD']`。デフォルトは `['GET', 'POST', 'PUT', 'PATCH', 'DELETE', 'HEAD', 'OPTIONS']`。
+* `cors['Access-Control-Request-Headers']`: 許可されるヘッダの配列。
+  全てのヘッダを意味する `['*']` または特定のヘッダを示す `['X-Request-With']` が設定可能。デフォルトは `['*']`。
 * `cors['Access-Control-Allow-Credentials']`: 現在のリクエストをクレデンシャルを使ってすることが出来るかどうかを定義。
-`true`、`false` または `null` (設定なし) が設定可能。デフォルトは `null`。
+  `true`、`false` または `null` (設定なし) が設定可能。デフォルトは `null`。
 * `cors['Access-Control-Max-Age']`: プリフライトリクエストの寿命を定義。デフォルトは `86400`。
 
-次の例は、生成元 `http://www.myserver.net` に対する `GET`、`HEAD` および `OPTIONS` のメソッドによる CORS を許可するものです:
+次の例は、生成元 `http://www.myserver.net` に対する `GET`、`HEAD` および `OPTIONS` のメソッドによる CORS を許可するものです。
 
 ```php
 use yii\filters\Cors;
@@ -375,7 +370,7 @@ public function behaviors()
 ```
 
 デフォルトのパラメータをアクション単位でオーバーライドして CORS ヘッダをチューニングすることも可能です。
-例えば、`login` アクションに `Access-Control-Allow-Credentials` を追加することは、次のようにすれば出来ます:
+例えば、`login` アクションに `Access-Control-Allow-Credentials` を追加することは、次のようにすれば出来ます。
 
 ```php
 use yii\filters\Cors;

docs/guide-ja/structure-models.md

@@ -7,7 +7,7 @@
 モデルクラスは、[[yii\base\Model]] またはその子クラスを拡張することによって作成することが出来ます。
 基底クラス [[yii\base\Model]] は数多くの有用な機能をサポートしています。
 
-* [属性](#attributes): 業務のデータを表現し、通常のオブジェクトプロパティや配列要素のようにアクセス出来る。
+* [属性](#attributes): 業務のデータを表現する。通常のオブジェクトプロパティや配列要素のようにしてアクセス出来る。
 * [属性のラベル](#attribute-labels): 属性の表示ラベルを規定する。
 * [一括代入](#massive-assignment): 一回のステップで複数の属性にデータを投入することをサポートしている。
 * [検証規則](#validation-rules): 宣言された検証規則に基いて入力されたデータを確認する。
@@ -25,7 +25,7 @@
 
 モデルは業務のデータを *属性* の形式で表現します。
 全ての属性はそれぞれパブリックにアクセス可能なモデルのプロパティと同様なものです。
-メソッド [[yii\base\Model::attributes()]] が、モデルがどのような属性を持つかを規定します。
+[[yii\base\Model::attributes()]] メソッドが、モデルがどのような属性を持つかを規定します。
 
 属性に対しては、通常のオブジェクトプロパティにアクセスするのと同じようにして、アクセスすることが出来ます。
 
@@ -57,7 +57,7 @@ foreach ($model as $name => $value) {
 ### 属性を定義する<a name="defining-attributes"></a>
 
 あなたのモデルが [[yii\base\Model]] を直接に拡張するものである場合、既定によって、全ての *static でない public な* メンバ変数は属性となります。
-例えば、次に示す `ContactForm` モデルは4つの属性を持ちます: すなわち、`name`、`email`、`subject`、そして、`body` です。
+例えば、次に示す `ContactForm` モデルは4つの属性、すなわち、`name`、`email`、`subject`、そして、`body` を持ちます。
 この `ContactForm` モデルは、HTML フォームから受け取る入力データを表現するために使われます。
 
 ```php
@@ -77,9 +77,9 @@ class ContactForm extends Model
 
 [[yii\base\Model::attributes()]] をオーバーライドして、属性を異なる方法で定義することが出来ます。
 このメソッドはモデルの中の属性の名前を返さなくてはなりません。
-例えば、[[yii\db\ActiveRecord]] はそのようにして、関連付けられたデータベーステーブルのコラム名を属性の名前として返しています。
-これと同時に `__get()` や `__set()` などのマジックメソッドをオーバーライドして、
-属性が通常のオブジェクトプロパティと同じようにアクセス出来るようにする必要があるかもしれないことに注意してください。
+例えば、[[yii\db\ActiveRecord]] は、関連付けられたデータベーステーブルのコラム名を属性の名前として返すことによって、属性を定義しています。
+これと同時に、定義された属性に対して通常のオブジェクトプロパティと同じようにアクセスすることが出来るように、
+`__get()` や `__set()` などのマジックメソッドをオーバーライドする必要があるかもしれないことに注意してください。
 
 
 ### 属性のラベル <a name="attribute-labels"></a>
@@ -101,8 +101,7 @@ echo $model->getAttributeLabel('name');
 このメソッドは、キャメルケースの変数名を複数の単語に分割し、各単語の最初の文字を大文字にします。
 例えば、`username` は `Username` となり、`firstName` は `First Name` となります。
 
-自動的に生成されるラベルを使用したくない場合は、[[yii\base\Model::attributeLabels()]] をオーバーライドして、
-属性のラベルを明示的に宣言することが出来ます。例えば、
+自動的に生成されるラベルを使用したくない場合は、[[yii\base\Model::attributeLabels()]] をオーバーライドして、属性のラベルを明示的に宣言することが出来ます。例えば、
 
 ```php
 namespace app\models;
@@ -129,7 +128,7 @@ class ContactForm extends Model
 ```
 
 複数の言語をサポートするアプリケーションでは、属性のラベルを翻訳したいと思うでしょう。
-これも、以下のように、[[yii\base\Model::attributeLabels()|attributeLabels()]] の中で行うことが出来ます:
+これも、以下のように、[[yii\base\Model::attributeLabels()|attributeLabels()]] の中で行うことが出来ます。
 
 ```php
 public function attributeLabels()
@@ -147,8 +146,7 @@ public function attributeLabels()
 [シナリオ](#scenarios) に基づいて、同じ属性に対して違うラベルを返すことことが出来ます。
 
 > Info|情報: 厳密に言えば、属性のラベルは [ビュー](structure-views.md) の一部を成すものです。
-  しかし、たいていの場合、モデルの中でラベルを宣言する方が便利が良く、
-  結果としてクリーンで再利用可能なコードになります。
+  しかし、たいていの場合、モデルの中でラベルを宣言する方が便利が良く、結果としてクリーンで再利用可能なコードになります。
 
 
 ## シナリオ<a name="scenarios"></a>
@@ -160,19 +158,19 @@ public function attributeLabels()
 
 モデルは [[yii\base\Model::scenario]] プロパティを使って、自身が使われているシナリオを追跡します。
 既定では、モデルは `default` という単一のシナリオのみをサポートします。
-次のコードは、モデルのシナリオを設定する二つの方法を示すものです:
+次のコードは、モデルのシナリオを設定する二つの方法を示すものです。
 
 ```php
 // プロパティとしてシナリオをセットする
 $model = new User;
 $model->scenario = 'login';
 
-// シナリオはコンフィギュレーションでセットされる
+// シナリオは設定情報でセットされる
 $model = new User(['scenario' => 'login']);
 ```
 
 既定では、モデルによってサポートされるシナリオは、モデルで宣言されている [検証規則](#validation-rules) によって決定されます。
-しかし、次のように、[[yii\base\Model::scenarios()]] メソッドをオーバーライドして、この動作をカスタマイズすることが出来ます:
+しかし、次のように、[[yii\base\Model::scenarios()]] メソッドをオーバーライドして、この動作をカスタマイズすることが出来ます。
 
 ```php
 namespace app\models;
@@ -201,7 +199,7 @@ class User extends ActiveRecord
 
 `scenarios()` の既定の実装は、検証規則の宣言メソッドである [[yii\base\Model::rules()]] に現れる全てのシナリオを返すものです。
 `scenarios()` をオーバーライドするときに、デフォルトのシナリオに加えて新しいシナリオを導入したい場合は、
-次のようなコードを書きます:
+次のようなコードを書きます。
 
 ```php
 namespace app\models;
@@ -250,9 +248,8 @@ if ($model->validate()) {
 ```
 
 
-モデルに関連付けられた検証規則を宣言するためには、[[yii\base\Model::rules()]] メソッドをオーバーライドして、
-モデルの属性が満たすべき規則を返すようにします。
-次の例は、`ContactForm` モデルのために宣言された検証規則を示します:
+モデルに関連付けられた検証規則を宣言するためには、[[yii\base\Model::rules()]] メソッドをオーバーライドして、モデルの属性が満たすべき規則を返すようにします。
+次の例は、`ContactForm` モデルのために宣言された検証規則を示します。
 
 ```php
 public function rules()
@@ -269,10 +266,10 @@ public function rules()
 
 一個の規則は、一個または複数の属性を検証するために使うことが出来ます。
 また、一個の属性は、一個または複数の規則によって検証することが出来ます。
-検証規則をどのように宣言するかについて、更なる詳細は [入力を検証する](input-validation.md) の節を参照してください。
+検証規則をどのように宣言するかについての詳細は [入力を検証する](input-validation.md) の節を参照してください。
 
-時として、特定の [シナリオ](#scenarios) にのみ適用される規則が必要になるでしょう。そのためには、下記のように、
-規則に `on` プロパティを指定することが出来ます:
+時として、特定の [シナリオ](#scenarios) にのみ適用される規則が必要になるでしょう。
+そのためには、下記のように、規則に `on` プロパティを指定することが出来ます。
 
 ```php
 public function rules()
@@ -290,8 +287,8 @@ public function rules()
 `on` プロパティを指定しない場合は、その規則は全てのシナリオに適用されることになります。
 現在の [[yii\base\Model::scenario|シナリオ]] に適用可能な規則は *アクティブな規則* と呼ばれます。
 
-属性が検証されるのは、それが `scenarios()` の中でアクティブな属性であると宣言されており、
-かつ、`rules()` の中で宣言されている一つまたは複数のアクティブな規則と関連付けられている場合であり、また、そのような場合だけです。
+属性が検証されるのは、それが `scenarios()` の中でアクティブな属性であると宣言されており、かつ、その属性が `rules()`
+の中で宣言されている一つまたは複数のアクティブな規則と結び付けられている場合であり、また、そのような場合だけです。
 
 
 ## 一括代入<a name="massive-assignment"></a>
@@ -299,7 +296,7 @@ public function rules()
 一括代入は、一行のコードを書くだけで、ユーザの入力したデータをモデルに投入できる便利な方法です。
 一括代入は、入力されたデータを [[yii\base\Model::$attributes]] に直接に代入することによって、モデルの属性にデータを投入します。
 次の二つのコード断片は等価であり、どちらもエンドユーザから送信されたフォームのデータを `ContactForm` モデルの属性に割り当てようとするものです。
-明らかに、一括代入を使う前者の方が、後者よりも明瞭で間違いも起こりにくいでしょう:
+明らかに、一括代入を使う前者の方が、後者よりも明瞭で間違いも起こりにくいでしょう。
 
 ```php
 $model = new \app\models\ContactForm;
@@ -318,8 +315,8 @@ $model->body = isset($data['body']) ? $data['body'] : null;
 
 ### 安全な属性<a name="safe-attributes"></a>
 
-一括代入は、いわゆる *安全な属性*、すなわち、モデルの現在の [[yii\base\Model::scenario|シナリオ]]
-用に [[yii\base\Model::scenarios()]] にリストされている属性に対してのみ適用されます。
+一括代入は、いわゆる *安全な属性*、すなわち、[[yii\base\Model::scenarios()]] においてモデルの現在の [[yii\base\Model::scenario|シナリオ]]
+のためにリストされている属性に対してのみ適用されます。
 例えば、`User` モデルが次のようなシナリオ宣言を持っている場合において、現在のシナリオが `login` であるときは、`username` と `password` のみが一括代入が可能です。その他の属性はいっさい触れられません。
 
 ```php
@@ -332,9 +329,8 @@ public function scenarios()
 }
 ```
 
-> Info|情報: 一括代入が安全な属性に対してのみ適用されるのは、どの属性がエンドユーザのデータによって
-  修正されうるかを制御する必要があるからです。
-  例えば、`User` モデルに、ユーザに割り当てられる権限を決定する `permission` という属性がある場合、
+> Info|情報: 一括代入が安全な属性に対してのみ適用されるのは、どの属性がエンドユーザの入力データによって修正されうるかを制御する必要があるからです。
+  例えば、`User` モデルに、ユーザに割り当てられた権限を決定する `permission` という属性がある場合、
   この属性が修正できるのは、管理者がバックエンドのインターフェイスを通じてする時だけに制限したいでしょう。
 
 [[yii\base\Model::scenarios()]] の既定の実装は [[yii\base\Model::rules()]] に現われる全てのシナリオと属性を返すものです。
@@ -354,11 +350,11 @@ public function rules()
 
 ### 安全でない属性<a name="unsafe-attributes"></a>
 
-上記で説明したように、[[yii\base\Model::scenarios()]] メソッドは二つの目的を持っています:
+上記で説明したように、[[yii\base\Model::scenarios()]] メソッドは二つの目的を持っています。
 すなわち、どの属性が検証されるべきかを決めることと、どの属性が安全であるかを決めることです。
 めったにない場合として、属性を検証する必要はあるが、安全であるという印は付けたくない、ということがあります。
 そういう時は、下の例の `secret` 属性のように、`scenarios()` の中で宣言するときに属性の名前の前に感嘆符
-`!` を前置することが出来ます:
+`!` を前置することが出来ます。
 
 ```php
 public function scenarios()
@@ -370,8 +366,7 @@ public function scenarios()
 ```
 
 このモデルが `login` シナリオにある場合、三つの属性は全て検証されます。しかし、`username` と
-`password` の属性だけが一括代入が可能です。`secret` 属性に入力値を割り当てるためには、
-下記のように明示的に実行する必要があります。
+`password` の属性だけが一括代入が可能です。`secret` 属性に入力値を割り当てるためには、下記のように明示的に代入を実行する必要があります。
 
 ```php
 $model->secret = $secret;
@@ -384,8 +379,8 @@ $model->secret = $secret;
 Excel 形式に変換したい場合があるでしょう。
 エクスポートのプロセスは二つの独立したステップに分割することが出来ます。
 最初のステップで、モデルは配列に変換されます。そして第二のステップで、配列が目的の形式に変換されます。
-あなたは最初のステップだけに注力しても構いません。と言うのは、第二のステップは汎用的なデータフォーマッタ、
-例えば [[yii\web\JsonResponseFormatter]] によって達成できるからです。
+あなたは最初のステップだけに注力しても構いません。と言うのは、第二のステップは汎用的なデータフォーマッタ、例えば [[yii\web\JsonResponseFormatter]]
+によって達成できるからです。
 
 モデルを配列に変換する最も簡単な方法は、[[yii\base\Model::$attributes]] プロパティを使うことです。
 例えば、
@@ -399,23 +394,21 @@ $array = $post->attributes;
 
 モデルを配列に変換するためのもっと柔軟で強力な方法は、[[yii\base\Model::toArray()]] メソッドを使うことです。
 このメソッドの既定の動作は [[yii\base\Model::$attributes]] のそれと同じものです。
-しかしながら、このメソッドを使うと、どのデータ項目 (*フィールド* と呼ばれます) を結果の配列に入れるか、
-そして、その項目にどのような書式を適用するかを選ぶことが出来ます。
-実際、[レスポンスの書式設定](rest-response-formatting.md) で説明されているように、
-RESTful ウェブサービスの開発においては、これがモデルをエクスポートする既定の方法となっています。
+しかしながら、このメソッドを使うと、どのデータ項目 (*フィールド* と呼ばれます)
+を結果の配列に入れるか、そして、その項目にどのような書式を適用するかを選ぶことが出来ます。
+実際、[レスポンスの書式設定](rest-response-formatting.md) で説明されているように、RESTful
+ウェブサービスの開発においては、これがモデルをエクスポートする既定の方法となっています。
 
 
 ### フィールド<a name="fields"></a>
 
-フィールドとは、単に、モデルの [[yii\base\Model::toArray()]] メソッドを呼ぶことによって取得される配列の中の、
-名前付きの要素のことです。
+フィールドとは、単に、モデルの [[yii\base\Model::toArray()]] メソッドを呼ぶことによって取得される配列に含まれる名前付きの要素のことです。
 
-既定では、フィールドの名前は属性の名前と等しいものになります。しかし、この既定の動作は、
-[[yii\base\Model::fields()|fields()]] および/または [[yii\base\Model::extraFields()|extraFields()]] メソッドをオーバーライドして、変更することが出来ます。
-どちらも、フィールド定義のリストを返すべきメソッドです。
-`fields()` によって定義されたフィールドは、デフォルトフィールドです。
-すなわち、`toArray()` が、既定ではこれらのフィールドを返すということを意味します。
-`extraFields()` メソッドは、`$expand` パラメータによって指定する限りにおいて `toArray()` によって返され得る、追加のフィールドを定義します。
+既定では、フィールドの名前は属性の名前と等しいものになります。しかし、この既定の動作は、[[yii\base\Model::fields()|fields()]]
+および/または [[yii\base\Model::extraFields()|extraFields()]] メソッドをオーバーライドして、変更することが出来ます。
+どちらのメソッドも、フィールド定義のリストを返します。
+`fields()` によって定義されるフィールドは、デフォルトフィールドです。すなわち、`toArray()` はデフォルトでこれらのフィールドを返す、ということを意味します。
+`extraFields()` メソッドは、`$expand` パラメータによって指定する限りにおいて `toArray()` によって返される追加のフィールドを定義するものです。
 例として、次のコードは、`fields()` で定義された全てのフィールドと、
 (`extraFields()` で定義されていれば) `prettyName` と `fullAddress` フィールドを返すものです。
 
@@ -424,8 +417,8 @@ $array = $model->toArray([], ['prettyName', 'fullAddress']);
 ```
 
 `fields()` をオーバーライドして、フィールドを追加、削除、リネーム、再定義することが出来ます。
-`fields()` の返り値は配列でなければなりません。配列のキーはフィールド名であり、
-配列の値は対応するフィールド定義です。フィールド定義には、プロパティ/属性の名前か、または、対応するフィールドの値を返す無名関数を使うことが出来ます。
+`fields()` の返り値は配列でなければなりません。配列のキーはフィールド名であり、配列の値は対応するフィールド定義です。
+フィールドの定義には、プロパティ/属性 の名前か、または、対応するフィールドの値を返す無名関数を使うことが出来ます。
 フィールド名がそれを定義する属性名と同一であるという特殊な場合においては、配列のキーを省略することが出来ます。
 例えば、
 
@@ -475,30 +468,28 @@ public function fields()
 
 要約すると、モデルは、
 
-* ビジネスデータを表現する属性を含むことが出来ます;
-* データの有効性と整合性を保証する検証規則を含むことが出来ます;
-* ビジネスロジックを実装するメソッドを含むことが出来ます;
+* ビジネスデータを表現する属性を含むことが出来ます。
+* データの有効性と整合性を保証する検証規則を含むことが出来ます。
+* ビジネスロジックを実装するメソッドを含むことが出来ます。
 * リクエスト、セッション、または他の環境データに直接アクセスするべきではありません。
-  これらのデータは、[コントローラ](structure-controllers.md) によってモデルに注入されるべきです;
-* HTML を埋め込むなどの表示用のコードは避けるべきです -  表示は [ビュー](structure-views.md) で行う方が良いです;
+  これらのデータは、[コントローラ](structure-controllers.md) によってモデルに注入されるべきです。
+* HTML を埋め込むなどの表示用のコードは避けるべきです -  表示は [ビュー](structure-views.md) で行う方が良いです。
 * あまりに多くの [シナリオ](#scenarios) を単一のモデルで持つことは避けましょう。
 
 大規模で複雑なシステムを開発するときには、たいてい、上記の最後にあげた推奨事項を考慮するのが良いでしょう。
 そういうシステムでは、モデルは数多くの場所で使用され、それに従って、数多くの規則セットやビジネスロジックを含むため、非常に大きくて重いものになり得ます。
 コードの一ヶ所に触れるだけで数ヶ所の違った場所に影響が及ぶため、ついには、モデルのコードの保守が悪夢になってしまうこともよくあります。
-モデルのコードの保守性を高めるために、以下の戦略をとることが出来ます:
+モデルのコードの保守性を高めるために、以下の戦略をとることが出来ます。
 
 * 異なる [アプリケーション](structure-applications.md) や [モジュール](structure-modules.md)
   によって共有される一連の基底モデルクラスを定義します。
   これらのモデルクラスは、すべてで共通に使用される最小限の規則セットとロジックのみを含むべきです。
-* モデルを使用するそれぞれの [アプリケーション](structure-applications.md) または [モジュール](structure-modules.md) において、
-  対応する基底モデルクラスから拡張した具体的なモデルクラスを定義します。
+* モデルを使用するそれぞれの [アプリケーション](structure-applications.md) または [モジュール](structure-modules.md)
+  において、対応する基底モデルクラスから拡張した具体的なモデルクラスを定義します。
   この具体的なモデルクラスが、そのアプリケーションやモジュールに固有の規則やロジックを含むべきです。
 
-例えば、[アドバンストアプリケーションテンプレート](tutorial-advanced-app.md) の中で、
-基底モデルクラス `common\models\Post` を定義することが出来ます。
-次に、フロントエンドアプリケーションにおいては、`common\models\Post` から拡張した具体的なモデルクラス
-`frontend\models\Post` を定義して使います。
-また、バックエンドアプリケーションにおいても、同様に、`backend\models\Post` を定義します。
+例えば、[アドバンストアプリケーションテンプレート](tutorial-advanced-app.md) の中で、基底モデルクラス `common\models\Post`
+を定義することが出来ます。次に、フロントエンドアプリケーションにおいては、`common\models\Post` から拡張した具体的なモデルクラス
+`frontend\models\Post` を定義して使います。また、バックエンドアプリケーションにおいても、同様に、`backend\models\Post` を定義します。
 この戦略を取ると、`frontend\models\Post` の中のコードはフロントエンドアプリケーション固有のものであると保証することが出来ます。
 そして、フロントエンドのコードにどのような変更を加えても、バックエンドアプリケーションを壊すかもしれないと心配する必要がなくなります。

docs/guide-ja/structure-modules.md

 モジュール
 ==========
 
-モジュールは、[モデル](structure-models.md)、[ビュー](structure-views.md)、[コントローラ](structure-controllers.md)、
-およびその他の支援コンポーネントから構成される自己充足的なソフトウェアのユニットです。
-モジュールが [アプリケーション](structure-applications.md) にインストールされている場合、
-エンドユーザはモジュールのコントローラにアクセスする事が出来ます。これらのことを理由として、
-モジュールは小さなアプリケーションと見なされることがよくあります。しかし、モジュールは単独では配置できず、
-アプリケーションの中に存在しなければならないという点で [アプリケーション](structure-applications.md) とは異なります。
+モジュールは、[モデル](structure-models.md)、[ビュー](structure-views.md)、[コントローラ](structure-controllers.md)、およびその他の支援コンポーネントから構成される自己充足的なソフトウェアのユニットです。
+モジュールが [アプリケーション](structure-applications.md) にインストールされている場合、エンドユーザはモジュールのコントローラにアクセスする事が出来ます。
+これらのことを理由として、モジュールは小さなアプリケーションと見なされることがよくあります。
+しかし、モジュールは単独では配置できず、アプリケーションの中に存在しなければならないという点で [アプリケーション](structure-applications.md) とは異なります。
 
 
 ## モジュールを作成する <a name="creating-modules"></a>
@@ -14,7 +12,7 @@
 モジュールは、モジュールの [[yii\base\Module::basePath|ベースパス]] と呼ばれるディレクトリとして組織されます。
 このディレクトリの中に、ちょうどアプリケーションの場合と同じように、`controllers`、`models`、`views`
 のようなサブディレクトリが存在して、コントローラ、モデル、ビュー、その他のコードを収納しています。
-次の例は、モジュール内の中身を示すものです:
+次の例は、モジュール内の中身を示すものです。
 
 ```
 forum/
@@ -32,13 +30,11 @@ forum/
 ### モジュールクラス <a name="module-classes"></a>
 
 全てのモジュールは [[yii\base\Module]] から拡張したユニークなモジュールクラスを持たなければなりません。
-モジュールクラスは、モジュールの [[yii\base\Module::basePath|ベースパス]] 直下に配置されて
-[オートロード可能](concept-autoloading.md) になっていなければなりません。
+モジュールクラスは、モジュールの [[yii\base\Module::basePath|ベースパス]] 直下に配置されて [オートロード可能](concept-autoloading.md) になっていなければなりません。
 モジュールがアクセスされたとき、対応するモジュールクラスの単一のインスタンスが作成されます。
-[アプリケーションのインスタンス](structure-applications.md) と同じように、モジュールのインスタンスは
-モジュール内のコードがデータとコンポーネントを共有するために使用されます。
+[アプリケーションのインスタンス](structure-applications.md) と同じように、モジュールのインスタンスは、モジュール内のコードがデータとコンポーネントを共有するために使用されます。
 
-次のコードは、モジュールクラスがどのように見えるかを示す例です:
+次のコードは、モジュールクラスがどのように見えるかを示す例です。
 
 ```php
 namespace app\modules\forum;
@@ -55,28 +51,25 @@ class Module extends \yii\base\Module
 }
 ```
 
-`init` メソッドがモジュールのプロパティを初期化するためのコードをたくさん含む場合は、それを
-[コンフィギュレーション](concept-configurations.md) の形で保存し、`init()` の中で次のコードを使って
-読み出すことも可能です:
+`init` メソッドがモジュールのプロパティを初期化するためのコードをたくさん含む場合は、
+それを [構成情報](concept-configurations.md) の形で保存し、`init()` の中で次のコードを使って読み出すことも可能です。
 
 ```php
 public function init()
 {
     parent::init();
-    // config.php からロードしたコンフィギュレーションでモジュールを初期化する
+    // config.php からロードした構成情報でモジュールを初期化する
     \Yii::configure($this, require(__DIR__ . '/config.php'));
 }
 ```
 
-ここで、コンフィギュレーションファイル `config.php` は、
-[アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の場合と同じように、
-次のような内容を含むことが出来ます。
+ここで、構成情報ファイル `config.php` は、[アプリケーションの構成情報](structure-applications.md#application-configurations) の場合と同じように、次のような内容を含むことが出来ます。
 
 ```php
 <?php
 return [
     'components' => [
-        // コンポーネントのコンフィギュレーションのリスト
+        // コンポーネントの構成情報のリスト
     ],
     'params' => [
         // パラメータのリスト
@@ -87,11 +80,9 @@ return [
 
 ### モジュール内のコントローラ <a name="controllers-in-modules"></a>
 
-モジュールの中でコントローラを作成するときは、コントローラクラスをモジュールクラスの名前空間の `controllers`
-サブ名前空間に置くことが規約です。このことは、同時に、コントローラのクラスファイルをモジュールの
-[[yii\base\Module::basePath|ベースパス]] 内の `controllers` ディレクトリに置くべきことをも意味します。
-例えば、前の項で示された `forum` モジュールの中で `post` コントローラを作成するためには、次のようにして
-コントローラを宣言しなければなりません:
+モジュールの中でコントローラを作成するときは、コントローラクラスをモジュールクラスの名前空間の `controllers` サブ名前空間に置くことが規約です。
+このことは、同時に、コントローラのクラスファイルをモジュールの [[yii\base\Module::basePath|ベースパス]] 内の `controllers` ディレクトリに置くべきことをも意味します。
+例えば、前の項で示された `forum` モジュールの中で `post` コントローラを作成するためには、次のようにしてコントローラを宣言しなければなりません。
 
 ```php
 namespace app\modules\forum\controllers;
@@ -105,78 +96,72 @@ class PostController extends Controller
 ```
 
 コントローラクラスの名前空間は、[[yii\base\Module::controllerNamespace]] プロパティを構成してカスタマイズすることが出来ます。
-いくつかのコントローラがこの名前空間の外にある場合でも、[[yii\base\Module::controllerMap]] プロパティを構成することによって、
-それらをアクセス可能にすることが出来ます。これは、[アプリケーションでのコントローラマップ](structure-applications.md#controller-map)
-の場合と同様です。
+いくつかのコントローラがこの名前空間の外にある場合でも、[[yii\base\Module::controllerMap]] プロパティを構成することによって、それらをアクセス可能にすることが出来ます。
+これは、[アプリケーションでのコントローラマップ](structure-applications.md#controller-map) の場合と同様です。
 
 
 ### モジュール内のビュー <a name="views-in-modules"></a>
 
 モジュール内のビューは、モジュールの [[yii\base\Module::basePath|ベースパス]] 内の `views` ディレクトリに置かれなくてはなりません。
-モジュール内のコントローラによってレンダリングされるビューは、ディレクトリ `views/ControllerID` の下に置きます。ここで、
-`ControllerID` は [コントローラ ID](structure-controllers.md#routes) を指します。例えば、コントローラクラスが `PostController`
-である場合、ディレクトリはモジュールの [[yii\base\Module::basePath|ベースパス]] の中の `views/post` となります。
+モジュール内のコントローラによってレンダリングされるビューは、ディレクトリ `views/ControllerID` の下に置きます。
+ここで、`ControllerID` は [コントローラ ID](structure-controllers.md#routes) を指します。
+例えば、コントローラクラスが `PostController` である場合、ディレクトリはモジュールの [[yii\base\Module::basePath|ベースパス]] の中の `views/post` となります。
 
-モジュールは、そのモジュールのコントローラによってレンダリングされるビューに適用される [レイアウト](structure-views.md#layouts)
-を指定することが出来ます。レイアウトは、既定では `views/layouts` ディレクトリに置かれなければならず、また、
-[[yii\base\Module::layout]] プロパティがレイアウトの名前を指すように構成しなければなりません。
+モジュールは、そのモジュールのコントローラによってレンダリングされるビューに適用される [レイアウト](structure-views.md#layouts) を指定することが出来ます。
+レイアウトは、既定では `views/layouts` ディレクトリに置かれなければならず、また、[[yii\base\Module::layout]] プロパティがレイアウトの名前を指すように構成しなければなりません。
 `layout` プロパティを構成しない場合は、アプリケーションのレイアウトが代りに使用されます。
 
 
 ## モジュールを使う <a name="using-modules"></a>
 
-アプリケーションの中でモジュールを使うためには、アプリケーションの [[yii\base\Application::modules|modules]] プロパティのリストに
-そのモジュールを載せてアプリケーションを構成するだけで大丈夫です。次のコードは、
-[アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で
-`forum` モジュールを使うようにするものです:
+アプリケーションの中でモジュールを使うためには、アプリケーションの [[yii\base\Application::modules|modules]] プロパティのリストにそのモジュールを載せてアプリケーションを構成するだけで大丈夫です。
+次のコードは、[アプリケーションの構成情報](structure-applications.md#application-configurations) の中で `forum` モジュールを使うようにするものです。
 
 ```php
 [
     'modules' => [
         'forum' => [
             'class' => 'app\modules\forum\Module',
-            // ... モジュールのその他のコンフィギュレーション ...
+            // ... モジュールのその他の構成情報 ...
         ],
     ],
 ]
 ```
 
-[[yii\base\Application::modules|modules]] プロパティは、モジュールのコンフィギュレーションの配列を取ります。各配列のキーは、
-アプリケーションの全てのモジュールの中でそのモジュールを特定するためのユニークな *モジュール ID* を表します。そして、
-対応する配列の値は、そのモジュールを作成するための [コンフィギュレーション](concept-configurations.md) です。
+[[yii\base\Application::modules|modules]] プロパティは、モジュールの構成情報の配列を取ります。
+各配列のキーは、アプリケーションの全てのモジュールの中でそのモジュールを特定するためのユニークな *モジュール ID* を表します。
+そして、対応する配列の値は、そのモジュールを作成するための [構成情報](concept-configurations.md) です。
 
 
 ### ルート <a name="routes"></a>
 
-アプリケーションの中のコントローラをアクセスするのと同じように、[ルート](structure-controllers.md#routes)
-がモジュールの中のコントローラを指し示すために使われます。モジュール内のコントローラのルートは、モジュール ID で始まり、
-コントローラ ID、アクション ID と続くものでなければなりません。例えば、アプリケーションが `forum` という名前のモジュールを
-使用している場合、`forum/post/index` というルートは、`forum` モジュール内の `post` コントローラの `index` アクションを表します。
-ルートがモジュール ID だけを含む場合は、[[yii\base\Module::defaultRoute]] プロパティ (その既定値は `default` です) が、
-どのコントローラ/アクションが使用されるべきかを決定します。これは、`forum` というルートは `forum` モジュール内の
-`default` コントローラを表すという意味です。
+アプリケーションの中のコントローラをアクセスするのと同じように、[ルート](structure-controllers.md#routes) がモジュールの中のコントローラを指し示すために使われます。
+モジュール内のコントローラのルートは、モジュール ID で始まり、コントローラ ID、アクション ID と続くものでなければなりません。
+例えば、アプリケーションが `forum` という名前のモジュールを使用している場合、`forum/post/index` というルートは、`forum` モジュール内の `post` コントローラの `index` アクションを表します。
+ルートがモジュール ID だけを含む場合は、[[yii\base\Module::defaultRoute]] プロパティ (既定値は `default` です) が、どのコントローラ/アクションが使用されるべきかを決定します。
+これは、`forum` というルートは `forum` モジュール内の `default` コントローラを表すという意味です。
 
 
 ### モジュールにアクセスする <a name="accessing-modules"></a>
 
-モジュール内において、モジュール ID や、モジュールのパラメータ、モジュールのコンポーネントなどにアクセスするために、
-[モジュールクラス](#module-classes) のインスタンスを取得する必要があることがよくあります。次の文を使ってそうすることが出来ます:
+モジュール内において、モジュール ID や、モジュールのパラメータ、モジュールのコンポーネントなどにアクセスするために、[モジュールクラス](#module-classes) のインスタンスを取得する必要があることがよくあります。
+次の文を使ってそうすることが出来ます。
 
 ```php
 $module = MyModuleClass::getInstance();
 ```
 
-ここで `MyModuleClass` は、関心を持っているモジュールクラスの名前を指します。`getInstance()` メソッドは、
-現在リクエストされているモジュールクラスのインスタンスを返します。モジュールがリクエストされていない場合は、
-このメソッドは null を返します。モジュールクラスの新しいインスタンスを手動で作成しようとしてはいけないことに注意してください。
+ここで `MyModuleClass` は、関心を持っているモジュールクラスの名前を指します。
+`getInstance()` メソッドは、現在リクエストされているモジュールクラスのインスタンスを返します。
+モジュールがリクエストされていない場合は、このメソッドは null を返します。
+モジュールクラスの新しいインスタンスを手動で作成しようとしてはいけないことに注意してください。
 そのインスタンスは、リクエストに対するレスポンスとして Yii によって作成されたインスタンスとは別のものになります。
 
-> Info|情報: モジュールを開発するとき、モジュールが固定の ID を使うと仮定してはいけません。なぜなら、モジュールは、
-  アプリケーションや他のモジュールの中で使うときに、任意の ID と結び付けることが出来るからです。
-  モジュール ID を取得するためには、上記の方法を使って最初にモジュールのインスタンスを取得し、そして `$module->id`
-  によって ID を取得しなければなりません。
+> Info|情報: モジュールを開発するとき、モジュールが固定の ID を使うと仮定してはいけません。
+  なぜなら、モジュールは、アプリケーションや他のモジュールの中で使うときに、任意の ID と結び付けることが出来るからです。
+  モジュール ID を取得するためには、上記の方法を使って最初にモジュールのインスタンスを取得し、そして `$module->id` によって ID を取得しなければなりません。
 
-モジュールのインスタンスにアクセスするためには、次の二つの方法を使うことも出来ます:
+モジュールのインスタンスにアクセスするためには、次の二つの方法を使うことも出来ます。
 
 ```php
 // ID が "forum" である子モジュールを取得する
@@ -186,8 +171,7 @@ $module = \Yii::$app->getModule('forum');
 $module = \Yii::$app->controller->module;
 ```
 
-最初の方法は、モジュール ID を知っている時しか役に立ちません。一方、第二の方法は、
-リクエストされているコントローラについて知っている場合に使うのに最適な方法です。
+最初の方法は、モジュール ID を知っている時しか役に立ちません。一方、第二の方法は、リクエストされているコントローラについて知っている場合に使うのに最適な方法です。
 
 いったんモジュールのインスタンスをとらえれば、モジュールに登録されたパラメータやコンポーネントにアクセスすることが可能になります。
 例えば、
@@ -202,7 +186,7 @@ $maxPostCount = $module->params['maxPostCount'];
 いくつかのモジュールは、全てのリクエストで毎回走らせる必要があります。[[yii\debug\Module|デバッグ]] モジュールがその一例です。
 そうするためには、そのようなモジュールをアプリケーションの [[yii\base\Application::bootstrap|bootstrap]] プロパティのリストに挙げます。
 
-例えば、次のアプリケーションのコンフィギュレーションは、`debug` モジュールが常にロードされることを保証するものです:
+例えば、次のアプリケーションの構成情報は、`debug` モジュールが常にロードされることを保証するものです。
 
 ```php
 [
@@ -219,9 +203,10 @@ $maxPostCount = $module->params['maxPostCount'];
 
 ## 入れ子のモジュール <a name="nested-modules"></a>
 
-モジュールはレベルの制限無く入れ子にすることが出来ます。つまり、モジュールは別のモジュールを含むことが出来、
-その含まれたモジュールもさらに別のモジュールを含むことが出来ます。含む側を *親モジュール*、含まれる側を *子モジュール*
-と呼びます。子モジュールは、親モジュールの [[yii\base\Module::modules|modules]] プロパティの中で宣言されなければなりません。
+モジュールはレベルの制限無く入れ子にすることが出来ます。
+つまり、モジュールは別のモジュールを含むことが出来、その含まれたモジュールもさらに別のモジュールを含むことが出来ます。
+含む側を *親モジュール*、含まれる側を *子モジュール* と呼びます。
+子モジュールは、親モジュールの [[yii\base\Module::modules|modules]] プロパティの中で宣言されなければなりません。
 例えば、
 
 ```php
@@ -244,8 +229,7 @@ class Module extends \yii\base\Module
 ```
 
 入れ子にされたモジュールの中にあるコントローラのルートは、全ての祖先のモジュールの ID を含まなければなりません。
-例えば、`forum/admin/dashboard/index` というルートは、`forum` モジュールの子モジュールである `admin` モジュールの
-`dashboard` コントローラの `index` アクションを表します。
+例えば、`forum/admin/dashboard/index` というルートは、`forum` モジュールの子モジュールである `admin` モジュールの `dashboard` コントローラの `index` アクションを表します。
 
 > Info|情報: [[yii\base\Module::getModule()|getModule()]] メソッドは、親モジュールに直接属する子モジュールだけを返します。
 [[yii\base\Application::loadedModules]] プロパティがロードされた全てのモジュールのリストを保持しています。
@@ -254,9 +238,8 @@ class Module extends \yii\base\Module
 
 ## 最善の慣行 <a name="best-practices"></a>
 
-モジュールは、それぞれ密接に関係する一連の機能を含む数個のグループに分割できるような、規模の大きなアプリケーションに
-最も適しています。そのような機能グループをそれぞれモジュールとして、特定の個人やチームによって開発することが出来ます。
+モジュールは、それぞれ密接に関係する一連の機能を含む数個のグループに分割できるような、規模の大きなアプリケーションに最も適しています。
+そのような機能グループをそれぞれモジュールとして、特定の個人やチームによって開発することが出来ます。
 
-モジュールは、また、機能グループレベルでコードを再利用するための良い方法でもあります。ある種のよく使われる機能、
-例えばユーザ管理やコメント管理などは、全て、将来のプロジェクトで容易に再利用できるように、モジュールの形式で
-開発することが出来ます。
+モジュールは、また、機能グループレベルでコードを再利用するための良い方法でもあります。
+ある種のよく使われる機能、例えばユーザ管理やコメント管理などは、全て、将来のプロジェクトで容易に再利用できるように、モジュールの形式で開発することが出来ます。

docs/guide-ja/structure-overview.md

@@ -2,11 +2,11 @@
 ====
 
 Yii のアプリケーションは [モデル・ビュー・コントローラ (MVC)](http://ja.wikipedia.org/wiki/Model_View_Controller) デザインパターンに従って組織されます。
-[モデル](structure-models.md) は、データ、ビジネスロジック、規則を表現します;
-[ビュー](structure-views.md) は、モデルの出力表現です;
+[モデル](structure-models.md) は、データ、ビジネスロジック、規則を表現します。
+[ビュー](structure-views.md) は、モデルの出力表現です。
 そして [コントローラ](structure-controllers.md) は入力を受け取って、それを [モデル](structure-models.md) と [ビュー](structure-views.md) のためのコマンドに変換します。
 
-MVC 以外にも、Yii のアプリケーションは下記の要素を持っています:
+MVC 以外にも、Yii のアプリケーションは下記の要素を持っています。
 
 * [エントリスクリプト](structure-entry-scripts.md): エンドユーザから直接アクセスできる PHP スクリプトです。
   これはリクエスト処理サイクルを開始する役目を持っています。
@@ -15,9 +15,9 @@ MVC 以外にも、Yii のアプリケーションは下記の要素を持って
 * [アプリケーションコンポーネント](structure-application-components.md): アプリケーションと共に登録されたオブジェクトであり、リクエストに応えるための様々なサービスを提供します。
 * [モジュール](structure-modules.md): それ自身に完全な MVC を含む自己完結的なパッケージです。
   アプリケーションは複数のモジュールとして組織することが出来ます。
-* [フィルター](structure-filters.md): 各リクエストが実際に処理される前と後に、コントローラから呼び出される必要があるコードを表現します。
+* [フィルタ](structure-filters.md): 各リクエストが実際に処理される前と後に、コントローラから呼び出される必要があるコードを表現します。
 * [ウィジェット](structure-widgets.md): [ビュー](structure-views.md) に埋め込むことが出来るオブジェクトです。コントローラのロジックを含むことが可能で、異なるビューで再利用することが出来ます。
 
-下の図がアプリケーションの静的な構造を示すものです:
+下の図がアプリケーションの静的な構造を示すものです。
 
 ![アプリケーションの静的な構造](images/application-structure.png)

docs/guide-ja/structure-views.md

@@ -3,9 +3,8 @@
 
 ビューは [MVC](http://ja.wikipedia.org/wiki/Model_View_Controller) アーキテクチャの一部を成すものです。
 ビューはエンドユーザにデータを表示することに責任を持つコードです。
-ウェブアプリケーションにおいては、ビューは、通常、主として HTML コードと表示目的の PHP コードを含む PHP スクリプトファイルである、
-*ビューテンプレート* の形式で作成されます。
-そして、ビューテンプレートを管理する [[yii\web\View|ビュー]] [アプリケーションコンポーネント](structure-application-components.md) は、
+ウェブアプリケーションにおいては、ビューは、通常、主として HTML コードと表示目的の PHP コードを含む PHP スクリプトファイルである、*ビューテンプレート* の形式で作成されます。
+そして、ビューテンプレートを管理する [[yii\web\View|ビュー]] [アプリケーションコンポーネント](structure-application-components.md) が、
 ビューの構築とレンダリングを助けるためによく使われるメソッドを提供します。
 なお、簡潔さを重視して、ビューテンプレートまたはビューテンプレートファイルを単にビューと呼ぶことがよくあります。
 
@@ -38,25 +37,22 @@ $this->title = '繝ｭ繧ｰ繧､繝ｳ';
 <?php ActiveForm::end(); ?>
 ```
 
-ビューの中でアクセスできる `$this` は、このビューテンプレートを管理しレンダリングしている
-[[yii\web\View|ビューコンポーネント]] を参照します。
+ビューの中でアクセスできる `$this` は、このビューテンプレートを管理しレンダリングしている [[yii\web\View|ビューコンポーネント]] を参照します。
 
 `$this` 以外に、上記の例の `$model` のように、前もって定義された変数がビューの中にあることがあります。
 このような変数は、[コントローラ](structure-controllers.md) または [ビューのレンダリング](#rendering-views) をトリガするオブジェクトによってビューに *プッシュ* されたデータを表します。
 
-> Tip|ヒント: 上の例では、事前に定義された変数は、IDE に認識されるように、
-  ビューの先頭のコメントブロックの中にリストされています。これは、ビューに
-  ドキュメントを付けるのにも良い方法です。
+> Tip|ヒント: 上の例では、事前に定義された変数は、IDE に認識されるように、ビューの先頭のコメントブロックの中にリストされています。
+  これは、ビューにドキュメントを付けるのにも良い方法です。
 
 
 ### セキュリティ <a name="security"></a>
 
-HTML ページを生成するビューを作成するときは、エンドユーザから受け取るデータを
-表示する前に エンコード および/または フィルター することが重要です。
+HTML ページを生成するビューを作成するときは、エンドユーザから受け取るデータを表示する前にエンコード および/または フィルタすることが重要です。
 そうしなければ、あなたのアプリケーションは [クロスサイトスクリプティング](http://ja.wikipedia.org/wiki/%E3%82%AF%E3%83%AD%E3%82%B9%E3%82%B5%E3%82%A4%E3%83%88%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%97%E3%83%86%E3%82%A3%E3%83%B3%E3%82%B0) 攻撃をこうむるおそれがあります。
 
 平文テキストを表示するためには、まず [[yii\helpers\Html::encode()]] を呼んでエンコードします。
-例えば、次のコードはユーザの名前を表示する前にエンコードしています:
+例えば、次のコードはユーザの名前を表示する前にエンコードしています。
 
 ```php
 <?php
@@ -68,8 +64,8 @@ use yii\helpers\Html;
 </div>
 ```
 
-HTML コンテンツを表示するためには、[[yii\helpers\HtmlPurifier]] を使って、最初にコンテンツをフィルターします。
-例えば、次のコードは、投稿のコンテンツを表示する前にフィルターしています:
+HTML コンテンツを表示するためには、[[yii\helpers\HtmlPurifier]] を使って、最初にコンテンツをフィルタします。
+例えば、次のコードは、投稿のコンテンツを表示する前にフィルタしています。
 
 ```php
 <?php
@@ -81,28 +77,22 @@ use yii\helpers\HtmlPurifier;
 </div>
 ```
 
-> Tip|ヒント: HTMLPurifier は、出力を安全なものにすることにおいては素晴らしい仕事をしますが、
-  速くはありません。アプリケーションが高いパフォーマンスを要求する場合は、
-  フィルター結果を [キャッシュ](caching-overview.md) することを考慮すべきです。
+> Tip|ヒント: HTMLPurifier は、出力を安全なものにすることにおいては素晴らしい仕事をしますが、速くはありません。
+  アプリケーションが高いパフォーマンスを要求する場合は、フィルター結果を [キャッシュ](caching-overview.md) することを考慮すべきです。
 
 
 ### ビューを整理する <a name="organizing-views"></a>
 
-[コントローラ](structure-controllers.md) や [モデル](structure-models.md) と同じように、
-ビューを整理するための規約があります。.
+[コントローラ](structure-controllers.md) や [モデル](structure-models.md) と同じように、ビューを整理するための規約があります。.
 
-* コントローラによって表示されるビューは、既定では、ディレクトリ
-  `@app/views/ControllerID` の下に置かれるべきものです。
+* コントローラによって表示されるビューは、既定では、ディレクトリ `@app/views/ControllerID` の下に置かれるべきものです。
   ここで、`ControllerID` は [コントローラ ID](structure-controllers.md#routes) を指します。
-  例えば、コントローラクラスが `PostController` である場合、ディレクトリは `@app/views/post`
-  となります。`PostCommentController` の場合は、ディレクトリは `@app/views/post-comment` です。
-  また、コントローラがモジュールに属する場合は、ディレクトリは [[yii\base\Module::basePath|モジュールディレクトリ]]
-  の下の `views/ControllerID` です。
-* [ウィジェット](structure-widgets.md) で表示されるビューは、既定では、`WidgetPath/views`
-  ディレクトリの下に置かれるべきものです。ここで、`WidgetPath` は、ウィジェットのクラスファイル
-  を含んでいるディレクトリを指します。
-* 他のオブジェクトによって表示されるビューについても、ウィジェットの場合と同じ規約に従うことが
-  推奨されます。
+  例えば、コントローラクラスが `PostController` である場合、ディレクトリは `@app/views/post` となります。
+  `PostCommentController` の場合は、ディレクトリは `@app/views/post-comment` です。
+  また、コントローラがモジュールに属する場合は、ディレクトリは [[yii\base\Module::basePath|モジュールディレクトリ]] の下の `views/ControllerID` です。
+* [ウィジェット](structure-widgets.md) で表示されるビューは、既定では、`WidgetPath/views` ディレクトリの下に置かれるべきものです。
+  ここで、`WidgetPath` は、ウィジェットのクラスファイルを含んでいるディレクトリを指します。
+* 他のオブジェクトによって表示されるビューについても、ウィジェットの場合と同じ規約に従うことが推奨されます。
 
 これらの既定のビューディレクトリは、コントローラやウィジェットの [[yii\base\ViewContextInterface::getViewPath()]]
 メソッドをオーバーライドすることでカスタマイズすることが可能です。
@@ -110,14 +100,13 @@ use yii\helpers\HtmlPurifier;
 
 ## ビューをレンダリングする <a name="rendering-views"></a>
 
-[コントローラ](structure-controllers.md) の中でも、[ウィジェット](structure-widgets.md) の中でも、
-または、その他のどんな場所でも、ビューをレンダリングするメソッドを呼ぶことによって
-ビューをレンダリングすることが出来ます。
+[コントローラ](structure-controllers.md) の中でも、[ウィジェット](structure-widgets.md) の中でも、または、その他のどんな場所でも、
+ビューをレンダリングするメソッドを呼ぶことによってビューをレンダリングすることが出来ます。
 これらのメソッドは、下記に示されるような類似のシグニチャを共有します。
 
 ```
 /**
- * @param string $view ビュー名またはファイルパス、実際のレンダリングメソッドに依存する
+ * @param string $view ビュー名またはファイルパス (実際のレンダリングメソッドに依存する)
  * @param array $params ビューに引き渡されるデータ
  * @return string レンダリングの結果
  */
@@ -127,20 +116,14 @@ methodName($view, $params = [])
 
 ### コントローラでのレンダリング <a name="rendering-in-controllers"></a>
 
-[コントローラ](structure-controllers.md) の中では、ビューをレンダリングするために
-次のコントローラメソッドを呼ぶことが出来ます:
+[コントローラ](structure-controllers.md) の中では、ビューをレンダリングするために次のコントローラメソッドを呼ぶことが出来ます。
 
-* [[yii\base\Controller::render()|render()]]: [名前付きビュー](#named-views) をレンダリングし、
-  その結果に [レイアウト](#layouts) を適用する。
-* [[yii\base\Controller::renderPartial()|renderPartial()]]: [名前付きビュー](#named-views) を
-  レイアウトなしでレンダリングする。
-* [[yii\web\Controller::renderAjax()|renderAjax()]]: [名前付きビュー](#named-views) を
-  レイアウトなしでレンダリングし、登録されている全ての JS/CSS スクリプトおよびファイルを注入する。
+* [[yii\base\Controller::render()|render()]]: [名前付きビュー](#named-views) をレンダリングし、その結果に [レイアウト](#layouts) を適用する。
+* [[yii\base\Controller::renderPartial()|renderPartial()]]: [名前付きビュー](#named-views) をレイアウトなしでレンダリングする。
+* [[yii\web\Controller::renderAjax()|renderAjax()]]: [名前付きビュー](#named-views) をレイアウトなしでレンダリングし、登録されている全ての JS/CSS スクリプトおよびファイルを注入する。
   通常、AJAX ウェブリクエストに対するレスポンスにおいて使用される。
-* [[yii\base\Controller::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md)
-  の形式で指定されたビューをレンダリングする。
-* [[yii\base\Controller::renderContent()|renderContent()]]: 現在適用可能な [レイアウト](#layouts) に埋め込むことによって、
-  静的な文字列をレンダリングする。このメソッドは バージョン 2.0.1 以降で使用可能。
+* [[yii\base\Controller::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md) の形式で指定されたビューをレンダリングする。
+* [[yii\base\Controller::renderContent()|renderContent()]]: 静的な文字列をレンダリングして、現在適用可能な [レイアウト](#layouts) に埋め込む。このメソッドは バージョン 2.0.1 以降で使用可能。
 
 例えば、
 
@@ -172,12 +155,10 @@ class PostController extends Controller
 
 ### ウィジェットでのレンダリング <a name="rendering-in-widgets"></a>
 
-[ウィジェット](structure-widgets.md) の中では、ビューをレンダリングするために、
-次のウィジェットメソッドを使用することが出来ます。
+[ウィジェット](structure-widgets.md) の中では、ビューをレンダリングするために、次のウィジェットメソッドを使用することが出来ます。
 
 * [[yii\base\Widget::render()|render()]]: [名前付きのビュー](#named-views) をレンダリングする。
-* [[yii\base\Widget::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md)
-  の形式で指定されたビューをレンダリングする。
+* [[yii\base\Widget::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md) の形式で指定されたビューをレンダリングする。
 
 例えば、
 
@@ -204,19 +185,15 @@ class ListWidget extends Widget
 
 ### ビューでのレンダリング <a name="rendering-in-views"></a>
 
-[[yii\base\View|ビューコンポーネント]] によって提供される下記のメソッドのどれかを使うと、
-ビューの中で、別のビューをレンダリングすることが出来ます:
+[[yii\base\View|ビューコンポーネント]] によって提供される下記のメソッドのどれかを使うと、ビューの中で、別のビューをレンダリングすることが出来ます。
 
 * [[yii\base\View::render()|render()]]: [名前付きのビュー](#named-views) をレンダリングする。
-* [[yii\web\View::renderAjax()|renderAjax()]]: [名前付きビュー](#named-views) をレンダリングし、
-  登録されている全ての JS/CSS スクリプトおよびファイルを注入する。
+* [[yii\web\View::renderAjax()|renderAjax()]]: [名前付きビュー](#named-views) をレンダリングし、登録されている全ての JS/CSS スクリプトおよびファイルを注入する。
   通常、AJAX ウェブリクエストに対するレスポンスにおいて使用される。
-* [[yii\base\View::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md)
-  の形式で指定されたビューをレンダリングする。
+* [[yii\base\View::renderFile()|renderFile()]]: ビューファイルのパスまたは [エイリアス](concept-aliases.md) の形式で指定されたビューをレンダリングする。
 
-例えば、ビューの中の次のコードは、現在レンダリングされているビューと同じディレクトリにある
-`_overview.php` というビューファイルをレンダリングします。
-ビューでは `$this` が [[yii\base\View|ビュー]] コンポーネントを参照することを思い出してください:
+例えば、ビューの中の次のコードは、現在レンダリングされているビューと同じディレクトリにある `_overview.php` というビューファイルをレンダリングします。
+ビューでは `$this` が [[yii\base\View|ビュー]] コンポーネントを参照することを思い出してください。
 
 ```php
 <?= $this->render('_overview') ?>
@@ -237,8 +214,7 @@ echo \Yii::$app->view->renderFile('@app/views/site/license.php');
 
 ### 名前付きビュー <a name="named-views"></a>
 
-ビューをレンダリングするとき、ビューを指定するのには、ビューの名前か、
-ビューファイルのパス/エイリアスか、どちらかを使うことが出来ます。
+ビューをレンダリングするとき、ビューを指定するのには、ビューの名前か、ビューファイルのパス/エイリアスか、どちらかを使うことが出来ます。
 たいていの場合は、より簡潔で柔軟な前者を使います。
 名前を使って指定されるビューを *名前付きビュー* と呼びます。
 
@@ -246,42 +222,32 @@ echo \Yii::$app->view->renderFile('@app/views/site/license.php');
 
 * ビュー名はファイル拡張子を省略することが出来ます。その場合、`.php` が拡張子として使われます。
   例えば、`about` というビュー名は `about.php` というファイル名に対応します。
-* ビュー名が二つのスラッシュ (`//`) で始まる場合は、対応するビューファイルのパスは `@app/views/ViewName`
-  となります。つまり、ビューファイルは [[yii\base\Application::viewPath|アプリケーションのビューパス]]
-  の下で探されます。例えば、`//site/about` は `@app/views/site/about.php` へと解決されます。
-* ビュー名が一つのスラッシュ (`/`) で始まる場合は、ビューファイルのパスは、ビュー名の前に、現在
-  アクティブな [モジュール](structure-modules.md) の [[yii\base\Module::viewPath|ビューパス]]
-  を置くことによって形成されます。アクティブなモジュールが無い場合は、`@app/views/ViewName`
-  が使用されます。例えば、`/user/create` は、現在アクティブなモジュールが `user` である場合は、
-  `@app/modules/user/views/user/create.php` へと解決されます。アクティブなモジュールが無い場合は、
-  ビューファイルのパスは `@app/views/user/create.php` となります。
-* ビューが [[yii\base\View::context|コンテキスト]] を伴ってレンダリングされ、そのコンテキストが
-  [[yii\base\ViewContextInterface]] を実装している場合は、ビューファイルのパスは、コンテキストの
-  [[yii\base\ViewContextInterface::getViewPath()|ビューパス]] をビュー名の前に置くことによって
-  形成されます。これは、主として、コントローラとウィジェットの中でレンダリングされるビューに当てはまります。
-  例えば、コンテキストが `SiteController` コントローラである場合、`site/about` は `@app/views/site/about.php`
-  へと解決されます。
-* あるビューが別のビューの中でレンダリングされる場合は、後者のビューファイルを含んでいるディレクトリが
-  前者のビュー名の前に置かれて、実際のビューファイルのパスが形成されます。例えば、`item` は、
-  `@app/views/post/index.php` というビューの中でレンダリングされる場合、`@app/views/post/item`
-  へと解決されます。
-
-上記の規則によると、コントローラ `app\controllers\PostController` の中で `$this->render('view')` を呼ぶと、
-実際には、ビューファイル `@app/views/post/view.php` がレンダリングされ、一方、そのビューの中で
-`$this->render('_overview')` を呼ぶと、ビューファイル `@app/views/post/_overview.php`
-がレンダリングされることになります。
+* ビュー名が二つのスラッシュ (`//`) で始まる場合は、対応するビューファイルのパスは `@app/views/ViewName` となります。
+  つまり、ビューファイルは [[yii\base\Application::viewPath|アプリケーションのビューパス]] の下で探されます。
+  例えば、`//site/about` は `@app/views/site/about.php` へと解決されます。
+* ビュー名が一つのスラッシュ (`/`) で始まる場合は、ビューファイルのパスは、ビュー名の前に、現在アクティブな [モジュール](structure-modules.md) の [[yii\base\Module::viewPath|ビューパス]] を置くことによって形成されます。
+  アクティブなモジュールが無い場合は、`@app/views/ViewName` が使用されます。
+  例えば、`/user/create` は、現在アクティブなモジュールが `user` である場合は、`@app/modules/user/views/user/create.php` へと解決されます。
+  アクティブなモジュールが無い場合は、ビューファイルのパスは `@app/views/user/create.php` となります。
+* ビューが [[yii\base\View::context|コンテキスト]] を伴ってレンダリングされ、そのコンテキストが [[yii\base\ViewContextInterface]] を実装している場合は、
+  ビューファイルのパスは、コンテキストの [[yii\base\ViewContextInterface::getViewPath()|ビューパス]] をビュー名の前に置くことによって形成されます。
+  これは、主として、コントローラとウィジェットの中でレンダリングされるビューに当てはまります。
+  例えば、コンテキストが `SiteController` コントローラである場合、`site/about` は `@app/views/site/about.php` へと解決されます。
+* あるビューが別のビューの中でレンダリングされる場合は、後者のビューファイルを含んでいるディレクトリが前者のビュー名の前に置かれて、実際のビューファイルのパスが形成されます。
+  例えば、`item` は、`@app/views/post/index.php` というビューの中でレンダリングされる場合、`@app/views/post/item` へと解決されます。
+
+上記の規則によると、コントローラ `app\controllers\PostController` の中で `$this->render('view')` を呼ぶと、実際には、ビューファイル `@app/views/post/view.php` がレンダリングされ、
+一方、そのビューの中で `$this->render('_overview')` を呼ぶと、ビューファイル `@app/views/post/_overview.php` がレンダリングされることになります。
 
 
 ### ビューの中でデータにアクセスする <a name="accessing-data-in-views"></a>
 
-ビューの中でデータにアクセスするためのアプローチが二つあります: 「プッシュ」と「プル」です。
+ビューの中でデータにアクセスするためのアプローチが二つあります。「プッシュ」と「プル」です。
 
 ビューをレンダリングするメソッドに二番目のパラメータとしてデータを渡すのが「プッシュ」のアプローチです。
 データは、「名前-値」のペアの配列として表されなければなりません。
-ビューがレンダリングされるときに、PHP の `extract()` 関数がこの配列に対して呼び出され、
-ビューの中でこの配列から変数が抽出されます。
-例えば、次のコードはコントローラの中でビューをレンダリングしていますが、`report` ビューに
-二つの変数、すなわち、`$foo = 1` と `$bar = 2` をプッシュしています。
+ビューがレンダリングされるときに、PHP の `extract()` 関数がこの配列に対して呼び出され、ビューの中でこの配列から変数が抽出されます。
+例えば、次のコードはコントローラの中でビューをレンダリングしていますが、`report` ビューに二つの変数、すなわち、`$foo = 1` と `$bar = 2` をプッシュしています。
 
 ```php
 echo $this->render('report', [
@@ -290,11 +256,10 @@ echo $this->render('report', [
 ]);
 ```
 
-「プル」のアプローチは、[[yii\base\View|ビューコンポーネント]] またはビューからアクセス出来るその他のオブジェクト (例えば `Yii::$app`) から
-積極的にデータを読み出すものです。
-下記のコードを例として使って、ビューの中で `$this->context` という式でコントローラオブジェクト
-を取得することが出来ます。その結果、`report` ビューの中でコントローラの全てのプロパティや
-メソッドにアクセスすることが出来ます。次の例ではコントローラ ID にアクセスしています:
+「プル」のアプローチは、[[yii\base\View|ビューコンポーネント]] またはビューからアクセス出来るその他のオブジェクト (例えば `Yii::$app`) から積極的にデータを読み出すものです。
+下記のコード例のように、ビューの中では `$this->context` という式でコントローラオブジェクトを取得することが出来ます。
+その結果、`report` ビューの中で、コントローラの全てのプロパティやメソッドにアクセスすることが出来ます。
+次の例ではコントローラ ID にアクセスしています。
 
 ```php
 The controller ID is: <?= $this->context->id ?>
@@ -304,24 +269,20 @@ The controller ID is: <?= $this->context->id ?>
 通常は「プッシュ」アプローチが、ビューでデータにアクセスする方法として推奨されます。
 なぜなら、ビューのコンテキストオブジェクトに対する依存がより少ないからです。
 その短所は、常にデータ配列を手作業で作成する必要がある、ということです。
-ビューが共有されてさまざまな場所でレンダリングされる場合、その作業が面倒くさくなり、また、
-間違いも生じやすくなります。
+ビューが共有されてさまざまな場所でレンダリングされる場合、その作業が面倒くさくなり、また、間違いも生じやすくなります。
 
 
 ### ビューの間でデータを共有する <a name="sharing-data-among-views"></a>
 
-[[yii\base\View|ビューコンポーネント]] が提供する [[yii\base\View::params|params]] プロパティを使うと
-ビューの間でデータを共有することが出来ます。
+[[yii\base\View|ビューコンポーネント]] が提供する [[yii\base\View::params|params]] プロパティを使うと、ビューの間でデータを共有することが出来ます。
 
-例えば、`about` というビューで、次のようなコードを使って、
-パン屑リストの現在の区分を指定することが出来ます。
+例えば、`about` というビューで、次のようなコードを使って、パン屑リストの現在の区分を指定することが出来ます。
 
 ```php
 $this->params['breadcrumbs'][] = 'About Us';
 ```
 
-そして、[レイアウト](#layouts) ファイル (これも一つのビューです) の中で、[[yii\base\View::params|params]]
-によって渡されたデータを使って、パン屑リストを表示することが出来ます:
+そして、[レイアウト](#layouts) ファイル (これも一つのビューです) の中で、[[yii\base\View::params|params]] によって渡されたデータを使って、パン屑リストを表示することが出来ます。
 
 ```php
 <?= yii\widgets\Breadcrumbs::widget([
@@ -334,23 +295,19 @@ $this->params['breadcrumbs'][] = 'About Us';
 
 レイアウトは、複数のビューの共通部分をあらわす特殊なタイプのビューです。
 例えば、たいていのウェブアプリケーションでは、ページは共通のヘッダとフッタを持っています。
-すべてのビューで同じヘッダとフッタを繰り返すことも出来ますが、もっと良い方法は、
-そういうことはレイアウトの中で一度だけして、コンテンツビューのレンダリング結果を
-レイアウトの中の適切な場所に埋め込むことです。
+すべてのビューで同じヘッダとフッタを繰り返すことも出来ますが、もっと良い方法は、そういうことはレイアウトの中で一度だけして、コンテンツビューのレンダリング結果をレイアウトの中の適切な場所に埋め込むことです。
 
 
 ### レイアウトを作成する <a name="creating-layouts"></a>
 
-レイアウトもまたビューですので、通常のビューと同様な方法で作成することが出来ます。既定では、
-レイアウトは `@app/views/layouts` ディレクトリに保存されます。[モジュール](structure-modules.md)
-の中で使用されるレイアウトについては、[[yii\base\Module::basePath|モジュールディレクトリ]] の下の
-`views/layouts` ディレクトリに保存されるべきものとなります。既定のレイアウトディレクトリは、
-アプリケーションまたはモジュールの [[yii\base\Module::layoutPath]] プロパティを構成することで
-カスタマイズすることが出来ます。
+レイアウトもまたビューですので、通常のビューと同様な方法で作成することが出来ます。
+既定では、レイアウトは `@app/views/layouts` ディレクトリに保存されます。
+[モジュール](structure-modules.md) の中で使用されるレイアウトについては、[[yii\base\Module::basePath|モジュールディレクトリ]]
+の下の `views/layouts` ディレクトリに保存されるべきものとなります。
+既定のレイアウトディレクトリは、アプリケーションまたはモジュールの [[yii\base\Module::layoutPath]] プロパティを構成することでカスタマイズすることが出来ます。
 
-次の例は、レイアウトがどのようなものであるかを示すものです。説明のために、レイアウトの中のコードを
-大幅に単純化していることに注意してください。実際には、ヘッドのタグやメインメニューなど、もっと
-多くのコンテンツを追加する必要があるでしょう。
+次の例は、レイアウトがどのようなものであるかを示すものです。説明のために、レイアウトの中のコードを大幅に単純化していることに注意してください。
+実際には、ヘッドのタグやメインメニューなど、もっと多くのコンテンツを追加する必要があるでしょう。
 
 ```php
 <?php
@@ -379,13 +336,11 @@ use yii\helpers\Html;
 <?php $this->endPage() ?>
 ```
 
-見ると分かるように、レイアウトはすべてのページに共通な HTML タグを生成しています。`<body>`
-セクションの中でレイアウトが `$content` という変数をエコーしていますが、これは、
-コンテンツビューのレンダリング結果を表すものであり、[[yii\base\Controller::render()]] が呼ばれるときに、レイアウトにプッシュされるものです。
+見ると分かるように、レイアウトはすべてのページに共通な HTML タグを生成しています。`<body>` セクションの中でレイアウトが `$content` という変数をエコーしていますが、
+これは、コンテンツビューのレンダリング結果を表すものであり、[[yii\base\Controller::render()]] が呼ばれるときに、レイアウトにプッシュされるものです。
 
 上記のコードに示されているように、たいていのレイアウトは次に挙げるメソッドを呼び出すべきです。
-これらのメソッドは主としてレンダリングの過程に関するイベントをトリガして、他の場所で登録された
-スクリプトやタグが、メソッドが呼ばれた場所に正しく注入されるようにするためのものです。
+これらのメソッドは主としてレンダリングの過程に関するイベントをトリガして、他の場所で登録されたスクリプトやタグが、メソッドが呼ばれた場所に正しく注入されるようにするためのものです。
 
 - [[yii\base\View::beginPage()|beginPage()]]: このメソッドがレイアウトの一番初めに呼ばれるべきです。
   これは、ページの開始を示す [[yii\base\View::EVENT_BEGIN_PAGE|EVENT_BEGIN_PAGE]] イベントをトリガします。
@@ -395,37 +350,33 @@ use yii\helpers\Html;
   このメソッドは、ページのレンダリングが完了したときに、登録された head の HTML コード (リンクタグ、メタタグなど) に置き換えられるプレースホルダを生成します。
 - [[yii\web\View::beginBody()|beginBody()]]: このメソッドが `<body>` セクションの最初で呼ばれるべきです。
   このメソッドは [[yii\web\View::EVENT_BEGIN_BODY|EVENT_BEGIN_BODY]] イベントをトリガし、
-  body の開始位置を目的とする登録された HTML コード (JavaScript など) によって置き換えられる
-  プレースホルダを生成します。
+  body の開始位置を目的とする登録された HTML コード (JavaScript など) によって置き換えられるプレースホルダを生成します。
 - [[yii\web\View::endBody()|endBody()]]: このメソッドが `<body`> セクションの最後で呼ばれるべきです。
   このメソッドは  [[yii\web\View::EVENT_END_BODY|EVENT_END_BODY]] イベントをトリガし、
-  body の終了位置を目的とする登録された HTML コード (JavaScript など) によって置き換えられる
-  プレースホルダを生成します。
+  body の終了位置を目的とする登録された HTML コード (JavaScript など) によって置き換えられるプレースホルダを生成します。
 
 
 ### レイアウトでデータにアクセスする <a name="accessing-data-in-layouts"></a>
 
-レイアウトの中では、事前定義された二つの変数にアクセス出来ます: `$this` と `$content` です。前者は、
-通常のビューにおいてと同じく、[[yii\base\View|ビュー]] コンポーネントを参照します。一方、後者は、
-コントローラの中で [[yii\base\Controller::render()|render()]] メソッドを呼ぶことによってレンダリングされる、
+レイアウトの中では、事前定義された二つの変数、すなわち、`$this` と `$content` にアクセス出来ます。
+前者は、通常のビューにおいてと同じく、[[yii\base\View|ビュー]] コンポーネントを参照します。
+一方、後者は、コントローラの中で [[yii\base\Controller::render()|render()]] メソッドを呼ぶことによってレンダリングされる、
 コンテンツビューのレンダリング結果を含むものです。
 
-レイアウトの中で他のデータにアクセスする必要があるときは、[ビューの中でデータにアクセスする](#accessing-data-in-views)
-の項で説明されている「プル」の方法を使う必要があります。コンテンツビューからレイアウトにデータを渡す必要があるときは、
-[ビューの間でデータを共有する](#sharing-data-among-views) の項で説明されている方法を使うことが出来ます。
+レイアウトの中で他のデータにアクセスする必要があるときは、[ビューの中でデータにアクセスする](#accessing-data-in-views) の項で説明されている「プル」の方法を使う必要があります。
+コンテンツビューからレイアウトにデータを渡す必要があるときは、[ビューの間でデータを共有する](#sharing-data-among-views) の項で説明されている方法を使うことが出来ます。
 
 
 ### レイアウトを使う <a name="using-layouts"></a>
 
 [コントローラでのレンダリング](#rendering-in-controllers) の項で説明されているように、コントローラの中で
-[[yii\base\Controller::render()|render()]] メソッドを呼んでビューをレンダリングすると、レンダリング結果に
-レイアウトが適用されます。既定では、`@app/views/layouts/main.php` というレイアウトが使用されます。
-
-[[yii\base\Application::layout]] または [[yii\base\Controller::layout]] のどちらかを構成することによって、異なるレイアウトを
-使うことが出来ます。前者は全てのコントローラによって使用されるレイアウトを決定するものですが、後者は個々のコントローラについて
-前者をオーバーライドするものです。例えば、次のコードは、`post` コントローラがビューをレンダリングするときに
-`@app/views/layouts/post.php` をレイアウトとして使うようにするものです。その他のコントローラは、`layout` プロパティに
-触れられていないと仮定すると、引き続き既定の `@app/views/layouts/main.php` をレイアウトとして使います。
+[[yii\base\Controller::render()|render()]] メソッドを呼んでビューをレンダリングすると、レンダリング結果にレイアウトが適用されます。
+既定では、`@app/views/layouts/main.php` というレイアウトが使用されます。
+
+[[yii\base\Application::layout]] または [[yii\base\Controller::layout]] のどちらかを構成することによって、異なるレイアウトを使うことが出来ます。
+前者は全てのコントローラによって使用されるレイアウトを決定するものですが、後者は個々のコントローラについて前者をオーバーライドするものです。
+例えば、次のコードは、`post` コントローラがビューをレンダリングするときに `@app/views/layouts/post.php` をレイアウトとして使うようにするものです。
+その他のコントローラは、`layout` プロパティに触れられていないと仮定すると、引き続き既定の `@app/views/layouts/main.php` をレイアウトとして使います。
  
 ```php
 namespace app\controllers;
@@ -440,13 +391,11 @@ class PostController extends Controller
 }
 ```
 
-モジュールに属するコントローラについては、モジュールの [[yii\base\Module::layout|layout]] プロパティを構成して、モジュール内の
-コントローラに特定のレイアウトを使用することも出来ます。
+モジュールに属するコントローラについては、モジュールの [[yii\base\Module::layout|layout]] プロパティを構成して、モジュール内のコントローラに特定のレイアウトを使用することも出来ます。
 
-`layout` プロパティは異なるレベル (コントローラ、モジュール、アプリケーション) で構成されうるものですので、
-Yii は舞台裏で二つのステップを践んで、特定のコントローラで実際に使われるレイアウトファイルが何であるかを決定します。
+`layout` プロパティは異なるレベル (コントローラ、モジュール、アプリケーション) で構成されうるものですので、Yii は舞台裏で二つのステップを踏んで、特定のコントローラで実際に使われるレイアウトファイルが何であるかを決定します。
 
-最初のステップで、Yii はレイアウトの値とコンテキストモジュールを決定します:
+最初のステップで、Yii はレイアウトの値とコンテキストモジュールを決定します。
 
 - コントローラの [[yii\base\Controller::layout]] プロパティが null でないときは、それをレイアウトの値として使い、
   コントローラの [[yii\base\Controller::module|モジュール]] をコンテキストモジュールとして使う。
@@ -456,7 +405,7 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
   そのようなモジュールが見つからなかったときは、レイアウトは適用されないということを意味する。
 
 第二のステップでは、最初のステップで決定されたレイアウトの値とコンテキストモジュールに従って、実際のレイアウトファイルを決定します。
-レイアウトの値は下記のいずれかであり得ます:
+レイアウトの値は下記のいずれかであり得ます。
 
 - パスエイリアス (例えば、`@app/views/layouts/main`)。
 - 絶対パス (例えば、`/main`): すなわち、スラッシュで始まるレイアウトの値の場合。
@@ -471,12 +420,12 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 
 ### 入れ子のレイアウト <a name="nested-layouts"></a>
 
-ときとして、あるレイアウトの中に別のレイアウトを入れたい場合があるでしょう。例えば、
-ウェブサイトの別々のセクションにおいて、違うレイアウトを使いたいけれども、
-それらのレイアウトは全て、全体としての HTML5 ページ構造を生成する同一の基本レイアウトを
-共有している、という場合です。この目的を達することは、次のように、子レイアウトの中で
+ときとして、あるレイアウトの中に別のレイアウトを入れたい場合があるでしょう。
+例えば、ウェブサイトの別々のセクションにおいて、違うレイアウトを使いたいけれども、
+それらのレイアウトは全て、全体としての HTML5 ページ構造を生成する同一の基本レイアウトを共有している、という場合です。
+この目的を達することは、次のように、子レイアウトの中で
 [[yii\base\View::beginContent()|beginContent()]] と [[yii\base\View::endContent()|endContent()]]
-を呼ぶことで可能になります:
+を呼ぶことで可能になります。
 
 ```php
 <?php $this->beginContent('@app/views/layouts/base.php'); ?>
@@ -488,8 +437,8 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 
 上のコードが示すように、子レイアウトのコンテンツは [[yii\base\View::beginContent()|beginContent()]] と
 [[yii\base\View::endContent()|endContent()]] によって囲まれなければなりません。
-[[yii\base\View::beginContent()|beginContent()]] に渡されるパラメータは、
-親レイアウトで何であるかを指定するものです。レイアウトのファイルまたはエイリアスのどちらかを使うことが出来ます。
+[[yii\base\View::beginContent()|beginContent()]] に渡されるパラメータは、親レイアウトで何であるかを指定するものです。
+レイアウトのファイルまたはエイリアスのどちらかを使うことが出来ます。
 
 上記のアプローチを使って、2レベル以上のレイアウトを入れ子にすることも出来ます。
 
@@ -497,16 +446,14 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 ### ブロックを使う <a name="using-blocks"></a>
 
 ブロックを使うと、ある場所でビューコンテンツを規定して、別の場所でそれを表示することが可能になります。
-ブロックはたいていはレイアウトと一緒に使われます。例えば、ブロックをコンテンツビューで定義して、
-それをレイアウトで表示する、ということが出来ます。
+ブロックはたいていはレイアウトと一緒に使われます。
+例えば、ブロックをコンテンツビューで定義して、それをレイアウトで表示する、ということが出来ます。
 
-[[yii\base\View::beginBlock()|beginBlock()]] と [[yii\base\View::endBlock()|endBlock()]]
-を呼んでブロックを定義します。
+[[yii\base\View::beginBlock()|beginBlock()]] と [[yii\base\View::endBlock()|endBlock()]] を呼んでブロックを定義します。
 すると、そのブロックを `$view->blocks[$blockID]` によってアクセス出来るようになります。
 ここで `$blockID` は、定義したときにブロックに割り当てたユニークな ID を指します。
 
-次の例は、どのようにブロックを使えば、レイアウトの特定の部分をコンテンツビューで
-カスタマイズすることが出来るかを示すものです。
+次の例は、どのようにブロックを使えば、レイアウトの特定の部分をコンテンツビューでカスタマイズすることが出来るかを示すものです。
 
 最初に、コンテンツビューで、一つまたは複数のブロックを定義します。
 
@@ -528,8 +475,7 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 <?php $this->endBlock(); ?>
 ```
 
-次に、レイアウトビューで、得ることが出来ればブロックをレンダリングし、ブロックが定義されていないときは
-何らかの既定のコンテンツを表示します。
+次に、レイアウトビューで、得ることが出来ればブロックをレンダリングし、ブロックが定義されていないときは何らかの既定のコンテンツを表示します。
 
 ```php
 ...
@@ -561,9 +507,8 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 ## ビューコンポーネントを使う <a name="using-view-components"></a>
 
 [[yii\base\View|ビューコンポーネント]] はビューに関連する多くの機能を提供します。
-ビューコンポーネントは、[[yii\base\View]] またはその子クラスの個別のインスタンスを作成することによっても取得できますが、
-たいていの場合は、`view` アプリケーションコンポーネントを主として使うことになるでしょう。
-このコンポーネントは [アプリケーションのコンフィギュレーション](structure-applications.md#application-configurations) の中で、次のようにして構成することが出来ます:
+ビューコンポーネントは、[[yii\base\View]] またはその子クラスの個別のインスタンスを作成することによっても取得できますが、たいていの場合は、`view` アプリケーションコンポーネントを主として使うことになるでしょう。
+このコンポーネントは [アプリケーションの構成情報](structure-applications.md#application-configurations) の中で、次のようにして構成することが出来ます。
 
 ```php
 [
@@ -577,8 +522,7 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 ]
 ```
 
-ビューコンポーネントは、次に挙げるビュー関連の有用な機能を提供します。それぞれについては、
-独立の節で更に詳細に説明されます。
+ビューコンポーネントは、次に挙げるビュー関連の有用な機能を提供します。それぞれについては、独立の節で更に詳細に説明されます。
 
 * [テーマ](output-theming.md): ウェブサイトのテーマを開発し変更することを可能にします。
 * [フラグメントキャッシュ](caching-fragment.md): ウェブページの中の断片をキャッシュすることを可能にします。
@@ -586,17 +530,16 @@ Yii 縺ｯ闊槫床陬上〒莠後▽縺ｮ繧ｹ繝ャ繝励ｒ霍ｵ繧薙〒縲∫音螳壹繧ｳ繝ｳ繝医Ο繝ｼ
 * [アセットバンドルの取り扱い](structure-assets.md): [アセットバンドル](structure-assets.md) の登録とレンダリングをサポートします。
 * [代替のテンプレートエンジン](tutorial-template-engines.md): [Twig](http://twig.sensiolabs.org/)、[Smarty](http://www.smarty.net/) など、他のテンプレートエンジンを使用することを可能にします。
 
-次に挙げるマイナーではあっても有用な諸機能は、ウェブページを開発するときに頻繁に使用するでしょう:
+次に挙げるマイナーではあっても有用な諸機能は、ウェブページを開発するときに頻繁に使用するでしょう。
 
 
 ### ページタイトルを設定する <a name="setting-page-titles"></a>
 
-どんなウェブページにもタイトルが無ければなりません。通常、タイトルタグは [layout](#layouts) の中で表示されます。しかし、
-実際においては、多くの場合、タイトルはレイアウトではなくコンテンツビューで決められます。この問題を解決するために、
-[[yii\web\View]] は、タイトル情報をコンテンツビューからレイアウトに渡すための [[yii\web\View::title|title]] プロパティを
-提供しています。
+どんなウェブページにもタイトルが無ければなりません。通常、タイトルタグは [layout](#layouts) の中で表示されます。
+しかし、実際においては、多くの場合、タイトルはレイアウトではなくコンテンツビューで決められます。
+この問題を解決するために、[[yii\web\View]] は、タイトル情報をコンテンツビューからレイアウトに渡すための [[yii\web\View::title|title]] プロパティを提供しています。
 
-この機能を利用するためには、全てのコンテンツビューにおいて、次のようにタイトルを設定します:
+この機能を利用するためには、全てのコンテンツビューにおいて、次のようにタイトルを設定します。
 
 ```php
 <?php
@@ -604,7 +547,7 @@ $this->title = 'My page title';
 ?>
 ```
 
-そして、レイアウトビューで、`<head>` セクションに次のコードを忘れずに書くようにします:
+そして、レイアウトビューで、`<head>` セクションに次のコードを忘れずに書くようにします。
 
 ```php
 <title><?= Html::encode($this->title) ?></title>
@@ -613,11 +556,10 @@ $this->title = 'My page title';
 
 ### メタタグを登録する <a name="registering-meta-tags"></a>
 
-ウェブページは、通常、いろいろな関係者によって必要とされるさまざまなメタタグを生成する必要があります。ページタイトルと同じように、
-メタタグは `<head>` セクションに出現して、通常はレイアウトの中で生成されます。
+ウェブページは、通常、いろいろな関係者によって必要とされるさまざまなメタタグを生成する必要があります。
+ページタイトルと同じように、メタタグは `<head>` セクションに出現して、通常はレイアウトの中で生成されます。
 
-どのようなメタタグを生成するかをコンテンツビューの中で指定したい場合は、下記のように、
-[[yii\web\View::registerMetaTag()]] をコンテンツビューの呼ぶことが出来ます:
+どのようなメタタグを生成するかをコンテンツビューの中で指定したい場合は、下記のように、[[yii\web\View::registerMetaTag()]] をコンテンツビューの呼ぶことが出来ます。
 
 ```php
 <?php
@@ -625,20 +567,17 @@ $this->registerMetaTag(['name' => 'keywords', 'content' => 'yii, framework, php'
 ?>
 ```
 
-上記のコードは、ビューコンポーネントによって "keywords" メタタグを登録するものです。登録されたメタタグは、
-レイアウトがレンダリングを完了した後でレンダリングされます。すなわち、レイアウトの中で [[yii\web\View::head()]]
-を呼び出した場所に、次の HTML コードが生成されて挿入されます:
+上記のコードは、ビューコンポーネントによって "keywords" メタタグを登録するものです。登録されたメタタグは、レイアウトがレンダリングを完了した後でレンダリングされます。
+すなわち、レイアウトの中で [[yii\web\View::head()]] を呼び出した場所に、次の HTML コードが生成されて挿入されます。
 
 ```php
 <meta name="keywords" content="yii, framework, php">
 ```
 
-[[yii\web\View::registerMetaTag()]] を複数回呼び出した場合は、メタタグが同じものか否かに関係なく、
-複数のメタタグが登録されることに注意してください。
+[[yii\web\View::registerMetaTag()]] を複数回呼び出した場合は、メタタグが同じものか否かに関係なく、複数のメタタグが登録されることに注意してください。
 
-ある型のメタタグのインスタンスが一つだけになることを保証したい場合は、このメソッドを呼ぶときに第二のパラメータとして
-キーを指定することが出来ます。例えば、次のコードでは、二つの "description" メタタグを登録していますが、
-二番目のものだけがレンダリングされることになります。
+ある型のメタタグのインスタンスが一つだけになることを保証したい場合は、このメソッドを呼ぶときに第二のパラメータとしてキーを指定することが出来ます。
+例えば、次のコードでは、二つの "description" メタタグを登録していますが、二番目のものだけがレンダリングされることになります。
 
 ```html
 $this->registerMetaTag(['name' => 'description', 'content' => '俺が Yii で作ったクールなウェブサイトだぜぃ!!'], 'description');
@@ -648,9 +587,10 @@ $this->registerMetaTag(['name' => 'description', 'content' => '髱｢逋ｽ縺い繝ｩ繧
 
 ### リンクタグを登録する <a name="registering-link-tags"></a>
 
-[メタタグ](#registering-meta-tags) と同じように、リンクタグも多くの場合において有用なものです。例えば、favicon をカスタマイズしたり、
-RSS フィードを指し示したり、OpenID を別のサーバに委任したり、等々。リンクタグも、[[yii\web\View::registerLinkTag()]] を使って、
-メタタグと同じような方法で取り扱うことが出来ます。例えば、コンテンツビューにおいて、次のようにしてリンクタグを登録することが出来ます。
+[メタタグ](#registering-meta-tags) と同じように、リンクタグも多くの場合において有用なものです。
+例えば、favicon をカスタマイズしたり、RSS フィードを指し示したり、OpenID を別のサーバに委任したり、等々。
+リンクタグも、[[yii\web\View::registerLinkTag()]] を使って、メタタグと同じような方法で取り扱うことが出来ます。
+例えば、コンテンツビューにおいて、次のようにしてリンクタグを登録することが出来ます。
 
 ```php
 $this->registerLinkTag([
@@ -674,20 +614,18 @@ $this->registerLinkTag([
 ## ビューのイベント <a name="view-events"></a>
 
 [[yii\base\View|ビューコンポーネント]] はビューをレンダリングする過程においていくつかのイベントをトリガします。
-これらのイベントに反応することによって、ビューにコンテンツを注入したり、
-エンドユーザに送信される前にレンダリング結果を加工したりすることが出来ます。
+これらのイベントに反応することによって、ビューにコンテンツを注入したり、エンドユーザに送信される前にレンダリング結果を加工したりすることが出来ます。
 
 - [[yii\base\View::EVENT_BEFORE_RENDER|EVENT_BEFORE_RENDER]]: コントローラでファイルをレンダリングする前にトリガされます。
   このイベントのハンドラは、[[yii\base\ViewEvent::isValid]] を false にセットして、レンダリングのプロセスをキャンセルすることが出来ます。
 - [[yii\base\View::EVENT_AFTER_RENDER|EVENT_AFTER_RENDER]]: ファイルのレンダリングの後、[[yii\base\View::afterRender()]] を呼ぶことによってトリガされます。
-  このイベントのハンドラは、レンダリング結果を [[yii\base\ViewEvent::output]] によって取得することが出来、
-  このプロパティを修正してレンダリング結果を変更することが出来ます。
+  このイベントのハンドラは、レンダリング結果をプロパティ [[yii\base\ViewEvent::output]] を通じて取得して、それを修正してレンダリング結果を変更することが出来ます。
 - [[yii\base\View::EVENT_BEGIN_PAGE|EVENT_BEGIN_PAGE]]: レイアウトの中で [[yii\base\View::beginPage()]] を呼ぶことによってトリガされます。
 - [[yii\base\View::EVENT_END_PAGE|EVENT_END_PAGE]]: レイアウトの中で [[yii\base\View::endPage()]] を呼ぶことによってトリガされます。
 - [[yii\web\View::EVENT_BEGIN_BODY|EVENT_BEGIN_BODY]]: レイアウトの中で [[yii\web\View::beginBody()]] を呼ぶことによってトリガされます。
 - [[yii\web\View::EVENT_END_BODY|EVENT_END_BODY]]: レイアウトの中で [[yii\web\View::endBody()]] を呼ぶことによってトリガされます。
 
-例えば、次のコードはページの body の最後に現在の日付を注入するものです:
+例えば、次のコードはページの body の最後に現在の日付を注入するものです。
 
 ```php
 \Yii::$app->view->on(View::EVENT_END_BODY, function () {
@@ -698,10 +636,9 @@ $this->registerLinkTag([
 
 ## 静的なページをレンダリングする <a name="rendering-static-pages"></a>
 
-静的なページというのは、主たるコンテンツのほとんどが静的なもので、コントローラからプッシュされる動的なデータに
-アクセスする必要がないページを指します。
+静的なページというのは、主たるコンテンツのほとんどが静的なもので、コントローラからプッシュされる動的なデータにアクセスする必要がないページを指します。
 
-静的なページは、そのコードをビューに置き、そして、コントローラで次のようなコードを使うと表示することが出来ます:
+静的なページは、そのコードをビューに置き、そして、コントローラで次のようなコードを使うと表示することが出来ます。
 
 ```php
 public function actionAbout()
@@ -732,8 +669,7 @@ class SiteController extends Controller
 }
 ```
 
-このようにすると、ディレクトリ `@app/views/site/pages` の下に `about` という名前のビューを作成したときに、
-次の URL によってこのビューを表示することが出来るようになります:
+このようにすると、ディレクトリ `@app/views/site/pages` の下に `about` という名前のビューを作成したときに、次の URL によってこのビューを表示することが出来るようになります。
 
 ```
 http://localhost/index.php?r=site/page&view=about
@@ -748,18 +684,17 @@ http://localhost/index.php?r=site/page&view=about
 
 ビューはエンドユーザが望む形式でモデルを表現することに対して責任を持ちます。一般的に、ビューは
 
-* 主として表示目的のコードを含むべきです。例えば、HTML、そしてデータをたどり、書式化してレンダリングする簡単な PHP コードなど。
+* 主として表示目的のコードを含むべきです。例えば、HTML、または、データをたどって書式化してレンダリングする簡単な PHP コードなど。
 * DB クエリを実行するコードは含むべきではありません。そのようなコードはモデルの中で実行されるべきです。
 * `$_GET` や `$_POST` のようなリクエストデータに直接アクセスするべきではありません。それはコントローラの仕事です。
   リクエストデータが必要な場合は、コントローラからビューにプッシュされるべきです。
 * モデルのプロパティを読み出すことが出来ます。しかし、それを修正するべきではありません。
 
 ビューを管理しやすいものにするために、複雑すぎるビューや、冗長なコードをあまりに多く含むビューを作ることは避けましょう。
-この目的を達するために、次のテクニックを使うことが出来ます:
+この目的を達するために、次のテクニックを使うことが出来ます。
 
 * 共通の表示セクション (ページのヘッダやフッタなど) を表すために [レイアウト](#layouts) を使う。
-* 複雑なビューはいくつかの小さなビューに分割する。既に説明したレンダリングのメソッドを使えば、
-  小さなビューをレンダリングして大きなビューを組み上げることが出来る。
+* 複雑なビューはいくつかの小さなビューに分割する。既に説明したレンダリングのメソッドを使えば、小さなビューをレンダリングして大きなビューを組み上げることが出来る。
 * ビューの構成要素として [ウィジェット](structure-widgets.md) を使う。
-* ビューでデータを変換し書式化するためのヘルパークラスを作成して使う。
+* ビューでデータを変換し書式化するためのヘルパクラスを作成して使う。
 

docs/guide-ja/structure-widgets.md

@@ -2,7 +2,7 @@
 ============
 
 ウィジェットは、[ビュー](structure-views.md) で使用される再利用可能な構成ブロックで、
-複雑かつコンフィギュレーション可能なユーザインタフェイス要素をオブジェクト指向のやり方で作成するためのものです。
+複雑かつ構成可能なユーザインタフェイス要素をオブジェクト指向のやり方で作成するためのものです。
 例えば、日付選択ウィジェットを使うと、入力として日付を選択することを可能にする素敵なデイトピッカーを生成することが出来ます。
 このとき、あなたがしなければならないことは、次のようなコードをビューに挿入することだけです:
 
@@ -13,8 +13,8 @@ use yii\jui\DatePicker;
 <?= DatePicker::widget(['name' => 'date']) ?>
 ```
 
-数多くのウィジェットが Yii にバンドルされています。例えば、[[yii\widgets\ActiveForm|アクティブフォーム]] や、
-[[yii\widgets\Menu|メニュー]]、[jQuery UI ウィジェット](widget-jui.md)、[Twitter Bootstrap ウィジェット](widget-bootstrap.md) などです。
+数多くのウィジェットが Yii にバンドルされています。
+例えば、[[yii\widgets\ActiveForm|アクティブフォーム]] や、[[yii\widgets\Menu|メニュー]]、[jQuery UI ウィジェット](widget-jui.md)、[Twitter Bootstrap ウィジェット](widget-bootstrap.md) などです。
 下記では、ウィジェットに関する基本的な知識の手引きをします。
 特定のウィジェットの使い方について学ぶ必要がある場合は、クラス API ドキュメントを参照してください。
 
@@ -23,9 +23,8 @@ use yii\jui\DatePicker;
 
 ウィジェットは主として [ビュー](structure-views.md) で使われます。
 ビューでウィジェットを使うためには、[[yii\base\Widget::widget()]] メソッドを使うことが出来ます。
-このメソッドは、ウィジェットを初期化するための [コンフィギュレーション](concept-configurations.md) 配列を受け取り、ウィジェットのレンダリング結果を返します。
-例えば、下記のコードは、日本語を使い、入力を `$model` の `from_date`
-属性に保存するように構成された日付選択ウィジェットを挿入するものです。
+このメソッドは、ウィジェットを初期化するための [構成情報](concept-configurations.md) 配列を受け取り、ウィジェットのレンダリング結果を返します。
+例えば、下記のコードは、日本語を使い、入力を `$model` の `from_date` 属性に保存するように構成された日付選択ウィジェットを挿入するものです。
 
 ```php
 <?php
@@ -41,8 +40,8 @@ use yii\jui\DatePicker;
 ]) ?>
 ```
 
-ウィジェットの中には、コンテンツのブロックを受け取ることが出来るものもあります。その場合、コンテンツのブロックは
-[[yii\base\Widget::begin()]] と [[yii\base\Widget::end()]] の呼び出しの間に包むようにしなければなりません。
+ウィジェットの中には、コンテンツのブロックを受け取ることが出来るものもあります。
+その場合、コンテンツのブロックは [[yii\base\Widget::begin()]] と [[yii\base\Widget::end()]] の呼び出しの間に包むようにしなければなりません。
 例えば、次のコードは [[yii\widgets\ActiveForm]] ウィジェットを使ってログインフォームを生成するものです。
 このウィジェットは、`begin()` と `end()` が呼ばれる場所で、それぞれ、開始と終了の `<form>` タグを生成します。
 その間に置かれたものは全てそのままレンダリングされます。
@@ -66,17 +65,15 @@ use yii\helpers\Html;
 <?php ActiveForm::end(); ?>
 ```
 
-[[yii\base\Widget::widget()]] がウィジェットのレンダリング結果を返すのとは違って、[[yii\base\Widget::begin()]] メソッドが
-ウィジェットのインスタンスを返すことに注意してください。返されたウィジェットのインスタンスを使って、ウィジェットのコンテンツを
-構築することが出来ます。
+[[yii\base\Widget::widget()]] がウィジェットのレンダリング結果を返すのとは違って、[[yii\base\Widget::begin()]] メソッドがウィジェットのインスタンスを返すことに注意してください。
+返されたウィジェットのインスタンスを使って、ウィジェットのコンテンツを構築することが出来ます。
 
 
 ## ウィジェットを作成する <a name="creating-widgets"></a>
 
-ウィジェットを作成するためには、[[yii\base\Widget]] を拡張して、[[yii\base\Widget::init()]] および/または [[yii\base\Widget::run()]]
-メソッドをオーバーライドします。通常、`init()` メソッドはウィジェットのプロパティを正規化するコードを含むべきものであり、
-`run()` メソッドはウィジェットのレンダリング結果を生成するコードを含むべきものです。レンダリング結果は、直接に "echo"
-しても、`run()` の返り値として文字列として返しても構いません。
+ウィジェットを作成するためには、[[yii\base\Widget]] を拡張して、[[yii\base\Widget::init()]] および/または [[yii\base\Widget::run()]] メソッドをオーバーライドします。
+通常、`init()` メソッドはウィジェットのプロパティを正規化するコードを含むべきものであり、`run()` メソッドはウィジェットのレンダリング結果を生成するコードを含むべきものです。
+レンダリング結果は、直接に "echo" しても、`run()` の返り値として文字列として返しても構いません。
 
 次の例では、`HelloWidget` が `message` プロパティとして割り当てられたコンテンツを HTML エンコードして表示します。
 プロパティがセットされていない場合は、デフォルトとして "Hello World" を表示します。
@@ -115,8 +112,7 @@ use app\components\HelloWidget;
 <?= HelloWidget::widget(['message' => 'おはよう']) ?>
 ```
 
-下記は `HelloWidget` の変種で、`begin()` と `end()` の間に包まれたコンテンツを受け取り、それを
-HTML エンコードして表示するものです。
+下記は `HelloWidget` の変種で、`begin()` と `end()` の間に包まれたコンテンツを受け取り、それを HTML エンコードして表示するものです。
 
 ```php
 namespace app\components;
@@ -140,12 +136,10 @@ class HelloWidget extends Widget
 }
 ```
 
-ご覧のように、`init()` の中で PHP の出力バッファが開始され、`init()` と `run()` の呼び出しの間の全ての出力がキャプチャされ、
-`run()` の中で処理されて返されます。
+ご覧のように、`init()` の中で PHP の出力バッファが開始され、`init()` と `run()` の呼び出しの間の全ての出力がキャプチャされ、`run()` の中で処理されて返されます。
 
-> Info|情報: [[yii\base\Widget::begin()]] を呼ぶと、ウィジェットの新しいインスタンスが作成され、ウィジェットのコンストラクタの
-  最後で `init()` メソッドが呼ばれます。[[yii\base\Widget::end()]] を呼ぶと、`run()` メソッドが呼ばれて、その返り値が `end()`
-  によって echo されます。
+> Info|情報: [[yii\base\Widget::begin()]] を呼ぶと、ウィジェットの新しいインスタンスが作成され、ウィジェットのコンストラクタの最後で `init()` メソッドが呼ばれます。
+[[yii\base\Widget::end()]] を呼ぶと、`run()` メソッドが呼ばれて、その返り値が `end()` によって echo されます。
 
 次のコードは、この `HelloWidget` の新しい変種をどのように使うかを示すものです:
 
@@ -160,9 +154,10 @@ use app\components\HelloWidget;
 <?php HelloWidget::end(); ?>
 ```
 
-場合によっては、ウィジェットが大きな固まりのコンテンツを表示する必要があるかもしれません。コンテンツを `run()`
-メソッドの中に埋め込むことも出来ますが、より良い方法は、コンテンツを [ビュー](structure-views.md) の中に置いて、
-[[yii\base\Widget::render()]] を呼んでレンダリングすることです。例えば、
+場合によっては、ウィジェットが大きな固まりのコンテンツを表示する必要があるかもしれません。
+コンテンツを `run()` メソッドの中に埋め込むことも出来ますが、より良い方法は、コンテンツを [ビュー](structure-views.md)
+の中に置いて、[[yii\base\Widget::render()]] を呼んでレンダリングすることです。
+例えば、
 
 ```php
 public function run()
@@ -171,25 +166,24 @@ public function run()
 }
 ```
 
-既定では、ウィジェット用のビューは `WidgetPath/views` ディレクトリの中のファイルに保存すべきものです。ここで
-`WidgetPath` はウィジェットのクラスファイルを含むディレクトリを指します。したがって、上記の例では、ウィジェットクラスが
-`@app/components` に配置されていると仮定すると、`@app/components/views/hello.php` というビューファイルがレンダリングされる
-ことになります。[[yii\base\Widget::getViewPath()]] メソッドをオーバーライドして、ウィジェットのビューファイルを含むディレクトリを
-カスタマイズすることが出来ます。
+既定では、ウィジェット用のビューは `WidgetPath/views` ディレクトリの中のファイルに保存すべきものです。
+ここで `WidgetPath` はウィジェットのクラスファイルを含むディレクトリを指します。
+したがって、上記の例では、ウィジェットクラスが `@app/components` に配置されていると仮定すると、`@app/components/views/hello.php` というビューファイルがレンダリングされることになります。
+[[yii\base\Widget::getViewPath()]] メソッドをオーバーライドして、ウィジェットのビューファイルを含むディレクトリをカスタマイズすることが出来ます。
 
 
 ## 最善の慣行 <a name="best-practices"></a>
 
 ウィジェットはビューのコードを再利用するためのオブジェクト指向の方法です。
 
-ウィジェットを作成するときでも、MVC パターンに従うべきです。一般的に言うと、ロジックはウィジェットクラスに保持し、
-表現は [ビュー](structure-views.md) に保持すべきです。
+ウィジェットを作成するときでも、MVC パターンに従うべきです。
+一般的に言うと、ロジックはウィジェットクラスに保持し、表現は [ビュー](structure-views.md) に保持すべきです。
 
-ウィジェットは自己完結的に設計されるべきです。言い換えると、ウィジェットを使うときに、他に何もしないでも
-ビューに挿入することが出来るようにすべきです。この要求は、ウィジェットが CSS、JavaScript、画像などの外部リソースを必要とする場合は、
-扱いにくい問題になり得ます。幸いなことに、Yii はこの問題を解決するのに利用することが出来る [アセットバンドル](structure-assets.md)
-のサポートを提供しています。
+ウィジェットは自己完結的に設計されるべきです。
+言い換えると、ウィジェットを使うときに、他に何もしないでもビューに挿入することが出来るようにすべきです。
+この要求は、ウィジェットが CSS、JavaScript、画像などの外部リソースを必要とする場合は、扱いにくい問題になり得ます。
+幸いなことに、Yii はこの問題を解決するのに利用することが出来る [アセットバンドル](structure-assets.md) のサポートを提供しています。
 
-ウィジェットがビューコードだけを含む場合は、[ビュー](structure-views.md) と非常に似たものになります。実際のところ、この場合、
-両者の唯一の違いは、ウィジェットが再配布可能なクラスである一方で、ビューはアプリケーション内に保持することが望ましい
-素の PHP スクリプトである、というぐらいの事です。
+ウィジェットがビューコードだけを含む場合は、[ビュー](structure-views.md) と非常に似たものになります。
+実際のところ、この場合、両者の唯一の違いは、ウィジェットが再配布可能なクラスである一方で、
+ビューはアプリケーション内に保持することが望ましい素の PHP スクリプトである、というぐらいの事です。