把最常用的开源的英文API进行中文化

[nobodxbodon]

用某种编程语言的大多数项目里都依赖的第三方库可能就几十个 (比如Java里的JUnit, Log4j, Guava, ApacheCommon等等 - Java's top 20: The most used Java libraries on GitHub). 而这些库里最常用的接口可能不到10%,所以中文化可以增量进行,维护的工作量应该比较可控.

另外, 对核心库的中文化是个工作量更大的挑战, 因为包括文档的翻译, 而且可能会有不可能汉化的部分(比如无法用一个新interface取代Iterable的问题). 这里是尝试对Java核心库的汉化. 比如ArrayList汉化成"数组列表", 单元测试示例如下:

public class 数组列表测试 {

  // TODO: 添加测试“取”方法
  
  @Test
  public void 测试添加元素类() {
    数组列表<Integer> 表 = new 数组列表<>();
    表.添加(1);
    assertTrue(表.长度() == 1);
  }

  @Test
  public void 测试添加整数元素类() {
    数组列表<Integer> 表 = new 数组列表<>();
    表.添加(0, 2);
    assertTrue(表.长度() == 1);
    表.添加(0, 1);
    assertTrue(表.长度() == 2);
  }

  @Test
  public void 测试Collections方法() {
    数组列表<Integer> 表 = new 数组列表<>();
    表.添加(2);
    表.添加(1);
    Collections.sort(表.原型());
    assertTrue(表.取(0) == 1);
  }
}

请大家头脑风暴一下. 这个思路是否可行,或者对哪些语言比较可行.

[ice1000]

你可以搞个IntelliJ IDEA 插件来把这些API显示成中文

[nobodxbodon]

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

[ice1000]

If we can display them in Chinese, by the same technique, we can display the reserved words in Chinese too. If the names are real Chinese there'll be lots of problems, like, we have to do lots of rewrite.

[nobodxbodon]

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

[ice1000]

Eclipse sucks

IntelliJ IDEA is much more powerful

[sih4sing5hong5]

我個人認為用母語做一个好用的函式庫會比共一个好的函式庫翻譯做母語效果好

親像：
共結巴接到別的語言，閣用母語定API，效果可能會較好一屑

update:

1. 逼逐家程式內底有母語
2. 逐家慣勢程式內底有母語
3. 逐家開始用母語創作
4. 才閣改程式語言本身

[ice1000]

真棒，我终于装上中文输入法了

另外 重新做API的话 迁移现有库是比较困难的哟。

[ice1000]

还有一个不是问题的问题——空格和分号你们觉得全角好还是半角好

[nobodxbodon]

Sorry! 竟然漏看了后三楼!

@sih4sing5hong5 感觉我们都同意接口(API)本身汉化是有价值的. 就像你说的1-4, 这样可以让使用这些API的用户逐步适应和开始用母语编程. 请问你的倾向是用母语开发新的库, 而不是把现有库的接口翻译成母语吗? 那提到结巴的意思是新建一个它的branch, 然后在它的源码里修改所有接口吗? 比如:

jieba.cut -> 结巴.切分
jieba.suggest_freq -> 结巴.调节词频

@ice1000 确实, 已有代码换用汉化API会有工作量, 不过如果光是重命名的话应该还好, 毕竟没有改接口本身的设计. 刚在那个汇编器的测试代码里把assertEquals换成了'相等', 替换方法和import, 还算不麻烦.

关于空格和分号, 我现在把输入法设置成了"中文下使用英文标点", 所以包括（，“。；都是英文. 主要原因是省得每次输入"."都要切换输入法. 这样设置之后Java下中文开发感觉舒服了很多. 如果你指的是新的语言,那就是另一个问题了.

[azige]

关于汉化现存编程语言以及其库的问题，请允许本人稍微长篇大论一下拙见。

本人在这里提的观点是“汉化现存编程语言及其库的意义不大”，并给了个简单理由，即“汉化现存编程语言以及其库会难以维护且不利于非中文编程者贡献”，这个理由似乎还是普遍受认同的。本人在此提出另外两个理由。

API应当是国际化的

就像在很多UI设计中我们用一些占位符来替代文本，然后在资源文件中给出对应不同区域语言的实际文本一样。代码库的API应该只是纯粹的符号，可以被符合规范的编译器处理，生成我们想要的程序。而至于API的语义应当由独立于程序之外的注释和文档来描述。虽然自注释的变量方法名可以提高对人类的可读性，但那并不是代码本身该做的事，代码该做的事是对编译器描述一段正确的程序。比起将代码库的API直接翻译成中文，是不是翻译API参考文档更好呢？

基于英语语法的语句难以翻译成妥当的中文

举个可能不恰当的例子，将SQL语句 SELECT p FROM person WHERE p.age > 20 直接汉化关键词和标识符的话就变成 选择 人 从 人物表 满足 人.年龄 > 20，原句是通顺的英文而汉化后是蹩脚的中文。大部分基于英文的编程语言和一些库的API设计都是尽可能接近自然英语的语法的，而这样就会导致直接汉化关键词和标识符出来的结果非常莫名奇妙。因此比起汉化现存编程语言和其库，是不是基于中文语法设计全新的编程语言和库更好呢？

[nobodxbodon]

欢迎发表不同看法. 在建讨论组之前也看到过一些类似的. 虽然不一定能够完全说服对方, 不过就像迎新帖里说的, 中文编程的范围足够广, 总能找到一些自己愿意着力的方向并且有所突破. 至于其他暂时不认可的方向, 也请抱着宽容的心态进行探讨和建议.

也是一些个人看法:

API应当是国际化的

对于现有的英文API, 并不一定要通过修改它的源码改成一个纯中文版本, 更可行的可能是对它作扩展, 比如汉化JUnit的assert系列方法.

就像在很多UI设计中我们用一些占位符来替代文本，然后在资源文件中给出对应不同区域语言的实际文本一样。代码库的API应该只是纯粹的符号，可以被符合规范的编译器处理，生成我们想要的程序。而至于API的语义应当由独立于程序之外的注释和文档来描述。虽然自注释的变量方法名可以提高对人类的可读性，但那并不是代码本身该做的事，代码该做的事是对编译器描述一段正确的程序。

不敢苟同. 听起来你认为API以及内部方法/变量的命名无关紧要. 有不少readablity相关的文章, 比如Writing for Readability

比起将代码库的API直接翻译成中文，是不是翻译API参考文档更好呢？关于API汉化问题, 有不同的实现方法.

翻译参考文档从维护的工作量来说, 只会比通过扩展来汉化API更加大. 因为如果API本身被修改了, 文档的改动量肯定比API名称的改动量大. 当然, 同意翻译文档的价值.

基于英语语法的语句难以翻译成妥当的中文

你应该不是说, 英文自然语言很难翻译成妥当的中文吧? 如果特指英文编程语言的语法, 它们还远没有到自然语言的程度.

SQL确实是最接近英文语法的语言之一, 不过即使汉化过的语句 选择 人 从 人物表 满足 人.年龄 > 20, 我也觉得挺好理解的. 当然这是个比较主观的问题, 尤其在没有任何统计数据支持的情况下.

大部分基于英文的编程语言和一些库的API设计都是尽可能接近自然英语的语法的，而这样就会导致直接汉化关键词和标识符出来的结果非常莫名奇妙。

个人感觉, 比如顶楼的例程, 不觉得使用了汉化API的代码有什么问题.

因此比起汉化现存编程语言和其库，是不是基于中文语法设计全新的编程语言和库更好呢？

就像之前所说, 方向很多, 而它们的出成果速度/工作量/实现方法/难度/面向受众都很不同, 恐怕很难绝对地说哪种方向更好. 很欢迎选择一个你感兴趣的方向(issue)参与, 或者开新issue/创建代码库. 另外, 这里有个设计中文语法的DSL的尝试.

[ice1000]

https://github.com/icela/FriceEngine-DSL

我曾经其实不看好中文编程

[nobodxbodon]

@azige 漏说了一块:

不利于非中文编程者贡献

这是个很值得探讨的问题. 我看到的现状是, 中文开发者自己开发的开源库/框架, 绝大多数的贡献者也都是中文开发者. 原因肯定是多方面的. 能够想到的有:

• 多数库有类似功能的国外开源项目. 作为外国程序员首选参与的肯定是那些
• 如果是和中文本身相关的库, 比如结巴分词之类的, 主要的用户也是中文开发者, 自然维护的也是

个人也不赞成100%的中文化. 需要和国外交流的项目肯定有. 但就像overview主页说的, 为了1%(假定的数字)的硬性需要而在99%的其他项目中强制使用英文编程, 恐怕是得不偿失.

@ice1000 欣赏了魔改版, 虽然魔音缭绕, 但是颇为亲切 lol

[azige]

@nobodxbodon

对于现有的英文API, 并不一定要通过修改它的源码改成一个纯中文版本, 更可行的可能是对它作扩展, 比如汉化JUnit的assert系列方法.

这点本人倒是支持，中文化的扩展还是有帮助的。但是本人是坚定的反对“把所有的一切都变成中文”

不敢苟同. 听起来你认为API以及内部方法/变量的命名无关紧要. 有不少readablity相关的文章, 比如Writing for Readability

可能本人表达不准确。本人认为代码的可读性是很重要的，但通过注释和文档来描述API的使用方法和规则更重要。毕竟读为人类而写的文档比读为机器而写的代码肯定是更容易的，并且API的命名本身并不能包含其使用方法和规则。

关于那个SQL的例子，如果设计 从 人物表 选择 符合 人.年龄 > 20 的 人 这样的语言是不是比直接翻译的那样的蹩脚要好呢？虽然设计这样的语言可能比直接翻译SQL的工作量会多，但这样的语言才有中文的价值。

给个本人在工作中实际使用中文编程的例子表明一下立场 😃
以下是本人的工作项目中的一个Groovy脚本的片段，本人为这种脚本写了一个简单的框架，脚本是不懂编程的游戏设计写的

def 基础策略() {
    if (存在单位(是自己 & mp比例范围(0,0.05))){ 
        选择单位(敌方 & 活着的){
            攻击 选择结果集.随机目标
        }
    }
    选择单位(敌方 & 活着的){
        if (选择结果集数量 > 2){
            使用技能 "XXX", 选择结果集.hp数值最低
        } 
    }
    选择单位(敌方 & hp比例范围(0, 0.1)){
        if (选择结果集数量 > 0) {
            使用技能 "XXX", 选择结果集.hp数值最低
        }
    }
    选择单位(敌方 & 活着的){
        if (选择结果集数量 > 1){
            使用技能 "XXX", 选择结果集.hp数值最低
        } else {
            使用技能 "XXX", 选择结果集.hp数值最低
        }
    }
}

[ice1000]

@nobodxbodon 当时也就随便写的，你们可以把它作为一个Demo hhh

[ice1000]

你们都不睡觉的吗

[azige]

@nobodxbodon

中文开发者自己开发的开源库/框架, 绝大多数的贡献者也都是中文开发者

但就像overview主页说的, 为了1%(假定的数字)的硬性需要而在99%的其他项目中强制使用英文编程, 恐怕是得不偿失.

能预测到某个项目只会有中文编程者使用倒还好，那些预测不了的，即使是单人项目，都不知道哪一天会不会突然有国际友人参与进来（真实的例子，本人的 moebooru-viewer 原本是为了解决个人需要和某站被墙的问题弄的，结果突然某天有人提交了一个加入多语言支持的 PR 😭 ）

本人的观点基本上是“入乡随俗”，在Java中就使用英语，在易语言中就使用中文。因为学过Java的程序员应该有90%都是会英语的，而学过易语言的程序员应该有100%都是会中文的。

[nobodxbodon]

@ice1000 我这里现在时间是周日中午12:20 :) 现在吃不消熬夜啦 最多到1点

