关于协作

[imknown]

1.3 要正式版了... 占个坑先... 方便后续讨论... (主要是 我怕我自己 忘记了...)

参考:

1. 开源文档翻译的质量保障实践
2. 把command-line-library-js.md翻译成简体中文 #31
3. 优化翻译: Array 的构造函数说明 #34

[hltj]

我也备注下之前整理的一些其他东西：

工具使用

• 请使用 Intellij IDEA（社区版就够用）编辑 markdown 文件（如果只是改错别字，github 在线编辑亦可）
• 代码提交之前一定要看 diff，自行校对

对于初次翻译的要求

• 务必阅读术语表（目前是草稿）。但术语表未能涵盖所有用语，最好已经读过大多数已翻译章节，避免术语分歧。
• 建议每次只翻译一节，不建议翻译过大篇幅。但为了避免断章取义，尽量通读整篇后再翻译。
• 确保每句话首先经过谷歌或者搜狗机翻（不要参考其他家的）。
  机翻前请将原文多余换行替换为空格。因为无论谷歌还是搜狗，都不会跨行翻译一句话。
  机翻可能在专业术语和一些专业逻辑上有严重不足，不过它们的好处是通常对英文惯用句式、惯用语比较了解，也不容易漏词。而专业术语和专业逻辑正是我们比较熟悉的，以机翻为参考来翻译通常不容易出错，但不要完全照抄机翻。
• 如果遇到某一句不确定如何翻译，可以保持英文。这样 review 的人或者其他读者看到可以补充翻译。
• 代码中的注释也翻译，除了 //sampleStart、//sampleEnd 不要翻译，这个是 Kotlin playgroud 需要用到的特殊注释，需要保留原文。
  在 Kotlin 中文站/英文官方站的代码示例里，默认会把 //sampleStart 之前、//sampleEnd 之后的代码隐藏，这样来突出代码的主要部分。
• 行级对照翻译——即中文译文与英文原文的行都一一对应，如果这导致中文从非标点符号地方断开，请使用 HTML 注释——其中 <!-- 放在上一行尾，-->放在下一行首。
  这是为了在官方源站更新时便于合并（不易出冲突，出现冲突也容易解决）。
  注意： 如果在句号、逗号、分号、问号、叹号、右括号、右引号等标点处换行以及在中西文之间自换行，那么不用加 HTML 注释。

这里西文包括单词和数字。

翻译的要求

