Merge pull request #7111 from softark/docs-guide-ja-structure-rev

docs/guide-ja/concept-events.md

@@ -274,6 +274,6 @@ Yii::$app->trigger('bar', new Event(['sender' => new Foo]));
 ということです。その代わりに、ハンドラのアタッチとイベントのトリガはともに、(アプリケーションのインスタンスなど) シングルトンを
 介して行われます。
 
-しかし、グローバルイベントの名前空間はあらゆる部分から共有されているので、名前空間の整理 ("frontend.mail.sent"、"backend.mail.sent" など)
+しかし、グローバルイベントの名前空間はあらゆる部分から共有されているので、ある種の名前空間 ("frontend.mail.sent"、"backend.mail.sent" など)
 を導入するというような、賢いグローバルイベントの名前付けをする必要があります。
 

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

@@ -101,7 +101,7 @@ $customer->save();
 ----------------------
 
 アクティブレコードは、データベースとの間でデータを交換するために [[yii\db\Connection|DB 接続]] を使用します。
-既定では、アクティブレコードは `db` [アプリケーションコンポーネント](structure-application-components.md) を接続として使用します。
+デフォルトでは、アクティブレコードは `db` [アプリケーションコンポーネント](structure-application-components.md) を接続として使用します。
 [データベースの基礎](db-dao.md) で説明したように、次のようにして、アプリケーションの構成情報ファイルの中で `db` コンポーネントを構成することが出来ます。
 
 ```php
@@ -726,10 +726,10 @@ $orders = Order::find()->joinWith('books.author')->all();
 [[yii\db\ActiveQuery::joinWith()|joinWith()]] を使うときは、カラム名の曖昧さを解決することについて、あなたが責任を負わなければなりません。
 上記の例では、order テーブルと item テーブルがともに `id` という名前のカラムを持っているため、`item.id` と `order.id` を使って、`id` カラムの参照の曖昧さを解決しています。
 
-既定では、リレーションを結合すると、リレーションがイーガーロードされることにもなります。
-この既定の動作は、指定されたリレーションをイーガーロードするかどうかを規定する `$eagerLoading` パラメータを渡して、変更することが出来ます。
+デフォルトでは、リレーションを結合すると、リレーションがイーガーロードされることにもなります。
+このデフォルトの動作は、指定されたリレーションをイーガーロードするかどうかを規定する `$eagerLoading` パラメータを渡して、変更することが出来ます。
 
-また、既定では、[[yii\db\ActiveQuery::joinWith()|joinWith()]] は関連テーブルを結合するのに `LEFT JOIN` を使います。
+また、デフォルトでは、[[yii\db\ActiveQuery::joinWith()|joinWith()]] は関連テーブルを結合するのに `LEFT JOIN` を使います。
 結合タイプをカスタマイズするために `$joinType` パラメータを渡すことが出来ます。
 `INNER JOIN` タイプのためのショートカットとして、[[yii\db\ActiveQuery::innerJoinWith()|innerJoinWith()]] を使うことが出来ます。
 
@@ -980,7 +980,7 @@ class Post extends \yii\db\ActiveRecord
 楽観的ロックは、複数のユーザが編集のために同一のレコードにアクセスすることを許容しつつ、発生しうる衝突を回避するものです。
 例えば、ユーザが (別のユーザが先にデータを修正したために) 陳腐化したデータに対してレコードの保存を試みた場合は、[[\yii\db\StaleObjectException]] 例外が投げられて、更新または削除はスキップされます。
 
-楽観的ロックは、`update()` と `delete()` メソッドだけでサポートされ、既定では使用されません。
+楽観的ロックは、`update()` と `delete()` メソッドだけでサポートされ、デフォルトでは使用されません。
 
 楽観的ロックを使用するためには、
 

docs/guide-ja/db-dao.md

@@ -530,7 +530,7 @@ $db->createCommand("UPDATE user SET username='demo' WHERE id=1")->execute();
 
 > Note|注意: [[yii\db\Connection::masters|masters]] プロパティを使って一つまたは複数のマスタを構成する場合は、データベース接続を定義する `Connection` オブジェクト自体のその他のプロパティ (例えば、`dsn`、`username`、`password`) は全て無視されます。
 
-既定では、トランザクションはマスタ接続を使用します。そして、トランザクション内では、全ての DB 操作はマスタ接続を使用します。
+デフォルトでは、トランザクションはマスタ接続を使用します。そして、トランザクション内では、全ての DB 操作はマスタ接続を使用します。
 例えば、
 
 ```php

docs/guide-ja/db-migrations.md

@@ -321,14 +321,14 @@ yii migrate/up --migrationPath=@app/modules/forum/migrations
 
 ### 複数のデータベースのマイグレーション
 
-既定では、マイグレーションは `db` [アプリケーションコンポーネント](structure-application-components.md) によって指定されるデータベースに対して適用されます。
+デフォルトでは、マイグレーションは `db` [アプリケーションコンポーネント](structure-application-components.md) によって指定されるデータベースに対して適用されます。
 これは、`--db` オプションを指定することによって変更することが出来ます。例えば、
 
 ```
 yii migrate --db=db2
 ```
 
-上記のコマンドは、既定のマイグレーションパスに置かれている *全ての* マイグレーションを `db2` データベースに適用するものです。
+上記のコマンドは、デフォルトのマイグレーションパスに置かれている *全ての* マイグレーションを `db2` データベースに適用するものです。
 
 アプリケーションが複数のデータベースを扱っている場合は、いくつかのマイグレーションはあるデータベースに適用されなければならず、他のマイグレーションは別のデータベースに適用されなければならない、ということがあり得ます。
 そのような場合には、異なるデータベースごとに基底マイグレーションクラスを作成して、下記のように [[yii\db\Migration::init()]] メソッドをオーバーライドすることを推奨します。

docs/guide-ja/db-query-builder.md

@@ -445,7 +445,7 @@ foreach ($query->each() as $user) {
 [[yii\db\Query::batch()]] メソッドと [[yii\db\Query::each()]] メソッドは [[yii\db\BatchQueryResult]] オブジェクトを返します。
 このオブジェクトは `Iterator` インタフェイスを実装しており、従って、`foreach` 構文の中で使うことが出来ます。
 初回の反復の際に、データベースに対する SQL クエリが作成されます。データは、その後、反復のたびにバッチモードで取得されます。
-既定では、バッチサイズは 100 であり、各バッチにおいて 100 行のデータが取得されます。
+デフォルトでは、バッチサイズは 100 であり、各バッチにおいて 100 行のデータが取得されます。
 `batch()` または `each()` メソッドに最初のパラメータを渡すことによって、バッチサイズを変更することが出来ます。
 
 [[yii\db\Query::all()]] とは対照的に、バッチクエリは一度に 100 行のデータしかメモリに読み込みません。

docs/guide-ja/helper-overview.md

@@ -4,7 +4,7 @@
 > Note|注意: この節はまだ執筆中です。
 
 Yii は、一般的なコーディングのタスク、例えば、文字列や配列の操作、HTML コードの生成などを手助けする多くのクラスを提供しています。
-これらのヘルパクラスは `yii\helpers` 名前空間の下に組織されており、すべてスタティックなクラス (すなわち、スタティックなプロパティとメソッドのみを含み、インスタンス化すべきでないクラス) です。
+これらのヘルパクラスは `yii\helpers` 名前空間の下に編成されており、すべてスタティックなクラス (すなわち、スタティックなプロパティとメソッドのみを含み、インスタンス化すべきでないクラス) です。
 
 ヘルパクラスは、そのスタティックなメソッドの一つを直接に呼び出すことによって使用します。
 例えば、

docs/guide-ja/input-validation.md

@@ -114,10 +114,10 @@ public function rules()
 
 [[yii\base\Model::validate()]] は、呼び出されると、バリデーションプロセスをカスタマイズするためにオーバーライドできる二つのメソッドを呼び出します。
 
-* [[yii\base\Model::beforeValidate()]]: 既定の実装は [[yii\base\Model::EVENT_BEFORE_VALIDATE]] イベントをトリガするものです。
+* [[yii\base\Model::beforeValidate()]]: デフォルトの実装は [[yii\base\Model::EVENT_BEFORE_VALIDATE]] イベントをトリガするものです。
   このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが実行される前に、何らかの前処理 (例えば入力されたデータの正規化) をすることが出来ます。
   このメソッドは、バリデーションを続行すべきか否かを示す真偽値を返さなくてはなりません。
-* [[yii\base\Model::afterValidate()]]: 既定の実装は [[yii\base\Model::EVENT_AFTER_VALIDATE]] イベントをトリガするものです。
+* [[yii\base\Model::afterValidate()]]: デフォルトの実装は [[yii\base\Model::EVENT_AFTER_VALIDATE]] イベントをトリガするものです。
   このメソッドをオーバーライドするか、または、イベントに反応して、バリデーションが完了した後に、何らかの後処理をすることが出来ます。
 
 
@@ -195,7 +195,7 @@ HTML フォームから入力データが送信されたとき、入力値が空
 ]
 ```
 
-既定では、入力値が空であると見なされるのは、それが、空文字列であるか、空配列であるか、null であるときです。
+デフォルトでは、入力値が空であると見なされるのは、それが、空文字列であるか、空配列であるか、null であるときです。
 空を検知するこのデフォルトのロジックは、[[yii\validators\Validator::isEmpty]] プロパティを PHP コーラブルで構成することによって、カスタマイズすることが出来ます。
 例えば、
 
@@ -330,7 +330,7 @@ class MyForm extends Model
 }
 ```
 
