htwx
htwx
就是因为注释翻译的不准确,毕竟没有人工参与.所以我保留了英文注释,这个注释实际是可以做到一键替换的.
我的这个CTS汉化了LIB\关键字\标识符\编译选项\命令行命令\现在唯一剩下的是\编译错误,这个不是实现不了是量太大. 900多行,而且要求翻译必须相当准确.  
英文接口不多(文档还是很多的),就是我提到的几个主流框架,剩下的基本都是500行以下的小型接口文档,我的工具如果是英语好的人翻译1天2万行,如果英语不好1天也能5000+有谷歌翻译在基本能谁用谁翻译就行了,翻译完的可以发布到 npm 社区,有版本控制就没什么大问题了. 就翻译来讲还有比较麻烦的事情,因为英语有大小写,缩写,简写,单数复数等等区别,还有有些英语单词在英语中的本意也不是程序中药表达的意思,所以还是很难翻译的 因为翻译类型声明文件要求英文是不同的中文也不能相同所以比较麻烦. 例如: ERROR Error ERR err 甚至还有 e 汉语的意思对应的都是 "错误" 单复数也麻烦 毕竟汉语大多数是省略复数表达的 例如这个 lines 你翻译成 行组,行集,多行... 都不咋地. 就是这个 this 翻译起来都很费劲 这个也是我的这版没有发布的原因之一,关键字的翻译现在的结果我是不满意,但还没找到更好更贴切的, es6\es6\es7\node 等这几个基本的类型声明文件里有好多我感觉翻译的不满意的,还有些专业词汇没有拿准是否应该翻译 例如 HTML SVG...
**因为翻译类型声明文件要求英文是不同的中文也不能相同所以比较麻烦 例如 ERROR Error ERR err 甚至还有 e .** 这个没什么好办法因为你是翻译现有的库,人家已经这样了, 没法改了.我现在采取的也是加 前后缀的做法 例如 ERROR 就是_错误_ , Error 错误类, Err 错误_ err 错误__ 对于e 这种有2个办法就是 对e 不翻译或者 有个局部词典 //@{ 错误___:e }...
**这就实现了你在家里用中文编程 到单位去一样可以提交成英文代码.** 这个的实现方式也是要标注词典的, 但是你在开始的地方吧这个名词标注好 对应的英文后 例如: **getText** 你标注成 **取文本** ,在以后你只要使用 取文本 编译的时候就 替换成 **getText** 了编译完后 词典文件就自动抹掉了你提交的时候是纯英文的. 这个有很多使用场景的 , 多数是用在外包的时候你给人家提供中文代码人家拒收的. 中文编程必须要产生效益才能有人愿意用.如果不能产生效益 写的代码谁都不要就麻烦. 目前的大环境就这样,这个是要长期才能改观的事.
这个使用全局词典是为了增加翻译速度的 例如 name 你翻译成 名称 全部的 name就都成 名称了, 但是 这就要求 Name 你就不能翻译成 名称了,因为是全局的,英文不一样的 中文一定要不一样, 但不不要求 中文一样,对应的 英文也要一样, 只要 名称不冲突就行了, 所以这个烦, 因为使用了全局词典 ,还有就刚才的 p 在全局翻译成 属性, 能满足80%的需求, 可能局部中的 p 并不表示 属性的意思...
如果他们不再一个作用域这样是可以的 如果在一个作用域就会报错 . 就ts 而言 我的全局是指一个在一个js模块空间内, 如果这个js 模块是全局的那就在全局范围内不能有重复的
就是说所有的标识符是有作用域的 有的是 全局作用域 例如全局变量, 有的是 块作用域 ...
还有这个 词典也要做 范围检查和 字符合法性检查等等的 就不能出现 不允许的标识符 例如 1getText 这个就是错误的 getText1 就是正确的
vscode 有完善的 插件系统 专门针对各种编程语言的 所以 智能感知 很容易实现的 现在 微软开源了 语言服务 和 语言服务客户端 写个 智能提示 不是大问题