@azige

毕竟读为人类而写的文档比读为机器而写的代码肯定是更容易的，并且API的命名本身并不能包含其使用方法和规则。

API的读者就是开发者吧?

虽然设计这样的语言可能比直接翻译SQL的工作量会多，但这样的语言才有中文的价值。

个人对汉化编程语言的关键词兴趣其实不大(早先汉化过coffeescript的关键词). 现在觉得代码里主要的语义是自定义的类/方法/变量, 所以可以直接开始中文编程的实践, 不用先汉化语言关键词. 之前是就你的例子的个人观感而已. 我也同意如果要汉化某个编程语言的关键词, 还不如探索接近中文使用习惯和语法的新语言. 不过汉化API和汉化语言的关键词又有点不同.

大赞一下你的Groovy框架和例程. 不知框架能不能开源? 一起学习一下.

（真实的例子，本人的 moebooru-viewer 原本是为了解决个人需要和某站被墙的问题弄的，结果突然某天有人提交了一个加入多语言支持的 PR 😭 ）

多谢分享! 当然希望看到更多的国外开发者参与项目. 不过我的出发点有些不同. 除去预测得到是否会有国外开发者参与的情况, 剩下的自己发起的项目, 我首要考虑的是对自己的开发和维护最有利的编程方式. 因为在可以预见的将来, 我自己会是最主要的贡献者. 如果我自己的开发和维护成本随着项目变大而变得不可持续, 那么在项目成型和能够吸引其他开发者参与之前可能就夭折了. 我自己的感觉是用中文命名是我更熟悉和容易的方式.

