翻译审核流程

[greyli]

考虑实行下面的审核流程，欢迎提出改进建议。

首先对一个翻译进行一个大概的质量判断，根据翻译准确度和行文流畅度，给翻译划分质量等级：

• low：基本含义翻译错误，排版混乱，语句不通畅
• medium：没有翻译错误，排版正确，语句基本通畅
• high：没有翻译错误，排版正确，行文流畅

分别使用对应的标签进行标记，并采取相应措施：

• high：审核优先级高。鼓励翻译更多章节
• medium：审核优先级中等。委婉建议优化和改进翻译后的措辞流畅度，比如不必完全直译
• low：审核优先级低。不再接受后续翻译请求。如果质量非常差，而且给出审核意见后改进意愿很低，可以考虑关闭 PR

P.S. 目前只有我和 @frostming 在做审核工作，如果你的英语足够好，欢迎帮忙审核已经提交的 PR。另外我也会尝试邀请翻译过旧版本 Flask 中文文档的作者。

[rosekc]

大概有几点想法

• 引入字幕组类似的初翻-润色流程。对于刚翻译完的文档不必过于严格要求，可以先合并到临时的分支，将 review 工作留到后面润色。
• 翻译词汇讨论与投票 #12 中的翻译投票需要落实到词汇表，将常见词汇的翻译和上下文落实到文档中。这个工作应该在润色前完成，接着在润色中统一翻译的风格。
• 建立翻译聊天群组，可以更快跟踪进度，提问也可以更快解决。

[greyli]

对于刚翻译完的文档不必过于严格要求

我看有的翻译问题还是挺大的，还是拒绝后续翻译比较好，避免带来更多的审核工作量。我更倾向于审核合格后再合并。

翻译投票需要落实到词汇表

是的，不过我暂时还没时间做。

建立翻译聊天群组，可以更快跟踪进度，提问也可以更快解决。

聊天用 Discord 吧： https://discord.gg/NXeRDwQrYA

[greyli]

似乎添加 quality: medium 和 quality: high 的意义不大，或许可以直接简化为两个：

• open for future contribution
• close for future contribution

或者更进一步，直接简化为单个标签：

• close for future contribution

[greyli]

标签 quality: low 替换成了 close for future contribution。

三个标签分别改成了：

• 这是你的 last dance
• 翻译质量有待提高
• 我看好你哦

[FesonX]

@greyli 之前参与过掘金的翻译计划，翻译、校对、审核都是可认领的任务 xitu/gold-miner#4238

[greyli]

@greyli 之前参与过掘金的翻译计划，翻译、校对、审核都是可认领的任务 xitu/gold-miner#4238

谢谢，我去参考下。我的想法是校对/审核不用认领，直接 reivew 提交的 PR 就可以了，每个人都可以 review。欢迎帮忙一起审核！

[greyli]

在用户提交的翻译被评估翻译质量之前，不再接受该用户新的章节认领请求。

[Sefank]

首先感谢 @greyli 以及各位参与翻译项目的大佬们所做的贡献，我看到其实许多内容已经大致有了翻译，但是由于还没走完review的流程导致pr还没有合并，这里想问一下：

严苛的审核流程是否有必要坚持呢？换句话说，是不是应该考虑采用类似“敏捷开发”的模式，先上线再行修改？

我个人的观点是：库文档的翻译可能不适用于正经出版物的翻译流程，应该先追求“有”，然后再追求“好”，这可能也更符合开源社区的发展理念？

理由：

• Flask 作为一个快速发展的开发框架，其文档变动也相对频繁（至少与目前翻译跟进的速度相比更加频繁）。如果文档与实际功能不匹配的话，翻译的文档反而更容易造成困惑，故我个人认为这类框架的文档的时效性是翻译工作中需要考虑的一个重要因素。
• 目前来看文档翻译项目是社区性质的，应该属于 Unofficial Translation。我个人认为 Unofficial Translation 和官方文档有部分“翻译差异”应该是可以接受的。如果十分在意准确性的话，对没有经过严格审查的翻译内容可以采取标注“以原文为准”或类似字样的措施？

[greyli]

@Sefank 感谢建议！你的理由我能够理解，我也希望能够实现敏捷翻译，但现实情况稍微没那么理想，比如有些翻译包含代码逻辑上的错误，而不是翻译水平上的差异，这些需要修正后才能合并。接下来对于内容上没有逻辑错误，翻译水平尚可的 PR，我们会尝试尽快合并。

我也很想加快翻译进度，但是审核需要花费很多时间，最近基本都是 @FesonX 在 reivew，我也只是帮忙复审，所以进度比较慢。