关于godoc的中文/多国语言翻译

474 views
Skip to first unread message

chai2010

unread,
Jan 20, 2015, 2:20:57 AM1/20/15
to golang中文小组
目前Godoc的中文翻译在这里:

说实话, 我一直不太喜欢这个翻译的流程:

1. 需要直接在Go的代码上修改, 同步非常麻烦(里面大量的Go代码的变更信息)
2. 以后增加其他语言(比如繁体中文)基本是要从头进行
3. 很多手工相关的操作

因为同步的流程比较复杂, 又引入了更复杂的 gerrit 审核机制
(目前好像只有 @minux 和 @olingcat 2个人在使用).
这样无疑是增加了文档翻译者参与的难度.

我之前想到的比较理想的翻译流程:

1. 基于工具提取Go的包文档, 导出要翻译的文档(gettext/markdown/json之类的都可以)
2. 每个包的文档独立翻译(这样Go), 可以参考包的方式组织目录结构
3. 改造godoc, 支持多国语言的切换
4. 辅助工具用于同步或查漏补缺


最近我 fork 了 godoc, 做了一些调整以支持 多国语言的翻译.
目前已经支持 多国语言的 切换:


翻译文件在这里(目前只有`unsafe`包的简体中文版):


对于普通的翻译用户, 翻译 godoc 的文档就是给Go代码进行填空:

完成后 `go build && golangdoc -http=:6060 -lang=zh_CN` 就可以了.

如果需要, 以后甚至可以做一个 翻译源码 和 markdown 双向同步的工具.
这样的话, 翻译提交后, 可以在 github 上方便地查看翻译成果.

剥离了 Go 官方同步每天几十个CL的同步信息后,
对于 godoc 翻译这种不太复杂的合作,
`pull request` 绝对是足够了.

@minux
@olingcat
@xingxing

--

Oling Cat

unread,
Jan 20, 2015, 3:17:37 AM1/20/15
to Golang-China
我觉得似乎可以，不过能不能把原文和译文放到一起？这样方便校对。
此外我还有些疑问：如果官方文档更新的话要怎么同步？同步后对应的中文要如何更新？
有些翻译其实是要考虑代码的上下文的，这点怎么解决？对照着源码来在这里翻译么？

另外我还是倾向用Gerrit做审校的，首先这个并不复杂，一旦熟悉上手很快；其次评论和更改之间进行对比的功能也比Github的PR强大，还有 minux 也在尝试如何把PR自动转换成CL的方法，这样一来只有审校者用Gerrit就行了。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9nFJgb1oBkg%3Dd%3DbHd%2B%3DZ-x35eTtYX3AqzWiRQc9F80n1Q%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 3:18:08 AM1/20/15
to Golang-China

谢谢对我们目前流程的批评。说实话，我们对目前的翻译方式也不满意。

2015-01-20 2:20 GMT-05:00 chai2010 <chais...@gmail.com>:
目前Godoc的中文翻译在这里:

说实话, 我一直不太喜欢这个翻译的流程:

1. 需要直接在Go的代码上修改, 同步非常麻烦(里面大量的Go代码的变更信息)
2. 以后增加其他语言(比如繁体中文)基本是要从头进行
3. 很多手工相关的操作
目前主要纠结如何同步官方的改动。对于标准库的翻译这个要求不高，因为改动
非常不频繁，而且我基本看每个改动，但是 subrepo 就没那个精力了，而且以
tools 为例，经常是大幅的改动。尤其是他们在开发 refactor 工具，tools 或许是
试验田…… （PS：最近有人提到 alandonovan 开发了一个 sockdrawer 工具 [这
名字真形象！]，可以把一个巨型包拆成小包，而且在 runtime 上试验了一把，
效果惊人，参见 CL 3027。）

因为同步的流程比较复杂
同步确实非常复杂，但是译者是不需要考虑同步的问题的，我们会自己负责同步
上游改动的。显然这个仅适用于 Go 标准库这种很成熟的包。翻译 tools 至今还
是没有任何想法。
 
, 又引入了更复杂的 gerrit 审核机制
(目前好像只有 @minux 和 @olingcat 2个人在使用).
这样无疑是增加了文档翻译者参与的难度.
其实 Gerrit 没增加多少难度，说到底只不过你一个 branch 一个 commit，然后不
push 到 github，而是 push 到 Gerrit 而已。剩下的都是自动的。 

从 Github 换成 Gerrit 的原因主要是，Github 上根本没有办法做真正的代码审核。
比如，你要求一个修改，然后作者改了，往 Pull Request 里加了几个 commit，
你是没有办法合并起来看这个新的 Pull Request 整体和你前一次看到的 PR 上
的差异的。要么你重新看一遍所有文件的差异，要么你看一遍新加入的 commit
的所有 diff，但是看这些的时候，你又看不到以前提的 comment 了。如果时间
间隔较长，你要审核还得先回顾你提了什么建议，然后再看是否根据要求改了。
完全是没效率。

如果你用 Gerrit 就知道什么叫代码审核工具了。Github 那个只是玩具而已……
Go 用 hg 的时候用的 Rietveld 都达不到 Gerrit 的水准。（Android, ChromeOS,
QT, LibreOffice 等巨型项目应该都不是随随便便选 Gerrit 的吧……）


我之前想到的比较理想的翻译流程:

1. 基于工具提取Go的包文档, 导出要翻译的文档(gettext/markdown/json之类的都可以)
我觉得脱离环境（上下文）翻译是不行的。这也是为什么翻译 gccgo 的错误信息，
我坚持为每个错误信息创造实例。译者应该站在读者的角度考虑。

所以，翻译包文档的时候，至少要看着上下文才比较好。或许直接在源代码里翻译
时看到的上下文太多了。然后翻译的时候或许会加入自己的理解。比如原文是：

The time taken is a function of the length of the slices and is independent of the contents.

执行时间是切片长度的函数，并且与切片内容无关。

看了底下简短的实现，或许会翻译成：
执行时间是切片长度的线性函数，并且与切片内容无关。

但是，这里”线性“函数就译者自己加的，虽然是对的，但是是不符合翻译的原则的。
（觉得原文不够清晰的，最好是直接给上游提交 CL，这里就体现出用 Gerrit 的另
一个好处了……）

其实社区还有一个包文档的翻译，比我们的要全得多，他是直接翻译 godoc.org 渲
染的 HTML。从上下文的角度看是恰到好处，因为最终读者也看的是同样的内容，
但是如何同步新的改动是个问题。

2. 每个包的文档独立翻译(这样Go), 可以参考包的方式组织目录结构
恩。赞同。
 
3. 改造godoc, 支持多国语言的切换
恩 这个比目前在前端切换语言要强。我们确实没有考虑过多国语言的支持，反正
我们只关注简体中文。
 
4. 辅助工具用于同步或查漏补缺
恩 最核心的问题就两个：
(1) 如何同步上游的改动，同步改动需要知道如下信息：原有的英文，现在的英文，
原有的中文，然后改中文。
(2) 翻译的时候需要有恰当的上下文。

我最理想的翻译方式是，翻译 godoc 输出，又程序自动处理同步和整合到源代码里。
但是这个显然和多国语言支持不兼容。除非我们引入一些 godoc 扩展，比如

// en: english comment here
// zh: 中文注释
// xx: xxxxxx

最近我 fork 了 godoc, 做了一些调整以支持 多国语言的翻译.
目前已经支持 多国语言的 切换:


翻译文件在这里(目前只有`unsafe`包的简体中文版):


对于普通的翻译用户, 翻译 godoc 的文档就是给Go代码进行填空:

完成后 `go build && golangdoc -http=:6060 -lang=zh_CN` 就可以了.

如果需要, 以后甚至可以做一个 翻译源码 和 markdown 双向同步的工具.
这样的话, 翻译提交后, 可以在 github 上方便地查看翻译成果.

剥离了 Go 官方同步每天几十个CL的同步信息后,
对于 godoc 翻译这种不太复杂的合作,
`pull request` 绝对是足够了.
我还是觉得用 Gerrit 对译者没有太多的负担，还是 git commit, git push，甚至还简单些，
因为不需要去打开浏览器点击 Send Pull Request 然后再写一个理由；但是对于审核者
的帮助巨大，比 Pull Request 好。 

@minux
@olingcat
@xingxing

xnotepad

unread,
Jan 20, 2015, 3:42:53 AM1/20/15
to golang...@googlegroups.com
额，看来尝试翻译的人还不少啊。我也说一下我的思路啊：

通过工具提取包的所有的文档到doc_zh.go, doc_tw.go等文件中，
通过md5码与原英文文档相关联，这样在更新时可以很容易找到
哪一部分需要重新翻译。
这样不需要修改go的所有源代码，而且doc_zh.go本身内容都是注释，
也不会影响编译，只需要少量修改godoc，就可以切换语言。



--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9wrWnUNUVaEcGN25%2Bh6MQj29bY8r5kC23Y9JmKv4_-zGA%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 20, 2015, 3:43:00 AM1/20/15
to golang中文小组


在 2015年1月20日 下午4:17，Oling Cat <olin...@gmail.com>写道：
我觉得似乎可以，不过能不能把原文和译文放到一起？这样方便校对。
可以放到一起(目前也是在一个包):

用 各种 diff 工具就可以比较2个文件. 

此外我还有些疑问：如果官方文档更新的话要怎么同步？同步后对应的中文要如何更新？
有些翻译其实是要考虑代码的上下文的，这点怎么解决？对照着源码来在这里翻译么？
辅助辅助工具自动提取最新的文档, 更新 unsafe_origin.go 和 unsafe_translated.go .
godoc 都是 api 的使用说明, 代码的上下文是没多少帮助的.
实在不行可以看 godoc.org 吧. 


另外我还是倾向用Gerrit做审校的，首先这个并不复杂，一旦熟悉上手很快；其次评论和更改之间进行对比的功能也比Github的PR强大，还有 minux 也在尝试如何把PR自动转换成CL的方法，这样一来只有审校者用Gerrit就行了。
这个是另一个问题了, 和翻译文档的组织方式没有冲突.
目前不评论, 只是保留个人看法了. 

PS: 最强大的工具不一定是最合适的工具.

chai2010

unread,
Jan 20, 2015, 4:01:02 AM1/20/15
to golang中文小组
在 2015年1月20日 下午4:17，minux <mi...@golang.org>写道：

谢谢对我们目前流程的批评。说实话，我们对目前的翻译方式也不满意。

2015-01-20 2:20 GMT-05:00 chai2010 <chais...@gmail.com>:
目前Godoc的中文翻译在这里:

说实话, 我一直不太喜欢这个翻译的流程:

1. 需要直接在Go的代码上修改, 同步非常麻烦(里面大量的Go代码的变更信息)
2. 以后增加其他语言(比如繁体中文)基本是要从头进行
3. 很多手工相关的操作
目前主要纠结如何同步官方的改动。对于标准库的翻译这个要求不高，因为改动
非常不频繁，而且我基本看每个改动，但是 subrepo 就没那个精力了，而且以
tools 为例，经常是大幅的改动。尤其是他们在开发 refactor 工具，tools 或许是
试验田…… （PS：最近有人提到 alandonovan 开发了一个 sockdrawer 工具 [这
名字真形象！]，可以把一个巨型包拆成小包，而且在 runtime 上试验了一把，
效果惊人，参见 CL 3027。）
是这个问题. subrepo 基本是没有翻译的动力了(同步很麻烦). 

因为同步的流程比较复杂
同步确实非常复杂，但是译者是不需要考虑同步的问题的，我们会自己负责同步
上游改动的。显然这个仅适用于 Go 标准库这种很成熟的包。翻译 tools 至今还
是没有任何想法。
同上. 
 
, 又引入了更复杂的 gerrit 审核机制
(目前好像只有 @minux 和 @olingcat 2个人在使用).
这样无疑是增加了文档翻译者参与的难度.
其实 Gerrit 没增加多少难度，说到底只不过你一个 branch 一个 commit，然后不
push 到 github，而是 push 到 Gerrit 而已。剩下的都是自动的。 
自动的前提是要先学会如何提交Go 的代码.
大家觉得这个流程难度如何呢... 

从 Github 换成 Gerrit 的原因主要是，Github 上根本没有办法做真正的代码审核。
比如，你要求一个修改，然后作者改了，往 Pull Request 里加了几个 commit，
你是没有办法合并起来看这个新的 Pull Request 整体和你前一次看到的 PR 上
的差异的。要么你重新看一遍所有文件的差异，要么你看一遍新加入的 commit
的所有 diff，但是看这些的时候，你又看不到以前提的 comment 了。如果时间
间隔较长，你要审核还得先回顾你提了什么建议，然后再看是否根据要求改了。
完全是没效率。

