cn-introduction/04-schema.md

@@ -15,7 +15,7 @@
 如果你克隆了其中的一个依赖包，直接在其上开始工作，那么它就变成了“root 包”。与作为他人的依赖包时使用相同的 `composer.json` 文件，但上下文发生了变化。
 
 > **注意：** 一个资源包是不是“root 包”，取决于它的上下文。
-> 例如：如果你的项目依赖 `monolog` 库，那么你的项目就是“root 包”。
+> 例：如果你的项目依赖 `monolog` 库，那么你的项目就是“root 包”。
 > 但是，如果你从 GitHub 上克隆了 `monolog` 为它修复 bug，
 > 那么此时 `monolog` 就是“root 包”。
 
@@ -25,7 +25,7 @@
 
 包的名称，它包括供应商名称和项目名称，使用 `/` 分隔。
 
-例如：
+例：
 
 * monolog/monolog
 * igorw/event-source
@@ -44,7 +44,7 @@
 
 它应该符合 'X.Y.Z' 或者 'vX.Y.Z' 的形式， `-dev`、`-patch`、`-alpha`、`-beta` 或 `-RC` 这些后缀是可选的。在后缀之后也可以再跟上一个数字。
 
-例如：
+例：
 
     1.0.0
     1.0.2
@@ -70,7 +70,7 @@
 composer 原生支持以下4种类型：
 
 - **library:** 这是默认类型，它会简单的将文件复制到 `vendor` 目录。
