From df4989324a4e6c2993b8229aa4eacdc867869544 Mon Sep 17 00:00:00 2001
From: Nobuo Kihara <softark@gmail.com>
Date: Fri, 4 May 2018 17:38:12 +0900
Subject: [PATCH] gods/internals-ja revised [ci skip]

---
 docs/internals-ja/README.md               |  5 +-
 docs/internals-ja/automation.md           |  3 +-
 docs/internals-ja/core-code-style.md      | 85 ++++++++++++-----------
 docs/internals-ja/design-decisions.md     |  7 +-
 docs/internals-ja/git-workflow.md         | 56 +++++++--------
 docs/internals-ja/project-organization.md | 15 ++--
 docs/internals-ja/pull-request-qa.md      |  3 +-
 docs/internals-ja/release.md              | 16 +++--
 docs/internals-ja/report-an-issue.md      |  3 +-
 docs/internals-ja/translation-workflow.md |  9 +--
 docs/internals-ja/versions.md             | 13 ++--
 docs/internals-ja/view-code-style.md      |  5 +-
 12 files changed, 110 insertions(+), 110 deletions(-)

diff --git a/docs/internals-ja/README.md b/docs/internals-ja/README.md
index 4e2459a1ee..ac6ac04a7b 100644
--- a/docs/internals-ja/README.md
+++ b/docs/internals-ja/README.md
@@ -24,7 +24,7 @@ Yii 開発者ドキュメント
 フレームワーク開発
 ------------------
 
-- [プルリクエストの品質保証](pull-request-qa.md)
+- [プル・リクエストの品質保証](pull-request-qa.md)
 - [自動化されるタスク](automation.md) コード・スタイルの修正、ドキュメントやファイルの自動生成など。
 - [設計上の決定](design-decisions.md) - よく議論される事柄についての FAQ 形式の声明リスト。
 
@@ -45,5 +45,4 @@ Yii 開発者ドキュメント
 
 ### データベースのテスト
 