如果你用 Gerrit 就知道什么叫代码审核工具了。Github 那个只是玩具而已……
Go 用 hg 的时候用的 Rietveld 都达不到 Gerrit 的水准。（Android, ChromeOS,
QT, LibreOffice 等巨型项目应该都不是随随便便选 Gerrit 的吧……）
我承认gerrit功能很强大. 但是也有很多人不使用preview评审工具.
用 gerrit 的问题和Go迁移到github的原因是一样的.
别人已经熟悉了github的流程, 不想再学一套.
github上用gerrit的估计也没几个... 


我之前想到的比较理想的翻译流程:

1. 基于工具提取Go的包文档, 导出要翻译的文档(gettext/markdown/json之类的都可以)
我觉得脱离环境（上下文）翻译是不行的。这也是为什么翻译 gccgo 的错误信息，
我坚持为每个错误信息创造实例。译者应该站在读者的角度考虑。

所以，翻译包文档的时候，至少要看着上下文才比较好。或许直接在源代码里翻译
时看到的上下文太多了。然后翻译的时候或许会加入自己的理解。比如原文是：

The time taken is a function of the length of the slices and is independent of the contents.

执行时间是切片长度的函数，并且与切片内容无关。

看了底下简短的实现，或许会翻译成：
执行时间是切片长度的线性函数，并且与切片内容无关。

但是，这里”线性“函数就译者自己加的，虽然是对的，但是是不符合翻译的原则的。
（觉得原文不够清晰的，最好是直接给上游提交 CL，这里就体现出用 Gerrit 的另
一个好处了……）
对于gccgo的翻译, 有上下文和代码当然是理想的.
但是对于 godoc 中 api 的翻译, 上下文就没什么价值了. 

其实社区还有一个包文档的翻译，比我们的要全得多，他是直接翻译 godoc.org 渲
染的 HTML。从上下文的角度看是恰到好处，因为最终读者也看的是同样的内容，
但是如何同步新的改动是个问题。

2. 每个包的文档独立翻译(这样Go), 可以参考包的方式组织目录结构
恩。赞同。
 
3. 改造godoc, 支持多国语言的切换
恩 这个比目前在前端切换语言要强。我们确实没有考虑过多国语言的支持，反正
我们只关注简体中文。
如你只关注简体中文的话, godoc 应该也不会做改动吧(毕竟他们只关注英文). 
 
4. 辅助工具用于同步或查漏补缺
恩 最核心的问题就两个：
(1) 如何同步上游的改动，同步改动需要知道如下信息：原有的英文，现在的英文，
原有的中文，然后改中文。
这个都是可以有的. 
(2) 翻译的时候需要有恰当的上下文。
建议直接 godoc 上查看. 

我最理想的翻译方式是，翻译 godoc 输出，又程序自动处理同步和整合到源代码里。
但是这个显然和多国语言支持不兼容。除非我们引入一些 godoc 扩展，比如

// en: english comment here
// zh: 中文注释
// xx: xxxxxx

多国语言放在一个代码中,  绝对是一个混乱的开始....
我打赌, Go的官方也不会认同的.

目前, 我比较希望官方的godoc包能支持翻译的hook钩子:

这样的话, 用户可以灵活地选择(官方的或自己的)翻译包.


最近我 fork 了 godoc, 做了一些调整以支持 多国语言的翻译.
目前已经支持 多国语言的 切换:


翻译文件在这里(目前只有`unsafe`包的简体中文版):


对于普通的翻译用户, 翻译 godoc 的文档就是给Go代码进行填空:

完成后 `go build && golangdoc -http=:6060 -lang=zh_CN` 就可以了.

如果需要, 以后甚至可以做一个 翻译源码 和 markdown 双向同步的工具.
这样的话, 翻译提交后, 可以在 github 上方便地查看翻译成果.

剥离了 Go 官方同步每天几十个CL的同步信息后,
对于 godoc 翻译这种不太复杂的合作,
`pull request` 绝对是足够了.
我还是觉得用 Gerrit 对译者没有太多的负担，还是 git commit, git push，甚至还简单些，
因为不需要去打开浏览器点击 Send Pull Request 然后再写一个理由；但是对于审核者
的帮助巨大，比 Pull Request 好。 
文档翻译毕竟不是Go语言开发, 其实没必须要么严禁的流程.
我觉得最理想的方式是在网页上修改markdown文件, 在网页中预览.
用工具自动同步markdown到其他格式的翻译数据.
太高大上的东西不一定接地气的...

@minux
@olingcat
@xingxing

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 4:10:50 AM1/20/15
to Golang-China
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）

然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）

然后：回答同样的问题。

既然要翻译，那就要尽可能保证一致且严谨。除非是你一个翻译，否则不互相审校是
绝对不行的。

前面的 merge 是个极端的例子，但是你随便看看 Gerrit 上的其他改动，尤其是 Go
官方的（golang.org/cl）。

chai2010

unread,
Jan 20, 2015, 4:18:33 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）
你这个例子恰恰证明了现在的翻译流程很不方便.
而且已经到了影响正常翻译工作的层度.

这个PR里的 99.99% 是官方的代码改动, 是和中文翻译没有任何关系的改动.
为何要关注这些改动呢? 难道只是为了衬托 gerrit 的强大, github PR 的无能?
 

然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？ 

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）

然后：回答同样的问题。
前面的流程问题, 导致了一个新的/不应该存在的需求.
现在这个不应该存在的需求到成了feature了...
 

既然要翻译，那就要尽可能保证一致且严谨。除非是你一个翻译，否则不互相审校是
绝对不行的。
这个我同意.
但是即使没有严禁的审核流程, github 上翻译合作的例子也比比皆是(比如之前的swift的翻译).
gerrit是屠龙刀, 但是用来杀鸡的话屠龙刀也不一定就方便的.
 

前面的 merge 是个极端的例子，但是你随便看看 Gerrit 上的其他改动，尤其是 Go
官方的（golang.org/cl）。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

chai2010

unread,
Jan 20, 2015, 4:22:25 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）

然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）
补充一个问题:
这些改动是你一个人审核呢, 还要请Go的那些官方开发者来审核呢?
总之, 我是不能完全看懂那些改动全部意义的.
是否merge正确我都不能确定.

你就估计下, golang-china 邮件中, 有多少人能做这个 99.99% 改动的审核工作?
又有多少人愿意做这个 99.99% 改动的审核工作?

希望不要回避这个问题.
 

然后：回答同样的问题。

既然要翻译，那就要尽可能保证一致且严谨。除非是你一个翻译，否则不互相审校是
绝对不行的。

前面的 merge 是个极端的例子，但是你随便看看 Gerrit 上的其他改动，尤其是 Go
官方的（golang.org/cl）。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 4:25:17 AM1/20/15
to Golang-China
2015-01-20 4:18 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）
你这个例子恰恰证明了现在的翻译流程很不方便.
而且已经到了影响正常翻译工作的层度.

这个PR里的 99.99% 是官方的代码改动, 是和中文翻译没有任何关系的改动.
为何要关注这些改动呢? 难道只是为了衬托 gerrit 的强大, github PR 的无能?
问题就是这个改动里有翻译的修改，是需要看的。
恰恰就是这 99.99% 的不需要关注的修改掩盖了真正需要关注的内容。


然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？ 

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）

然后：回答同样的问题。
前面的流程问题, 导致了一个新的/不应该存在的需求.
现在这个不应该存在的需求到成了feature了...
不管如何翻译，总是有审核的过程。而且，如何翻译 doc 下的文档？不论如何，
这类 merge 总是需要看的。

chai2010

unread,
Jan 20, 2015, 4:31:15 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:24，minux <mi...@golang.org>写道：

2015-01-20 4:18 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）
你这个例子恰恰证明了现在的翻译流程很不方便.
而且已经到了影响正常翻译工作的层度.

这个PR里的 99.99% 是官方的代码改动, 是和中文翻译没有任何关系的改动.
为何要关注这些改动呢? 难道只是为了衬托 gerrit 的强大, github PR 的无能?
问题就是这个改动里有翻译的修改，是需要看的。
恰恰就是这 99.99% 的不需要关注的修改掩盖了真正需要关注的内容。
99.99% 是你自己创造出来的问题.
用户关心的是Go1.3的中文翻译, Go1.4的中文翻译.
普通用户不关系Go1.3和Go1.4的代码变化的每一个细节. 


然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？ 

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）

然后：回答同样的问题。
前面的流程问题, 导致了一个新的/不应该存在的需求.
现在这个不应该存在的需求到成了feature了...
不管如何翻译，总是有审核的过程。而且，如何翻译 doc 下的文档？不论如何，
这类 merge 总是需要看的。
文档的翻译和Go的开发基本是独立的2个流程.
让翻译流程和开发流程的混在一起是问题的根源.
doc文档的翻译, 以任何一个Go的release版本为基础就行了.
doc文档需要每天跟进每个typo的变化吗?
 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 4:31:53 AM1/20/15
to Golang-China
2015-01-20 4:22 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）

然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）
补充一个问题:
这些改动是你一个人审核呢, 还要请Go的那些官方开发者来审核呢?
总之, 我是不能完全看懂那些改动全部意义的.
是否merge正确我都不能确定.

你就估计下, golang-china 邮件中, 有多少人能做这个 99.99% 改动的审核工作?
又有多少人愿意做这个 99.99% 改动的审核工作?

希望不要回避这个问题.
如果你真的看过 Gerrit 如何展示 merge 你就明白这个问题我不需要回答。

我们不审核官方的改动，所以 upstream 的所有改动都默认是正确的，我们想看
的只是我们在 merge 过程中额外修改的内容（主要是解决冲突），而 Gerrit 展
示的恰好是这部分内容。你 merge 得对不对一眼就能看出来。

如果 merge 一点冲突没有，完美的 auto-merge，那么 Gerrit 会告诉你这个 CL
一行改动也没有。比如这个：
然后看看 github 展示的对应的 commit:

Github 告诉我这个 merge commit 修改了：
196 changed files  with 3,954 additions and 2,756 deletions.

明白区别了么？

chai2010

unread,
Jan 20, 2015, 4:34:26 AM1/20/15
to golang中文小组
没明白有几个人能做这个 99.99% 的审核工作.
而且这个完美的auto-merge恰恰是最没有价值的部分(对于中文翻译来说). 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 4:41:16 AM1/20/15
to golang...@googlegroups.com
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。

当官方释出新的 release-branch.go1.5 分支时，直接在此分支 branch 出新的 chinese-branch.go1.5；而不是从 chinese-branch.go1.4 上 branch。

上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件，然后寻找 1.5 和 1.4 的官方差异更新翻译。

在 2015年1月20日 下午5:31，minux <mi...@golang.org>写道：

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9zC3z8NfdKB2yu-L5rugEFZDN7fNm85DvGp7AeHVkdvNw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 4:42:52 AM1/20/15
to Golang-China
根本没人需要审核这 99.99% 部分。 Gerrit 自动隐藏了 auto merge 的部分。这么明显
为啥你就看不出来呢？我都给你两个区别明显的例子了。

你认为没有价值，那你准备如何翻译 doc/ 目录下的文档？

还是那句话，要是没用过更好的工具，总也体会不到更好的工具的价值。
我知道 Gerrit 是最好的代码审核工具（我用过更好的…… 细节不便说），但是 Gerrit 和
Github PR 相比实在是不言自明的。

文档的翻译和Go的开发基本是独立的2个流程.
让翻译流程和开发流程的混在一起是问题的根源.
doc文档的翻译, 以任何一个Go的release版本为基础就行了.
doc文档需要每天跟进每个typo的变化吗?
我们也没有每天 merge 一次啊。事实上，正是由于 merge 间隔时间太长，才导致
merge 的 diff 过大的。

按照你的意思是，等新版本发布后突击翻译所有内容？那除非是你一个人负责才有希望
按时发布。大家利用空闲时间贡献，都是有一点翻译一点，哪有一下子等发布都来集中
帮你翻译？

chai2010

unread,
Jan 20, 2015, 4:44:48 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:41，Larry Li <larry...@gmail.com>写道：
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。
汉化不针对 master 分支，只针对 release。
这个才真正的汉化流程!!! 

minux

