中文化类C编程语言需要什么样的关键字? #40

swizl · 2017-10-18T10:18:28Z

基于clang做中文编译，取得了一点成绩。
做出来是中英双语的，可使用中文关键字、中文符号，对原来的C，C++，Objective-C没有影响，安全兼容。
之前基于tinycc做的时候，有人嫌弃中文关键字选得不好。
目前还没动工，大家看看用些什么字词比较好？
Java, JS, Python, Go 等其他语言也可以一起讨论一下。

----- 追加 -----
关键词汉化待选列表整理在此wiki页

htwx · 2017-10-18T10:29:57Z

我的主张关键字还是应该与长期以来形成的一些习惯保持一致，就中文关键字来说，字符最好控制在2到4个个，不要太长也不要太短，还有就是各种语言虽然关键字不同，但是中文能统一是最好的。

swizl · 2017-10-18T10:58:29Z

其实问这个问题之前，我希望的都能找到一个字对应，最好了。比较适合懒癌患者。
当然做出大家肯定会不喜欢的

可以统计一下，哪些关键字用得多，就尽量短一些。

我的脑洞：
int 整
char 字
float 浮
double 双

switch 切
case 例

if 如
else 另

return 回

break 破
continue 续

new 新
delete 删
namespace 名宇

this 此

try 试
throw 抛

while 、for 和 in 还有好多没想好
要是有人是中文系的就好了。

nobodxbodon · 2017-10-18T17:56:25Z

希望这个讨论不会太分神(因为太见仁见智, 就像推敲诗里的取字一样)妨碍编译器修改的进度 :)
好像你之前也提到过, 先改出来再说, 毕竟修改词汇是方便的事情. 只要还没有大规模推广, 就不用考虑太多向前兼容的问题.

话说回来, 也许需要一些例程, 囊括所有关键词, 写出来看看视觉效果. 比如(来源), 只包含了几个:

#include <iostream>
using 名字 std;
 
整 main () {
   字 成绩 = 'D';

   切(成绩) {
      例 'A' :
         cout << "牛!" << endl; 
         破;
      例 'B' :
      例 'C' :
         cout << "不错" << endl;
         破;
      例 'D' :
         cout << "及格" << endl;
         破;
      例 'F' :
         cout << "从头来过" << endl;
         破;
      默认 :
         cout << "没这种成绩" << endl;
   }
   cout << "你的成绩是" << 成绩 << endl;
 
   回 0;
}

虽然够醒目了, 不过感觉有些不大自然. 当然, 英文关键词对于英文自然语言很多也是很不自然的 :) 不过那些英文关键词是好几十年前成型的, 相比现在可读性要求可能比较低, 咱们的起点可以考虑高一些.

切其他含义用的比较多吧, 猜想你取的是"切换"之意. 个人脑洞一下, 也许, 不用特别拘泥于英文关键词本身的翻译, 而基于它的用途(代码中的作用)来寻找中文对应. 抛砖迎玉一下, 比如switch, 感觉岔蛮形象的.
另外, 个人第一感觉回后面跟的是回到的位置, 因为回家的印象太深了...平常说的函数返回值已经有点约定俗成了, 要不还是用返回?

要是有人是中文系的就好了。

@nlpguyz 不知你有没有认识有中文/翻译专业背景的一起讨论?

nobodxbodon · 2017-10-18T18:11:07Z

@htwx

还有就是各种语言虽然关键字不同，但是中文能统一是最好的。

要不把CTS的关键词中英对照贴一下? 或者分享一下相关的代码链接?

buyouyuan · 2017-10-19T00:57:21Z

我赞成先作。作好了，可以随时改嘛。
现在主要是先搞出中文环境才是第一

hummerstudio · 2017-10-19T01:55:03Z

int 整数型
char 字符型
float 浮点型
double 双浮点型

switch 开关/切换
case 情况

if 如果
else 否则

return 返回

break 断开
continue 继续

new 新建
delete 删除
namespace 命名空间

this 本体

try 尝试
throw 抛出

还可再商酌

我认为没有必要在使用中文的时候还是一个单字，使用中文的好处就在于能达到一种类似”所见即所得“的效果，能够让代码有自解释的作用。使用汇编、C、高级语言，都是为了对程序员友好，增强可读性和可维护性的，减少代码量是实现这两个目的的副产品，因此不要节省，像 @htwx 说的，2-4个字符都可以接受，中文也有这个能力。

中文编程的另一个重要目的就是不需要人有英文的思维和相关知识，只需要关心计算机技术、算法、业务逻辑等待。对于我们这些已经会了的人，在做中文关键字和语言的时候，就要去除脑子里的这些思维定式，像有些关键字不好翻译的时候，正说明我们没有真正的理解，而是在机械的模仿，记住了判断情况很多就用switch，循环就用for等等，至于它是什么意思，并没有转化为母语来理解记忆。

我建议先按语言把关键字列出来，容易翻译的先确定好，不好翻译的我们分任务自愿领取，专门去查询一下使用这个词的原因，一起讨论，确定适合中文用户理解的翻译。

hummerstudio · 2017-10-19T02:21:01Z

@swizl

while 、for 和 in 还有好多没想好

while 就是当
for item in items 就是对于 item 在 items 中这里就涉及到中文和英文的语法区别，从这里也可以看出来英文编程语言并非完全不是英语，它还是包含了英文语法的。可作为反驳这一观点的论据。

