@tamlok 多谢. 之前错以为没有这样的中文编程入门书籍. 好像比之前发现的那本日语命名的日文编程译著更早: https://www.v2ex.com/t/498973#;
刚略看了一下, 感觉太侧重算法导致代码中命名优势体现的不大明显. 个人更倾向于入门书中的示例以更接近日常生活的题材为好, 之前试写的 Java 上手: https://github.com/program-in-chinese/java_in_hours_chn

@iRiven
@ccpp132
@fox0001
关于第六点, 主要出发点是, 当前义务教育部分仍然是中文授课所有传统学科. 在编程使用中文是更能将编程和传统学科结合教学的方法. 对于我的情况, 想让下一代更多使用中文(在英文环境中), 需要利用所有可能方式使他们亲身体验到中文的用途.

可以参考日本最近才出的小学编程教育指导: "它山之石-日本推广编程中使用日语命名的渊源" https://zhuanlan.zhihu.com/p/47128031
另外, 这也牵涉到中文知识库的搭建: "初步尝试将传统学科的内容程序 /数据化" https://zhuanlan.zhihu.com/p/47807062

@youngxu
@liuyanjun0826
@woostundy
@buhi
@fuyufjh
无以为报 唯有化压力为动力继续改进功能:

https://www.v2ex.com/t/503451#reply6

@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 规则). 除了关键词之外, 命名部分和自然语言的机翻有何区别呢? 能想到的就是方法名更倾向于动词短语, 类 /变量名更倾向于名词短语, 还有吗?