文档翻译流程 (Translation Workflow)

Flutter 中文文档翻译流程

任务总览文档：https://shimo.im/sheets/KaUjqukvcZciKQ4A/N4Aax （已暂停使用）

项目参与总流程

1. Fork 本项目
2. 在 Issue 区 认领翻译/校对
3. 完成翻译/校对
4. 发 Pull Request
5. （可选）到 PR 区 协助发表评论和建议

翻译任务认领

1. 查阅 Issue 区，查看待翻译任务，可以通过任务时间和文档类型等 Label 过滤任务。
2. 确定自己的时间和内容预期之后，留言提出要认领这个任务，并给出预计完成时间。
3. Maintainers 一般会在 24 小时之内回复，得到回复确认之后，任务认领成功。

进行翻译

本项目所有涉及英文到中文转换的部分均称为 翻译，但不包含文档顶部的 元数据。

为了保证统一的阅读体验，我们定义了自己的信、达、雅：

技术内容的翻译并非是在“考察”英文能力，最重要的实际是中文表述能力。优秀的译者会准确理解英文内容，揣摩原作者希望给读者传达的要素，然后用中文准确无误又不失优雅的表述出来。 所以，请：

慎用谷歌翻译

虽然数量不多，但谷歌翻译已经属于「人人皆可访问」的谷歌产品之一， 但我们期望你的翻译是一个创作过程，自行分析词句的构成，写出英文大略意思和表示，然后你借助任意翻译工具做验证，再对翻译文稿中的专有名词和术语做搜索和研究，最后再将自己对这句话的理解输出并提交。

文明且客观地使用书面用语

我们翻译的内容是开放给所有人的，读者当中可能有开发者、有设计师，有刚入门的萌新，也有驰骋江湖的前辈。因此，坚持一个公认的标准非常有必要，我们希望每一位译者可以以一份公共出版物的心态来对待交付的文档翻译结果，语言力求得体、准确、客观、简洁和生动。

排版要求

文字排版

我们推崇这份常见的 中文文案排版指南 (Chinese Typography Guide)，其中提到了一些增强网站气质的排版指南，比如中英文之间需要加入空格，标点符号的用法，正确的专有名词引用，等，我们 fork 的版本增加了「全角 / 半角括号」部分的统一认知。

Markdown 翻译排版

非常感谢雪狼对本翻译项目的支持，我们为网站加入了中英文对照的功能，即点击文档的中文则显示英文原始文档，以方便读者进行英文内容核实和提出翻译建议等。原理其实是一个逐行的 markdown 文本扫描脚本，当脚本检测到英文的时候，会按照一定格式检测下一行看其是否有中文翻译，如果有，则加入，如果没有则跳过，详见：文档翻译格式 (Translation Spec)。

我们的重点是翻译创作的结果，格式上的问题请不要吝惜你的提问，我们非常乐意回答。

翻译提交（commit 和 Pull Request）

在确认自己翻译的内容正确并自查完成后，按照 git commit 规范进行提交，提交需要注意以下事项：

• 请确保细粒度的提交，尽可能做到一个 commit 只作用于一个文档
• 确保 commit message 清晰明了

将相关 commit 提交至自己 Fork 的 Git 仓库后，发起 Pull Request。PR 过程中注意以下事项：

1. 一次 PR 尽量只包含一个文件
2. PR 标题格式：

[完成翻译] 路径/文件名.md（请复制路径名，如 src/docs/***.md）， 如：PR 标题示例

3. PR Message 内容格式：

[完成翻译] 路径/文件名.md

Resolve #Issue编号

如：PR message 内容示例

校对

所有无法达到 reviewer 期望值的稿件会被提出要求校对， 无人校对的稿件将会被退稿重新翻译，连续三次被退稿的译者将不得再参与本次翻译任务。 谢谢你的付出，但是请谅解和尊重大家的时间。

合并 (Maintainers)

文档必须要有 Approval 才能进行合并，请在通过前尽可能地仔细检查，并确认所有的 suggestion 都已一一对应。

在合并文档时，请使用 "Squash and merge" 将所有请求合并为一个。 标题依照 PR 标题格式，内容清空或只留下有关的协作者信息。

参考 https://github.com/cfug/flutter.cn/commit/54d3e0192408c660b19f1eb2f0ad7103109b7974