博客评论 - 开源项目用英文标识符就能招徕国外用户吗？ - OSCHINA

唠叨何

2021/04/14 09:19

历史冷饭翻出来炒而已，应该尊重历史，尊重现实。不要花费时间来讨论这些无谓的问题。

唠叨何

2021/04/14 09:00

搞计算机的，知不知道“信息孤岛”这个词？文章写得再长，也是没见识。

吴烜2020

2021/04/14 10:15

为什么现在发帖用中文？难道也是“信息孤岛”？在连国外用户都没有的情况下就一厢情愿地认为“大概会有国外开发者会看到吧？”，很合理么？话说有什么原创项目有国际合作吗？分享一下吧大家都可以学习推广经验。

唠叨何

2021/04/16 13:54

为什么发帖用中文，因为发帖是寻求中国人的帮助，你试一下去外网寻求帮助的时候发中文看看效果会怎么样。为什么注释要用英文，为什么大家要学英文，就是为了跟世界接轨，当项目推出去做开源的时候如果有外国智力愿意参与进来他可以毫无障碍。为什么一份冷饭乐此不疲的炒，不就是为了体现自己的存在感呗。

osc_566335

2021/04/13 09:36

我一直抱着类似观点。因此看到吴老师 @吴烜2020 的观点非常赞同。但是我在实践中发现一个中文编程非常致命的问题：就是任意造字问题，而这个问题本质上就是符号的自定义化问题。中文编程不能解决这个问题，那么中文编程不过是英文编程的符号替换罢了。但是如果中文编程解决了这个问题，有自定义符号系统（自定义造字和符号）。那么其远远超越了现在的英文编程覅下系统，因为就是现在的英文编程系统也并不具备。因为任何语言的单词都是由语义偏移的，而且多个字符的表义肯定也比单个符号辨识度要差。
目前的任何编程语言，受制于英文符号系统（字母和标点符号）用来表达已经明显受到制约。例如在绝大所属语言系统中，因为标点符号系统不够用，只能使用多字母组合的关键字。
在我的思路里面，语言本身的固定关键字都应该使用单个符号，而不是字母拼装的关键字。单个符号表示确定的固定的语义，这样才能在人和计算机之间建立最少的转义路径。而要实现这个目标，现有的标点符号肯定是不够用的，因此自定义符号几乎是必须的。

吴烜2020

2021/04/13 10:37

本文主要探讨中文命名标识符，猜测你说的也许是中文编程语言的语法设计？不知为何不能使用已有的中文字符词语作为语法关键词呢？不妨举例探讨一下。

osc_566335

2021/04/13 13:22

我是在你文中的思想上拓展了一下。因为就算中文命名标识符如果仅仅是从英文换成中文的话，你说的特点都是存在的。但是仅仅如此的话，需求性固然再大，但是缺少决定性。中文存在的一个劣势是需要输入法的转换，造成输入的不方便。按我的思路的话，我强调的是单个字作为符号做关键字，但是不建议词。因为用词的话，那么就全面在输入方便性上劣于英文了。但是用单个字作为关键字的一个大好处是，拥有实际上的相当足够多的符号来使用，整个语句够简洁，且表达语义够清晰。而且不用空格来分词。用词语或者单词做关键字，还是存在必须分词的问题。但是如果仅仅用现有中文符号的话，还是不够的，因为如果需要不断切换输入法，就把中文的优势完全转嫁为用户输入的劣势了。所以，一个理想的中文编程，应该是在不需要输入法切换下完成的。

吴烜2020

2021/04/13 13:49

减少切换可以由改进IDE实现。已有此类插件，详见《开源指北》误区一章。话说回来，“输入新代码”这一任务在整个开发过程中所占比例相当小，更多的多的时间精力用在阅读已有的代码，因此母语命名的可读性优势会提升开发维护的效率。至于使用单字而不是直接沿用比如需求文档中的业务术语，个人很难想象各种场景有此需要，可否举例说明？

osc_566335

2021/04/14 10:37

