为此,Breword技术翻译小组对Koa的最新版本进行了翻译,并对照源码进行审校,确保最大程度上的理解无误。html
点击这里查看Breword翻译的 Koa中文文档node
与其余译文版本相比,咱们采起了一些不一样的翻译策略。如下仅列举几点加以说明,也欢迎你们在评论区进行讨论。git
其余版本的翻译:app.proxy 当真正的代理头字段将被信任时github
Breword的翻译:app.proxy为true 时,代理的头部字段将会被解析。api
这里trusted,咱们没有直译成“被信任”,而是意译成“被解析”。服务器
其余版本的翻译:app.subdomainOffset 对于要忽略的 .subdomains 偏移[2]cookie
Breword的翻译:app.subdomainOffset计算.subdomains时须要忽略的偏移量[2]app
文档对subdomainOffset进行了举例说明。假设域名是"tobi.ferrets.example.com"。若是app.subdomainOffset没有设置,也就是说默认要忽略的偏移量是2,那么ctx.subdomains是["ferrets", "tobi"]。less
其余版本的翻译:app.context 是从其建立 ctx 的原型。您能够经过编辑 app.context 为 ctx 添加其余属性。这对于将 ctx 添加到整个应用程序中使用的属性或方法很是有用,这可能会更加有效(不须要中间件)和/或 更简单(更少的 require()),而更多地依赖于ctx,这能够被认为是一种反模式。dom
Breword的翻译:app.context是ctx的原型。想要给ctx添加更多的属性,你能够修改app.context。这对在ctx上自定义一些能在app全局使用的属性和方法很是有用,并且性能高(不使用中间件)、更简单(更少使用require())。不足的地方在于过多依赖ctx,这可能被认为是反模式。
其余版本的翻译:
overwrite 一个布尔值,表示是否覆盖之前设置的同名的 cookie (默认是 false). 若是是 true, 在同一个请求中设置相同名称的全部 Cookie(无论路径或域)是否在设置此Cookie 时从 Set-Cookie 标头中过滤掉。
Breword的翻译:
overwrite:布尔值,表示是否覆盖先前设置的同名cookie(默认是false)。若是设置为true,设置的cookie会覆盖同一请求里的同名cookie(不管路径或域名是否相同),即头部字段Set-Cookie会过滤掉以前设置的cookie。
其余版本的翻译:根据 ? 获取原始查询字符串。
Breword的翻译:获取原始查询字符串,这个字符串不带有?(即?以后的查询字符串)。
void of的意思就是“不带有”。
其余版本的翻译: 使用 ? 获取原始查询字符串。
Breword的翻译:获取原始查询字符串,这个字符串带有?。
这里的“with”,意思不是“经过什么工具”,而是“带有”。源码里也对这个字段进行了说明。
response.flushHeaders()
Flush any set headers, and begin the body.
其余版本的翻译:刷新任何设置的标头,并开始主体。
Breword的翻译:清空(Flush)任何已设置的头部字段,并开始把body发回到客户端。
为了更好地理解这个字段,咱们查阅了node.js的官方文档关于request.flushHeaders()的说明。
因此对应地来看response.flushHeaders(),意思就是服务器不用等待body,能够先发送头部字段到客户端,再发送body。
咱们在github上创建了一个仓库,用于存放Breword翻译的开源文档。欢迎star。 Breword/awesome-sync-to-Chinese