docs/internals-ja updated [ci skip]

docs/internals-ja/README.md

@@ -0,0 +1,43 @@
+Yii 開発者ドキュメント
+======================
+
+このディレクトリは、Yii フレームワークの開発とリリースプロセスに関するドキュメントを含んでいます。
+
+寄稿者のためのガイドライン
+--------------------------
+
+- [課題を報告する仕方](report-an-issue.md)
+- [始めよう](getting-started.md)
+- [Yii 2 寄稿者のための Git ワークフロー](git-workflow.md) - 開発環境をセットアップして Yii に対する寄稿を始めるためのステップバイステップのガイド。
+- [Yii2 コアフレームワークコードスタイル](core-code-style.md)
+- [Yii2 ビューコードスタイル](view-code-style.md)
+
+
+ドキュメント
+------------
+
+- [翻訳ステータス](translation-status.md) - どのドキュメントが翻訳できる状態か。
+- [翻訳チーム](translation-teams.md)
+- [翻訳ワークフロー](translation-workflow.md)
+
+
+フレームワーク開発
+------------------
+
+- [プルリクエストの品質保証](pull-request-qa.md)
+- [自動化されるタスク](automation.md) コードスタイルの修正、ドキュメントやファイルの自動生成など。
+- [設計上の決定](design-decisions.md) - よく議論される事柄についての FAQ 形式の声明リスト。
+
+バージョニングとリリース
+------------------------
+
+- [プロジェクトの編成](project-organization.md)
+- [Yii のバージョニング](versions.md)
+- [新しいバージョンのリリース](release.md)
+
+その他
+------
+
+### 例外の階層
+
+![Yii フレームワークの例外階層](exception_hierarchy.png)

docs/internals-ja/automation.md

@@ -13,3 +13,8 @@ Yii の開発に取り組む際に、自動化できるタスクがいくつか
   `./build/build php-doc/fix` を実行して修正してください。
   このコマンドは完璧なものではないため、望ましくない変更があるかもしれませんので、コミットする前に変更点をチェックしてください。
   `git add -p` を使って変更をレビューすることが出来ます。
+
+- Mime 型マジックファイル (`framework/helpers/mimeTypes.php`) の Apache HTTPd レポジトリによる更新。
+  `./build/build mime-type` を実行してファイルを更新して下さい。
+
+上記のコマンドの全てが [release process]() に含まれています。これらをリリースの間に実行しても構いませんが、必要ではありません。

docs/internals-ja/core-code-style.md

@@ -1,5 +1,5 @@
-Yii2 コアフレームワークのコードスタイル
-=======================================
+Yii2 コアフレームワークコードスタイル
+=====================================
 
 下記のコードスタイルが Yii 2.x コアと公式エクステンションの開発に用いられています。
 コアに対してコードをプルリクエストをしたいときは、これを使用することを考慮してください。

docs/internals-ja/git-workflow.md