你说的可读性，母语更好，我当然是和你保持同样观点的，只要避免输入的障碍我完全赞成。我说的不是业务术语对应的标识符，而是语言本身的符号、关键字之类。我说的可能比较混乱让大家不好理解。我就举一个例子吧，比如“等于”是不是用 = 这个符号比 equals 和 “等于”这样都要好？，那么“赋值为”、“定义为”呢？现在很多语言因为无法有足够的符号，都是用的关键字。如果我们能用定制符号，一个符号就能做好的事，为啥要用多个符号呢？而且只用一个符号不用“分词”啊，多个符号，你就必须要添加额外的像空格这样的分隔符号。另外单个符号就单独表义，也更简洁了，辨识程度也远远高于关键字。易于理解肯定语言更好，但是涉及到通用性和语义的确定性，以及表达的简洁性，符号要比语言更好。这就是为啥有的界面设计指导里面提倡多用图标而不是用文字的道理。用单个符号，就相当于图标了。符号不够用是现在英语编程的最大语言设计弊病，但是字母文字国家的人往往却不会觉察。最多在怎么构造上点科技树，没什么新花样。我倒是设想，可以直接把关键字设计为字符不行吗？毕竟连表情符号都设计进去编码了啊。而且那么大量的汉字和其它语言字母，也可以用啊。这个问题应该还是受制于输入的方便性。当然这个方面扯多了有点离题了。

吴烜2020

2021/04/14 11:01

常用英文编程语言中的确有=这样少数使用符号而非词语的关键词。个人认为用特殊符号代替词语不一定是未来编程语言设计的必然发展方向，尤其在中文编程语言设计中。另外，不用空格分隔的语言设计，是技术上可行且已有先行者的（详见《AppleScript类自然语言与非英语语法设计》中的日文代码示例）。

osc_566335

2021/04/14 11:00

为啥我打好的分段没有了？不能支持分段吗？试下，多了请帮我删掉。你说的可读性，母语更好，我当然是和你保持同样观点的，只要避免输入的障碍我完全赞成。我说的不是业务术语对应的标识符，而是语言本身的符号、关键字之类。我说的可能比较混乱让大家不好理解。我就举一个例子吧，比如“等于”是不是用 = 这个符号比 equals 和 “等于”这样都要好？，那么“赋值为”、“定义为”呢？现在很多语言因为无法有足够的符号，都是用的关键字。如果我们能用定制符号，一个符号就能做好的事，为啥要用多个符号呢？而且只用一个符号不用“分词”啊，多个符号，你就必须要添加额外的像空格这样的分隔符号。另外单个符号就单独表义，也更简洁了，辨识程度也远远高于关键字。易于理解肯定语言更好，但是涉及到通用性和语义的确定性，以及表达的简洁性，符号要比语言更好。这就是为啥有的界面设计指导里面提倡多用图标而不是用文字的道理。用单个符号，就相当于图标了。符号不够用是现在英语编程的最大语言设计弊病，但是字母文字国家的人往往却不会觉察。最多在怎么构造上点科技树，没什么新花样。我倒是设想，可以直接把关键字设计为字符不行吗？毕竟连表情符号都设计进去编码了啊。而且那么大量的汉字和其它语言字母，也可以用啊。这个问题应该还是受制于输入的方便性。当然这个方面扯多了有点离题了。

osc_566335

2021/04/14 11:11

嵌套太多直接贴这里：所以这就问题就到了我一开始提到的关键点了：中文编程的优势所在？如果仅仅是母语编程易读性好的话，完全不能对英文编程有颠覆性作用。我这个思路（完全的符号化编程，除了用户和业务对应的标识符）以前和群友讨论的时候，说在60年代就有计算机科学家主张过，真正的编程语言应该如此，但是不好实现。（VVJ百科上有，但是我后来忘了地址。）但是这个思路实际上才是中文编程的精华所在。否则只是将英文换成母语，换个皮而已。

吴烜2020

2021/04/14 11:19

请勿将在英文编程语言开发中使用中文命名标识符与设计具有中文特性的编程语言对立起来。实际上前者可以为中文API和语法提供必要土壤，毕竟无论什么样的语言设计，在实用中必然要和标识符一道使用。

osc_566335

2021/04/14 11:27