本人的观点基本上是“入乡随俗”，在Java中就使用英语，在易语言中就使用中文。因为学过Java的程序员应该有90%都是会英语的，而学过易语言的程序员应该有100%都是会中文的。

我发现的另一个问题是, osc上一些即使很热火的开源框架, 比如JFinal, 大多只有极少的其他开发者贡献. 个人认为一个很重要的原因, 就是代码很难阅读, 而英文命名是一个主要的障碍. 也许对于开发者本人来说, 随着项目的开展, 一些开始时有些别扭的英文命名自己也习惯了, 但是对于刚拿到整个代码的新开发者(中文用户), 任何不妥当的英文命名都会导致迷惑和时间的浪费, 想要短时间了解脉络几乎是不可能的任务. 为了吸引理论上的几千万国外开发者, 而不优先选择对几百万的中文开发者(包括自己)阅读代码有利的编程方式, 个人认为这种思路是很值得商榷和分情况探讨的, 而不是简单的"入乡随俗".

话说回来, 在下还真没有一个有影响力的开源项目, 所以现在很大程度是纸上谈兵 :) 现在开展的一些实验项目就是为在英文编程语言里用中文命名吃螃蟹.

另外, 多数英文编程语言支持unicode命名, 起初的动因虽然不清楚, 但说明多数语言开发社区是认可这种需求的. 个人不认为, "只应该"在中文编程语言中用中文命名, 而"不应该"在英文编程语言中使用.

