我做了一个网站，用来翻译开源技术文档，有兴趣吗？

[cy476571989]

你想参与翻译开源项目技术文档吗?

大家好，我做了一个名叫 Breword 的网站，专门用来翻译 Github 上开源项目的技术文档。

Github 上面有很多优秀的开源项目，但是它们的中文文档翻译质量参差不齐，而且更新地不及时，很多时候中文文档会落后项目的代码很多个版本。

Breword 的出现，就是为了解决这些问题。

在 Breword 上, 你只需输入 github 项目的地址，后台程序就会自动抓取该项目的文档下来。

之后，我们会调用 Google Translate 的机器翻译 API，预先生成文档的机器翻译结果，同时提供一个可视化编辑器，译者只需在机器翻译的结果上进行修改。经过我们的内部实验，google 提供的机器翻译结果，非常具有参考性，这意味着，译者只需专注在长难句的修改上即可，大大提高翻译效率。

页面翻译完后，可以提交审校，与 Github 一样，所有人都可以审校译文、评论。审校通过后，由项目管理员合并。

待主要文档（次要文档都可以删除，不必翻译）都翻译完成后，可以点击发布，Breword 提供托管服务，会自动将项目文档转换成一个文档网站，提供页面间导航栏和页面内导航栏，同时在右下角可以切换文档语言及版本。

发布后，后台监测程序会实时检查源项目是否有更新，更新后，会比对原文，高亮出译文中相应的修改的地方，方便译者翻译文档的更新部分，以便尽早能够发布更新的译文文档。

以上是 Breword 目前的主要功能，目的是帮助开发者，译者更高效的翻译文档，同时提高可维护性。

欢迎大家试玩，提出宝贵意见，一起翻译更多的文档，推动国内开源运动的发展。

Breword 网站地址： https://www.breword.com

已经发布的项目文档的地址： https://docs.breword.com

对这个项目感兴趣或有建议的，欢迎勾搭： [email protected]

[cbangchen]

翻译完之后的内容，网站本身是否有拥有或者使用的关系，怎么保证。这些最基本的，不解释，能有人用才见鬼了。

[cy476571989]

@cbangchen 谢谢你的提问，我本质上是想模仿 Github 的方式来翻译文档，翻译完之后的文档会部署在 Breword 的网站上面，同时，你也可以下载翻译后的文档，部署在自己的服务器上。后面会提供类似 Sponser 的功能，由阅读文档的读者自愿赞助，争取能够实现一个良性循环。

[PhxNirvana]

1L 是问如何取得授权以及授权的许可范围。。那我顺便问一下译文的所有权和使用权好了

[shiny]

非常棒，前段时间想翻译 async.js 的文档，正有这些痛点。

[cy476571989]

@PhxNirvana 现在没有考虑到授权、版权相关的问题，因为都是开源的，想的是尽可能的开放，而且，你自己创建的翻译项目，所有注册用户都可以给你贡献翻译，本质上是协作翻译，目的是更好的促进国内开源运动的发展，以及让我们国内的技术不要一直落后国外很多。至于其它网站的抄袭啥的，如果能够帮助到更多的开发者，那也挺好的。Linux 内核几千万行代码都是开放的，我们为啥要封闭自己呢？

[cy476571989]

@shiny 谢谢，有兴趣咱们可以一起翻译，后期会做 赞助 类似的功能，希望能够给参与翻译的译者一定的物质回报，形成一个良性循环。

[turtlekey]

很好的项目呀！没事我也来翻译翻译。哈哈。

[Liutos]

有种维基百科的感觉~

[arjen]

支持一下

[MoccaCafe]

谷歌翻译 API 好像是 100W 字符 20 美刀，楼主是如何解决这个费用呢？有免费调用的途径吗

[cy476571989]

