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 cf12816f50f291d1a4850faa51105252c84c972d..878e510afd3ab4fa8fa14d7de8c6f904ec3988f4 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"
@@ -15,6 +15,39 @@ 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) 等等。另外，也可在开源中国社区求助、协力解决。毕竟，「走的人多了，也便成了路」。
+
+- 框架限制必须用英文怎么办？
+
+  比如 JavaBeans 规范一定要使用 set/get 前缀。即便如此，仍然可以使用中英混合的命名，只要开发者感觉更易读即可，比如 `getCostOutcomeRatioByClientGroup` 相比 `get投入产出比By客户组`。类似地，一些常用的英文术语或简写，如果没想到合适中文对应术语，大可以暂时保留这部分英文命名。
+
+- 中英文混输的效率会低吗？
+
+  大多数情况下，读代码的时间远超过写代码的时间。即便仅仅讨论写代码的效率，也要考虑推敲英文命名甚至查字典的时间，何况很多领域业务相关命名连恰当英文表达都很难找到。另外，随着中文命名实践的普及，相应的 IDE 辅助功能也在不断涌现，比如 [JetBrains](https://gitee.com/tuchg/ChinesePinyin-CodeCompletionHelper) 和 [VS Code](https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant) 的中文代码补全插件。
+
+- 项目已经是英文命名的，没法转了？
+
+  如果某一部分的英文命名经常在开发组中引起误解或者新手甚至自己也难以看懂，可以尝试从这部分先开始中文化，看看效果后再逐步在其他部分采用。与任何未曾尝试过的技术一样，渐进增量式的应用可以减小风险、在使用中逐渐适应。
+
+- 用了中文命名之后，怎样为国外用户服务？
+
+  如果需要面向国外用户，首先要对用户界面和使用文档进行国际化。如果是库，用户界面就是 API。技术上，可以开发中英两套 API。如果想更进一步，鼓励国外开发者参与开发项目，当然可以逐步将命名英文化，但也应综合考虑是否值得。
+
+总之，澄清这个误区的目的，绝不是排斥英文命名，而是让更多开源作者意识到可以视项目性质和自身情况因地制宜、具体情况具体分析，灵活选择何时、何处进行中文命名实践，也希望中文开源社区能以开放宽容的心态看待中文命名标识符这一并不新的“新技术”。
 
 ***
 > 参考：https://opensource.com/resources/what-open-source