关于翻译的统一画风问题

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

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


 

基本规则

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

语法通则

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

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

其他暂时没有,遇到再说~😀

“关于翻译的统一画风问题”的一个回复

发表评论

电子邮件地址不会被公开。 必填项已用*标注