@MoccaCafe 没有，: (, 其实问题也不大，100 w 可以翻译很多文档，也值了，关键是它的翻译质量还挺有参考价值的。内部亲测，确实能够提高翻译效率。

[cy476571989]

@turtlekey 欢迎，只有更多的人来翻译，在翻译中学习，咱们国内的技术力量会越来越强大。👍

[cy476571989]

@arjen 谢谢，可以来一起翻译啊。

[1ver]

赞，希望论文也有这种多人贡献翻译的，最近做毕设自己看英文的真的累

[chihiro2014]

说点个人意见，不喜勿喷。
关于翻译这块，个人以为第一是要有技术深度的人参与，并不是随便一个人就能参与的，毕竟你要为后来者负责。放着一个错误的翻译，如果不及时更新，其实就很容易出现问题。
第二翻译者的英文功底必须到位。至少，开个玩笑，你也得有大学 6 级的程度。纯靠谷歌翻译，那需要人来做什么。

其实如果国人能做的话，早就做了，不会这么多年，这方面连点消息都没有。我们国内的 IT 落后不是没有原因的，某种意义上来说，从根里面烂掉了。讲的内容依然是几十年前的东西，然而国外都在讲最新的内容。这样下去，本来只差几十年，后面可能就是几百年。
如果从历史角度出发，04 年的时候，我们国家其实和国外差距不大。但是 04 年之后到现在，我们国内出来的大神几乎没有，都是凤毛麟角系列。
而且最近看了 B 站上搬运的很多国外大学的视频，再看看国内学习的视频，同样是本科，我们学的是个啥？？？人家都在写基础库，我们这帮人都在学啥？？？
顺带推荐下我个人比较喜欢的宝藏 up 主，你也可以去关注下，B 站可以去搜 simviso 官方 这个频道
上面很多的内容都不错，而且翻译国外课程的字幕里面都有注解，方便理解

[Hallujah]

如果是完全开源的，免费给技术人员彩月文档用那就非常好了，必须要顶一下。

[cy476571989]

@chihiro2014 关于 Google translate 翻译的质量，可以点到 breword 网站里面的一个页面去看看便知，默认出现的译文就是机器翻译的结果。因为技术文档本身没有非常多的长难句，所以翻译效果还不错。

关于协作翻译，这就像在 github 上，我们都可以对 linux 内核代码提 pr，但最终能够被合并的是少数，可以被合并的一定是整个项目社区都认可的代码。在 breword 这里是一样的道理，整个翻译社区的 review 力量，可以过滤掉低质量的翻译，项目管理员最终决定合并谁提交的翻译。即便项目管理员也不行，合并了劣质的翻译页面，发布后还会受到整个读者群体的监督。所以，我认为协作翻译文档这条路是可行的。

最后，国内开源技术这块做得不好，这不应该阻止我们做一些事情，让它变得更好，毕竟，落后就要挨打。唯有通过追赶，最终成为领头羊，掌握话语权，我们的后代才能有好的生活。

[renmu]

我觉得这个项目倒是很不错，解决了两方版本不同步的问题，国内初级开发者以及爱好者还是非常多的，大家都会倾向于寻找母语的资料和文档（毕竟看起来舒服多了）。

但是作者授权和翻译文章的使用权及使用权问题是肯定要解决的，大家还是很看中这个方面的。

之前有看到有个中文站机翻各大文档，还标榜自己是第一个中文文档，特别让人恶心

[cy476571989]

@renmu 嗯，我自己在工作的过程中，也发现很多同事都会看中文文档，用百度搜索资料，即便是我认识的一个朋友，上外英语专业的，转行写代码，还是更喜欢看中文文档，毕竟没有大脑转换的消耗。而且对于新项目就更是这样，一些新的概念，直接看英文文档会直接一头雾水。比如: 有个前端库叫 redux-saga, 这个 `saga` 当初硬是没明白啥意思。

[ooo000]

很多技术文档更新比翻译要快，可能前一版本的翻译还没完成，新版本英文文档已经发布了。

[cy476571989]

@ooo000 嗯，是的，这种情况，我们还是只能先把当前抓取的版本翻译完，等发布后，再去拉取新的版本，主要一个是为了支持提供翻译文档的多版本，另外就是让每个版本的翻译能够有一个 deadline, 不能无限制的在一个翻译版本，一直不停的加新内容。

[darluc]

👍👍👍

[chihiro2014]

不得不说，如果能坚持下来，其实还行。坚持不下来，其实我们只是不断地循环往复这个轮回= =。这种事情不是靠一个人就能解决的，以前做过 Galgame 汉化相关的内容，大家一开始都很有激情，但是做到最后，鸟兽四散。
对于开源翻译文档这个来讲，也是啊。毕竟能坚持下去的人很少。慢慢就没动力了。
你看，Rust 文档小组，前段时间都被说的解散了，其实就是这个道理

[himself65]

目前有 N 多个翻译网站，而且面向 i18n 的更多，但看了一下您的网站竞争力可能不强
而且翻译网站生态，不管是哪个网站都是个大问题。有水平的直接看英文，没水平的都是读别人写好的文章，实际上我不太看好所有这些文档翻译网站

[himself65]

@chihiro2014

也不能称之为解散吧

Refs:

- https://blog.rust-lang.org/inside-rust/2020/03/27/goodbye-docs-team.html
-https://rust.cc/article?id=f54278cf-e742-48fa-9831-0dfca8cc435a

文章最后一段

> As such, this blog post isn't really announcing the end of the docs team as much as it is describing what is already true today. I will still be doing my work on core, and the book. And I plan on submitting some more docs PRs in the future.

[chihiro2014]

@himself65 所以我才说，说的被解散，实际并没有解散啊，不过其实意义都一样的。因为就一个人在努力，但周围人无动于衷，只是挂个名字。就拿 Q 群来讲，靠一个群主苦苦支撑活跃，最后还是不得不面临解散的情况，或者死群

[chihiro2014]

@himself65 个人我也感觉很难看好，做这块内容真不是英语好就行，没有专业基础打底，很难翻译的好。之前看人翻译 Spring 框架的文档，虽然质量很高，但是其实真没啥人看的，而且其实造成现在这种局面，我觉得 CSDN 啥的也难辞其咎吧。你抄我我抄你，剩下想找资料的时候遇上的都是错误的东西，这个就很坑爹了
https://www.simviso.com/doc/spring-framework-5.2.x-cn/

[KousukeSakurako]

超厉害

[j137tt736CExzlfM]

底部 Translations powered by Breword 有问题或者建议，请联系： [email protected] 这句话可以删掉，不知道的人看到底部还以为是这篇翻译文章的维护者邮箱地址呢。

[sunriz]

不如想办法怎么学好英文。。不管是什么语言的资料，第一手都是最有价值的吧。
说到这我倒是有个想法，如果一个网站上能同步原版的文档，并且开放给读者批注的功能，可以是自己总结的重点之类的，可以形成笔记，别的用户可以在下面评论。这样大家都能讨论交流，英语不好的人，也可以结合查翻译慢慢理解。因为是很多人讨论的，应该和比一个人翻译出入少些，也把阅读理解做了

[yunye]

这个东西啊，感觉挺好，下次翻译文档时试试。另外，要是翻译 CSS 框架文档这类需要效果演示的，有什么解决方案的吗？

[woncode]

支持，我觉得楼主网站最大的作用，是有效地协助翻译过程，让那些有能力翻译和愿意帮助他人的牛人，能够更轻松地完成翻译。

而不是像有些人所想的靠它推动中文翻译界，这难免给它加太重的担子了，导致大家容易质疑它。

[woncode]

另外，提一个建议，当完成翻译后，可以加一个直接向原 github 仓库提 pr 的功能，把文件直接交会项目库，因为项目本身才是最大的用户流量源头，用户一般都是先搜到项目首页，然后才找到文档，那让用户直接在项目仓库上找到中文文档，这才能让翻译最容易得到用户的阅读

可以在文档页尾加入翻译来源，即楼主的网站，这样就能给网站导流，使得项目本身和楼主的网站能够良性的互相促进发展

[xuanwu]

翻译一下 API 命名，更有长远价值，投入还相对少的多。
之前的相关设想，中文 API 文档浏览器： https://github.com/program-in-chinese/overview/issues/165

[wangxiaoaer]

@MoccaCafe 机器翻译能跳过代码和标签吗？

[dashuizhuyu]

支持

[reus]

英语学不会吗？为什么要看翻译？谁能保证原文更新了，翻译也能跟上？

[qof3990]

@chihiro2014 我们国家 it 不落后吧，最多是桌面端落后，移动端是和美国 top2 啊。而且移动端占了互联网流量的八成。
行业从业人数有多少，决定行业上限有多高。我们国家程序员人数已经突破两百万稳坐世界第二，仅次于印度啊，大大超过美国 100 万，甚至和全欧洲持平。当然，如果把英语圈程序员都加起来是没法比。不过就又变成了世界上只有两个国家的问题。¯\_(ツ)_/¯
我不是说嘴臭啊，新闻要多看数据，那些哀叹我国落后的资讯也要把情绪化的东西剔除一下再吸收，对吧∠( ᐛ 」∠)_
当然，国内做底层设计的少，应用的多，这是个时间问题。只要坚持下去，我们的底层设计也会跟上的。就比如这些翻译网站。他们就是 it 界的基础设施。我国基础设施大跃进不也是在加工制造业挣钱之后才开始的吗。朱军加油💪💪💪

[jinliming2]

如果是 Google 翻译，我为啥不直接用 Chrome 右键直接翻译或是浏览器装扩展，反而到第三方找是否有这个文档的翻译，找到的还是 Google 翻译的……
Google 翻译虽说准确度还行，但对于部分语法，翻译出来的结果含义会与原文完全相反，而这时如果人工英语水平不行的话，就完全看不出问题所在了……
人工如何保证实时性？毕竟纯 Google 翻译就不太可能有用户，没有用户就没有热情上去贡献人工翻译，所以第一步是如何先在贡献者比较少的情况下，把大量主流项目的高质量人工翻译先放上去吸引用户。但这一步如何做到？
这不像正常的开源项目那样，用到的人肯定会写代码，能力弱的提 issue 找人帮忙，能力强的直接自己改了然后提 pull request / merge request，毕竟是自己用到的项目，改个 bug 、加个功能是对自己有益的。

但毕竟开源不给钱，懂英语的不需要翻译所以没动力，不懂英语的没能力翻译，英语水平一般的翻译结果质量不能保证……

[cy476571989]

@chihiro2014 你说得很对，关键是坚持，毕竟谁都需要吃饭。后面会考虑在读者那端，能够给项目参与译者一些类似 Sponser 的赞助。
同时，翻译这个事情，也不一定就是纯粹的付出，自己也是会有收获的。比如你会对那个技术，框架本身，有更深入的理解。

[cy476571989]

@lazzyboy 不好意思，造成了误解，这个目前最主要是为了引流，后面会在文档的 header 部分，显著位置放上这一个页面译者的个人公开信息，比如用户名，邮箱等等。

[cy476571989]

@sunriz 翻译后的文档网站，现在已经支持中英文切换、多版本切换，关于批注，笔记，评论的功能，这些已经被我们提上了日程，正在开发当中，此外，还有搜索、文档与代码片段的对应、Playground 等等，后面这些功能都会有。我们对读者端非常重视，最在意的就是如何能够提高读者阅读技术文档的效率，如何帮助开发者提高技术能力。希望可以持续关注 Breword 。

[cy476571989]

@woncode 谢谢你的建议，我已经记录下来了，不仅如此，还计划在 pr 中包含所有参与译者的信息。欢迎继续关注 Breword

[cy476571989]

@wangxiaoaer 可以的。

[cy476571989]

@jinliming2 感谢你的回复，google translate 对于简单句子的翻译准确率还是挺高的，问题最多的其实是技术专有名词，比如 node.js ，很多会直接用 node, 而 google translate 就只会翻译为 `节点`（对于这种，目前 breword editor 提供了全局替换的功能，处理这种情况很方便）。在 Breword， 译者真正的翻译过程，是在机器翻译的基础上进行修改，调整，修改机器翻译得不好的地方。

[xy2401]

我今天居然做做一样的。不过是简单的脚本。没能力做这个网站。支持支持

[xy2401]

现在是还不支持下载吗？

[cy476571989]

@xy2401 单页的下载正在开发中，整个项目的译文下载还有 bug, 本周内肯定会上线，希望持续关注，一起交流。下载功能上线后，在项目主页，你就可以直接下载页面，等到所有译文发布后，类似 github, 所有原文，译文会打包为一个 tar 包，供下载所有的文档。

[hjdtl]

如果你有一个 idea，你分享到 v 站，很大概率的情况是，被反对，而不是提出有用的建议...
我觉得这个东西挺好的，有问题可以一起讨论解决嘛
真实佛了

[qof3990]

@hjdtl 符合真实世界概率，大多数人是成功不了的，失败的久了，自然就认为大多尝试都会失败。进而认为就应该失败，不应该成功。否则岂不是证明了自己的无能。

[jin7]

@hjdtl #49 的确 不管什么东西放到这里都会被喷

[zzzzzzggggggg]

掘金好像在做这个事情？

[cabing]

赞一个。

[augustheart]

寒假在家看 asio 文档，然后突发奇想拿起笔自己翻译（写在纸上，顺便练字）。
然后发现一个问题：翻译一份文档的工作量就相当于做个平台了……

[rillhu]

不错，我也一直在尝试在个人博客里翻译，不过时间太有限了

[youxiachai]

真不是当年 oschina 干的事情吗。。。

[kdxcxs]

@reus 即使是读得懂英语有中文的话效率也会提高一点的吧，就像尤大自己说的，有良好的中文文档是 vue 成功的一个原因

[Rackar]

这个项目很赞啊。想参加

[cy476571989]

@zzzzzzggggggg 掘金的翻译计划是基于 github 的 pr 流程，而且直接修改 markdown 文件，翻译的同时还得处理样式，最关键的是，它专注的是技术文章，而不是开源项目文档，类似于技术新闻。

[cy476571989]

@Rackar breword 网址：www.breword.com ，希望一起交流。

[cy476571989]

@augustheart 是的，翻译文档蛮考验人的，最基本的是你需要对那个技术本身足够了解，不了解，你也理解不了文档在说啥，更别说翻译了，所以，翻译的同时，自身的技术能力也能得到极大的成长，还能将自己的理解分享出来，帮助更多开发者，岂不妙哉！

[wssy]

有机会的参与一下。
楼主加油!

[find456789]

支持 支持

[find456789]

建议你的网站 可以支持 github 直接登录

[gladuo]

改革的正道是用老版的文档 finetune 一下现有的通用翻译模型，精细化一下代码、术语、api 的识别，让机器翻译的翻译质量更好，手工的翻译工作量大而杂，终究不是未来

[kajweb]

还没细看，不过提供以下建议。
1 、建议左侧原文，右侧译文这样显示。

2 、为啥不选择直接在项目上 pr……

[ysmood]

建议先做个问卷调查，看看到底不能阅读英文文档的程序员的比例，我估计很少，大学毕业就需要 4 级英文了，英文文档一般都浅显易懂。
我也很赞同授人以渔的观念，或许多花些时间到技术相关的英文教育上会更有效，这方面其实也可以有很多开源项目可做的，比如做一个平台用 AI 分析搜集常见的容易误解的技术性英文单词或者句子等等。

[ysmood]

仅仅是我个人的观点：即使给一些外语的技术演讲加上中文字幕都会更促进社区的进步，很多演讲能给人的启发远远大于文档能产生的收益。
另外，不只是英文，有想法的人任何国家都有。

[chaos4fun]

我觉得翻译文档的质量差主要是因为有了 Google 翻译，让没有金刚钻的人也敢揽瓷器活了。

[hbolive]

支持！

[chihiro2014]

@ysmood 国外的演讲虽然好，但大部分人只是看看。看过也就看过了，不会去思考落地的。就拿 Java 来讲，都知道 Spring 好，现在国外都在推荐使用相应式开发，mvc 要被淘汰，但大部分国人还是固步自封 ing

[charlie21]

不同领域的东西可以互相淘汰吗，想 “淘汰” 想疯了吧

[zhenizhui]

印记中文不是干过了这个事了吗？

[cy476571989]

@kajweb 目前 editor 翻译的模式是光标 hover 到那个句子上面，弹出 popup 弹窗，里面是原文。后面会让 editor 支持多种原文、译文的对照模式，让译者能够自由选择。
关于在项目提 PR, 我们重点是自己开发了 editor && 机器预翻译，可视化编辑，这些是 github 现在不支持的，至于文档托管，后面会支持项目管理员自己可以下载译文下来，放到自己的仓库里面，自己托管。

[sofm]

建议和官方项目合作，把自己的翻译放上去整合。
使用 gitbook 合作翻译，github 上静态资源托管，不需要造轮子。
翻译最大的问题是，翻译人员要对项目各 api 很熟悉才行。这样的人不好找，况且还没有报酬，只能作为爱好，默默为社区做贡献，很难得。

[cy476571989]

@sofm，嗯，后面会考虑跟 GitHub 开源项目的维护者合作，帮助把他们的项目翻译为中文文档。

[aureole999]

@cy476571989 DeepL 的翻译目测比谷歌的还好，可以试试

[xiaomimei]

支持！

[xiaomimei]

github 登录 +1

[yearliny]

每次这种类型的帖子总有会那么多人说学英语，我就想说那些人是不是没看过翻译的中文文档，是不是没看过带字幕的美剧和日剧，全都是先学语言在看的。

这个东西是肯定有需求的，翻译成中文肯定是有利于传播的。

[imlinhanchao]

类似印记中文？

[cy476571989]

@aureole999 谢谢推荐，试玩了一下，确实很棒，我会在 breword 里尝试的。

[cy476571989]

@imlinhanchao 看过印记中文这个产品，breword 跟他估计出发点都差不多，但是到后面，会发展得截然不同，我会把 breword 这个产品经营好，感兴趣可以一起交流。

[tension2012]

我觉得完全没有必要做这个事情,你去看看即使国人写的开源项目,里面的变量命名,依然都还是英文的,如果遇到问题了,去 github 上提问,也依然需要英文, 英文对于程序员来说,其实也是一种门槛

[xmlf]

记得上学时老师说过的一句话，个人非常赞同：你自己觉得会了，不是真的会。只有你能把你所学的讲出来教会给别人才是真的会，更是对自己的知识的一次总结和提炼。
楼主，加油！

[heraclitusq]

1. 想法不错。如果能 PR 进原项目就更好了。
2. 前景不好。原因有两点，一是大环境。英语越来越普及，只能看中文文档的 IT 从业人员会逐渐地减少。从个人小环境出发看，投入产出效益低。有能力翻译项目的专业 IT 从业人员可以把翻译的时间用在更加能够创造价值的研究和生产活动中。
粗想一下，大约大学生会比较想尝试下这类活动。不过也必然导致翻译水平参差不齐，十有八九烂尾。

[cy476571989]

@xmlf 谢谢，赞同你的看法，能用通俗语言把一个技术讲明白，才说明你真的懂了，翻译恰恰就是这样一个过程。

[Rackar]

@cy476571989 测了一下。rst 的转换为了 md，但是还是只找到了一篇文档，其他的没有导入和翻译。https://www.breword.com/projects/5e8b30975c7e97001b22f62f

[mara1]

@cy476571989 ,有个想法，目前是鼠标悬浮出英文，可不可以直接把英文展示出来，这样看文档的人，也会慢慢对照着熟悉英文。 不知道楼主觉得怎么样

[cy476571989]

@mara1 嗯，会支持多个翻译浏览模式，现在 review 页面用的就是左右分屏的 原文、译文对照的方式。会考虑给 editor 这边也加上，如果大家觉得这样方便的话。

[metrxqin]

作为一名软件工程师，连阅读技术文档都需要依赖别人的翻译成果，应该找找自身原因。

[mydearxym]

很有意义的项目，希望能支持 github 登陆 +1
可以试试给一些有名气的国外项目 README 里面提交一个 badge 之类的链接试试 : )