[buyouyuan]

大家好！
看了这几期的讨论，现在主要是两个问题，1、全部中文化 2、部分中文化。
我们可以分两步走，开两个主题。我们可以为自己喜欢的主题自由的去贡献。
现在我们全凭自己的兴趣和爱好，但我们的最终目的是一样的。我想我们的目的是这样的。
“可以在中文环境中，自由的自在的操控电脑！”

[nobodxbodon]

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

[azige]

@nobodxbodon

API的读者就是开发者吧?

嗯～实在不知道怎么表达了，简单的说把 list.add 翻译成 表.添加 对中文编程者提供的帮助并不如把 http://docs.oracle.com/javase/8/docs/api/java/util/List.html#add-E- 这段翻译成中文所提供的帮助大。

关于代码可读性的话本人无法提供合适的论述，在本人看来只要命名良好，英文和中文是等价的（但是中文的参考文档对中文编程者来说更可读）。

osc上一些即使很热火的开源框架, 比如JFinal, 大多只有极少的其他开发者贡献. 个人认为一个很重要的原因, 就是代码很难阅读, 而英文命名是一个主要的障碍

虽然不太妥当，但是既然在osc上发表的话就是适合”入乡随俗“使用中文的场景呀（笑）

我首要考虑的是对自己的开发和维护最有利的编程方式. 因为在可以预见的将来, 我自己会是最主要的贡献者. 如果我自己的开发和维护成本随着项目变大而变得不可持续, 那么在项目成型和能够吸引其他开发者参与之前可能就夭折了. 我自己的感觉是用中文命名是我更熟悉和容易的方式.