没有没有，我实际上是完全赞成你的观点的。只是难得看到有大佬能比较支持中文编程，所以拓展开聊了聊。有点离题了而已。实际上你说的这篇文章的主题，我自己就在实践。比如，哪些测试项目，我发现即使在现在的工具生态里面，用中文命名单元测试函数也比用英文要具有优势得多。将中文命名用在单元测试函数上的好处是在测试列表上直接显示了中文，而且这些函数不需要被在编码中调用，避开了输入时的麻烦。也避免了有的读者所说的在部署时更改缺少中文环境的问题。如果你认可，可以向大家推荐一下。就像你说的，中文标识符可以为中文编程，乃至最后的符号编程培养生态建立基础。

吴烜2020

2021/04/15 03:49

测试用例的确是已经采用英文命名的项目逐步引入中文命名的一个入手点。个人认为各项目可以视实际情况选取相对业务语义密集、修改的开销小风险低的子部分开始中文命名的技术验证。

袁德俊

2021/04/12 17:43

我听到过一句话，某厂特别高看有国外社区背景的项目，换句话说，拥抱开源是拥抱国际开源社区。这多少有些哪个，开源社区本就在眼前，拥抱与否真的跟命名规则每啥关系。心里想不想拥抱是真的。做好文档，力所能及，能吸引多少小伙伴是你的诚意，也有一个契合度问题，最主要还是项目本身。有这功夫码字，想想项目本身吧。

osc_566335

2021/04/12 09:19

还是那句老话，有的人想以热脸贴冷屁股来获得重视。

吴烜2020

2021/04/12 10:37

个人感觉不少是没有意识到用母语命名的可行性和对开源项目的益处。

妙木山的大贤者

2021/04/10 10:30

其实这样做，退一万步来说，最主要的问题是需要修改项目的环境不一定有中文环境（中文字体和中文输入法），譬如你用中文写了个在 Linux 下运行的脚本，放到服务器上需要修改，而服务器为了安全起见没有安装桌面、也没有安装中文 tty 支持，也不能允许 VSCode 这样的工具进行远程开发，你只能用 vim 和 nano；这时你就会发现你无法直接在服务器上修改你写的玩意……虽然你可以用拼音，但是拼音和英文混搭反而很容易写出可读性糟糕的家伙

吴烜2020

2021/04/10 10:34

这种开发场景毕竟是少数。任何技术都需因地制宜。

吴烜2020

2021/04/10 10:52

说到脚本，推荐个集锦项目：
https://gitee.com/chuanjiao10/kasini3000
其中不少标识符用了中文命名

varyuan

2021/04/09 20:45

就这还放到首页? 恶心人呢

osc_566335

2021/04/13 09:18

认真讨论的人讨论事，喷子专门攻击人。

薯粉1Q84

2021/04/09 17:44

wepy 这种项目有外国人用？

Gfast开源-qixun

2021/04/09 18:23

外国人中有华人。哈。。

我的ID是jmjoy

2021/04/09 17:07

所以，我一直建议，全世界的语言专家联合起来，造一门没有明显倾向性的人造语言，全世界推广，这才是真正的国际化。

Jyang2016

2021/04/09 17:57

你好，有“世界语”

我的ID是jmjoy

2021/04/12 10:25

世界语有倾向性

G

GrayWaLL

2021/04/12 09:32

没有倾向性，那得把所有字母都换成火星字母，不然就跟“世界语”一样，无法服众，也不会有人用。但是，假设你真的设计一套”火星字母“，也不会有人去学。你这个建议是不可行的，语言的通行是与国家实力息息相关的，现阶段你无论如何也无法逃避英语的影响。

吴烜2020

2021/04/12 10:16

现在发帖为何用中文而不是英文？OSC不也可以被所有国外用户访问吗？没有明确的国外用户参与需求时，默认用母语表达和交流，不是很正常的事情吗？为何开源项目的标识符就例外呢？

我的ID是jmjoy

2021/04/12 10:26

说到底还是执行力度问题

Mr_陈

2021/04/09 17:00

class 你好 {} ?

吴烜2020

2021/04/09 23:22

在 vs code 中文代码快速补全插件的用户反馈中看到的实例之一是有“主动技”、“技能范围”、“概率伤害效果”等等与游戏业务相关的术语，这就很能体现母语命名的优势。

d

dwcz

2021/04/09 16:41

