前文《开源项目必须用英文命名标识符吗？》有幸获得不少社区响应，其中对中文命名技术本身的质疑大多在《Gitee 开源指北》第 5 小节：有关开源的常见误区 中已作阐述。很高兴看到母语命名在可读性方面的优势已有相当共鸣。
另有几位提到，想要项目有“国际影响力”，或者“有可能面向国外开发者”，就该用英文命名标识符。想起一位国外开发者对中文命名标识符的观点，颇为应景，就由此展开吧。
来自 Rust 语言支持非ASCII码标识符的讨论中的 这一楼，发言者 @Manishearth 是 Rust 开发组成员。摘录如下：
逐句来看：有很多库除了标识符用英文命名之外，其他的文档等等大多不是英文。这种库，即便是像 wepy 这种两万星的受欢迎项目，他也不会用，即便 wepy 用了中文类名，对他来说，也没有什么区别。项目是可以有英文文档，但除非项目已经火了否则不常见，而够火的时候，项目可能就用英文命名了。至于非英文命名的 API 怎么用？就不用呗。
这段话很值得琢磨。
一个国内开源项目，如果没有国外用户，何谈国外开发者参与贡献？而没有完备的英文文档（wepy 项目首页的英文版在 2020 年 7 月编写，而这位发言早在 2018 年），国外开发者几乎不会去了解项目内容。以 wepy 为例，个人很难想象这位 Rust 语言开发组成员打算写微信小程序，也就是说他没找到英文文档很可能就没细看 wepy 项目到底是啥。
那么，像 wepy 这样首先面向国内市场，在数年没有英文说明的项目开发时间内，用英文命名标识符有什么必要呢？
至于 API 用非英文命名，国外开发者往往已有英文命名的相似 API 可用，几乎没有“缺你不行”的情况。想从其他方面与现有英文 API 竞争的话，为何不从国内市场开始呢？用中文命名无疑会对国内用户更友好，如再转战国外市场时，大可再开发一套英文 API。
无论国内国外市场，也无论开源闭源，软件项目的推广首先是“让人知道好用”。而“让人知道”和“好用”两者都不依赖于用英文命名标识符。
对于个人开发者来说，项目推广的开销尤其大。公司背景的开源项目往往可以自带流量，但个人项目往往只能通过各种社区的自荐，而在国外社区的推广往往更加困难。如果在座各位独立开发者有在国外市场推广成功的国内原创开源项目例子，不妨分享一下，相信很多开发者都会有兴趣。
在完成了英文文档、编写英文推广文案各处散发、与国外潜在用户交流等等“杂事”后，如果真有哪天必须开始重命名标识符为英文，会发现这一“最浅层重构”的工作量相对而言不值一提。
正如前文评论区的某位指出的：
在完善项目功能的整个过程中，使用母语命名的益处，可另开文章详述，这里仅举一个方面。开源项目，尤其是个人业余开发的，往往是利用各种碎片时间，能随时“拿起来”就是个重要优势。试想，如果过几天回头看代码时，就要卡在某些标识符命名上困惑当初到底是怎么个思路才会起这个名字，会消磨掉多少更新改进的热情。当然，用母语也可能起烂命名，但无论在起命名还是在读命名上，都会比用第二语言更加易于表达和理解。
小结
开源项目使用什么标识符，应当综合考虑，而不是盲从“全部用英文命名肯定没错”。是否要国外市场、打算为了国外市场持续付出多少、是否值得在一开始就用第二语言命名、在获得国外用户之前会为此付出多大额外开发开销，都值得思量。