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

[cy476571989]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[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]

超厉害

[lazzyboy]

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

[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 的赞助。
同时，翻译这个事情，也不一定就是纯粹的付出，自己也是会有收获的。比如你会对那个技术，框架本身，有更深入的理解。