@HvangStormstout 嗯, 之前有类似提议: https://www.v2ex.com/t/502820?p=1#r_6382598

还没想好怎么显示. 如果紧跟在英文后面, 代码的视觉效果不大好吧.
现在可以按照行数找到对应行. 先看看能不能把弹窗变窄一些, 现在经常遮住部分原代码段.

@no1xsyzy 加"的"可以在机翻时实现。个人不觉得必要。毕竟"基本计算器" "科学计算器"还算一目了然吧

@l00t 嗯 这个插件仅在原代码可读且为英文时有效

@947211232 请给一个英文没歧义, 翻译过来中文有歧义的例子

@nililnellaf #64 的那个 Java 源码翻译服务做了语法分析, 做了初步的层级翻译(类 /方法 /变量名). 但对不同语言的语法分析和代码生成工作量较大. 感觉 JS 实现难度更大了.

@Yourshell 关于中文命名与代码可读性, 请见 #97 的文章.

@agdhole
@U2Fsd
@dovme
@no1xsyzy
"对在代码中使用中文命名的质疑与回应": https://zhuanlan.zhihu.com/p/30529835

欢迎各种不同意见. 如有兴趣可以另开题讨论, 或者到专栏文章回复, 或者 github 讨论组此专用贴: https://github.com/program-in-chinese/overview/issues/44

@littlewing
@beny2mor
可以看看 gg 翻译的结果是否更好 (刚试了并没有)

@acrisliu 同样一段代码在谷歌和百度翻译都把它翻成了'秒'. 只有有道翻成了'第二'. 机器翻译本来就是大课题, 就这个插件使用直译能到现在的效果已经在我的意料之外了. 见 #11 和 #64 最近也在找 JS 实现的 NLP 相关库, 并不想自己造轮子.

初步小结在短文'在线代码离线翻译 Chrome 插件"一马"v0.0.8':
https://zhuanlan.zhihu.com/p/48120706
看来短期内只需支持 GitHub, 码云即可.

@AlkTTT
> 但是是在后面备注，而不是直接替换

嗯, 也许可以支持几种显示模式

> 方法里面的源码最好不要翻译，翻译过来会有语法错误。

如果不翻译关键词( #67), 仅是命名翻译之后, 应该不会有语法错误

> 方法上面的注释，这个翻译过来才是最棒的

见 #11 和 #64, 长句翻译还远.

@waytoshine 插件更侧重的是对命名部分的翻译.
关键词汉化视觉效果与易语言接近. 但个人认为中文语法的编程语言还远未成熟. 参考专栏里那个"抚子"语言, 就有不少源于日语自然语言的特色语法, 如无空格设计, '它'的使用等等.

@micean
@ray1888 并非在线浏览代码, 而是对网页中的代码段进行命名和少数文本常量的翻译.

@babedoll 请见 #11 和 #64, 长句翻译还远.

@loshine1992 多谢. 也许可以作为批量翻译功能的参考.

@jay4497 多数语言的编译器已经支持中文命名了吧, 为何还要"翻译成实际代码"?

@misaka19000 关键词的翻译确实很值得商榷. 之前有相关讨论: https://github.com/program-in-chinese/overview/issues/40
欢迎推荐更合适的翻译.

@Admstor 嗯, 其实设想中的一个目标是"让用户可以选择是否中文化关键词": https://github.com/program-in-chinese/webextension_github_code_translator/issues/3
如果关键词不汉化, 理想情况下翻译出的结果应该可以编译(假设该语言支持 Unicode 命名, 大多数排行靠前的应该都有支持的编译器)

@janus77 多谢提醒. 已为重名检验添加 issue: https://github.com/program-in-chinese/webextension_github_code_translator/issues/16

刚实测:
`SelectItem` -> `选定项`
`chooseItem` -> `选取项`
现在这个英汉词典数据还蛮给力的, 实测中暂时没有发现重名情况.

@flyingghost 多谢宝贵建议!

关于 0, 基本同意. 个人估计用户群还是很大的, 应该在万级以上.

> 按层级翻译（比如类名 > 方法名 > 变量名）。细节实现就放着好了。层级设置可控就更好了。

很同意. 其实之前还做了一个 Java 实现的对 Java 源码进行层级翻译的服务: https://zhuanlan.zhihu.com/p/45236358 主要难点是源码分析. 那个服务基于 Roaster, 它支持类 /方法 /变量的分析(实现细节除外), 这已经可以做到层级可控, 但问题是扩展到其他语言工作量较大(即使用 antlr4)

> 对于命名的翻译，一定别忘了借鉴下划线、驼峰等天然分词符。人家都帮你分好了不用白不用。

应该已经实现了, 如`loadData`->`加载数据`, `gtk_window_set_default_size`-> `gtk_窗口_设置_默认_大小`

> 仅针对快速阅读理解来说，注释的重要性远大于源码实现细节。

嗯, 但这个插件项目现在是很简单的直译, 暂未发现 JS 的机翻库, 与第四点一同恐怕要慢慢积累技术(命名本身也存在上下文问题, 如 #29 指出的)才能接近句级别翻译.

> 一定要做语法解析，至少做到词法解析吧。源码这种东西，千万不能按文本处理。

上面那个 Java 源码翻译服务做了. 这个插件暂时倚靠的是在线代码网站本身的解析(直接挖它 HTML 中的代码段, 进行直接的词级替换. 所有高亮都用的相同 CSS 规则). 除了关键词之外, 命名部分和自然语言的机翻有何区别呢? 能想到的就是方法名更倾向于动词短语, 类 /变量名更倾向于名词短语, 还有吗?

@beny2mor 做过调研, 发现在线翻译服务的代码翻译结果不大好:
https://zhuanlan.zhihu.com/p/44169542

@HeiXiaoBai 不好意思 #50 那句话是对 @bbbai #44 的回应

@no1xsyzy
翻译质量肯定有很大改进空间 #11
没有使用任何在线翻译服务, 用的是另一个离线英汉词典插件: https://chrome.google.com/webstore/detail/%E7%A6%BB%E7%BA%BF%E8%8B%B1%E6%B1%89%E8%AF%8D%E5%85%B8/ndifefelacmidghjaehmhicbchbidhpe