@@ -27,7 +27,7 @@ Yii をクローンしたディレクトリ、通常は "yii2" に入って、
 git remote add upstream git://github.com/yiisoft/yii2.git
 ```
 
-### 3. テスト環境を準備する
+### 3. テスト環境を準備する <span id="prepare-the-test-environment"></span
 
 以下のステップは、翻訳またはドキュメントだけに取り組みたい場合は、必要ではありません。
 

docs/internals-ja/project-organization.md

@@ -0,0 +1,33 @@
+プロジェクトの編成
+==================
+
+このドキュメントは Yii2 開発レポジトリの編成を説明するものです。
+ 
+1. 個々のコアエクステンションとアプリケーションテンプレートは、[yiisoft](https://github.com/yiisoft) Github オーガニゼーションの下の *独立した* 別の Github プロジェクトとして保守されます。
+    
+   エクステンションのプロジェクト名は、先頭に `yii2-` を付けます。例えば、`gii` エクステンションは `yii2-gii` です。
+   Composer のパッケージ名は Github レポジトリ名と同じで、例えば `yiisoft/yii2-gii` です。
+   
+   アプリケーションテンプレートのプロジェクト名は、先頭に `yii2-app-` を付けます。例えば、`basic` アプリケーションテンプレートは `yii2-app-basici` です。
+   Composer のパッケージ名は Github レポジトリ名と同じで、例えば `yiisoft/yii2-app-basic` です。
+   
+   各々のエクステンション/アプリケーションのプロジェクトは、
+ 
+   * "docs" フォルダにおいてそのチュートリアルドキュメントを保守します。API ドキュメントは、エクステンション/アプリケーションがリリースされるときにその場で生成されます。
+   * "tests" フォルダにおいてそれ自身のテストコードを保守します。
+   * それ自身のメッセージ翻訳やその他全ての関係するメタコードを保守します。
+   * 対応する Github プロジェクトによって、課題 (issue) を追跡します。
+      
+   エクステンションのレポジトリは、必要に応じて、個別にリリースされます。アプリケーションテンプレートはフレームワークとともにリリースされます。
+   詳細は [バージョンポリシー](versions.md) を参照して下さい。
+
+2. `yiisoft/yii2` プロジェクトが、Yii2 フレームワーク開発のためのメインレポジトリです。
+   このレポジトリは Composer パッケージ [yiisoft/yii2-dev](https://packagist.org/packages/yiisoft/yii2-dev) を提供します。
+   これは、コアフレームワークコード、フレームワークの単体テスト、決定版ガイド、そして、フレームワーク開発とリリースのための一組のビルドツールを含んでいます。
+   
+   コアフレームワークのバグと機能要望は、この Github プロジェクトのイッシュートラッカーによって追跡されます。
+   
+3. `yiisoft/yii2-framework` レポジトリは、開発プロジェクトレポジトリの `framework` ディレクトリのリードオンリーな git subsplit です。
+   このレポジトリが、フレームワークのインストールに使用される Composer 公式パッケージである [yiisoft/yii2](https://packagist.org/packages/yiisoft/yii2) を提供します。
+
+4. 開発するときには、[build dev/app](git-workflow.md#prepare-the-test-environment) コマンドを使って、アプリケーションとエクステンションを開発プロジェクトの構成に含めることが出来ます。

docs/internals-ja/pull-request-qa.md

@@ -1,10 +1,10 @@
 プルリクエストの品質保証
 ========================
 
-PR をマージするか否かをチェックするときには、特に以下の基準が考慮されるべきです。
+PR をマージできるか否かをチェックするときには、特に以下の基準が考慮されるべきです。
 
 - PR にリンクされている課題(イッシュー)が存在するか、または、PR がどのようなことを修正ないし追加しようとしているのかに関する十分な説明があること。
-- 単体テスト。必須ではありませんが、非常に高く評価されます。PR によって修正されたコードが無ければ失敗する、というテストであること。
-- CHANGELOG のエントリがあること。エントリは次のリリースのセクションに、イッシューのタイプと番号の順に書き入れます。
+- 単体テスト。必須ではありませんが、大いに歓迎されます。PR によって修正されるコードが無ければ失敗する、というテストであること。
+- CHANGELOG のエントリがあること。エントリは次のリリースのセクションに、課題のタイプと番号の順に書き入れます。
   担当した者のニックネームがあること。
 - [コードスタイル](core-code-style.md) および [ビューコードスタイル](view-code-style.md) が OK であること。これらは、マージされる際に、マージする者の判断に従って修正される場合があります。

docs/internals-ja/release.md

@@ -0,0 +1,69 @@
+新しいバージョンのリリース
+==========================
+
+フレームワークのリリースを作成するのに必要とされる手順のリストは、時とともに長くなり、手作業で管理するのが困難になっています。
+そのため、どの手順も忘れられることが無いように、コマンドラインツールを作成しました。
+
+リリースの手順の概要
+--------------------
+
+- ...
+
+リリースコマンド
+----------------
+
+リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソールコマンド](../../build/controllers/ReleaseController.php) によって自動化されています。
+
+リリースコマンドは、フレームワークの `build` ディレクトリに含まれている Yii アプリケーションを使って呼び出すことが出来ます。
+
+    ./build/build help release  # このコマンドをフレームワークのレポジトリのルートで実行します
+
+> Info: コマンドを `--dryRun` オプションを付けて実行すると、どのようになるかを見ることが出来ます。
+> このオプションを使うと、変更は何もなされず、どんなコミットやタグも生成されたり、プッシュされたりしません。
+
+### 必要条件
+
+リリースコマンドは、[Git ワークフローのドキュメント](git-workflow.md#extensions) で紹介されている開発環境に依存しています。
+すなわち、アプリケーションテンプレートは `/apps/` の下に配置されていなければならず、
+エクステンションは `/extensions/` の下に配置されていなければなりません。
+`dev/app` コマンドを使うと、この構成がデフォルトで作成されます。
+
+### バージョンの概要
+
+フレームワークとエクステンションのバージョンについて概要を把握したいときは、以下を実行することが出来ます。
+
+    ./build/build release/info
+
+全てのレポジトリのタグを取得するために `--update` を指定して実行し、最新の情報を取得することも出来ます。
+
+### リリースを作成する
+
+フレームワークのリリースの作成では、下記のコマンドの実行します (アプリケーションは常にフレームワークと一緒にリリースされます)。
+
+    ./build release framework
+    ./build release app-basic
+    ./build release app-advanced
+
+エクステンションのリリースの作成では、実行するコマンドは一つだけです (例えば、redis なら)
+
+    ./build release redis
+
+リリースコマンドは、デフォルトでは、現在チェックアウトされているブランチを元に新しいマイナーバージョンをリリースします。
+デフォルトと異なるバージョンをリリースするためには、`--version` オプションを使ってバージョンを指定する必要があります。例えば、
+`--version=2.1.0`, or `--version=2.1.0-beta`.
+
+
+#### 新しいメジャーバージョン、例えば 2.1.0 をリリースする
+
+新しいメジャーバージョンのリリースは、[バージョン規約](versions.md) で説明されているように、ブランチの変更を伴います。
+以下は、`master` から派生した `2.1` ブランチ上で開発されている `2.1.0` バージョンをリリースする例を示すものです。
+リリース前においては `master` は `2.0.x` の諸バージョンを含んでいます。
+
+- `master` から新しいブランチ `2.0` を作成する
+- composer.json がこのブランチに対するブランチエイリアスを含まないようにする
+- 必要な変更を `master` から `2.1` にマージする
+- `master` が `2.1` の最新のコミットを指すようにする
+- composer.json のマスターに対するブランチエイリアスを `2.1.x-dev` とする
+- `2.1` ブランチを削除する
+
+`master` をチェックアウトし、`--version=2.1.0` オプションを付けて、リリースコマンドを実行する。

docs/internals-ja/translation-status.md

@@ -0,0 +1,4 @@
+翻訳ステータス
+==============
+
+すべてのドキュメントが翻訳可能な状態です。

docs/internals-ja/translation-teams.md

@@ -0,0 +1,65 @@
+翻訳チーム
+==========
+
+ブラジルのポルトガル語
+----------------------
+
+- **Davidson Alencar, [@davidsonalencar](https://github.com/davidsonalencar), davidson.t.i@gmail.com**
+- [@wbraganca](https://github.com/wbraganca)
+- Alan Michel Willms Quinot, [@alanwillms](https://github.com/alanwillms), dyulax@gmail.com
+
+中国語
+------
+
+- **Paris Qian Sen 东方孤思子,[@qiansen1386](https://github.com/qiansen1386),qiansen1386@gmail.com**
+- [@AbrahamGreyson 刘阳](https://github.com/AbrahamGreyson)
+- [@fmalee](https://github.com/fmalee)
+- [@funson86 花生](https://github.com/funson86)
+- [@ivantree 长兴苗木](https://github.com/ivantree)
+- [@netyum 未来](https://github.com/netyum)
+- [@riverlet 小河](https://github.com/riverlet)
+- [@yiichina 巡洋舰](https://github.com/yiichina)
+
+フィンランド語
+--------------
+
+- Jani Mikkonen, [@janisto](https://github.com/janisto), janisto@php.net
+
+ドイツ語
+--------
+
+- Carsten Brandt, [@cebe](https://github.com/cebe), mail@cebe.cc
+
+イタリア語
+----------
+
+- Lorenzo Milesi, [@maxxer](https://github.com/maxxer), maxxer@yetopen.it
+
+日本語
+------
+
+- Nobuo Kihara 木原伸夫, [@softark](https://github.com/softark), softark@gmail.com
+- Tomoki Morita, [@jamband](https://github.com/jamband), tmsongbooks215@gmail.com
+- Hisateru Tanaka, [@tanakahisateru](https://github.com/tanakahisateru), tanakahisateru@gmail.com
+
+ロシア語
+--------
+
+- **Alexander Makarov, [@samdark](https://github.com/samdark), sam@rmcreative.ru**
+- [@MUTOgen](https://github.com/MUTOgen)
+- [@prozacUa](https://github.com/prozacUa)
+
+スペイン語
+----------
+
+- Luciano Baraglia, [@lucianobaraglia](https://github.com/lucianobaraglia)
+- Marco Da Silva, [@markmarco16](https://github.com/markmarco16), markmarco16@gmail.com
+- Daniel Gómez Pan [@pana1990](https://github.com/pana1990), pana_1990@hotmail.com
+
+ウクライナ語
+------------
+
+- **Alexandr Bordun [@borales](https://github.com/Borales), admin@yiiframework.com.ua**
+- Roman Bahatyi [@RichWeber](https://github.com/RichWeber), rbagatyi@gmail.com
+- Igor Zozulinskyi [@3y3ik](https://github.com/3y3ik)
+- Vadym Chenin [@vchenin](https://github.com/vchenin), vchenin@meta.ua

docs/internals-ja/versions.md

@@ -10,41 +10,77 @@ Yii バージョン規約
 しかし、これは理想としての計画です。
 ferver の記事は、Semantic Versioning を使おうが使うまいが、これが現実には達成が困難な計画であることを示す現実世界の実例を示しています。
 
-要約すれば、私たちのバージョン付与ポリシーは次のようになります。
+要約すれば、Yii 2 に対する私たちのバージョン付与ポリシーは次のようになります。
 
+## バージョン番号
 
-## パッチリリース `2.x.Y`
-
-パッチリリースは、100% 後方互換であるべきです。
-理想的には、互換性が損なわれる可能性を減らすために、バグ修正のみを含ませたいと私たちは望んでいます。
-実際には、2.0.x はより頻繁にリリースされており、また、小さな機能改良をも追加して、ユーザが新機能をより早く享受できるようにしています。
-* `2.x` という名前のブランチ上で保守される。
-* 主としてバグ修正と小さな機能強化を含む。
-* 大きな機能拡張はしない。
-* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。唯一の例外はセキュリティ問題で、その場合は後方互換性が破られることもある。
-* リリースのサイクルは1～2ヶ月程度。
-* プレリリース (alpha, beta, RC) は不要。
-* 定期的に (少なくとも週に一回は手作業で) マスターブランチにマージバックされるべき。
+バージョン番号は `2.x.y.z` のフォーマットとします。ここで `z` が `0` であるリリースについては、`z` は省略可能です。
 
+将来出るであろう Yii バージョン 3 については、1.0 に対する 2.0 のようなものになると予想されるので、ここでは言及しません。
+このようなことは、外的な技術進歩 (たとえば PHP の 5.0 から 5.4 へのアップグレード) によって、3年から5年に一度しか生じないものと予期しています。
 
-## マイナーリリース `2.X.0`
+## `2.X.0`: メジャーリリース
 
-後方互換性を損ないうる大きな機能と変更を含む非後方互換なリリース。
-以前のバージョンからのアップグレードは簡単ではないかもしれないが、完全なアップグレードのガイド、または可能であればスクリプトが提供される。
+後方互換性を損ないうる大きな機能追加と変更を含む、非後方互換なリリースです。
+以前のバージョンからのアップグレードは簡単ではないかも知れませんが、完全なアップグレードのガイドが提供されます。
 
-* マスターブランチ上で開発。
 * 主として新機能とバグ修正を含む。
 * パッチリリースからマージされた小さな機能強化とバグ修正を含む。
 * `UPGRADE-2.X.md` ファイルに記録される非後方互換な変更を含みうる。
-* リリースのサイクルは6～8ヶ月程度。
+* リリースのサイクルはだいたい12ヶ月またはそれ以上。
 * プレリリースが必要: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc`
 * 大きなニュースリリースとマーケティング努力を必要とする。
 
