@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

@sherylynn 嗯, 这些小项目应该是通过中文命名投入产出比最高的. 代码可读性提高又使自己的维护和改进省力很多. 专栏里之前写过一些 python 小工具 /浏览器插件, 都是中文命名.

@hcivincentchan 嗯 组里多数项目都是中文命名 因为面向中文用户

@quietjosen 哦? 之前倒没注意过这个.
这个同时取命名里的多个词应该也算特色之一. 只是还离像样的机翻还远得很. 估计要先在 JB 版里改进了(见 https://www.v2ex.com/t/507615 ), 毕竟 Java 的 nlp 库更成熟一些.

@xpresslink 多谢. 需要考察一下词库. 个人感觉现在这个词典质量还可以. 主要的提升空间应该是在全命名翻译.
在线翻译 API 的次数限制还是想尽量避免, 不过也许在用户数不那么大的时候是有益补充. 到时候看工作量和用户数量综合考虑吧.

@evam 多谢支持. 正好刚把工作环境切到 IDEA.
如有进展会尽早告知.

@springmarker
@xpresslink 看到排名前两位的插件"Translate"使用了有道 API, "ECTranslation"应该也是有道.
所以打算做的有两个主要优势:

1. 离线词典数据, 不依赖在线翻译服务, 因此不存在 API 访问次数限制问题.
2. 支持驼峰 /下划线命名, 虽然翻译质量还很原始, 但至少支持同时查询一个命名中的所有词

@xpresslink 请问是哪个?

没有用 Visual Studio 的吗? 看了几个排名都在前面.

@shaojz2005 不在目标之内. 毕竟个人倾向于尽量在业务代码中使用中文命名.

@tt67wq elisp 不大了解, 估计要在工作需要重拾 scheme 之类的时候再考虑了..