Xuan Wu

@lc6464 这位做了白话语法的：https://github.com/Zhou-zhi-peng/cnpl @rainmanhhh IDE 技术上可以做到支持内置输入法，像 [这个](https://github.com/tuchg/ChinesePinyin-CodeCompletionHelper) IntelliJ 下的中文补全辅助插件。

Another way to crawl is to load the page in tab, and grab the content on page complete. Just tried with the link @appjitsu posted and seems to work fine....

个人倾向于做库, 因为不会依赖具体某个IDE, 而且我还是用的Eclipse :) 另外, 倾向于代码直接是中文, 而不是显示成中文而实际还是英文. 有兴趣的话大可以试做插件.

对于已有的代码, 确实是个办法. 建个中英对照表, 然后通过插件方式显示成中文. 不过太久太久没有做插件所以不是很有动力 )) 个人觉得, 如果没有打算吸引非中文母语的程序员参与项目, 那么重构一下现有代码(纯粹重命名)也是值得的, 毕竟IDE对重命名的支持应该不错. 当然这是站着说话不腰疼, 因为我暂时还没有做过大规模把已有代码中文化的事情. 如果有项目想试着中文化, 欢迎开新issue讨论.

Sorry! 竟然漏看了后三楼! @sih4sing5hong5 感觉我们都同意接口(API)本身汉化是有价值的. 就像你说的1-4, 这样可以让使用这些API的用户逐步适应和开始用母语编程. 请问你的倾向是用母语开发新的库, 而不是把现有库的接口翻译成母语吗? 那提到[结巴](https://github.com/fxsjy/jieba)的意思是新建一个它的branch, 然后在它的源码里修改所有接口吗? 比如: ``` jieba.cut -> 结巴.切分 jieba.suggest_freq -> 结巴.调节词频 ``` @ice1000 确实, 已有代码换用汉化API会有工作量, 不过如果光是重命名的话应该还好, 毕竟没有改接口本身的设计. 刚在那个汇编器的测试代码里把assertEquals换成了'相等', 替换方法和import, 还算不麻烦. 关于空格和分号, 我现在把输入法设置成了"中文下使用英文标点", 所以包括（，“。；都是英文....

欢迎发表不同看法. 在建讨论组之前也看到过一些类似的. 虽然不一定能够完全说服对方, 不过就像迎新帖里说的, 中文编程的范围足够广, 总能找到一些自己愿意着力的方向并且有所突破. 至于其他暂时不认可的方向, 也请抱着宽容的心态进行探讨和建议. 也是一些个人看法: > API应当是国际化的 对于现有的英文API, 并不一定要通过修改它的源码改成一个纯中文版本, 更可行的可能是对它作扩展, 比如[汉化JUnit的assert系列方法](https://github.com/program-in-chinese/overview/issues/10). > 就像在很多UI设计中我们用一些占位符来替代文本，然后在资源文件中给出对应不同区域语言的实际文本一样。代码库的API应该只是纯粹的符号，可以被符合规范的编译器处理，生成我们想要的程序。而至于API的语义应当由独立于程序之外的注释和文档来描述。虽然自注释的变量方法名可以提高对人类的可读性，但那并不是代码本身该做的事，代码该做的事是对编译器描述一段正确的程序。 不敢苟同. 听起来你认为API以及内部方法/变量的命名无关紧要. 有不少readablity相关的文章, 比如[Writing for Readability](https://www.codeproject.com/tips/815600/writing-for-readability) > 比起将代码库的API直接翻译成中文，是不是翻译API参考文档更好呢？关于API汉化问题, 有不同的实现方法. 翻译参考文档从维护的工作量来说, 只会比通过扩展来汉化API更加大. 因为如果API本身被修改了, 文档的改动量肯定比API名称的改动量大....

@azige 漏说了一块: > 不利于非中文编程者贡献 这是个很值得探讨的问题. 我看到的现状是, 中文开发者自己开发的开源库/框架, 绝大多数的贡献者也都是中文开发者. 原因肯定是多方面的. 能够想到的有: - 多数库有类似功能的国外开源项目. 作为外国程序员首选参与的肯定是那些 - 如果是和中文本身相关的库, 比如结巴分词之类的, 主要的用户也是中文开发者, 自然维护的也是 个人也不赞成100%的中文化. 需要和国外交流的项目肯定有. 但就像overview主页说的, 为了1%(假定的数字)的硬性需要而在99%的其他项目中强制使用英文编程, 恐怕是得不偿失. @ice1000 欣赏了魔改版, 虽然魔音缭绕, 但是颇为亲切 lol

@ice1000 我这里现在时间是周日中午12:20 :) 现在吃不消熬夜啦 最多到1点 @azige > 毕竟读为人类而写的文档比读为机器而写的代码肯定是更容易的，并且API的命名本身并不能包含其使用方法和规则。 API的读者就是开发者吧? > 虽然设计这样的语言可能比直接翻译SQL的工作量会多，但这样的语言才有中文的价值。 个人对汉化编程语言的关键词兴趣其实不大(早先[汉化过coffeescript的关键词](https://github.com/nobodxbodon/coffeescript)). 现在觉得代码里主要的语义是自定义的类/方法/变量, 所以可以直接开始中文编程的实践, 不用先汉化语言关键词. 之前是就你的例子的个人观感而已. 我也同意如果要汉化某个编程语言的关键词, 还不如探索接近中文使用习惯和语法的新语言. 不过汉化API和汉化语言的关键词又有点不同. 大赞一下你的Groovy框架和例程. 不知框架能不能开源? 一起学习一下. > （真实的例子，本人的 moebooru-viewer 原本是为了解决个人需要和某站被墙的问题弄的，结果突然某天有人提交了一个加入多语言支持的 PR 😭 ） 多谢分享!...

@buyouyuan 赞一下. 求同存异最好. 不过好像没有发现谁把全部中文化作为当前目标的 :)

@azige 嗯, 对于中文代码的可读性提高(对于中文母语的开发者), 是个暂时没有考据的论题. 也正是我现在进行实践想要探索的. > 虽然不太妥当，但是既然在osc上发表的话就是适合”入乡随俗“使用中文的场景呀（笑） 如果这么说, 好像也对 :) 说起来在osc上还没有好好挖掘过中文代码的项目, 嗯, 有空试试 > 本人觉得使用了自己会的英文单词，然后附上必要的中文注释，就足够维护自己开发的项目了 关于注释和命名, 在我之前的工作环境里, 是我第一次接触正式的可读性审核. 可惜自己没有正式成为可读性审核员, 不过也吃过猪肉(每个commit都被审核过). 有个印象是, 审核员会尽量倾向于减少注释量, 而强调代码本身的可读性(其中最重要的因素之一就是命名). 审核里会不时出现"这个方法名已经self-explaining了,注释就不用了"之类的评语. 虽然没有当面确认过, 但写注释和维护注释的额外工作量应该也是这种倾向的动因之一. 算是我对于命名对于可读性的意义的实践体会吧. 对于从开头就希望融入外语开发者社区的项目, 如果能够吸引外语开发者的参与, 并且成型和壮大,...