讨论组内首次微信语音聚会将于北京时间 2018 年 12 月 1 日周六 14:00-15:00 进行. 如有兴趣参与请尽早申请入组, 方式见顶楼.
https://github.com/program-in-chinese/overview/issues/66#issuecomment-443129093

@luvxy 顶楼链接的文章中有, 从 vue 原 repo fork 出后添加的"translate-source"branch: https://github.com/program-in-chinese/vue/tree/translate-source

@zado 多谢支持.
关于自动转换插件, 之前做的浏览器插件(火狐 & Chrome) 是个原型: https://www.v2ex.com/t/505052 但还没有进行机器翻译的改进
这个项目主要目的是探索手工翻译现有源码库的问题和方案. 不知哪些部分最有帮助? 现在翻译的部分有: 文件名, 变量 /方法名, 文本内容(比如提示信息'Vue 是构造器, 需要`new`调用')

@swcat
@windfarer
@zingl 见 #7 关键字可以中文化, 见"修改 V8 和 node.js 建立中文后端开发工具"(非本人作品): https://zhuanlan.zhihu.com/p/44953946 但此项目打算尽量不影响工具链.

@tiaod 短期内用英文关键字应该是投入产出较高的, 但中文关键字 /语法的工具链应该会随着中文命名的推广而逐渐应用和成熟.

@murmur
@summerwar
项目是打算一直保持编译和所有测试通过的 (每个 commit 都运行过了 npm test), 因此除非要同时维护一个支持中文关键词的编译器(组里之前做过, 不过维护肯定工作量较大), 这一点恐怕做不到.

@imydou 现在就已经开源, 链接在前文. 暂时作为 vue repo 的一个分支. 本身 vue 的许可证好像是允许另外包装的, 不过个人不打算这么做.

@hsfzxjy 参考了微软的 TS 官方文档. 请见文章中的链接中的术语表.

@luoway 个人看来这类似于逐行注释 直接把源码中文化应该更直接提高可读性

@TomVista 是 vue 项目文档比较完备 测试也多 毕竟这么些年沉淀了

@514656282
@zgl263885
@gstqc
@TomVista
刚开始 vue.js 源码中的文件名翻译: https://www.v2ex.com/t/510083

@vcinex "代码可读性"

@likuku 见 #35

@likuku 代码有"自说明"特性, 外文书籍没有?
JDK API 光是 util 包就有 800 多单词, 整个 JDK 接口有三千多. 这还只算了 API 部分, 没算源码中的词. 外文 IT 专业书籍的单词量不一定比这大多少吧.

@corningsun
@XinLake 嗯, 个人更关注源码本身的翻译. 文档对最终用户有益但对消化开源项目本身&提高自研能力好处很有限.

@kslr 有幸遇到啊。账号被封？是在那次事件中吗？还是其他原因？
项目事件后的流水一直挺惨淡的。很少项目过百的。也亏得他坚持那么久

@loading 至少有实质进展再联系. 测试都还没跑过.
年末都放假了八字没一撇的事何必打扰他.

@zgl263885
@ian19znj 见#14 末句

@loading
@mohoumk2 文档变化往往跟不上源码

@TomVista 多谢推荐, 不知有什么特别原因吗?

另外, 初步决定从 vuejs 开始, 没看错的话大约 1 万六千行源码. 还在熟悉构建和测试环境.

@secondwtq 商业公司通过开源获得人力资源是一种在推广的同时吸引劳力, 加速建立优势的方式(开源初始并不一定已有市场优势), 这种方式与其他已有市场优势地位的闭源项目用于维持或者延长优势地位采用的各种其他方式(商业宣传 /招聘)没有本质区别. 在此过程中公开了无论是不是"没那么重要"的技术, 总归是好事, 这也是楼主文末说到的, 假以时日, 在现在开源项目中处于边缘的国内开发者, 通过这么些年的学习(和对国外公司的无偿贡献), 迟早会有自己的核心项目和社区形成.

@DjvuLee 我并不认为楼主原意是拒绝开源, 而是探讨商业公司开源项目的商业目的. 毕竟在商言商, 商业运营必需要劳力和用户. 诸位是不是把商业开源和非盈利的开源组织混为一谈了?

@kingwl "任何人"? 源自 wiki:
英语的母语使用者: 360 – 400 million 第二语言使用者: 400 million; 作为外语使用者: 600 – 700 million, 总计算 15 亿
中文的仅仅算母语使用者: 12 亿
世界总人口: 77 亿

@hxd
@ericls 暂时日常工作交流的英语够用了, 谢谢关心
万一翻译后的代码库有人跟进, 说明有对口资源, 不觉得会影响原本想往原代码库贡献的开发者, 何谈分裂社区?

@binux 很高兴看到你并不是针对中文编程. 在下只是 IT 界的小学生, 业余在海滩边捡捡贝壳而已.

@aXxxxX
@monsterxx03 市面上大把中译书籍, 说明有其需求. 这本质上和翻译书籍没有区别.

@wallriding 嗯, 这值得研究. 打算在翻译过程中记录一下翻译的命名个数 /出现数, 以及大概耗费的时间.

@starcraft 实际上开展中文命名的公司也许比十分之一还少. 本站搜集的: https://www.v2ex.com/t/477109 不过推广几年应该会看到井喷.

@sylxjtu 无论词汇是否认识, 对母语的敏感度总归高于第二语言.

@kingwl
@lance6716 关于 TiDB, 也许正说明了: 程序是没有国界的, 但程序员(或者所在的公司)有

在#90 链接里, 有另一个方面的阐述:

现状是, 中文开发者主创的开源库 /框架, 绝大多数的贡献者也都是中文开发者, 即使非常流行和国际化的框架如 vuejs 也是如此. 原因肯定是多方面的. 能够想到的有:
- 有类似功能的国外开源项目. 作为外国程序员首选参与的肯定是那些
- 如果是和中文本身相关的库, 如结巴分词, 主要的用户也是中文开发者, 自然维护的也是

@secondwtq 在"技术没那么重要"的情况下, 尽量利用先发优势扩大影响就直接影响生存了. 见#90 通过开源加速建立开发者社区是一个重要方面.

开源导致社区资源愈加集中于已处于领域优势地位的项目(如 Chrome)是必然的, 这是富者越富的一个方面--越不缺人力资源的地方越有人力资源.
楼主提到的两个问题非常现实(角色边缘, 代码很难消化). 而根源还是在于代码难以消化. 这就和英语命名有关. 正好今天回答的一个问题"中国为什么没有 Apache?"有异曲同工之处: https://www.zhihu.com/question/268978889/answer/535028630