[GrayXu]

很有意义的项目，母语阅读的速度和理解完全不一样。（为防有人说英语水平云云，表示考了托福 GRE

[JerryCha]

建议首屏改为以下内容的蓝底黄字：

重 要 通 告

本站不对翻译成品之质量负责。



量起来以后招一批英语好的养老程序员，专门从事人工润色工作，提供有偿服务

[necodba]

不知道有没有人，为啥我看到这个思路第一想法居然是嗯，此处应该点个 star…

[cy476571989]

@mydearxym Github 登录正在加紧开发中，马上会上线，谢谢关注。

[cy476571989]

@JerryCha Breword 的初衷之一就是要持续输出高质量的中文文档，读者端会增加评论，点赞功能，同时依赖于社区广泛的 review 机制，相信可以过滤掉低劣的翻译。

[cy476571989]

@GrayXu 是的，深表赞同，毕竟生活在国内的人来说，没有一个英语的语境，导致即便英语能力本身不错，再看英语文档时，仍然会有大脑思维转换的负担，特别是再又遇到一些生僻词的时候...

[cy476571989]

@metrxqin 翻译文档 && 写博客，从作者的角度而言，本质上都是对自己技术理解的一个输出，分享。我们都会看别人写的博客，为啥对翻译的技术文档嗤之以鼻呢？当然，翻译质量有高低之分，但是，更好的解决方法是，去促进高质量的翻译的输出，过滤掉不好的翻译，这些都是我们技术人员力所能及的事情。

建议你可以去 breword 尝试翻译几篇文档，就会知道我所言非虚。

[xiaotianhu]

看起来学好英语才是正道啊.
靠这种翻译站提升技术就是野路子.

当然 lz 做的事儿还是很好的.支持一下.