swizl · 2017-10-19T02:43:33Z

@hummerstudio in 是我最头痛的一个。改语法我还搞不定，"在...之中"我找不到一个前置用法的词。不过我感觉古文中很有可能有，可以找出了再用用，大家习惯就好了。

前面的关键字都很正式，对于有赖癌的我来说，有些太长了。
下面两个嘈点：
类型干吗都加“型”，每人知道只是型吗？
如双浮点型，四个字，多少个拼音字母啊！英文也只叫double，没叫double_float.

swizl · 2017-10-19T02:51:33Z

@hummerstudio 我想了一下，可以多弄几个同义词。不过要改一改，clang匹配的文本和kw的方式，加起来才方便。不然加一个词都得source全搜一般，4，5处加一加。

nobodxbodon · 2017-10-19T03:02:04Z

要不在wiki里建个页面, 类似这样列出关键词和待定的可能选项? 然后有不同想法的可以自己添到"待选关键词里". 不过也许需要一个大致同意的'风格", 比如是否带"型".

英文关键词	待选关键词	暂定
int	整整型整数整数型
char	字字符字符型
...	...

hummerstudio · 2017-10-19T05:12:51Z

@swizl

"在...之中"我找不到一个前置用法的词。不过我感觉古文中很有可能有，可以找出了再用用，大家习惯就好了。
古文是”于“，如居于此，处于中等等。

我觉得中文关键字可以分为两类，一类是汉化已有语言的，不用要求完全符合汉语语法，汉化只是为了避免使用英文和混用导致的不一致性问题，这是中文编程的第一步（基于现有技术、时间限制和利用现有语言的需要），写中文关键字教程的时候可以提到原始英文，但写代码还是用中文来写。最终我们是希望能够按汉语语法来的，这个就需要我们自己来创造新语言了。

下面两个嘈点：
类型干吗都加“型”，每人知道只是型吗？
如双浮点型，四个字，多少个拼音字母啊！英文也只叫double，没叫double_float.

型不加感觉也可以。不要去想字母个数了，只想汉字个数吧！加上IDE的智能提示，其实效率会很高的！如何翻译可以再商酌，我查了下，像float关键字在C#里对应的类是System.Single,这样和double才是对应关系，float说不定是个历史遗留的关键字，后来CPU发展了，才出现double类型，这背后都是有发展脉络的，但是我们并不清楚，我认为我们翻译尽量符合实际意思，不一定直译。

在上述知识的背景下，float翻译为单精度，double翻译为双精度似乎更好。

@nobodxbodon 可以的。

nobodxbodon · 2017-10-19T05:29:10Z

wiki页已新建, 链接也添加到了顶楼

htwx · 2017-10-19T05:40:52Z

这是TS涉及到的


        'string': '文字',
        'number': '数字',
        'symbol': '符号',
        'function': '函数',
        'boolean': '真假',
        'null': '空',
        'true': '真',
        'false': '假',
        'void': '无值',
        'never': '不可及',
        'object': '基对象',
        '__type': '__类型',
        'unknown': '未知的',
        'untyped': `类型化`,
        '__resolving__': '__解决中__',
        'any': '通用型',
        'arguments': '增强参数集',
        '__computed': '__计算',
        '__object': '__基对象',
        '__function': '__函数',
        '__jsxAttributes': '__jsx属性',
        'arg': '参数',
        'export=': '导出=',
        '__export': '__导出',
        '__index': '__索引',
        '__new': '__新建',
        '__call': '__调用',
        '__constructor': '__构造器',
        '__global': '__全局',
        '__class': '__类',
        '__missing': '__失踪节点',
        'default': '默认',
        'prototype': '原型',
        'exports': '导出集',
        'ThisType': '本对象类型类',
        'Array': '数组类',
        'Object': '基对象类',
        'Function': '函数类',
        'String': '文字类',
        'Number': '数字类',
        'Boolean': '真假类',
        'RegExp': '正则表达式类',
        'abstract': '抽象',
        'as': '转为',
        'break': '跳出',
        'case': '为',
        'catch': '捕获',
        'class': '类',
        'continue': '继续',
        'const': '常量',
        'constructor': '构造器',
        'debugger': '调试',
        'declare': '声明',
        'delete': '删除',
        'do': '开始',
        'else': '否则',
        'enum': '枚举',
        'export': '导出',
        'extends': '扩展',
        'finally': '最后',
        'for': '循环',
        'from': '从',
        'get': '取',
        'if': '如果',
        'implements': '实现',
        'import': '引入',
        'in': '在',
        'instanceof': '类为',
        'interface': '接口',
        'is': '是',
        'keyof': '键为',
        'let': '变量',
        'module': '模块',
        'namespace': '名称空间',
        'new': '新建',
        'package': '包',
        'private': '私有',
        'protected': '保护',
        'public': '公开',
        'readonly': '只读',
        'require': '需要',
        'global': '全局',
        'return': '返回',
        'set': '置',
        'static': '静态',
        'super': '父构造器',
        'switch': '假如',
        'this': '本对象',
        'throw': '抛出',
        'try': '尝试',
        'type': '类型',
        'typeof': '类型为',
        'var': '自由变量',
        'while': '判断循环',
        'with': '外扩',
        'yield': '获得',
        'async': '异步',
        'await': '等待',
        'of': '属于',
        'IArguments': '所有参数接口',
        'ReadonlyArray': '只读数组类',