• 热情与耐心
• 一定的技术基础与英文基础。
• 熟悉 markdown 语法，了解 jekyll 语法。
• 能够区分正文与代码：代码非注释部分保持原样，行文与代码注释部分都需要翻译。
• 正文或代码注释部分一律用中文标点符号。
• 中西文词语之间要留空格，中文与 ` 之间留空格。
• 中文标点与西文之间不留空格。
• 英文表示并列关系的逗号，在中文中要用顿号。

一些小 tips 与注意点

• you/your/we/us 等有时需要将对话语气转为客观描述语气。不要在译文中使用 您，通常用到 you 的原文都可以译为省略主语的中文，如果实在不能省略，请使用你。
• A, B, C and D 翻译为 甲、乙、丙与丁。
• and 尽量不要译为 “和”（偏口语），常见译法有 与、及、以及、并且、并、且、而。and other ... 通常 以及其他……。and 有时也不译，直接逗号断句。
• example 尽量译作 示例 而不是 “例子”，同样是前者更偏书面语，后者更偏口语。
• never 有时译为 决不 会比 从不 更通顺。
• from 有时译为 在……中 比 从…… 更好。另外也译为 来自、源于。
• the 有时也要翻译，这时翻译为 该、其 等。
• 被动语态翻译更好方式：变被动为主动（有些翻译成忽略主语的主动式），另外有些英文词语对应中文的主动与被动表意差异不大，这时可直接用主动语气表示。
• 过去分词翻译辅助有：已……的、受、所。
• while 在子句首，可翻译为 同时、而等。
• specific 指定的，特有的，具体的；given 给定的。
• To do sth. , ... 可能表示 “要做xxx” 或者 为做xxx。表示前者含义时，译为 如需 XXX，可 ……通常会比 “要 XXX，……” 更自然。
• allow 不一定总翻译成 允许，很多情况都可以译为 让 XXX 可以/能够……、支持 ……——对于这种情况，通常中文都不用 “允许” 一词，试想一个大活人凭什么需要一个事物“允许”？更多的是表达有了这个东西，大家多了一种选择。
• one or more/one or multiple 以为 一到多个比 “一或多个” 更自然。
• 机翻时可能会把 if 条件句式翻译为 “如果……则”，应该纠正为如果……，那么或者如果……就，若采用偏文言形式，则用若……则。
• 如果有些英文单词不译，那么需要注意要在译文中采用原形形式，比如 volatiles 要改用 volatile。

[hltj]

不翻译术语表（草稿，完善中，欢迎补充&修订）

注意：单个词汇（非短语）术语不译时，需保持其原形形式，例如原文的 futures，在译文中应该为 future）

英文	描述
list	当指 List 时，其他场景通常译为列表或者列出等
set	当指 Set 时，其他场景可能译为集合或者设置等
map	当指 Map 时，其他场景可能译为映射等
future	其他编程语言中 future 概念，如 Java 的 Future
promise	JavaScript 的 Promise
Kotlin/Native	native 单独使用时通常译作原生，而作为专有名词 Kotlin/Native 时不译
framework	当指苹果平台的 framework 时不译，其他场景译为 框架
artifact	构件，因与“构建”同音，拼音输入易出现错别字，可以保留不译
getter	属性读取方法
setter	属性写入方法

翻译术语表（草稿，完善中，欢迎补充&修订）

英文	中译	描述
Early Access Preview	抢先体验预览
evaluate / evaluation	求值	通常用于表达式求值时表示 求值，如 lazy evaluation 惰性求值
experimental	实验性的	本站采用实验性的，因此不要译作试验性的
feature	特性	本站译为特性，因此不要译为功能
functionality	功能/功能性
functional programming	函数式编程	不要译作 功能性编程
function	函数	大多数场景下 function 都是函数的概念，不要译作功能，不要译作方法
method	方法	究竟译作函数还是方法，取决于原文用词
delegate	委托	不要译作代理
proxy	代理	究竟译作委托还是代理，取决于原文用词
range	区间	与数学上的闭区间概念类似，不要译作范围
scope	作用域	不要译作范围
declare / declaration	声明
define / definition	定义
constructor	构造函数	也称构造器，不过本站统一取构造函数
check	检测	当含有“判断是否符合某种条件”之意时译为 检测 而不是 检查
inspect	探查
native	原生/ native	“Kotlin/Native”不译，其他译作原生或者原生平台
primitive	原语/原生类型	这里的原生类型指 Char、Int、Double 等基本类型，如果用作协程相关上下文中，通常表示原语
raw type	原始类型	这里的原始类型指（Java 中）忽略泛型的类型
progression	数列
builder	构建器	不要译作构造器
build	构建/构建项	动词通常译为 构建，名词为 构建项（表示 构建过程 除外）
compilation	编译项
dependency	依赖项
Kotlin Koan	Kotlin 心印	Koan 不要译作公案
suspend function	挂起函数	suspend 本站统一称挂起，因此不要译为暂停
lambda	lambda 表达式	多加上“表达式”三个字；本站将 lambda 与 lambda expression 均翻译为 lambda 表达式
null safety	空安全
nullable / nullability	可空的/可空性
non-null	非空的
parenthesis / parentheses	圆括号/括号	不要译为小括号
bracket	方括号	不要译为中括号
brace	花括号	不要译为大括号
open parenthesis / bracket / brace	左圆/方/花括号
close parenthesis / bracket / brace	右圆/方/花括号
infix function	中缀函数
contract	契约	“契约式设计”/“契约式编程”的契约，不要译为合同
destructure	解构
string interpolation	字符串内插
operator	操作符	之所以不译作运算符，是因为 Kotlin 中有些操作符并不是运算符，比如 iterator、getValue 等
extension	扩展	不要翻译成拓展
receiver	接收者	词根辨析：receive 接收，accept 接受
variance	型变
invariant / invariance	不型变	用于泛型场景，本站取不型变（其他地方可能译作不变）；而在 native 文档中可能表示不变式
covariant / covariance	协变
contravariant / contravariance	逆变
artifact	构件	本站采用构件，因此不要译作工件 。那么口语跟“构建”怎么区分？——“构件”读作“构件儿” 😃
target	目标/目标平台/面向	当指“目标平台”时，做名词翻译为目标平台，做动词翻译为面向……或者以……为目标平台
top level	顶层	指顶层作用域，如顶层函数、顶层协程
see ... for	关于……请参见……
read ... for	关于……请参阅……
refer to ... for	关于……请参考……
inference	推断	不译作推导的原因是，编程语言特性“列表推导”（虽然 Kotlin 无此特性）中的“推导”对应的是 comprehension
override	覆盖	本站选用覆盖，因此不要译作重写
overload	重载
backing field	幕后字段
assign(ment)	赋值	通常表示赋值，不要译作分配
reassign(ment)	重新赋值/重复赋值
pipe	管道
pipeline	流水线
pipe stage	流水线阶段
supervision	监督
task	任务
job	作业
explicit	显式	显式类型、显式指定等场景不要译作明确
inherit	继承/承袭	在类继承、父子线程等场景中译作继承，其他场景可译作承袭
extensible/extendible	可扩展的
scalable	可伸缩的	对应 scalability 为可伸缩性，不要译作可扩展
common module	公共模块	本站采用公共，因此不要翻译为通用
interaction	交互
interop / interoperate	互操作
mangling / name mangling / name decoration	名字修饰
block	代码块	大多数情况 block 指代码块，如有少数其他情况可译为块
runtime	运行时
continuation	续体
continuation passing style	续体传递风格
coroutine intrinsics	协程内建函数
repository	版本库/仓库	通常都是用于代码版本库，译为 版本库。如果用作“数据仓库”等其他场景，可译为 仓库
DCE (dead code elimination)	无用代码消除	本站采用 无用代码消除，不要译为 死代码消除
compile-time	编译期	不要译为 编译时
qualifier	限定符
for example	例如	不要译为 比如、譬如
paradigm	范式	programming paradigms：编程范式
boilerplate code	样板代码	有时，单独一个 boilerplate 也译为 样板代码
project	项目	不要译为 工程 ，IDEA 等中文语言包也是用 项目，这也与 Visual Studio 等其他 IDE 一致
reactive	反应式	不要译为“响应式”（响应式 web 词源 responsive），其词根 reactor 意为“反应堆”
source set	源代码集	谷歌 Android 中文文档用此译法，因此不用源集/源文件集
application	应用程序	英文用全写，中文也用
app	应用	英文用缩略，中文也用
XXX specific	XXX 特有的	不要译为 特定于 XXX 的 如 platform-specific 译为 平台特有的 而不是 特定于平台的
top-level	顶层	不要译为 顶级
trailing commas	尾部逗号
argument	实参
parameter	形参
review	审阅，评审

[imknown]

推荐一个 Microsoft 术语集, 仅供参考:

https://www.microsoft.com/zh-cn/language

[hltj]

推荐一个 Microsoft 术语集, 仅供参考:

https://www.microsoft.com/zh-cn/language

手欠搜了个协程 😂

[imknown]

@hltj coroutine 翻译成 协同程序 和 协同例程 啦, 估计是 协程 的 全称吧. 维基百科搜 协同程序 也会跳转到 协程... 好不统一...

[hltj]

@imknown 嗯，微软大多数翻译的挺好的，只有个别的有些问题

[imknown]

@hltj 分享一个 微软翻译的 新闻 https://m.ithome.com/html/395344.htm 🤣

[hltj]

@hltj 分享一个 微软翻译的 新闻 https://m.ithome.com/html/395344.htm 🤣

我之前看过，不过必应的翻译还是不行，没有谷歌的好，也没有搜狗的好

[Shadowell]

有没有认领任务表？任务如何分配？如何协作？

[hltj]

有没有认领任务表？任务如何分配？如何协作？

目前没有按照任务领取方式，主要是考虑两点：

1. 《对于初次翻译的要求》中也有提到，不鼓励一次翻译过多的内容，不便于 review、校对。而如果一次翻译内容不多的话，不按照领取方式也不会有太多重复劳动的浪费。
2. 避免领取任务长期不能完成，而其他人不便参与。基于这一点，建议不只初翻，其他情况也都按照小步快走方式。

这里协作主要指不同人翻译如何保持一贯风格，以及 review、校对别人翻译时的参考。