炸了，开源社区应该用中文吗？-技术圈

微信搜索逆锋起笔关注后回复编程pdf
领取编程大佬们所推荐的 23 种编程资料！

编者按：

近日，有位 Apache APISIX 用户在 comment 中用中文写下这样一句话，“能不能语言自信点，母语不说飙英文，就能国际化成功吗”。

一石激起千层浪，很快就引发了关于“开源社区应该使用什么语言”的大讨论。

OSCHINA 基于此话题转载、征集了相关稿件，并发起动弹讨论活动。目前该系列已发表稿件四篇，近 500 位用户贡献优质长评：

《在开源的世界里，应该讲开发者都能懂的语言！》，作者：李建盛

《开源社区应该选择什么语言？》，作者：庄表伟

《开源项目必须用英文命名标识符吗？》，作者：吴烜

《开源项目用英文标识符就能招徕国外用户吗？》，作者：吴烜

在开源的世界里，应该讲开发者都能懂的语言

作者|李建盛

中国有句古话，叫做“入乡随俗”，也就是说，我们首先要分辨出自己所处的空间，然后根据空间的形势和状态进行观察、学习，然后在进一步的找人沟通。

拿 Apache APISIX 这个 issue 的回答来说，哪位叫嚣汉语自信的同学，显然是走错了门，他应该去榕树下之类的网站寻找自己的自信，比如和《三体》的作者刘慈欣探讨下未来宇宙中汉语的声音，或者是给诺贝尔文学奖得主莫言先生最近的《晚熟的人》进行评论。

在专业的共同体里，有其独特的文化和传统，使用什么样的语言、鼓励什么样的措辞、配合什么样的语气表达都是由其自主特色的。后来跟进的人，应该尊重共同体的做法。

这个世界上没有任何统一的标尺，将所有事情都囊括。自然语言自信应该在其自身的领域里寻找，而不是到非常专业的计算机专业领域里寻找存在感，这无异于缘木求鱼。

由 X-lab 发起，同济大学开源学博士赵生宇领导的《GitHub 2020全域报告》里明确指出“孤岛项目”多数是非英语项目，是没有融入开源世界的，或者是想进入开源世界的通道没有打开，语言成为了不可逾越的沟壑。

开源社区应该选择什么语言？

作者|庄表伟

一、编程语言与源代码

这个其实应该是最少争议的环节。因为几乎所有的编程语言，都是“类英语”的形式。所以，从阅读体验的角度来说：

我们将一个源代码文件，看做一篇完整的文章。在这篇文章中：中英文夹杂，甚至英文加汉语拼音混杂都是严重影响阅读体验的

包命名、文件名、函数名、变量名等等，都严重建议一律使用英文

在源代码中，我的个人意见是尽量用源代码本身来说话，而无需注释。如果一定要加注释，也强烈建议使用简短英文说明

二、文档

我的建议是：最开始写文档的人，用你最熟悉的语言来写。然后再量力而为，翻译成其他需要的语言。

三、围绕项目的讨论

这个问题，需要从两个层面来看，一个是：你参与到一个已经存在的社区。另一个是：你管理自己的社区。

参与人家的社区：入乡随俗

自己的社区：取决于社区的目标

所谓入乡随俗，其实很简单：人家社区都用英文，或者都用中文，你就不要冲过去说：“能不能语言自信点？”

社区的目标，就比较麻烦了。我只能说：无论基于何种目标，一个健康的社区，与是否使用英语，并无必然的相关性。或者，换言之：下定决心，一开始就用全英文交流，并不是一个繁荣发展的开源社区的，天然保障。

四、项目之外的日常交流

这个其实更少争论，大家在微信群、QQ群、邮件列表、Slack里，自然就会选择自己最常用的语言交流。如果是一个国际化的社区，自然就会更加多的使用英语。而如果中国人占大多数，自然就会使用中文。强行规定，并无必要。

开源项目必须用英文命名标识符吗？

作者|吴烜

开源项目的基本架构搭建之后，如果项目本身使用的是中文命名，用户（往往非程序员）应该会更有动力去学习代码。并不是说英文命名肯定会阻止参与项目，但会让很大一部分人望而却步。

实际上开源项目很大一部分工作量在于后期维护、界面改进、相似功能的堆积，以及相关测试。这部分完全可以由原作者之外的参与者，即普通用户来实现，原作者就可以专心投入到架构/大功能的优化改进上。久而久之，编程新手也会逐渐成为熟练程序员、核心贡献者。

能够吸引更多人来投入项目，而不是点个星就走，是开源项目能够壮大和持久的关键。任何能够降低参与门槛的技术，都应该值得项目作者认真考察，根据项目酌情决定。

回忆一下，无论是开源还是闭源项目，过去几周有没有碰到如下情况之一：

翻自己之前写的代码，发现某个标识符不知所谓

看别人的代码，不懂某个标识符

同事来问你某个标识符啥意思

在我看来，这种时候就可以考虑一下，将这个标识符改成中文会不会少些麻烦。大可以从需要的地方开始改，不用上来就把整个项目的标识符全部中文化。

开源项目用英文标识符就能招徕国外用户吗？

作者|吴烜

一个国内开源项目，如果没有国外用户，何谈国外开发者参与贡献？而没有完备的英文文档（wepy 项目首页的英文版在 2020 年 7 月编写，而这位发言早在 2018 年），国外开发者几乎不会去了解项目内容。以 wepy 为例，个人很难想象这位 Rust 语言开发组成员打算写微信小程序，也就是说他没找到英文文档很可能就没细看 wepy 项目到底是啥。

那么，像 wepy 这样首先面向国内市场，在数年没有英文说明的项目开发时间内，用英文命名标识符有什么必要呢？

至于 API 用非英文命名，国外开发者往往已有英文命名的相似 API 可用，几乎没有“缺你不行”的情况。想从其他方面与现有英文 API 竞争的话，为何不从国内市场开始呢？用中文命名无疑会对国内用户更友好，如再转战国外市场时，大可再开发一套英文 API。

无论国内国外市场，也无论开源闭源，软件项目的推广首先是“让人知道好用”。而“让人知道”和“好用”两者都不依赖于用英文命名标识符。