这点可能就是非常的视个人习惯而定了。本人觉得使用了自己会的英文单词，然后附上必要的中文注释，就足够维护自己开发的项目了，至少我自己是这样。虽然也可能因为英文能力不足出现蹩脚的命名，但那些对英语母语的人来说应该还是能理解的，而对中文编程者来说还有中文注释能参考。

要在自己的项目里使用什么语言就自己决定好了，让其他人”入乡随俗“吧。但是一个考虑到要国际化的项目最好还是用国际化的语言的。

[nobodxbodon]

@azige 嗯, 对于中文代码的可读性提高(对于中文母语的开发者), 是个暂时没有考据的论题. 也正是我现在进行实践想要探索的.

虽然不太妥当，但是既然在osc上发表的话就是适合”入乡随俗“使用中文的场景呀（笑）

如果这么说, 好像也对 :) 说起来在osc上还没有好好挖掘过中文代码的项目, 嗯, 有空试试

本人觉得使用了自己会的英文单词，然后附上必要的中文注释，就足够维护自己开发的项目了

关于注释和命名, 在我之前的工作环境里, 是我第一次接触正式的可读性审核. 可惜自己没有正式成为可读性审核员, 不过也吃过猪肉(每个commit都被审核过). 有个印象是, 审核员会尽量倾向于减少注释量, 而强调代码本身的可读性(其中最重要的因素之一就是命名). 审核里会不时出现"这个方法名已经self-explaining了,注释就不用了"之类的评语. 虽然没有当面确认过, 但写注释和维护注释的额外工作量应该也是这种倾向的动因之一. 算是我对于命名对于可读性的意义的实践体会吧.

对于从开头就希望融入外语开发者社区的项目, 如果能够吸引外语开发者的参与, 并且成型和壮大, 绝对是喜而乐见的. 说起来有点"围城", 个人还是会更侧重于为那些主要面向中文开发者的项目(包括自己的项目)尝试更加"自然"和熟悉的编程方式, 也是一种精神寄托吧.

[azige]

突然想提一下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]

没有提供中文API

据我所知没有任何一个语言/标准库/第三方库有中文命名的API的. #6 就是希望搜集这类项目.

Java中有个无论如何都回避不掉的问题就是JavaBeans规范一定要你使用set/get命名。除去Java本身之外，Java生态圈里很多命名约定也都是基于英文的（例如maven版本号的 -SNAPSHOT 特殊语义，旧junit中需要测试的方法必须以test开头等），如果在命名中使用中文，又要遵循这些约定的话，就会变成奇怪的中英文混合命名

确实在实践中碰到混用的情况, 我基本上是能用多少中文就用多少. 如果想在Java里用中文编写代码, 中英混用是不可能避免的. 关于开发中文API, 还是具体情况具体分析吧. 刚顺便汉化了JUnit的assert系列方法, 自己先在项目里试用着.

[azige]

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

[nobodxbodon]

@azige BTW 这里是刚开始的一个很小的中文DSL(勉强算吧)实验.

[nobodxbodon]

@hummerstudio

我认为这个工作是非常必要，并且在目前的技术条件下也是较可行的方案。在此之前我就有这个想法。

握爪.

不过翻译的过程我有不同看法，我认为不需要去翻译内部的算法实现过程，只需要去翻译类别和方法名就可以了。

刚开始的项目汉化JUnit4就是这个方式.

需要先将核心库分类，率先改最基础的类，再去改使用到基础类的类，逐步地，代码中文化的程度就会逐步提高。这需要有熟悉相关语言的人出面做这个工作。

你指的是汉化JDK类吗? 我之前踢到过铁板. 一次 两次(13楼是铁板)尝试.

[hummerstudio]

@nobodxbodon

