关于翻译的统一画风问题

首先这个翻译并不是开源翻译，根据将来的捐赠收入，大家会得到补偿（可能不多

其次作为贡献者你自己翻译的爽是前提。

基本规则

• 首先你会得到这个博客的一个作者帐号，用这个号在这个博客发布你的翻译，正在翻译的章节请使用“保存草稿”功能持续更新。——你保存草稿我能够看到，这样我就知道你占了哪个坑，翻译了多少。
• 添加代码使用编辑器第一行最右边的 <> 按钮，默认语言就是 Swift，很方便。
• 原文当中的所有代码都要按照原缩进格式放到代码块里，代码内容不翻译，代码注释暂不翻译。
• 英文原句的句号位置不要改变，即保持原句格式。由于翻译需要，逗号就随意了。
• 原文中的格式不要改变，即引用还是要引用，斜体还要斜体，括号要括号。
• 原文中的灰色字体，即行内代码块不翻译，但要保证全部都会出现在正确的位置，同时使用代码块中的行内选项来添加同样的行内代码块。
• 原文中的灰色标题对应翻译中的二级标题；每一章的章节名称请写到文章名称里不要写在正文哈。
• 黑色标题则是对应翻译中的三级标题。
• 发布文章的时候记得选择 Swift 分类下的自翻分类哈。
• 另外翻译不懂的可以参考开源翻译版本，但我个人推荐尽量从原文翻译，有不懂的留言给我~
• 上一行的要求之所以会存在，是因为我们要避免出现类似抄袭的问题。
• 原文中的链接不要添加，在链接内容上加下划线，整体看起来像是这样： 这里有个链接（此处应有链接）  等第二次精翻的时候我统一给加，加括号里的字是为了到时候方便检索。
• 遵循传统定义，我们对“参数”使用更严谨的形参和实参的区分： 其中 parameter 译为形式参数； argument 为实际参数；

语法通则

虽然我最终都会校译和校对，但还是希望大家能够按照一定的标准来进行翻译，目前能想到的有如下几点：

• 构造器：根据原文命名，用初始化器更贴切一些，名词形式则对应 初始化
• 可选类型：可选的问题这样规定，optional 为 可选 ； 而 复数形式则为 可选项，作为形容词的时候我们译为“可选项 a”这样，具体情境大家随机应变
• 可选项的解包、解封：我们使用 展开 来描述
• 嵌套类型： 我们讲  内嵌类型，对应方法什么的也是 nested 为内嵌。
• 权限控制：Access 我们讲  访问，  访问控制。文中所有的 Access 都是访问而不是权限。
• Attributes：特性
• 关于 collection 和 set ，两个都是集合，我们普遍认为前者是集合，为了区分，后者称为合集。
• self-contained 译为 独立
• delegate 代理——我们翻译为“委托”这个更容易理解且好组织词汇。
• Store Properties 译为存储属性，符合工科传统习惯。
• adopted 译为采纳，conform则为遵循；
• type Annotation 译为  类型标注

其他暂时没有，遇到再说~?

本文由 落格博客 原创撰写：落格博客 » 关于翻译的统一画风问题

转载请保留出处和原文链接：https://www.logcg.com/archives/1186.html