对老外，中文命名的问题不是看不懂，是有时没字体，连看都看不到--老外也有老外的难处啊。其实，更应该考虑提高编程效率和好的工具。只要是好的东西，人总会想出办法的。有好的中文命名，就应该用，不需考虑老外。没好的还是维持现状。中国人应该停止在这类问题上讨论了。

d

dwcz

2021/04/09 16:17

这点应该好解决。提供双语环境呗。只是现有工具都还不顺手。其实，关键还是文档问题--写一道都难写好，何况写两道。个人认为，最关键的是，应该把写者和读者分离。让写的顺手，看的顺眼。现有，打孔机模式，无形中，增大写者和读者之间的矛盾。说白了，事情复杂了，想一次搞定是不可能的，还是用分而治之吧。所有行业都在利用计算机的优势，唯独就是编程界一直在维持依赖靠改人模式为主--这大概就是看别人的缺点容易，看自己的难吧。

dxx2018

2021/04/09 16:02

这本身就是不自信的表现

FlashCHen

2021/04/09 15:18

所以你得标题用了火星文

金拱门

2021/04/09 14:41

一般来说，不论面向全球，还是国内。类名，方法名，变量常量等都会以英文来编码（除开特殊的关键术语，用中文拼音）。只要有这个习惯，就不需要在乎是不是英语了。

注释按照自己的开发规范，反正我注释都是写中文的。基于第一天，优秀的编码习惯，根本不需要写注释（API接口除外）。

能不能招徕国外用户……和语言这个没关系的。产品只要包含双语。国外用户自然会给你提交PR。

吴烜2020

2021/04/09 14:54

至少，用拼音的部分命名，建议改用中文命名，万一有国外开发者读到，不会误以为是什么特别英文缩写。

u

uitb

2021/04/09 13:11

注释习惯写中文的，但变量名函数名类名什么的写中文，反正我自己会觉得看着难受，英文就是当做符号用，整写中文在里面夹杂着，总感觉不伦不类的，一天天的来纠结这些个无关紧要的东西，大概就是某些人习惯喷的没创新吧，你爱写中文变量写中文变量呗，人家习惯用英文你管得着，人家英文开源你不爽别看啊，真的是一天天吃饱了没事干

吴烜2020

2021/04/09 13:24

如果命名标识符时把英文“当做符号用”，建议了解一下“代码可读性”，以及它在软件开发维护中的作用。

清帝

2021/04/09 12:16

长度米可比long_ri ce好多了

妙木山的大贤者

2021/04/10 10:11

然而用 length_meter 更 ok

w

wangxinxx

2021/04/09 12:07

有意思，中文文档和中文编程是两回事。语言保留字就像代数符号，不方便中文胜任。文档看受众，你定位国际化，要有英文是最好的，国内用仅中文也没有问题呀。计算机起源英文国家，支持其他语言都是打的类似补丁，个别软件中文目录都可能受影响。

吴烜2020

2021/04/09 12:36

此文探讨的不是语言保留字（关键词）的中文化问题，而是中文命名标识符（变量、类名等）

w

wangxinxx

2021/04/09 17:49

英文关键字，中文变量名，以后计算机行业肯定缺人，因为没有人能受得了。

吴烜2020

2021/04/09 23:31

中文命名作为一项技术，如果能切实改进项目开发维护效率，自然会被越来越多个人和公司采用。从中文补全插件的反馈来看，开发者的体验是明确的，分享一则：“觉得这个插件很好用，装了之后效率贼高，反正proground混淆了中文和英文没什么区别，写代码反而是更快更易读了”

开源中国首席技术官

2021/04/09 12:07

“木兰语言”已经实锤造假了，还天天当个宝一样拿出来秀。没什么“值得思量”的，到现在还在扯什么中文英文，这是中文英文的问题吗？

奔走江湖，天涯归处

2021/04/09 11:25

只面向国内生态的项目，的确可以尝试中文做标识符命名。

不过现在各种语言的关键字都是因为英文的，然后夹杂中文标识符，在我的感官上一般，尤其是输入的时候还不太顺手。有机会可以试试纯中文的编程语言+中文命名，这样可能感官上更好一些。

吴烜2020

2021/04/09 12:05