unread,
Jan 20, 2015, 4:45:35 AM1/20/15
to Golang-China
2015-01-20 4:41 GMT-05:00 Larry Li <larry...@gmail.com>:
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。

当官方释出新的 release-branch.go1.5 分支时，直接在此分支 branch 出新的 chinese-branch.go1.5；而不是从 chinese-branch.go1.4 上 branch。

上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件，然后寻找 1.5 和 1.4 的官方差异更新翻译。
那样工作量非常大。我们试过。其实原先的 hg repo 里有 zh-go1.3 这样的 branch，但是我们
不希望等到新版本发布之后再开始翻译所有改动。毕竟翻译者的时间是分散的，不一定能在
release 分支创建之后能集中几天翻译所有新的改动。

手工解决冲突这个步骤如果冲突过大是非常恼人的，不管你用什么工具，而且因为你在 git
merge 阶段，没办法 git commit 来保存中间过程，所以从这里讲也行不通。

唯一的办法是溪水长流，跟踪 tip，过一段时间 merge 一次。 等官方 branch 了，我们也跟着
branch。

chai2010

unread,
Jan 20, 2015, 4:47:30 AM1/20/15
to golang中文小组
我当然是看出来了.
但是你拿auto-merge这种, 不需要审核的代码来说gerrit强大有什么舒服力呢? 

你认为没有价值，那你准备如何翻译 doc/ 目录下的文档？

还是那句话，要是没用过更好的工具，总也体会不到更好的工具的价值。
我知道 Gerrit 是最好的代码审核工具（我用过更好的…… 细节不便说），但是 Gerrit 和
Github PR 相比实在是不言自明的。

文档的翻译和Go的开发基本是独立的2个流程.
让翻译流程和开发流程的混在一起是问题的根源.
doc文档的翻译, 以任何一个Go的release版本为基础就行了.
doc文档需要每天跟进每个typo的变化吗?
我们也没有每天 merge 一次啊。事实上，正是由于 merge 间隔时间太长，才导致
merge 的 diff 过大的。

按照你的意思是，等新版本发布后突击翻译所有内容？那除非是你一个人负责才有希望
按时发布。大家利用空闲时间贡献，都是有一点翻译一点，哪有一下子等发布都来集中
帮你翻译？
Go1.3到Go1.4会有啥变化呢?
就算是有一点变化, 也是可以在其他分支先翻译出来,
等Go的下个正式版本发布都再merge之前的分支的翻译的.

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 4:48:05 AM1/20/15
to golang...@googlegroups.com
上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件。

这个工作确实工作量非常之大。但，这个不是 git merge。只是 patch。patch 不成功是产生中间文件，当前 patch 成功的修改是可以 commit 的。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9yquBb1tLdC%3DcstyOkhGegSYaNZprq9t0UtUrmk5XJAiw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 4:48:16 AM1/20/15
to Golang-China
2015-01-20 4:44 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:41，Larry Li <larry...@gmail.com>写道：
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。
汉化不针对 master 分支，只针对 release。
这个才真正的汉化流程!!! 
用不着用红字强调。你考虑下如何具体操作这个流程。

你有 release-branch.go1.4 上，现在 release-branch.go1.5 出来了。你准备咋做？

请考虑现实情况，你是试图 merge 1.4 到 1.5 是几乎不可能的。而且我们要考虑
的不仅仅是包文档，还有 doc 下其他那么多文档呢。

chai2010

unread,
Jan 20, 2015, 4:48:53 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:45，minux <mi...@golang.org>写道：

2015-01-20 4:41 GMT-05:00 Larry Li <larry...@gmail.com>:
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。

当官方释出新的 release-branch.go1.5 分支时，直接在此分支 branch 出新的 chinese-branch.go1.5；而不是从 chinese-branch.go1.4 上 branch。

上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件，然后寻找 1.5 和 1.4 的官方差异更新翻译。
那样工作量非常大。我们试过。其实原先的 hg repo 里有 zh-go1.3 这样的 branch，但是我们
不希望等到新版本发布之后再开始翻译所有改动。毕竟翻译者的时间是分散的，不一定能在
release 分支创建之后能集中几天翻译所有新的改动。
工作量大的原因是因为你改变了Go的代码, 将中文的翻译和Go代码混乱到一起了.
这是翻译流程不合理导致的问题.
Go本身的api是相当稳定的.
根本就没有多少需要merge的.
 

手工解决冲突这个步骤如果冲突过大是非常恼人的，不管你用什么工具，而且因为你在 git
merge 阶段，没办法 git commit 来保存中间过程，所以从这里讲也行不通。

唯一的办法是溪水长流，跟踪 tip，过一段时间 merge 一次。 等官方 branch 了，我们也跟着
branch。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 4:50:04 AM1/20/15
to Golang-China
2015-01-20 4:48 GMT-05:00 Larry Li <larry...@gmail.com>:
上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件。

这个工作确实工作量非常之大。但，这个不是 git merge。只是 patch。patch 不成功是产生中间文件，当前 patch 成功的修改是可以 commit 的。
问题是这个步骤如何分工？release 间的改动非常大，指望一个人来 merge，不管是 git merge 还是基于
patch，都是不现实的。

chai2010

unread,
Jan 20, 2015, 4:51:59 AM1/20/15
to golang中文小组
操作流程我在开始的邮件就写了.

1. 将翻译和Go的代码库分离
2. 只基于Go的正式版本翻译
3. 用工具自动提取翻译文档

翻译的git库只维护翻译文档的版本.
不涉及Go的开发变化. 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

chai2010

unread,
Jan 20, 2015, 4:52:39 AM1/20/15
to golang中文小组
用工具自动提取出来要翻译的文档, 要翻译的文档根本就没有多大变化!
所有的这些都是因为, 将翻译信息混入到Go代码导致的.
我并不认同这种方式.
 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 4:52:57 AM1/20/15
to golang...@googlegroups.com
patch 会产生 .rej 中间文件，可以把当前 patch 成功的翻译 commit。然后，安排人手处理 .rej 冲突文件。


在 2015年1月20日 下午5:49，minux <mi...@golang.org>写道：

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9yH6Mp2p8J8QArET-XrrQdWJ2Xw1Fw8Osd5EpcHQ0G2zg%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 4:53:26 AM1/20/15
to Golang-China
2015-01-20 4:50 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:47，minux <mi...@golang.org>写道：
2015-01-20 4:44 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:41，Larry Li <larry...@gmail.com>写道：
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。
汉化不针对 master 分支，只针对 release。
这个才真正的汉化流程!!! 
用不着用红字强调。你考虑下如何具体操作这个流程。

你有 release-branch.go1.4 上，现在 release-branch.go1.5 出来了。你准备咋做？

请考虑现实情况，你是试图 merge 1.4 到 1.5 是几乎不可能的。而且我们要考虑
的不仅仅是包文档，还有 doc 下其他那么多文档呢。
操作流程我在开始的邮件就写了.

1. 将翻译和Go的代码库分离
2. 只基于Go的正式版本翻译
3. 用工具自动提取翻译文档

翻译的git库只维护翻译文档的版本.
不涉及Go的开发变化. 
你说了半天只是包，我说了，我们不只考虑包的翻译。
实际上包翻译才算开始阶段，很多都在探索之中。

minux

unread,
Jan 20, 2015, 4:53:26 AM1/20/15
to Golang-China
2015-01-20 4:48 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:45，minux <mi...@golang.org>写道：

2015-01-20 4:41 GMT-05:00 Larry Li <larry...@gmail.com>:
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。

当官方释出新的 release-branch.go1.5 分支时，直接在此分支 branch 出新的 chinese-branch.go1.5；而不是从 chinese-branch.go1.4 上 branch。

上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件，然后寻找 1.5 和 1.4 的官方差异更新翻译。
那样工作量非常大。我们试过。其实原先的 hg repo 里有 zh-go1.3 这样的 branch，但是我们
不希望等到新版本发布之后再开始翻译所有改动。毕竟翻译者的时间是分散的，不一定能在
release 分支创建之后能集中几天翻译所有新的改动。
工作量大的原因是因为你改变了Go的代码, 将中文的翻译和Go代码混乱到一起了.
这是翻译流程不合理导致的问题.
我也说了流程我也不满意。但是除了包文档或许有更好的流程，其他文档怎么办？

我再解释一遍，跟踪主干是为了溪水长流。利用开发 1.5 的时间来翻译 1.5 相对
1.4 的改动。

chai2010

unread,
Jan 20, 2015, 4:56:29 AM1/20/15
to golang中文小组
即使要提前翻译1.5相对1.4的改动, 也没有必要完全记录Go的开发变化.
翻译者只需要在Go1.5正式release之后, 将dev分支的翻译信息合并到正式release的Go1.5就可以了.
翻译者为何非要记录Go的详细的开发变化呢?
 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 4:57:07 AM1/20/15
to Golang-China
2015-01-20 4:52 GMT-05:00 Larry Li <larry...@gmail.com>:
patch 会产生 .rej 中间文件，可以把当前 patch 成功的翻译 commit。然后，安排人手处理 .rej 冲突文件。
但是这依然没有解决开源项目最大的问题。

等你缺人手的时候，没人有时间。导致 1.5 发布，可能过了好长时间才翻译完 1.5。

chai2010

unread,
Jan 20, 2015, 4:58:25 AM1/20/15
to golang中文小组
我目前说的主要是包.
不过doc的翻译, 一样是可以基于release版本翻译的.

而且, 只谈包的翻译, 目前的进展也不大.
我觉得翻译的门槛太高, 不利于参与绝对是一个因素. 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 4:58:27 AM1/20/15
to golang...@googlegroups.com
.rej 不处理并不影响 commit，明白么？

只是翻译不完全。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9yy_za9BG2bJCmKdrKy33uafyJ56%2B822TkfMOmhwDSq6w%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 4:59:33 AM1/20/15
to Golang-China
2015-01-20 4:56 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:51，minux <mi...@golang.org>写道：
2015-01-20 4:48 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:45，minux <mi...@golang.org>写道：

2015-01-20 4:41 GMT-05:00 Larry Li <larry...@gmail.com>:
golang 和 gitlab 一样都采用了 release 分支的开发工作流，即 master 开发然后 release 一个主版本分支，小版本发布直接在 release 分支上。

我在 gitlab 汉化上的实践，目前采用的方案是对每个 release 建立对应的翻译分支。即 release-branch.go1.4 分支有对应的 chinese-branch.go1.4 分支。

汉化不针对 master 分支，只针对 release。

当官方释出新的 release-branch.go1.5 分支时，直接在此分支 branch 出新的 chinese-branch.go1.5；而不是从 chinese-branch.go1.4 上 branch。

上个版本（1.4）的翻译是通过 git diff release-branch.go1.4..chinese-branch.go1.4 然后 patch 到新的 chinese-branch.go1.5 分支。手工解决冲突文件，然后寻找 1.5 和 1.4 的官方差异更新翻译。
那样工作量非常大。我们试过。其实原先的 hg repo 里有 zh-go1.3 这样的 branch，但是我们
不希望等到新版本发布之后再开始翻译所有改动。毕竟翻译者的时间是分散的，不一定能在
release 分支创建之后能集中几天翻译所有新的改动。
工作量大的原因是因为你改变了Go的代码, 将中文的翻译和Go代码混乱到一起了.
这是翻译流程不合理导致的问题.
我也说了流程我也不满意。但是除了包文档或许有更好的流程，其他文档怎么办？

我再解释一遍，跟踪主干是为了溪水长流。利用开发 1.5 的时间来翻译 1.5 相对
1.4 的改动。
即使要提前翻译1.5相对1.4的改动, 也没有必要完全记录Go的开发变化.
翻译者只需要在Go1.5正式release之后, 将dev分支的翻译信息合并到正式release的Go1.5就可以了.
翻译者为何非要记录Go的详细的开发变化呢?

在我们目前的流程里，翻译者是不需要关心开发变化的，所有 merge 是管理员进行的。

我再说一遍，我们根据 tip 翻译，是为了重叠翻译最新文档和开发最新版的时间。不然
5个月没事儿干， 最后一个月一大堆事情是不希望看到的。

chai2010

unread,
Jan 20, 2015, 5:00:31 AM1/20/15
to golang中文小组
在 2015年1月20日 下午5:56，minux <mi...@golang.org>写道：
1.5的doc文档可以手工的方式覆盖到 翻译的dev分支.
1.5的包文档可以用工具自动提取到分页的dev分支.