+## `2.x.Y`: マイナーリリース
+
+100% 後方互換であるべき、パッチリリースです。
+理想的には、後方互換性を損なわない変更だけを含ませたいと私たちは望んでいます。
+しかし、100% の後方互換性を常に保つことは不可能ですので、アップグレードに関するノートが `UPGRADE.md` に記録されます。
+実際には、2.0.x はより頻繁にリリースされており、また、小さな機能改良をも追加して、ユーザが新機能をより早く享受できるようにしています。
+
+* 主としてバグ修正と小さな機能強化を含む。
+* 大きな機能拡張や修正はしない。
+* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。ごく少数の例外は許容されるが、その場合は `UPGRADE.md` に記録される。
+* リリースのサイクルは1～2ヶ月程度。
+* プレリリース (alpha, beta, RC) は不要。
+* 継続的に (少なくとも週に一回は手作業で) マスターブランチにマージバックされるべき。
+* ニュースによる広報を伴う。プロジェクトサイトがアップデートされる。
+
+### `2.x.y.Z`: パッチリリース
+
+バグ修正のみを含む、100% 後方互換であるべき、パッチリリースです。
+ニュースによる広報やプロジェクトサイトのアップデートはしません (ただし、重大な/セキュリティの問題についての修正を含む場合は、別です)。
+このリリースのプロセスはほぼ自動的に実行されます。
+
+* バグ修正のみを含む。機能追加はしない。
+* 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。唯一の例外はセキュリティ問題で、その場合は後方互換性が破られることもある。
+* リリースのサイクルは1～2週間程度。
+* プレリリース (alpha, beta, RC) は不要。
+* リリース時にマスターブランチにマージバックされなければならない。
+
+
+## ブランチ規約
+
+* `master` ブランチは、現在の安定版メジャーリリースの開発ブランチで、現在は `2.0.x` バージョンです。
+* 各メジャーリリースは、そのバージョン番号の名前を持つブランチ上で開発されます。例えば、`2.1`。
+* メジャーリリース `2.n` の準備が出来たら、`master` から `2.(n-1).x` と名付けられた保守ブランチを作成します。
+例えば、バージョン `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` ブランチにマージバックされます。
+
+次の図は、各ブランチ上でのコミット履歴の経時的な変化を説明したものです。
+
+![ブランチ規約](versions-branches.png)
+
 