Intellij和vs code已有中文补全辅助插件。另外，在英文编程语言中使用非英文母语命名的表达和理解效率，试试便知，之前与 @欧阳春晖有过对比切磋。

奔走江湖，天涯归处

2021/04/09 13:51

我的不顺手主要体现在中英文切换和使用习惯上。例如定义函数，先输入function后，直接统一英文命名的话，我接下来写函数名称前只需要敲一下空格就行，而若是中文命名，那么我的输入法首先得确定为中文，所以输入function这个关键词之后需要先回车确认，然后再敲击空格，这样就会多一步操作，跟平时使用习惯有一些差异，需要一些时间来适应这种方式。

吴烜2020

2021/04/09 13:57

除了每次切换，还试过几种办法：1）输入法尽量保持中文状态，输入英文function后回车输入 2）借助此类补全辅助插件尽量保持英文输入状态：https://gitee.com/tuchg/ChinesePinyin-CodeCompletionHelper

奔走江湖，天涯归处

2021/04/09 14:03

这个补全插件有点意思，一会儿试试

乌合之众

2021/04/09 09:58

这个没有什么好说的。开发者愿意怎么来就怎么来，中文还是英文，都是开发者自己的选择，与他人无关。要觉得别人开源的项目使用中文（英文）不好，可以自己写一个替代品啊，you can you up,no can no b.b.
个人觉得，代码中文还是英文无所谓，不过注释和文档有中文的就比较方便。

吴烜2020

2021/04/09 11:18

更合适和可读的命名往往可以取代部分注释，毕竟注释的同步维护也是额外开销。这也是可读性审核的一个方面。

妙木山的大贤者

2021/04/10 10:14

其实那更应该用标准的英文了，这样注释基本可以不写

吴烜2020

2021/04/10 10:31

个人感觉，用“标准英文”命名和用“标准中文”相比，对中文为母语的开发者来说后者读写都更易。在挠头想不出英文命名时有个中文命名的备选项也挺香。

老牛拉货车

2021/04/09 09:43

我不反对中文编程，但刻意主张用中文替代英文编码，有种political correctness（抱歉中文被屏蔽了）的感觉。英文编程能让更大的群体参与，就像你使用第三方库，碰到文档和关键字是法语，你真的觉得很方便吗？

longforus

2021/04/09 10:39

支持

吴烜2020

2021/04/09 11:21

因地制宜，因时制宜。把命名方式看成“项目开始就敲定中文还是英文命名，整个项目必须保持完全一致，而且永远如此”的一锤子买卖，是个人不提倡的。

欧阳春晖

2021/04/09 14:07

项目是有开发规范的，你用了一般别人也会用

菜狗哉

2021/04/09 09:35

都没人用，谈何国外用户

Lenxvp

2021/04/09 09:34

不理解这里的英文标识符具体包含哪些，但如果是像API、变量等属于代码关键部分，使用英文仅仅是因为更好交流，更好理解，毕竟用拼音取名变量API有时候连说中文的人都看不懂，而英文变量不过是用一些比较简单的英文词汇，而对于项目名用英文，也不过是ISO之于“国际标准化组织”符号化标识。不过对于代码注释、文档一类，一些国内的项目，有时候也都只提供英文，而不愿意为国内的用户提供一下中文文档，就有些不太理解，中文也许在代码这种符号化标识方面确实不如英文，但在代码用意的表达能力上不觉的输给英文，真正优秀的项目，人家管你什么语言，开着机翻也愿意去读，但用母语注释写文档，为自己母语的用户提供便利，推动母语的国际化不也是一件好事？

撸代码的厨子

2021/04/09 09:24

自己的项目，怎么简单怎么来，共享的就算了

Jasper

2021/04/09 09:24

Ruby 1995年发布，早期也是日文资料比较多英文资料少，2000年左右进入美国后，英文资料多起来，2004年，Rails诞生，然后Ruby逐渐为世人所知。前后大约10年的时间，所以开源项目能不能成功是需要时间检验，所以一开始你爱用中文就去用呗，影响力能有多大？好好做好项目，项目有用才是王道。

欧阳春晖

2021/04/09 09:42