对于Go的git库来说, 我们只是做了复制/粘贴/覆盖的操作.
但是我们自己的翻译是有版本信息的(但不包含详细的Go的开发变化).

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 5:01:01 AM1/20/15
to Golang-China
2015-01-20 4:58 GMT-05:00 Larry Li <larry...@gmail.com>:
.rej 不处理并不影响 commit，明白么？

只是翻译不完全。
我当然明白。但是你这么做还是我说的5个月没事儿干，最后一个月翻译所有差异。

chai2010

unread,
Jan 20, 2015, 5:04:02 AM1/20/15
to golang中文小组
管理员只是你1/2个人吧.
其他人根本就没机会参与到翻译/合并的流程里来了.
翻译这种合作的事情, 没必要搞像搞那样只有rsc/pike能大牛统一才能进行那样的麻烦.
 

我再说一遍，我们根据 tip 翻译，是为了重叠翻译最新文档和开发最新版的时间。不然
5个月没事儿干， 最后一个月一大堆事情是不希望看到的。
谁没没有说5个月就不允许翻译1.5的文档.
Go dev的分支的翻译对于中文的dev分支, 但是版本没必要完全1:1对应. 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 20, 2015, 5:05:18 AM1/20/15
to Golang-China
2015-01-20 5:00 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:56，minux <mi...@golang.org>写道：
2015-01-20 4:52 GMT-05:00 Larry Li <larry...@gmail.com>:
patch 会产生 .rej 中间文件，可以把当前 patch 成功的翻译 commit。然后，安排人手处理 .rej 冲突文件。
但是这依然没有解决开源项目最大的问题。

等你缺人手的时候，没人有时间。导致 1.5 发布，可能过了好长时间才翻译完 1.5。
1.5的doc文档可以手工的方式覆盖到 翻译的dev分支.
1.5的包文档可以用工具自动提取到分页的dev分支.
本质没区别啊。我们现在译者也是看一个相对稳定的代码库，我们负责解决冲突。 

跟你说的手工覆盖到 dev 分支其实是等价的。我们定期更新我们的 master，就是
同步 1.5 最新的变化。

对于Go的git库来说, 我们只是做了复制/粘贴/覆盖的操作.
但是我们自己的翻译是有版本信息的(但不包含详细的Go的开发变化).

chai2010

unread,
Jan 20, 2015, 5:05:21 AM1/20/15
to golang中文小组
文档的发布没必要完全和Go的发布同步.
再说, 之前已经说了多次了, 1.5的翻译可以提前进行.
但是没有必要和Go的git完全同步(这是所有问题的根源). 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 5:06:12 AM1/20/15
to golang...@googlegroups.com
那当然了，出现 .rej 就说明。你翻译了的东西被官方修改了，需要重新翻译。这本来就是更新翻译的工作。

甚至你翻译的内容正好被官方删除了，或者移动到其他地方。

即使采用其他的方案，这些也是需要 git merge 时要处理的。

使用 patch 的好处在于：默认不处理，采用官方内容，保证原始数据的有效性。

而且，我们可以把有效的工作直接 commit，而不需要等待手工 merge。

在 2015年1月20日 下午6:00，minux <mi...@golang.org>写道：

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9yPERYW5sRZuJC%3DMRyo1b1uDN5qm2R4Npq_tqXuE2YS%3Dg%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 20, 2015, 5:07:36 AM1/20/15
to golang中文小组
在 2015年1月20日 下午6:04，minux <mi...@golang.org>写道：

2015-01-20 5:00 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:56，minux <mi...@golang.org>写道：
2015-01-20 4:52 GMT-05:00 Larry Li <larry...@gmail.com>:
patch 会产生 .rej 中间文件，可以把当前 patch 成功的翻译 commit。然后，安排人手处理 .rej 冲突文件。
但是这依然没有解决开源项目最大的问题。

等你缺人手的时候，没人有时间。导致 1.5 发布，可能过了好长时间才翻译完 1.5。
1.5的doc文档可以手工的方式覆盖到 翻译的dev分支.
1.5的包文档可以用工具自动提取到分页的dev分支.
本质没区别啊。我们现在译者也是看一个相对稳定的代码库，我们负责解决冲突。
非常有本质的区别!

我说的只是doc的复制/粘贴.
包只提取文档部分(而文档基本是不怎么变化的).

我说的文档和文档翻译信息, 和Go的代码是完全分离的.
我们只关系文档和翻译变化. 
 

跟你说的手工覆盖到 dev 分支其实是等价的。我们定期更新我们的 master，就是
同步 1.5 最新的变化。
有本质的区别. 

对于Go的git库来说, 我们只是做了复制/粘贴/覆盖的操作.
但是我们自己的翻译是有版本信息的(但不包含详细的Go的开发变化).

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

Larry Li

unread,
Jan 20, 2015, 5:08:26 AM1/20/15
to golang...@googlegroups.com
是的。官方在 rc 甚至在 alpha/beta 的时候释出新分支，就可以开始工作了。

基于实践经验，rc 再开始会减少很多工作。

如果能忍受一定的延时，最好还是在 stable 后再开始。

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9nABzNHR1F86UaM6_QaS-i79-xPm2-ZSyb9qw%2Bm%2B0KMiQ%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 5:09:48 AM1/20/15
to Golang-China
2015-01-20 5:06 GMT-05:00 Larry Li <larry...@gmail.com>:
那当然了，出现 .rej 就说明。你翻译了的东西被官方修改了，需要重新翻译。这本来就是更新翻译的工作。

甚至你翻译的内容正好被官方删除了，或者移动到其他地方。

即使采用其他的方案，这些也是需要 git merge 时要处理的。

使用 patch 的好处在于：默认不处理，采用官方内容，保证原始数据的有效性。

而且，我们可以把有效的工作直接 commit，而不需要等待手工 merge。
我一直都没否认工作是等价的这个问题，最大的分歧是时间问题。

我认为 1.5 发布之后开发翻译 1.5 是不够的，否则你总是在翻译上一个文档版本，
中文版永远跟不上新版本的发布。

我们追踪 tip，希望在官方发布 1.5 的时候，同步出中文的 1.5.
 

minux

unread,
Jan 20, 2015, 5:11:20 AM1/20/15
to Golang-China
2015-01-20 5:07 GMT-05:00 chai2010 <chais...@gmail.com>:


在 2015年1月20日 下午6:04，minux <mi...@golang.org>写道：

2015-01-20 5:00 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:56，minux <mi...@golang.org>写道：
2015-01-20 4:52 GMT-05:00 Larry Li <larry...@gmail.com>:
patch 会产生 .rej 中间文件，可以把当前 patch 成功的翻译 commit。然后，安排人手处理 .rej 冲突文件。
但是这依然没有解决开源项目最大的问题。

等你缺人手的时候，没人有时间。导致 1.5 发布，可能过了好长时间才翻译完 1.5。
1.5的doc文档可以手工的方式覆盖到 翻译的dev分支.
1.5的包文档可以用工具自动提取到分页的dev分支.
本质没区别啊。我们现在译者也是看一个相对稳定的代码库，我们负责解决冲突。
非常有本质的区别!

我说的只是doc的复制/粘贴.
包只提取文档部分(而文档基本是不怎么变化的).

我说的文档和文档翻译信息, 和Go的代码是完全分离的.
我们只关系文档和翻译变化. 
还是表面的差异。我们只不过采取了把中文放到 Go 代码里的方式，因为最开始目的是我们
不维护自己的 godoc fork，即使要修改，也不做大幅的代码调整。 

Larry Li

unread,
Jan 20, 2015, 5:19:29 AM1/20/15
to golang...@googlegroups.com
gitlab 7.7 的汉化工作


​
patch 7.6 的 diff 到 7.7 默认会有 86 个 rej。

我目前的实践原则是，即使在 7.6 上有汉化不完全的情况。新的 7.7 的释出，工作版本就是 7.7 了。

没有一定的必要，不会在旧的 release 上投入工作量。

处理 rej 比重新审视相关文件更新翻译更加有效。rej 很大程度上是当前工作的 todo。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9zP%2BYhfJa7JBLryf%2BYRa0KBBTni%2BofBWfSh8mGvgdaQFw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 5:25:54 AM1/20/15
to Golang-China
2015-01-20 5:08 GMT-05:00 Larry Li <larry...@gmail.com>:
是的。官方在 rc 甚至在 alpha/beta 的时候释出新分支，就可以开始工作了。
以 Go 1.4 为例，12月11日发布，11月17日建立 1.4 分支，你只有不到
一个月的时间更新。

如果完全翻译完了或许这段时间足够更新所有修改，但是目前阶段，这么
短时间绝对不现实。

基于实践经验，rc 再开始会减少很多工作。

如果能忍受一定的延时，最好还是在 stable 后再开始。