htwx · 2017-10-19T05:43:21Z

这些是TS里JSDOC涉及的


 export const 内置JSDoc标签名 = createMapFromTemplate({
        "@type": "@类型",
        "@typedef": "@自定义类型",
        "@prop": "@属性",
        "@property": "@属性",
        "@arg": "@参数",
        "@param": "@参数",
        "@augments": "@增强参数集",
        "@augment": "@增强参数",
        "@return": "@返回",
        "@returns": "@返回",
        "@class": "@类",
        "@constructor": "@构造函数",
        "@template": "@模板",
    })

htwx · 2017-10-19T05:44:59Z

CTS中的关键字及ES5标识符汉化文件

nobodxbodon · 2017-10-19T05:52:13Z

@htwx orz 拜托一下, 最后一个特别长的(ES5)能不能换成一个代码链接啊? github的issue连个分页也没有, 这样五千多行贴出来之后, 看之后的评论的会比较累, 翻到底要个好几分钟, 呵呵

htwx · 2017-10-19T06:04:14Z

我这个翻译的不好但是很全面, 这个也是我还没发布的主因. 关键字和相关术语及常用的标识符最好形成一个业界统一的标准, 成立个标准组织.

htwx · 2017-10-19T06:16:16Z

这个歌CTS里面涉及到的内容实际很多包括了全部ES5 里面的方法属性对象等等内容, 关键字及标识符汉化是很重要的, 我的这套汉化的不理想, 这也是我还没发布的主因. 关键字根据我这些年的经验最好就是固定 2~3个汉字的范围内, 标识符主要分为:

模块名
名称空间名
函数名
类名
枚举名
接口名
装饰函数名
方法名
属性名
实参名
形参名
类型参数名
变量名
全局变量名
常量名
术语(HTML SVG ... )
文件名 ....

最好要有一套方案
我的经验及建议是关键字最好2~3个之间, 中英文编程人员认同度高的(就是不要和英文原版差距太大), 要给人学了中文编程后很轻松的就可以去写英文编程, 不要造成太严重的割裂. 从我的这套代码写出来的效果看 1个字的关键字很不可取,

1: 太短给鼠标选择带来困难.
2: 目前来看空格作为分割符是省略不掉的,用空格分割后1个字很不协调.
3: 在后期插件处理上1个字的关键字给插件编写带来一定的难度(主要是智能提示).
4: 名称尽量符号程序中的逻辑.
5:类似于 get set I of in is on from at obj err 等等类的可以根据是在标识符开头\ 中间\ 结尾\ 独立 \大写\ 小写等特点固定翻译.

swizl · 2017-10-19T11:12:03Z

@hummerstudio
in 对应 '于' 不错，这个居然搞忘了。
主要是一些介词，比较难搞，像 of 之类。
如 sizeof，之前翻成 "求大小" 还是不满意
不知道有没有跟 of 意思、用法都搭得字词？

@htwx
大部分关键字都很好，但有一些看着就不爽，有一些还没统一起来。
也亏你，憋出这么多，不容易

is 是
这个应该是判断的吧，用 '为' 较好。有的语言有 yes，no的值，到翻译的时候，找什么对应去呢？
in 在
虽然我之前也是这么翻的，但一直不爽。于真的可以。

keyof 键为
感觉就不是一个意思，我也头疼 of。求键如何
typeof 类型为
同上

var 自由变量
var 不是Variable的缩写吗？ "变量" 就可以了。

RegExp 正则表达式
正则就行了，RegExp 也是缩写呀。哪天人家写全了，怎么翻？

for 循环
while 判断循环
也行，就是感觉意思没到

typedef 自定义类型
类型定义

空 null
无值 viod
void 无值
我觉得两个意思弄反了， null 无， void 空

untyped 类型化
意思反了，未类型化

switch 假如
case 为
好吧，能自洽。感觉意思不一样

htwx · 2017-10-19T12:08:02Z

@swizl var 这个和 let 在ts 里挺冲突的现在更推荐用 let 所以就把 var 翻译为自由变量意思比 let 变量更灵活的意思关于 of 是比较麻烦的根据你的提醒我感觉翻译为 "求解" 在这种用法中更合适类型求解键型求解怎么样关于其他的都比我的强, 看来多讨论是有用的. 谢谢
错误处多指正,我这些都是机器翻译的,我本人是看着英语就困的人,不是假的是真的3个字母以上的英文我要1天不输入10次以上就会忘, 2个月没打过英文不管原来多熟悉也想不起来, 其他的就没这个毛病, 脑袋没感觉本. 我自称 "英语盲" 10年编程离开 ide 不会写, 因为我只记住了关键字的前2-3个字母. 看着认识就是记不住字母顺序.

swizl · 2017-10-19T14:08:13Z

@htwx 刚看了一下，var 和 let 用法上还是有一点区别的，var 从JS继承的，在JS里被诟病过的，let应该有些优化。当然主要是原词语义要对应上，一个用过原版语言的人能很快识别。

我建议 var 变量 let 让/设

我上学的时候，英文也非常烂。主要是对英文比较抗拒。
工作之后，因为邮件、文档有的公司是英文，没办法必须抛弃抗拒的心态。
慢慢积累，才有一点提高的。