-> Note|注意: 既定では、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかのバリデーション規則に失敗したりしている場合には、適用されません。
+> Note|注意: デフォルトでは、インラインバリデータは、関連付けられている属性が空の入力値を受け取ったり、既に何らかのバリデーション規則に失敗したりしている場合には、適用されません。
 > 規則が常に適用されることを保証したい場合は、規則の宣言において [[yii\validators\Validator::skipOnEmpty|skipOnEmpty]] および/または [[yii\validators\Validator::skipOnError|skipOnError]] のプロパティを false に設定することが出来ます。
 > 例えば、
 >

docs/guide-ja/intro-upgrade-from-v1.md

@@ -273,7 +273,7 @@ ActiveForm::end();
 コンソールアプリケーション
 --------------------------
 
-コンソールアプリケーションは、ウェブアプリケーションと同じように、コントローラとして組織されるようになりました。
+コンソールアプリケーションは、ウェブアプリケーションと同じように、コントローラとして編成されるようになりました。
 1.1 における `CConsoleCommand` と同様に、コンソールコントローラは [[yii\console\Controller]] を拡張したものでなければなりません。
 
 コンソールコマンドを走らせるためには、`yii <route>` という構文を使います。

docs/guide-ja/intro-yii.md

@@ -19,7 +19,7 @@ Yii を他のフレームワークと比べると
 
 あなたが既に他のフレームワークに親しんでいる場合は、Yii を比較するとどうなのかを知りたいでしょう。
 
-- ほとんどの PHP フレームワーク同様、Yii は MVC (Model-View-Controller) デザインパターンを実装し、このパターンに基づいたコードの組織化を推進しています。
+- ほとんどの PHP フレームワーク同様、Yii は MVC (Model-View-Controller) デザインパターンを実装し、このパターンに基づいたコードの編成を推進しています。
 - Yii は、コードはシンプルかつエレガントに書かれるべきである、という哲学を採用しています。
   何らかのデザインパターンの厳密な遵守を主な目的とする凝りすぎた設計を、Yii がしようと試みることは決してありません。
 - Yii はフル装備のフレームワークです。

docs/guide-ja/output-data-widgets.md

