Merge pull request #427 from liulyxandy-codemao/liulyxandy-codemao-pa…

…tch-1

TRANSLATORS.md

@@ -9,3 +9,7 @@ This file contains the translation contributors who are willing to help translat
 ## Portuguese-Brazil
 
 - [@LucasHT22](https://github.com/LucasHT22)
+
+## Chinese Simplified
+
+- [@liulyxandy-codemao](https://github.com/liulyxandy-codemao)

lang/zh-CN/index.md

@@ -176,7 +176,7 @@ FAQ
 
 ### 为整个公共 API 写文档太费事了！
 
-为供他人使用的软件编写适当的文档，是你作为一名专业开发者应尽的职责。保持项目高效的一个非常重要的部份是掌控软件的复杂度，如果没有人知道如何使用你的软件或不知道哪些函数的调用是可靠的，要掌控复杂度会是困难的。长远来看，使用语义化版本控制以及对于公共 API 有良好规范的坚持，可以让每个人及每件事都运行顺畅。
+为供他人使用的软件编写适当的文档，是你作为一名专业开发者应尽的职责。保持项目高效的一个非常重要的部分是掌控软件的复杂度，如果没有人知道如何使用你的软件或不知道哪些函数的调用是可靠的，要掌控复杂度会是困难的。长远来看，使用语义化版本控制以及对于公共 API 有良好规范的坚持，可以让每个人及每件事都运行顺畅。
 
 ### 万一不小心把一个不兼容的改版当成了次版本号发行了该怎么办？
 
@@ -192,15 +192,15 @@ FAQ
 
 ### 我该如何处理即将弃用的功能？
 
-弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部份公共 API 时，你应该做两件事：（1）更新你的文档让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。
+弃用现存的功能是软件开发中的家常便饭，也通常是向前发展所必须的。当你弃用部分公共 API 时，你应该做两件事：（1）更新你的文档让使用者知道这个改变，（2）在适当的时机将弃用的功能透过新的次版本号发布。在新的主版本完全移除弃用功能前，至少要有一个次版本包含这个弃用信息，这样使用者才能平顺地转移到新版 API。
 
 ### 语义化版本对于版本的字符串长度是否有限制呢？
 
 没有，请自行做适当的判断。举例来说，长到 255 个字符的版本已过度夸张。再者，特定的系统对于字符串长度可能会有他们自己的限制。
 
 ### “v1.2.3” 是一个语义化版本号吗？
 
-“v1.2.3” 并不是的一个语义化的版本号。但是，在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中，将 “version” 缩写为 “v” 是很常见的。比如：`git tag v1.2.3 -m "Release version 1.2.3"` 中，“v1.2.3” 表示标签名称，而 “1.2.3” 是语义化版本号。
+“v1.2.3” 并不是一个语义化的版本号。但是，在语义化版本号之前增加前缀 “v” 是用来表示版本号的常用做法。在版本控制系统中，将 “version” 缩写为 “v” 是很常见的。比如：`git tag v1.2.3 -m "Release version 1.2.3"` 中，“v1.2.3” 表示标签名称，而 “1.2.3” 是语义化版本号。
 
 ### 是否有推荐的正则表达式用以检查语义化版本号的正确性？