Browse Source
# Conflicts: # framework/di/Instance.php # tests/framework/filters/AccessRuleTest.phptags/3.0.0-alpha1
Alexander Makarov
8 years ago
248 changed files with 7204 additions and 1162 deletions
@ -1,281 +0,0 @@
|
||||
Modules |
||||
======= |
||||
|
||||
Modules are self-contained software units that consist of [models](structure-models.md), [views](structure-views.md), |
||||
[controllers](structure-controllers.md), and other supporting components. End users can access the controllers |
||||
of a module when it is installed in [application](structure-applications.md). For these reasons, modules are |
||||
often viewed as mini-applications. Modules differ from [applications](structure-applications.md) in that |
||||
modules cannot be deployed alone and must reside within applications. |
||||
|
||||
|
||||
## Creating Modules <span id="creating-modules"></span> |
||||
|
||||
A module is organized as a directory which is called the [[yii\base\Module::basePath|base path]] of the module. |
||||
Within the directory, there are sub-directories, such as `controllers`, `models`, `views`, which hold controllers, |
||||
models, views, and other code, just like in an application. The following example shows the content within a module: |
||||
|
||||
``` |
||||
forum/ |
||||
Module.php the module class file |
||||
controllers/ containing controller class files |
||||
DefaultController.php the default controller class file |
||||
models/ containing model class files |
||||
views/ containing controller view and layout files |
||||
layouts/ containing layout view files |
||||
default/ containing view files for DefaultController |
||||
index.php the index view file |
||||
``` |
||||
|
||||
|
||||
### Module Classes <span id="module-classes"></span> |
||||
|
||||
Each module should have a unique module class which extends from [[yii\base\Module]]. The class should be located |
||||
directly under the module's [[yii\base\Module::basePath|base path]] and should be [autoloadable](concept-autoloading.md). |
||||
When a module is being accessed, a single instance of the corresponding module class will be created. |
||||
Like [application instances](structure-applications.md), module instances are used to share data and components |
||||
for code within modules. |
||||
|
||||
The following is an example how a module class may look like: |
||||
|
||||
```php |
||||
namespace app\modules\forum; |
||||
|
||||
class Module extends \yii\base\Module |
||||
{ |
||||
public function init() |
||||
{ |
||||
parent::init(); |
||||
|
||||
$this->params['foo'] = 'bar'; |
||||
// ... other initialization code ... |
||||
} |
||||
} |
||||
``` |
||||
|
||||
If the `init()` method contains a lot of code initializing the module's properties, you may also save them in terms |
||||
of a [configuration](concept-configurations.md) and load it with the following code in `init()`: |
||||
|
||||
```php |
||||
public function init() |
||||
{ |
||||
parent::init(); |
||||
// initialize the module with the configuration loaded from config.php |
||||
\Yii::configure($this, require(__DIR__ . '/config.php')); |
||||
} |
||||
``` |
||||
|
||||
where the configuration file `config.php` may contain the following content, similar to that in an |
||||
[application configuration](structure-applications.md#application-configurations). |
||||
|
||||
```php |
||||
<?php |
||||
return [ |
||||
'components' => [ |
||||
// list of component configurations |
||||
], |
||||
'params' => [ |
||||
// list of parameters |
||||
], |
||||
]; |
||||
``` |
||||
|
||||
|
||||
### Controllers in Modules <span id="controllers-in-modules"></span> |
||||
|
||||
When creating controllers in a module, a convention is to put the controller classes under the `controllers` |
||||
sub-namespace of the namespace of the module class. This also means the controller class files should be |
||||
put in the `controllers` directory within the module's [[yii\base\Module::basePath|base path]]. |
||||
For example, to create a `post` controller in the `forum` module shown in the last subsection, you should |
||||
declare the controller class like the following: |
||||
|
||||
```php |
||||
namespace app\modules\forum\controllers; |
||||
|
||||
use yii\web\Controller; |
||||
|
||||
class PostController extends Controller |
||||
{ |
||||
// ... |
||||
} |
||||
``` |
||||
|
||||
You may customize the namespace of controller classes by configuring the [[yii\base\Module::controllerNamespace]] |
||||
property. In case some of the controllers are outside of this namespace, you may make them accessible |
||||
by configuring the [[yii\base\Module::controllerMap]] property, similar to [what you do in an application](structure-applications.md#controller-map). |
||||
|
||||
|
||||
### Views in Modules <span id="views-in-modules"></span> |
||||
|
||||
Views in a module should be put in the `views` directory within the module's [[yii\base\Module::basePath|base path]]. |
||||
For views rendered by a controller in the module, they should be put under the directory `views/ControllerID`, |
||||
where `ControllerID` refers to the [controller ID](structure-controllers.md#routes). For example, if |
||||
the controller class is `PostController`, the directory would be `views/post` within the module's |
||||
[[yii\base\Module::basePath|base path]]. |
||||
|
||||
A module can specify a [layout](structure-views.md#layouts) that is applied to the views rendered by the module's |
||||
controllers. The layout should be put in the `views/layouts` directory by default, and you should configure |
||||
the [[yii\base\Module::layout]] property to point to the layout name. If you do not configure the `layout` property, |
||||
the application's layout will be used instead. |
||||
|
||||
|
||||
### Console commands in Modules <span id="console-commands-in-modules"></span> |
||||
|
||||
Your module may also declare commands, that will be available through the [Console](tutorial-console.md) mode. |
||||
|
||||
In order for the command line utility to see your commands, you will need to change the [[yii\base\Module::controllerNamespace]] |
||||
property, when Yii is executed in the console mode, and point it to your commands namespace. |
||||
|
||||
One way to achieve that is to test the instance type of the Yii application in the module's `init` method: |
||||
|
||||
```php |
||||
public function init() |
||||
{ |
||||
parent::init(); |
||||
if (Yii::$app instanceof \yii\console\Application) { |
||||
$this->controllerNamespace = 'app\modules\forum\commands'; |
||||
} |
||||
} |
||||
``` |
||||
|
||||
Your commands will then be available from the command line using the following route: |
||||
|
||||
``` |
||||
yii <module_id>/<command>/<sub_command> |
||||
``` |
||||
|
||||
## Using Modules <span id="using-modules"></span> |
||||
|
||||
To use a module in an application, simply configure the application by listing the module in |
||||
the [[yii\base\Application::modules|modules]] property of the application. The following code in the |
||||
[application configuration](structure-applications.md#application-configurations) uses the `forum` module: |
||||
|
||||
```php |
||||
[ |
||||
'modules' => [ |
||||
'forum' => [ |
||||
'class' => 'app\modules\forum\Module', |
||||
// ... other configurations for the module ... |
||||
], |
||||
], |
||||
] |
||||
``` |
||||
|
||||
The [[yii\base\Application::modules|modules]] property takes an array of module configurations. Each array key |
||||
represents a *module ID* which uniquely identifies the module among all modules in the application, and the corresponding |
||||
array value is a [configuration](concept-configurations.md) for creating the module. |
||||
|
||||
|
||||
### Routes <span id="routes"></span> |
||||
|
||||
Like accessing controllers in an application, [routes](structure-controllers.md#routes) are used to address |
||||
controllers in a module. A route for a controller within a module must begin with the module ID followed by |
||||
the [controller ID](structure-controllers.md#controller-ids) and [action ID](structure-controllers.md#action-ids). |
||||
For example, if an application uses a module named `forum`, then the route |
||||
`forum/post/index` would represent the `index` action of the `post` controller in the module. If the route |
||||
only contains the module ID, then the [[yii\base\Module::defaultRoute]] property, which defaults to `default`, |
||||
will determine which controller/action should be used. This means a route `forum` would represent the `default` |
||||
controller in the `forum` module. |
||||
|
||||
|
||||
### Accessing Modules <span id="accessing-modules"></span> |
||||
|
||||
Within a module, you may often need to get the instance of the [module class](#module-classes) so that you can |
||||
access the module ID, module parameters, module components, etc. You can do so by using the following statement: |
||||
|
||||
```php |
||||
$module = MyModuleClass::getInstance(); |
||||
``` |
||||
|
||||
where `MyModuleClass` refers to the name of the module class that you are interested in. The `getInstance()` method |
||||
will return the currently requested instance of the module class. If the module is not requested, the method will |
||||
return null. Note that you do not want to manually create a new instance of the module class because it will be |
||||
different from the one created by Yii in response to a request. |
||||
|
||||
> Info: When developing a module, you should not assume the module will use a fixed ID. This is because a module |
||||
can be associated with an arbitrary ID when used in an application or within another module. In order to get |
||||
the module ID, you should use the above approach to get the module instance first, and then get the ID via |
||||
`$module->id`. |
||||
|
||||
You may also access the instance of a module using the following approaches: |
||||
|
||||
```php |
||||
// get the child module whose ID is "forum" |
||||
$module = \Yii::$app->getModule('forum'); |
||||
|
||||
// get the module to which the currently requested controller belongs |
||||
$module = \Yii::$app->controller->module; |
||||
``` |
||||
|
||||
The first approach is only useful when you know the module ID, while the second approach is best used when you |
||||
know about the controllers being requested. |
||||
|
||||
Once you have the module instance, you can access parameters and components registered with the module. For example, |
||||
|
||||
```php |
||||
$maxPostCount = $module->params['maxPostCount']; |
||||
``` |
||||
|
||||
|
||||
### Bootstrapping Modules <span id="bootstrapping-modules"></span> |
||||
|
||||
Some modules may need to be run for every request. The [[yii\debug\Module|debug]] module is such an example. |
||||
To do so, list the IDs of such modules in the [[yii\base\Application::bootstrap|bootstrap]] property of the application. |
||||
|
||||
For example, the following application configuration makes sure the `debug` module is always loaded: |
||||
|
||||
```php |
||||
[ |
||||
'bootstrap' => [ |
||||
'debug', |
||||
], |
||||
|
||||
'modules' => [ |
||||
'debug' => 'yii\debug\Module', |
||||
], |
||||
] |
||||
``` |
||||
|
||||
|
||||
## Nested Modules <span id="nested-modules"></span> |
||||
|
||||
Modules can be nested in unlimited levels. That is, a module can contain another module which can contain yet |
||||
another module. We call the former *parent module* while the latter *child module*. Child modules must be declared |
||||
in the [[yii\base\Module::modules|modules]] property of their parent modules. For example, |
||||
|
||||
```php |
||||
namespace app\modules\forum; |
||||
|
||||
class Module extends \yii\base\Module |
||||
{ |
||||
public function init() |
||||
{ |
||||
parent::init(); |
||||
|
||||
$this->modules = [ |
||||
'admin' => [ |
||||
// you should consider using a shorter namespace here! |
||||
'class' => 'app\modules\forum\modules\admin\Module', |
||||
], |
||||
]; |
||||
} |
||||
} |
||||
``` |
||||
|
||||
For a controller within a nested module, its route should include the IDs of all its ancestor modules. |
||||
For example, the route `forum/admin/dashboard/index` represents the `index` action of the `dashboard` controller |
||||
in the `admin` module which is a child module of the `forum` module. |
||||
|
||||
> Info: The [[yii\base\Module::getModule()|getModule()]] method only returns the child module directly belonging |
||||
to its parent. The [[yii\base\Application::loadedModules]] property keeps a list of loaded modules, including both |
||||
direct children and nested ones, indexed by their class names. |
||||
|
||||
|
||||
## Best Practices <span id="best-practices"></span> |
||||
|
||||
Modules are best used in large applications whose features can be divided into several groups, each consisting of |
||||
a set of closely related features. Each such feature group can be developed as a module which is developed and |
||||
maintained by a specific developer or team. |
||||
|
||||
Modules are also a good way of reusing code at the feature group level. Some commonly used features, such as |
||||
user management, comment management, can all be developed in terms of modules so that they can be reused easily |
||||
in future projects. |
||||
@ -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) |
||||
|
||||
その他 |
||||
------ |
||||
|
||||
### 例外の階層 |
||||
|
||||
 |
||||
|
After Width: | Height: | Size: 63 KiB |
Binary file not shown.
@ -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) コマンドを使って、アプリケーションとエクステンションを開発プロジェクトの構成に含めることが出来ます。 |
||||
@ -1,10 +1,10 @@
|
||||
プルリクエストの品質保証 |
||||
======================== |
||||
|
||||
PR をマージするか否かをチェックするときには、特に以下の基準が考慮されるべきです。 |
||||
PR をマージできるか否かをチェックするときには、特に以下の基準が考慮されるべきです。 |
||||
|
||||
- PR にリンクされている課題(イッシュー)が存在するか、または、PR がどのようなことを修正ないし追加しようとしているのかに関する十分な説明があること。 |
||||
- 単体テスト。必須ではありませんが、非常に高く評価されます。PR によって修正されたコードが無ければ失敗する、というテストであること。 |
||||
- CHANGELOG のエントリがあること。エントリは次のリリースのセクションに、イッシューのタイプと番号の順に書き入れます。 |
||||
- 単体テスト。必須ではありませんが、大いに歓迎されます。PR によって修正されるコードが無ければ失敗する、というテストであること。 |
||||
- CHANGELOG のエントリがあること。エントリは次のリリースのセクションに、課題のタイプと番号の順に書き入れます。 |
||||
担当した者のニックネームがあること。 |
||||
- [コードスタイル](core-code-style.md) および [ビューコードスタイル](view-code-style.md) が OK であること。これらは、マージされる際に、マージする者の判断に従って修正される場合があります。 |
||||
|
||||
@ -0,0 +1,79 @@
|
||||
新しいバージョンのリリース |
||||
========================== |
||||
|
||||
フレームワークのリリースを作成するのに必要とされる手順のリストは、時とともに長くなり、手作業で管理するのが困難になっています。 |
||||
そのため、どの手順も忘れられることが無いように、コマンドラインツールを作成しました。 |
||||
|
||||
リリースの手順の概要 |
||||
-------------------- |
||||
|
||||
- ... |
||||
|
||||
リリースコマンド |
||||
---------------- |
||||
|
||||
リリースの手順は、フレームワークの開発レポジトリに含まれている [release コンソールコマンド](../../build/controllers/ReleaseController.php) によって自動化されています。 |
||||
|
||||
リリースコマンドは、フレームワークの `build` ディレクトリに含まれている Yii アプリケーションを使って呼び出すことが出来ます。 |
||||
|
||||
./build/build help release # このコマンドをフレームワークのレポジトリのルートで実行します |
||||
|
||||
> Info: コマンドを `--dryRun` オプションを付けて実行すると、どのようになるかを見ることが出来ます。 |
||||
> このオプションを使うと、変更は何もなされず、どんなコミットやタグも生成されたり、プッシュされたりしません。 |
||||
|
||||
### 必要条件 |
||||
|
||||
リリースコマンドは、[Git ワークフローのドキュメント](git-workflow.md#extensions) で紹介されている開発環境に依存しています。 |
||||
すなわち、アプリケーションテンプレートは `/apps/` の下に配置されていなければならず、 |
||||
エクステンションは `/extensions/` の下に配置されていなければなりません。 |
||||
この構成は `dev/app` および `dev/ext` のコマンドを使って作成することが推奨されます。 |
||||
|
||||
例えば、エクステンションのインストールは: |
||||
|
||||
./build/build dev/ext authclient |
||||
|
||||
アプリケーションは: |
||||
|
||||
./build/build dev/app basic |
||||
|
||||
このインストール方法によって、エクステンションが現在のレポジトリの状態と同じフレームワークコードを使用する事を保証することが出来ます。 |
||||
|
||||
### バージョンの概要 |
||||
|
||||
フレームワークとエクステンションのバージョンについて概要を把握したいときは、以下を実行することが出来ます。 |
||||
|
||||
./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` オプションを付けて、リリースコマンドを実行する。 |
||||
Binary file not shown.
@ -0,0 +1,4 @@
|
||||
翻訳ステータス |
||||
============== |
||||
|
||||
すべてのドキュメントが翻訳可能な状態です。 |
||||
@ -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 |
||||
|
After Width: | Height: | Size: 813 KiB |
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in new issue