本主题费了这么多口舌，如果用来翻译的话，早就翻译完一个包了。
最近出了非常有意思的 cmd/gc bug (#9634)，我原计划还想花点时间瞧瞧呢……

@chai2010 抛开 Gerrit 和 PR 的问题不谈，你说的包方案可以实践一下。
但是我不喜欢那个格式，我觉得给翻译者的是越少结构越好：

输入文件 [1]:
// ArbitraryType is here for the purposes of documentation only and is not
// actually part of the unsafe package. It represents the type of an arbitrary
// Go expression.
type ArbitraryType int

然后翻译成 [2]:
// ArbitraryType 在此处只用作文档目的，它实际上并不是 unsafe 包的一部分。
// 它代表任意一个Go表达式的类型。
type ArbitraryType

换句话说，翻译的输入应该是命令行 godoc 输出那个样子的。然后用 go/doc
提取和同步翻译，这个我赞成。等于我们有一个目录保存 [1] 那样的输入文件，
然后每个语言单独一个目录放 [2] 那样的输出。

我们可以试试提取所有包的这样的文件进行翻译。

godoc 的改动再讨论。现在我们有自己完全控制的 godoc 服务器，想改哪里
都没问题。

Oling Cat

unread,
Jan 20, 2015, 5:37:21 AM1/20/15
to Golang-China
呃..你们先不要吵，首先我们放下 doc 和 article 文档，因为这个都是大段的文字，很好翻译同步；subrepo 我们目前不管它，因为官方都没定数。然后我们只有 pkg 和 cmd 文档的问题了，于是先列出需要解决的问题：
1. 翻译方式
2. 同步方式
3. 审校方式
4. 多种语言

于是我们针对各点开始讨论。

现行方案：直接在源码里的原文底下添加翻译
优点：godoc 不做修改直接可以提取并展现在网页上，接近官方的文档阅读体验；和官方文档的同步由某几个人进行，对于译者来说，只需找到注释进行翻译即可；对于同步者来说，凡有更新必然提醒冲突，解决冲突的同时就能更新对应的中文翻译。
缺点：对译者使用各种工具的前提要求较高，但熟悉稳定后只需简单地提交CL，根据审校者提出的问题修改即可，也不算缺点。

Chai 的方案：提取官方文档到自己的格式中进行翻译
优点：无需每个人都 clone 整个源码，只需关注自己感兴趣的直接翻译。呈现方式可以多样，
缺点：需要自己维护一系列工具，如：godoc 的修改版用于展现翻译的文档，提取文档并保持更新的工具等。

关于Gerrit CL和Github PR的问题，我们其实不必关注官方的代码，因为 merge 时虽然看起来是一堆，但只有冲突的文件需要更改，所以修改的工作量并不大。但对于现行方案来说，Github 会把所有修改全部摊开，很难让别人审查更新，而Gerrit可以避免这一点，同时按次序列出每次要求的更改或修正。Chai 的方法由于提取了文档，在PR上看起来不会是很大一片，但实际的修改量和现行的方法其实相同。

由于校对会进行很多轮，因此需要有方法来对比每轮之间的差异，Gerrit可以做到，而Github则需要每次都从头看一遍。Gerrit的另一个好处是，可以为每个修改单独提交CL，然后一次 mail 所有的CL，每个CL都能按照需要灵活并入到主代码树中；而PR只有一个，一次PR多个提交的话，每次更新都要记得哪些提交看过确认好了，哪些还没有确认。其实 Chai 的提取文档方法也可以用 Gerrit，二者之间并不冲突。

关于多语言，现行方案是写死在源码里的，因此每种语言要分不同 repo 转换修改一遍；Chai的方法只是看不到源码了，但对于所有的翻译同样也要完整修改一遍。

现在我只是根据自己的理解写了这些，如有遗漏欢迎补充。

2015-01-20 17:31 GMT+08:00 minux <mi...@golang.org>:

2015-01-20 4:22 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月20日 下午5:10，minux <mi...@golang.org>写道：
觉得 github PR 好的，去试图审核一下
（打开之前，确保你有足够的空闲内存）

然后回答这个问题：
merge 的过程中 OlingCat 改了那些部分？是否都正确？

然后再去看看 Gerrit 上 merge 的 CL 是如何展示的（不是同一个 CL）：
（使用 github 的 OAuth 认证。）
补充一个问题:
这些改动是你一个人审核呢, 还要请Go的那些官方开发者来审核呢?
总之, 我是不能完全看懂那些改动全部意义的.
是否merge正确我都不能确定.

你就估计下, golang-china 邮件中, 有多少人能做这个 99.99% 改动的审核工作?
又有多少人愿意做这个 99.99% 改动的审核工作?

希望不要回避这个问题.
如果你真的看过 Gerrit 如何展示 merge 你就明白这个问题我不需要回答。

我们不审核官方的改动，所以 upstream 的所有改动都默认是正确的，我们想看
的只是我们在 merge 过程中额外修改的内容（主要是解决冲突），而 Gerrit 展
示的恰好是这部分内容。你 merge 得对不对一眼就能看出来。

如果 merge 一点冲突没有，完美的 auto-merge，那么 Gerrit 会告诉你这个 CL
一行改动也没有。比如这个：
然后看看 github 展示的对应的 commit:

Github 告诉我这个 merge commit 修改了：
196 changed files  with 3,954 additions and 2,756 deletions.

明白区别了么？

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9zC3z8NfdKB2yu-L5rugEFZDN7fNm85DvGp7AeHVkdvNw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 20, 2015, 5:51:48 AM1/20/15
to Golang-China
2015-01-20 5:37 GMT-05:00 Oling Cat <olin...@gmail.com>:
呃..你们先不要吵，首先我们放下 doc 和 article 文档，因为这个都是大段的文字，很好翻译同步；subrepo 我们目前不管它，因为官方都没定数。然后我们只有 pkg 和 cmd 文档的问题了，于是先列出需要解决的问题：
cmd 没太多需要翻译的内容。除了 cmd/go 的，其他可以先放一放（我目前不知道 1.5 cmd/ 下到底
会是什么布局，我问了 Russ 了，等他的回复中，当然不排除他们还没讨论这个问题。）

还有一个问题要讨论，是跟踪 release 分支还是跟踪 master，我觉得 @chai2010 也赞同跟踪 master，
除了 Gerrit 的分歧之外，就是要不要修改真正的源代码的问题。

Gerrit 的问题我坚持。修改源代码的问题我赞成那不是最佳的方案。参见我上文提的方案，我认为对于
译者来说那是最佳的情况。其余的技术细节，再讨论。重要的是把翻译工作开展起来。否则吵得翻天
覆地也没意义（我想起了上次关于翻译的话题也引发了大水，但是回过头来看，参与争论的有多少人
会实际地去翻译？有多少人是为了争论而争论？我觉得也为辩论而辩论了好多篇，完全是浪费时间。）

Gerrit 可以选择评论一行的某几个字符，这点 github 也做不到。Gerrit 的键盘操作键绑定也不错，诸如
此类。

但是 @chai2010 说门槛过高，或许，我们可以考虑自己重新开发一个工具，让你一键就把一个你要
发成 PR 的 branch 变成 CL。或者我们来做这个工作，译者继续采取向某一个 branch 加 commit 的
熟悉的方式，我们负责转换成 CL，这样既满足了我们能在 Gerrit 上评论翻译又满足了译者不愿意学习
新工具的要求。当然 译者还是需要注册 Gerrit 账户，否则无法接收邮件通知（或者你看 golang-china
上转发的通知也行）。

Oling Cat

unread,
Jan 20, 2015, 6:06:53 AM1/20/15
to Golang-China
现在我们统一一下意见：
1. 我和 minux 赞成提取包文档到单独的文件里进行翻译，毕竟谁都不喜欢直接在一堆源码里挑注释来翻译；不过我们需要个更精简的格式，chai 是否愿意和我们以 godoc 的输出为基础设计一下？
2. 等格式固定，对应工具齐备后，翻译审校工作可以放到Gerrit上来，大家可以试用一下Gerrit的审校，对比Github再做决定。

所以目前我们的首要工作是弄一个比较清楚，精简的提取格式，chai 意见如何？

至于通过在 release 之间打 patch 来更新的方法，目前我不赞同，等到所有文档基本完成后再说吧。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9wB%2Bso-pwEdqkyzAoLZJ55yDwhwOizy6F3csoZfQKCL0Q%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

xnotepad

unread,
Jan 20, 2015, 7:58:55 PM1/20/15
to golang...@googlegroups.com
https://github.com/caixw/GoTranslation 这是我之前断断续续设计的一个翻译方案，虽然不够完美，不过的确挺简洁的。
本来想年底有空的时候慢慢完善的，如果对大家能有所帮助，那最好不过了！

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAHZn%3DunVDZ%2BtcWSfUMBfjvLWkosYthVoUybKmFRsaO70hUz2ug%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 20, 2015, 10:35:17 PM1/20/15
to golang中文小组
又增加了好多内容, 我在一个里回了.

> 还是表面的差异。我们只不过采取了把中文放到 Go 代码里的方式，因为最开始目的是我们
> 不维护自己的 godoc fork，即使要修改，也不做大幅的代码调整。 

恩, "把中文放到 Go 代码里的方式" 确实是有历史原因.

不过现在的状况是: 1) 直接在Go代码修改; 2) 改造 godoc, 支持外部翻译资源加载.

对于 1) 来说, 还有一个额外的缺点:
普通的本地Go用户, 无法很方便地享受中文文档带来的好处.
代价是: a) 下载体积巨大的git库; b) 和本地的Go版本冲突

而且从带来合并的工作量来说, 我也比较认同 2) 的方式.