你指的是汉化JDK类吗? 我之前踢到过铁板. 一次 两次(13楼是铁板)尝试.

是的（Java对UTF-8支持是非常好的，包名、类名、函数名都可以是中文，一点问题都没有）。铁板是只解决不了的问题吗？首先，我觉得这个方向是没有问题的。方法可以改变一下，不要上来就一个类一个类的翻译，先把整体工作内容和量整理出来，规划好再做。就像写程序的时候先把算法想清楚，再下手码代码一个道理。像帖子中你提到的同样的单词要有统一命名，这个问题在脑子里谋划时就可以先预见到。

具体讲：

1. 先确定翻译范围，列出来。包括（类所属）包名、类名、（类的）方法名。方法名有API可以很方便的打印出来，具体我不记得了，IDE显示方法名就是用的这个API。
2. 在步骤1的基础上，看看哪些是常见的词（专业术语，有特殊指定的词等），讨论制定一个标准的英文->中文的对照表。
3. 在步骤2的基础上，参考步骤1的输出，就可以让社区的人员来自愿领取翻译任务了，这时候已经没有什么技术性可研了，写好教程即可。
4. 另外要做好版本控制，做到一个官方JDK版本对应一个汉化版本。

大体上是这样一个步骤，步骤3的实施过程可以根据步骤2的结果看看复杂性如何，是否可以引入一些方便的工具来进一步降低难度和效率（比如开发一个源码自动修改、打包的工具，只需要翻译人员提供一个特定格式的文本文件，工具读取文件，自动修改英文原版源码，并作打包）。

[nobodxbodon]

@hummerstudio

是的（Java对UTF-8支持是非常好的，包名、类名、函数名都可以是中文，一点问题都没有）

嗯. 已经实践过一些

铁板是只解决不了的问题吗？首先，我觉得这个方向是没有问题的。方法可以改变一下，不要上来就一个类一个类的翻译

没记错的话我尝试了不止一种汉化方式(帖子里应该有, 回头小结一下). 那个铁板好像在新建Iterable对应汉化接口的时候碰到的. 能开始就有完善规划是最好, 不过我那些尝试都只是在趟雷而已. 感觉还没找到一条可行而且工作量可控的路. 请问你设想的技术路线是?

[hummerstudio]

@nobodxbodon 有雷我们解决不了，不代表别人解决不了，我们把任务列出来，标记上进度和阻塞原因，可以继续做其他的。除非原理我们很清楚，并且确定完全规避不了。

[hummerstudio]

汉化我最近思考了下，是不是采用新建库的方式更好？我们只需要起一个新的中文包/类/方法名，然后调用原始类库即可，相当于包装了一层。

这样既不会破坏原有代码的兼容性，又能快速把新库应用到实际开发中，毕竟整个工程量是很大的，不能等全部翻译完了再去使用。

使用封装的形式也简单很多。对照API文档就可以翻译了。相当于前期的整理工作都不用做了。

@program-in-chinese/all

[nobodxbodon]

@hummerstudio JUnit4就是新建了库. 之前的JDK汉化也是, 其中两种不同汉化方法(封装/翻译源码)碰到的技术问题也在那里详述了. 请多指教.

[nobodxbodon]

看到这个知乎回复:

而对于非专业人员来说，觉得中文编程或者写代码对于易读性的提升还是有很大帮助的，尤其一些广泛普及的开源代码，比如php编写的discuz，如果其中的变量名都使用中文，对于二次开发应该有很大的便利。如果一些针对非专业编程人员的场景，比如实际的业务逻辑处理部分，即使只是采用中文变量名，对于提高业务代码的可读性也不是一般的提高。对于学习编程的人员来说，采用中文变量和代码，也可以让大家认识到，这些代码对于计算机来说，实际都是一样的，提高易读易学性的同时，可以更深入的理解计算机运行的本质。

作者：苗工
链接：https://www.zhihu.com/question/19769482/answer/250694442
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

尤其其中对于discuz之类框架的汉化, 感觉可以归到这个主题里.

[nobodxbodon]

对外网站刚发文: 用中文命名API的意义和途径. 欢迎批评, PR, issue.

