diff --git "a/\347\254\254\344\270\200\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md" "b/\347\254\254\344\270\200\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md"
index d4f44f794a307c63f04bf1b454a1f90f39dc8907..cb1d0e3473127719f38acd4c4d7ce1019792d4d9 100644
--- "a/\347\254\254\344\270\200\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md"
+++ "b/\347\254\254\344\270\200\351\203\250\345\210\206\342\200\224\342\200\224\345\210\235\350\257\206\345\274\200\346\272\220/\346\234\211\345\205\263\345\274\200\346\272\220\347\232\204\345\270\270\350\247\201\350\257\257\345\214\272.md"
@@ -14,7 +14,7 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，
 所以开源**并不意味着**完全免费和随意使用源代码！
 
 ### 「半开源」和「伪开源」也是开源吗？
-开源不只是开放源代码，根据OSI的定义，开源必须满足一系列条款。
+开源不只是开放源代码，根据 OSI 的定义，开源必须满足一系列条款。
 半开源和伪开源都违反了开源的其中某些条款，因此不是开源。
 
 ### 开源项目必须用英文命名标识符吗？
@@ -22,16 +22,20 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，
 虽然很多开发者早已知道多数常用编程语言支持中文命名标识符并付诸实践，但仍然常见“如果项目开源的话还是要用英文命名”的说法。2007 年 Python3 决定支持非 ASCII 码标识符的[增强建议书](https://www.python.org/dev/peps/pep-3131/)中指出：
 
 > A developer wishing to make a library widely available needs to make a number of explicit choices (such as publication, licensing, language of documentation, and language of identifiers). It should always be the choice of the author to make these decisions - not the choice of the language designers.
+> 
+> 希望使库广泛可用的开发人员需要做出许多明确的选择（例如发布、许可、文档语言和标识符语言）。做这些决定应该是源码作者的选择，而不是语言设计者的选择。
 
 这段话同样适用于开源项目。无论是文档还是源码中标识符使用的语言，项目作者都可以根据实际需求来灵活决定，而非简单的一刀切用英文。实际上，开源项目往往是在开发者业余的碎片时间进行，文档和测试往往从简。这种情况下，代码的清晰度和可维护性对于项目可持续性尤显重要，这恰恰是母语命名标识符的优势。正如同一文档指出：
 
 > By using identifiers in their native language, code clarity and maintainability of the code among speakers of that language improves.
+>
+> 通过在母语中使用标识符，使用该语言的人可以提高代码的清晰度和可维护性。
 
 下面是一些常见的顾虑：
 
 - 用中文命名出了问题怎么办？
 
-  像任何技术一样，在使用推广中必然有各种问题出现。如果是编程语言或是开源框架对中文命名的支持问题，可以向它们的开发组反映，往往能得到解决，先例有 [Vue.js](https://github.com/vuejs/vue/issues/6971)、[Hibernate](https://hibernate.atlassian.net/browse/HHH-13383)、[pip](https://github.com/pypa/pip/issues/8342) 等等。另外，也可在开源中国社区求助、协力解决。毕竟，「走的人多了，也便成了路」。
+  像任何技术一样，在使用推广中必然有各种问题出现。如果是编程语言或是开源框架对中文命名的支持问题，可以向它们的开发组反映，往往能得到解决，先例有 [Vue.js](https://github.com/vuejs/vue/issues/6971)、[Hibernate](https://hibernate.atlassian.net/browse/HHH-13383)、[pip](https://github.com/pypa/pip/issues/8342) 等等。另外，也可在开源中国社区求助，协力解决。毕竟，「走的人多了，也便成了路」。
 
 - 框架限制必须用英文怎么办？
 
@@ -41,6 +45,8 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，
 
   大多数情况下，读代码的时间远超过写代码的时间。即便仅仅讨论写代码的效率，也要考虑推敲英文命名甚至查字典的时间，何况很多领域业务相关命名连恰当英文表达都很难找到。另外，随着中文命名实践的普及，相应的 IDE 辅助功能也在不断涌现，比如 [JetBrains](https://gitee.com/tuchg/ChinesePinyin-CodeCompletionHelper) 和 [VS Code](https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant) 的中文代码补全插件。
 
+  此外，你还可以考虑在命名中加入拼音的元素，比如`视频`你可以命名为 `shipin` 而不是 `video`。你还可以使用拼音的首字母来命名，比如`项目经理`可以使用 `xmjl` 来命名。这样既不会降低写代码的效率，同时也提高了中文含义的可读性。
+
 - 项目已经是英文命名的，没法转了？
 
   如果某一部分的英文命名经常在开发组中引起误解或者新手甚至自己也难以看懂，可以尝试从这部分先开始中文化，看看效果后再逐步在其他部分采用。与任何未曾尝试过的技术一样，渐进增量式的应用可以减小风险、在使用中逐渐适应。
@@ -52,4 +58,4 @@ GPL、MIT、BSD 等比较流行的开源协议允许使用者修改源代码，
 总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。
 
 ***
-> 参考：https://opensource.com/resources/what-open-source
+> 参考：[https://opensource.com/resources/what-open-source](https://opensource.com/resources/what-open-source)