> 本主题费了这么多口舌，如果用来翻译的话，早就翻译完一个包了。
> 最近出了非常有意思的 cmd/gc bug (#9634)，我原计划还想花点时间瞧瞧呢……

确实, 如果大家都安照你希望的方式做的话, godoc 应该已经全部翻译玩了.
Go的BUG库也可以做同样的推理.

流程和工具的问题, 我觉得还是重要的, 而且目前也确实可以解决.
只有大家能有参与的动力, 一切的问题都好解决.

> @chai2010 抛开 Gerrit 和 PR 的问题不谈，你说的包方案可以实践一下。

Gerrit 和 PR 先这样也可以, 我保留意见吧.

> 但是我不喜欢那个格式，我觉得给翻译者的是越少结构越好：
> 
> 输入文件 [1]:
> // ArbitraryType is here for the purposes of documentation only and is not
> // actually part of the unsafe package. It represents the type of an arbitrary
> // Go expression.
> type ArbitraryType int
> 
> 然后翻译成 [2]:
> // ArbitraryType 在此处只用作文档目的，它实际上并不是 unsafe 包的一部分。
> // 它代表任意一个Go表达式的类型。
> type ArbitraryType
> 
> 换句话说，翻译的输入应该是命令行 godoc 输出那个样子的。然后用 go/doc
> 提取和同步翻译，这个我赞成。等于我们有一个目录保存 [1] 那样的输入文件，
> 然后每个语言单独一个目录放 [2] 那样的输出。
>
> 我们可以试试提取所有包的这样的文件进行翻译。

恩, 我也不喜欢现在的格式, 当时只是为了尽快弄一个可以看到效果的版本.

而且全部转成 static.go 静态价值的方式, 对于 doc 目录是不可行的(有16MB大, 编译失败).

我比较同意你的参考 builtin 包文档的方式翻译(这是内置包, builtin.go 就只是文档).

我临时建立了一个项目, 暂时放 local 的试验文件:


对我来说, 有一个技术难点. 我不怎么该如何处理以下格式的注释:

// 注释....
const {
ONE = iota // 注释一...
          // 注释一继续...
TWO
three      // 内部注释
}

`go/doc.Package` 好像不好表示这种信息.
如果能解决这个问题, 标准包的翻译就算是有完美的解决方案了.

对于第三方包的翻译, 可能是由包作者自己维护的, 可能需要嵌套一个子目录.
对应前面的 `golangdoc.local` 目录结构.


> godoc 的改动再讨论。现在我们有自己完全控制的 godoc 服务器，想改哪里
> 都没问题。

是的, 自己定制 godoc 会灵活很多.


> 还有一个问题要讨论，是跟踪 release 分支还是跟踪 master，我觉得 @chai2010 也赞同跟踪 master，
> 除了 Gerrit 的分歧之外，就是要不要修改真正的源代码的问题。

修改真正的源代码还有一个问题是, 不利于普通用户下载翻译文档使用(会影响本地Go版本).

> Gerrit 的问题我坚持。修改源代码的问题我赞成那不是最佳的方案。参见我上文提的方案，我认为对于
> 译者来说那是最佳的情况。其余的技术细节，再讨论。重要的是把翻译工作开展起来。否则吵得翻天
> 覆地也没意义（我想起了上次关于翻译的话题也引发了大水，但是回过头来看，参与争论的有多少人
> 会实际地去翻译？有多少人是为了争论而争论？我觉得也为辩论而辩论了好多篇，完全是浪费时间。）

其实参与翻译的人有很多, 从2010年开始, 我见过很多版本的翻译.
可以无法很好的合并起来.


> 现在我们统一一下意见：
> 1. 我和 minux 赞成提取包文档到单独的文件里进行翻译，毕竟谁都不喜欢直接在一堆源码里挑注释来翻译；不过我们需要个更精简的格式，chai 是否愿意和我们以 godoc 的输出为基础设计一下？

目前比较认同以 builtin.go 的方式翻译(有一些技术问题需要解决), 但是和Go源码分离.
请参考前面的回复和链接.

> 2. 等格式固定，对应工具齐备后，翻译审校工作可以放到Gerrit上来，大家可以试用一下Gerrit的审校，对比Github再做决定。
> 
> 所以目前我们的首要工作是弄一个比较清楚，精简的提取格式，chai 意见如何？
> 
> 至于通过在 release 之间打 patch 来更新的方法，目前我不赞同，等到所有文档基本完成后再说吧。

如过是独立的git库的话, 就可以方便的做翻译分支了.
可以针对release/master做灵活的配置.


要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CADRK%2BymAR-Us-wMJpaRGJNYbA3d%3DMn93Vx5dydwpAsc84JK3zA%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--

duyt

unread,
Jan 20, 2015, 10:51:01 PM1/20/15
to golang...@googlegroups.com
作为旁观者，我很高兴chai2010提出这个参与复杂度的问题。我也试着clone过中文文档的翻译，正如chai2010第一份message所说，我对直接go代码修改和大量手工操作感到不解。我没有用过gerrit，看上去像是个不错的审核工具。如果有一个清晰的流程，让翻译者不用去费劲考虑中英文翻译之外的事情，我相信能有更多的人参与进来。

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9nyjyhz%3DtqM7JKCdFpiV1cUz67m0Oy%3Dw_E9rcgd0y8LDQ%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

Oling Cat

unread,
Jan 21, 2015, 12:33:49 AM1/21/15
to Golang-China
我比较赞同用 builtin.go 的方式，其实从最初的包翻译一开始就是采用了这个方法。但有一个问题：官方的包文档在点击声明后面的类型时，可以跳转到源码里的实现中，而 builtin 的方式则无法看到。这个有办法解决么？我们是否可以在点击声明后面的类型时跳转到官方的源码中？

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFkdjeB9tLcuaBbn9KDyyQWEuCW%2Bem74xZwF-fJi288RfcR-FQ%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

Oling Cat

unread,
Jan 21, 2015, 12:39:37 AM1/21/15
to Golang-China
关于内部注释的翻译，我们暂且放下（或许第二阶段），因为它应该是和源码紧紧关联的，而且一般不会呈现给读者。现在的首要任务是如何提取一般意义上的包文档进行翻译。

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9nyjyhz%3DtqM7JKCdFpiV1cUz67m0Oy%3Dw_E9rcgd0y8LDQ%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 21, 2015, 2:12:13 AM1/21/15
to golang中文小组
在 2015年1月21日 下午1:33，Oling Cat <olin...@gmail.com>写道：
我比较赞同用 builtin.go 的方式，其实从最初的包翻译一开始就是采用了这个方法。但有一个问题：官方的包文档在点击声明后面的类型时，可以跳转到源码里的实现中，而 builtin 的方式则无法看到。这个有办法解决么？我们是否可以在点击声明后面的类型时跳转到官方的源码中？
这个builtin.go不是真正的代码, 只是类似json的一种翻译数据的存储格式(为了方便翻译的人, 不需要学习其他的东西).
由专门的包从中提取出翻译后的文档, 用于覆盖godoc中原始的英文文档.
点击类型的声明还是会调整到官方的代码实现中.

chai2010

unread,
Jan 21, 2015, 4:53:06 AM1/21/15
to golang中文小组
初步实现了 golangdoc 对 doc 翻译目录的支持.

目前需要手工配置 golangdoc.local 翻译目录:
git clone https://github.com/chai2010/golangdoc.local.git $(GOROOT)/godoc_local

具体可以参考 local 子包(从 i18n 改名而来, 增强了接口):

下面应该可以尝试实现对 builtin.go 翻译风格的支持了.
--

dlin

unread,
Jan 21, 2015, 5:14:49 AM1/21/15
to golang...@googlegroups.com
想到兩個方法

方法1: 如果可以把 godoc 資料 斷句之後 轉成 pot,

然後使用

gettext 翻譯文件工具 https://www.transifex.com/

這樣就可以讓廣大不需要懂程式碼的人協助翻譯.

但是，這的確有可能沒辦法翻的精確(因為沒有看上下文).

方法2: 改 godoc 程式，頁面上支援切換顯示語系，以及編輯.存檔.

允許修改的地方開放編輯,
存檔的結果可輸出純文字 markdown or rst format.
輸出的目的是為了存入 git, 供比對 review.

編輯時，同時顯示原始語句，翻譯過的語句
有工具button 直接代入 google translation 的結果. 或是文件中重覆語句的翻譯


On Tuesday, January 20, 2015 at 3:20:57 PM UTC+8, chai2010 wrote:
目前Godoc的中文翻译在这里:

说实话, 我一直不太喜欢这个翻译的流程:

1. 需要直接在Go的代码上修改, 同步非常麻烦(里面大量的Go代码的变更信息)
2. 以后增加其他语言(比如繁体中文)基本是要从头进行
3. 很多手工相关的操作

因为同步的流程比较复杂, 又引入了更复杂的 gerrit 审核机制
(目前好像只有 @minux 和 @olingcat 2个人在使用).
这样无疑是增加了文档翻译者参与的难度.

我之前想到的比较理想的翻译流程:

1. 基于工具提取Go的包文档, 导出要翻译的文档(gettext/markdown/json之类的都可以)
2. 每个包的文档独立翻译(这样Go), 可以参考包的方式组织目录结构
3. 改造godoc, 支持多国语言的切换
4. 辅助工具用于同步或查漏补缺


最近我 fork 了 godoc, 做了一些调整以支持 多国语言的翻译.
目前已经支持 多国语言的 切换:


翻译文件在这里(目前只有`unsafe`包的简体中文版):


对于普通的翻译用户, 翻译 godoc 的文档就是给Go代码进行填空:

完成后 `go build && golangdoc -http=:6060 -lang=zh_CN` 就可以了.

如果需要, 以后甚至可以做一个 翻译源码 和 markdown 双向同步的工具.
这样的话, 翻译提交后, 可以在 github 上方便地查看翻译成果.

剥离了 Go 官方同步每天几十个CL的同步信息后,
对于 godoc 翻译这种不太复杂的合作,
`pull request` 绝对是足够了.

@minux
@olingcat
@xingxing

--

zhen Gao

unread,
Jan 21, 2015, 5:57:39 AM1/21/15
to golang中国邮件列表
GOOGLE不是有一个协同翻译工具么，他就可以做到完美断句。。
直接提交网页就行。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/2a5c0d4e-a049-4b1b-8e30-ae92973239d2%40googlegroups.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

minux

unread,
Jan 21, 2015, 6:15:24 AM1/21/15
to Golang-China
2015-01-21 4:52 GMT-05:00 chai2010 <chais...@gmail.com>:
初步实现了 golangdoc 对 doc 翻译目录的支持.

目前需要手工配置 golangdoc.local 翻译目录:
git clone https://github.com/chai2010/golangdoc.local.git $(GOROOT)/godoc_local

具体可以参考 local 子包(从 i18n 改名而来, 增强了接口):

下面应该可以尝试实现对 builtin.go 翻译风格的支持了.
很好！

你翻译的文件完全跟我预想的一致。作为文档，我具体描述一下我的设想，我认
为它同时照顾了译者和审校者的需求：

翻译前：
// 英文原文
Go 声明

翻译后：（重要的是保留原文，这样如果翻译完成后又做了中文的改动审校者继续有的参考。）
// 英文原文 （Gerrit 会帮助我们保证译者没有修改原文）

// 中文翻译
Go 声明

唯一需要的工具就是自动合并英文的改变，比如英文原文变了，
则自动更新已经翻译的文件为这样：
// 新原文 这个和 diff 的顺序不确定，或许新原文更靠近译文好些？
// 不过 diff 我是希望翻译完就删除的，所以我觉得 diff 放中间更好。

// 旧英文原文 vs 新原文的 diff
// http://godoc.org/github.com/kylelemons/godebug/diff，当然你可以用更好的算法，
// 忽略换行区别的；但是这个不是最关键的。主要是保证审校者在查看这个版本的
// 翻译的时候可以看到新旧原文的区别，然后要对应的考虑中文新旧翻译的差异是
// 否和英文的差异想符合。（具体地说就是英文改变的原因我们要在翻译的结果上
// 体现出来，如果中文翻译需要更新的话；有的时候英文变了，中文不一定需要更
// 新。）

// /*旧中文翻译*/    # 这里采取某种途径标明这个翻译已经过时。
Go 声明

然后这个版本要提交。

译者更新的时候，看 diff 翻译，翻译完成的时候删除 diff，变成这样：
// 新原文

// 新中文翻译
Go 声明

yet...@gmail.com

unread,
Jan 21, 2015, 11:14:50 AM1/21/15
to golang...@googlegroups.com

研究了一下从go源码解析注释的方法，写了一个demo, 供大家讨论。
实现思路是从go文件中提取出注释，生成po文件，翻译者将只需要翻译po文件，这种做法优点如下：
翻译po文件，翻译者不需要会git、merge...
翻译过程中英文对照
可以使用gettext相关工具提高翻译效率
翻译成果可复用
golang的新版本发布后仅需要增量翻译
可使用transifex之类的平台合作翻译与校验

实现关键点，给个po文件看看吧：
#. used by: func Hi: (此处可加入注释的上下文，以帮助翻译者，不加也没啥影响)
#: io.go:19:2 （此处，表示文件名，本注释在源文件中开始的行号，本注释共占用了几行。）
msgid ""
"ErrShortWrite means that a write accepted fewer bytes than requested"
"but failed to return an explicit error."
msgstr ""

关键点在于给po文件加上的源文件位置信息，根据此信息，当翻译完成之后，可将这些信息写回源文件（将某行开始的n行被替换成中文注释，这个代码还是比较容易写的）。

关于后续版本升级说明，假定目前针对golang 1.4版本生成golang-1.4.po文件，里面的行号信息肯定是固定的，在版本不变的情况下翻译和更新源代码文件都不会存在问题。msg*系列工具对po中加的那两行不产生影响，并且会自动支持。
如果golang 1.5版本发布，使用此工具生成 golang-1.5.pot, 然后使用msgmerge工具就可以将golang-1.4.po翻译的成果merge过来，同时自动更新行号信息为1.5版本的。


--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9zzeurqavHpBrtA8E_gnPeRKXYhzk78mC3N_L5KTL06sw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
Best regards!

yetist

yet...@gmail.com

unread,
Jan 21, 2015, 9:07:49 PM1/21/15
to golang...@googlegroups.com
对上述方案又进行了更新，基本可以完整模拟文档翻译的整个流程，请大家讨论评估。


请git clone项目，请运行test.sh测试，完成之后请对比io.po和io-1.4.po，这分别是golang1.3和golang 1.4版本的io.go文件的翻译结果。

--
Best regards!

yetist

chai2010

unread,
Jan 21, 2015, 10:16:29 PM1/21/15
to golang中文小组
po翻译的优点是有界面工具支持, 对于非码农用户友好(但是这个翻译需要非Go码农参与吗?).

po的缺点是无法精确的描述Go的注释信息, 而且容易对Go文档的小修改产生放大效果.

比如(1):

  // 注释
  const (
    // 注释
    A = ... // 注释
    B = ... // 注释
    // 注释
  )

比如(2):

  // 注释1, 当这个注释产生很小的变化, 可能就对po产生的很大的影响(不利于版本管理)
  func AAA()

而且 po 不利于手工修改, 也不利于审查.

我感觉 builtin.go 是比较理想的方式(和写Go注释完全一致).
这个对于参与Go翻译的人要求应该不算高吧.

在 2015年1月22日 上午12:14，yet...@gmail.com <yet...@gmail.com>写道：
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAGMB4_PRujSVBnY%3DgQq5GdHFqjgU7z-9UMPYTX84rTjOd%2BBjKA%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--

chai2010

unread,
Jan 21, 2015, 10:24:24 PM1/21/15
to golang中文小组
对于标准包的翻译, 已经有了比较合理的组织方式了.

但是对于第三方的包, 很可能只是包自己附带了翻译文件.

怎么兼顾 标准包 和 第三方包 的翻译是一个问题.

目前想到的一个方案:

1. 第三方包的目录下有 `doc_$(lang).go` 文件, 对应各个语言的翻译

比如: doc_zh_CN.go 对应 zh_CN 的翻译

2. `doc_$(lang).go` 文件的内容组织和 `builtin.go` 一样, 但是不参与正常 build

每个 `doc_$(lang).go` 文件开头增加 `// +build ingore` 回避编译的文件.

改造后的 godoc 复制从 `doc_$(lang).go` 文件提取翻译信息.

3. `doc_$(lang).go` 可以在包的相同目录, 也可以在外部目录

比如:

a) my/pkg/doc_zh_CN.go
b) $(GOROOT)/local/zh_CN/src/my/pkg/doc_zh_CN.go

4. 第三方包的翻译方案也适用于标准包

不过标准包的翻译文件一般是放在外面目录, 比如 $(GOROOT)/local

一个小缺点是, builtin.go 需要对于 builtin/doc_zh_CN.go

`doc_$(lang).go` 会导致很多重名文件.


PS: 刚给 golangdoc 增加了 Windows 服务模式的支持.

使用如下:

// # install as windows service
// golangdoc -service-install -http=:6060 -lang=zh_CN
//
// # start/stop service
// golangdoc -service-start
// golangdoc -service-stop
//
// # remove service
// golangdoc -service-remove
--

yet...@gmail.com

unread,
Jan 21, 2015, 11:19:00 PM1/21/15
to golang...@googlegroups.com
> po的缺点是无法精确的描述Go的注释信息, 而且容易对Go文档的小修改产生放大效果.
请问这个怎么讲？为什么无法精确描述Go的注释信息？

>// 注释1, 当这个注释产生很小的变化, 可能就对po产生的很大的影响(不利于版本管理)
注释产生很小的变化，就会对po产生很大的影响，这个能多讲一下吗？
不知道你的的不利于版本管理的问题是什么？如果指的是po合并/更新等造成词条前后顺序乱掉的话，可以使用“ -s, --sort-output 输出前排序” 选项。

po另一个好处是如果多个文档中有同一个词如"Default"的话，可以只翻译一次，而同时保持各个术语的一致性。

在 2015年1月22日 上午11:16，chai2010 <chais...@gmail.com>写道：
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9mCOeeCyjZTWLFamxZzXyBwY1Jh2DvD6yAcJDnbYFrQyw%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--
Best regards!

yetist

Oling Cat

unread,
Jan 21, 2015, 11:41:33 PM1/21/15
to Golang-China
po 的方式我不赞同，因为：
1. 我用过的不少以 po 翻译的软件，因为脱离了上下文，导致有些词本身虽然翻译得正确，但和当时情景结合的话用起来有点奇怪，当然不排除是译者的能力问题。
2. 我们不需要不熟悉Go的人翻译包文档，因为它的地位决定了它必须准确而易懂，用 po 虽然降低了门槛，但我怕同样会降低翻译质量。
3. 术语确实要统一，但只翻译一次，后文直接替换的话，遇到同词不同意或反之的情况就比较麻烦了（例如 term 和 item），因为如果提前替换了中文，有可能会给译者一个先入为主的诱导，纠正时又会增加考虑的负担。
当然你可以给出例子来打消我的顾虑，不过目前 chai 的方案看起来非常不错，我打算采用这个方法。

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAGMB4_N86hTJFTrYF9gzEY0ogYhm-pi0t6MpJyxSfm8dfpbq7A%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 22, 2015, 12:12:35 AM1/22/15
to golang中文小组