-## メジャーリリース `X.0.0`
+## リリース
 
-1.0 に対する 2.0 など。
-これは外部的な技術の進歩 (例えば、PHP が 5.0 から 5.4 へアップグレードされた、など) に依存して、3年から5年の間に一度だけ生じるものであると私たちは予想しています。
+Yii 2 フレームワークと公式エクステンションのプロジェクトは、ともに、上述のバージョン規約およびブランチ規約に従います。
+ただし、フレームワークと公式エクステンションのプロジェクトは、お互いに独立にリリースされます。
+すなわち、すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。
+アプリケーションテンプレートは、常に、フレームワークと同時にリリースされます。
 
-> Note: 公式エクステンションも同じバージョン付与ポリシーに従っていますが、フレームワークとは独立にリリースされることがあります。
-  すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。
+上記で説明されたリリースサイクルは、コアフレームワークにのみ適用されます。
+エクステンションは必要に応じてリリースされます。
+エクステンションは、何らバグ修正や機能拡張を受けずに、長期間にわたって新しいリリースを持たないことがあり得ます。

docs/internals-ja/view-code-style.md

@@ -1,5 +1,5 @@
-Yii2 ビューのコードスタイル
-===========================
+Yii2 ビューコードスタイル
+=========================
 
 下記のコードスタイルが Yii 2.x コアと公式エクステンションのビューファイルに用いられています。
 私たちは、あなたが自分のアプリケーションにこのコードスタイルを使うことを強制するものではありません。