[nobodxbodon]

@htwx program-in-chinese/Java#1 (comment) 内容更适合这里讨论:

汉化编译器都不难 包括 C# JAVA 如果没有有效的汉化库的方法,只是汉化编译器作用不大, 大家要多想想 怎么汉化 库
怎么说呢, 英文 api 中文化 也要从 编译器或运行器来实现, 在外部实现 就要重写api 了
我的那个 CTS也是如果就只是汉化关键字 真的只有10分钟就完了, 难就难在 要支持汉化的API 了,
这个我 看过好几个编译器的源码了, 想实现 api 中文 必须从 编译器 或运行时 来实现.

你说的API应该是核心库部分吧? 关于CTS, 个人觉得汉化关键词可以先出一个版本.

[nobodxbodon]

@MikaGuraN 的Android开发库: #51 (comment)

[nobodxbodon]

@yozman 在#40 (comment) 中提出:

布道第一步应该是用中文翻译一些流行的类库的接口

应该集中力量，
先搞一门语言，
目前看来 php 是最优的选择

这与上面有共鸣. 个人也很赞同(program-in-chinese/quan1#1 (comment) 讨论中也大致确定将PHP作为优先的中文命名实践方向).
请问对从哪个/些php类库入手有何建议? 之前考虑过通用框架(比如Lavarel/CakePHP), 还有专用框架比如Disquz, 个人倾向于后者, 因为业务语义更丰富, 更易于体现母语优势.

[yfz0574]

倾向于代码直接是中文, 而不是显示成中文而实际还是英文.

我也是，只显示成中文的话，调试的时候还是遇到英文，反而摸不着头脑了。并且调试找BUG在编程中是占了很大比例的，不得不重视这个问题。

[zaoqi-unsafe]

我让代码是中文，将可以显示成English,调试bug也将可以显示English

[nobodxbodon]

我让代码是中文，将可以显示成English,调试bug也将可以显示English

不知实现方式是否和#25 (comment) 类似(在注释中自定义词典条目)? 那里有一些相关讨论.

[nobodxbodon]

有提议将Python的requests中文化. 考虑将其与#165 结合, 在核心库之外包括一些常用库.

[nobodxbodon]

几个优先考虑的因素：

• 领域相关的库，而不是过于通用的库。通用库意味着很多计算机专用术语需要自行翻译，而专业库更多时候已经有完备的相关中文术语可以沿用于API命名。
• 易于测试。虽然很可能是直接封装原有库，但为了使用户信任，仍需完备的测试集。
• 最好是国内开发组实现的库
  • 由于对文档进行汉化几乎是必须的，相较汉化英文库+英文文档，汉化国人创建的库至少只要汉化库就可以，因为大多数都已经有中文文档了
  • 汉化库时，可以参考中文文档中的术语。既省汉化的力，又能和官方的中文用语一致。像大疆机甲大师机器人的Python API中，”装甲“，”底盘“，”云台“等等中文术语都在官方文档中。
  • 非技术层面的理由，国人创建的库更多的是针对国内市场的。这一特性决定了，在比例上来说，这些库的使用者（或者潜在使用者）对中文命名的需求较大。简言之，通用库的国内用户数量不一定比国内某些库的大。即使更大，汉化的工作量也更大，而目标群体不一定那么领情。
• 有相对固定用户群，社区够大就行，最好有较活跃的交流渠道，以便推广和搜集反馈。
• 有发行平台，不需自行维护单独网站等。
• 考虑到国内去 windows 的趋势，应避免选择和 windows 平台绑定的库

除了传统的库 （library），也包括在线 API，比如之前听说过百度的某些API 的 JSON 键名为中文。类似汉化本地库，也可以对在线 API 进行封装。
【待续】

[nobodxbodon]

@mandolin 请问基于 vue 的 中文前端框架 打算支持 vue3 吗？

[mandolin]

@mandolin 请问基于 vue 的 中文前端框架 打算支持 vue3 吗？

肯定会的，过一段时间就会重新开始这件事，去年因为各种因素中止了一年。