Update Ch14

src/Ch14_More_about_Cargo_and_Crates-io.md

@@ -505,14 +505,14 @@ $ cargo yank --vers 0.1.0 --undo
 
 ### 创建工作区
 
-*工作区，a workspace* 是共享了同一 `Cargo.lock` 文件与输出目录的包集合。咱们来构造一个用到工作区的项目 -- 咱们将使用一些简单代码，这样咱们便可着重于工作区的结构。组织工作区有多种方式，因此咱们将只给出一种常见方式。咱们将会有包含着一个二进制代码箱，与两个库代码箱的一个工作区。其中的二进制代码箱，将提供依赖于那两个库代码箱的 `main` 功能。其中一个库代码箱，将提供一个 `add_one` 函数，而另一个则会提供 `add_two` 函数。这三个代码箱，都将是同一工作区的组成部分。这里将以创建该工作区的目录开始：
+*工作区，a workspace* 是共享了同一 `Cargo.lock` 文件与输出目录的包集合。咱们来构造一个用到工作区的项目 -- 咱们将使用一些简单代码，这样咱们便可着重于工作区的结构。组织工作区有多种方式，因此咱们将只给出一种常见方式。咱们将会有包含着一个二进制代码箱，与两个库代码箱的一个工作区。其中的二进制代码箱，将提供主要功能，其将依赖于其中的两个库代码箱。而一个库代码箱将提供 `add_one` 函数，另一个则会提供 `add_two` 函数。这三个代码箱，都将是同一工作区的一部分。咱们将以创建出工作区目录开始：
 
 ```console
 $ mkdir add
 $ cd add
 ```
 
-接着，在那个 `add` 目录中，就要创建一个将对整个工作区加以配置的 `Cargo.toml` 文件了。这个文件不会有 `[package]` 小节。相反，他会以一个 `[workspace]` 小节打头，这将允许咱们通过指定有着这里二进制代码箱的那个包的路径，而把一些成员添加到这个工作区；在此情形下，那个路径就是 `adder`:
+接下来，在 `add` 目录中，咱们就要创建出将对整个工作区加以配置的 `Cargo.toml` 文件。这个文件不会有 `[package]` 小节。相反，他会以 `[workspace]` 小节开始，其将允许咱们，通过指定出有着咱们的二进制代码箱的包路径，而把成员添加到工作区；在这个示例中，那个路径为 `adder`:
 
 文件名：`Cargo.toml`
 
@@ -523,14 +523,14 @@ members = [
 ]
 ```
 
-再接着，这里将通过在这个 `add` 目录里头，运行 `cargo new` 创建出那个 `adder` 二进制代码箱：
+接着，咱们将通过在 `add` 目录里运行 `cargo new`，而创建出 `adder` 二进制代码箱：
 
 ```console
 $ cargo new adder
      Created binary (application) `adder` package
 ```
 
-到这里，就可以通过运行 `cargo build`，构造这个工作区了。这个 `add` 目录下的那些文件，看起来应像下面这样：
+到这里，咱们就可通过运行 `cargo build` 构建出工作区。`add` 目录下的文件，看起来应像下面这样：
 
 ```console
 .
@@ -543,14 +543,14 @@ $ cargo new adder
 └── target
 ```
 
-这个工作区在顶级有个 `target` 目录，那些编译好的物件（the compiled artifacts）就会放入到其中；那个 `adder` 包则并无其自己的 `target` 目录。即使在 `adder` 目录内部运行 `cargo build`，那些编译出的物件，仍会以位处于 `add/target` 而告终，而不会在 `add/adder/target` 目录里。Cargo 之所以像这样来架构这个 `target` 目录，是因为工作区中的那些代码箱，是为了依赖于彼此。若各个代码箱都有其自己的 `target` 目录，那么各个代码箱为了把编译成的物件放在自己的 `target` 目录中，而不得不重新编译工作区中的各个其他代码箱。通过共用一个 `target` 目录，这些代码箱就可以避免不必要的重构建。
+在其顶层，工作区有个 `target` 目录，那些编译出的物件，the compiled artifacts，就会放入其中；`adder` 包没有自己的 `target` 目录。即使咱们在 `adder` 目录内运行 `cargo build`，那些编译出的物件，仍将出现在 `add/target` 中，而不是 `add/adder/target` 目录里。Cargo 之所以像这样来组织 `target` 目录，是因为工作区中的代码箱是为了依赖于彼此。若各个代码箱都有自己的 `target` 目录，那么为了把编译出的物件放在自己的 `target` 目录中，就不得不重新编译工作区中其他各个代码箱。经由共用一个 `target` 目录，代码箱就可以避免不必要的重新构建。
 
 
-### 创建工作区中的第二个包
+### 在工作区中创建第二个包
 
 **Creating the Second Package in the Workspace**
 
-接下来，就要创建出工作区中的另一个成员包，并将其叫做 `add_one`。请修改顶层的 `Cargo.toml`，在其中的 `members` 清理里指明 `add_one` 的路径：
+接下来，咱们来创建出工作区中的另一个成员包，并将其叫做 `add_one`。请修改顶层的 `Cargo.toml`，在其中的 `members` 清理里指明 `add_one` 的路径：
 
 文件名：`Cargo.toml`
 

src/Ch21_Appendix.md

@@ -803,7 +803,12 @@ Semantic Versioning rules, 又大版本、小版本及补丁版本构成的，
 
 - 工作区
 
-Workspace，
+Workspace，为有着多个库代码箱的大型项目组织的一项 Cargo 特性。
+
+
+- 编译出的物件
+
+The compiled artifacts
 
 
 - 单态化