docs/guide-ja updated [ci skip]

docs/guide-ja/concept-autoloading.md

@@ -1,8 +1,8 @@
 クラスのオートローディング
 =================
 
-Yiiは、必要となるすべてのクラスファイルを、特定してインクルードするにあたり、 [クラスのオートローディングメカニズム](http://www.php.net/manual/ja/language.oop5.autoload.php)
-を頼りにします。[PSR-4 標準](https://github.com/php-fig/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader.md) に準拠した、高性能なクラスのオートローダーを提供します。
+Yiiは、必要となるすべてのクラスファイルを特定してインクルードするにあたり、 [クラスのオートローディングメカニズム](http://www.php.net/manual/ja/language.oop5.autoload.php)
+を頼りにします。Yii は、[PSR-4 標準](https://github.com/php-fig/fig-standards/blob/master/proposed/psr-4-autoloader/psr-4-autoloader.md) に準拠した、高性能なクラスのオートローダーを提供しています。
 このオートローダーは、あなたが `Yii.php` ファイルをインクルードするときにインストールされます。
 
 > 補足: 説明を簡単にするため、このセクションではクラスのオートローディングについてのみお話しします。しかし、
@@ -14,24 +14,24 @@ Yii オートローダーの使用 <span id="using-yii-autoloader"></span>
 
 Yii のクラスオートローダーを使用するには、自分のクラスを作成して名前を付けるとき、次の2つの単純なルールに従わなければなりません:
 
-* 各クラスは名前空間の下になければなりません (例 `foo\bar\MyClass`)
+* 各クラスは [名前空間](http://php.net/manual/ja/language.namespaces.php) の下になければなりません (例 `foo\bar\MyClass`)
 * 各クラスは次のアルゴリズムで決定される個別のファイルに保存されなければなりません:
 
 ```php
-// $className は先頭にバックスラッシュを持つ完全修飾名
+// $className は先頭にバックスラッシュを持たない完全修飾クラス名
 $classFile = Yii::getAlias('@' . str_replace('\\', '/', $className) . '.php');
 ```
 たとえば、クラス名と名前空間が `foo\bar\MyClass` であれば、対応するクラスファイルのパスの [エイリアス](concept-aliases.md) は、
-`@foo/bar/MyClass.php` になります。このエイリアスがファイルパスになるようにするには、`@foo` または `@foo/bar`
+`@foo/bar/MyClass.php` になります。このエイリアスがファイルパスとして解決できるようにするためには、`@foo` または `@foo/bar`
 のどちらかが、 [ルートエイリアス](concept-aliases.md#defining-aliases) でなければなりません。
 
-[ベーシックプロジェクトテンプレート](start-basic.md) を使用している場合、最上位の名前空間 `app` の下にクラスを置くことができ、
+[ベーシックプロジェクトテンプレート](start-installation.md) を使用している場合、最上位の名前空間 `app` の下にクラスを置くことができ、
 そうすると、新しいエイリアスを定義しなくても、Yii によってそれらをオートロードできるようになります。これは `@app`
 が [事前定義されたエイリアス](concept-aliases.md#predefined-aliases) であるためで、`app\components\MyClass` のようなクラス名を
-今説明したアルゴリズムに従って、クラスファイル `AppBasePath/components/MyClass.php` だと解決できるのです。
+今説明したアルゴリズムに従って、クラスファイル `AppBasePath/components/MyClass.php` であると解決することが出来ます。
 
-[アドバンストプロジェクトテンプレート](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/README.md) では、各階層にそれ自身のルートエイリアスを持っています。たとえば、
-フロントエンド層はルートエイリアス `@frontend` を持ち、バックエンド層は `@backend` です。その結果、名前空間 `frontend` の下に
+[アドバンストプロジェクトテンプレート](https://github.com/yiisoft/yii2-app-advanced/blob/master/docs/guide-ja/README.md) では、各層がそれ自身のルートエイリアスを持っています。たとえば、
+フロントエンド層はルートエイリアス `@frontend` を持ち、バックエンド層のルートエイリアスは `@backend` です。その結果、名前空間 `frontend` の下に
 フロントエンドクラスを置き、バックエンドクラスを `backend` の下に置けます。これで、これらのクラスは Yii のオートローダーによって
 オートロードできるようになります。
 
@@ -62,7 +62,7 @@ Yii はパッケージ依存関係マネージャとして Composer を包含し
 
 Yii オートローダーを他のオートローダーと一緒に使うときは、他のすべてのオートローダーがインストールされた *後で* 、 `Yii.php`
 ファイルをインクルードする必要があります。これで Yii のオートローダーが、任意クラスのオートローディング要求に応答する最初のものになります。
-たとえば、次のコードは [Basic Application Template](start-basic.md) の [エントリスクリプト](structure-entry-scripts.md) から抜粋したものです。
+たとえば、次のコードは [ベーシックプロジェクトテンプレート](start-installation.md) の [エントリスクリプト](structure-entry-scripts.md) から抜粋したものです。
 最初の行は、Composer のオートローダーをインストールしており、二行目は Yii のオートローダーをインストールしています。
 
 ```php
@@ -73,7 +73,7 @@ require(__DIR__ . '/../vendor/yiisoft/yii2/Yii.php');
 あなたは Yii のオートローダーを使わず、Composer のオートローダーだけを単独で使用することもできます。しかし、そうすることによって、
 あなたのクラスのオートローディングのパフォーマンスは低下し、クラスをオートロード可能にするために Composer が設定したルールに従わなければならなくなります。
 
-> Info: Yiiのオートローダーを使用したくない場合は、 `Yii.php` ファイルの独自のバージョンを作成し、
+> Info: Yiiのオートローダーを使用したくない場合は、 `Yii.php` ファイルのあなた独自のバージョンを作成し、
   それを [エントリスクリプト](structure-entry-scripts.md) でインクルードする必要があります。
 
 
@@ -84,5 +84,4 @@ Yii のオートローダーは、 [エクステンション](structure-extensio
 エクステンションがその `composer.json` ファイルに正しく `autoload` セクションを指定していることです。
 `autoload` 指定方法の詳細については [Composer のドキュメント](https://getcomposer.org/doc/04-schema.md#autoload) 参照してください。
 
-Yii のオートローダーを使用しない場合でも、まだ Composer のオートローダーはエクステンションクラスをオートロード可能です。
-
+Yii のオートローダーを使用しない場合でも、まだ Composer のオートローダーがエクステンションクラスをオートロードすることが可能です。

docs/guide-ja/concept-di-container.md

@@ -325,8 +325,8 @@ class HotelController extends Controller
 }
 ```
 
-あなたがブラウザからこのコントローラにアクセスすると、 `BookingInterface` をインスタンス化できませんという
-不具合報告エラーが表示されるでしょう。これは、この依存関係に対処する方法を DI コンテナに教える必要があるからです:
+あなたがブラウザからこのコントローラにアクセスすると、 `BookingInterface` をインスタンス化できない、という不平を言う
+エラーが表示されるでしょう。これは、この依存関係に対処する方法を DI コンテナに教える必要があるからです:
 
 ```php
 \Yii::$container->set('app\components\BookingInterface', 'app\components\BookingService');

docs/guide-ja/concept-events.md

@@ -4,7 +4,7 @@
 イベントを使うと、既存のコードの特定の実行ポイントに、カスタムコードを挿入することができます。イベントにカスタムコードを添付すると、
 イベントがトリガされたときにコードが自動的に実行されます。たとえば、メーラーオブジェクトがメッセージを正しく送信できたとき、
 `messageSent` イベントをトリガするとします。もしメッセージの送信がうまく行ったことを知りたければ、単に `messageSent`
-イベントにトラッキングコードを付与すするだけで、それが可能になります。
+イベントにトラッキングコードを付与するだけで、それが可能になります。
 
 Yiiはイベントをサポートするために、 [[yii\base\Component]] と呼ばれる基底クラスを導入してします。クラスがイベントをトリガする必要がある場合は、
 [[yii\base\Component]] もしくはその子クラスを継承する必要があります。
@@ -16,10 +16,10 @@ Yiiはイベントをサポートするために、 [[yii\base\Component]] と
 イベントハンドラとは、関連するイベントがトリガされたときに実行される、 [PHP コールバック](http://www.php.net/manual/ja/language.types.callable.php)
 です。次のコールバックのいずれも使用可能です:
 
-- 文字列で指定されたグローバル PHP 関数 (括弧を除く) `'trim'` など
-- オブジェクトとメソッド名文字列の配列で指定された、オブジェクトのメソッド (括弧を除く) `[$object, 'methodName']` など
-- クラス名文字列とメソッド名文字列の配列で指定された、静的なクラスメソッド (括弧を除く) `['ClassName', 'methodName']` など
-- 無名関数 `function ($event) { ... }` など
+- 文字列で指定されたグローバル PHP 関数 (括弧を除く)、例えば `'trim'`。
+- オブジェクトとメソッド名文字列の配列で指定された、オブジェクトのメソッド (括弧を除く)、例えば `[$object, 'methodName']`。
+- クラス名文字列とメソッド名文字列の配列で指定された、静的なクラスメソッド (括弧を除く)、例えば `['ClassName', 'methodName']`。
+- 無名関数、例えば `function ($event) { ... }`。
 
 イベントハンドラのシグネチャはこのようになります:
 

docs/guide-ja/db-active-record.md

@@ -190,7 +190,7 @@ $customer = Customer::findOne([
 
 // アクティブでない全ての顧客を返す
 // SELECT * FROM `customer` WHERE `status` = 0
-$customer = Customer::findAll([
+$customers = Customer::findAll([
     'status' => Customer::STATUS_INACTIVE,
 ]);
 ```

docs/guide-ja/rest-authentication.md

@@ -30,14 +30,14 @@ Yii は上記の全ての認証方法をサポートしています。新しい
 その代りに、すべてのリクエストに対して認証が実行されます。このことは、ステップ 2 と 3 によって達成されます。
 
 > Tip|情報: RESTful API をアプリケーションの形式で開発する場合は、アプリケーションの構成情報で `user` アプリケーションコンポーネント(structure-application-components.md) の [[yii\web\User::enableSession|enableSession]] プロパティを構成することが出来ます。
-  RESTful API をモジュールとして開発する場合は、次のように、モジュールの `init()` メソッドに一行を追加することが出来ます。
+> RESTful API をモジュールとして開発する場合は、次のように、モジュールの `init()` メソッドに一行を追加することが出来ます。
 > ```php
-public function init()
-{
-    parent::init();
-    \Yii::$app->user->enableSession = false;
-}
-```
+> public function init()
+> {
+>     parent::init();
+>     \Yii::$app->user->enableSession = false;
+> }
+> ```
 
 例えば、HTTP Basic 認証を使う場合は、`authenticator` ビヘイビアを次のように構成することが出来ます。
 

docs/guide-ja/runtime-requests.md

@@ -64,10 +64,10 @@ $param = $request->getBodyParam('id');
 ```php
 $request = Yii::$app->request;
 
-if ($request->isAjax) { // リクエストは AJAX リクエスト }
-if ($request->isGet)  { // リクエストメソッドは GET }
-if ($request->isPost) { // リクエストメソッドは POST }
-if ($request->isPut)  { // リクエストメソッドは PUT }
+if ($request->isAjax) { /* リクエストは AJAX リクエスト */ }
+if ($request->isGet)  { /* リクエストメソッドは GET */ }
+if ($request->isPost) { /* リクエストメソッドは POST */ }
+if ($request->isPut)  { /* リクエストメソッドは PUT */ }
 ```
 
 ## リクエストの URL <span id="request-urls"></span>
@@ -99,7 +99,7 @@ $headers = Yii::$app->request->headers;
 // Accept ヘッダの値を返す
 $accept = $headers->get('Accept');
 
-if ($headers->has('User-Agent')) { // User-Agent ヘッダが在る }
+if ($headers->has('User-Agent')) { /* User-Agent ヘッダが在る */ }
 ```
 
 `request` コンポーネントは、よく使用されるいくつかのヘッダにすばやくアクセスする方法を提供しています。

docs/guide-ja/security-authorization.md

@@ -1,8 +1,6 @@
 権限付与
 ========
 
-> Note|注意: この節はまだ執筆中です。
-
 権限付与は、ユーザが何かをするのに十分な許可を有しているか否かを確認するプロセスです。
 Yii は二つの権限付与の方法を提供しています。すなわち、アクセス制御フィルタ (ACF) と、ロールベースアクセス制御 (RBAC) です。
 
@@ -10,13 +8,14 @@ Yii は二つの権限付与の方法を提供しています。すなわち、
 アクセス制御フィルタ (ACF)
 --------------------------
 
-アクセス制御フィルタ (ACF) は、何らかの単純なアクセス制御だけを必要とするアプリケーションで使うのに最も適した、単純な権限付与の方法です。
-その名前が示すように、ACF は、コントローラまたはモジュールにビヘイビアとしてアタッチすることが出来るアクションフィルタです。
-ACF は一連の [[yii\filters\AccessControl::rules|アクセス規則]] をチェックして、現在のユーザがリクエストしたアクションにアクセスすることが出来るかどうかを確認します。
+アクセス制御フィルタ (ACF) は、[[yii\filters\AccessControl]] として実装される単純な権限付与の方法であり、何らかの単純なアクセス制御だけを必要とするアプリケーションで使うのに最も適したものです。
+その名前が示すように、ACF は、コントローラまたはモジュールで使用することが出来るアクション [フィルタ](structure-filters.md) です。
+ACF は、ユーザがアクションの実行をリクエストしたときに、一連の [[yii\filters\AccessControl::rules|アクセス規則]] をチェックして、現在のユーザがそのアクションにアクセスする許可を持つかどうかを決定します。
 
-下記のコードは、[[yii\filters\AccessControl]] として実装された ACF の使い方を示すものです。
+下記のコードは、`site` コントローラで ACF を使う方法を示すものです。
 
 ```php
+use yii\web\Controller;
 use yii\filters\AccessControl;
 
 class SiteController extends Controller
@@ -49,28 +48,29 @@ class SiteController extends Controller
 上記のコードにおいて、ACF は `site` コントローラにビヘイビアとしてアタッチされています。
 これがアクションフィルタを使用する典型的な方法です。
 `only` オプションは、ACF が `login`、`logout`、`signup` のアクションにのみ適用されるべきであることを指定しています。
+`site` コントローラの他の全てのアクションには ACF の影響は及びません。
 `rules` オプションは [[yii\filters\AccessRule|アクセス規則]] を指定するものであり、以下のように読むことが出来ます。
 
 - 全てのゲストユーザ (まだ認証されていないユーザ) に、'login' と 'singup' のアクションにアクセスすることを許可します。
-  `roles` オプションに疑問符 `?` が含まれていますが、これは「ゲスト」として認識される特殊なトークンです。
+  `roles` オプションに疑問符 `?` が含まれていますが、これは「ゲスト」を表す特殊なトークンです。
 - 認証されたユーザに、'logout' アクションにアクセスすることを許可します。
-  `@` という文字はもう一つの特殊なトークンで、認証されたユーザとして認識されるものです。
+  `@` という文字はもう一つの特殊なトークンで、「認証されたユーザ」を表すものです。
 
 ACF が権限のチェックを実行するときには、規則を一つずつ上から下へ、適用されるものを見つけるまで調べます。
 そして、適用される規則の `allow` の値が、ユーザが権限を有するか否かを判断するのに使われます。
 適用される規則が一つもなかった場合は、ユーザが権限をもたないことを意味し、ACF はアクションの継続を中止します。
 
-デフォルトでは、ユーザが現在のアクションにアクセスする権限を持っていないと判定した場合は、ACF は以下のことだけを行います。
+ユーザが現在のアクションにアクセスする権限を持っていないと判定した場合は、デフォルトでは、ACF は以下の手段を取ります。
 
-* ユーザがゲストである場合は、[[yii\web\User::loginRequired()]] を呼び出します。
-  このメソッドで、ブラウザをログインページにリダイレクトすることが出来ます。
+* ユーザがゲストである場合は、[[yii\web\User::loginRequired()]] を呼び出して、ユーザのブラウザをログインページにリダイレクトします。
 * ユーザが既に認証されている場合は、[[yii\web\ForbiddenHttpException]] を投げます。
 
-この動作は、[[yii\filters\AccessControl::denyCallback]] プロパティを構成することによって、カスタマイズすることが出来ます。
+この動作は、次のように、[[yii\filters\AccessControl::denyCallback]] プロパティを構成することによって、カスタマイズすることが出来ます。
 
 ```php
 [
     'class' => AccessControl::className(),
+    ...
     'denyCallback' => function ($rule, $action) {
         throw new \Exception('このページにアクセスする権限がありません。');
     }
@@ -100,7 +100,7 @@ ACF が権限のチェックを実行するときには、規則を一つずつ
     - `?`: ゲストユーザ (まだ認証されていないユーザ) を意味します。
     - `@`: 認証されたユーザを意味します。
 
-   その他のロール名を使う場合には、RBAC (次の節で説明します) が必要とされ、判断のために [[yii\web\User::can()]] が呼び出されます。
+   その他のロール名を使うと、[[yii\web\User::can()]] の呼び出しが惹起されますが、そのためには、RBAC (次の節で説明します) を有効にする必要があります。
    このオプションが空であるか指定されていない場合は、規則が全てのロールに適用されることを意味します。
 
  * [[yii\filters\AccessRule::ips|ips]]: どの [[yii\web\Request::userIP|クライアントの IP アドレス]] にこの規則が適用されるかを指定します。
@@ -151,8 +151,7 @@ class SiteController extends Controller
 ```
 
 
-ロールベースアクセス制御 (RBAC)
----------------------------------------
+## ロールベースアクセス制御 (RBAC) <span id="rbac"></span>
 
 ロールベースアクセス制御 (RBAC) は、単純でありながら強力な集中型のアクセス制御を提供します。
 RBAC と他のもっと伝統的なアクセス制御スキーマとの比較に関する詳細については、[Wiki 記事](http://ja.wikipedia.org/wiki/%E3%83%AD%E3%83%BC%E3%83%AB%E3%83%99%E3%83%BC%E3%82%B9%E3%82%A2%E3%82%AF%E3%82%BB%E3%82%B9%E5%88%B6%E5%BE%A1) を参照してください。
@@ -166,7 +165,7 @@ RBAC を使用することには、二つの作業が含まれます。
 説明を容易にするために、まず、いくつかの基本的な RBAC の概念を導入します。
 
 
-### 基本的な概念
+### 基本的な概念 <span id="basic-concepts"></span>
 
 ロール (役割) は、*許可* (例えば、記事を作成する、記事を更新するなど) のコレクションです。
 一つのロールを一人または複数のユーザに割り当てることが出来ます。
@@ -183,14 +182,14 @@ Yii は、一般的な *半順序* 階層を実装していますが、これは
 ロールは許可を含むことが出来ますが、許可はロールを含むことが出来ません。
 
 
-### RBAC マネージャを構成する
+### RBAC を構成する <span id="configuring-rbac"></span>
 
 権限付与データを定義してアクセスチェックを実行する前に、[[yii\base\Application::authManager|authManager]] アプリケーションコンポーネントを構成する必要があります。
 Yii は二種類の権限付与マネージャを提供しています。すなわち、[[yii\rbac\PhpManager]] と [[yii\rbac\DbManager]] です。
 前者は権限付与データを保存するのに PHP スクリプトファイルを使いますが、後者は権限付与データをデータベースに保存します。
 あなたのアプリケーションが非常に動的なロールと許可の管理を必要とするのでなければ、前者を使うことを考慮するのが良いでしょう。
 
-#### authManager を `PhpManager` で構成する
+#### `PhpManager` を使用する <span id="using-php-manager"></span>
 
 次のコードは、アプリケーションの構成情報で [[yii\rbac\PhpManager]] クラスを使って `authManager` を構成する方法を示すものです。
 
@@ -208,10 +207,10 @@ return [
 
 これで `authManager` は `\Yii::$app->authManager` によってアクセスすることが出来るようになります。
 
-> Tip|ヒント: デフォルトでは、[[yii\rbac\PhpManager]] は RBAC データを `@app/rbac/` ディレクトリの下のファイルに保存します。
-  権限の階層をオンラインで変更する必要がある場合は、必ず、ウェブサーバのプロセスがこのディレクトリとその中の全てのファイルに対する書き込み権限を有するようにしてください。
+デフォルトでは、[[yii\rbac\PhpManager]] は RBAC データを `@app/rbac/` ディレクトリの下のファイルに保存します。
+権限の階層をオンラインで変更する必要がある場合は、必ず、ウェブサーバのプロセスがこのディレクトリとその中の全てのファイルに対する書き込み権限を有するようにしてください。
 
-#### authManager を `DbManager` で構成する
+#### `DbManager` を使用する <span id="using-db-manager"></span>
 
 次のコードは、アプリケーションの構成情報で [[yii\rbac\DbManager]] クラスを使って `authManager` を構成する方法を示すものです。
 
@@ -243,7 +242,7 @@ return [
 これで `authManager` は `\Yii::$app->authManager` によってアクセスすることが出来るようになります。
 
 
-### 権限付与データを構築する
+### 権限付与データを構築する <span id="generating-rbac-data"></span>
 
 権限付与データを構築する作業は、つまるところ、以下のタスクに他なりません。
 
@@ -335,7 +334,7 @@ public function signup()
 動的に更新される権限付与データを持つ複雑なアクセス制御を必要とするアプリケーションについては、`authManager` が提供する API を使って、特別なユーザインタフェイス (つまり、管理パネル) を開発する必要があるでしょう。
 
 
-### 規則を使う
+### 規則を使う <span id="using-rules"></span>
 
 既に述べたように、規則がロールと許可に制約を追加します。
 規則は [[yii\rbac\Rule]] を拡張したクラスであり、[[yii\rbac\Rule::execute()|execute()]] メソッドを実装しなければなりません。
@@ -394,7 +393,7 @@ $auth->addChild($author, $updateOwnPost);
 
 ![規則を持つ RBAC 階層](images/rbac-hierarchy-2.png "規則を持つ RBAC 階層")
 
-### アクセスチェック
+### アクセスチェック <span id="access-check"></span>
 
 権限付与データが準備できてしまえば、アクセスチェックは [[yii\rbac\ManagerInterface::checkAccess()]] メソッドを呼ぶだけの簡単な仕事です。
 たいていのアクセスチェックは現在のユーザに関するものですから、Yii は、便利なように、[[yii\web\User::can()]] というショートカットメソッドを提供しています。
@@ -406,7 +405,7 @@ if (\Yii::$app->user->can('createPost')) {
 }
 ```
 
-現在のユーザが ID=1 である Jane であるとすると、`createPost` からスタートして `Jane` まで到達しようと試みます。
+現在のユーザが `ID=1` である Jane であるとすると、`createPost` からスタートして `Jane` まで到達しようと試みます。
 
 ![アクセスチェック](images/rbac-access-check-1.png "アクセスチェック")
 
@@ -431,7 +430,7 @@ Jane の場合は、彼女が管理者であるため、少し簡単になりま
 
 ![アクセスチェック](images/rbac-access-check-3.png "アクセスチェック")
 
-### デフォルトロールを使う
+### デフォルトロールを使う <span id="using-default-roles"></span>
 
 デフォルトロールというのは、*全て* のユーザに *黙示的* に割り当てられるロールです。
 [[yii\rbac\ManagerInterface::assign()]] を呼び出す必要はなく、権限付与データはその割り当て情報を含みません。

docs/guide-ja/security-best-practices.md

@@ -136,12 +136,18 @@ CSRF は、クロスサイトリクエストフォージェリ (cross-site reque
 
 例えば、`an.example.com` というウェブサイトが `/logout` という URL を持っており、この URL を単純な GET でアクセスするとユーザをログアウトさせるようになっているとします。
 ユーザ自身によってこの URL がリクエストされる限りは何も問題はありませんが、ある日、悪い奴が、ユーザが頻繁に訪れるフォーラムに `<img src="http://an.example.com/logout">` というリンクを含むコンテントを何とかして投稿することに成功します。
-ブラウザは画像のリクエストとページのリクエストの間に何ら区別を付けませんので、ユーザがそのような `img` タグを含むページを開くと `an.example.com` からログアウトされてしまうことになる訳です。
+ブラウザは画像のリクエストとページのリクエストの間に何ら区別を付けませんので、ユーザがそのような `img` タグを含むページを開くとブラウザはその URL に対して GET リクエストを送信します。
+そして、ユーザが `an.example.com` からログアウトされてしまうことになる訳です。
 
 これは基本的な考え方です。ユーザがログアウトされるぐらいは大したことではない、と言うことも出来るでしょう。
-しかし、POST を送信することも、それほど難しくはありません。
-
-CSRF を回避するためには、次のことを守らなければなりません。
+しかし、悪い奴は、この考え方を使って、もっとひどいことをすることも出来ます。
+例えば、`http://an.example.com/purse/transfer?to=anotherUser&amout=2000` という URL を持つウェブサイトがあると考えて見てください。
+この URL に GET リクエストを使ってアクセスすると、権限を持つユーザアカウントから `anotherUser` に $2000 が送金されるのです。
+私たちは、ブラウザは画像をロードするのに常に GET リクエストを使う、ということを知っていますから、この URL が POST リクエストだけを受け入れるようにコードを修正することは出来ます。
+しかし残念なことに、それで問題が解決する訳ではありません。
+攻撃者は `<img>` タグの代りに何らかの JavaScript コードを書いて、その URL に対する POST リクエストの送信を可能にすることが出来ます。
+
+CSRF を回避するためには、常に次のことを守らなければなりません。
 
 1. HTTP の規格、すなわち、GET はアプリケーションの状態を変更すべきではない、という規則に従うこと。
 2. Yii の CSRF 保護を有効にしておくこと。

docs/guide-ja/structure-applications.md

@@ -2,7 +2,8 @@
 ================
 
 アプリケーションは Yii アプリケーションシステム全体の構造とライフサイクルを統制するオブジェクトです。
-全ての Yii アプリケーションシステムは、それぞれ、[エントリスクリプト](structure-entry-scripts.md) において作成され、`\Yii::$app` という式でグローバルにアクセス可能な、単一のアプリケーションオブジェクトを持ちます。
+全ての Yii アプリケーションシステムは、それぞれ、単一のアプリケーションオブジェクトを持ちます。
+アプリケーションオブジェクトは、[エントリスクリプト](structure-entry-scripts.md) において作成され、`\Yii::$app` という式でグローバルにアクセスすることが出来るオブジェクトです。
 
 > Info|情報: ガイドの中で「アプリケーション」という言葉は、文脈に応じて、アプリケーションオブジェクトを意味したり、アプリケーションシステムを意味したりします。
 

docs/guide-ja/structure-controllers.md

@@ -119,20 +119,20 @@ class SiteController extends Controller
 
 ### コントローラクラスの命名規則 <span id="controller-class-naming"></span>
 
-コントローラクラスの名前は下記の規則に従ってコントローラ ID から導出することが出来ます。
+コントローラクラスの名前は下記の手順に従ってコントローラ ID から導出することが出来ます。
 
-* ダッシュで区切られた各単語の最初の文字を大文字に変える。
-  コントローラ ID がスラッシュを含む場合、この規則は ID の最後のスラッシュの後ろの部分にのみ適用されることに注意。
-* ダッシュを削除し、フォワードスラッシュを全てバックワードスラッシュに置き換える。
-* 接尾辞 `Controller` を追加する。
-* そして、[[yii\base\Application::controllerNamespace|コントローラ名前空間]] を頭に付ける。
+1. ハイフンで区切られた各単語の最初の文字を大文字に変える。
+   コントローラ ID がスラッシュを含む場合、この規則は ID の最後のスラッシュの後ろの部分にのみ適用されることに注意。
+2. ハイフンを削除し、フォワードスラッシュを全てバックワードスラッシュに置き換える。
+3. 接尾辞 `Controller` を追加する。
+4. [[yii\base\Application::controllerNamespace|コントローラ名前空間]] を頭に付ける。
 
 以下は、[[yii\base\Application::controllerNamespace|コントローラ名前空間]] がデフォルト値 `app\controllers` を取っていると仮定したときの、いくつかの例です。
 
-* `article` から `app\controllers\ArticleController` が導出される。
-* `post-comment` から `app\controllers\PostCommentController` が導出される。
-* `admin/post-comment` から `app\controllers\admin\PostCommentController` が導出される。
-* `adminPanels/post-comment` から `app\controllers\adminPanels\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` であるファイルに保存されるべきものとなります。
@@ -213,8 +213,8 @@ class SiteController extends Controller
 アクションは、たいてい、あるリソースについて特定の操作を実行するように設計されます。
 この理由により、アクション ID は、通常、`view`、`update` などのような動詞になります。
 
-デフォルトでは、アクション ID は、小文字の英字、数字、アンダースコア、そして、ダッシュのみを含むべきものです。
-アクション ID の中のダッシュは単語を分けるために使われます。
+デフォルトでは、アクション ID は、小文字の英字、数字、アンダースコア、そして、ハイフンのみを含むべきものです。
+アクション ID の中のハイフンは単語を分けるために使われます。
 例えば、`view`、`update2`、`comment-post` は全て有効なアクション ID ですが、`view?`、`Update` はそうではありません。
 
 アクションは二つの方法、すなわち、インラインアクションまたはスタンドアロンアクションとして作成することが出来ます。
@@ -227,11 +227,11 @@ class SiteController extends Controller
 
 インラインアクションは、たった今説明したように、アクションメソッドの形で定義されるアクションを指します。
 
-アクションメソッドの名前は、次の基準に従って、アクション ID から導出されます。
+アクションメソッドの名前は、次の手順に従って、アクション ID から導出されます。
 
-* アクション ID に含まれる各単語の最初の文字を大文字に変換する。
-* ダッシュを削除する。
-* 接頭辞 `action` を付ける。
+1. アクション ID に含まれる各単語の最初の文字を大文字に変換する。
+2. ハイフンを削除する。
+3. 接頭辞 `action` を付ける。
 
 例えば、`index` は `actionIndex` となり、`hello-world` は `actionHelloWorld` となります。
 
@@ -397,10 +397,10 @@ class SiteController extends Controller
    * アクション ID に合致するアクションメソッドが見つかった場合は、インラインアクションが作成される。
    * 上記以外の場合は、[[yii\base\InvalidRouteException]] 例外が投げられる。
 3. コントローラは、アプリケーション、(コントローラがモジュールに属する場合は) モジュール、そしてコントローラの `beforeAction()` メソッドをこの順で呼び出す。
-   * どれか一つの呼び出しが false を返した場合は、残りのまだ呼ばれていない `beforeAction()` はスキップされ、アクションの実行はキャンセルされる。
+   * どれか一つの呼び出しが false を返した場合は、残りのまだ呼ばれていない `beforeAction()` メソッドはスキップされ、アクションの実行はキャンセルされる。
    * デフォルトでは、それぞれの `beforeAction()` メソッドは、ハンドラをアタッチすることが可能な `beforeAction` イベントをトリガする。
 4. コントローラがアクションを実行する。
-   * リクエストデータが解析されて、アクションパラメータにデータが投入される。
+   * アクションパラメータが解析されて、リクエストデータからデータが投入される。
 5. コントローラは、コントローラ、(コントローラがモジュールに属する場合は) モジュール、そしてアプリケーションの `afterAction()` メソッドをこの順で呼び出す。
    * デフォルトでは、それぞれの `afterAction()` メソッドは、ハンドラをアタッチすることが可能な `afterAction` イベントをトリガする。
 6. アプリケーションはアクションの結果を受け取り、それを [レスポンス](runtime-responses.md) に割り当てる。
@@ -411,7 +411,7 @@ class SiteController extends Controller
 良く設計されたアプリケーションでは、コントローラはたいてい非常に軽いものになり、それぞれのアクションは数行のコードしか含まないものになります。
 あなたのコントローラが少々複雑になっている場合、そのことは、通常、コントローラをリファクタして、コードの一部を他のクラスに移動すべきことを示すものです。
 
-要約すると、コントローラは、
+いくつかのベストプラクティスを特に挙げるなら、コントローラは、
 
 * [リクエスト](runtime-requests.md) データにアクセスすることが出来ます。
 * リクエストデータを使って [モデル](structure-models.md) や他のサービスコンポーネントのメソッドを呼ぶことが出来ます。

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

@@ -1,7 +1,7 @@
 エントリスクリプト
 ==================
 
-エントリスクリプトは、アプリケーションのブートストラップ過程のチェーンにおける最初の環です。
+エントリスクリプトは、アプリケーションのブートストラップの過程における最初のステップです。
 アプリケーションは (ウェブアプリケーションであれ、コンソールアプリケーションであれ）単一のエントリスクリプトを持ちます。
 エンドユーザはエントリスクリプトに対してリクエストを発行し、エントリスクリプトはアプリケーションのインスタンスを作成して、それにリクエストを送付します。