在 2015年1月22日 下午12:18，yet...@gmail.com <yet...@gmail.com>写道：
> po的缺点是无法精确的描述Go的注释信息, 而且容易对Go文档的小修改产生放大效果.
请问这个怎么讲？为什么无法精确描述Go的注释信息？
Go的注释有不少特殊的字符, 比如: "'`\n\t 等

而且有些特殊的字符还是有特殊含义的. 比如: \t

po 表达这些字符需要做精确的匹配.
工具生成还好说, 手工就难搞了.

比如这种格式:

  // 常量 // 注意, 这个在po中会重名
  //
  // func examle() {
  // println("你好!") // 这里的代码不好写吧(有\t\n"字符)
  // }
  const (
  A = ...
  B = ...
  ) 

>// 注释1, 当这个注释产生很小的变化, 可能就对po产生的很大的影响(不利于版本管理)
注释产生很小的变化，就会对po产生很大的影响，这个能多讲一下吗？
不知道你的的不利于版本管理的问题是什么？如果指的是po合并/更新等造成词条前后顺序乱掉的话，可以使用“ -s, --sort-output 输出前排序” 选项。
po 本质上是给 poedit 之类程序使用的数据格式.
手工虽然可以修改, 但是还是没有直接写Go注释那样的方便.

而且, 对于比较长的注释. po 就更难表达了.

Go程序中注释的一些小变化, 可以在 po 看来是
很多的变化, 甚至会丢弃老的注释(增加fuzzy标记),
然后再为新的注释生成新的 msgid.

但是, Go的pkg文档注释, 其实不是用 msgid 来唯一定位的(而且 用 pkg.FunName 标识). 

po另一个好处是如果多个文档中有同一个词如"Default"的话，可以只翻译一次，而同时保持各个术语的一致性。
po 的合并或排序只能解决一般的问题.
但是这些行为都不是我们自己可控制的(po是给程序用 的).

"Default" 是它的一个不足.
虽然可以用ctx提高精确性, 但是这样就会越复杂了(对于翻译者来说).
 

chai2010

unread,
Jan 22, 2015, 5:18:36 AM1/22/15
to golang中文小组
golangdoc 已经支持 基于 doc_zh_CN.go 风格的翻译:

翻译文件在这里:

同时也支持扩展包自己发布翻译文件:

需要注意的是 外部翻译文件放在这个目录:
$(GOROOT)/translations
--

chai2010

unread,
Jan 22, 2015, 9:44:57 PM1/22/15
to golang中文小组
golangdoc 改造工作已经基本完成(GAE部分还没改).

翻译文件的同步工具计划稍后再做(基于原文档/翻译后文档生成doc_zh_CN.go).

目前可以手工创建 doc_zh_CN.go 文件用于包文档翻译了.


标准库的例子:

第三方库的例子:

@minux @olingcat 你们看 golangdoc 放哪里维护比较合适?

翻译流程是否要等到 同步工具 完成 之后再调整?


PS:
如果有想 参与 godoc/同步工具 开发和维护 的, 赶紧留言啊.

--

xnotepad

unread,
Jan 22, 2015, 10:10:53 PM1/22/15
to golang...@googlegroups.com
你是怎么处理特定于平台的函数的。


要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9%3Dnb05qCPqAtV5a%3D%3DDQi0N67bgb%3Dk1pLdKYvUZhcPMvCQ%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 22, 2015, 10:17:10 PM1/22/15
to golang中文小组
没有处理特定平台的文件.

当 godoc 显示某个包的文档时, 根据包的导入路径查找对应的 doc_zh_CN.go 文件.
然后用 doc_zh_CN.go 中的文档覆盖原始的文档.

doc_zh_CN.go 只是一个文档, 不参与Go的编译.

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CADRK%2BynhsCUK9tzWvJ9%3DkR3Ab%2BbN-bEqbopMrZHk5-4rJQG_Qg%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--

xnotepad

unread,
Jan 22, 2015, 10:26:20 PM1/22/15
to golang...@googlegroups.com
我不知道go标准库中存在这么一种情况，一个函数对于不同平台，文档会有细微的差别。

要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAN95H9nF81vTU_uHry7_hN7kqOA7K1W0chPnAxx5_NVUxWLZeA%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。

chai2010

unread,
Jan 22, 2015, 10:36:15 PM1/22/15
to golang中文小组


在 2015年1月23日 上午11:26，xnotepad <xnot...@gmail.com>写道：
我不知道go标准库中存在这么一种情况，一个函数对于不同平台，文档会有细微的差别。
恩. 之前的 syscall 包 在不同的平台接口是不同的.
现在已经拆到不同的包去了:

这种差别估计要特殊处理下.

minux

unread,
Jan 22, 2015, 10:41:57 PM1/22/15
to Golang-China


On Jan 22, 2015 10:26 PM, "xnotepad" <xnot...@gmail.com> wrote:
> 我不知道go标准库中存在这么一种情况，一个函数对于不同平台，文档会有细微的差别。
举例？除了 syscall 之外，哪个包存在这种情况？

syscall 不同平台差异过大，肯定要单独翻译，好在 syscall 包基本没有文档（当然你可以认为这其实是坏事儿）。syscall 包已经不会再改了，所以翻译一次就行了。

加 doc_LANG.go 的方式也可以扩展到支持 doc_LANG_GOOS_GOARCH.go 这样的为某个平台单独翻译的情况。就是提取待翻译文档的时候要更麻烦点，得尽可能抽取一致的文档到全局doc。。。

chai2010

unread,
Jan 22, 2015, 11:54:52 PM1/22/15
to golang中文小组
已经增加了对 GOOS 和 GOARCH 的支持:


处理的优先顺序:

// {FS}:/src/importPath/doc_$(lang)_GOOS_GOARCH.go
// {FS}:/src/importPath/doc_$(lang)_GOARCH.go
// {FS}:/src/importPath/doc_$(lang)_GOOS.go
// {FS}:/src/importPath/doc_$(lang).go

普通包还是按之前的 doc_zh_CN.go 方式处理.


--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。
要在网络上查看此讨论，请访问https://groups.google.com/d/msgid/golang-china/CAFK4q9zN6%3DK%3DkfR%3DbCjgi2AvBwet36vjD%3DM87EzTNjpGQ3BJmg%40mail.gmail.com。
要查看更多选项，请访问https://groups.google.com/d/optout。



--

minux

unread,
Jan 25, 2015, 1:43:53 AM1/25/15
to Golang-China
2015-01-22 21:44 GMT-05:00 chai2010 <chais...@gmail.com>:
golangdoc 改造工作已经基本完成(GAE部分还没改).

翻译文件的同步工具计划稍后再做(基于原文档/翻译后文档生成doc_zh_CN.go).

目前可以手工创建 doc_zh_CN.go 文件用于包文档翻译了.


标准库的例子:

第三方库的例子:

@minux @olingcat 你们看 golangdoc 放哪里维护比较合适?
你可以写那个 repo。 

翻译流程是否要等到 同步工具 完成 之后再调整?
恩 还是加紧做工作吧。先得有一个工具给定 import path，生成 doc_zh_CN.go；
第二步是，如果 doc_zh_CN.go 已经存在，合并已有翻译和（可能）更新的英文文档。
这个以后放在 Go-zh/pkg ？我们就不再区分来自哪里的包了，反正 import path 是独立
的，比如如果有人愿意翻译，github.com/user/repo/pkg，如果那个包真的值得翻译，
我们也可以加进来。这样如何？

我最近发现中文版的 Go Tour 翻译得不够好，有些句子不够通顺，所以趁着这个空隙，
我们先调整下中文版的 Go Tour。顺便继续给 http://tour.go-zh.org 做广告。这个不是
架在 GAE 上的，所以没有访问限制。

mikespook

unread,
Jan 25, 2015, 8:46:42 PM1/25/15
to golang中文组 golang中文组
终于有人也能参加到 go-tour 的中文化工作中了。个人希望，minux 对于 tour 感觉翻译有问题的地方，希望能够在 go-zh 的分支中进行了调整后，也向上游项目做一个反馈。

这个项目从开始工作到现在为止，仅仅收到过 10 个 issue。一方面来说，这和项目本身的质量不高、宣传力度小有极大的关系。另一方面来说，go-tour 内容偏少，难度偏低，导致留存较低。现在 Go 入门的文章、书籍正处于爆发期，go-tour 这种没有什么太大商业价值的东西，不容易引起各个面向初学者的技术媒体、社区的兴趣（商业价值导向）。

根据我的统计，golangtc 社区架设的中文版现在的流量是最大的。大约占到全部流量的 70%。

在 2015年1月25日 下午2:43，minux <mi...@golang.org>写道：


我最近发现中文版的 Go Tour 翻译得不够好，有些句子不够通顺，所以趁着这个空隙，
我们先调整下中文版的 Go Tour。顺便继续给 http://tour.go-zh.org 做广告。这个不是
架在 GAE 上的，所以没有访问限制。



--
Xing Xing (邢星)
mikespook <mike...@gmail.com>
http://mikespook.com

chai2010

unread,
Jan 26, 2015, 5:09:31 AM1/26/15
to golang中文小组
在 2015年1月25日 下午2:43，minux <mi...@golang.org>写道：

2015-01-22 21:44 GMT-05:00 chai2010 <chais...@gmail.com>:
golangdoc 改造工作已经基本完成(GAE部分还没改).

翻译文件的同步工具计划稍后再做(基于原文档/翻译后文档生成doc_zh_CN.go).

目前可以手工创建 doc_zh_CN.go 文件用于包文档翻译了.


标准库的例子:

第三方库的例子:

@minux @olingcat 你们看 golangdoc 放哪里维护比较合适?
你可以写那个 repo。 
好的.
我会保留golangdoc, 同时会同步更新 godoc-i18n. 

翻译流程是否要等到 同步工具 完成 之后再调整?
恩 还是加紧做工作吧。先得有一个工具给定 import path，生成 doc_zh_CN.go；
第二步是，如果 doc_zh_CN.go 已经存在，合并已有翻译和（可能）更新的英文文档。
增加了docgen, 用于提取包文档到 doc_zh_CN.go 文件:

目前已经可以自动合并已经翻译的文档.
但是原英文对照部分还没有包含. 
这个以后放在 Go-zh/pkg ？我们就不再区分来自哪里的包了，反正 import path 是独立
的，比如如果有人愿意翻译，github.com/user/repo/pkg，如果那个包真的值得翻译，
我们也可以加进来。这样如何？
同意放 go-zh/pkg.
如果是比较重要的第三方包, 也可以考虑在pkg里翻译吧.
当然, 第三方包也可以在自己目录提供翻译文件. 
 

我最近发现中文版的 Go Tour 翻译得不够好，有些句子不够通顺，所以趁着这个空隙，
我们先调整下中文版的 Go Tour。顺便继续给 http://tour.go-zh.org 做广告。这个不是
架在 GAE 上的，所以没有访问限制。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

chai2010

unread,
Jan 26, 2015, 9:20:54 PM1/26/15
to golang中文小组
--

minux

unread,
Jan 26, 2015, 10:56:28 PM1/26/15
to Golang-China


2015-01-26 21:20 GMT-05:00 chai2010 <chais...@gmail.com>:
docgen 已经可以自动合并原始的英文和当然的翻译:
这段是怎么回事儿？

这段没有中文翻译啊？为啥中文翻译那里是重新折行的英文？
得加点测试。这个程序有点复杂，我不希望在开始翻译之后才发现bug。

至少得测试以下几个：
1. 比较 godoc （不要用修改的 godoc，用原版的 godoc）对原来包生成的文档和直接对
doc_zh_CN.go 生成的输出是一致的。（只考虑英文翻译的）这个确定提取的文档是完整的。

2. 测试能够正确 merge 进来英文更新，这个我没想好如何测试。。

chai2010

unread,
Jan 27, 2015, 2:03:50 AM1/27/15
to golang中文小组
在 2015年1月27日 上午11:56，minux <mi...@golang.org>写道：