文档是可以双语翻译，标识符就不一定了，大量修改标识符意味着推翻重构，你以为那么简单？刚开始不做好准备，何谈国际标准，linux为什么一开始要建立在POSIX上，而不是自己一套标准，然后转入POSIX？你根本不懂设计

Jasper

2021/04/09 10:10

哈哈，我其实是主张一开始就把能想到的都应该去做，比如大家都用英文标示这样的惯例了，楼主爱用就让他用呗，大部分的开源都是为了开源而开源了，可能根本成不了事，就是一时兴起而已。

songdragon

2021/04/09 09:14

命名修改带来的是大量重构。还是支持一次命名到位，降低修改概率。

欧阳春晖

2021/04/09 09:43

完全同意

Jason909

2021/04/09 08:55

吸引外国开发者，对绝大部分的国产开源项目来说都属于异想天开。国际化不足以成为这些项目使用英文标识符的理由。

欧阳春晖

2021/04/09 09:40

刚开始不做好准备以后何谈建立国际社区？更何况，效率，可读性问题了解下。。

Jason909

2021/04/09 10:02

绝大部分国产项目从开始到生命周期结束都都没必要考虑国外开发者的问题。中文标识符不会给中文母语者带来可读性问题，甚至阅读得更快，关于可读性问题不如说一下英文和拼音混用，以及乱用缩写。

吴烜2020

2021/04/09 11:09

母语命名标识符在可读性上的优势，的确一试便知。

欧阳春晖

2021/04/09 14:09

等以后要改的时候，直接重构了，而且效率是大坑文件大小也是大坑，现在英文编程，源码都在这么大了，中文。。请考虑下通用编码和字体大小

吴烜2020

2021/04/09 14:51

之前对nginx-enhance-module中文化后的代码文件是5938 字节，原本英文命名的是 5552 字节，这还是在英文命名相对简单、有较多缩写的情况下，请问这种差异在什么开发环境下会有可感知的影响呢？

花

花花世界19

2021/04/09 08:49

说句不中听的话，中文就不适合编程。但适合给一些人打点鸡血，刺激一下自豪感

江柯

2021/04/09 09:04

就好奇，中文怎么就不适合编程了？

Altman

2021/04/09 09:06

你先把你项目里所有英文标识符换成中文试试，然后再协同开发试试

吴烜2020

2021/04/09 11:11

有何问题呢？https://gitee.com/Program-in-Chinese/vscode_Chinese_Input_Assistant/blob/master/%E8%A1%A5%E5%85%A8%E5%AE%9E%E7%8E%B0.js

王联

2021/04/09 13:45

手动赞

红薯片

2021/04/09 17:07

没啥问题，就是看不下去，直接关了

江柯

2021/04/13 09:26

你这完全就是偏见了吧，，

欧阳春晖

2021/04/09 08:43

这篇文章是说法明显偏颇，不刚开始做好准备，以后何谈建立国际社区？更何况，即便是国内，也几乎使用英文标识符，这是效率的问题，也是可读性问题

hyjiacan

2021/04/09 09:13

有道理。开发效率才是重点。来个简单的例子：比如，要声明一个整数变量，用于表示一个人的年龄，用中文是这样：整数年龄 = 32 而用英文是 int age = 32

欧阳春晖

2021/04/09 09:45

专业网工敲路由器命令行命令，都要用命令简写，还用中文，那些人是不考虑可读性和效率的一群人，我切个输入法都要几秒钟了？有这个时间早就一行代码输完了

吴烜2020

2021/04/09 11:14

中英标识符比长短？请分享一段原创的代码，我中文化后对比看看吧。

hyjiacan

2021/04/09 11:36

你居然觉得这是长短的问题真是好尴尬。。。

吴烜2020

2021/04/09 12:33

恕我眼拙，不解例子含义。如果是说输入效率，有需求就会有办法，通过开发环境与输入法的集成提供补全等输入辅助在二十年前易语言开始就有方案，近几年更出现了intellij和vs code下的中文命名补全辅助插件，今后此类功能会越来越完善。另外，中文命名的优势在业务相关术语尤其突出，比如“实付工程款”。

欧阳春晖

2021/04/09 14:06

比下敲键盘的数量再说

吴烜2020

2021/04/09 14:16

