diff --git a/docs/internals-ja/README.md b/docs/internals-ja/README.md index 446f038..4e2459a 100644 --- a/docs/internals-ja/README.md +++ b/docs/internals-ja/README.md @@ -1,16 +1,16 @@ Yii 開発者ドキュメント ====================== -このディレクトリは、Yii フレームワークの開発とリリースプロセスに関するドキュメントを含んでいます。 +このディレクトリは、Yii フレームワークの開発とリリース・プロセスに関するドキュメントを含んでいます。 寄稿者のためのガイドライン -------------------------- - [課題を報告する仕方](report-an-issue.md) - [始めよう](getting-started.md) -- [Yii 2 寄稿者のための Git ワークフロー](git-workflow.md) - 開発環境をセットアップして Yii に対する寄稿を始めるためのステップバイステップのガイド。 -- [Yii 2 コアフレームワークコードスタイル](core-code-style.md) -- [Yii 2 ビューコードスタイル](view-code-style.md) +- [Yii 2 寄稿者のための Git ワークフロー](git-workflow.md) - 開発環境をセットアップして Yii に対する寄稿を始めるためのステップ・バイ・ステップのガイド。 +- [Yii 2 コア・フレームワーク・コード・スタイル](core-code-style.md) +- [Yii 2 ビュー・コード・スタイル](view-code-style.md) ドキュメント @@ -25,7 +25,7 @@ Yii 開発者ドキュメント ------------------ - [プルリクエストの品質保証](pull-request-qa.md) -- [自動化されるタスク](automation.md) コードスタイルの修正、ドキュメントやファイルの自動生成など。 +- [自動化されるタスク](automation.md) コード・スタイルの修正、ドキュメントやファイルの自動生成など。 - [設計上の決定](design-decisions.md) - よく議論される事柄についての FAQ 形式の声明リスト。 バージョニングとリリース diff --git a/docs/internals-ja/automation.md b/docs/internals-ja/automation.md index a4bc913..4019b9f 100644 --- a/docs/internals-ja/automation.md +++ b/docs/internals-ja/automation.md @@ -3,18 +3,18 @@ Yii の開発に取り組む際に、自動化できるタスクがいくつかあります: -- フレームワークのルートディレクトリに配置されるクラスマップ `classes.php` の生成。 +- フレームワークのルート・ディレクトリに配置されるクラス・マップ `classes.php` の生成。 `./build/build classmap` を実行して生成してください。 -- クラスファイルの中の、ゲッターとセッターによって導入されるプロパティを記述する `@property` 注釈の生成。 +- クラス・ファイルの中の、ゲッターとセッターによって導入されるプロパティを記述する `@property` 注釈の生成。 `./build/build php-doc/property` を実行して注釈を更新してください。 -- コードスタイルと phpdoc コメントの細かい問題の修正。 +- コード・スタイルと phpdoc コメントの細かい問題の修正。 `./build/build php-doc/fix` を実行して修正してください。 このコマンドは完璧なものではないため、望ましくない変更があるかもしれませんので、コミットする前に変更点をチェックしてください。 `git add -p` を使って変更をレビューすることが出来ます。 -- Mime タイプマジックファイル (`framework/helpers/mimeTypes.php`) の Apache HTTPd レポジトリによる更新。 +- Mime タイプ・マジック・ファイル (`framework/helpers/mimeTypes.php`) の Apache HTTPd レポジトリによる更新。 `./build/build mime-type` を実行してファイルを更新して下さい。 - CHANGELOG ファイルのエントリの出現順序は、`./build/build release/sort-changelog framework` diff --git a/docs/internals-ja/bc.md b/docs/internals-ja/bc.md index 2339fa2..2975864 100644 --- a/docs/internals-ja/bc.md +++ b/docs/internals-ja/bc.md @@ -1,28 +1,28 @@ # 後方互換性 -私たちは `2.x.y.Z` のようなパッチリリースにおいては厳密に後方互換性を保持するように努めるとともに、 -`2.x.Y` のようなマイナーリリースにおいても修正が必要となるような後方互換性の無い変更を避けるように努めています。 +私たちは `2.x.y.Z` のようなパッチ・リリースにおいては厳密に後方互換性を保持するように努めるとともに、 +`2.x.Y` のようなマイナー・リリースにおいても修正が必要となるような後方互換性の無い変更を避けるように努めています。 バージョン番号については [Yii バージョン規約](versions.md) を参照して下さい。 ## 使用 -### インターフェイス +### インタフェイス -ユースケース | 後方互換? +ユース・ケース | 後方互換? -------------|---------- -インターフェイスのタイプヒント | Yes -インターフェイス・メソッドの呼び出し | Yes -**インターフェイスの実装における ...** | +インタフェイスのタイプ・ヒント | Yes +インタフェイス・メソッドの呼び出し | Yes +**インタフェイスの実装における ...** | メソッドの実装 | Yes 実装済みメソッドへの引数の追加 | Yes 引数のデフォルト値の追加 | Yes ### クラス -ユースケース | 後方互換? +ユース・ケース | 後方互換? -------------|---------- -クラスのタイプヒント | Yes +クラスのタイプ・ヒント | Yes 新しいインスタンスの作成 | Yes クラスの拡張 | Yes パブリック・プロパティへのアクセス | Yes @@ -44,26 +44,26 @@ ## 開発 -### インターフェイスの変更 +### インタフェイスの変更 変更のタイプ | 後方互換? -------------|---------- 削除 | No 名前または名前空間の変更 | No -親のインターフェイスの追加 | 新しいメソッドが追加されなければ Yes -親のインターフェイスの削除 | No -**インターフェイス・メソッド** | +親のインタフェイスの追加 | 新しいメソッドが追加されなければ Yes +親のインタフェイスの削除 | No +**インタフェイス・メソッド** | メソッドの追加 | No メソッドの削除 | No 名前の変更 | No -親のインターフェイスへの移動 | Yes +親のインタフェイスへの移動 | Yes デフォルト値を持たない引数の追加 | No デフォルト値を持つ引数の追加 | No 引数の削除 | Yes (末尾の一つまたは複数の引数のみ) 引数のデフォルト値の追加 | No 引数のデフォルト値の削除 | No -引数のタイプヒントの追加 | No -引数のタイプヒントの削除 | No +引数のタイプ・ヒントの追加 | No +引数のタイプ・ヒントの削除 | No 引数の型の変更 | No 戻り値の型の変更 | No **定数** | @@ -80,8 +80,8 @@ final への変更 | No abstract への変更 | No 名前または名前空間の変更 | No 親クラスの変更 | Yes ただし元の親クラスは祖先クラス(祖父母クラスなど)として残らなければならない -インターフェイスの追加 | Yes -インターフェイスの削除 | No +インタフェイスの追加 | Yes +インタフェイスの削除 | No **パブリック・プロパティ** | パブリック・プロパティの追加 | Yes パブリック・プロパティの削除 | No @@ -95,10 +95,10 @@ abstract への変更 | No **プライベート・プロパティ** | プライベート・プロパティの追加 | Yes プライベート・プロパティの削除 | Yes -**コンストラクター** | -コンストラクターの削除 | No -パブリック・コンストラクターの可視性低減 | No -プロテクト・コンストラクターの可視性低減 | No +**コンストラクタ** | +コンストラクタの削除 | No +パブリック・コンストラクタの可視性低減 | No +プロテクト・コンストラクタの可視性低減 | No 親クラスへの移動 | Yes **パブリック・メソッド** | パブリック・メソッドの追加 | Yes @@ -111,8 +111,8 @@ abstract への変更 | No 引数の削除 | Yes (末尾の一つまたは複数の引数のみ) 引数のデフォルト値の追加 | No 引数のデフォルト値の削除 | No -引数のタイプヒントの追加 | No -引数のタイプヒントの削除 | No +引数のタイプ・ヒントの追加 | No +引数のタイプ・ヒントの削除 | No 引数の型の変更 | No 戻り値の型の変更 | No **プロテクト・メソッド** | @@ -126,8 +126,8 @@ abstract への変更 | No 引数の削除 | Yes (末尾の一つまたは複数の引数のみ) 引数のデフォルト値の追加 | No 引数のデフォルト値の削除 | No -引数のタイプヒントの追加 | No -引数のタイプヒントの削除 | No +引数のタイプ・ヒントの追加 | No +引数のタイプ・ヒントの削除 | No 引数の型の変更 | No 戻り値の型の変更 | No **プライベート・メソッド** | @@ -139,8 +139,8 @@ abstract への変更 | No 引数の削除 | Yes 引数のデフォルト値の追加 | Yes 引数のデフォルト値の削除 | Yes -引数のタイプヒントの追加 | Yes -引数のタイプヒントの削除 | Yes +引数のタイプ・ヒントの追加 | Yes +引数のタイプ・ヒントの削除 | Yes 引数の方の変更 | Yes 戻り値の型の変更 | Yes **スタティック・メソッド** | diff --git a/docs/internals-ja/core-code-style.md b/docs/internals-ja/core-code-style.md index df63d1d..a2d58bd 100644 --- a/docs/internals-ja/core-code-style.md +++ b/docs/internals-ja/core-code-style.md @@ -1,21 +1,21 @@ -Yii 2 コアフレームワークコードスタイル +Yii 2 コア・フレームワーク・コード・スタイル ===================================== -下記のコードスタイルが Yii 2.x コアと公式エクステンションの開発に用いられています。 -コアに対してコードをプルリクエストをしたいときは、これを使用することを考慮してください。 -私たちは、あなたが自分のアプリケーションにこのコードスタイルを使うことを強制するものではありません。 -あなたにとってより良いコードスタイルを自由に選んでください。 +下記のコード・スタイルが 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) に適用されることは、すべて私たちのコード・スタイルにも適用されます。 - ファイルは `_e[$name])) { $this->_e[$name] = new Vector; } - $this->ensureBehaviors(); - return $this->_e[$name]; } ``` @@ -445,17 +443,17 @@ public function getEventHandlers($name) 上記の例に見られるように、phpDoc コメントの書式設定には markdown を使います。 -ドキュメントの中でクラス、メソッド、プロパティをクロスリンクするために使える追加の文法があります。 +ドキュメントの中でクラス、メソッド、プロパティをクロス・リンクするために使える追加の文法があります。 -- `[[canSetProperty]]` は、同じクラス内の `canSetProperty` メソッドまたはプロパティへのクロスリンクを生成します。 -- `[[Component::canSetProperty]]` は、同じ名前空間内の `Component` クラスの `canSetProperty` メソッドへのクロスリンクを生成します。 -- `[[yii\base\Component::canSetProperty]]` は、`yii\base` 名前空間の`Component` クラスの `canSetProperty` メソッドへのクロスリンクを生成します。 -- `[[Component]]` は、同じ名前空間内の `Component` クラスへのクロスリンクを生成します。ここでも、クラス名に名前空間を追加することが可能です。 +- `[[canSetProperty]]` は、同じクラス内の `canSetProperty` メソッドまたはプロパティへのクロス・リンクを生成します。 +- `[[Component::canSetProperty]]` は、同じ名前空間内の `Component` クラスの `canSetProperty` メソッドへのクロス・リンクを生成します。 +- `[[yii\base\Component::canSetProperty]]` は、`yii\base` 名前空間の`Component` クラスの `canSetProperty` メソッドへのクロス・リンクを生成します。 +- `[[Component]]` は、同じ名前空間内の `Component` クラスへのクロス・リンクを生成します。ここでも、クラス名に名前空間を追加することが可能です。 上記のリンクにクラス名やメソッド名以外のラベルを付けるためには、次の例で示されている文法を使うことが出来ます。 ``` -... [[header|ヘッダセル]] に表示されているように +... [[header|ヘッダ・セル]] に表示されているように ``` `|` の前の部分がメソッド、プロパティ、クラスへの参照であり、`|` の後ろの部分がリンクのラベルです。 diff --git a/docs/internals-ja/design-decisions.md b/docs/internals-ja/design-decisions.md index 5a974b6..ac93554 100644 --- a/docs/internals-ja/design-decisions.md +++ b/docs/internals-ja/design-decisions.md @@ -5,26 +5,26 @@ 非常に強固な理由があるのでない限りは、これらの決定は一貫性のために守られなければなりません。 これらの決定に対するいかなる変更もコア開発者間の同意を得なければなりません。 -1. **[いかなる時にパスエイリアスをサポートするか](https://github.com/yiisoft/yii2/pull/3079#issuecomment-40312268)** - 構成情報にパスエイリアスを使用することは非常に利便性が高いため、構成可能なプロパティに対してはパスエイリアスをサポートすべきである。 - その他の場合には、パスエイリアスに対するサポートを制限すべきである。 +1. **[いかなる時にパス・エイリアスをサポートするか](https://github.com/yiisoft/yii2/pull/3079#issuecomment-40312268)** + 構成情報にパス・エイリアスを使用することは非常に利便性が高いため、構成可能なプロパティに対してはパス・エイリアスをサポートすべきである。 + その他の場合には、パス・エイリアスに対するサポートを制限すべきである。 2. **いかなる時にメッセージを翻訳するか** - 技術者でないエンドユーザに対して表示され、また、そういうユーザに対して意味を持つメッセージは翻訳されるべきである。 - HTTP ステータスメッセージ、コードに関する例外などは翻訳されるべきではない。 - コンソールメッセージは、エンコーディングとコードページの処理に困難が伴うため、常に英語で表示されるものとする。 + 技術者でないエンド・ユーザに対して表示され、また、そういうユーザに対して意味を持つメッセージは翻訳されるべきである。 + HTTP ステータス・メッセージ、コードに関する例外などは翻訳されるべきではない。 + コンソール・メッセージは、エンコーディングとコード・ページの処理に困難が伴うため、常に英語で表示されるものとする。 3. **[認証クライアントのサポートの追加](https://github.com/yiisoft/yii2/issues/1652)** - 保守性を高めるために、コアエクステンションには認証クライアントをこれ以上追加しない。 - 認証クライアントの追加はユーザエクステンションの形でなされるべきである。 + 保守性を高めるために、コア・エクステンションには認証クライアントをこれ以上追加しない。 + 認証クライアントの追加はユーザ・エクステンションの形でなされるべきである。 4. **クロージャを使うときは**、たとえ使用されないものがある場合でも、**渡されるすべてのパラメータをシグニチャに含める** ことが推奨される。 このようにすると、全ての情報が直接に見えるので、コードの修正やコピーがより容易になり、どのパラメータが実際に利用できるかをドキュメントで調べる必要がなくなる。 ([#6584](https://github.com/yiisoft/yii2/pull/6584), [#6875](https://github.com/yiisoft/yii2/issues/6875)) -5. データベーススキーマでは **unsigned int より int** を使う。 +5. データベース・スキーマでは **unsigned int より int** を使う。 int を使うと、PHP で整数として表現できるという利点がある。 unsigned の場合、32 bit システムでは、文字列を使って表現しなければならなくなる。 また、unsigned int はサイズを倍にするとはいうものの、そのような広大な数値空間を必要とするテーブルを持っている場合は、unsigned に頼るより bigint または mediumint を使用する方が安全である。 6. [ヘルパか、独立した非スタティックなクラスか](https://github.com/yiisoft/yii2/pull/12661#issuecomment-251599463) -7. **セッターメソッドチェイニング** は、意味のある値を返すメソッドがそのクラスに存在する場合は、避けるべきである。 +7. **セッター・メソッド・チェイニング** は、意味のある値を返すメソッドがそのクラスに存在する場合は、避けるべきである。 チェイニングは、クラスがビルダーであり、全てのセッターが内部状態を修正するものである場合にサポートされうる。 https://github.com/yiisoft/yii2/issues/13026 8. ローカルな try-catch の替りに **グローバルな例外/エラーハンドラ** が使われる。 diff --git a/docs/internals-ja/git-workflow.md b/docs/internals-ja/git-workflow.md index b196157..a33f4e7 100644 --- a/docs/internals-ja/git-workflow.md +++ b/docs/internals-ja/git-workflow.md @@ -8,7 +8,7 @@ Yii 2 寄稿者のための Git ワークフロー あなたの開発環境を準備する -------------------------- -以下のステップを踏むと Yii の開発環境を作成し、それを使って Yii フレームワークのコアコードに取り組むことが出来るようになります。 +以下のステップを踏むと Yii の開発環境を作成し、それを使って Yii フレームワークのコア・コードに取り組むことが出来るようになります。 これらのステップは、あなたが最初に寄稿するときにだけ必要になります。 ### 1. github で Yii リポジトリを [Fork](http://help.github.com/fork-a-repo/) し、あなたのフォークをあなたの開発環境にクローンする @@ -37,19 +37,19 @@ git remote add upstream git://github.com/yiisoft/yii2.git JavaScript を扱おうとしている場合は、 -- `npm install` を実行して JavaScript テストツール群とその依存ライブラリをインストールします +- `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 ` を実行し、ベーシックアプリケーションをクローンし、ベーシックアプリケーションのための composer 依存パッケージをインストールします + - `php build/build dev/app basic ` を実行し、ベーシック・アプリケーションをクローンし、ベーシック・アプリケーションのための composer 依存パッケージをインストールします ここで `` は、`git@github.com:my_nickname/yii2-app-basic.git` のような、あなたのレポジトリのフォークの URL です。 - あなたがコアフレームワークの貢献者である場合は、フォークの指定を省略しても構いません。 + あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。 このコマンドは外部 composer パッケージは通常どおりインストールしますが、yii2 レポジトリは現在チェックアウトされているものをリンクします。 これで、インストールされる全てのコードについて、一つのインスタンスを持つことになります。 - 必要であれば、アドバンストアプリケーションについても同様にします: `php build/build dev/app advanced `。 + 必要であれば、アドバンスト・アプリケーションについても同様にします: `php build/build dev/app advanced `。 このコマンドは後日、依存パッケージを更新するためにも使用されます。このコマンドは内部的に `composer update` を実行します。 @@ -62,7 +62,7 @@ JavaScript を扱おうとしている場合は、 ### 単体テスト -レポジトリのルートディレクトリで `phpunit` を実行することによって単体テストを実行することが出来ます。 +レポジトリのルート・ディレクトリで `phpunit` を実行することによって単体テストを実行することが出来ます。 phpunit をグローバルにインストールしていない場合は、代りに `php vendor/bin/phpunit` を実行することが出来ます。 テストによっては、データベースの設定と構成が必要なものがあります。 @@ -72,7 +72,7 @@ phpunit をグローバルにインストールしていない場合は、代り 例えば、バリデータと redis のためのテストだけを走らせるためには、`phpunit --group=validators,redis` とします。 利用できるグループのリストを取得するためには、`phpunit --list-groups` を実行してください。 -JavaScript の単体テストは、レポジトリのルートディレクトリで `npm test` を走らせることによって実行することが出来ます。 +JavaScript の単体テストは、レポジトリのルート・ディレクトリで `npm test` を走らせることによって実行することが出来ます。 ### エクステンション @@ -85,11 +85,11 @@ php build/build dev/ext ここで `` がエクステンションの名前、例えば `redis` です。 そして `` は、`git@github.com:my_nickname/yii2-redis.git` のような、あなたのエクステンションのフォークの URL です。 -あなたがコアフレームワークの貢献者である場合は、フォークの指定を省略しても構いません。 +あなたがコア・フレームワークの貢献者である場合は、フォークの指定を省略しても構いません。 -エクステンションをアプリケーションテンプレートのどちらかでテストしたい場合は、通常そうするように、アプリケーションの `composer.json` にそれを追加するだけです。 -例えば、ベーシックアプリケーションの `require` セクションに `"yiisoft/yii2-redis": "~2.0.0"` を追加します。 -`php build/build dev/app basic ` を実行すると、エクステンションとその依存パッケージがインストールされ、`extensions/redis` に対するシンボリックリンクが作成されます。 +エクステンションをアプリケーション・テンプレートのどちらかでテストしたい場合は、通常そうするように、アプリケーションの `composer.json` にそれを追加するだけです。 +例えば、ベーシック・アプリケーションの `require` セクションに `"yiisoft/yii2-redis": "~2.0.0"` を追加します。 +`php build/build dev/app basic ` を実行すると、エクステンションとその依存パッケージがインストールされ、`extensions/redis` に対するシンボリック・リンクが作成されます。 こうすることで、composer の vendor ディレクトリではなく、直接に yii2 のレポジトリで作業をすることが出来るようになります。 > Note: デフォルトの git レポジトリの Url を使うため、SSH 経由で github からクローンすることになります。 @@ -106,11 +106,11 @@ php build/build dev/ext 数分間時間を取って、既存の課題リストに目を通し、あなたが寄稿しようとしている問題に合致するものが無いかどうか調べてください。 もし課題リストにすでに挙っているのを見つけた場合は、その課題にコメントを残して、あなたがその項目について取り組もうとしていることを示してください。 あなたが取り組もうとしている問題に合致する既存の課題が見つからなかった場合は、[新しい課題を立て](report-an-issue.md) てください。 -単純な修正であれば、直接にプルリクエストをしてください。 +単純な修正であれば、直接にプル・リクエストをしてください。 こうすることで、開発チームはあなたの提案をレビューし、将来にわたって適切なフィードバックを提供することが可能になります。 > 小さな変更や、ドキュメントの問題、または単純な修正については、課題を作成する必要はありません。 - それらについては、プルリクエストだけで十分です。 + それらについては、プル・リクエストだけで十分です。 ### 2. メインの Yii ブランチから最新のコードをプルする @@ -120,9 +120,9 @@ git pull upstream 最新のコードに対して作業することを保証するために、すべての新しい寄稿においてこのステップから作業を開始すべきです。 -### 3. 現在の Yii のマスターブランチに基いて、あなたの寄稿のための新しいブランチを作成する +### 3. 現在の Yii のマスター・ブランチに基いて、あなたの寄稿のための新しいブランチを作成する -> これは非常に重要です。なぜなら、master ブランチを使うと、あなたのアカウントからは一つ以上のプルリクエストを送信することが出来なくなるからです。 +> これは非常に重要です。なぜなら、master ブランチを使うと、あなたのアカウントからは一つ以上のプル・リクエストを送信することが出来なくなるからです。 独立したバグ修正や変更は、各々、それ自身のブランチに入れるべきです。 ブランチの名前は説明的なものにし、あなたのコードが関係する課題の番号で始まるようにしてください。 @@ -153,7 +153,7 @@ Enh #999: 機能拡張の内容説明 (あなたの名前) ``` `#999` は `Bug` または `Enh` が参照している課題番号です。 -チェンジログは、タイプ (`Bug`, `Enh`) によってグループ化し、課題番号順に並べます。 +チェンジ・ログは、タイプ (`Bug`, `Enh`) によってグループ化し、課題番号順に並べます。 非常に小さな修正、すなわち、タイポやドキュメントの修正については、CHANGELOG を更新する必要はありません。 @@ -167,7 +167,7 @@ git add path/to/my/file.php `-p` オプションを使って、コミットに含める変更を選択することも出来ます。 -説明的なコミットメッセージを付けて修正をコミットしてください。 +説明的なコミット・メッセージを付けて修正をコミットしてください。 github があなたのコミットを自動的にチケットとリンクするように、必ず `#XXX` でチケット番号に言及してください。 ``` @@ -180,9 +180,9 @@ git commit -m "#999 を解決する変更の短い説明をここに入れる" git pull upstream master ``` -このステップは、プルリクエストを出す前にあなたのブランチが最新のコードを持っていることを確実にするためのものです。 +このステップは、プル・リクエストを出す前にあなたのブランチが最新のコードを持っていることを確実にするためのものです。 もし何かマージ衝突がある場合は、ここでそれを修正してから再度変更をコミットすべきです。 -こうすると、Yii 開発チームがワンクリックであなたの変更をマージすることが確実に出来るようになります。 +こうすると、Yii 開発チームがワン・クリックであなたの変更をマージすることが確実に出来るようになります。 ### 8. 衝突をすべて解決したら、あなたのコードを github にプッシュする @@ -192,27 +192,27 @@ git push -u origin 999-name-of-your-branch-goes-here `-u` パラメータによって、今後はあなたのそのブランチが github のブランチに対して自動的にプッシュおよびプルされるようになります。 つまり、次回 `git push` とタイプしたときには、git は既にどこにプッシュすればよいか知っている、ということです。 -こうしておくと、後でプルリクエストにコミットを追加したくなった場合に便利です。 +こうしておくと、後でプル・リクエストにコミットを追加したくなった場合に便利です。 ### 9. upstream に対して [プルリクエスト](https://help.github.com/articles/creating-a-pull-request-from-a-fork/) を発行する -github 上のあなたのリポジトリに入って、"Pull Request" をクリックし、右側にあるブランチを選び、コメントボックスにもう少し詳細を記述します。 -プルリクエストを課題とリンクさせるために、プルコメントのどこかに `#999` という書式で課題番号を記載します。 +github 上のあなたのリポジトリに入って、"Pull Request" をクリックし、右側にあるブランチを選び、コメント・ボックスにもう少し詳細を記述します。 +プル・リクエストを課題とリンクさせるために、プル・コメントのどこかに `#999` という書式で課題番号を記載します。 -> 全てのプルリクエストはそれぞれ一つの課題を解決すべきものであることに注意してください。 +> 全てのプル・リクエストはそれぞれ一つの課題を解決すべきものであることに注意してください。 ### 10. 誰かがあなたのコードをレビューする 誰かがあなたのコードをレビューします。あなたは修正を求められるかも知れません。その場合は、ステップ #6 に戻ってください -(現在のプルリクエストが open である限りは、別の新しいプルリクエストをする必要はありません)。 -あなたのコードが受け入れられた場合は、コードはメインブランチにマージされて、次回の Yii のリリースの一部となります。 +(現在のプル・リクエストが open である限りは、別の新しいプル・リクエストをする必要はありません)。 +あなたのコードが受け入れられた場合は、コードはメイン・ブランチにマージされて、次回の Yii のリリースの一部となります。 受け入れられなくても、落胆しないでください。 必要とする機能は人によってさまざまに異なりますし、Yii は全ての人に対して全てを提供することは出来ません。 また、却下された場合でも、あなたのコードはそれを必要とする人々から参照されるように github 上で公開され続けます。 ### 11. クリーンアップする -あなたのコードが受け入れられるか却下されるかした後、あなたが作業してきたブランチをローカルレポジトリおよび `origin` から削除することが出来ます。 +あなたのコードが受け入れられるか却下されるかした後、あなたが作業してきたブランチをローカル・レポジトリおよび `origin` から削除することが出来ます。 ``` git checkout master @@ -222,9 +222,9 @@ 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) が含まれるようにしてください。 -すなわち、プルリクエストが、 +退行 (regression) を早期に発見するために、github 上の Yii コード・ベースへのマージは、すべて [Travis CI](http://travis-ci.org) に取り上げられて、自動化されたテストにかけられます。 +コア・チームとしては、このサービスに過大な負担をかけたくないために、以下の場合にはマージの説明に [`[ci skip]`](https://docs.travis-ci.com/user/customizing-the-build/#Skipping-a-build) が含まれるようにしてください。 +すなわち、プル・リクエストが、 * javascript、css または画像ファイルだけに影響する場合 * ドキュメントを更新する場合 @@ -232,7 +232,7 @@ git push origin --delete 999-name-of-your-branch-goes-here がそうです。 -このようにすることによって、そもそもテストによってカバーされない変更に対しては、travis がテストランを開始しないようにすることが出来ます。 +このようにすることによって、そもそもテストによってカバーされない変更に対しては、travis がテスト・ランを開始しないようにすることが出来ます。 ### コマンド概要 (上級の寄稿者向け) diff --git a/docs/internals-ja/project-organization.md b/docs/internals-ja/project-organization.md index 36ca17b..85985d9 100644 --- a/docs/internals-ja/project-organization.md +++ b/docs/internals-ja/project-organization.md @@ -3,31 +3,31 @@ このドキュメントは Yii 2 開発レポジトリの編成を説明するものです。 -1. 個々のコアエクステンションとアプリケーションテンプレートは、[yiisoft](https://github.com/yiisoft) Github オーガニゼーションの下の *独立した* 別の Github プロジェクトとして保守されます。 +1. 個々のコア・エクステンションとアプリケーション・テンプレートは、[yiisoft](https://github.com/yiisoft) Github オーガニゼーションの下の *独立した* 別の Github プロジェクトとして保守されます。 エクステンションのプロジェクト名は、先頭に `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 ドキュメントは、エクステンション/アプリケーションがリリースされるときにその場で生成されます。 + * "docs" フォルダにおいてそのチュートリアル・ドキュメントを保守します。API ドキュメントは、エクステンション/アプリケーションがリリースされるときにその場で生成されます。 * "tests" フォルダにおいてそれ自身のテストコードを保守します。 * それ自身のメッセージ翻訳やその他全ての関係するメタコードを保守します。 * 対応する Github プロジェクトによって、課題 (issue) を追跡します。 - エクステンションのレポジトリは、必要に応じて、個別にリリースされます。アプリケーションテンプレートはフレームワークとともにリリースされます。 - 詳細は [バージョンポリシー](versions.md) を参照して下さい。 + エクステンションのレポジトリは、必要に応じて、個別にリリースされます。アプリケーション・テンプレートはフレームワークとともにリリースされます。 + 詳細は [バージョン・ポリシー](versions.md) を参照して下さい。 -2. `yiisoft/yii2` プロジェクトが、Yii 2 フレームワーク開発のためのメインレポジトリです。 +2. `yiisoft/yii2` プロジェクトが、Yii 2 フレームワーク開発のためのメイン・レポジトリです。 このレポジトリは Composer パッケージ [yiisoft/yii2-dev](https://packagist.org/packages/yiisoft/yii2-dev) を提供します。 - これは、コアフレームワークコード、フレームワークの単体テスト、決定版ガイド、そして、フレームワーク開発とリリースのための一組のビルドツールを含んでいます。 + これは、コア・フレームワーク・コード、フレームワークの単体テスト、決定版ガイド、そして、フレームワーク開発とリリースのための一組のビルド・ツールを含んでいます。 - コアフレームワークのバグと機能要望は、この Github プロジェクトのイッシュートラッカーによって追跡されます。 + コア・フレームワークのバグと機能要望は、この Github プロジェクトのイッシュー・トラッカーによって追跡されます。 -3. `yiisoft/yii2-framework` レポジトリは、開発プロジェクトレポジトリの `framework` ディレクトリのリードオンリーな git subsplit です。 +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) コマンドを使って、アプリケーションとエクステンションを開発プロジェクトの構成に含めることが出来ます。 diff --git a/docs/internals-ja/pull-request-qa.md b/docs/internals-ja/pull-request-qa.md index f7ed48e..6750a04 100644 --- a/docs/internals-ja/pull-request-qa.md +++ b/docs/internals-ja/pull-request-qa.md @@ -1,5 +1,5 @@ -プルリクエストの品質保証 -======================== +プル・リクエストの品質保証 +========================== PR をマージできるか否かをチェックするときには、特に以下の基準が考慮されるべきです。 @@ -7,4 +7,4 @@ 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 0320725..70acc9b 100644 --- a/docs/internals-ja/release.md +++ b/docs/internals-ja/release.md @@ -2,19 +2,19 @@ ========================== フレームワークのリリースを作成するのに必要とされる手順のリストは、時とともに長くなり、手作業で管理するのが困難になっています。 -そのため、どの手順も忘れられることが無いように、コマンドラインツールを作成しました。 +そのため、どの手順も忘れられることが無いように、コマンドライン・ツールを作成しました。 リリースの手順の概要 -------------------- - ... -リリースコマンド ----------------- +リリース・コマンド +------------------ -リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソールコマンド](../../build/controllers/ReleaseController.php) によって自動化されています。 +リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソール・コマンド](../../build/controllers/ReleaseController.php) によって自動化されています。 -リリースコマンドは、フレームワークの `build` ディレクトリに含まれている Yii アプリケーションを使って呼び出すことが出来ます。 +リリース・コマンドは、フレームワークの `build` ディレクトリに含まれている Yii アプリケーションを使って呼び出すことが出来ます。 ./build/build help release # このコマンドをフレームワークのレポジトリのルートで実行します @@ -23,8 +23,8 @@ ### 必要条件 -リリースコマンドは、[Git ワークフローのドキュメント](git-workflow.md#extensions) で紹介されている開発環境に依存しています。 -すなわち、アプリケーションテンプレートは `/apps/` の下に配置されていなければならず、 +リリース・コマンドは、[Git ワークフローのドキュメント](git-workflow.md#extensions) で紹介されている開発環境に依存しています。 +すなわち、アプリケーション・テンプレートは `/apps/` の下に配置されていなければならず、 エクステンションは `/extensions/` の下に配置されていなければなりません。 この構成は `dev/app` および `dev/ext` のコマンドを使って作成することが推奨されます。 @@ -36,7 +36,7 @@ ./build/build dev/app basic -このインストール方法によって、エクステンションが現在のレポジトリの状態と同じフレームワークコードを使用する事を保証することが出来ます。 +このインストール方法によって、エクステンションが現在のレポジトリの状態と同じフレームワーク・コードを使用する事を保証することが出来ます。 ### バージョンの概要 @@ -58,14 +58,14 @@ ./build/build release redis -リリースコマンドは、デフォルトでは、現在チェックアウトされているブランチを元に新しいマイナーバージョンをリリースします。 +リリース・コマンドは、デフォルトでは、現在チェックアウトされているブランチを元に新しいマイナー・バージョンをリリースします。 デフォルトと異なるバージョンをリリースするためには、`--version` オプションを使ってバージョンを指定する必要があります。例えば、 `--version=2.1.0`, or `--version=2.1.0-beta`. -#### 新しいメジャーバージョン、例えば 2.1.0 をリリースする +#### 新しいメジャー・バージョン、例えば 2.1.0 をリリースする -新しいメジャーバージョンのリリースは、[バージョン規約](versions.md) で説明されているように、ブランチの変更を伴います。 +新しいメジャー・バージョンのリリースは、[バージョン規約](versions.md) で説明されているように、ブランチの変更を伴います。 以下は、`master` から派生した `2.1` ブランチ上で開発されている `2.1.0` バージョンをリリースする例を示すものです。 リリース前においては `master` は `2.0.x` の諸バージョンを含んでいます。 @@ -73,7 +73,7 @@ - composer.json がこのブランチに対するブランチエイリアスを含まないようにする - 必要な変更を `master` から `2.1` にマージする - `master` が `2.1` の最新のコミットを指すようにする -- composer.json のマスターに対するブランチエイリアスを `2.1.x-dev` とする +- composer.json のマスターに対するブランチ・エイリアスを `2.1.x-dev` とする - `2.1` ブランチを削除する -`master` をチェックアウトし、`--version=2.1.0` オプションを付けて、リリースコマンドを実行する。 +`master` をチェックアウトし、`--version=2.1.0` オプションを付けて、リリース・コマンドを実行する。 diff --git a/docs/internals-ja/report-an-issue.md b/docs/internals-ja/report-an-issue.md index cda9326..1e1be41 100644 --- a/docs/internals-ja/report-an-issue.md +++ b/docs/internals-ja/report-an-issue.md @@ -3,17 +3,17 @@ あなたが報告する課題 (issue) がより迅速に解決されるように、課題を作成するときには下記のガイドラインに従って下さい。 -* PHP と Yii のバージョン、オペレーティングシステムとウェブサーバのタイプ、および、ブラウザのタイプとバージョンについて、情報を提供してください。 -* 出来れば、**完全な**エラーのコールスタックを提供して下さい。問題を説明するスクリーンショットは大いに歓迎されます。 +* PHP と Yii のバージョン、オペレーティング・システムとウェブ・サーバのタイプ、および、ブラウザのタイプとバージョンについて、情報を提供してください。 +* 出来れば、**完全な**エラーのコール・スタックを提供して下さい。問題を説明するスクリーン・ショットは大いに歓迎されます。 * 問題を再現する手順を記述して下さい。問題を再現するコードを提供してくださるならば、なお一層良いでしょう。 -* 可能であれば、さらに進んで、失敗する単体テストを作成して [プルリクエストを発行](git-workflow.md) してくださっても構いません。 +* 可能であれば、さらに進んで、失敗する単体テストを作成して [プル・リクエストを発行](git-workflow.md) してくださっても構いません。 課題が公式エクステンションのどれかと関係がある場合は、エクステンションのレポジトリで課題を報告してください。 エクステンションとの関係がよく分らない場合は、[メインのレポジトリに報告](https://github.com/yiisoft/yii2/issues/new) () してください。 **以下の場合は課題を報告しないでください** -* Yii の何らかの機能の使い方に関する質問。この目的のためには、[フォーラム](http://www.yiiframework.com/forum/index.php/forum/42-general-discussions-for-yii-20/) または [チャットルーム](http://www.yiiframework.com/chat/) を使うべきです。 +* Yii の何らかの機能の使い方に関する質問。この目的のためには、[フォーラム](http://www.yiiframework.com/forum/index.php/forum/42-general-discussions-for-yii-20/) または [チャット・ルーム](http://www.yiiframework.com/chat/) を使うべきです。 * 問題がセキュリティに関するものである場合。セキュリティ問題を報告するときは、[開発者に直接コンタクト](http://www.yiiframework.com/security/) してください。 **課題の重複を避ける** diff --git a/docs/internals-ja/translation-workflow.md b/docs/internals-ja/translation-workflow.md index cfbc701..5c2a37a 100644 --- a/docs/internals-ja/translation-workflow.md +++ b/docs/internals-ja/translation-workflow.md @@ -2,13 +2,13 @@ ================ Yii は国際的なアプリケーションと開発者にとって役に立つように、数多くの言語に翻訳されています。 -貢献が大いに歓迎される主な領域はドキュメントとフレームワークメッセージです。 +貢献が大いに歓迎される主な領域はドキュメントとフレームワーク・メッセージです。 -フレームワークメッセージ ------------------------- +フレームワーク・メッセージ +-------------------------- フレームワークは二種類のメッセージを持っています。一つは開発者向けの例外メッセージで、これは決して翻訳されません。 -もう一つはエンドユーザーが実際に目にする検証エラーのようなメッセージです。 +もう一つはエンド・ユーザが実際に目にする検証エラーのようなメッセージです。 メッセージの翻訳を開始するためには: @@ -17,7 +17,7 @@ Yii は国際的なアプリケーションと開発者にとって役に立つ 言語コードの形式は、例えば `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=` を走らせます。 3. `framework/messages/your_language/yii.php` のメッセージを翻訳します。ファイルは必ず UTF-8 エンコーディングを使って保存してください。 -4. [プルリクエスト](git-workflow.md) をします。 +4. [プル・リクエスト](git-workflow.md) をします。 あなたの翻訳を最新状態に保つために、`./yii message/extract @yii/messages/config.php --languages=` を再び走らせることが出来ます。 このコマンドは、変更のなかった箇所には触れることなく、自動的にメッセージを再抽出してくれます。 @@ -41,6 +41,6 @@ Yii は国際的なアプリケーションと開発者にとって役に立つ php build translation "../docs/guide" "../docs/guide-ru" "Russian guide translation report" > report_guide_ru.html ``` -このコマンドが composer に関して不平を言うようであれば、ソースのルートディレクトリで `composer install` を実行してください。 +このコマンドが composer に関して不平を言うようであれば、ソースのルート・ディレクトリで `composer install` を実行してください。 -ドキュメントの文法の情報およびスタイルガイドに関して、[documentation_style_guide.md](../documentation_style_guide.md) を参照して下さい。 +ドキュメントの文法の情報およびスタイル・ガイドに関して、[documentation_style_guide.md](../documentation_style_guide.md) を参照して下さい。 diff --git a/docs/internals-ja/versions.md b/docs/internals-ja/versions.md index 635e8d8..133d3a1 100644 --- a/docs/internals-ja/versions.md +++ b/docs/internals-ja/versions.md @@ -17,21 +17,21 @@ Yii バージョン規約 将来出るであろう Yii バージョン 3 については、1.0 に対する 2.0 のようなものになると予想されるので、ここでは言及しません。 このようなことは、外的な技術進歩 (たとえば PHP の 5.0 から 5.4 へのアップグレード) によって、3年から5年に一度しか生じないものと予期しています。 -## `2.X.0`: メジャーリリース +## `2.X.0`: メジャー・リリース 後方互換性を損ないうる大きな機能追加と変更を含む、非後方互換なリリースです。 以前のバージョンからのアップグレードは簡単ではないかも知れませんが、完全なアップグレードのガイドが提供されます。 * 主として新機能とバグ修正を含む。 -* パッチリリースからマージされた小さな機能強化とバグ修正を含む。 +* パッチ・リリースからマージされた小さな機能強化とバグ修正を含む。 * `UPGRADE-2.X.md` ファイルに記録される非後方互換な変更を含みうる。 * リリースのサイクルはだいたい12ヶ月またはそれ以上。 -* プレリリースが必要: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc` -* 大きなニュースリリースとマーケティング努力を必要とする。 +* プレ・リリースが必要: `2.X.0-alpha`, `2.X.0-beta`, `2.X.0-rc` +* 大きなニュース・リリースとマーケティング努力を必要とする。 -## `2.x.Y`: マイナーリリース +## `2.x.Y`: マイナー・リリース -ほぼ後方互換であるマイナーリリースです。 +ほぼ後方互換であるマイナー・リリースです。 理想的には、後方互換性を損なわない変更だけを含ませたいと私たちは望んでいます。 しかし、すべてを 100% 後方互換に保つことが常に可能である訳ではありませんので、アップグレードに関するノートが `UPGRADE.md` に記録されます。 実際の運用では、2.0.x はより頻繁にリリースされるので、小さな機能改良の追加も行って、ユーザが新機能をより早く享受できるようにしています。 @@ -40,32 +40,32 @@ Yii バージョン規約 * 大きな機能拡張や修正はしない。 * 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。ごく少数の例外は許容されるが、その場合は `UPGRADE.md` に記録される。 * リリースのサイクルは1～2ヶ月程度。 -* プレリリース (alpha, beta, RC) は不要。 -* 継続的に (少なくとも週に一回は手作業で) マスターブランチにマージバックされるべき。 -* ニュースによる広報を伴う。プロジェクトサイトがアップデートされる。 +* プレ・リリース (alpha, beta, RC) は不要。 +* 継続的に (少なくとも週に一回は手作業で) マスター・ブランチにマージ・バックされるべき。 +* ニュースによる広報を伴う。プロジェクト・サイトがアップデートされる。 -### `2.x.y.Z`: パッチリリース +### `2.x.y.Z`: パッチ・リリース -バグ修正のみを含む、100% 後方互換であるべき、パッチリリースです。 -ニュースによる広報やプロジェクトサイトのアップデートはしません (ただし、重大な/セキュリティの問題についての修正を含む場合は、別です)。 +バグ修正のみを含む、100% 後方互換であるべき、パッチ・リリースです。 +ニュースによる広報やプロジェクト・サイトのアップデートはしません (ただし、重大な/セキュリティの問題についての修正を含む場合は、別です)。 このリリースのプロセスはほぼ自動化されています。 * バグ修正のみを含み、機能追加はしない * 不安無しのアップグレードを保証するために、100% 後方互換でなければならない。唯一の例外はセキュリティ問題で、その場合は後方互換性が破られることもある * リリースのサイクルは1～2週間程度 -* プレリリース (alpha, beta, RC) は不要 -* リリース時にマスターブランチにマージバックされなければならない +* プレ・リリース (alpha, beta, RC) は不要 +* リリース時にマスター・ブランチにマージ・バックされなければならない ## ブランチ規約 -* `master` ブランチは、現在の安定版メジャーリリースの開発ブランチで、現在は `2.0.x` バージョンです。 -* 各メジャーリリースは、そのバージョン番号の名前を持つブランチ上で開発されます。例えば、`2.1`。 -* メジャーリリース `2.n` の準備が出来たら、`master` から `2.(n-1).x` と名付けられた保守ブランチを作成します。 +* `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` ブランチにマージバックされます。 +* パッチ・リリースをマークするために `2.x.y.z` というタグと `2.x.y` ブランチを作成します。`0` は省略されます。 +* `2.n.x` 保守ブランチ上の変更は、継続的に `master` ブランチにマージ・バックされます。 次の図は、各ブランチ上でのコミット履歴の経時的な変化を説明したものです。 @@ -76,8 +76,8 @@ Yii バージョン規約 フレームワークと公式エクステンションのプロジェクトは、お互いに独立にリリースされます。 すなわち、すなわち、フレームワークとエクステンションの間で、バージョン番号が異なることが予想されます。 -アプリケーションテンプレートは、常に、フレームワークと同時にリリースされます。 +アプリケーション・テンプレートは、常に、フレームワークと同時にリリースされます。 -上記で説明されたリリースサイクルは、コアフレームワークにのみ適用されます。 +上記で説明されたリリース・サイクルは、コア・フレームワークにのみ適用されます。 エクステンションは必要に応じてリリースされます。 エクステンションは、何らバグ修正や機能拡張を受けずに、長期間にわたって新しいリリースを持たないことがあり得ます。 diff --git a/docs/internals-ja/view-code-style.md b/docs/internals-ja/view-code-style.md index feb1214..8180086 100644 --- a/docs/internals-ja/view-code-style.md +++ b/docs/internals-ja/view-code-style.md @@ -1,14 +1,14 @@ -Yii 2 ビューコードスタイル -========================= +Yii 2 ビュー・コード・スタイル +============================== -下記のコードスタイルが Yii 2.x コアと公式エクステンションのビューファイルに用いられています。 -私たちは、あなたが自分のアプリケーションにこのコードスタイルを使うことを強制するものではありません。 -あなたにとってより良いコードスタイルを自由に選んでください。 +下記のコード・スタイルが Yii 2.x コアと公式エクステンションのビュー・ファイルに用いられています。 +私たちは、あなたが自分のアプリケーションにこのコード・スタイルを使うことを強制するものではありません。 +あなたにとってより良いコード・スタイルを自由に選んでください。 ```php