@@ -141,7 +141,7 @@ echo GridView::widget([
         'username',
         // 複雑なカラム定義
         [
-            'class' => 'yii\grid\DataColumn', // 省略可。これが既定値。
+            'class' => 'yii\grid\DataColumn', // 省略可。これがデフォルト値。
             'value' => function ($data) {
                 return $data->name; // 配列データの場合は $data['name']。例えば、SqlDataProvider を使う場合。
             },
@@ -388,7 +388,7 @@ echo GridView::widget([
 GridView でアクティブレコードを表示するときに、リレーションのカラムの値、例えば、単に投稿者の `id` というのではなく、投稿者の名前を表示するという場合に遭遇するかも知れません。
 `Post` モデルが `author` という名前のリレーションを持っていて、その投稿者のモデルが `name` という属性を持っているなら、カラムの属性名を `author.name` と定義します。
 そうすれば、GridView が投稿者の名前を表示するようになります。
-ただし、並べ替えとフィルタリングは、既定では有効になりません。
+ただし、並べ替えとフィルタリングは、デフォルトでは有効になりません。
 これらの機能を追加するためには、前の項で導入した `PostSearch` モデルを調整しなければなりません。
 
 リレーションのカラムによる並べ替えを有効にするためには、リレーションのテーブルを結合し、データプロバイダの Sort コンポーネントに並べ替えの規則を追加します。

docs/guide-ja/rest-quick-start.md

@@ -188,7 +188,7 @@ Content-Type: application/json; charset=UTF-8
 ## まとめ <span id="summary"></span>
 
 Yii の RESTful API フレームワークを使う場合は、API エンドポイントをコントローラアクションの形式で実装します。
-そして、コントローラを使って、単一タイプのリソースに対するエンドポイントを実装するアクションを組織化します。
+そして、コントローラを使って、単一タイプのリソースに対するエンドポイントを実装するアクションを編成します。
 
 リソースは [[yii\base\Model]] クラスを拡張するデータモデルとして表現されます。
 データベース (リレーショナルまたは NoSQL) を扱っている場合は、[[yii\db\ActiveRecord|ActiveRecord]] を使ってリソースを表現することが推奨されます。

docs/guide-ja/rest-resources.md

@@ -85,7 +85,7 @@ public function fields()
 }
 ```
 
-> Warning|警告: 既定ではモデルの全ての属性がエクスポートされる配列に含まれるため、データを精査して、
+> Warning|警告: デフォルトではモデルの全ての属性がエクスポートされる配列に含まれるため、データを精査して、
 > 公開すべきでない情報が含まれていないことを確認すべきです。そういう情報がある場合は、
 > `fields()` をオーバーライドして、除去すべきです。上記の例では、`auth_key`、`password_hash`
 > および `password_reset_token` を選んで除去しています。

docs/guide-ja/rest-versioning.md

@@ -34,7 +34,7 @@ Accept: application/vnd.company.myapp-v1+json
 コードの責任範囲をより良く分離するために、共通の基底のリソースとコントローラのクラスを保持して、それをバージョンごとの個別のモジュールでサブクラス化することが出来ます。
 サブクラスの中で、`Model::fields()` のような具体的なコードを実装します。
 
-あなたのコードを次のように組織することが出来ます。
+あなたのコードを次のように編成することが出来ます。
 
 ```
 api/

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

@@ -9,7 +9,7 @@ Yii は、エラー処理を従来よりはるかに快適な経験にしてく
 * エラーを表示するために専用の [コントローラアクション](structure-controllers.md#actions) を使うことがサポートされています。
 * さまざまなエラーレスポンス形式をサポートしています。
 
-[[yii\web\ErrorHandler|エラーハンドラ]] は既定で有効になっています。
+[[yii\web\ErrorHandler|エラーハンドラ]] はデフォルトで有効になっています。
 アプリケーションの [エントリスクリプト](structure-entry-scripts.md) において、定数 `YII_ENABLE_ERROR_HANDLER` を false と定義することによって、これを無効にすることが出来ます。
 
 
@@ -65,7 +65,7 @@ throw new NotFoundHttpException();
 > Info|情報: 例外が [[yii\base\UserException]] の子孫である場合は、`YII_DEBUG` の値の如何にかかわらず、コールスタックは表示されません。
 これは、この種の例外はユーザの誤操作によって引き起こされるものであり、開発者は何も修正する必要がないと考えられるからです。
 
-既定では、[[yii\web\ErrorHandler|エラーハンドラ]] は二つの [ビュー](structure-views.md) を使ってエラーを表示します。
+デフォルトでは、[[yii\web\ErrorHandler|エラーハンドラ]] は二つの [ビュー](structure-views.md) を使ってエラーを表示します。
 
 * `@yii/views/errorHandler/error.php`: エラーがコールスタック情報なしで表示されるべき場合に使用されます。
   `YII_DEBUG` が false の場合、これが表示される唯一のビューとなります。

docs/guide-ja/runtime-logging.md

@@ -32,9 +32,9 @@ Yii::trace('平均収益の計算を開始');
 
 > Info|情報: ログメッセージは文字列でも、配列やオブジェクトのような複雑なデータでも構いません。
 ログメッセージを適切に取り扱うのは [ログターゲット](#log-targets) の責任です。
-既定では、ログメッセージが文字列でない場合は、[[yii\helpers\VarDumper::export()]] が呼ばれて文字列に変換されることになります。
+デフォルトでは、ログメッセージが文字列でない場合は、[[yii\helpers\VarDumper::export()]] が呼ばれて文字列に変換されることになります。
 
-ログメッセージを上手に整理しフィルタするために、すべてのログメッセージにそれぞれ適切なカテゴリを指定することが推奨されます。
+ログメッセージを上手に編成しフィルタするために、すべてのログメッセージにそれぞれ適切なカテゴリを指定することが推奨されます。
 カテゴリに階層的な命名方法を採用すると、[ログターゲット](#log-targets) がカテゴリに基づいてメッセージをフィルタすることが容易になります。
 簡単でしかも効果的な命名方法は、カテゴリ名に PHP のマジック定数 `__METHOD__` を使用することです。
 これは、Yii フレームワークのコアコードでも使われている方法です。例えば、
@@ -168,7 +168,7 @@ Yii は下記のログターゲットをあらかじめ内蔵しています。
 2014-10-04 18:10:15 [::1][][-][trace][yii\base\Module::getModule] Loading module: debug
 ```
 
-既定では、ログメッセージは [[yii\log\Target::formatMessage()]] によって、下記のように書式設定されます。
+デフォルトでは、ログメッセージは [[yii\log\Target::formatMessage()]] によって、下記のように書式設定されます。
 
 ```
 タイムスタンプ [IP アドレス][ユーザ ID][セッション ID][重要性レベル][カテゴリ] メッセージテキスト
@@ -191,7 +191,7 @@ Yii は下記のログターゲットをあらかじめ内蔵しています。
 ```
 
 メッセージ前置情報以外にも、ログターゲットは、一群のログメッセージごとに一定のコンテキスト情報を追加します。
-既定では、その情報には、次のグローバル PHP 変数、すなわち、`$_GET`、`$_POST`、`$_FILES`、`$_COOKIE`、`$_SESSION` および `$_SERVER` の値が含まれます。
+デフォルトでは、その情報には、次のグローバル PHP 変数、すなわち、`$_GET`、`$_POST`、`$_FILES`、`$_COOKIE`、`$_SESSION` および `$_SERVER` の値が含まれます。
 ログターゲットに含ませたいグローバル変数の名前を [[yii\log\Target::logVars]] プロパティに設定することによって、この動作を調整することが出来ます。
 例えば、次のログターゲットの構成は、`$_SERVER` の値だけがログメッセージに追加されるように指定するものです。
 

docs/guide-ja/runtime-requests.md

@@ -2,7 +2,7 @@
 ==========
 
 アプリケーションに対するリクエストは、リクエストのパラメータ、HTTP ヘッダ、クッキーなどの情報を提供する [[yii\web\Request]] オブジェクトの形で表されます。
-与えられたリクエストに対応するリクエストオブジェクトには、既定では [[yii\web\Request]] のインスタンスである `request` [アプリケーションコンポーネント](structure-application-components.md) を通じてアクセスすることが出来ます。
+与えられたリクエストに対応するリクエストオブジェクトには、デフォルトでは [[yii\web\Request]] のインスタンスである `request` [アプリケーションコンポーネント](structure-application-components.md) を通じてアクセスすることが出来ます。
 この節では、アプリケーションの中でこのコンポーネントをどのように利用できるかを説明します。
 
 

docs/guide-ja/runtime-responses.md

@@ -6,7 +6,7 @@
 ウェブアプリケーション開発の最終的な目的は、本質的には、さまざまなリクエストに対してそのようなレスポンスオブジェクトを作成することにあります。
 
 ほとんどの場合は、主として `response` [アプリケーションコンポーネント](structure-application-components.md) を使用すべきです。
-このコンポーネントは、既定では、[[yii\web\Response]] のインスタンスです。
+このコンポーネントは、デフォルトでは、[[yii\web\Response]] のインスタンスです。
 しかしながら、Yii は、以下で説明するように、あなた自身のレスポンスオブジェクトを作成してエンドユーザに送信することも許容しています。
 
 この節では、レスポンスを構成してエンドユーザに送信する方法を説明します。
@@ -23,7 +23,7 @@ Yii::$app->response->statusCode = 200;
 ```
 
 けれども、たいていの場合、ステータスコードを明示的に設定する必要はありません。
-これは、[[yii\web\Response::statusCode]] の既定値が 200 であるからです。
+これは、[[yii\web\Response::statusCode]] のデフォルト値が 200 であるからです。
 そして、リクエストが失敗したことを示したいときは、下記のように、適切な HTTP 例外を投げることが出来ます。
 
 ```php
@@ -183,7 +183,7 @@ public function actionOld()
 \Yii::$app->response->redirect('http://example.com/new', 301)->send();
 ```
 
-> Info|情報: 既定では、[[yii\web\Response::redirect()]] メソッドはレスポンスのステータスコードを 302 にセットします。
+> Info|情報: デフォルトでは、[[yii\web\Response::redirect()]] メソッドはレスポンスのステータスコードを 302 にセットします。
 これはブラウザに対して、リクエストされているリソースが *一時的に* 異なる URI に配置されていることを示すものです。
 ブラウザに対してリソースが *恒久的に* 配置替えされたことを教えるためには、ステータスコード 301 を渡すことが出来ます。
 
@@ -238,7 +238,7 @@ public function actionDownload()
 ## レスポンスを送信する <span id="sending-response"></span>
 
 レスポンスの中のコンテントは、[[yii\web\Response::send()]] メソッドが呼ばれるまでは、エンドユーザに向けて送信されません。
-既定では、このメソッドは [[yii\base\Application::run()]] の最後で自動的に呼ばれます。
+デフォルトでは、このメソッドは [[yii\base\Application::run()]] の最後で自動的に呼ばれます。
 しかし、このメソッドを明示的に呼んで、強制的にレスポンスを即座に送信することも可能です。
 
 [[yii\web\Response::send()]] メソッドは次のステップを踏んでレスポンスを送出します。

docs/guide-ja/runtime-routing.md

@@ -84,7 +84,7 @@ $url = Url::to(['post/view', 'id' => 100]);
 ### デフォルトルート <span id="default-route"></span>
 
 リクエストから解析されたルートが空になった場合は、いわゆる *デフォルトルート* が代りに使用されることになります。
-既定では、デフォルトルートは `site/index` であり、`site` コントローラの `index` アクションを指します。
+デフォルトでは、デフォルトルートは `site/index` であり、`site` コントローラの `index` アクションを指します。
 デフォルトルートは、次のように、アプリケーションの構成情報の中でアプリケーションの [[yii\web\Application::defaultRoute|defaultRoute]] プロパティを構成することによって、カスタマイズすることが出来ます。
 
 ```php
@@ -296,7 +296,7 @@ URL 隕丞援縺ｯ縲√後ヱ繧ｿ繝ｼ繝ｳ - 繝ｫ繝ｼ繝医阪繝壹い縺ｨ縺励※螳｣險縺吶ｋ莉･
 ]
 ```
 
-規則の構成情報で `class` を指定しない場合は、既定として、[[yii\web\UrlRule]] が使われます。
+規則の構成情報で `class` を指定しない場合は、デフォルトとして、[[yii\web\UrlRule]] が使われます。
 
 
 ### 名前付きパラメータ <span id="named-parameters"></span>
@@ -327,7 +327,7 @@ URL 隕丞援縺ｯ縲√ヱ繧ｿ繝ｼ繝ｳ縺ｮ荳ｭ縺ｧ `<ParamName:RgExp>` 縺ｮ蠖｢蠑上〒謖ｮ壹＆
 - `/index.php/posts/2014/php` は、最初の規則を使って解析され、ルートは `post/index`、`year` パラメータの値は 2014、そして、`category` パラメータの値は `php` となります。
 - `/index.php/post/100` は、三番目の規則を使って解析され、ルートが `post/view`、`id` パラメータの値が 100 となります。
 - `/index.php/posts/php` は、どのパターンにも合致しないため、[[yii\web\UrlManager::enableStrictParsing]] が true の場合は、[[yii\web\NotFoundHttpException]] を引き起こします。
-  [[yii\web\UrlManager::enableStrictParsing]] が false (これが既定値です) の場合は、パス情報の部分である `posts/php` がルートとして返されることになります。
+  [[yii\web\UrlManager::enableStrictParsing]] が false (これがデフォルト値です) の場合は、パス情報の部分である `posts/php` がルートとして返されることになります。
  
 規則が URL 生成に使われる場合は、
 
@@ -360,7 +360,7 @@ URL 隕丞援縺ｮ繝ｫ繝ｼ繝医↓縺ｯ繝代Λ繝｡繝ｼ繧ｿ蜷阪ｒ蝓九ａ霎ｼ繧縺薙→縺悟譚･縺ｾ
 
 > Info|情報: ルートをパラメータ化することによって、URL 規則の数を大幅に減らすことが可能になり、[[yii\web\UrlManager|URL マネージャ]] のパフォーマンスを目に見えて改善することが出来ます。
   
-既定では、規則の中で宣言されたパラメータは必須となります。
+デフォルトでは、規則の中で宣言されたパラメータは必須となります。
 リクエストされた URL が特定のパラメータを含まない場合や、URL が特定のパラメータなしで生成される場合には、規則は適用されません。
 パラメータのどれかをオプション扱いにしたい場合は、規則の [[yii\web\UrlRule::defaults|defaults]] プロパティを構成することが出来ます。
 このプロパティのリストに挙げられたパラメータはオプション扱いとなり、規定されなかった場合は指定された値を取るようになります。
@@ -516,7 +516,7 @@ RESTful API 繧貞ｮ溯｣☆繧九→縺阪縲∽ｽｿ逕ｨ縺輔ｌ縺ｦ縺ｋ HTTP 繝｡繧ｽ繝ラ縺
 ]
 ```
 
-> Info|情報: 規則の構成情報で `class` を指定しない場合は、既定として、[[yii\web\UrlRule]] クラスが使われます。
+> Info|情報: 規則の構成情報で `class` を指定しない場合は、デフォルトとして、[[yii\web\UrlRule]] クラスが使われます。
   
 
 ### 規則を動的に追加する <span id="adding-rules"></span>

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

@@ -8,7 +8,7 @@ Yii 縺ｯ繧ｻ繝す繝ｧ繝ｳ縺ｨ繧ｯ繝く繝ｼ繧偵が繝悶ず繧ｧ繧ｯ繝医→縺励※繧ｫ繝励そ繝ｫ
 
 ## セッション <span id="sessions"></span>
 
-[リクエスト](runtime-requests.md) や [レスポンス](runtime-responses.md) と同じように、既定では [[yii\web\Session]] のインスタンスである `session` [アプリケーションコンポーネント] によって、セッションにアクセスすることが出来ます。
+[リクエスト](runtime-requests.md) や [レスポンス](runtime-responses.md) と同じように、デフォルトでは [[yii\web\Session]] のインスタンスである `session` [アプリケーションコンポーネント] によって、セッションにアクセスすることが出来ます。
 
 
 ### セッションのオープンとクローズ <span id="opening-closing-sessions"></span>
@@ -121,7 +121,7 @@ $session['captcha.lifetime'] = 3600;
 
 ### カスタムセッションストレージ <span id="custom-session-storage"></span>
 
-既定の [[yii\web\Session]] クラスはセッションデータをサーバ上のファイルとして保存します。
+デフォルトの [[yii\web\Session]] クラスはセッションデータをサーバ上のファイルとして保存します。
 Yii は、また、さまざまなセッションストレージを実装する下記のクラスをも提供しています。
 
 * [[yii\web\DbSession]]: セッションデータをデータベーステーブルを使って保存する。

docs/guide-ja/start-gii.md

@@ -44,7 +44,7 @@ defined('YII_ENV') or define('YII_ENV', 'dev');
 http://hostname/index.php?r=gii
 ```
 
-> Note|注意: ローカルホスト以外のマシンから Gii にアクセスしようとすると、既定ではセキュリティ上の理由でアクセスが拒否されます。
+> Note|注意: ローカルホスト以外のマシンから Gii にアクセスしようとすると、デフォルトではセキュリティ上の理由でアクセスが拒否されます。
 > 下記のように Gii を構成して、許可される IP アドレスを追加することが出来ます。
 >
 ```php

docs/guide-ja/start-hello.md

@@ -109,7 +109,7 @@ http://hostname/index.php?r=site/say&message=Hello+World
 このページはアプリケーションの他のページと同じヘッダとフッタを共有しています。
 
 URL から `message` パラメータを省略すると、"こんにちは" を表示するページを見ることになるでしょう。
-これは、`message` が `actionSay()` メソッドにパラメータとして渡されるものであり、それが省略された場合には、既定値である `"こんにちは"` が代りに使われるからです。
+これは、`message` が `actionSay()` メソッドにパラメータとして渡されるものであり、それが省略された場合には、デフォルト値である `"こんにちは"` が代りに使われるからです。
 
 > Info|情報: 新しいページは他のページと同じヘッダとフッタを共有していますが、それは [[yii\web\Controller::render()|render()]] メソッドが `say` ビューの結果をいわゆる [レイアウト](structure-views.md#layouts) に自動的に埋め込むからです。
 レイアウトは、この場合、`views/layouts/main.php` にあります。

docs/guide-ja/start-installation.md

@@ -6,7 +6,7 @@ Yii 縺ｯ莠後▽縺ｮ譁ｹ豕輔〒繧､繝ｳ繧ｹ繝医繝ｫ縺吶ｋ縺薙→縺悟譚･縺ｾ縺吶ゅ☆縺ｪ
 
 Yii の標準的なインストールを実行すると、フレームワークとアプリケーションテンプレートの両方がダウンロードされてインストールされます。
 アプリケーションテンプレートは、いくつかの基本的な機能、例えば、ログインやコンタクトフォームなどを実装した、動作する Yii アプリケーションです。
-そのコードは推奨される方法に従って組織されています。
+そのコードは推奨される方法に従って編成されています。
 そのため、アプリケーションテンプレートは、あなたのプロジェクトのための良い開始点としての役割を果たしうるものです。
 
 この節と後続のいくつかの節においては、いわゆる *ベーシックアプリケーションテンプレート* とともに Yii をインストールする方法、および、このテンプレート上に新しい機能を実装する方法を説明します。
@@ -14,7 +14,7 @@ Yii 縺ｯ繧ゅ≧荳縺､縲ー繧｢繝峨ヰ繝ｳ繧ｹ繝医い繝励Μ繧ｱ繝ｼ繧ｷ繝ｧ繝ｳ繝Φ繝励Ξ繝ｼ
 こちらは、チーム開発環境において多層構造のアプリケーションを開発するときに使用する方が望ましいものです。
 
 > Info|情報: ベーシックアプリケーションテンプレートは、ウェブアプリケーションの 90 パーセントを開発するのに適したものです。
-  アドバンストアプリケーションテンプレートとの主な違いは、コードがどのように組織されているかという点にあります。
+  アドバンストアプリケーションテンプレートとの主な違いは、コードがどのように編成されているかという点にあります。
   あなたが Yii は初めてだという場合は、シンプルでありながら十分な機能を持っているベーシックアプリケーションテンプレートに留まることを強く推奨します。
 
 

docs/guide-ja/start-workflow.md

@@ -3,7 +3,7 @@
 
 Yii のインストールが終ると、実際に動く Yii のアプリケーションにアクセスすることが出来ます。
 その URL は、`http://hostname/basic/web/index.php` あるいは `http://hostname/index.php` など、設定によって異なります。
-この節では、アプリケーションに組み込み済みの機能を紹介し、コードがどのように組織されているか、そして、一般にアプリケーションがリクエストをどのように処理するかを説明します。
+この節では、アプリケーションに組み込み済みの機能を紹介し、コードがどのように編成されているか、そして、一般にアプリケーションがリクエストをどのように処理するかを説明します。
 
 > Info|情報: 話を簡単にするために、この「始めよう」のチュートリアルを通じて、`basic/web` をウェブサーバのドキュメントルートとして設定したと仮定します。
   そして、アプリケーションにアクセスするための URL は `http://hostname/index.php` またはそれに似たものになるように設定したと仮定します。

docs/guide-ja/structure-applications.md

@@ -214,7 +214,7 @@ if (YII_ENV_DEV) {
 #### [[yii\base\Application::controllerMap|controllerMap]] <span id="controllerMap"></span>
 
 このプロパティは、コントローラ ID を任意のコントローラクラスに割り付けることを可能にするものです。
-既定では、Yii は [規約](#controllerNamespace) に基づいてコントローラ ID をコントローラクラスに割り付けます
+デフォルトでは、Yii は [規約](#controllerNamespace) に基づいてコントローラ ID をコントローラクラスに割り付けます
 (例えば、`post` という ID は `app\controllers\PostController` に割り付けられます)。
 このプロパティを構成することによって、特定のコントローラに対する規約を破ることが出来ます。
 下記の例では、`account` は `app\controllers\UserController` に割り付けられ、`article` は `app\controllers\PostController` に割り付けられることになります。
@@ -258,7 +258,7 @@ if (YII_ENV_DEV) {
 アプリケーションが多言語をサポートする必要があるときは、このプロパティを構成しなければなりません。
 
 このプロパティの値が、メッセージの翻訳、日付の書式、数字の書式などを含む [国際化](tutorial-i18n.md) のさまざまな側面を決定します。
-例えば、[[yii\jui\DatePicker]] ウィジェットは、どの言語でカレンダーを表示すべきか、そして日付をどのように書式設定すべきかを、既定では、このプロパティを使用して決定します。
+例えば、[[yii\jui\DatePicker]] ウィジェットは、どの言語でカレンダーを表示すべきか、そして日付をどのように書式設定すべきかを、デフォルトでは、このプロパティを使用して決定します。
 
 言語を指定するのには、[IETF 言語タグ](http://ja.wikipedia.org/wiki/IETF%E8%A8%80%E8%AA%9E%E3%82%BF%E3%82%B0) に従うことが推奨されます。
 例えば、`en` は英語を意味し、`en-US` はアメリカ合衆国の英語を意味します。

docs/guide-ja/structure-assets.md

@@ -109,7 +109,7 @@ class AppAsset extends AssetBundle
 アセットバンドルクラスを定義するときには [[yii\web\AssetBundle::sourcePath|sourcePath]] プロパティを指定しなければなりません。
 
 > Note|注意: `@webroot/assets` を [[yii\web\AssetBundle::sourcePath|ソースパス]] として使ってはいけません。
-  このディレクトリは、既定では、[[yii\web\AssetManager|アセットマネージャ]] がソースの配置場所から発行されたアセットファイルを保存する場所として使われます。
+  このディレクトリは、デフォルトでは、[[yii\web\AssetManager|アセットマネージャ]] がソースの配置場所から発行されたアセットファイルを保存する場所として使われます。
   このディレクトリの中のファイルはすべて一時的なものと見なされており、削除されることがあります。
 
 
@@ -157,13 +157,13 @@ public $cssOptions = ['noscript' => true];
 ```
 
 JavaScript ファイルをページの head セクションにインクルードするためには、次のオプションを使います
-(既定では、JavaScript ファイルは body セクションの最後にインクルードされます)。
+(デフォルトでは、JavaScript ファイルは body セクションの最後にインクルードされます)。
 
 ```php
 public $jsOptions = ['position' => \yii\web\View::POS_HEAD];
 ```
 
-既定では、アセットバンドルが発行されるときは、[[yii\web\AssetBundle::sourcePath]] で指定されたディレクトリの中にある全てのコンテントが発行されます。
+デフォルトでは、アセットバンドルが発行されるときは、[[yii\web\AssetBundle::sourcePath]] で指定されたディレクトリの中にある全てのコンテントが発行されます。
 [[yii\web\AssetBundle::publishOptions|publishOptions]] プロパティを構成することによって、この振る舞いをカスタマイズすることが出来ます。
 例えば、[[yii\web\AssetBundle::sourcePath]] の一個または数個のサブディレクトリだけを発行するために、アセットバンドルクラスの中で下記のようにすることが出来ます。
 
@@ -328,7 +328,7 @@ return [
 既に述べたように、アセットバンドルがウェブからアクセス出来ないディレクトリに配置されている場合は、バンドルがビューに登録されるときに、アセットがウェブディレクトリにコピーされます。
 このプロセスは *アセット発行* と呼ばれ、[[yii\web\AssetManager|アセットマネージャ]] によって自動的に実行されます。
 
-既定では、アセットが発行されるディレクトリは `@webroot/assets` であり、`@web/assets` という URL に対応するものです。
+デフォルトでは、アセットが発行されるディレクトリは `@webroot/assets` であり、`@web/assets` という URL に対応するものです。
 この場所は、[[yii\web\AssetManager::basePath|basePath]] と [[yii\web\AssetManager::baseUrl|baseUrl]] のプロパティを構成してカスタマイズすることが出来ます。
 
 ファイルをコピーすることでアセットを発行する代りに、OS とウェブサーバが許容するなら、シンボリックリンクを使うことを考慮しても良いでしょう。
@@ -355,7 +355,7 @@ return [
 その中で、下記のバンドルはよく使われるものであり、あなたのアプリケーションやエクステンションのコードでも参照することが出来るものです。
 
 - [[yii\web\YiiAsset]]: 主として `yii.js` ファイルをインクルードするためのバンドルです。
-  このファイルはモジュール化された JavaScript のコードを組織化するメカニズムを実装しています。
+  このファイルはモジュール化された JavaScript のコードを編成するメカニズムを実装しています。
   また、`data-method` と `data-confirm` の属性に対する特別なサポートや、その他の有用な機能を提供します。
 - [[yii\web\JqueryAsset]]: jQuery の bower パッケージから `jquery.js` ファイルをインクルードします。
 - [[yii\bootstrap\BootstrapAsset]]: Twitter Bootstrap フレームワークから CSS ファイルをインクルードします。
@@ -584,7 +584,7 @@ return [
 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/) を使用します。
+デフォルトでは、Yii は JavaScript ファイルの結合に [Closure Compiler](https://developers.google.com/closure/compiler/) を使い、CSS ファイルの結合に [YUI Compressor](https://github.com/yui/yuicompressor/) を使用します。
 あなたの好みのツールを使うためには、手作業でツールをインストールしたり、オプションを調整したりしなければなりません。
 
 この構成情報ファイルを使い、`asset` コマンドを走らせて、アセットファイルを結合して圧縮し、同時に、新しいアセットバンドルの構成情報ファイル `assets-prod.php` を生成することが出来ます。

docs/guide-ja/structure-controllers.md

@@ -139,7 +139,7 @@ class SiteController extends Controller
 一方、`admin/post2-comment` コントローラは `@app/controllers/admin/Post2CommentController.php` というエイリアスのファイルに保存されるべきものとなります。
 
 > Info|情報: 最後の例である `admin/post2-comment` は、どうすれば [[yii\base\Application::controllerNamespace|コントローラ名前空間]] のサブディレクトリにコントローラを置くことが出来るかを示しています。
-  この方法は、コントローラをいくつかのカテゴリに分けて整理したい、けれども [モジュール](structure-modules.md) は使いたくない、という場合に役立ちます。
+  この方法は、コントローラをいくつかのカテゴリに分けて編成したい、けれども [モジュール](structure-modules.md) は使いたくない、という場合に役立ちます。
 
 
 ### コントローラマップ <span id="controller-map"></span>

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

@@ -62,7 +62,7 @@ $config = require(__DIR__ . '/../config/web.php');
 
 defined('YII_DEBUG') or define('YII_DEBUG', true);
 
-// fcgi が既定では STDIN と STDOUT を定義していないので
+// デフォルトでは fcgi が STDIN と STDOUT を定義していないので
 defined('STDIN') or define('STDIN', fopen('php://stdin', 'r'));
 defined('STDOUT') or define('STDOUT', fopen('php://stdout', 'w'));
 
@@ -89,12 +89,12 @@ Yii は下記の三つの定数をサポートしています。
 * `YII_DEBUG`: アプリケーションがデバッグモードで走るかどうかを指定します。
   デバッグモードにおいては、アプリケーションはより多くのログ情報を保持し、例外が投げられたときに、より詳細なエラーのコールスタックを表示します。
   この理由により、デバッグモードは主として開発時に使用されるべきものとなります。
-  `YII_DEBUG` の既定値は false です。
+  `YII_DEBUG` のデフォルト値は false です。
 * `YII_ENV`: どういう環境でアプリケーションが走っているかを指定します。
   詳細は、[構成情報](concept-configurations.md#environment-constants) の節で説明されます。
-  `YII_ENV` の既定値は `'prod'` であり、アプリケーションが本番環境で走っていることを意味します。
+  `YII_ENV` のデフォルト値は `'prod'` であり、アプリケーションが本番環境で走っていることを意味します。
 * `YII_ENABLE_ERROR_HANDLER`: Yii によって提供されるエラーハンドラを有効にするかどうかを指定します。
-  この定数の既定値は true です。
+  この定数のデフォルト値は true です。
 
 定数を定義するときには、しばしば次のようなコードを用います。
 

docs/guide-ja/structure-extensions.md

@@ -19,7 +19,7 @@
 
 [Composer](https://getcomposer.org/) を持っていない場合は、それをインストールする必要があることに注意してください。
 
-既定では、Composer は [Packagist](https://packagist.org/) に登録されたパッケージをインストールします。
+デフォルトでは、Composer は [Packagist](https://packagist.org/) に登録されたパッケージをインストールします。
 Packagist はオープンソース Composer パッケージの最大のレポジトリであり、そこでエクステンションを探すことが出来ます。
 また、[自分自身のレポジトリを作成](https://getcomposer.org/doc/05-repositories.md#repository) して、それを使うように Composer を構成することも出来ます。
 これは、あなたがプライベートなエクステンションを開発していて、それを自分のプロジェクト間でのみ共有したい場合に役に立つ方法です。
@@ -201,7 +201,7 @@ Yii は [Composer アセットプラグイン](https://github.com/francoispluchi
 上記のコードは、エクステンションが `jquery` Bower パッケージに依存することを述べています。
 一般に、`composer.json` の中でBower パッケージを指すためには `bower-asset/PackageName` を使うことが出来ます。
 そして、NPM パッケージを指すためには `npm-asset/PackageName` を使うことが出来ます。
-Composer が Bower または NPM のパッケージをインストールする場合は、既定では、それぞれ、`@vendor/bower/PackageName` および `@vendor/npm/Packages` というディレクトリの下にパッケージの内容がインストールされます。
+Composer が Bower または NPM のパッケージをインストールする場合は、デフォルトでは、それぞれ、`@vendor/bower/PackageName` および `@vendor/npm/Packages` というディレクトリの下にパッケージの内容がインストールされます。
 この二つのディレクトリは、`@bower/PackageName` および `@npm/PackageName` という短いエイリアスを使って参照することも可能です。
 
 アセット管理に関する詳細については、[アセット](structure-assets.md#bower-npm-assets) の節を参照してください。

docs/guide-ja/structure-filters.md

@@ -5,7 +5,7 @@
 例えば、アクセスコントロールフィルタはアクションの前に走って、アクションが特定のエンドユーザだけにアクセスを許可するものであることを保証します。
 また、コンテント圧縮フィルタはアクションの後に走って、レスポンスのコンテントをエンドユーザに送出する前に圧縮します。
 
-フィルタは、前フィルタ (アクションの *前* に適用されるフィルタのロジック) および/または 後フィルタ (アクションの *後* に適用されるフィルタ) から構成されます。
+一つのフィルタは、前フィルタ (アクションの *前* に適用されるフィルタのロジック) および/または 後フィルタ (アクションの *後* に適用されるロジック) から構成することが出来ます。
 
 
 ## フィルタを使用する <span id="using-filters"></span>
@@ -30,17 +30,15 @@ public function behaviors()
 }
 ```
 
-既定では、コントローラクラスの中で宣言されたフィルタは、そのコントローラの *全て* のアクションに適用されます。
+デフォルトでは、コントローラクラスの中で宣言されたフィルタは、そのコントローラの *全て* のアクションに適用されます。
 しかし、[[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]] のプロパティを上で説明したように構成しない限り、
-そのフィルタは、モジュールまたはアプリケーションに属する *全て* のコントローラアクションに適用されます。
+そのようにした場合、[[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) を使うべきです。
+> Note|注意: モジュールやアプリケーションでフィルタを宣言する場合、[[yii\base\ActionFilter::only|only]] と [[yii\base\ActionFilter::except|except]] のプロパティでは、アクション ID ではなく、[ルート](structure-controllers.md#routes) を使わなければなりません。
 なぜなら、モジュールやアプリケーションのスコープでは、アクション ID だけでは完全にアクションを指定することが出来ないからです。
 
 一つのアクションに複数のフィルタが構成されている場合、フィルタは下記で説明されている規則に従って適用されます。
@@ -59,8 +57,7 @@ public function behaviors()
 
 ## フィルタを作成する <span id="creating-filters"></span>
 
-新しいアクションフィルタを作成するためには、[[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 である場合、このフィルタの後に続くフィルタはスキップされ、アクションは実行を中止されます。
@@ -102,13 +99,11 @@ Yii 縺ｯ繧医￥菴ｿ繧上ｌ繧倶ｸ騾｣縺ｮ繝輔ぅ繝ｫ繧ｿ繧呈署萓帙＠縺ｦ縺翫ｊ縲√◎繧後ｉ
 ### [[yii\filters\AccessControl|AccessControl]] <span id="access-control"></span>
 
 AccessControl は、一組の [[yii\filters\AccessControl::rules|規則]] に基づいて、シンプルなアクセスコントロールを提供するものです。
-具体的に言うと、アクションが実行される前に、AccessControl はリストされた規則を調べて、現在のコンテキスト変数
-(例えば、ユーザの IP アドレスや、ユーザのログイン状態など) に最初に合致するものを見つけます。
+具体的に言うと、アクションが実行される前に、AccessControl はリストされた規則を調べて、現在のコンテキスト変数 (例えば、ユーザの IP アドレスや、ユーザのログイン状態など) に最初に合致するものを見つけます。
 そして、合致した規則によって、リクエストされたアクションの実行を許可するか拒否するかを決定します。
 合致する規則がなかった場合は、アクセスは拒否されます。
 
-次の例は、認証されたユーザに対しては `create` と `update` のアクションへのアクセスを許可し、
-その他のすべてのユーザにはこれら二つのアクションに対するアクセスを拒否する仕方を示すものです。
+次の例は、認証されたユーザに対しては `create` と `update` のアクションへのアクセスを許可し、その他のすべてのユーザにはこれら二つのアクションに対するアクセスを拒否する仕方を示すものです。
 
 ```php
 use yii\filters\AccessControl;
@@ -125,7 +120,7 @@ public function behaviors()
                     'allow' => true,
                     'roles' => ['@'],
                 ],
-                // その他は、既定により拒否される
+                // その他はすべてデフォルトにより拒否される
             ],
         ],
     ];
@@ -143,8 +138,7 @@ public function behaviors()
 
 次の例は、[[yii\filters\auth\HttpBasicAuth]] の使い方を示すもので、HTTP Basic 認証に基づくアクセストークンを使ってユーザを認証しています。
 これを動作させるためには、あなたの [[yii\web\User::identityClass|ユーザアイデンティティクラス]]
-が [[yii\web\IdentityInterface::findIdentityByAccessToken()|findIdentityByAccessToken()]] 
-メソッドを実装していなければならないことに注意してください。
+が [[yii\web\IdentityInterface::findIdentityByAccessToken()|findIdentityByAccessToken()]] メソッドを実装していなければならないことに注意してください。
 
 ```php
 use yii\filters\auth\HttpBasicAuth;
@@ -192,8 +186,7 @@ public function behaviors()
 }
 ```
 
-レスポンス形式と言語は [アプリケーションのライフサイクル](structure-applications.md#application-lifecycle)
-のもっと早い段階で決定される必要があることがよくあります。
+レスポンス形式と言語は [アプリケーションのライフサイクル](structure-applications.md#application-lifecycle) のもっと早い段階で決定される必要があることがよくあります。
 このため、ContentNegotiator はフィルタの他に、[ブートストラップコンポーネント](structure-applications.md#bootstrap) としても使うことができるように設計されています。
 例えば、次のように、ContentNegotiator を [アプリケーションの構成情報](structure-applications.md#application-configurations) の中で構成することが出来ます。
 
@@ -218,14 +211,13 @@ use yii\web\Response;
 ];
 ```
 
-> Info|情報: 望ましいコンテントタイプと言語がリクエストからは決定できない場合は、[[formats]] および [[languages]]
-に挙げられている最初の形式と言語が使用されます。
+> Info|情報: 望ましいコンテントタイプと言語がリクエストから決定できない場合は、[[formats]] および [[languages]] に挙げられている最初の形式と言語が使用されます。
 
 
 
 ### [[yii\filters\HttpCache|HttpCache]] <span id="http-cache"></span>
 
-HttpCache は `Last-Modified` および `Etag` の HTTP ヘッダを利用して、クライアントサイドのキャッシュを実装するものです。
+HttpCache は `Last-Modified` および `Etag` の HTTP ヘッダを利用して、クライアント側のキャッシュを実装するものです。
 
 ```php
 use yii\filters\HttpCache;
@@ -250,7 +242,7 @@ HttpCache 縺ｫ髢｢縺吶ｋ隧ｳ邏ｰ縺ｯ [HTTP 繧ｭ繝｣繝す繝･](caching-http.md) 縺ｮ遽繧
 
 ### [[yii\filters\PageCache|PageCache]] <span id="page-cache"></span>
 
-PageCache はサーバサイドにおけるページ全体のキャッシュを実装するものです。
+PageCache はサーバ側におけるページ全体のキャッシュを実装するものです。
 次の例では、PageCache が `index` アクションに適用されて、最大 60 秒間、または、`post` テーブルのエントリ数が変化するまでの間、ページ全体をキャッシュしています。
 さらに、このページキャッシュは、選択されたアプリケーションの言語に従って、違うバージョンのページを保存するようにしています。
 
@@ -282,8 +274,8 @@ PageCache 縺ｮ菴ｿ逕ｨ縺ｫ髢｢縺吶ｋ隧ｳ邏ｰ縺ｯ [繝壹繧ｸ繧ｭ繝｣繝す繝･](caching-page
 
 ### [[yii\filters\RateLimiter|RateLimiter]] <span id="rate-limiter"></span>
 
-RateLimiter は [リーキーバケットアルゴリズム](http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%82%AD%E3%83%BC%E3%83%90%E3%82%B1%E3%83%83%E3%83%88)
-に基づいてレート制限のアルゴリズムを実装するものです。主として RESTful API を実装するときに使用されます。
+RateLimiter は [リーキーバケットアルゴリズム](http://ja.wikipedia.org/wiki/%E3%83%AA%E3%83%BC%E3%82%AD%E3%83%BC%E3%83%90%E3%82%B1%E3%83%83%E3%83%88) に基づいてレート制限のアルゴリズムを実装するものです。
+主として RESTful API を実装するときに使用されます。
 このフィルタの使用に関する詳細は [レート制限](rest-rate-limiting.md) の節を参照してください。
 
 
@@ -291,7 +283,7 @@ RateLimiter 縺ｯ [繝ｪ繝ｼ繧ｭ繝ｼ繝舌こ繝ヨ繧｢繝ｫ繧ｴ繝ｪ繧ｺ繝](http://ja.wikipedia
 
 VerbFilter は、HTTP リクエストメソッド (HTTP 動詞) がリクエストされたアクションによって許可されているかどうかをチェックするものです。
 許可されていない場合は、HTTP 405 例外を投げます。
-次の例では、VerbFilter が宣言されて、CRUD アクションに対して許可されるメソッドの典型的なセットを規定しています。
+次の例では、VerbFilter が宣言されて、CRUD アクションに対して許可されるメソッドの典型的なセットを指定しています。
 
 ```php
 use yii\filters\VerbFilter;
@@ -315,8 +307,7 @@ public function behaviors()
 
 ### [[yii\filters\Cors|Cors]] <span id="cors"></span>
 
-クロスオリジンリソース共有 [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 は、ブラウザとサーバが交信して、クロスドメインのリクエストを許可するか否かを決定する方法を定義するものです。

docs/guide-ja/structure-modules.md

@@ -4,14 +4,13 @@
 モジュールは、[モデル](structure-models.md)、[ビュー](structure-views.md)、[コントローラ](structure-controllers.md)、およびその他の支援コンポーネントから構成される自己充足的なソフトウェアのユニットです。
 モジュールが [アプリケーション](structure-applications.md) にインストールされている場合、エンドユーザはモジュールのコントローラにアクセスする事が出来ます。
 これらのことを理由として、モジュールは小さなアプリケーションと見なされることがよくあります。
-しかし、モジュールは単独では配置できず、アプリケーションの中に存在しなければならないという点で [アプリケーション](structure-applications.md) とは異なります。
+しかし、モジュールは単独では配備できず、アプリケーションの中に存在しなければならないという点で [アプリケーション](structure-applications.md) とは異なります。
 
 
 ## モジュールを作成する <span id="creating-modules"></span>
 
-モジュールは、モジュールの [[yii\base\Module::basePath|ベースパス]] と呼ばれるディレクトリとして組織されます。
-このディレクトリの中に、ちょうどアプリケーションの場合と同じように、`controllers`、`models`、`views`
-のようなサブディレクトリが存在して、コントローラ、モデル、ビュー、その他のコードを収納しています。
+モジュールは、モジュールの [[yii\base\Module::basePath|ベースパス]] と呼ばれるディレクトリとして編成されます。
+このディレクトリの中に、ちょうどアプリケーションの場合と同じように、`controllers`、`models`、`views` のようなサブディレクトリが存在して、コントローラ、モデル、ビュー、その他のコードを収納しています。
 次の例は、モジュール内の中身を示すものです。
 
 ```
@@ -34,7 +33,7 @@ forum/
 モジュールがアクセスされたとき、対応するモジュールクラスの単一のインスタンスが作成されます。
 [アプリケーションのインスタンス](structure-applications.md) と同じように、モジュールのインスタンスは、モジュール内のコードがデータとコンポーネントを共有するために使用されます。
 
-次のコードは、モジュールクラスがどのように見えるかを示す例です。
+次のコードは、モジュールクラスがどのようなものかを示す例です。
 
 ```php
 namespace app\modules\forum;
@@ -51,8 +50,7 @@ class Module extends \yii\base\Module
 }
 ```
 
-`init` メソッドがモジュールのプロパティを初期化するためのコードをたくさん含む場合は、
-それを [構成情報](concept-configurations.md) の形で保存し、`init()` の中で次のコードを使って読み出すことも可能です。
+`init` メソッドがモジュールのプロパティを初期化するためのコードをたくさん含む場合は、それを [構成情報](concept-configurations.md) の形で保存し、`init()` の中で次のコードを使って読み出すことも可能です。
 
 ```php
 public function init()
@@ -108,7 +106,7 @@ class PostController extends Controller
 例えば、コントローラクラスが `PostController` である場合、ディレクトリはモジュールの [[yii\base\Module::basePath|ベースパス]] の中の `views/post` となります。
 
 モジュールは、そのモジュールのコントローラによってレンダリングされるビューに適用される [レイアウト](structure-views.md#layouts) を指定することが出来ます。
-レイアウトは、既定では `views/layouts` ディレクトリに置かれなければならず、また、[[yii\base\Module::layout]] プロパティがレイアウトの名前を指すように構成しなければなりません。
+レイアウトは、デフォルトでは `views/layouts` ディレクトリに置かれなければならず、また、[[yii\base\Module::layout]] プロパティがレイアウトの名前を指すように構成しなければなりません。
 `layout` プロパティを構成しない場合は、アプリケーションのレイアウトが代りに使用されます。
 
 
@@ -138,7 +136,7 @@ class PostController extends Controller
 アプリケーションの中のコントローラをアクセスするのと同じように、[ルート](structure-controllers.md#routes) がモジュールの中のコントローラを指し示すために使われます。
 モジュール内のコントローラのルートは、モジュール ID で始まり、コントローラ ID、アクション ID と続くものでなければなりません。
 例えば、アプリケーションが `forum` という名前のモジュールを使用している場合、`forum/post/index` というルートは、`forum` モジュール内の `post` コントローラの `index` アクションを表します。
-ルートがモジュール ID だけを含む場合は、[[yii\base\Module::defaultRoute]] プロパティ (既定値は `default` です) が、どのコントローラ/アクションが使用されるべきかを決定します。
+ルートがモジュール ID だけを含む場合は、[[yii\base\Module::defaultRoute]] プロパティ (デフォルト値は `default` です) が、どのコントローラ/アクションが使用されるべきかを決定します。
 これは、`forum` というルートは `forum` モジュール内の `default` コントローラを表すという意味です。
 
 
@@ -151,11 +149,11 @@ class PostController extends Controller
 $module = MyModuleClass::getInstance();
 ```
 
-ここで `MyModuleClass` は、関心を持っているモジュールクラスの名前を指します。
+ここで `MyModuleClass` は、当該モジュールクラスの名前を指すものです。
 `getInstance()` メソッドは、現在リクエストされているモジュールクラスのインスタンスを返します。
 モジュールがリクエストされていない場合は、このメソッドは null を返します。
 モジュールクラスの新しいインスタンスを手動で作成しようとしてはいけないことに注意してください。
-そのインスタンスは、リクエストに対するレスポンスとして Yii によって作成されたインスタンスとは別のものになります。
+手動で作成したインスタンスは、リクエストに対するレスポンスとして Yii によって作成されたインスタンスとは別のものになります。
 
 > Info|情報: モジュールを開発するとき、モジュールが固定の ID を使うと仮定してはいけません。
   なぜなら、モジュールは、アプリケーションや他のモジュールの中で使うときに、任意の ID と結び付けることが出来るからです。
@@ -220,7 +218,7 @@ class Module extends \yii\base\Module
 
         $this->modules = [
             'admin' => [
-                // ここはもっと短い名前空間の使用を考慮すべきだ!
+                // ここはもっと短い名前空間の使用を考慮すべきです
                 'class' => 'app\modules\forum\modules\admin\Module',
             ],
         ];

docs/guide-ja/structure-overview.md

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

docs/guide-ja/structure-views.md

@@ -80,9 +80,9 @@ use yii\helpers\HtmlPurifier;
   アプリケーションが高いパフォーマンスを要求する場合は、フィルター結果を [キャッシュ](caching-overview.md) することを考慮すべきです。
 
 
-### ビューを整理する <span id="organizing-views"></span>
+### ビューを編成する <span id="organizing-views"></span>
 
-[コントローラ](structure-controllers.md) や [モデル](structure-models.md) と同じように、ビューを整理するための規約があります。.
+[コントローラ](structure-controllers.md) や [モデル](structure-models.md) と同じように、ビューを編成するための規約があります。.
 
 * コントローラによって表示されるビューは、デフォルトでは、ディレクトリ `@app/views/ControllerID` の下に置かれるべきものです。
   ここで、`ControllerID` は [コントローラ ID](structure-controllers.md#routes) を指します。
@@ -456,14 +456,14 @@ class PostController extends Controller
 <?php $this->endBlock(); ?>
 ```
 
-次に、レイアウトビューで、得ることが出来ればブロックをレンダリングし、ブロックが定義されていないときは何らかの既定のコンテントを表示します。
+次に、レイアウトビューで、得ることが出来ればブロックをレンダリングし、ブロックが定義されていないときは何らかのデフォルトのコンテントを表示します。
 
 ```php
 ...
 <?php if (isset($this->blocks['block1'])): ?>
     <?= $this->blocks['block1'] ?>
 <?php else: ?>
-    ... block1 の既定のコンテント ...
+    ... block1 のデフォルトのコンテント ...
 <?php endif; ?>
 
 ...
@@ -471,7 +471,7 @@ class PostController extends Controller
 <?php if (isset($this->blocks['block2'])): ?>
     <?= $this->blocks['block2'] ?>
 <?php else: ?>
-    ... block2 の既定のコンテント ...
+    ... block2 のデフォルトのコンテント ...
 <?php endif; ?>
 
 ...
@@ -479,7 +479,7 @@ class PostController extends Controller
 <?php if (isset($this->blocks['block3'])): ?>
     <?= $this->blocks['block3'] ?>
 <?php else: ?>
-    ... block3 の既定のコンテント ...
+    ... block3 のデフォルトのコンテント ...
 <?php endif; ?>
 ...
 ```

docs/guide-ja/structure-widgets.md

 ウィジェット
 ============
 
-ウィジェットは、[ビュー](structure-views.md) で使用される再利用可能な構成ブロックで、
-複雑かつ構成可能なユーザインタフェイス要素をオブジェクト指向のやり方で作成するためのものです。
+ウィジェットは、[ビュー](structure-views.md) で使用される再利用可能な構成ブロックで、複雑かつ構成可能なユーザインタフェイス要素をオブジェクト指向のやり方で作成するためのものです。
 例えば、日付選択ウィジェットを使うと、入力として日付を選択することを可能にする素敵なデイトピッカーを生成することが出来ます。
 このとき、あなたがしなければならないことは、次のようなコードをビューに挿入することだけです:
 
@@ -41,7 +40,7 @@ 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>` タグを生成します。
 その間に置かれたものは全てそのままレンダリングされます。
@@ -155,8 +154,7 @@ use app\components\HelloWidget;
 ```
 
 場合によっては、ウィジェットが大きな固まりのコンテントを表示する必要があるかもしれません。
-コンテントを `run()` メソッドの中に埋め込むことも出来ますが、より良い方法は、コンテントを [ビュー](structure-views.md)
-の中に置いて、[[yii\base\Widget::render()]] を呼んでレンダリングすることです。
+コンテントを `run()` メソッドの中に埋め込むことも出来ますが、より良い方法は、コンテントを [ビュー](structure-views.md) の中に置いて、[[yii\base\Widget::render()]] を呼んでレンダリングすることです。
 例えば、
 
 ```php
@@ -166,7 +164,7 @@ public function run()
 }
 ```
 
-既定では、ウィジェット用のビューは `WidgetPath/views` ディレクトリの中のファイルに保存すべきものです。
+デフォルトでは、ウィジェット用のビューは `WidgetPath/views` ディレクトリの中のファイルに保存すべきものです。
 ここで `WidgetPath` はウィジェットのクラスファイルを含むディレクトリを指します。
 したがって、上記の例では、ウィジェットクラスが `@app/components` に配置されていると仮定すると、`@app/components/views/hello.php` というビューファイルがレンダリングされることになります。
 [[yii\base\Widget::getViewPath()]] メソッドをオーバーライドして、ウィジェットのビューファイルを含むディレクトリをカスタマイズすることが出来ます。
@@ -185,5 +183,4 @@ public function run()
 幸いなことに、Yii はこの問題を解決するのに利用することが出来る [アセットバンドル](structure-assets.md) のサポートを提供しています。
 
 ウィジェットがビューコードだけを含む場合は、[ビュー](structure-views.md) と非常に似たものになります。
-実際のところ、この場合、両者の唯一の違いは、ウィジェットが再配布可能なクラスである一方で、
-ビューはアプリケーション内に保持することが望ましい素の PHP スクリプトである、というぐらいの事です。
+実際のところ、この場合、両者の唯一の違いは、ウィジェットが再配布可能なクラスである一方で、ビューはアプリケーション内に保持することが望ましい素の PHP スクリプトである、というぐらいの事です。

docs/guide-ja/test-fixtures.md

@@ -181,13 +181,13 @@ foreach ($this->profiles as $row) ...
 その必要がなければ、単にそれぞれの個別テストケースとそれに対応するフィクスチャの開発に専念することが出来ます。
 
 
-フィクスチャクラスとデータファイルを組織化する
-----------------------------------------------
+フィクスチャクラスとデータファイルを編成する
+--------------------------------------------
 
 デフォルトでは、フィクスチャクラスは対応するデータファイルを探すときに、フィクスチャのクラスファイルを含むフォルダのサブフォルダである `data` フォルダの中を見ます。
 簡単なプロジェクトではこの規約に従うことができます。
 大きなプロジェクトでは、おそらくは、同じフィクスチャクラスを異なるテストに使うために、データファイルを切り替える必要がある場合がよく生じます。
-従って、クラスの名前空間と同じように、データファイルを階層的な方法で組織化することを推奨します。
+従って、クラスの名前空間と同じように、データファイルを階層的な方法で編成することを推奨します。
 例えば、
 
 ```
@@ -215,7 +215,7 @@ data\
 > 例えば、DB フィクスチャを [[yii\test\ActiveFixture]] から拡張している場合は、DB テーブルの名前をフィクスチャのデータファイル名として使うべきです。
 > MongoDB フィクスチャを [[yii\mongodb\ActiveFixture]] から拡張している場合は、コレクション名をファイル名として使うべきです。
 
-同様な階層は、フィクスチャクラスファイルを組織化するのにも使うことが出来ます。
+同様な階層は、フィクスチャクラスファイルを編成するのにも使うことが出来ます。
 `data` をルートディレクトリとして使うのでなく、データファイルとの衝突を避けるために `fixtures` をルートディレクトリとして使うのが良いでしょう。