nobodxbodon · 2017-10-19T17:38:53Z

如 sizeof，之前翻成 "求大小" 还是不满意
不知道有没有跟 of 意思、用法都搭得字词？

@swizl 像之前提到的, 如果不拘泥于它的现有关键词, 而是基于它的实际含义, 那么也许字长接近?
这种方式的坏处是一开始用惯sizeof的可能看起来不舒服, 不过感觉对于新手来说可能会更加易于理解.

另外, 在看到这个例子之前, 我也一直设想一个英文词在所有它所在的编程语言里都最好有同样的中文对应, 但是, sizeof在PHP里是求数组中元素个数的, 在Java里没有sizeof但核心库里有size, 也是求Collection中元素个数. 如果强求用词一致性, 似乎是延续了同一英文用词在不同编程语言中有不同含义这个问题. 是不是可以考虑基于在每种语言中的实际含义, 具体情况具体分析?

swizl · 2017-10-25T08:23:24Z

clang 折腾新成果
修改一个文件就能支持中文关键字了
https://github.com/llvm-mirror/clang/blob/master/lib/Basic/IdentifierTable.cpp

void IdentifierTable::AddKeywords(const LangOptions &LangOpts) ;
中用 AddKeyword 添加中文关键字和关键字enum 的对应关系

tok::PPKeywordKind IdentifierInfo::getPPKeywordID() const ;
在 switch 的 default 中可加宏的关键字，通过字符返回宏关键字enum

就这么简单！

nobodxbodon · 2017-10-25T09:13:06Z

@swizl 恭喜! 期待早日看到代码示例, 或者新代码库.

htwx · 2017-10-25T15:13:18Z

来个最难翻译的如果 class 翻译成2个汉字怎么最好 @swizl @nobodxbodon @buyouyuan @hummerstudio
我翻译成种类肯定是最差的.

nobodxbodon · 2017-10-25T16:10:01Z

"类型"? 其实感觉也需要推敲一下.
之前在写Java入门的时候, 倒是纠结了一下"object"的说法. 主要是没想明白为什么一开始要译作"对象", 个人感觉"个体"更形象. 一个"类型"可以有很多"个体", 感觉挺顺的. 欢迎拍砖.

htwx · 2017-10-25T16:14:34Z

class type object Object 这2个都麻烦 C++ 的原则要比那个麻烦点他内部可能会有对关键字字符代码的验证,例如关键字的长度和关键字字符是否为 ascii 等等

nobodxbodon · 2017-10-25T16:28:50Z

觉得这个解释有点借鉴:
class - 类别
type - 类型
不好意思之前写反了

htwx · 2017-10-25T16:38:51Z

至少比种类强听你的就叫类别了, 那个最后也改成善后或收尾, 一会在把整理好的关键字表在发一遍. 号召大家继续改. 这个对语言读和理解起来太重要了.

导入 { 某某类 } 来自 "某某模块";
引入 { 某某类 } 来自 "某某模块";
引用 { 某某类 } 来自 "某某模块";
使用 { 某某类 } 来自 "某某模块";

4b5ent1 · 2018-08-20T16:11:26Z

@swizl JAVA 中文关键字的一个方案，欢迎排砖。 #40 (comment)