1, 开发周期中读代码的时间远超过“写”代码的时间。 2, 编写代码不是照着稿子打字，起命名是无论国内外开发者都头痛的任务，而引用时，也要首先“回忆”需要哪个 API、变量等等。这两方面母语命名都有相当优势。 3，用上上述中文补全插件之后，可以大大减轻切换输入法和输入完整中文词语的次数。

欧阳春晖

2021/04/09 14:32

你习惯就好，反正大家之前怎么编程，以后还怎么编程，我们继续使用我们的英语，你就慢慢的沉迷在你的中文编程吧，不想和你说了

pan3793

2021/04/09 02:01

可能体会不到看天书的痛苦吧。前阵子看ClickHouse资料时，Github issue时不时来个俄文，文档机翻中文，半残英文，切到俄文发现多了很多篇幅。去看源码，时不时来段俄文注释。现在已经好多，社区基本全面转向英文了。

吴烜2020

2021/04/09 02:45

不正说明ClickHouse项目是先在俄文社区发展完善后再逐步适应国外开发者参与么？

妙木山的大贤者

2021/04/10 10:22

这反而充分说明无论你先开始用什么语言写标识符，最后都得转向以英文为主

吴烜2020

2021/04/10 10:27

到“最后”—国际化合作开发的项目有多少呢？在到达“最后”之前有多少年是纯粹在国内开发者甚至于仅有自己奋斗呢？

妙木山的大贤者

2021/04/10 10:42

很多年前，我的项目只写中文文档和只发布中文版本（英文版本都只做了 2.0 发布到国外的一个论坛后因为网络问题一年都没去关注），然而那个项目在国内用的人很少，反而我之前在国外发的那个帖子后续还有人继续更新项目近况，然后不少人用谷歌翻译做了英文本地化版本（虽然有些简陋吧，但还能用）……那天被震撼的我，开始亲自做英文本地化，然后发布后没几分钟那群用户感觉特别高兴，后来随着经验的增加，于是逐渐就变成用英文写代码、注释和提交注释，然后文档也是先写英文，当然最后发布前会翻译成中文。

吴烜2020

2021/04/10 10:58

请问是哪个项目？想学习一下国际化合作之路。

妙木山的大贤者

2021/04/10 11:15

回复 @吴烜2020 : 小项目而已(虽然用的人不算少)，仓库地址 https://github.com/M2Team/NSudo，当然至今也能在我最早发布项目的国内论坛（远景论坛，而且我还是版主）看到有人把 NSudo 3.0 的老外谷歌翻译版给搬过去（而我在远景都发布到 8.0.1 了，也是挺有趣的)

吴烜2020

2021/04/10 12:34

回复 @妙木山的大贤者 : 刚看了合作者，好像国外开发者有 myfreeer Margen67 fcharlie obando777 fossabot Thdub 这几位？看了他们的 commit，似乎基本上是界面本地化和项目配置。个人很理解原创项目有国际合作者的成就感（想起之前个人这个小插件虽然用了中文命名标识符也有国外开发者做了小改进和本地化：https://github.com/program-in-chinese/HistoryInThreads_WebExtension ），但毕竟现状是绝大多数国内开源项目没有看到那一天，即便有国外开发者参与，往往也是在项目成型数年之后（像 NSudo 是 2015 年开始，到 2018 年之后才有国外参与吧），那么是否在项目开始之时就全部用英文标识符，个人认为需要视人、项目、进展而定，不用强求“全英文”、“全中文”、“一成不变“。

妙木山的大贤者

2021/04/10 13:12

回复 @吴烜2020 : 其实 NSudo 是从 2014 年 5 月开始的（那时我还没有上传 GitHub，只是在远景论坛公布源代码），然后 2016 年 2 月之后开始亲自做英文本地化，其实直接去 GitHub 贡献的人并不多，大部分还是反馈 Bug（可以参阅 MDL 论坛 NSudo 的帖子）……还有贡献者名单里，myfreer 和 fcharlie 是国内的开发者，其中 fcharlie 曾经是 Gitee 的核心开发人士（在项目方面给了我大量的指点，其中包括使用 MIT 许可，引入连续集成等）

妙木山的大贤者

2021/04/10 13:27

