overview
overview copied to clipboard
program-in-chinese
索引: 对现有编程语言的英文关键词进行汉化或者再创造的实例
曾几何时, 编译器还多不能支持中文标识符, 前人努力过改变. 现在多数语言本身已经支持unicode的标识符, 可以认为用中文编程的第一个障碍基本消除了. 随着语言和编译器的开源, 出现了各种对英文关键词的编程语言进行汉化的实践. 下面试着罗列一下:
TypeScript (原作者 @htwx. 演示) PowerShell TinyCC (@swizl 的开发过程) clang Lua，@xgongya的版本 Julia CoffeeScript Python (原作者 @swizl) 原Python讨论区issue: 1 2
也有参照原语言的语法, 自己开发的语言:
Z语言 (类LOGO) 类似Forth的栈语言-亲密数编程语言 【原链已失效，此为存档链接】
请各位补充.
@hummerstudio 有同感. 之前主要的考虑是尽量把讨论集中在一处. 规整到wiki之后, 同步也是个工作量. 请问有兴趣加入讨论组, 方便各种操作(创建wiki等)吗?
CTS这个项目一直是我一个人在搞，前后耗时快7个多月了，现在0.0.1版本基本完成了。现在这个项目基本下载编译后就能使用，但现在没有写自述文件，本人原来曾经汉化过C#后来发现没有意义因为C#我只能汉化成中文关键字，.net是没有办法的，这个是因为需要CLR（运行时）的支持，就放弃了。
这个TS是微软开源的类型化JS。可能本人多接触的是后端语言强类型的接触比较多，js用的不多，在后端人员看来这个js真的是问题太多了，微软的这个TS基本解决了js存在的一些问题，根据官方的说法TS是JS的超集，就是说JS的写法TS是完全能覆盖的。TS因为是编译时强类型的所以在程序开发阶段就能排除大多数的问题。微软说TS是为了使JS能具备开发大型程序而改进的，事实确实做到了，微软开源的vscode 也是TS开发的，从实际的运行来看，真的很不错。TS是自写自身的编程语言，近10万行的代码在VsCode上编译运行调试没什么压力。
我这次改造是基于TS2.5版本开发的TS原有的功能没有一点改变，是在官方的基础上做的加法，这个完全可以当做TS的编译器来使用。TS、JS的英文版代码块（或源文件）。直接拷贝进来就可以用。时间上来讲这个版本我本来没打算公开出去，本来想在TS2.5.5的时候在跟进一版在公开，那时候估计基本的文档也能完善了，我的这个CTS重新增量开发了TS的语言服务(tss)，IDE这块是在TSVsCode的插件基础上做的增量开发，从语法高亮到智能提示所有的TS原版具备的功能这个CTS都具备，基本能达到TS原版在VsCode开发时的开发体验（我自己反而不行，因为长期使用英文关键字开发反而使用中文做教程的时候卡壳，这是因为10几年基本形成习惯性动作了，一时半会还真不好改）。
现在TS、JS的生态越来越强大成了一个真正的跨平台语言，在桌面有electron、nw等，移动端有ReactNative、微信、支付宝的小程序等、服务器本身node就是干这个的，社区有npm。因为TS为了类型化JS创造性的增加了个类型声明文件（.d.ts文件，作用类似于c语言的.h文件）。有了这个类型声明文件使得不用改变electric、nw、rn本身源码只是修改.d.ts文件就可以实现汉化成为可能。也就是我的这个CTS不但是一个汉化的强类型的JS超集同时也能汉化 electric、nw、rn、还有成千上万的js模块文件，汉化的方法也很简单只是在.d.ts文件上标注词典就可以了，我本人也写了工具。在翻译工具的帮助下几乎任何人都可以汉化LIB。解决了虽然能汉化C#但是不能汉化.net的尴尬。
这个图片是es5以下版本的js默认类型支持库(LIB)在原版声明的基础上增加词典标注这个就是完全支持中文编程的支持库了，我设计了工具。标注起来不麻烦。像这种近2w行的类型声明文件没几个，90%的类型声明文件在500~5000行之间，包括electric、nw、react、reactnative、SQL、redis（键值数据库等等）
虽然注释是英文的但是鼠标悬停提示会有机器翻译的汉语注释
虽然注释是英文的但是鼠标悬停提示会有机器翻译的汉语注释.
格式化的文本也能翻译(虽然不是很准确,毕竟是机器翻译的)
@htwx 非常感谢详细介绍! 刚试着看了一下修改的部分, 注意到用了中文代码并且翻译了原有的注释, 再赞一下. 看到了一些alias相关的部分, 估计我是管中窥豹了:). 另外, 比如这个commit, 代码修改量有+/-30k, 恐怕看起来会吃力. 不知这个汉化方法能否比较方便地集成TS源码原本master分支的新提交? 应该半年来有不少吧?
有些还是不行的虽然没改变ts的原有功能但是对他的大量内部函数数据类型都做了修改。现在合并肯定不行。但是我开发的时候就考虑到了以后版本跟进的问题。如果官方更新我可能2天内就能跟进，在他们不是结构化大量的的更改源码的情况下，本来要在他发布2.5.5 的时候跟进一次，原来设想 官方更新5次我更新1次，除非他们是有革命性的更新。估计这是不可能的在5个小版本间就大范围更新。因为ts已经很完善了
@htwx 才发现你在原楼添了很多内容 :) 再次感谢分享!
CTS这个项目一直是我一个人在搞，前后耗时快7个多月了
钦佩毅力! 不知日常工作中是用TS开发吗?
本人原来曾经汉化过C#后来发现没有意义因为C#我只能汉化成中文关键字
请问能分享一下汉化方法/思路吗? 是扩展Roslyn实现?
我这次改造是基于TS2.5版本开发的TS原有的功能没有一点改变，是在官方的基础上做的加法，这个完全可以当做TS的编译器来使用。
赞! 请问自编译过吗?
我的这个CTS重新增量开发了TS的语言服务(tss)
看到源码里添加了百度/有道翻译的内容, 不知指的是这里吗?
IDE这块是在TSVsCode的插件基础上做的增量开发，从语法高亮到智能提示所有的TS原版具备的功能这个CTS都具备，基本能达到TS原版在VsCode开发时的开发体验
请问是在TS之外, 对vscode进行了改进吗?
因为长期使用英文关键字开发反而使用中文做教程的时候卡壳
请问是打算编写一些教程对这个编程环境进行推广吗?
汉化的方法也很简单只是在.d.ts文件上标注词典就可以了，我本人也写了工具。在翻译工具的帮助下几乎任何人都可以汉化LIB。
这里能否麻烦细说一下? 看后面的词典标注的示例图还是有些蒙圈...不好意思TS小白
一个细节, 看到你的演示里输入"超文本"之后弹出自动补全列表, 就想到之前@lightrabbit和@cleverdango做的vscode里根据拼音输入弹出自动补全, 应该会让输入顺畅一些.
这个考虑过,但实际还在矛盾中。我是一直坚持中文标识符命名的，实际上搜狗输入法有时比智能提示还好用。只要你连续的输入几次相关的词组，这个是临时写的演示，输入法没有输入记录。如果自己做拼音补全不一定比搜狗好用（主要是实力不行啊）。
@htwx
我是一直坚持中文标识符命名的
大赞! 请问工作中也是吗? 那整个团队也是? 不知有没有碰到过什么中文相关的技术坑啊? 最近在JUnit4汉化过程里碰到一个UTF8<->GBK出现乱码的问题, 因为对字符编码不熟, 还是颇费了点时间.
如果自己做拼音补全不一定比搜狗好用（主要是实力不行啊）
好像上面链接的演示就实现了这个吧? 比如, 输入"chwb"应该就会弹出"超文本"相关的代码提示. @lightrabbit @cleverdango 没理解错吧?
另外, 机器翻译还真是个翻译文档的捷径, 不过质量恐怕有些难以保证啊. 特别对新手来说, 翻译的误导可能会导致不必要的困惑.
钦佩毅力! 不知日常工作中是用TS开发吗？ 我是建筑设计专业的平时不做开发，我有自己的事业，我年龄比较大了，自己觉得还不错，我是以我自己学习这个的经历来考虑，中文编程能推广起来真的是对国对民都好的事情，现在难点不再这个到底可不可行上，而是没有大的公司采用中文编程，如果 阿里腾讯百度小米等等有1到2家是用中文编程的或是推动中文编程的，你不让他们学他们都不干。就那个帖子而言那些疯狂反对的，反而是对中文编程最熟悉的，弄不好他们就是那些整天到处问些低级问题的那些人，只是靠时间费了九牛二虎之力才一点点学会的人。我说他们中90%的人曾用过中文编程。 请问能分享一下汉化方法/思路吗? 是扩展Roslyn实现? 我在研究C#的时候C#才4.0那是Roslyn还没开源，我是从mono入的手，后来罗斯林开源了我也看了，要汉化C#现在肯定是要从罗斯林开始开发，但是C#的接口文件是通过反射取得的（就是从元数据）如果你要汉化.net就要改 MSIL和CLR了（前提是要保持和英文C#的兼容性），如果不考虑兼容问题到时不用直接从.netcode的源码改就行了。
我的这个版本还没有打算推广, 我想实现的是 中文一条龙 中文HTML, 中文CSS, 中文TS, 中文Node, 中文React 这几天已经在搞 中文H5了
我的这个CTS汉化了LIB\关键字\标识符\编译选项\命令行命令\现在唯一剩下的是\编译错误,这个不是实现不了是量太大.
900多行,而且要求翻译必须相当准确.
@htwx
我是建筑设计专业的平时不做开发，我有自己的事业，我年龄比较大了，自己觉得还不错，我是以我自己学习这个的经历来考虑
很佩服! 很少看到非专业的隔行学成的.
...我说他们中90%的人曾用过中文编程。
呵呵, 那个issue就不再继续讨论了吧. 这里还比较清静, 讨论也比较理性, 且珍惜 :)
TS是自写自身的，你的编译器源码首先要编译的就是你的源码？就是说我写的这个最少编译过10w+的代码。
哦, 能够自编译的话确实已经比较完善了.
VsConde 如果你不需要创建新的UI不用改源码在插件的环境下基本都能实现
请问是开发了一个新插件吗?
我的这个版本还没有打算推广, 我想实现的是 中文一条龙 中文HTML, 中文CSS, 中文TS, 中文Node, 中文React
很期待. 这样影响确实会比较大, 而且H5和CSS的汉化之后可以和其他语言/框架集成. 不过工作量恐怕不小. 不知你设想用什么方式推广比较合适? 也许做一些入门教程, 比如从无到有做一个网络服务和简单的界面?
英文文档和编译信息的翻译恐怕要发挥社区的力量啊...尤其是前者
@htwx
900多行
英文接口文档应该浩瀚的多吧?
而且要求翻译必须相当准确.
非常同意. 也许还可以添加一些信息, 如果原本的信息不够明确的话.
英文接口不多(文档还是很多的),就是我提到的几个主流框架,剩下的基本都是500行以下的小型接口文档,我的工具如果是英语好的人翻译1天2万行,如果英语不好1天也能5000+有谷歌翻译在基本能谁用谁翻译就行了,翻译完的可以发布到 npm 社区,有版本控制就没什么大问题了. 就翻译来讲还有比较麻烦的事情,因为英语有大小写,缩写,简写,单数复数等等区别,还有有些英语单词在英语中的本意也不是程序中药表达的意思,所以还是很难翻译的 因为翻译类型声明文件要求英文是不同的中文也不能相同所以比较麻烦. 例如: ERROR Error ERR err 甚至还有 e 汉语的意思对应的都是 "错误"
单复数也麻烦 毕竟汉语大多数是省略复数表达的 例如这个 lines 你翻译成 行组,行集,多行... 都不咋地.
就是这个 this 翻译起来都很费劲
这个也是我的这版没有发布的原因之一,关键字的翻译现在的结果我是不满意,但还没找到更好更贴切的, es6\es6\es7\node 等这几个基本的类型声明文件里有好多我感觉翻译的不满意的,还有些专业词汇没有拿准是否应该翻译 例如 HTML SVG 等等.
我不想搞的太民粹我的设想还是应该和主流语言之间能无缝的转换对接. 我的这个CTS是可以随时编译为英文TS的能力的, 所以中文全角标点符号我就没考虑. CTS是每个标识符都允许存在2个名称是相等的. 可以互相转换. 这就实现了你在家里用中文编程 到单位去一样可以提交成英文代码.
在CTS里 //@@ 是词典标识符 在 TS 里这个就是普通的注释. 不影响任何问题. 调试环境是经过 .map 文件映射到源码里的. 所以虽然 运行时还是运行的英文但程序报错等确是中文的于源码能对应上.
因为编程的原因长时间 中文输入英文标点,这里就不切换了将就看吧.
就翻译来讲还有比较麻烦的事情,因为英语有大小写,缩写,简写,单数复数等等区别,还有有些英语单词在英语中的本意也不是程序中药表达的意思,所以还是很难翻译的.
嗯, 代码注释/接口文档的翻译还是最好有开发经验的来做.
因为翻译类型声明文件要求英文是不同的中文也不能相同所以比较麻烦 例如 ERROR Error ERR err 甚至还有 e .
这个感觉原本设计就有点问题啊...能举个例子吗? 其实如果含义不同的话感觉就应该从命名上进行区分, 而不是靠大小写/缩写.
单复数也麻烦 毕竟汉语大多数是省略复数表达的 例如这个 lines 你翻译成 行组,行集,多行.都不咋地.
其实这个在中文命名有类似的问题. 之前也碰到过类似的. 现在我在源码里比较多用的是直接省略复数表达, 然后在必须强调单数的时候再加修饰每,某之类. 这样感觉和中文自然语言最接近.
因为编程的原因长时间 中文输入英文标点,这里就不切换了将就看吧.
呵呵, 我也是用搜狗的"中文下使用英文标点". 很习惯了.
因为翻译类型声明文件要求英文是不同的中文也不能相同所以比较麻烦 例如 ERROR Error ERR err 甚至还有 e .
这个没什么好办法因为你是翻译现有的库,人家已经这样了, 没法改了.我现在采取的也是加 前后缀的做法
例如 ERROR 就是_错误_ , Error 错误类, Err 错误_ err 错误__ 对于e 这种有2个办法就是 对e 不翻译或者 有个局部词典 //@{ 错误___:e } 来把作用域里的 e 翻译成 错误___
我的文件里有几种词典 : //@@{ ... } 这种是 全局词典, //@{ ... } 局部词典 //@{ ... }@ //@@{ ... }@ 临时词典
就是这个 this 翻译起来都很费劲
个人感觉本身,吾,自己,我都可以考虑, 虽然后几个显得拟人化了. 话说, 你觉得把代码库转到github如何? 在你账号下或是组里都行. 这样方便我们在那个代码库开issue讨论这些比较具体的问题.
还有些专业词汇没有拿准是否应该翻译 例如 HTML SVG 等等.
嗯, 这些直译可能有点长啊. HTML-超文本标记语言, SVG-可缩放矢量图
我的这个CTS是可以随时编译为英文TS的能力的, 所以中文全角标点符号我就没考虑.
嗯, 支持全角符号还是让有兴趣的通过IDE扩展实现吧.
这就实现了你在家里用中文编程 到单位去一样可以提交成英文代码.
这个...如果自己用中文命名自定义的变量/方法了的话, 靠机器翻译不可靠吧?
在CTS里 //@@ 是词典标识符 在 TS 里这个就是普通的注释.
哦, 才反应过来, 这个//@@是你为中英对照设计的.
例如 ERROR 就是 错误 , Error 错误类, Err 错误_ err 错误__ 对于e 这种有2个办法就是 对e 不翻译或者 有个局部词典 //@{ 错误___:e } 来把作用域里的 e 翻译成 错误___
这个_和__有点区别不明显啊. 和之前的this翻译问题类似, 方便的话新开代码库/issue讨论?
这就实现了你在家里用中文编程 到单位去一样可以提交成英文代码. 这个的实现方式也是要标注词典的, 但是你在开始的地方吧这个名词标注好 对应的英文后 例如: getText 你标注成 取文本 ,在以后你只要使用 取文本 编译的时候就 替换成 getText 了编译完后 词典文件就自动抹掉了你提交的时候是纯英文的. 这个有很多使用场景的 , 多数是用在外包的时候你给人家提供中文代码人家拒收的. 中文编程必须要产生效益才能有人愿意用.如果不能产生效益 写的代码谁都不要就麻烦. 目前的大环境就这样,这个是要长期才能改观的事.
这个使用全局词典是为了增加翻译速度的 例如 name 你翻译成 名称 全部的 name就都成 名称了, 但是 这就要求 Name 你就不能翻译成 名称了,因为是全局的,英文不一样的 中文一定要不一样, 但不不要求 中文一样,对应的 英文也要一样, 只要 名称不冲突就行了, 所以这个烦, 因为使用了全局词典 ,还有就刚才的 p 在全局翻译成 属性, 能满足80%的需求, 可能局部中的 p 并不表示 属性的意思 这时可以用 局部词典来修正. 这样翻译的工作量 就小很多 .
中文编程必须要产生效益才能有人愿意用.如果不能产生效益 写的代码谁都不要就麻烦. 目前的大环境就这样,这个是要长期才能改观的事.
同意!
关于用词典在注释中命名, 下面这种情况, 两个不同的中文方法, 英文命名不慎重复了, 编译时如何处理呢?
//@@ getText
取文本(){...}
...
//@@ getText
取字符串(){...}
如果他们不再一个作用域这样是可以的 如果在一个作用域就会报错 . 就ts 而言 我的全局是指一个在一个js模块空间内, 如果这个js 模块是全局的那就在全局范围内不能有重复的