Closed nobodxbodon closed 5 years ago
由于代码命名与自然语言相去甚远, 因此长远考虑借助词典进行逐词翻译而不是现有在线翻译的API(调用受限, 而且字典不可控), 在此基础上添加一些常见的命名语法规则, 比如Map命名时经常使用的xxByy
可以翻作从yy到xx
(仅作举例), 比如ageByName
->从名字到年龄
. 但原型/短期如用在线翻译API方便亦可.
@htwx 记得之前你在CTS相关项目里也调用过外部翻译API, 请问实现的也是代码翻译吗?
发现一个英汉词典数据库, 考虑将其数据裁剪后封装成API, 可作为独立项目开展.
ageByName这种翻译,感觉可以机械化,by=从,>=龄从名
但是这里又会涉及到一个问题,就是有时候英译中,中文反而没有原文直观(视觉上的,英文有大小写,容易分词)
ageByName这种翻译,感觉可以机械化
之前也是打算用简单的语法转换, 比如按名称取年龄
("年龄"置后)等. 个人认为不一定要保持原文顺序, 因为如果中文很难找到同样顺序的表达, 多半这种表达本身就不常用.
有时候英译中,中文反而没有原文直观(视觉上的,英文有大小写,容易分词)
之前写的在代码中进行中文命名(类/变量/方法等)的优势里的优势之一"不需要驼峰命名法或者下划线分隔".
Generate source code from AST with Antlr4 and StringTemplates提到, 源码语法分析后再基于语法树生成源码这一转换过程有不少细节问题, 并非那么简单. 当然命名翻译并不牵涉改变代码结构, 但其中提到的这几条都还是问题:
- Preserve comments. I don't think ANTLR ASTs do this.
- Generate layout that preserves the original indentation.
- Preserve the radix, leading-zero count, and other "format" properties of literal values
- Renerate strings with reasonable escapes
考虑搭建原型时暂时只用最简单的字符串替换而不是对代码进行语法分析.
刚试了使用词典API翻译这个简单的例程:
class Person:
pass # An empty block
p = Person()
print(p)
有几个发现:
[计]
的释义, 应该是计算机领域的释义. 比如class: [计] 类别; 类; 种类; 类程
, 但也有比较偏的如pass: [计] 遍
, print: [计] DOS外部命令:在打印机上打印文件, 可一边打印文件一边执行其他工作
, 原型可以优先用[计]
释义, 之后再用术语词典API进行改善.# An empty block
就被译为# 一 空 块
p
这样的缩写命名, 理想情况是根据上下文得出含义(person), 但原型打算暂对单字母变量直接忽略(不翻译)使用现有在线翻译服务进行代码翻译的体验, 最后作了一点初步的需求分析.
代码翻译尝试-使用Roaster解析和生成Java源码. 感觉自然语言翻译部分挑战更大, 如何选择最合适的释义和词序重组等. 暂时打算先专攻Java. 其他编程语言如有类似Roaster这样兼顾源码语法解析和生成的库, 烦请告知.
搭了个服务演示翻译库:
POST到 74.91.17.250:8091, 在code
参数输入英文源码, 返回汉化后的源码. Postman截图:
初步界面演示, jquery. 可能写篇短文. http://74.91.17.250:9000/
重构+测试+小改进(支持数组类型的翻译):
语法高亮编辑器~ 进度说明: https://www.v2ex.com/t/484895#r_6214357
@swizl https://github.com/program-in-chinese/overview/issues/48#issuecomment-426504562 转至此继续探讨:
想了一下做成对单个源文件翻译的工具就好了。遍历文件夹用shell等工具处理就可以了。但是得保存词条表。流程大概是:先在词条表中查找,有的话,直接用,以保证整个工程翻译的一致性。没有的话,调用翻译接口,使用返回结果,并保存在词条表中。
感觉难度取决于对源代码的语法分析程度. 如果翻译出的文件需要能够编译, 就有更多细节要照顾. 像上面实现的, Integer->整数, String->字符串, 对于一般浏览代码也许有意义, 但导致不能编译. 此项目暂时的重点是阅读代码大意.
@nobodxbodon 哈哈,对的。 第一步,可以将所有变量名、函数名、宏名、枚举值等字符串,放在词条表里,供人校对,甚至可以作"本地化"。即使同一个单词在不同的名称中被翻译成不同的意思,对编译器也不影响,因为整个字符串在工程中是一致的。 第二步,再作分词,将各种名称、字符串,按照驼峰、下划线、空格等分词,并建立数型关联表、映射表等。确定一个元词的翻译,对应的名称串、字符串,都会翻译一致。 最后,可能再去考虑更复杂的情况:
用了个translate
子域名, 但还没搞定80端口, 还是原来的9000端口: http://translate.codeinchinese.com:9000/
已改为80端口. 刚测试 http://translate.codeinchinese.com/ 如下. 改进的功能是: 类型字段已翻译(visitedCountries->拜访国家)
JavaScript源码翻译可参考JS代码翻译成中文书写的代码
Github代码翻译插件的后续: Chrome插件原型 通过调用离线英汉词典插件的查词接口, 实现了除关键词和核心API之外的命名和文本单词部分翻译: Python: Typescript: Java: 打算继续改进. 包括添加所有语言的关键词词典, 等等.
继续下去有两个方向. 一是继续浏览器和vscode(及visual studio)上的插件开发; 二是Java开发环境下的插件开发, 比如Eclipse. 前者的优势是, 因为都是JS实现, 可以重用的部分不少. 而且面向平台和用户较广. 但JS在NLP方面的库相对较少. 后者的优势是, Java的NLP相关库较丰富, 用户群也许更接近商用项目.
初步打算, 在v2帖的三项中, 先完成vscode的源码翻译预览(效果与当前浏览器插件齐平), 以接触尽可能大的用户群. 插件中实现并列编辑器可以参考官方参考例程. 之后再确定是进一步改进机翻效果还是尝试第二个方向.
几种模式都在考虑:
- 只是预览
- 批量翻译(只是单向)
- 像你说的翻译后只是作为中间产物使用, 源码仍然是英文命名
实现优先级暂定是从上向下, 感觉技术难度也是越后越难. 理想目标是保证完全翻译出的编译无误, 但即使使用 IDE 本身的重构 API 恐怕也不能 100%.
个人觉得和 #85 有很大部分重叠,不如先把这个item从主页隐藏了。如有新的阶段进展,再开,也许会好点
基于https://github.com/program-in-chinese/overview/issues/86#issuecomment-436745681 的计划, 已初步完成"vscode的源码翻译预览"功能: VS Code英汉词典v0.0.8: 批量翻译文件部分命名. vscode对源码标识符操作支持的API感觉比较有限. 机翻的挑战也不小. 短期目标转向https://github.com/program-in-chinese/overview/issues/97 .
源自 @swizl 的 https://github.com/program-in-chinese/overview/issues/59#issuecomment-411272880
https://github.com/program-in-chinese/overview/issues/37 中曾经用JDT实现从Java源码中类/方法的提取(似乎也有汉化后代码生成). 另一种可能是使用Antlr分析+StringTemplate生成新代码. 一般的源码命名汉化还需术语词典以及普通英汉词典(有库吗?).