Azige

关于汉化现存编程语言以及其库的问题，请允许本人稍微长篇大论一下拙见。 本人在[这里](https://github.com/program-in-chinese/overview/issues/2#issuecomment-320438155)提的观点是“汉化现存编程语言及其库的意义不大”，并给了个简单理由，即“汉化现存编程语言以及其库会难以维护且不利于非中文编程者贡献”，这个理由似乎还是普遍受认同的。本人在此提出另外两个理由。 #### API应当是国际化的 就像在很多UI设计中我们用一些占位符来替代文本，然后在资源文件中给出对应不同区域语言的实际文本一样。代码库的API应该只是纯粹的符号，可以被符合规范的编译器处理，生成我们想要的程序。而至于API的语义应当由独立于程序之外的注释和文档来描述。虽然自注释的变量方法名可以提高对人类的可读性，但那并不是代码本身该做的事，代码该做的事是对编译器描述一段正确的程序。比起将代码库的API直接翻译成中文，是不是翻译API参考文档更好呢？ #### 基于英语语法的语句难以翻译成妥当的中文 举个可能不恰当的例子，将SQL语句 `SELECT p FROM person WHERE p.age > 20` 直接汉化关键词和标识符的话就变成 `选择 人 从 人物表 满足 人.年龄 > 20`，原句是通顺的英文而汉化后是蹩脚的中文。大部分基于英文的编程语言和一些库的API设计都是尽可能接近自然英语的语法的，而这样就会导致直接汉化关键词和标识符出来的结果非常莫名奇妙。因此比起汉化现存编程语言和其库，是不是基于中文语法设计全新的编程语言和库更好呢？

@nobodxbodon > 对于现有的英文API, 并不一定要通过修改它的源码改成一个纯中文版本, 更可行的可能是对它作扩展, 比如汉化JUnit的assert系列方法. 这点本人倒是支持，中文化的扩展还是有帮助的。但是本人是坚定的反对“把所有的一切都变成中文” > 不敢苟同. 听起来你认为API以及内部方法/变量的命名无关紧要. 有不少readablity相关的文章, 比如Writing for Readability 可能本人表达不准确。本人认为代码的可读性是很重要的，但通过注释和文档来描述API的使用方法和规则更重要。毕竟读为人类而写的文档比读为机器而写的代码肯定是更容易的，并且API的命名本身并不能包含其使用方法和规则。 关于那个SQL的例子，如果设计 `从 人物表 选择 符合 人.年龄 > 20 的 人` 这样的语言是不是比直接翻译的那样的蹩脚要好呢？虽然设计这样的语言可能比直接翻译SQL的工作量会多，但这样的语言才有中文的价值。 给个本人在工作中实际使用中文编程的例子表明一下立场 😃 以下是本人的工作项目中的一个Groovy脚本的片段，本人为这种脚本写了一个简单的框架，脚本是不懂编程的游戏设计写的 def...

@nobodxbodon > 中文开发者自己开发的开源库/框架, 绝大多数的贡献者也都是中文开发者 > 但就像overview主页说的, 为了1%(假定的数字)的硬性需要而在99%的其他项目中强制使用英文编程, 恐怕是得不偿失. 能预测到某个项目只会有中文编程者使用倒还好，那些预测不了的，即使是单人项目，都不知道哪一天会不会突然有国际友人参与进来（真实的例子，本人的 [moebooru-viewer](https://github.com/azige/moebooru-viewer) 原本是为了解决个人需要和某站被墙的问题弄的，结果突然某天有人提交了一个加入多语言支持的 [PR](https://github.com/azige/moebooru-viewer/pull/1) 😭 ） 本人的观点基本上是“入乡随俗”，在Java中就使用英语，在易语言中就使用中文。因为学过Java的程序员应该有90%都是会英语的，而学过易语言的程序员应该有100%都是会中文的。

@nobodxbodon > API的读者就是开发者吧? 嗯～实在不知道怎么表达了，简单的说把 `list.add` 翻译成 `表.添加` 对中文编程者提供的帮助并不如把 http://docs.oracle.com/javase/8/docs/api/java/util/List.html#add-E- 这段翻译成中文所提供的帮助大。 关于代码可读性的话本人无法提供合适的论述，在本人看来只要命名良好，英文和中文是等价的（但是中文的参考文档对中文编程者来说更可读）。 > osc上一些即使很热火的开源框架, 比如JFinal, 大多只有极少的其他开发者贡献. 个人认为一个很重要的原因, 就是代码很难阅读, 而英文命名是一个主要的障碍 虽然不太妥当，但是既然在osc上发表的话就是适合”入乡随俗“使用中文的场景呀（笑） > 我首要考虑的是对自己的开发和维护最有利的编程方式. 因为在可以预见的将来, 我自己会是最主要的贡献者. 如果我自己的开发和维护成本随着项目变大而变得不可持续, 那么在项目成型和能够吸引其他开发者参与之前可能就夭折了. 我自己的感觉是用中文命名是我更熟悉和容易的方式. 这点可能就是非常的视个人习惯而定了。本人觉得使用了自己会的英文单词，然后附上必要的中文注释，就足够维护自己开发的项目了，至少我自己是这样。虽然也可能因为英文能力不足出现蹩脚的命名，但那些对英语母语的人来说应该还是能理解的，而对中文编程者来说还有中文注释能参考。 要在自己的项目里使用什么语言就自己决定好了，让其他人”入乡随俗“吧。但是一个考虑到要国际化的项目最好还是用国际化的语言的。

突然想提一下Java。Java是本人很喜欢的一个平台，原因之一就是他对中文用户非常友好，本人的很多对中文化编程方向的观点也来自于对使用Java平台的体验。 #### Java平台没有什么？ - 没有提供中文API #### Java平台有什么？ - 从编译到运行都有对Unicode的支持，写中文注释和标识符都没有问题 - Java 6 曾经提供过完整的中文的API参考文档（sun的遗产，oracle接手后似乎就没再搞过了，其网站现在也不提供下载了，本人这里留了一份→ https://pan.baidu.com/s/190DlW ） - JDK的大部分工具都有中文提示信息 - Java似乎是本人见过的唯一一个对异常信息提供了国际化支持的平台，并且一些JDK库中抛出的异常都有中文化的信息。虽然实际使用中并没有很多开发者为异常信息提供多语言支持 - 官方赞助的 NetBeans IDE 有中文语言支持 @nobodxbodon 关于“入乡随俗”，Java中有个无论如何都回避不掉的问题就是JavaBeans规范一定要你使用set/get命名。除去Java本身之外，Java生态圈里很多命名约定也都是基于英文的（例如maven版本号的 `-SNAPSHOT` 特殊语义，旧junit中需要测试的方法必须以test开头等），如果在命名中使用中文，又要遵循这些约定的话，就会变成奇怪的中英文混合命名，又或者是要把这些约定本身都给汉化（甚难，得不偿失）。所以本人的观点还是维持在“没有必要让API中文化，而是在周边提供中文支持”。当然，以扩展中文API的方式提供一些便于中文编程者使用的工具本人还是支持的，但是核心部分还是尽可能“入乡随俗”比较好。

@nobodxbodon 别忘了易语言～本人的观点是“最好不要汉化现存的基于英语的编程语言，而是开发新的基于中文的编程语言”，或者基于一些语言设计纯净的中文DSL也是很好的选择。（就像汉化junit的那些方法一样，本人还是支持的 😃 ）

@swizl 修改编译器令其支持中文字符集这点本人支持。开发新语言的话，至少本人并不打算开发通用语言，可能只是开发一些特定于领域的语言或者教学用的语言，这些还是有应用价值的，可以参考这个讨论 https://github.com/program-in-chinese/overview/issues/19 。 假如有一种简单易用的能处理文件系统的中文的脚本语言的话，本人的学不懂英文编程语言(哪怕是win bat)的非程序员同事就可以写个脚本来给一堆资源文件批量改名，而不是花两个小时去一个一个改名了(笑)

偶然路过，幸会各位前辈。本人是个普通的Java程序员，在之前也见过一些一股脑想汉化Java的人，正好在这里想简短的说一下本人的观点。 #### 本人支持的观点 - 中文编程能降低编程入门门槛 - 中文程序可以提高对中文母语编程者的可读性 #### 本人认为没有意义或意义不大的工作 - 汉化某种现存编程语言 - 汉化某种现存编程语言的库（简单理由：难以维护，不利于非中文编程者贡献） #### 本人认为有意义的工作 - 汉化现存编程语言或库的文档 - 汉化现存辅助软件开发的工具中的文本（如IDE、SCM、编译器以及近在眼前的GitHub等） - 设计新的易学易用的中文编程语言（但是很可能仅限于编程教学使用） - 在软件中提供面向初级用户的可以使用中文编写脚本的功能（就像按键精灵那样） - 设计通用的中文脚本语言（为上一条服务） 本人对编程中文化也是很有兴趣的，但是总觉得应该把劲用对地方才行？

游戏设计方面可能有很多应用，例如编写技能脚本或敌人的行动策略之类的

https://stackoverflow.com/a/61620 It depends: 1. Does your team conform to any existing standards that require your using ASCII? 2. Is your code ever going to be feasibly reused or read by...