-[こちら](https://gist.github.com/sergeymakinen/0696a5952f160ea28d7b64c3adfecf6f) に、
-Yii がサポートする全てのデータベースのためのテスト環境構成があります。
+[こちら](https://gist.github.com/sergeymakinen/0696a5952f160ea28d7b64c3adfecf6f) に、Yii がサポートする全てのデータベースのためのテスト環境構成があります。
diff --git a/docs/internals-ja/automation.md b/docs/internals-ja/automation.md
index 4019b9fd9c..3b4cf52fac 100644
--- a/docs/internals-ja/automation.md
+++ b/docs/internals-ja/automation.md
@@ -17,7 +17,6 @@ Yii の開発に取り組む際に、自動化できるタスクがいくつか
 - Mime タイプ・マジック・ファイル (`framework/helpers/mimeTypes.php`) の Apache HTTPd レポジトリによる更新。
   `./build/build mime-type` を実行してファイルを更新して下さい。
 
-- CHANGELOG ファイルのエントリの出現順序は、`./build/build release/sort-changelog framework`
-を実行することで更新することが出来ます。
+- CHANGELOG ファイルのエントリの出現順序は、`./build/build release/sort-changelog framework` を実行することで更新することが出来ます。
 
 上記のコマンドの全てが [リリースの工程]() に含まれています。これらをリリースとリリースの間に実行しても構いませんが、必要ではありません。
diff --git a/docs/internals-ja/core-code-style.md b/docs/internals-ja/core-code-style.md
index a2d58bd45d..fa1a2a3cec 100644
--- a/docs/internals-ja/core-code-style.md
+++ b/docs/internals-ja/core-code-style.md
@@ -3,19 +3,16 @@ Yii 2 コア・フレームワーク・コード・スタイル
 
 下記のコード・スタイルが Yii 2.x コアと公式エクステンションの開発に用いられています。
 コアに対してコードをプル・リクエストをしたいときは、これを使用することを考慮してください。
-私たちは、あなたが自分のアプリケーションにこのコード・スタイルを使うことを強制するものではありません。
-あなたにとってより良いコード・スタイルを自由に選んでください。
+私たちは、あなたが自分のアプリケーションにこのコード・スタイルを使うことを強制するものではありません。あなたにとってより良いコード・スタイルを自由に選んでください。
 
 なお、CodeSniffer のための設定をここで入手できます: https://github.com/yiisoft/yii2-coding-standards
 
-> Note: 以下では、説明のために、サンプル・コードのドキュメントやコメントを日本語に翻訳しています。
-  しかし、コア・コードや公式エクステンションに対して実際に寄稿する場合には、それらを英語で書く必要があります。
-
-
 ## 1. 概要
 
-全体として、私たちは [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) 互換のスタイルを使っていますので、
-[PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) に適用されることは、すべて私たちのコード・スタイルにも適用されます。
+全体として、私たちは [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)
+互換のスタイルを使っていますので、
+[PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) に適用されることは、
+すべて私たちのコード・スタイルにも適用されます。
 
 - ファイルは `<?php` または `<?=` のタグを使わなければならない。
 - ファイルの末尾には一個の改行があるべきである。
@@ -59,7 +56,7 @@ PHP コードは BOM 無しの UTF-8 のみを使わなければなりません
 
 ```php
 /**
- * ドキュメント
+ * Documentation
  */
 class MyClass extends \yii\base\BaseObject implements MyInterface
 {
@@ -91,7 +88,8 @@ class Foo
 - より読みやすいように、プロパティの宣言は空行を挟まずに続け、プロパティ宣言とメソッド宣言のブロック間には2行の空行を挟むべきです。
   また、異なる可視性のグループの間に、1行の空行を追加するべきです。
 - Private 変数は `$_varName` のように名付けるべきです。
-- Public なクラス・メンバとスタンドアロンな変数は、先頭を小文字にした `$camelCase` で名付けるべきです。
+- Public なクラス・メンバとスタンドアロンな変数は、
+  先頭を小文字にした `$camelCase` で名付けるべきです。
 - 説明的な名前を使うこと。`$i` や `$j` のような変数は使わないようにしましょう。
 
 例えば、
@@ -119,17 +117,18 @@ class Foo
 
 - 関数およびメソッドは、先頭を小文字にした `camelCase` で名付けるべきです。
 - 名前は、関数の目的を示す自己説明的なものであるべきです。
-- クラスのメソッドは常に修飾子 `private`、`protected` または `public` を使って、可視性を宣言すべきです。`var` は許可されません。
+- クラスのメソッドは常に修飾子 `private`、`protected` または `public` を使って、可視性を宣言すべきです。
+  `var` は許可されません。
 - 関数の開始の中括弧は関数宣言の次の行に置くべきです。
 
 ```php
 /**
- * ドキュメント
+ * Documentation
  */
 class Foo
 {
     /**
-     * ドキュメント
+     * Documentation
      */
     public function bar()
     {
@@ -145,8 +144,7 @@ class Foo
    `Model` または `ActiveRecord` のようなクラス名を使うことも出来ます。
  - 型付きの配列に対しては `ClassName[]` を使います。
  - PHPDoc の最初の行には、メソッドの目的を記述しなければなりません。
- - メソッドが何かをチェックする (たとえば、`isActive`, `hasClass` など) ものである場合は、
-   最初の行は `Checks whether` で始まらなければなりません。
+ - メソッドが何かをチェックする (たとえば、`isActive`, `hasClass` など) ものである場合は、最初の行は `Checks whether` で始まらなければなりません。
  - `@return` は、厳密に何が返されるのかを明示的に記述しなければなりません。
 
 ```php
@@ -164,7 +162,6 @@ class Foo
  }
 ```
 
-
 ### 4.5 コンストラクタ
 
 - PHP 4 スタイルのコンストラクタの代りに、`__construct` が使われるべきです。
@@ -199,14 +196,14 @@ $str = 'こんな具合に。';
 #### 変数置換
 
 ```php
-$str1 = "こんにちは $username さん";
-$str2 = "こんにちは {$username} さん";
+$str1 = "Hello $username!";
+$str2 = "Hello {$username}!";
 ```
 
 下記は許可されません。
 
 ```php
-$str3 = "こんにちは ${username} さん";
+$str3 = "Hello ${username}!";
 ```
 
 #### 連結
@@ -367,23 +364,27 @@ $mul = array_reduce($numbers, function($r, $x) use($n) {
 
 - ドキュメントの文法については [phpDoc](http://phpdoc.org/) を参照してください。
 - ドキュメントの無いコードは許容されません。
-- 全てのクラス・ファイルは、ファイル・レベルの doc ブロックを各ファイルの先頭に持ち、クラス・レベルの doc ブロックを各クラスの直前に持たなければなりません。
+- 全てのクラス・ファイルは、ファイル・レベルの doc ブロックを各ファイルの先頭に持ち、
+  クラス・レベルの doc ブロックを各クラスの直前に持たなければなりません。
 - メソッドが実際に何も返さないときは `@return` を使う必要はありません。
-- `yii\base\BaseObject` から派生するクラスのすべての仮想プロパティは、クラスの doc ブロックで `@property` タグでドキュメントされます。
-  これらの注釈は、`build` ディレクトリで `./build php-doc` コマンドを走らせることにより、対応する getter や setter の `@return` や `@param` タグから自動的に生成されます。
-  getter や setter に `@property` タグを追加することによって、これらのメソッドによって導入されるプロパティに対してドキュメントのメッセージを明示的に与えることが出来ます。
+- `yii\base\BaseObject` から派生するクラスのすべての仮想プロパティは、クラスの doc ブロックで
+  `@property` タグでドキュメントされます。
+  これらの注釈は、`build` ディレクトリで `./build php-doc` コマンドを走らせることにより、
+  対応する getter や setter の `@return` や `@param` タグから自動的に生成されます。
+  getter や setter に `@property` タグを追加することによって、これらのメソッドによって導入されるプロパティに対して
+  ドキュメントのメッセージを明示的に与えることが出来ます。
   これは `@return` で記述されているのとは違う説明を与えたい場合に有用です。
   下記が一例です。
 
   ```php
     <?php
     /**
-     * 全ての属性または一つの属性についてエラーを返す。
-     * @param string $attribute 属性の名前。全ての属性についてエラーを取得するためには null を使う。
-     * @property array 全ての属性に対するエラーの配列。エラーが無い場合は空の配列が返される。
-     * 結果は二次元の配列である。詳細な説明は [[getErrors()]] を参照。
-     * @return array 全ての属性または特定の属性に対するエラー。エラーが無い場合は空の配列が返される。
-     * 全ての属性に対するエラーを返す場合、結果は、下記のような二次元の配列になる。
+     * Returns the errors for all attribute or a single attribute.
+     * @param string $attribute attribute name. Use null to retrieve errors for all attributes.
+     * @property array An array of errors for all attributes. Empty array is returned if no error.
+     * The result is a two-dimensional array. See [[getErrors()]] for detailed description.
+     * @return array errors for all attributes or the specified attribute. Empty array is returned if no error.
+     * Note that when returning errors for all attributes, the result is a two-dimensional array, like the following:
      * ...
      */
     public function getErrors($attribute = null)
@@ -404,7 +405,7 @@ $mul = array_reduce($numbers, function($r, $x) use($n) {
 
 ```php
 /**
- * Component は *property*、*event* および *behavior* の機能を提供する基底クラスである。
+ * Component is the base class that provides the *property*, *event* and *behavior* features.
  *
  * @include @yii/docs/base-Component.md
  *
@@ -419,23 +420,25 @@ class Component extends \yii\base\BaseObject
 
 ```php
 /**
- * イベントに対してアタッチされたイベント・ハンドラのリストを返す。
- * 返された [[Vector]] オブジェクトを操作して、ハンドラを追加したり削除したり出来る。
- * 例えば、
+ * Returns the list of attached event handlers for an event.
+ * You may manipulate the returned [[Vector]] object by adding or removing handlers.
+ * For example,
  *
  * ```
  * $component->getEventHandlers($eventName)->insertAt(0, $eventHandler);
  * ```
  *
- * @param string $name イベントの名前
- * @return Vector イベントにアタッチされたハンドラのリスト
- * @throws Exception イベントが定義されていない場合
+ * @param string $name the event name
+ * @return Vector list of attached event handlers for the event
+ * @throws Exception if the event is not defined
  */
 public function getEventHandlers($name)
 {
     if (!isset($this->_e[$name])) {
         $this->_e[$name] = new Vector;
     }
+    $this->ensureBehaviors();
+    return $this->_e[$name];
 }
 ```
 
@@ -453,7 +456,7 @@ public function getEventHandlers($name)
 上記のリンクにクラス名やメソッド名以外のラベルを付けるためには、次の例で示されている文法を使うことが出来ます。
 
 ```
-... [[header|ヘッダ・セル]] に表示されているように
+... as displayed in the [[header|header cell]].
 ```
 
 `|` の前の部分がメソッド、プロパティ、クラスへの参照であり、`|` の後ろの部分がリンクのラベルです。
@@ -461,8 +464,8 @@ public function getEventHandlers($name)
 下記の文法を使ってガイドにリンクすることも可能です。
 
 ```markdown
-[ガイドへのリンク](guide:file-name.md)
-[ガイドへのリンク](guide:file-name.md#subsection)
+[link to guide](guide:file-name.md)
+[link to guide](guide:file-name.md#subsection)
 ```
 
 
@@ -492,8 +495,7 @@ public function getEventHandlers($name)
 
 ### 「何かをするな」を示す値
 
-コンポーネントに対して「何かをしない」という設定を許可するプロパティは `false` の値を受け入れるべきです。
-`null`、`''`、または `[]` がそういう値であると見なされるべきではありません。
+コンポーネントに対して「何かをしない」という設定を許可するプロパティは `false` の値を受け入れるべきです。`null`、`''`、または `[]` がそういう値であると見なされるべきではありません。
 
 ### ディレクトリ/名前空間の名前
 
@@ -502,3 +504,4 @@ public function getEventHandlers($name)
 - 機能や特徴を表す名前には単数形を使います (例えば、web)。
 - 出来れば単一の語の名前空間にします。
 - 単一の語が適切でない場合は、camelCase を使います。
+
diff --git a/docs/internals-ja/design-decisions.md b/docs/internals-ja/design-decisions.md
index ac93554032..72682b4a98 100644
--- a/docs/internals-ja/design-decisions.md
+++ b/docs/internals-ja/design-decisions.md
@@ -25,8 +25,5 @@
    <https://github.com/yiisoft/yii/pull/1923#issuecomment-11881967>
 6. [ヘルパか、独立した非スタティックなクラスか](https://github.com/yiisoft/yii2/pull/12661#issuecomment-251599463)
 7. **セッター・メソッド・チェイニング** は、意味のある値を返すメソッドがそのクラスに存在する場合は、避けるべきである。
-   チェイニングは、クラスがビルダーであり、全てのセッターが内部状態を修正するものである場合にサポートされうる。
-   https://github.com/yiisoft/yii2/issues/13026
-8. ローカルな try-catch の替りに **グローバルな例外/エラーハンドラ** が使われる。
-   なぜなら、その方が、ブートストラップなどのように `run()` メソッドのスコープ外で発生するデストラクタなど全てのものをキャッチする点において信頼性が高いからである。
-   [#14348](https://github.com/yiisoft/yii2/issues/14348) を参照。
+   チェイニングは、クラスがビルダーであり、全てのセッターが内部状態を修正するものである場合にサポートされうる。https://github.com/yiisoft/yii2/issues/13026
+8. ローカルな try-catch の替りに **グローバルな例外/エラーハンドラ** が使われる。なぜなら、その方が、ブートストラップなどのように `run()` メソッドのスコープ外で発生するデストラクタなど全てのものをキャッチする点において信頼性が高いからである。[#14348](https://github.com/yiisoft/yii2/issues/14348) を参照。
diff --git a/docs/internals-ja/git-workflow.md b/docs/internals-ja/git-workflow.md
index a33f4e75af..6f63fdf69f 100644
--- a/docs/internals-ja/git-workflow.md
+++ b/docs/internals-ja/git-workflow.md
@@ -3,7 +3,8 @@ Yii 2 寄稿者のための Git ワークフロー
 
 で、Yii の開発に貢献したい、と。すばらしい。 
 でも、あなたの修正案が速やかに採用されるチャンスを増やすために、以下のステップを踏むようにしてください。
-あなたが git と github については初めてだという場合は、最初に [github help](http://help.github.com/) や [try git](https://try.github.com) を精査したり、[git internal data model](http://nfarina.com/post/9868516270/git-is-simpler) についていくらか学習したりする必要があるかもしれません。
+あなたが git と github については初めてだという場合は、最初に [github help](http://help.github.com/) や [try git](https://try.github.com) を精査したり、
+[git internal data model](http://nfarina.com/post/9868516270/git-is-simpler) についていくらか学習したりする必要があるかもしれません。
 
 あなたの開発環境を準備する
 --------------------------
@@ -17,7 +18,8 @@ Yii 2 寄稿者のための Git ワークフロー
 git clone git@github.com:YOUR-GITHUB-USERNAME/yii2.git
 ```
 
-Linux において、GitHub で GIT を設定するのに問題が生じたり、"Permission Denied (publickey)" のようなエラーが発生したりする場合は、[setup your GIT installation to work with GitHub](http://help.github.com/linux-set-up-git/) に従ってください。
+Linux において、GitHub で GIT を設定するのに問題が生じたり、"Permission Denied (publickey)" のようなエラーが発生したりする場合は、
+[setup your GIT installation to work with GitHub](http://help.github.com/linux-set-up-git/) に従ってください。
 
 > Tip: あなたが Git に精通していない場合は、素晴らしい無料の [プロ Git ブック](https://git-scm.com/book/en/v2) を読むことをお勧めします。
 
@@ -37,16 +39,14 @@ git remote add upstream git://github.com/yiisoft/yii2.git
 
 JavaScript を扱おうとしている場合は、
 
-- `npm install` を実行して JavaScript テスト・ツール群とその依存ライブラリをインストールします
-([Node.js と NPM のインストール](https://nodejs.org/en/download/package-manager/) は完了しているものとします)。
+- `npm install` を実行して JavaScript テスト・ツール群とその依存ライブラリをインストールします ([Node.js と NPM のインストール](https://nodejs.org/en/download/package-manager/) は完了しているものとします)。
 
 > Note: JavaScript のテストが依存している [jsdom](https://github.com/tmpvar/jsdom) ライブラリは、Node.js 4 以降を必要とします。
   Node.js 6 または 7 を使用することをより強く推奨します。
 
-  - `php build/build dev/app basic <fork>` を実行し、ベーシック・アプリケーションをクローンし、ベーシック・アプリケーションのための composer 依存パッケージをインストールします
+- `php build/build dev/app basic <fork>` を実行し、ベーシック・アプリケーションをクローンし、ベーシック・アプリケーションのための composer 依存パッケージをインストールします
   ここで `<fork>` は、`git@github.com:my_nickname/yii2-app-basic.git` のような、あなたのレポジトリのフォークの URL です。
-  あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。
-  このコマンドは外部 composer パッケージは通常どおりインストールしますが、yii2 レポジトリは現在チェックアウトされているものをリンクします。
+  あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。このコマンドは外部 composer パッケージは通常どおりインストールしますが、yii2 レポジトリは現在チェックアウトされているものをリンクします。
   これで、インストールされる全てのコードについて、一つのインスタンスを持つことになります。
   
   必要であれば、アドバンスト・アプリケーションについても同様にします: `php build/build dev/app advanced <fork>`。
@@ -68,24 +68,20 @@ phpunit をグローバルにインストールしていない場合は、代り
 テストによっては、データベースの設定と構成が必要なものがあります。
 `tests/data/config.local.php` を作成して、`tests/data/config.php` において構成されている設定を上書きすることが出来ます。
 
-取り組んでいるグループのものだけにテストを限定することが出来ます。
-例えば、バリデータと redis のためのテストだけを走らせるためには、`phpunit --group=validators,redis` とします。
+取り組んでいるグループのものだけにテストを限定することが出来ます。例えば、バリデータと redis のためのテストだけを走らせるためには、`phpunit --group=validators,redis` とします。
 利用できるグループのリストを取得するためには、`phpunit --list-groups` を実行してください。
 
 JavaScript の単体テストは、レポジトリのルート・ディレクトリで `npm test` を走らせることによって実行することが出来ます。
 
 ### エクステンション
 
-エクステンションに取り組むためには、エクステンションのレポジトリをクローンする必要があります。
-私たちは、あなたに代ってそれをするコマンドを作っています。
+エクステンションに取り組むためには、エクステンションのレポジトリをクローンする必要があります。私たちは、あなたに代ってそれをするコマンドを作っています。
 
 ```
 php build/build dev/ext <extension-name> <fork>
 ```
 
-ここで `<extension-name>` がエクステンションの名前、例えば `redis` です。
-そして `<fork>` は、`git@github.com:my_nickname/yii2-redis.git` のような、あなたのエクステンションのフォークの URL です。
-あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。
+ここで `<extension-name>` がエクステンションの名前、例えば `redis` です。そして `<fork>` は、`git@github.com:my_nickname/yii2-redis.git` のような、あなたのエクステンションのフォークの URL です。あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。
 
 エクステンションをアプリケーション・テンプレートのどちらかでテストしたい場合は、通常そうするように、アプリケーションの `composer.json` にそれを追加するだけです。
 例えば、ベーシック・アプリケーションの `require` セクションに `"yiisoft/yii2-redis": "~2.0.0"` を追加します。
@@ -95,6 +91,7 @@ php build/build dev/ext <extension-name> <fork>
 > Note: デフォルトの git レポジトリの Url を使うため、SSH 経由で github からクローンすることになります。
 > `build` コマンドに `--useHttp` フラグを追加すれば、代りに HTTP を使うことが出来ます。
 
+
 バグ修正と機能改良に取り組む
 ----------------------------
 
@@ -109,8 +106,7 @@ php build/build dev/ext <extension-name> <fork>
 単純な修正であれば、直接にプル・リクエストをしてください。
 こうすることで、開発チームはあなたの提案をレビューし、将来にわたって適切なフィードバックを提供することが可能になります。
 
-> 小さな変更や、ドキュメントの問題、または単純な修正については、課題を作成する必要はありません。
-  それらについては、プル・リクエストだけで十分です。
+> 小さな変更や、ドキュメントの問題、または単純な修正については、課題を作成する必要はありません。それらについては、プル・リクエストだけで十分です。
 
 ### 2. メインの Yii ブランチから最新のコードをプルする
 
@@ -122,12 +118,12 @@ git pull upstream
 
 ### 3. 現在の Yii のマスター・ブランチに基いて、あなたの寄稿のための新しいブランチを作成する
 
-> これは非常に重要です。なぜなら、master ブランチを使うと、あなたのアカウントからは一つ以上のプル・リクエストを送信することが出来なくなるからです。
+> これは非常に重要です。なぜなら、master ブランチを使うと、
+  あなたのアカウントからは一つ以上のプル・リクエストを送信することが出来なくなるからです。
 
 独立したバグ修正や変更は、各々、それ自身のブランチに入れるべきです。
 ブランチの名前は説明的なものにし、あなたのコードが関係する課題の番号で始まるようにしてください。
-特定の課題を修正するものでない場合は、番号を省略してください。
-例えば、
+特定の課題を修正するものでない場合は、番号を省略してください。例えば、
 
 ```
 git checkout upstream/master
@@ -143,8 +139,7 @@ git checkout -b 999-name-of-your-branch-goes-here
 
 ### 5. CHANGELOG を更新する
 
-CHANGELOG ファイルを編集して、あなたの修正を追加します。
-新しい行は、ファイル冒頭の最初の見出し (現在開発中のバージョン) の下に挿入してください。
+CHANGELOG ファイルを編集して、あなたの修正を追加します。新しい行は、ファイル冒頭の最初の見出し (現在開発中のバージョン) の下に挿入してください。
 チェンジログの行は、下記のどちらかのように書いてください。
 
 ```
@@ -196,7 +191,8 @@ git push -u origin 999-name-of-your-branch-goes-here
 
 ### 9. upstream に対して [プルリクエスト](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) を発行する
 
-github 上のあなたのリポジトリに入って、"Pull Request" をクリックし、右側にあるブランチを選び、コメント・ボックスにもう少し詳細を記述します。
+github 上のあなたのリポジトリに入って、"Pull Request" をクリックし、右側にあるブランチを選び、
+コメント・ボックスにもう少し詳細を記述します。
 プル・リクエストを課題とリンクさせるために、プル・コメントのどこかに `#999` という書式で課題番号を記載します。
 
 > 全てのプル・リクエストはそれぞれ一つの課題を解決すべきものであることに注意してください。
@@ -204,15 +200,14 @@ github 上のあなたのリポジトリに入って、"Pull Request" をクリ
 ### 10. 誰かがあなたのコードをレビューする
 
 誰かがあなたのコードをレビューします。あなたは修正を求められるかも知れません。その場合は、ステップ #6 に戻ってください
-(現在のプル・リクエストが open である限りは、別の新しいプル・リクエストをする必要はありません)。
-あなたのコードが受け入れられた場合は、コードはメイン・ブランチにマージされて、次回の Yii のリリースの一部となります。
-受け入れられなくても、落胆しないでください。
-必要とする機能は人によってさまざまに異なりますし、Yii は全ての人に対して全てを提供することは出来ません。
+(現在のプル・リクエストが open である限りは、別の新しいプル・リクエストをする必要はありません)。あなたのコードが受け入れられた場合は、コードはメイン・ブランチにマージされて、次回の Yii のリリースの一部となります。
+受け入れられなくても、落胆しないでください。必要とする機能は人によってさまざまに異なりますし、Yii は全ての人に対して全てを提供することは出来ません。
 また、却下された場合でも、あなたのコードはそれを必要とする人々から参照されるように github 上で公開され続けます。
 
 ### 11. クリーンアップする
 
-あなたのコードが受け入れられるか却下されるかした後、あなたが作業してきたブランチをローカル・レポジトリおよび `origin` から削除することが出来ます。
+あなたのコードが受け入れられるか却下されるかした後、あなたが作業してきたブランチをローカル・レポジトリおよび 
+`origin` から削除することが出来ます。
 
 ```
 git checkout master
@@ -223,15 +218,14 @@ git push origin --delete 999-name-of-your-branch-goes-here
 ### 注意:
 
 退行 (regression) を早期に発見するために、github 上の Yii コード・ベースへのマージは、すべて [Travis CI](http://travis-ci.org) に取り上げられて、自動化されたテストにかけられます。
-コア・チームとしては、このサービスに過大な負担をかけたくないために、以下の場合にはマージの説明に [`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build) が含まれるようにしてください。
-すなわち、プル・リクエストが、
+コア・チームとしては、このサービスに過大な負担をかけたくないために、以下の場合にはマージの説明に 
+[`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build) が含まれるようにしてください。
+すなわち、プル・リクエストが下記のものである場合がそうです。
 
 * javascript、css または画像ファイルだけに影響する場合
 * ドキュメントを更新する場合
 * 固定の文字列だけを修正する (例えば、翻訳をアップデートする) 場合
 
-がそうです。
-
 このようにすることによって、そもそもテストによってカバーされない変更に対しては、travis がテスト・ランを開始しないようにすることが出来ます。
 
 ### コマンド概要 (上級の寄稿者向け)
diff --git a/docs/internals-ja/project-organization.md b/docs/internals-ja/project-organization.md
index 85985d926c..ea40adb9e6 100644
--- a/docs/internals-ja/project-organization.md
+++ b/docs/internals-ja/project-organization.md
@@ -3,18 +3,19 @@
 
 このドキュメントは Yii 2 開発レポジトリの編成を説明するものです。
  
-1. 個々のコア・エクステンションとアプリケーション・テンプレートは、[yiisoft](https://github.com/yiisoft) Github オーガニゼーションの下の *独立した* 別の Github プロジェクトとして保守されます。
+1. 個々のコア・エクステンションとアプリケーション・テンプレートは、[yiisoft](https://github.com/yiisoft) Github オーガニゼーションの下の
+*独立した* 別の Github プロジェクトとして保守されます。
     
-   エクステンションのプロジェクト名は、先頭に `yii2-` を付けます。例えば、`gii` エクステンションは `yii2-gii` です。
+   エクステンションのレポジトリ名は、先頭に `yii2-` を付けます。例えば、`gii` エクステンションは `yii2-gii` です。
    Composer のパッケージ名は Github レポジトリ名と同じで、例えば `yiisoft/yii2-gii` です。
    
-   アプリケーション・テンプレートのプロジェクト名は、先頭に `yii2-app-` を付けます。例えば、`basic` アプリケーション・テンプレートは `yii2-app-basici` です。
+   アプリケーション・テンプレートのレポジトリ名は、先頭に `yii2-app-` を付けます。例えば、`basic` アプリケーション・テンプレートは `yii2-app-basici` です。
    Composer のパッケージ名は Github レポジトリ名と同じで、例えば `yiisoft/yii2-app-basic` です。
    
    各々のエクステンション/アプリケーションのプロジェクトは、
  
    * "docs" フォルダにおいてそのチュートリアル・ドキュメントを保守します。API ドキュメントは、エクステンション/アプリケーションがリリースされるときにその場で生成されます。
-   * "tests" フォルダにおいてそれ自身のテストコードを保守します。
+   * "tests" フォルダにおいてそれ自身のテスト・コードを保守します。
    * それ自身のメッセージ翻訳やその他全ての関係するメタコードを保守します。
    * 対応する Github プロジェクトによって、課題 (issue) を追跡します。
       
@@ -28,6 +29,8 @@
    コア・フレームワークのバグと機能要望は、この Github プロジェクトのイッシュー・トラッカーによって追跡されます。
    
 3. `yiisoft/yii2-framework` レポジトリは、開発プロジェクト・レポジトリの `framework` ディレクトリのリード・オンリーな git subsplit です。
-   このレポジトリが、フレームワークのインストールに使用される Composer 公式パッケージである [yiisoft/yii2](https://packagist.org/packages/yiisoft/yii2) を提供します。
+   このレポジトリが、フレームワークのインストールに使用される Composer 公式パッケージである
+   [yiisoft/yii2](https://packagist.org/packages/yiisoft/yii2) を提供します。
 
-4. 開発するときには、[build dev/app](git-workflow.md#prepare-the-test-environment) コマンドを使って、アプリケーションとエクステンションを開発プロジェクトの構成に含めることが出来ます。
+4. 開発するときには、[build dev/app](git-workflow.md#prepare-the-test-environment) コマンドを使って、
+   アプリケーションとエクステンションを開発プロジェクトの構成に含めることが出来ます。
diff --git a/docs/internals-ja/pull-request-qa.md b/docs/internals-ja/pull-request-qa.md
index 6750a046c4..5526ef9bdc 100644
--- a/docs/internals-ja/pull-request-qa.md
+++ b/docs/internals-ja/pull-request-qa.md
@@ -7,4 +7,5 @@ PR をマージできるか否かをチェックするときには、特に以
 - 単体テスト。必須ではありませんが、大いに歓迎されます。PR によって修正されるコードが無ければ失敗する、というテストであること。
 - CHANGELOG のエントリがあること。エントリは次のリリースのセクションに、課題のタイプと番号の順に書き入れます。
   担当した者のニックネームがあること。
-- [コード・スタイル](core-code-style.md) および [ビュー・コード・スタイル](view-code-style.md) が OK であること。これらは、マージされる際に、マージする者の判断に従って修正される場合があります。
+- [コード・スタイル](core-code-style.md) および [ビュー・コード・スタイル](view-code-style.md) が OK であること。
+  これらは、マージされる際に、マージする者の判断に従って修正される場合があります。
diff --git a/docs/internals-ja/release.md b/docs/internals-ja/release.md
index 70acc9b5fe..c2bad01597 100644
--- a/docs/internals-ja/release.md
+++ b/docs/internals-ja/release.md
@@ -12,9 +12,11 @@
 リリース・コマンド
 ------------------
 
-リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソール・コマンド](../../build/controllers/ReleaseController.php) によって自動化されています。
+リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソール・コマンド](../../build/controllers/ReleaseController.php)
+によって自動化されています。
 
-リリース・コマンドは、フレームワークの `build` ディレクトリに含まれている Yii アプリケーションを使って呼び出すことが出来ます。
+リリース・コマンドは、フレームワークの `build` ディレクトリに含まれている Yii
+アプリケーションを使って呼び出すことが出来ます。
 
     ./build/build help release  # このコマンドをフレームワークのレポジトリのルートで実行します
 
@@ -36,7 +38,8 @@
 
     ./build/build dev/app basic
 
-このインストール方法によって、エクステンションが現在のレポジトリの状態と同じフレームワーク・コードを使用する事を保証することが出来ます。
+このインストール方法によって、エクステンションが現在のレポジトリの状態と同じフレームワーク・コードを使用する事を
+保証することが出来ます。
 
 ### バージョンの概要
 
@@ -65,8 +68,10 @@
 
 #### 新しいメジャー・バージョン、例えば 2.1.0 をリリースする
 
-新しいメジャー・バージョンのリリースは、[バージョン規約](versions.md) で説明されているように、ブランチの変更を伴います。
-以下は、`master` から派生した `2.1` ブランチ上で開発されている `2.1.0` バージョンをリリースする例を示すものです。
+新しいメジャー・バージョンのリリースは、[バージョン規約](versions.md) で説明されているように、
+ブランチの変更を伴います。
+以下は、`master` から派生した `2.1` ブランチ上で開発されている 
+`2.1.0` バージョンをリリースする例を示すものです。
 リリース前においては `master` は `2.0.x` の諸バージョンを含んでいます。
 
 - `master` から新しいブランチ `2.0` を作成する
@@ -77,3 +82,4 @@
 - `2.1` ブランチを削除する
 
 `master` をチェックアウトし、`--version=2.1.0` オプションを付けて、リリース・コマンドを実行する。
+
diff --git a/docs/internals-ja/report-an-issue.md b/docs/internals-ja/report-an-issue.md
index 1e1be41154..6b2a41a068 100644
--- a/docs/internals-ja/report-an-issue.md
+++ b/docs/internals-ja/report-an-issue.md
@@ -18,5 +18,4 @@
 
 **課題の重複を避ける**
 
-課題を報告する前に、[既存の課題](https://github.com/yiisoft/yii2/issues) を検索して、あなたが報告しようとしている課題が既に報告されていたり解決されていたりしないかを確かめ、重複した課題を報告しないようにしてください。
-さらにまた、Yii の最新のバージョンを使ってみて、それでもまだ問題が残っているかどうかを確かめてください。
+課題を報告する前に、[既存の課題](https://github.com/yiisoft/yii2/issues) を検索して、あなたが報告しようとしている課題が既に報告されていたり解決されていたりしないかを確かめ、重複した課題を報告しないようにしてください。さらにまた、Yii の最新のバージョンを使ってみて、それでもまだ問題が残っているかどうかを確かめてください。
diff --git a/docs/internals-ja/translation-workflow.md b/docs/internals-ja/translation-workflow.md
index 5c2a37a9b0..fdeecb73c3 100644
--- a/docs/internals-ja/translation-workflow.md
+++ b/docs/internals-ja/translation-workflow.md
@@ -14,7 +14,8 @@ Yii は国際的なアプリケーションと開発者にとって役に立つ
 
 1. `framework/messages/config.php` をチェックして、あなたの言語が `languages` のリストに載っていることを確認してください。
    もし無ければ、あなたの言語をそこに追加します (リストをアルファベット順に保つことを忘れないでください)。
-   言語コードの形式は、例えば `ru` や `zh-CN` のように、[IETF言語タグ](http://ja.wikipedia.org/wiki/IETF%E8%A8%80%E8%AA%9E%E3%82%BF%E3%82%B0) に従うべきです。
+   言語コードの形式は、例えば `ru` や `zh-CN` のように、
+   [IETF言語タグ](http://ja.wikipedia.org/wiki/IETF%E8%A8%80%E8%AA%9E%E3%82%BF%E3%82%B0) に従うべきです。
 2. `framework` に入って、`./yii message/extract @yii/messages/config.php --languages=<your_language>` を走らせます。
 3. `framework/messages/your_language/yii.php` のメッセージを翻訳します。ファイルは必ず UTF-8 エンコーディングを使って保存してください。
 4. [プル・リクエスト](git-workflow.md) をします。
@@ -25,8 +26,7 @@ Yii は国際的なアプリケーションと開発者にとって役に立つ
 翻訳ファイルの中で、配列の各要素は、メッセージ(キー)と翻訳(値)をあらわします。
 値が空文字列の場合は、メッセージは翻訳されないものと見なされます。
 翻訳が不要になったメッセージは、翻訳が一組の '@@' マークで囲まれます。
-メッセージ文字列は複数形書式とともに使うことが出来ます。
-詳細はガイドの [国際化](../guide-ja/tutorial-i18n.md) の節を参照してください。
+メッセージ文字列は複数形書式とともに使うことが出来ます。詳細はガイドの [国際化](../guide-ja/tutorial-i18n.md) の節を参照してください。
 
 ドキュメント
 ------------
@@ -35,7 +35,8 @@ Yii は国際的なアプリケーションと開発者にとって役に立つ
 ここで `<original>` は、`guide` や `internals` などの元の文書の名前であり、`<language>` は文書の翻訳先の言語コードです。
 例えば、ロシア語のガイドの翻訳は `docs/guide-ru` です。
 
-初期の仕事が完了した後は、最新の翻訳以後に変更されたソース文書の箇所を取得するために、`build` ディレクトリにある専用のコマンドを使うことが出来ます。
+初期の仕事が完了した後は、最新の翻訳以後に変更されたソース文書の箇所を取得するために、
+`build` ディレクトリにある専用のコマンドを使うことが出来ます。
 
 ```
 php build translation "../docs/guide" "../docs/guide-ru" "Russian guide translation report" > report_guide_ru.html
diff --git a/docs/internals-ja/versions.md b/docs/internals-ja/versions.md
index 133d3a1467..2a85d5d47c 100644
--- a/docs/internals-ja/versions.md
+++ b/docs/internals-ja/versions.md
@@ -29,6 +29,7 @@ Yii バージョン規約
 * プレ・リリースが必要: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc`
 * 大きなニュース・リリースとマーケティング努力を必要とする。
 
+
 ## `2.x.Y`: マイナー・リリース
 
 ほぼ後方互換であるマイナー・リリースです。
@@ -36,14 +37,15 @@ Yii バージョン規約
 しかし、すべてを 100% 後方互換に保つことが常に可能である訳ではありませんので、アップグレードに関するノートが `UPGRADE.md` に記録されます。
 実際の運用では、2.0.x はより頻繁にリリースされるので、小さな機能改良の追加も行って、ユーザが新機能をより早く享受できるようにしています。
 
-* 主としてバグ修正と小さな機能強化を含む。
-* 大きな機能拡張や修正はしない。
-* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。ごく少数の例外は許容されるが、その場合は `UPGRADE.md` に記録される。
+* 主としてバグ修正と機能強化を含む。
+* 不安無しのアップグレードを保証するために、ほぼ後方互換でなければならない。
+  ごく少数の例外は許容されるが、その場合は `UPGRADE.md` に記録される。
 * リリースのサイクルは1～2ヶ月程度。
 * プレ・リリース (alpha, beta, RC) は不要。
 * 継続的に (少なくとも週に一回は手作業で) マスター・ブランチにマージ・バックされるべき。
 * ニュースによる広報を伴う。プロジェクト・サイトがアップデートされる。
 
+
 ### `2.x.y.Z`: パッチ・リリース
 
 バグ修正のみを含む、100% 後方互換であるべき、パッチ・リリースです。
@@ -62,7 +64,7 @@ Yii バージョン規約
 * `master` ブランチは、現在の安定版メジャー・リリースの開発ブランチで、現在は `2.0.x` バージョンです。
 * 各メジャー・リリースは、そのバージョン番号の名前を持つブランチ上で開発されます。例えば、`2.1`。
 * メジャー・リリース `2.n` の準備が出来たら、`master` から `2.(n-1).x` と名付けられた保守ブランチを作成します。
-例えば、バージョン `2.1.0` が安定版としてリリースされ、`master` 上で開発されるようになると、`2.0` ブランチが作成されます。
+  例えば、バージョン `2.1.0` が安定版としてリリースされ、`master` 上で開発されるようになると、`2.0` ブランチが作成されます。
   ([composer branch naming schema](https://getcomposer.org/doc/02-libraries.md#branches) を参照).
 * パッチ・リリースをマークするために `2.x.y.z` というタグと `2.x.y` ブランチを作成します。`0` は省略されます。
 * `2.n.x` 保守ブランチ上の変更は、継続的に `master` ブランチにマージ・バックされます。
@@ -74,8 +76,7 @@ Yii バージョン規約
 
 ## リリース
 
-フレームワークと公式エクステンションのプロジェクトは、お互いに独立にリリースされます。
-すなわち、すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。
+フレームワークと公式エクステンションのプロジェクトは、お互いに独立にリリースされます。すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。
 アプリケーション・テンプレートは、常に、フレームワークと同時にリリースされます。
 
 上記で説明されたリリース・サイクルは、コア・フレームワークにのみ適用されます。
diff --git a/docs/internals-ja/view-code-style.md b/docs/internals-ja/view-code-style.md
index 81800863e6..3c39c56b92 100644
--- a/docs/internals-ja/view-code-style.md
+++ b/docs/internals-ja/view-code-style.md
@@ -1,10 +1,7 @@
 Yii 2 ビュー・コード・スタイル
 ==============================
 
-下記のコード・スタイルが Yii 2.x コアと公式エクステンションのビュー・ファイルに用いられています。
-私たちは、あなたが自分のアプリケーションにこのコード・スタイルを使うことを強制するものではありません。
-あなたにとってより良いコード・スタイルを自由に選んでください。
-
+下記のコード・スタイルが Yii 2.x コアと公式エクステンションのビュー・ファイルに用いられています。私たちは、あなたが自分のアプリケーションにこのコード・スタイルを使うことを強制するものではありません。あなたにとってより良いコード・スタイルを自由に選んでください。
 
 ```php
 <?php