3.0 KiB
签署 CLA
按照社区的要求,贡献者需要签署 CLA。
目录结构
主仓库文档的译文建议放到 en 文件夹下对应的目录,英文的目录树应当与中文的目录树一致。SIG 成员会有专人去进行审核。
文档的类别
为了避免开发者对各类文档的混淆,这里简单介绍一下区别。
规范(Specification)一般是技术类文档,比如,如何编译软件,如何翻译文档……
政策(Policies)一般是管理类文档,偏向于章程或纲领,比如,社区的理念,社区的组织架构……
规则(Rules)一般也是管理类文档,偏向于守则或规章制度,比如,代码的版权,讨论问题的礼仪……
命名规范
如果目录有空格则全部用短横线“-”隔开,文件名有空格用下划线“_”隔开。
查重
翻译前请先查阅文档库和搜索引擎,看看是否已有文档的译文。这里有2种情况。
(1)中文版是初始版本,已有相应的英文译文。
(2)英文版是初始版本,中文版是从英文翻译而来。
如果是情况(1),目前文库里已经有了一篇译文。此时你如果提交 PR 可以有 2 个方案。
(1)给原文打补丁,对原文进行修改。
(2)提交新文档。
插图的路径
译文中的插图应当放置在译文同级目录的 assets 文件夹,不要与译文并列存放。引用图片时使用相对路径“./”。这样做的好处是:如果上级文件夹被修改,引用图片的路径不会失效。
插图里文本的翻译
如果条件允许,建议将插图中的中文界面换成英文界面,重新截取。
机器翻译和人工校验
第一,我不反对机器翻译,但是,选择的翻译工具具备可靠性。
第二,人工校对不可缺少,而且,要认真仔细。
译文里的常见问题
1、注意英语中的语法、词性和时态。
差:In order to better manage issues, we divide participants into the following roles:
好:For better issues "management" , we "divided" the participants into the following roles:
2、译文要准确表达原文的意思。 对各项目进行测试。
差:Test projects。
好:Testing of various projects。
3、注意用词的统一。 中文原文里,分类标签应该翻译为“Kind Tags”。这不是对错的问题,是一种约定吧。
标签,这里不翻译为“label”,应为“Tags”。
参与者,出现了“participant”和“contributor”2种译文。
提出,出现了“proposed”和“raised”2种译文。
注意事项
如无特殊说明主仓库指的是docs仓库,副仓库指的是sig-documentation。 一般情况下,爱好者写的教程都会放到副仓库,官方提供的文档则会放到主仓库。但此种情况并不绝对,sig组也会根据写的内容来做出对应的建议。