abstract→象，这个比较勉强，还凑合。个人会选择音译[阿]或意译[虚]
assert→断，这个可以。另外可以考虑：定/试/假设
Boolean→不二，这个很好，服。
break→破；感觉[断]比[破]好点？
byte→字；感觉[节]比[字]好点，字有[word]的意思，1word=2byte
case→例；
catch→捕；捕这个用法感觉有点生硬，最好是意译，比如用[戳/取]
char→符；
class→类；
const→常；常作单字，感觉有点别扭。用[控]感觉好点？
continue→继；续比继好一点
default→默；还是用默认两个字比较好，单一个默字，很有违和感。单字可选用：赋
do→运；java的do感觉用[运]不如用[做]
double→双；个人倾向于用双浮
else→另；也可以用[余]
enum→举；用枚和列比较好
extends→承；单字用[扩]，双字用继承
final→终；用[末]比较好
finally→末；还是用[最后]吧，比较直接(finally是三音节，最后是双音节，感觉可以接受
float→浮；
for→为；个人倾向用[若]
goto→去；也可以用[见]
if→如；也可以用[如真/如一]
implements→成；用[立]比[成]好
import→进；用引入好一点。单字用[引]
instanceof→是；[是类/实为]比[是]好
int→整；或者i32
interface→接；接不好。建议可选：因/定/互
long→长；用i64
native→原；
new→新；感觉用[又]更好记
package→包
private→私；用[内/自]比[私]好一些
protected→保；用[固]好一点
public→公；或者用[共]
return→返；也可用[回]，更好认
short→短；用i16
static→固；用[禁]或[静]
strictfp→严；用[精浮]
super→超；用[上/越]
switch→分；用[选/验]
synchronized→同；用[同步]或[信]
this→此；
throw→抛；用[报]更直观
throws→弃；用[报出]
transient→暂；用[临/川]也可以
try→试；用[干]也可以
void→空；用[无]
volatile→易；用[微]好一点
while→当；用[为真]
true→真
false→假
null→无；用[空]

nobodxbodon · 2018-08-21T16:54:30Z

#40 (comment) 提过, 上个月写此文时愈发觉得, 语言设计(包括关键词设计)最好与使用结合.
个人考虑写一个非常简单的纯UI演示页, 左边是关键词对应表(可修改, 最好能保存/导出/导入), 右边是演示程序, 对应表修改后可以直接看到演示程序的形态. 演示程序可以慢慢积累一些有代表性的(算法/业务相关等等), 以及不同语法设计的(有/无空格, 不同符号/语法规则等等)
希望可以通过这样的动态效果测试, 更有效率地演示与达成共识.

4b5ent1 · 2018-08-21T17:48:21Z

@nlpguyz 不知你有没有认识有中文/翻译专业背景的一起讨论? #40 (comment)

@nobodxbodon 我有认识学中文的，也有认识做翻译/同传的，但是这两类人，都不怎么跟编程打交道。而反过来，认识的会编程的人里面，[古文/文学/人文]功底比较深厚的，好像没有。我是学电子的，对古文字古汉语有业余研究，翻译的话也还凑合的那种。

nobodxbodon · 2018-08-22T00:01:32Z

上面的想法初步实现并成文在中文关键词替换体验页面原型. 欢迎各种尝鲜/改进, 以及添加覆盖更多关键词的示例程序.

nobodxbodon · 2018-08-22T00:18:05Z

@Absente

我有认识学中文的，也有认识做翻译/同传的，但是这两类人，都不怎么跟编程打交道。

随着编程普及, 应该会有越来越多非理工科背景的加入.

而反过来，认识的会编程的人里面，[古文/文学/人文]功底比较深厚的，好像没有。我是学电子的，对古文字古汉语有业余研究，翻译的话也还凑合的那种。

在个人实践中, 中文命名更接近当代书面语. 从软件工程角度看, 需求文档(包括业务术语)一般也是用当代书面语, 个人认为在设计/实现时可顺势沿用. 在语言设计上, 如果关键词/语法与命名风格大相径庭, 也许会影响可读性. 这也是上面的工具的初衷, 希望更多从实例代码出发考虑关键词/语法设计.

4b5ent1 · 2018-10-03T10:19:16Z

@htwx #40 (comment)

关于ts的泛关键词汉化，个人还是持汉化从简的观点，即有些部分不需要汉化，只需要简化。

个人认为，需要汉化的有以下：

token	origin	token	origin	token	origin
文字	String	数字	Number	空	null
符号	symbol	布尔	Boolean	永不	never
未知	unknown	`__解决中__`	`__resolving__`	__jsx属性	__jsxAttributes
参数集	arguments	I参数集	IArguments	__全局	__global
__类	__class	导出=	export=	__导出	__export
__索引	__index	__构造	__constructor	默认	default
原型	prototype	导出集	exports	数组	Array
本类	ThisType	函数	Function	文类	正则
构造	constructor	调试器	debugger	删除	delete
导出	export	扩展	extends	最终	finally
导入	import	类从	instanceof	键为	keyof
模块	module	域	namespace	包	package
锁	protected	只读	readonly	要	require
全局	global	此	this	类型	type
类为	typeof	异步	async	等待	await
只读数组	ReadonlyArray

可简化的有以下几个： // __双下划线可以考虑写成[内]

token	origin	token	origin	token	origin
fn	function	obj	object	__obj	__object
__fn	__function	str	string	num	number
bool	boolean	impl	implements	pub	public

可有可无的有以下几个：

token	origin	token	origin
真	true	假	false
无值	void	任意	any
捕获	catch	基类	Object
像	abstract	声明	declare
枚举	enum	复	for
来自	from	取	get
如果	if	实现	implements
接口	interface	是	is
令	let	新建	new
私	private	返回	return
设	set	静态	static
父级	super	假如	switch
抛	throw	试	try
当	while	得	yield
属于	of'

待定的有：untyped，__computed
不做修改的有如下几个：
as，__type，arg，__new，__call，__missing，break，case，class，continue，const，do，else，in，var，with

java的关键词里面，感觉不需要汉化的有：
abstract，break，case，catch，const，continue，do，else，for，goto，if，new，native，protected，super，transient，volatile

可以汉化的有：
assert→假设 Boolean→布尔 default→默认 enum→枚举 extends→继承
finally→最后 float→浮 implements→ 构建 import→导入
instanceof→是类 int→i32 long→i64 short→i16
interface→接口 package→包 private→私 return→返回
synchronized→同步 this→此 throw→抛 throws→弃
void→无

汉化/可有可无：
strictfp→精浮 double→浮浮 class→类
byte→字节 char→符 final→末
static→静 switch→选 try→试
while→当 true→真 false→假
null→空

（todo:最后，typescript和java取交集

cflw · 2018-11-30T14:42:08Z

我看了一下维基页，有几个问题。

整数类型候选词”i数字“是否合适？并不是所有语言的int都是固定32位的。像c++里的int最小2字节，没有固定大小。python里的int是个大数类型。
关于近义词的处理。”argument“和”parameter“都有“参数”的意思。需要准确区分的时候，其中一个翻译成“参数”会不会有问题？

我觉得关键字候选词列表应该再长一点，尽量能够覆盖所有编程范式，包括函数式编程、等等。

nobodxbodon · 2018-12-01T04:44:52Z

@cflw

整数类型候选词”i数字“是否合适？并不是所有语言的int都是固定32位的。像c++里的int最小2字节，没有固定大小。python里的int是个大数类型。

+1. 要么不同语言取不同关键词, 要么直接用int原型integer的对应含义-"整数"或者近义词?

关于近义词的处理。”argument“和”parameter“都有“参数”的意思。需要准确区分的时候，其中一个翻译成“参数”会不会有问题？

这些并非常用语法关键词, 也许可以归在#54

nobodxbodon · 2020-03-11T02:47:44Z

才发觉eval好像是来源于英文代数术语中的 evaluate，后知后觉了：

When we substitute a specific value for each variable, and then perform the operations, it's called evaluating the expression.

darkcmh · 2020-05-11T15:34:31Z

稍微整理了一下在Q群的发言，关于中文化的编程，个人意见归纳成以下三个方面。
一、中式命名规范
现在当务之急是先定下一套行之有效的命名标准方案和现行IDE可支持的快速输入中文变量（自动补全）的功能并普及化，既能适合完全中文化的编程语言，又能兼容现行的其它支持中文命名的编程语言，这套规范和对应功能还要能堵上那些嫌切换中文输入麻烦的假洋鬼子的嘴，然后就是要联合一些有话语权的大V驳斥一些妖魔化中文编程的言论并要形成有效影响。

我的想法是在中文变量前加上对应中文的拼音缩写，无论中文有多长，缩写都只要3到4个应该足够定位，比如xm姓名，dz地址，主要是用来堵那些说打中文影响自动补全速度的人的嘴，这样无论是支持中文命名的编程语言还是完全中文化的编程语言都不影响自动补全功能了。——当然最完美的方案是能写个插件，直接让现有的各种主流IDE全部支持拼音缩写自动补全，那就可以完全省掉前缀的拼音缩写（VSC上已经有了一个由zj1d写的对应插件了，虽然是初版，但相当好用）。退而求其次的话最好也是能有个插件能在变量命名完成后自动提取拼音缩写加到最前。

而针对现有编程语言做一个新的IDE以及在IDE中添加输入法的方案个人认为不可行，因为每个人有自己习惯使用的输入法和编缉环境，而且还要考虑到五笔用户。不能让程序员改变原有输入法和编缉环境的习惯，所以不能让程序员换IDE，换输入法，这样会在普及中文编程上遇到抵制。

然后是类型缀词，我觉得以前受到原有英语规则影响让大家思维固化了，在已有明确声明的情况下再加同型缀词会显得多此一举，比如“class 学生”或“类学生”就已经表明“学生”是个类了，再加个类字就没必要了，英文库中class Object也没写成class ObjectClass呀，用的时候大家都知道，实在不知道查一下声明，在使用时，比如“new 学生（）”，明眼一看就能理解是“new”了一个“学生”，对新人来说也非常好理解，而“new 学生类（）”对于老手来说无所谓，但对新入门的小白来说就要多绕一个弯了，老师也许要这么解释：从学生类中生成一个新学生实例，——感觉不是很友好的解释。

同理的“添加()” 即可，没必要“添加f()”来表明这是个函数。什么时候需要加类型缀词呢？比如想强调“姓名”是个全局变量，那么“姓名g”或“姓名q”都行，g或q放在前还是后还要考量一下，因为目前中文化的自动完成支持功能欠缺，我前面提出过为了兼容现有的IDE，在中文命名前加上3到4个拼音缩写，如果不得不如此的话，把变量类型的缀词放在后面可以避免多加一个下划线的麻烦。非加不可的类型缀词完全可以放在最后，因为其实用的时候程序员大多都关注变量本身，只有别人看程序的时候才会看一下这变量是个什么类型，因此把缀词放在后面就是真的点缀一下，需要了解的人就扫一眼最后，不关心的人甚至根本不用看。

另外，在缀词问题上为了区分“学生学生”而专门变成“学生类学生”完全没必要，Object object纯粹就是一种懒人命名，对实例加上特定的缀词能在声明时区别即可，比如“学生学生实例”甚至“学生学生o”（o即对象object，或用obj，表示是一个实例化对象），这样能避免在库本身上过多累赘用字，实例化对象缀词爱用什么用什么只要能区分都无所谓，库的命名简洁干练与规范化才能让中文库显得有足够的“范儿”。

二、现有标准库的翻译
关于现有关键字与库的翻译，目前看到的结果也是有些地方显得太过在意英文原文，比如print直译成打印，我觉得直接用其作用来代替较好，比如print作用就是显示，那就翻译成显示就好，for、while、do...while统一成循环（do译成“开始”），反正编译时看的是括号里的格式，编译器根本不在意for和while两个单词有什么区别。

对于已存在的编程语言，没必要强求关键字中文化，毕竟三五十个词没多大难度，不用追求极致中文化，怎么方便怎么来。中英混合并不难看，想想数学上不也是：已知 △ABC为等边△，也没人说难看吧，也不需要写成已知三角形ABC或三角形甲乙丙吧。所以要中文化的是已有编程语言的库，根据一套统一的命名规范把现有库中文化，我的想法是直接根据原库结构做一套相同结构的中文命名的库，直接调用原库，相当重打个包，这样原库开源的话被人升级了算法我们也不需要修改，而且一套同样中文命名的库还能做Java版、C#版，因为只是调用对应的方法而已，这样甚至更有利于代码转换，同一套代码甚至可以同时用于Java和C#，——复制过来，稍改几个关键字直接编译即可，主体代码基本啥都不用改。

在库的翻译上，目前了解到的做的不错的是草蟒，以Python为切入点是非常好的选择，毕竟是超新星，流行且想以之为入门的人也多。不过其中一些命名规范问题也很明显，就是前面说的有些拘泥于英文用词。草蟒的汉化经验总结页面上也说了“如果直译难以理解或意译更好的话，应根据其作用取意译”，我觉得应该反过来，以意译为主直译为辅，也就是符合国人的表义习惯就好，像elseif，“余如”、“或如”都不太符合国人的思维表义，“或如”更容易造成理解错误，因为“或”在逻辑上是允许两者都满足的。如果找不到更好的古文风的译法，直接“否则若”会更好些，若实在纠结两字，用“异若”“异如”应该也还行（如果不是“异或”早被用于另一个关键词的话这里用异或会更贴切）。翻译时尽量用书面化语言，不必强求光从命名上就能一眼看出作用而用些口语化的用词，会显得非常“不专业”。例如在Q群里讨论过的lru_cache，即使母语是英文的原生使用者，同样也要先查“lru”是什么意思如何用才知其意，那么反正都是需要做“名词解释”的，用“低频缓存”（低频缓存管理）就专业得多，“低频”即“使用频率低”，查者一看即明，群里有人建议用“少用缓存”就显得过于口语化了。

三、新的完全中文化的编程语言
首先要考虑的是“定位”，就是这门语言注重哪方面的开发。然后针对定位设计关键字，要摒弃原有的照搬式的类C编程语言的方式，只能在一定程度上借鉴，能用格式区别的，就不用强求关键字不同。比如if和switch，完全可以用同一个字：若（或如果），区别就是
“若（a=b）{XXX;}”
和
“若（a）
{
为 5：XXX;中断;
为 8：XXX;中断;
}”
这完全是可以用格式区别编译的。

这样做首先能避免一些原来就抵触中文编程的人嘲讽只是翻译了一下现有编程语言的关键字以落人口实（造谣一张嘴，辟谣跑断腿，说易语言就是翻译一下VB就是最好的先例）。同时也能带入一些新的角度考虑如何让编程语言有更多“中国范儿”。

liuxilu · 2020-10-09T01:46:05Z

of 之于，合音为诸
应该不会有更好翻译了

switch-case 检-索

liuxilu · 2020-10-09T05:52:27Z

在列表中->中列表/中于列表。此种介词，均可如此：在你左边左你左于你；在你们中间间你们间于你们

nobodxbodon · 2021-05-17T17:03:59Z

@program-in-chinese/all 为国内用户访问方便起见，新话题转到 Gitee 发了： HTML 标签中文化命名探讨

tldzyx · 2021-10-09T06:20:29Z

@hummerstudio in 是我最头痛的一个。改语法我还搞不定，"在...之中"我找不到一个前置用法的词。不过我感觉古文中很有可能有，可以找出了再用用，大家习惯就好了。

前面的关键字都很正式，对于有赖癌的我来说，有些太长了。下面两个嘈点：类型干吗都加“型”，每人知道只是型吗？如双浮点型，四个字，多少个拼音字母啊！英文也只叫double，没叫double_float.

for(item in list)
--->
迭代(数据项来自列表)

这个感觉如何

tldzyx · 2021-10-09T06:26:20Z

现在使用中文方法多是在英文输入法情况下, 通过拼音首字母智能感知出来的. 但是考虑后面保持中文输入法的情况下编码, 这时候更多依赖的是输入法推测, 就我了解拼音输入法对于比较长、比较特殊的词有更快速精准的推导效果。

所以这里提个建议，关键词太短不可取（单字就别了重码率高， 2~3个字最佳，最长不超过5个字）。

nobodxbodon · 2021-10-09T07:07:01Z

@tldzyx 刚看草蟒里 for ... in 用的是取...于...：https://www.grasspy.cn/guide/kw.html

关于关键词，个人认为只要阅读通顺、语法风格一致都可尝试。输入方面，不大确定IDE辅助能做到什么程度，如果能像标识符补全这样的话，单字与否似乎问题不大。

tldzyx · 2021-10-10T03:25:53Z

@tldzyx 刚看草蟒里 for ... in 用的是取...于...：https://www.grasspy.cn/guide/kw.html

关于关键词，个人认为只要阅读通顺、语法风格一致都可尝试。输入方面，不大确定IDE辅助能做到什么程度，如果能像标识符补全这样的话，单字与否似乎问题不大。

取...于... 这种看着简洁, 对阅读友好, 但是对输入就很糟糕了, 全面使用中文编程的话, 实际上输入法就是保持中文的状态, 而现在普及的是拼音输入法, 所以拼音输入法下输入效率高的是词而不是字, 单字输入基本要全拼, 而且重码率高, 也因此不推荐用单字做中文关键词.

如果说兼顾读写的话, 我建议是关键词用2~3个字的, 输入时思路不容易被打断(五笔拆字拼音重码), 然后因为关键字是会被编译器识别到的, 可以通过插件将完备的长关键词显示成短的关键字以优化读体验, 因为底层存储的实际上是长关键词, 所以显示映射成什么样插件可以灵活配置不影响实际的语法语义.

nobodxbodon · 2021-10-10T06:31:03Z

@tldzyx 输入方面如果在实践中发现是瓶颈，总有方法改进体验（像上面提的标识符补全辅助插件）。个人认为语法设计上不妨先百花齐放，在实践中检验即可。顺便说下，之前尝试的借鉴自然语言的语法设计也有一些单字关键词。仅仅为了“可能”的输入效率问题而自缚手脚感觉不大值得。

xgongya · 2023-07-25T12:41:36Z

您好，您的邮件已收到，会尽快处理回复您！

nobodxbodon mentioned this issue Oct 20, 2017

git提交历史记录 program-in-chinese/CTS#1

Open

4b5ent1 mentioned this issue Oct 3, 2018

关于简化关键词汉化的一些建议 #91

Closed

This was referenced Oct 13, 2018

Ld2：Python变量命名规范 pyzh/song#26

Open

关于汉化关键词的标准化执行策略 #92

Closed

nobodxbodon mentioned this issue Oct 22, 2018

中文命名的特定问题, 相关风格及规范 #45

Open

4b5ent1 added this to the 2018戊戌 milestone Nov 30, 2018

nobodxbodon mentioned this issue Jan 28, 2019

组内repo盘点 #126

Closed

61 tasks

nobodxbodon unassigned 4b5ent1 May 12, 2020

liuxilu mentioned this issue Nov 10, 2020

试以单字译C# #181

Closed

This comment was marked as spam.

Sign in to view

中文化 类C编程语言 需要什么样的关键字? #40

中文化 类C编程语言 需要什么样的关键字? #40

Comments

swizl commented Oct 18, 2017 • edited by nobodxbodon Loading

htwx commented Oct 18, 2017

swizl commented Oct 18, 2017

nobodxbodon commented Oct 18, 2017

nobodxbodon commented Oct 18, 2017

buyouyuan commented Oct 19, 2017 • edited Loading

hummerstudio commented Oct 19, 2017

hummerstudio commented Oct 19, 2017

swizl commented Oct 19, 2017

swizl commented Oct 19, 2017

nobodxbodon commented Oct 19, 2017

hummerstudio commented Oct 19, 2017

nobodxbodon commented Oct 19, 2017

htwx commented Oct 19, 2017 • edited Loading

这是TS涉及到的

htwx commented Oct 19, 2017

这些是TS里JSDOC涉及的

htwx commented Oct 19, 2017 • edited Loading

nobodxbodon commented Oct 19, 2017

htwx commented Oct 19, 2017

htwx commented Oct 19, 2017 • edited Loading

swizl commented Oct 19, 2017

htwx commented Oct 19, 2017 • edited Loading

swizl commented Oct 19, 2017

nobodxbodon commented Oct 19, 2017

swizl commented Oct 25, 2017

nobodxbodon commented Oct 25, 2017

htwx commented Oct 25, 2017 • edited Loading

nobodxbodon commented Oct 25, 2017

htwx commented Oct 25, 2017 • edited Loading

nobodxbodon commented Oct 25, 2017 • edited Loading

htwx commented Oct 25, 2017 • edited Loading

4b5ent1 commented Aug 20, 2018 • edited Loading

nobodxbodon commented Aug 21, 2018

4b5ent1 commented Aug 21, 2018 • edited Loading

nobodxbodon commented Aug 22, 2018 • edited Loading

nobodxbodon commented Aug 22, 2018

4b5ent1 commented Oct 3, 2018 • edited Loading

cflw commented Nov 30, 2018

nobodxbodon commented Dec 1, 2018

nobodxbodon commented Mar 11, 2020

darkcmh commented May 11, 2020

liuxilu commented Oct 9, 2020 • edited Loading

liuxilu commented Oct 9, 2020

nobodxbodon commented May 17, 2021

tldzyx commented Oct 9, 2021

tldzyx commented Oct 9, 2021

nobodxbodon commented Oct 9, 2021

tldzyx commented Oct 10, 2021

nobodxbodon commented Oct 10, 2021

This comment was marked as spam.

xgongya commented Jul 25, 2023 via email

中文化类C编程语言需要什么样的关键字? #40

中文化类C编程语言需要什么样的关键字? #40

swizl commented Oct 18, 2017 •

edited by nobodxbodon

Loading

buyouyuan commented Oct 19, 2017 •

edited

Loading

htwx commented Oct 19, 2017 •

edited

Loading

htwx commented Oct 19, 2017 •

edited

Loading

htwx commented Oct 19, 2017 •

edited

Loading

htwx commented Oct 19, 2017 •

edited

Loading

htwx commented Oct 25, 2017 •

edited

Loading

htwx commented Oct 25, 2017 •

edited

Loading

nobodxbodon commented Oct 25, 2017 •

edited

Loading

htwx commented Oct 25, 2017 •

edited

Loading

4b5ent1 commented Aug 20, 2018 •

edited

Loading

4b5ent1 commented Aug 21, 2018 •

edited

Loading

nobodxbodon commented Aug 22, 2018 •

edited

Loading

4b5ent1 commented Oct 3, 2018 •

edited

Loading

liuxilu commented Oct 9, 2020 •

edited

Loading