-- **project:** 这表示当前包是一个项目，而不是一个库。例如：框架应用程序 [Symfony standard edition](https://github.com/symfony/symfony-standard)，内容管理系统 [SilverStripe installer](https://github.com/silverstripe/silverstripe-installer) 或者完全成熟的分布式应用程序。使用 IDE 创建一个新的工作区时，这可以为其提供项目列表的初始化。
+- **project:** 这表示当前包是一个项目，而不是一个库。例：框架应用程序 [Symfony standard edition](https://github.com/symfony/symfony-standard)，内容管理系统 [SilverStripe installer](https://github.com/silverstripe/silverstripe-installer) 或者完全成熟的分布式应用程序。使用 IDE 创建一个新的工作区时，这可以为其提供项目列表的初始化。
 - **metapackage:** 当一个空的包，包含依赖并且需要触发依赖的安装，这将不会对系统写入额外的文件。因此这种安装类型并不需要一个 dist 或 source。
 - **composer-plugin:** 一个安装类型为 `composer-plugin` 的包，它有一个自定义安装类型，可以为其它包提供一个 installler。详细请查看 [自定义安装类型](articles/custom-installers.md)。
 
@@ -80,7 +80,7 @@ composer 原生支持以下4种类型：
 
 该包相关的关键词的数组。这些可用于搜索和过滤。
 
-例如：
+例：
 
     logging
     events
@@ -128,7 +128,7 @@ composer 原生支持以下4种类型：
 
 对于闭源软件，你必须使用 `"proprietary"` 协议标识符。
 
-一个例如：
+一个例：
 
     {
         "license": "MIT"
@@ -136,7 +136,7 @@ composer 原生支持以下4种类型：
 
 对于一个包，当允许在多个许可协议间进行选择时（"disjunctive license"），这些协议标识符可以被指定为数组。
 
-多协议的一个例如：
+多协议的一个例：
 
     {
         "license": [
@@ -162,9 +162,9 @@ composer 原生支持以下4种类型：
 * **name:** 作者的姓名，通常使用真名。
 * **email:** 作者的 email 地址。
 * **homepage:** 作者主页的 URL 地址。
-* **role:** 该作者在此项目中担任的角色（例如：开发人员 或 翻译）。
+* **role:** 该作者在此项目中担任的角色（例：开发人员 或 翻译）。
 
-一个例如：
+一个例：
 
     {
         "authors": [
@@ -198,7 +198,7 @@ composer 原生支持以下4种类型：
 * **irc:** IRC 聊天频道地址，类似于 irc://server/channel。
 * **source:** 网址浏览或下载源。
 
-一个例如：
+一个例：
 
     {
         "support": {
@@ -213,7 +213,7 @@ composer 原生支持以下4种类型：
 
 下面提到的所有对象，都应该是 包名 到 [版本](01-basic-usage.md#包版本) 的映射对象。
 
-例如：
+例：
 
     {
         "require": {
@@ -223,9 +223,9 @@ composer 原生支持以下4种类型：
 
 所有的这些都是可选的。
 
-`require` 和 `require-dev` 还支持稳定性标签（@，仅针对“root 包”）。这允许你在 [minimum-stability](#minimum-stability) 设定的范围外做进一步的限制或扩展。例如：如果你想允许依赖一个不稳定的包，你可以在一个包的版本约束后使用它，或者是一个空的版本约束内使用它。
+`require` 和 `require-dev` 还支持稳定性标签（@，仅针对“root 包”）。这允许你在 [minimum-stability](#minimum-stability) 设定的范围外做进一步的限制或扩展。例：如果你想允许依赖一个不稳定的包，你可以在一个包的版本约束后使用它，或者是一个空的版本约束内使用它。
 
-例如：
+例：
 
     {
         "require": {
@@ -236,7 +236,7 @@ composer 原生支持以下4种类型：
 
 如果你的依赖之一，有对另一个不稳定包的依赖，你最好在 require 中显示的定义它，并带上足够详细的稳定性标识。
 
-例如：
+例：
 
     {
         "require": {
@@ -247,7 +247,7 @@ composer 原生支持以下4种类型：
 
 `require` 和 `require-dev` 还支持对 dev（开发）版本的明确引用（即：版本控制系统中的提交编号 commit），以确保它们被锁定到一个给定的状态，即使你运行了更新命令。你只需要明确一个开发版本号，并带上诸如 `#<ref>` 的标识。
 
-例如：
+例：
 
     {
         "require": {
@@ -298,7 +298,7 @@ simply list it in `provide`.
 
 格式如下，版本约束变成了描述信息。
 
-例如：
+例：
 
     {
         "suggest": {
@@ -316,11 +316,11 @@ PHP autoloader 的自动加载映射。
 
 在 `psr-0` key 下你定义了一个命名空间到实际路径的映射（相对于包的根目录）。注意，这里同样支持 PEAR-style 方式的约定（与命名空间不同，PEAR 类库在类名上采用了下划线分隔）。
 
-请注意，命名空间的申明应该以 `\\` 结束，以确保 autoloader 能够准确响应。例如： `Foo` 将会与 `FooBar` 匹配，然而以反斜杠结束就可以解决这样的问题， `Foo\\` 和 `FooBar\\` 将会被区分开来。
+请注意，命名空间的申明应该以 `\\` 结束，以确保 autoloader 能够准确响应。例： `Foo` 将会与 `FooBar` 匹配，然而以反斜杠结束就可以解决这样的问题， `Foo\\` 和 `FooBar\\` 将会被区分开来。
 
 在 install/update 过程中，PSR-0 引用都将被结合为一个单一的键值对数组，存储至 `vendor/composer/autoload_namespaces.php` 文件中。
 
-例如：
+例：
 
     {
         "autoload": {
@@ -332,7 +332,7 @@ PHP autoloader 的自动加载映射。
         }
     }
 
-如果你需要搜索多个目录中一个相同的前缀，你可以将它们指定为一个数组，例如：
+如果你需要搜索多个目录中一个相同的前缀，你可以将它们指定为一个数组，例：
 
     {
         "autoload": {
@@ -362,7 +362,7 @@ PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别
 
 你可以用 classmap 生成支持支持自定义加载的不遵循 PSR-0 规范的类库。要配置它指向需要的目录，以便能够准确搜索到类文件。
 
-例如：
+例：
 
     {
         "autoload": {
@@ -374,7 +374,7 @@ PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别
 
 如果你想要明确的指定，在每次请求时都要载入某些文件，那么你可以使用 'files' autoloading。通常作为函数库的载入方式（而非类库）。
 
-例如：
+例：
 
     {
         "autoload": {
@@ -389,7 +389,7 @@ PSR-0 方式并不仅限于申明命名空间，也可以是精确到类级别
 
 一个追加到 PHP `include_path` 中的列表。
 
-例如：
+例：
 
     {
         "include-path": ["lib/"]
@@ -418,40 +418,27 @@ Symfony 就是一个例子。它有一些独立的包作为组件。Yaml 组件
 
 ### minimum-stability <span>(root-only)</span>
 
-This defines the default behavior for filtering packages by stability. This
+这定义了通过稳定性过滤包的默认行为。默认为 `stable`（稳定）。因此如果你依赖于一个 `dev`（开发）包，你应该明确的进行定义。
-defaults to `stable`, so if you rely on a `dev` package, you should specify
-it in your file to avoid surprises.
 
-All versions of each package are checked for stability, and those that are less
+对每个包的所有版本都会进行稳定性检查，而低于 `minimum-stability` 所设定的最低稳定性的版本，将在解决依赖关系时被忽略。对于个别包的特殊稳定性要求，可以在 `require` 或 `require-dev` 中设定（请参考 [package links](#package-links)）。
-stable than the `minimum-stability` setting will be ignored when resolving
-your project dependencies. Specific changes to the stability requirements of
-a given package can be done in `require` or `require-dev` (see
-[package links](#package-links)).
 
-Available options (in order of stability) are `dev`, `alpha`, `beta`, `RC`,
+可用的稳定性标识（按字母排序）：`dev`、`alpha`、`beta`、`RC`、`stable`。
-and `stable`.
 
 ### prefer-stable <span>(root-only)</span>
 
-When this is enabled, Composer will prefer more stable packages over unstable
+当此选项被激活时，Composer 将优先使用更稳定的包版本。
-ones when finding compatible stable packages is possible. If you require a
-dev version or only alphas are available for a package, those will still be
-selected granted that the minimum-stability allows for it.
 
-Use `"prefer-stable": true` to enable.
+使用 `"prefer-stable": true` 来激活它。
 
 ### repositories <span>(root-only)</span>
 
-Custom package repositories to use.
+使用自定义的包资源库。
 
-By default composer just uses the packagist repository. By specifying
+默认情况下 composer 只使用 packagist 作为包的资源库。通过指定资源库，你可以从其他地方获取资源包。
-repositories you can get packages from elsewhere.
 
-Repositories are not resolved recursively. You can only add them to your main
+Repositories 并不是递归调用的，只能在“Root包”的 `composer.json` 中定义。附属包中的 `composer.json` 将被忽略。
-`composer.json`. Repository declarations of dependencies' `composer.json`s are
-ignored.
 
-The following repository types are supported:
+支持以下类型的包资源库：
 
 * **composer:** A composer repository is simply a `packages.json` file served
   via the network (HTTP, FTP, SSH), that contains a list of `composer.json`
@@ -466,9 +453,9 @@ The following repository types are supported:
   composer whatsoever you can define the package inline using a `package`
   repository. You basically just inline the `composer.json` object.
 
-For more information on any of these, see [Repositories](05-repositories.md).
+更多相关内容，请查看 [资源库](05-repositories.md)。
 
-Example:
+例：
 
     {
         "repositories": [