2015-01-26 21:20 GMT-05:00 chai2010 <chais...@gmail.com>:
docgen 已经可以自动合并原始的英文和当然的翻译:
这段是怎么回事儿？

这段没有中文翻译啊？为啥中文翻译那里是重新折行的英文？
恩, 之前是即使没有翻译也会将原始的英文当作翻译后的文档保存一份.
出现这行的原因是 `go/doc.ToText` 默认每行80个字符, 但是对于80个中文则太宽了(可能是160个宽度).
之前我临时将翻译部分的宽度改为40了, 结果显示原始的英文时就悲剧了... 

新更新的版本做了2点改进:
1. 采用unicode的 "east asian width" 属性计算字符串的宽度(从go/doc克隆了comment.go文件, 增加stringWidth函数)
2. 对于没有翻译的文档(准确说是翻译前后内容相同), 只输出1份原始文档

得加点测试。这个程序有点复杂，我不希望在开始翻译之后才发现bug。
同意. 后面会尝试增加一些测试. 

至少得测试以下几个：
1. 比较 godoc （不要用修改的 godoc，用原版的 godoc）对原来包生成的文档和直接对
doc_zh_CN.go 生成的输出是一致的。（只考虑英文翻译的）这个确定提取的文档是完整的。
这个思路不错. 

2. 测试能够正确 merge 进来英文更新，这个我没想好如何测试。。

其实最担心是会不会导致翻译信息丢失.
其他的都是小问题,

PS:
目前golangdoc对cmd/go和blog还不支持. 我没有详细看godoc中这部分的代码.
@minux 能给点提示吗. 

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 27, 2015, 10:05:10 AM1/27/15
to Golang-China


On Jan 27, 2015 2:03 AM, "chai2010" <chais...@gmail.com> wrote:
> 新更新的版本做了2点改进:
> 1. 采用unicode的 "east asian width" 属性计算字符串的宽度(从go/doc克隆了comment.go文件, 增加stringWidth函数)
> 2. 对于没有翻译的文档(准确说是翻译前后内容相同), 只输出1份原始文档

OK.


>>>
>>> 这是合并后的std包的翻译:
>>> http://github.com/chai2010/golangdoc.translations/tree/master/src
>>>
>>> docgen:
>>> http://godoc.org/github.com/chai2010/golangdoc/docgen
>>
>> 得加点测试。这个程序有点复杂，我不希望在开始翻译之后才发现bug。
>
> 同意. 后面会尝试增加一些测试. 
>>
>>
>> 至少得测试以下几个：
>> 1. 比较 godoc （不要用修改的 godoc，用原版的 godoc）对原来包生成的文档和直接对
>> doc_zh_CN.go 生成的输出是一致的。（只考虑英文翻译的）这个确定提取的文档是完整的。
>
> 这个思路不错. 
>>
>>
>> 2. 测试能够正确 merge 进来英文更新，这个我没想好如何测试。。
>>
> 其实最担心是会不会导致翻译信息丢失.
> 其他的都是小问题,

恩


> PS:
> 目前golangdoc对cmd/go和blog还不支持. 我没有详细看godoc中这部分的代码.
> @minux 能给点提示吗. 

不支持 cmd/go 是啥意思？blog 是用的 present 包渲染 .article 文件到 HTML。blog和talks都是这样，还没有啥好的翻译。

我本周会非常忙，麻烦 @OlingCat 看一下这个吧。下一步就是试试按照这个翻译了。

minux

unread,
Jan 27, 2015, 10:10:58 AM1/27/15
to Golang-China


On Jan 25, 2015 8:46 PM, "mikespook" <mike...@gmail.com> wrote:
> 终于有人也能参加到 go-tour 的中文化工作中了。个人希望，minux 对于 tour 感觉翻译有问题的地方，希望能够在 go-zh 的分支中进行了调整后，也向上游项目做一个反馈。

参见 bitbucket.org/Go-zh/go-tour-zh
的 pull request。我刚过了前两章，但是还在内部审核阶段。

如果你觉得上游有啥问题，欢迎发 CL。

> 这个项目从开始工作到现在为止，仅仅收到过 10 个 issue。一方面来说，这和项目本身的质量不高、宣传力度小有极大的关系。另一方面来说，go-tour 内容偏少，难度偏低，导致留存较低。现在 Go 入门的文章、书籍正处于爆发期，go-tour 这种没有什么太大商业价值的东西，不容易引起各个面向初学者的技术媒体、社区的兴趣（商业价值导向）。

跟 app engine 国内很难访问有没有关系？
架设在 tour.go-zh.org 之后会不会好些？

> 根据我的统计，golangtc 社区架设的中文版现在的流量是最大的。大约占到全部流量的 70%。

初学者到底希望看什么类型的文档呢？

chai2010

unread,
Jan 28, 2015, 4:38:27 AM1/28/15
to golang中文小组
cmd/xxx 的导入路径会作为 "xxx" 处理, 这个问题已经修复了.
同时增加了 blog 翻译的支持. 
talks 暂时先不考虑了.

我本周会非常忙，麻烦 @OlingCat 看一下这个吧。下一步就是试试按照这个翻译了。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 28, 2015, 7:06:47 AM1/28/15
to Golang-China


On Jan 28, 2015 4:38 AM, "chai2010" <chais...@gmail.com> wrote:
> 在 2015年1月27日 下午11:05，minux <mi...@golang.org>写道：,


>> > PS:
>> > 目前golangdoc对cmd/go和blog还不支持. 我没有详细看godoc中这部分的代码.
>> > @minux 能给点提示吗. 
>> 不支持 cmd/go 是啥意思？blog 是用的 present 包渲染 .article 文件到 HTML。blog和talks都是这样，还没有啥好的翻译。
>
> cmd/xxx 的导入路径会作为 "xxx" 处理, 这个问题已经修复了.

哦 你说的是这个问题。其实 C 写的工具都有单独的 doc.go，所以不用工具提取也没问题。Go 写的工具们，一般也是遵循专门的 doc.go 的原则。。。

> 同时增加了 blog 翻译的支持. 
这个怎么支持的？blog和talks没有本质区别啊。

> talks 暂时先不考虑了.

talks 没有大段文字，而且其实不了解相关内容也很难纯看幻灯片看明白内容，这个要翻译好得实际讲一遍才行。（幻灯片上文字太简略，得完全意译才行。。。）

mikespook

unread,
Jan 28, 2015, 8:20:06 PM1/28/15
to golang中文组 golang中文组
在 2015年1月27日 下午11:10，minux <mi...@golang.org>写道：


On Jan 25, 2015 8:46 PM, "mikespook" <mike...@gmail.com> wrote:
> 终于有人也能参加到 go-tour 的中文化工作中了。个人希望，minux 对于 tour 感觉翻译有问题的地方，希望能够在 go-zh 的分支中进行了调整后，也向上游项目做一个反馈。

参见 bitbucket.org/Go-zh/go-tour-zh
的 pull request。我刚过了前两章，但是还在内部审核阶段。

如果你觉得上游有啥问题，欢迎发 CL。

呃，可能我没说清楚。算了，这个问题，不用讨论了。

> 这个项目从开始工作到现在为止，仅仅收到过 10 个 issue。一方面来说，这和项目本身的质量不高、宣传力度小有极大的关系。另一方面来说，go-tour 内容偏少，难度偏低，导致留存较低。现在 Go 入门的文章、书籍正处于爆发期，go-tour 这种没有什么太大商业价值的东西，不容易引起各个面向初学者的技术媒体、社区的兴趣（商业价值导向）。
 跟 app engine 国内很难访问有没有关系？
架设在 tour.go-zh.org 之后会不会好些？

我认为不是架设在哪里的问题，golangtc 也是架设在国内可访问的主机上的。这个跟媒体宣传有关系。

> 根据我的统计，golangtc 社区架设的中文版现在的流量是最大的。大约占到全部流量的 70%。

初学者到底希望看什么类型的文档呢？

这个我感觉不能以“个人预期”为导向了。问题换一下“初学者到底适合看什么类型的文档呢？”会好很多。然而，问题就是，适合的未必有人喜欢。

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

chai2010

unread,
Jan 28, 2015, 8:20:12 PM1/28/15
to golang中文小组
在 2015年1月28日 下午8:06，minux <mi...@golang.org>写道：


On Jan 28, 2015 4:38 AM, "chai2010" <chais...@gmail.com> wrote:
> 在 2015年1月27日 下午11:05，minux <mi...@golang.org>写道：,
>> > PS:
>> > 目前golangdoc对cmd/go和blog还不支持. 我没有详细看godoc中这部分的代码.
>> > @minux 能给点提示吗. 
>> 不支持 cmd/go 是啥意思？blog 是用的 present 包渲染 .article 文件到 HTML。blog和talks都是这样，还没有啥好的翻译。
>
> cmd/xxx 的导入路径会作为 "xxx" 处理, 这个问题已经修复了.
 哦 你说的是这个问题。其实 C 写的工具都有单独的 doc.go，所以不用工具提取也没问题。Go 写的工具们，一般也是遵循专门的 doc.go 的原则。。。

主要的原因是在加载翻译文档的时候, 用的是 importPath 作为唯一的 key.
现在就是将 "xxx" 还原为 "cmd/xxx", 这2个文档是一样的:

我觉得用 "cmd/go" 会更简洁.

> 同时增加了 blog 翻译的支持. 
这个怎么支持的？blog和talks没有本质区别啊。

只是针对不同lang加载不同的vfs.
比如zh_CN对应这个fs:

> talks 暂时先不考虑了.

talks 没有大段文字，而且其实不了解相关内容也很难纯看幻灯片看明白内容，这个要翻译好得实际讲一遍才行。（幻灯片上文字太简略，得完全意译才行。。。）

目前官方的godoc也没有包含talks和tour等支持.
得先增加 talks和tour的支持.
翻译的支持比较简单的.

--
--
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina
---
您收到此邮件是因为您订阅了Google网上论坛上的“Golang-China”群组。
要退订此群组并停止接收此群组的电子邮件，请发送电子邮件到golang-china...@googlegroups.com。

minux

unread,
Jan 28, 2015, 10:25:39 PM1/28/15
to Golang-China
2015-01-28 20:19 GMT-05:00 chai2010 <chais...@gmail.com>:
在 2015年1月28日 下午8:06，minux <mi...@golang.org>写道

On Jan 28, 2015 4:38 AM, "chai2010" <chais...@gmail.com> wrote:
> 在 2015年1月27日 下午11:05，minux <mi...@golang.org>写道：,
>> > PS:
>> > 目前golangdoc对cmd/go和blog还不支持. 我没有详细看godoc中这部分的代码.
>> > @minux 能给点提示吗. 
>> 不支持 cmd/go 是啥意思？blog 是用的 present 包渲染 .article 文件到 HTML。blog和talks都是这样，还没有啥好的翻译。
>
> cmd/xxx 的导入路径会作为 "xxx" 处理, 这个问题已经修复了.
 哦 你说的是这个问题。其实 C 写的工具都有单独的 doc.go，所以不用工具提取也没问题。Go 写的工具们，一般也是遵循专门的 doc.go 的原则。。。

主要的原因是在加载翻译文档的时候, 用的是 importPath 作为唯一的 key.
现在就是将 "xxx" 还原为 "cmd/xxx", 这2个文档是一样的:

我觉得用 "cmd/go" 会更简洁.
恩 godoc 是特别处理了 /cmd。 

> 同时增加了 blog 翻译的支持. 
这个怎么支持的？blog和talks没有本质区别啊。

只是针对不同lang加载不同的vfs.
比如zh_CN对应这个fs:

> talks 暂时先不考虑了.

talks 没有大段文字，而且其实不了解相关内容也很难纯看幻灯片看明白内容，这个要翻译好得实际讲一遍才行。（幻灯片上文字太简略，得完全意译才行。。。）

目前官方的godoc也没有包含talks和tour等支持.
得先增加 talks和tour的支持.
翻译的支持比较简单的.
blog 和 talks 是独立的程序处理的。
blog 是 x/blog/blog，talks 是 x/tools/cmd/present。

本质都是 x/tools/present 包处理的。.article 和 .slide 和包文档还不太一样，原先计划是
类似 doc 目录下的 html 文件一样处理：注释原来的英文，然后底下添加中文。

不过我似乎感觉 present 文件格式本身可以添加多语言的支持。我考虑一下这个问题。
present.Elem 可以改成有一个默认版本和可选的若干语言的版本。
Reply all
Reply to author
Forward
0 new messages