回复 @吴烜2020 : 倒是 2018 年开始我参与了国际上一些开源项目的贡献，譬如 winfile（引入简中翻译）、OpenSSL（UWP 平台支持）、LVGL（Windows 模拟器仓库、Windows 移植仓库），但更多的还是维护 NSudo 与个人项目的公共库 Mile（虽然几年前还搞了个叫 Nagisa 的下载工具，然而那个项目暂时搁置），然后向前辈反馈 VC-LTL 的问题和建议且佛系更新 MINT（一个 Windows 非公开 API 的单头文件定义），顺便关注下朋友做的 CovScript（Windows 支持改进、裸机移植）……倒是因为我在 GitHub 上做的贡献和代码风格，去年毕业后被人挖到一家还算不错的公司做着一份有双休日的工作，所以我只要有精力，于是也会一直做开源，当然还是以英文为主，中文的话我至少会提供文档。

吴烜2020

2021/04/10 13:27

回复 @妙木山的大贤者 : 谢谢分享，之前不知道 MDL（是这帖吧？ https://forums.mydigitallife.net/threads/nsudo-series-of-system-administration-tools-general-thread.59268/ ）。个人感觉是这样，无论国内外开发者，能够后续加入项目并成为核心贡献者的（功能添加、大重构、关键 bug 修复、文档编写等等），尤其是已经超过千行的功能较复杂项目，是用户中的极少数几个，绝大多数用户还是会期盼原作者更新。当然也与项目性质有关，用户群越是项目本身技术栈的开发者，参与度也会越高。比如 Nsudo 貌似主要用户群是系统管理员，而项目用的主要是 C++开发，而系统管理员的 C++开发经验并不是普遍有（个人猜度），那么他们的项目开发参与度比例就会更小。

妙木山的大贤者

2021/04/10 13:53

回复 @吴烜2020 : 参与度不高也很正常，毕竟这年头 C++ 开发者就比较少，如果还要求对 Windows 开发比较了解的那种就更少了（笑

袁德俊

2021/04/12 18:07

对的，项目本身是关键。我也分享个类似的体验。我们维护了一个棋盘游戏的国际史数据库，发起方是欧洲的一个研究机构，我带学生维护中国史部分，一个是国外的游戏在中国的传播，一个是中国本土的游戏的国际化。在GOOGEL的时候，找到一个特别古老的一个BBS，基本很多帖子都是半年冒一个泡的。一看都是老玩家。我找到一个中国的游戏样本，全部是老外自己嗨，转帖了好多中文搜索结果，然后用GOOGLE一通翻译，90%都不对，还有有沾边儿的。我就回了一句，发了一段录的棋谱，结果就成热帖了，连续1周，版主给置顶，热烈讨论。还是那句，项目本身是关键，语言命名不重要。妙大人的项目现在用英文维护，肯定是必须的，粉丝是歪果仁吗。我现在天天发邮件，开始还字斟句酌，英文水平有限，最后还是用代码说事儿。真正想沟通了，语言不是问题。前两天看莫言的一个纪录片，外国的翻译家到他老家看书中描写的场景。就是这个意思。GITEE能置顶这个帖子，我想是其 “不做中国的GITHUB, 要做国际化的 GITEE”的一个愿景吧。有这个愿，就一定可以实现，早晚的事情。多做项目，多分享，多PR吧。

吴烜2020

2021/04/12 23:57

回复 @袁德俊 : 为国外开源项目出力和自己原创开源项目情况不同，与打工和自创公司的区别类似。项目由谁主导当然也是技术选择—包括中文命名的重要考虑因素之一。

osc_566335

2021/04/13 09:15

如果不先以俄文为主，聚集国内的支持者，会不会连“转成”英文的机会都没有了呢？想想你这个思考是否属于“幸存者偏差”的错觉？那些根本没发展到这一步的项目，为啥要非要E文来减少受众徒增成本呢？

吴烜2020

2021/04/13 10:34

除了减少母语同为中文的开发者的项目参与度之外，最大最直接影响的应该还是项目作者自己，尤其是占据大多数的单人开源项目。本身时间就紧，也没有合作者审核，命名时稍一放松随意就可能写出过几天自己看起来都像天书的英文命名。