Go语言中文Wiki

[金洪伟]

本来只想自己在Wiki中记笔记，但在换服务器的时候要送个域名，于是就弄了个 golangwiki.org，自己间断性地把翻译的东西贴上去，期间也有其他人注册并稍微帮了点忙。

我知道这里一直在用Google code的wiki在组织翻译，但我想目前 golangwiki.org 上面的东西要稍微更多、更新一点，Mediawiki在内容组织、用户权限分配、页面展示等方面也更好一点。因此就想和大家商量一下是不是还是都把翻译转到 golangwiki.org 上。

唯一不好的就是内容排版是要使用wiki语法，但我想这一点对大家来说并没有什么困难。如果有足够多的人上来帮忙，我会一直帮助维护这个小网站。

请大家发表看法！

[Liigo Zhuang]

我也有意帮忙，不知道该怎么参与。另外怎么与官网同步，楼主想好了吗？

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[mon...@gmail.com]

��Ҳ���԰�æ���Ѿ�������һ���û����û���Ҳ��monnand����

Liigo Zhuang wrote, On 03/13/2012 01:54 PM:
> ��Ҳ�����æ����֪������ô���롣������ô�����ͬ����¥���������
>
> �� 2012-3-13 PM11:56��"���ΰ" <ruo...@gmail.com
> <mailto:ruo...@gmail.com>>���
>
> ����ֻ���Լ���Wiki�мDZʼǣ����ڻ���������ʱ��Ҫ�͸��������Ǿ�Ū��
> �� golangwiki.org <http://golangwiki.org>���Լ�����Եذѷ���Ķ���
> ����ȥ���ڼ�Ҳ��������ע�Ტ��΢���˵�æ��
>
> ��֪������һֱ����Google code��wiki����֯���룬������Ŀǰ
> golangwiki.org <http://golangwiki.org> ����Ķ���Ҫ��΢��ࡢ����һ
> �㣬Mediawiki��������֯���û�Ȩ�޷��䡢ҳ��չʾ�ȷ���Ҳ���һ�㡣��
> �˾���ʹ������һ���Dz��ǻ��Ƕ��ѷ���ת�� golangwiki.org
> <http://golangwiki.org> �ϡ�
>
> Ψһ���õľ��������Ű���Ҫʹ��wiki������������һ��Դ����˵��û��
> ʲô���ѡ�������㹻�����������æ���һ�һֱ����ά�����С��վ��
>
> ���ҷ��?����
>
> --
> ����: Golang-China ~ ����Go���Լ����ʼ��б�
> ����: http://groups.google.com/group/golang-china
> ����: http://golang-china.org/
> IRC: irc.freenode.net <http://irc.freenode.net> #golang-china
> @golangchina
>
> --
> ����: Golang-China ~ ����Go���Լ����ʼ��б�
> ����: http://groups.google.com/group/golang-china
> ����: http://golang-china.org/
> IRC: irc.freenode.net #golang-china
> @golangchina

[bor...@gmail.com]

我也可以帮忙，现在主要的问题是怎么和官网上的资料同步？

--
Jiang Bian
http://www.wifihack.net/
http://golang-china.org/

[mon...@gmail.com]

bor...@gmail.com wrote, On 03/13/2012 09:30 PM:
>
> ��Ҳ���԰�æ��������Ҫ����������ô�͹����ϵ�����ͬ����

���˾��ã��͹���ͬ��û���⣬����������Լ�ԭ���Ķ�����Ҫ���͹ٷ��ĵ�����
��û����ˡ�

>
>
> --
> Jiang Bian
> http://www.wifihack.net/
> http://golang-china.org/
>

[bor...@gmail.com]

2012/3/14 mon...@gmail.com <mon...@gmail.com>

bor...@gmail.com wrote, On 03/13/2012 09:30 PM:
>

> 我也可以帮忙，现在主要的问题是怎么和官网上的资料同步？

个人觉得：和官网同步没问题，但最好能有自己原创的东西。要不和官方文档翻译
就没区别了。

原创的东西当然是越多越好，但是刚开始还是以翻译国外的文章为主吧， 之后原创的东西才能跟上。

[Oling Cat]

这下我译的spec终于有地方放了= =||

我是应该直接修改你的呢还是重新创建一个？我译到Expression（表达式）那里了，我看你有些地方还没译，我就直接贴上去了啊

--

Hello! This is Oling Cat!

2012/3/14 bor...@gmail.com <bor...@gmail.com>

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china

官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[金洪伟]

我不太理解同步的问题，我想这个问题可以分为两个方面：

（1）如何查看官网的某一文档在某次版本更新中都更新了那些内容，从而在对应的中文部分做出修改。

我承认这一方面是最重要的，但却没有好的办法。我想如果用源码安装Go的话，Mercurial本身的命令或许能用到hg status和hg diff，但请原谅我对hg命令并不熟悉。当然会有许多人像我一样，那就只有期望Go 1的文档不会那么频繁地改动。

（2）保证wiki上的文档结构和官网上的大致相同。以下用示例说明此wiki上的文档结构和官网的对应关系：

* install（Getting Started） ——> 安装（也可以将“入门”重定向到“安装”）
* Package flag ——> Package:flag （同样还有Command、Project和Example名字空间）

将来用通过建立一个合适的模板，通过规范化的形式列出原文标题、原文链接等。

[金洪伟]

直接修改别人原来已经进行的翻译。但最好别直接粘贴，而应该更正别人翻译的不好的地方。

[Oling Cat]

源码的godoc上有整个网站的源码，为什么不把这个作为golangwiki的网站内容呢？用hg应该比较容易得到修改，实在不行还可以看google code上的更新嘛。

--

Hello! This is Oling Cat!

2012/3/14 金洪伟 <ji...@163.com>

--

来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china

官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[Oling Cat]

我是说我把我已经译了但你还没译的贴上去。你已经译了的，我们比较一下谁的版本更好，或者取长补短，把你我译的整合起来。

--

Hello! This is Oling Cat!

2012/3/14 金洪伟 <ji...@163.com>

[金洪伟]

我想文档的翻译还是很重要，当然也可以弄自己原创的东西，甚至是一些示例代码，一些小技巧（tip），不过请注意版权要求“知识共享 署名-相同方式共享”。

在 2012年3月14日 上午9:37，mon...@gmail.com <mon...@gmail.com>写道：

bor...@gmail.com wrote, On 03/13/2012 09:30 PM:
>

[bor...@gmail.com]

2012/3/14 金洪伟 <ji...@163.com>

我想文档的翻译还是很重要，当然也可以弄自己原创的东西，甚至是一些示例代码，一些小技巧（tip），不过请注意版权要求“知识共享 署名-相同方式共享”。

我把 wiki.golang-china.org 已经重定向到 http://golangwiki.org 了。

原来的wiki.golang-china.org 上面基本上没有什么资料，荒废了很久了。

[bor...@gmail.com]

2012/3/14 bor...@gmail.com <bor...@gmail.com>

2012/3/14 金洪伟 <ji...@163.com>

我想文档的翻译还是很重要，当然也可以弄自己原创的东西，甚至是一些示例代码，一些小技巧（tip），不过请注意版权要求“知识共享 署名-相同方式共享”。

我把 wiki.golang-china.org 已经重定向到 http://golangwiki.org 了。

原来的wiki.golang-china.org 上面基本上没有什么资料，荒废了很久了。

gola...@box789.bluehost.com 发的邮件确认邮件进去gmail的Spam了。 

[minux]

2012/3/14 bor...@gmail.com <bor...@gmail.com>

2012/3/14 金洪伟 <ji...@163.com>

我想文档的翻译还是很重要，当然也可以弄自己原创的东西，甚至是一些示例代码，一些小技巧（tip），不过请注意版权要求“知识共享 署名-相同方式共享”。

我把 wiki.golang-china.org 已经重定向到 http://golangwiki.org 了。

我突然想到，其实golangwiki.org这个域名本身跟中文没啥关系，为啥不作为一个golang相关的wiki站点呢？

可以类似wikipedia，弄一个zh.golangwiki.org，原版的放en.golangwiki.org，这样估计同步起来也有帮助。

没准可以直接把官方的code.google.com/p/go-wiki给替代了，Google Code的wiki实在是不能和MediaWiki比。 

如果愿意的话，可以找adg@golang问问他的意思。

对于golang.org上面的文档，我还是建议放在godoc里。一是那些文档本身就是html格式的，再转成wiki格式的

没啥必要；二是我觉得页面风格和官网的也应该保持一致；三是这样同步或许容易些；注意目前golang.org上

的多数可能频繁更新的文档都加了时间戳。我们只要照着一个版本翻译完了，以后就可以增量翻译了，所以更

新上问题并不大（建议建立一个机制，每个文档翻译完成后由一人负责更新上游的改动，而且更新频率也不会

太频繁，顶多一周一次嘛；另外，Go 1.0发布后，这些核心文档的更新频率会更慢了）。

[Oling Cat]

同意minux大！我在想既然hg clone下来的代码里有完整的golang网站，能不能直接照着这个格式译成中文？做成一个子站点应该没问题吧？另外我想问下golang的官方文档是怎么编辑的，是直接的html还是什么东西生成的？如果格式能单独分离出来的话，就可以只专注于翻译内容了。

--

Hello! This is Oling Cat!

2012/3/14 minux <minu...@gmail.com>

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china

官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

[minux]

2012/3/14 Oling Cat <olin...@gmail.com>

同意minux大！我在想既然hg clone下来的代码里有完整的golang网站，能不能直接照着这个格式译成中文？做成一个子站点应该没问题吧？另外我想问下golang的官方文档是怎么编辑的，是直接的html还是什么东西生成的？如果格式能单独分离出来的话，就可以只专注于翻译内容了。

可以呀，我就是建议直接弄个中文的branch。啥httpd都不需要，直接godoc -http=:80就行了。（单独一个中文的分支

还有个好处，每次merge default的时候如果有冲突就意味着该翻译新内容了。。。在default分支hg diff一下有冲突的

文档就好了）

你可以看看/doc下的文档，都是手工编辑的html，但只有文档的结构信息，基本只要会用<p>和<code>就能编辑了。 

而且里面还可以用些html/template的东东，可以从/doc/progs/里买你包含一段代码进来等等。

另外呀，最近godoc添加了一个-url的参数，具体可以看看doc/Makefile的用法。如果不愿意使用godoc做web server，

也可以用这个feature把godoc渲染完的html文件放到服务器上。

[金洪伟]

用godoc当然可以，但同时需要了解修改pkg、cmd中各个源文件中的注释需要很大的工作量（因为包、命令的注释是通过源代码生成的），这几乎不可能完成，况且又如何组织协作？我们现在使用wiki只是为了大家共同协作来提高翻译质量，毕竟，这些需要多个人的共同努力。

如果主要的教程翻译完成，再转到godoc上是完全没有问题的，不过这些有很大必要吗？

--

来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--
Chingli

[minux]

2012/3/14 金洪伟 <ruo...@gmail.com>

用godoc当然可以，但同时需要了解修改pkg、cmd中各个源文件中的注释需要很大的工作量（因为包、命令的注释是通过源代码生成的），这几乎不可能完成，

包的文档翻译还是很难做的，那些工作量太大。先期目标应该是翻译完所有/doc下的文档。

况且又如何组织协作？我们现在使用wiki只是为了大家共同协作来提高翻译质量，毕竟，这些需要多个人的共同努力。

翻译html组织协作有啥问题呢？每人一个hg代码库，一个人一段也可以呀，互相push/pull。

我的意思是，你一旦弄成wiki格式了，格式上如何和同官方的页面保持一致？转回去可就就难了。。。

本质上不就是需要一个可以协作的编辑器嘛。

如果主要的教程翻译完成，再转到godoc上是完全没有问题的，不过这些有很大必要吗？

用什么格式应该先确定好。我说用godoc只是个建议。如果觉得wiki真的比godoc好得多，当然也可以。

反正别来回转格式就行了。

(godoc我觉得有一个很大的好处，文档里面的代码是从/doc/progs的文件中包含来的，一旦/doc/progs

更新了，那么文档会自动更新，原先godoc还比较弱，需要在/doc目录底下make一下才会更新，现在

godoc已经具备了解析这样的模版的能力了，所以也没有这个问题了；我们如果单独维护一套文档，可

没有机制帮我们自动更新里面的程序样例)

[Liigo Zhuang]

建议hg clone所有pkg源码，直接修改.go里面的doc翻译为中文，然后godoc自动生成中文文档。

[Liigo Zhuang]

唉，hg merge时肯定出现数不清的冲突……

[Xing Xing]

于 Fri, 16 Mar 2012 00:21:14 +0800
Liigo Zhuang <com....@gmail.com> 写道:

> 唉，hg merge时肯定出现数不清的冲突……

不会的，通常来说这样可以三方对比的查看更新。英文有哪些地方更新了，一目了然。
我在做 go-tour 的翻译的时候，就是采用这样的方式，英文有新的
commit ，就从英文源上 pull 回来，然后
merge。冲突了，就三方对比，英文那边更新了，就同步的修改中文。

[金洪伟]

我想使用godoc的大体思路应该是：

1. 克隆官方的代码库，比如将该代码库起名为 gozh
2. 大家都同时获得官方的代码库 go 和中文代码库 gozh
3. 大家在 gozh 代码库中进行翻译，并将翻译结果提交回去
4. 有一个 vps 或独立主机，再获得 gozh，编译并运行 godoc 命令，向大家提供类似于golang.org的中文文档
5. 如果官方代码更新，大家都更新 go 库，查看更新了那些地方，然后再在 gozh中相应地方进行修改
6. 再在服务器端更新代码，重新编译，重新运行godoc
   

这样的好处是显而易见的：和官方保持高度的一致，但坏处就是总是要维持一个和官方一致的代码库 gozh（官方的更新不能直接合并到此代码库中），维护起来难度较大，尤其是在并非每个人都熟悉Mercurial的情况下。

不知道我的理解是否正确？

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC:  irc.freenode.net     #golang-china
@golangchina

--
Chingli

[minux]

2012/3/16 金洪伟 <ruo...@gmail.com>

我想使用godoc的大体思路应该是：

1. 克隆官方的代码库，比如将该代码库起名为 gozh

建立一个zh的branch吧，这样大家只用一个go的代码库就可以了，我们继续在google code上建立一个项目比如说go-zh，

大家可以只保持一个go的代码库(除非还要push官方库)，同时从两边pull，给go-zh项目push就行了。 

1. 大家都同时获得官方的代码库 go 和中文代码库 gozh
2. 大家在 gozh 代码库中进行翻译，并将翻译结果提交回去
3. 有一个 vps 或独立主机，再获得 gozh，编译并运行 godoc 命令，向大家提供类似于golang.org的中文文档
4. 如果官方代码更新，大家都更新 go 库，查看更新了那些地方，然后再在 gozh中相应地方进行修改
5. 再在服务器端更新代码，重新编译，重新运行godoc
   

这样的好处是显而易见的：和官方保持高度的一致，但坏处就是总是要维持一个和官方一致的代码库 gozh（官方的更新不能直接合并到此代码库中），维护起来难度较大，尤其是在并非每个人都熟悉Mercurial的情况下。

学习mercurial还是简单的。而且这也不需要非常熟悉mercurial，我们还没弄codereview呢，那还真得学习一段时间。

在 2012年3月16日 下午1:50，Xing Xing <mike...@gmail.com>写道：

于 Fri, 16 Mar 2012 00:21:14 +0800 Liigo Zhuang <com....@gmail.com> 写道:
> 唉，hg merge时肯定出现数不清的冲突……
不会的，通常来说这样可以三方对比的查看更新。英文有哪些地方更新了，一目了然。
我在做 go-tour 的翻译的时候，就是采用这样的方式，英文有新的
commit ，就从英文源上 pull 回来，然后
merge。冲突了，就三方对比，英文那边更新了，就同步的修改中文。

en 这是个好办法。 

[Hongwei Jin]

也就是说我们要维护一个和go代码库平行的代码库go-zh，每次官方更新的时候查看都更新了哪些文件然后再相应地修改我们的go-zh。因为多数文档是从源代码中注释生成的，我觉得这样的复制粘贴工作量真的很大，但又不得不进行这种复制粘贴，要不然我们的go-zh就不是最新的了。说实在，我还是感觉这样挺难，当然，只翻译doc目录下的文档倒没有什么问题。不知道我的理解是否正确？

--

来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--
Chingli

[minux]

2012/3/16 Hongwei Jin <ruo...@gmail.com>

也就是说我们要维护一个和go代码库平行的代码库go-zh，每次官方更新的时候查看都更新了哪些文件然后再相应地修改我们的go-zh。因为多数文档是从源代码中注释生成的，我觉得这样的复制粘贴工作量真的很大，但又不得不进行这种复制粘贴，要不然我们的go-zh就不是最新的了。说实在，我还是感觉这样挺难，当

不是复制粘贴，是我们直接改我们分支的源代码。前面Xing Xing已经说了，用三方对比这么翻译反而是简单的。

如果我们脱离hg翻译，可就没有这么方便的三方对比merge了。

（那些文档是godoc从源代码中实时生成的，所以实际上如果我们想翻译也*必须*是翻译源代码注释，而不是翻译自动生成的

页面，那样不但很容易过时，过时了也不好更新）

然，只翻译doc目录下的文档倒没有什么问题。不知道我的理解是否正确？

代码注释我们原本准备翻译么？如果翻译的话显然还是放在代码一起才有意义呀。

或者说，如果我们准备翻译pkg的文档，那么就更应该采取单独一个hg分支的方法翻译了。

每人负责自己一个或者少数几个pkg的文档更新/翻译，我觉得工作量还好呀。

[Hongwei Jin]

呵呵，学到不少。不过最后还要请教一点，如果我们最后的确修改了每个文件的注释，比如pkg文档，这样即便官方的某些文件在某一个版本中没有修改，但其每个文件都应该和我们的不一样，如何将官方的这些文件merge到我们的zh呢？

--

来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--
Chingli

[minux]

2012/3/17 Hongwei Jin <ruo...@gmail.com>

呵呵，学到不少。不过最后还要请教一点，如果我们最后的确修改了每个文件的注释，比如pkg文档，这样即便官方的某些文件在某一个版本中没有修改，但其每个文件都应该和我们的不一样，如何将官方的这些文件merge到我们的zh呢？

hg的merge大概是这么这么做的：

比如说我们在zh branch上，要merge进来官方的default分支。hg merge -r default，

那么hg会先看我们分支上次merge default的时候default的版本号，比如说R1，然后default现在

在rev R2上，那么他会先计算R1到R2之间的差距，弄成一个patch，然后试图在我们的代码里

apply这个patch。

如果成功，那么就说merge成功，如果失败就让人来帮助他merge，因为这说明我们分支和default

分支都修改了同一行代码。

由于patch是有上下文的，所以大多数情况下，只要default没有修改被我们翻译的注释，那么merge

都会成功。只有修改了注释（或者离注释很近的代码）了之后才会导致merge失败，这时候三方

merge就有威力了，我们可以同时看到R1/R2和我们分支那个文件的样子，然后人工把改动merge进去。

不过我后来又想到一点，这样的话，似乎还真不太好弄一个人负责一个pkg的翻译。merge default

会一口气告诉你所有merge失败的文件，你都得resolve之后才能commit。当然我们前期肯定是不会

去翻译pkg的注释的。

[notedit]

方案定下了吗  翻译的话算我一个。

呼叫管理员，来组织一下吧

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--

Best Wishes..

[minux]

不等管理员了，我直接建立了一个POC项目，粗粗翻译了主页和主模版。

http://code.google.com/p/go-zh/  zh-default 分支

zh-default表示是翻译default的分支，以后上游有了新的分支之后，我们也跟着分，比如叫zh-go1之类。

大家看看这么做可以不？有兴趣的人可以直接联系我（初期最好是已经翻译过的人来吧，当然只要有兴

趣做这个，我觉得也没啥问题）。另外，是否把commit记录发到本邮件列表供参考？

（不知道能不能只过滤zh-开头的分支的改动，其他分支的改动我们倒是不用在意）

（如果要允许commit信件的话，得请管理员把go...@googlecode.com加入可以发文的列表）

2012/3/17 notedit <not...@gmail.com>

[Yili Zhao]

在 2012年3月17日 上午3:08，minux <minu...@gmail.com> 写道：
> 不等管理员了，我直接建立了一个POC项目，粗粗翻译了主页和主模版。
> http://code.google.com/p/go-zh/  zh-default 分支
> zh-default表示是翻译default的分支，以后上游有了新的分支之后，我们也跟着分，比如叫zh-go1之类。

能不能在主页上面或者主页上面的wiki写一点关于如何翻译的教程，因为对mercurial不太熟悉，但也想帮忙翻译。

--
Yili Zhao

[bor...@gmail.com]

2012/3/17 minux <minu...@gmail.com>

不等管理员了，我直接建立了一个POC项目，粗粗翻译了主页和主模版。

http://code.google.com/p/go-zh/  zh-default 分支

zh-default表示是翻译default的分支，以后上游有了新的分支之后，我们也跟着分，比如叫zh-go1之类。

大家看看这么做可以不？有兴趣的人可以直接联系我（初期最好是已经翻译过的人来吧，当然只要有兴

趣做这个，我觉得也没啥问题）。另外，是否把commit记录发到本邮件列表供参考？

（不知道能不能只过滤zh-开头的分支的改动，其他分支的改动我们倒是不用在意）

（如果要允许commit信件的话，得请管理员把go...@googlecode.com加入可以发文的列表）

怎么把 go...@googlecode.com 加入到发帖的列表里面，是给go...@googlecode.com发邀请吗？

PS: 没有经过你的同意，我把你已经加为邮件列表的管理员了。

[Oling Cat]

OK，我赶紧学习下hg去。

另外，doc是直接修改源html呢还是有某个可以生成html的东西？我到现在也没找到= =||

--

Hello! This is Oling Cat!

2012/3/17 Yili Zhao <pan...@gmail.com>

[minux]

2012/3/17 Oling Cat <olin...@gmail.com>

OK，我赶紧学习下hg去。

另外，doc是直接修改源html呢还是有某个可以生成html的东西？我到现在也没找到= =||

看看doc/目录下的.html文件就好了。godoc会根据他们生成最终版的html的。

原先就比较麻烦，如果文章用了模版，那么要改.tmpl文件，然后在doc/目录下运行make

更新对应的.html文件。 现在godoc把这部分整合进来了，所以现在直接改.html文件就好了。

[Oling Cat]

谢谢、我要报名，今天争取把已经译好的整理到源html里。另外既然Go1快发布了，我们是不是开始准备新一轮的文档翻译项目了？把还是r60.3的都更新一下。

--

Hello! This is Oling Cat!

2012/3/17 minux <minu...@gmail.com>

--

[minux]

2012/3/17 bor...@gmail.com <bor...@gmail.com>

2012/3/17 minux <minu...@gmail.com>

不等管理员了，我直接建立了一个POC项目，粗粗翻译了主页和主模版。

http://code.google.com/p/go-zh/  zh-default 分支

zh-default表示是翻译default的分支，以后上游有了新的分支之后，我们也跟着分，比如叫zh-go1之类。

大家看看这么做可以不？有兴趣的人可以直接联系我（初期最好是已经翻译过的人来吧，当然只要有兴

趣做这个，我觉得也没啥问题）。另外，是否把commit记录发到本邮件列表供参考？

（不知道能不能只过滤zh-开头的分支的改动，其他分支的改动我们倒是不用在意）

（如果要允许commit信件的话，得请管理员把go...@googlecode.com加入可以发文的列表）

怎么把 go...@googlecode.com 加入到发帖的列表里面，是给go...@googlecode.com发邀请吗？

似乎不行，go...@googlecode.com没办法回复邀请的。。。这个我再考虑考虑别的方式。

毕竟我们只想看zh-*分支的改动。 

PS: 没有经过你的同意，我把你已经加为邮件列表的管理员了。

谢谢。我把目前所有管理员全加为go-zh项目的owner了。

[minux]

2012/3/17 Oling Cat <olin...@gmail.com>

谢谢、我要报名，今天争取把已经译好的整理到源html里。另外既然Go1快发布了，我们是不是开始准备新一轮的文档翻译项目了？把还是r60.3的都更新一下。

已加。

大家注意下哦，commit的时候一定确定自己在zh-default分支哦。要是commit到default我们就没办法merge了。

我去看看怎么用Google App Engine建立一个类似tip.golang.org的网站实时看zh-default分支的更新。 

我同意开始新一轮的文档翻译了，目前已经进入Go 1发布前的最后收尾阶段了，基本上除了几个Go1-Must的问题

外已经不会再改代码了；主要是文档方面的工作还有一点；但是问题不大，我们可以开始弄文档了。

[notedit]

加上我吧，

要不制定一个基本的规则，就像你刚才说的要commit到zh-default 分支之类的，还有任务的拆分认领等。

我总对一个没有计划 没有规则约束的项目心存畏惧

--

来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--

Best Wishes..

[minux]

2012/3/17 notedit <not...@gmail.com>

加上我吧，

Done. 

要不制定一个基本的规则，就像你刚才说的要commit到zh-default 分支之类的，还有任务的拆分认领等。

我总对一个没有计划 没有规则约束的项目心存畏惧

en  很有道理。  原来是如何管理任务的？可以借鉴不？ 

[Liigo Zhuang]

我也参加。希望有一个（简单的）任务分配的在线管理系统，防止大家做重复的工作（多人同时翻译同一篇）。再有一个宽松的进度管理，以周为单位（至少大概每周提交进度或状态，避免一个人长期独占一篇文章的翻译）。还有就是校验和复查的流程。我是计划翻译官方pkg文档的，这个可以有，必须有。我们是不是可以复制golang.org整站的中文版出来。

在 2012-3-17 上午11:14，"minux" <minu...@gmail.com>写道：

[Oling Cat]

pkg应该说是个很长远的计划，因为差不多要改动所有源码，可以先划分成块，一点一点慢慢译。现在的工作重点应该是doc，如果改动不大的话应该可以借鉴一下原来译过的。

关于这个过程我是这样理解的：

首先从官方源clone出一个branch，叫做default，然后从default再clone出default-zh，并对其进行翻译（就是直接把原文译成中文）。当官方更新时，diff出官方源和default之间的不同，生成一个patch，对这个patch翻译后apply到default-zh，然后再把default和官方源完全同步，这样理解对么？

--

Hello! This is Oling Cat!

2012/3/17 Liigo Zhuang <com....@gmail.com>

我也参加。希望有一个（简单的）任务分配的在线管理系统，防止大家做重复的工作（多人同时翻译同一篇）。再有一个宽松的进度管理，以周为单位（至少大概每周提交进度或状态，避免一个人长期独占一篇文章的翻译）。还有就是校验和复查的流程。我是计划翻译官方pkg文档的，这个可以有，必须有。我们是不是可以复制golang.org整站的中文版出来。

在 2012-3-17 上午11:14，"minux" <minu...@gmail.com>写道：

[minux]

2012/3/17 Liigo Zhuang <com....@gmail.com>

我也参加。希望有一个（简单的）任务分配的在线管理系统，防止大家做重复的工作（多人同时翻译同一篇）。再有一个宽松的进度管理，以周为单位（至少大概每周提交进度或状态，避免一个人长期独占一篇文章的翻译）。还有就是校验和复查的流程。我是计划翻译官方pkg文档的，这个可以有，必须有。我们是不是可以复制golang.org整站的中文版出来。

已加。我正在研究如何用Google App Engine架设一个tip.golang.org出来。 

[minux]

2012/3/17 Oling Cat <olin...@gmail.com>

pkg应该说是个很长远的计划，因为差不多要改动所有源码，可以先划分成块，一点一点慢慢译。现在的工作重点应该是doc，如果改动不大的话应该可以借鉴一下原来译过的。

关于这个过程我是这样理解的：

首先从官方源clone出一个branch，叫做default，然后从default再clone出default-zh，并对其进行翻译（就是直接把原文译成中文）。当官方更新时，diff出官方源和default之间的不同，生成一个patch，对这个patch翻译后apply到default-zh，然后再把default和官方源完全同步，这样理解对么？

不用我们显式地出patch，hg merge -r default就行了。如果配置得正确，会自动开一个工具三方对比的。

当然这么做的唯一问题是每次merge都会报所有我们改过且官方也改过的文章的冲突，要么我们采取一个一个commit得merge进来，

要么我们频繁地merge。对于不是自己负责的文档就把英文改动merge到中文的间隙里，请负责那个文档的人更新。

[Oling Cat]

我建议一个星期merge一次，然后让负责那块文档的人一次更新一个星期的改动，毕竟文档应该不会很频繁很大幅度地改动了。倒是pkg让我感觉很难啊....

--

Hello! This is Oling Cat!

2012/3/17 minux <minu...@gmail.com>

--

[Liigo Zhuang]

翻译pkg文档有什么难，它是天然细化到func的，翻译一点是一点，拿出几分钟时间就能做一次有效提交。

[Oling Cat]

哦也对，貌似pkg稳定下来了，不会再作太大改动了吧？

--

Hello! This is Oling Cat!

2012/3/17 Liigo Zhuang <com....@gmail.com>

[Liigo Zhuang]

在 2012-3-17 下午12:44，"Liigo Zhuang" <com....@gmail.com>写道：
>
> 翻译pkg文档有什么难，它是天然细化到func的，翻译一点是一点，拿出几分钟时间就能做一次有效提交。
>

翻译中文pkg文档时，我建议仍然保留原英文文档（放在中文后面），方便用户对照。而且这样做还可以避免hg merge时冲突：中文是额外加进去的。解决了大问题！

[minux]

2012/3/17 Liigo Zhuang <com....@gmail.com>

在 2012-3-17 下午12:44，"Liigo Zhuang" <com....@gmail.com>写道：
>
> 翻译pkg文档有什么难，它是天然细化到func的，翻译一点是一点，拿出几分钟时间就能做一次有效提交。
>

翻译中文pkg文档时，我建议仍然保留原英文文档（放在中文后面），方便用户对照。而且这样做还可以避免hg merge时冲突：中文是额外加进去的。解决了大问题！

这是个好办法，对于英文/doc下的文档我们也可以类似这样做呀。举例：

<p>Go is an open source programming environment that makes it easy to build simple, reliable, and efficient software.</p>

我们给他改成：

<div class="english">

<p>Go is an open source programming environment that makes it easy to build simple, reliable, and efficient software.</p>

</div>

<p>Go是一个开源的编程环境……</p>

然后在css里面我们关闭div.english的display就好了嘛。虽然文件大了，但是这样我们的改动在hg看来都是在英文之间添加东西，

而不是改变。而且我们能很容易同时开启英文/中文对照，校对的时候也方便了嘛。（注意<div>和原来英文是换行的，保证了

其实英文相关的行我们不变。）

当然这样也有弊病，hg不会提示某个文章merge冲突，我们容易忘记要去翻译英文更新的部分。当然如果开启了hg的三方对比

功能，即使是merge成功也会开编辑器让你看对比的，所以这个机制还是很可行的。

[minux]

更新：http://zh-golang.appspot.com/

使用的是免费的Google App Engine，内存有限制，所以关闭了搜索功能。
我还在继续研究如何自动从go-zh项目获取更新。

2012/3/17 minux <minu...@gmail.com>

[Oling Cat]

那我就直接这样写咯～！话说打开gospec源码一看，结构那叫一个清晰啊....

也就是说把原文代码用<div class="english"></p>围起来，然后译文以同样格式写在这段下面？

--

Hello! This is Oling Cat!

2012/3/17 minux <minu...@gmail.com>

--

[minux]

2012/3/17 Oling Cat <olin...@gmail.com>

那我就直接这样写咯～！话说打开gospec源码一看，结构那叫一个清晰啊....

也就是说把原文代码用<div class="english"></p>围起来，然后译文以同样格式写在这段下面？

用<div class="english"></div>围起来。注意要一段一段的翻译，也就是每个<p></p>之间(包括

<p>和</p>)用div包起来，底下是那一段的中文翻译。

好  你先试试看，我继续研究下如何用模版来解决这个问题。我们先期先慢慢来。

用go_spec.html试试我们的方式。我现在觉得最佳的方式是用模版解决这个，类似这样

{{if .Chinese}}中文{{end}}{{if .English}}english{{end}}

的方式。不过我还得先再看看godoc的源代码。

[notedit]

使用GAE 的话 你要考虑到大多数墙内的人是访问不了的。

--
来自: Golang-China ~ 中文Go语言技术邮件列表
详情: http://groups.google.com/group/golang-china
官网: http://golang-china.org/
IRC: irc.freenode.net #golang-china
@golangchina

--

Best Wishes..

[Oling Cat]

http://zh-golang.appsp0t.com/ 这个墙里面可以访问

--

Hello! This is Oling Cat!

2012/3/17 notedit <not...@gmail.com>

[notedit]

我的错  我关了代理是可以上的 

[bor...@gmail.com]

如果把域名指向到 http://zh-golang.appspot.com/ 的话，是可以在墙内正常访问。

要不我把golang-china.org的域名指向到这边， 目前这个域名是重定向到 http://code.google.com/p/golang-china/ 的。

目前: golang-china.org 和  golangchina.org 这两个域名都在我的名下，都可以指定过去。

[minux]

2012/3/17 bor...@gmail.com <bor...@gmail.com>

如果把域名指向到 http://zh-golang.appspot.com/ 的话，是可以在墙内正常访问。

保险起见，还是到 http://zh-golang.appsp0t.com/ 吧。 

要不我把golang-china.org的域名指向到这边， 目前这个域名是重定向到 http://code.google.com/p/golang-china/ 的。

目前: golang-china.org 和  golangchina.org 这两个域名都在我的名下，都可以指定过去。

先不必吧。至少把已经翻译过的文档全都加入进去再指过去吧，现在就是首页我昨天粗粗翻译了一遍。 

[Oling Cat]

出现一个小问题：如果碰上不用翻译的段（比如代码），是直接跳过不管呢，还是象征性地“翻译”（就是复制）一下以保证每一段都有对应的中文呢？

--

Hello! This is Oling Cat!

2012/3/17 minux <minu...@gmail.com>

--

[minux]

2012/3/17 Oling Cat <olin...@gmail.com>

出现一个小问题：如果碰上不用翻译的段（比如代码），是直接跳过不管呢，还是象征性地“翻译”（就是复制）一下以保证每一段都有对应的中文呢？

代码不用翻译（对于使用模版的页面，代码也翻译不了）吧，尽可能减少我们需要处理的东西，这样能尽可能

减少不一致出现的可能。 

一般来说实例代码较少有注释的，因为一般周围的文字会立即解释每段的含义，所以我们就直接跳过文章里的

代码吧。

[Oling Cat]

且先不说代码里的注释，官方Spec最上面都有一个目录的，我估计那是根据html文档的h1、h2、h3标签生成的。但如果直接照这个文档生成，虽然css可以隐藏掉div，但如何让div里面的h*标签也在生成目录时自动过滤掉呢？

我开始想的是，这个包含中文和英文的文档只作为内部观看用，对外发布时写一个脚本把里面所有class="english"的div剔除掉。但如果把源码嵌套进div里，会被一起剔除；而如果不这样，我怕校对时会有点麻烦，然后我就纠结了= =||

minux大有什么更好的方法么？

--

Hello! This is Oling Cat!

2012/3/17 minux <minu...@gmail.com>

--

[Liigo Zhuang]

我个人以为，发布中文文档时也应该中英并陈（可以考虑默认隐藏/折叠英文）。中文翻译词不达意的情况不能避免，对照英文原文有时是必须的。很多时候译者并不能准确理解原作者的本意，即便准确理解了也未必能准确的用中文表达出来。

[Hongwei Jin]

好吧，这次讨论是我发起的，但最后却产生了意想不到的结果。不过到目前为止我仍然无法说服自己使用godoc的好处，我认为相对于wiki，godoc还存在以下的不足：

# 翻译的内容能否立即见效，在wiki中，哪怕你只改动一个错字，只要点击保存按钮，修改的东西就立即见效，而使用Mercurial写作显然要走更长的路；
# 这种通过认领翻译的方式真的好吗？在wiki中，我们根本不需要认领，只要谁临时翻译和修正了某一部分，直接将翻译的东西粘贴上去就行了，而其他人可以立即在你修改的基础上进行修改；
# 在网页中显示贡献者的名字，在wiki中，查看历史功能使得查看谁参与了贡献会一目了然，但使用godoc页面却没法直接看到，而必须要下载代码库使用相应的hg命令查看，这其实是个小问题，但多少有点不好；
# 简单性，wiki的操作流程显然要少很多，稍微难的是wiki语法，不过golang.org所使用的html标记很少，转到wiki真的很容易，相比起来，Mercurial要稍微难点，并且不是所有人都会，况且有些人可能喜欢git而不喜欢Mercurial；
# 可扩展性，是否我们的目标就只是一个和官方高度同步的代码库，而像blog.golang.org、Go Community
Wiki、go-lang.cat-v.org等等上面的东西其实也需要翻译过来（并且上面有许多文章还相当重要），另外许许多多的第三方项目也需要进行汇总和介绍的，还需要增加许多页面如术语列表、工作指导等等；
# wiki能轻易地在中文繁简体之间进行简化，而godoc却不行，这样是不是就将台湾、香港的参与者排除在外了？
# 我不完全明白这种和官方高度同步的做法工作量是不是太大？我们真的能做得好吗？而使用wiki，则完全允许我们的工作存在一定的滞后。

诚然，建立中文化分支并使用godoc是一种完美的方案，起码它能是界面、各种链接关系和官方保持高度的一致，只是这样一来，也可能会给我们带来很多的不便。我们是否过于追求完美了？可能我列举的这些有些吹毛求疵，但是我觉得大家还是需要对这些问题进行考虑。

既然大家一致同意使用godoc，我会先关闭golangwiki.org的用户注册（每天都有垃圾信息实在很烦人），等其上的内容完全转移到
http://zh-golang.appspot.com/ 后就将其关闭。本人近期内要忙毕业答辩的工作，等完成后也会踊跃参与翻译的。

强烈建议将 golangwiki.org和code.google.com/p/golang-china
上已翻译完成的内容转移过去，但也建议在 http://zh-golang.appspot.com/
首页弄个链接页面说明这些工作以前都是由谁完成的，毕竟，翻译这些东西很辛苦的。

在 2012年3月17日 下午11:53，Liigo Zhuang <com....@gmail.com> 写道：
> 我个人以为，发布中文文档时也应该中英并陈（可以考虑默认隐藏/折叠英文）。中文翻译词不达意的情况不能避免，对照英文原文有时是必须的。很多时候译者并不能准确理解原作者的本意，即便准确理解了也未必能准确的用中文表达出来。
>
> 在 2012年3月17日 下午7:11，Oling Cat <olin...@gmail.com>写道：
>
>>
>> 且先不说代码里的注释，官方Spec最上面都有一个目录的，我估计那是根据html文档的h1、h2、h3标签生成的。但如果直接照这个文档生成，虽然css可以隐藏掉div，但如何让div里面的h*标签也在生成目录时自动过滤掉呢？

--
Chingli

[Wei guangjing]

我在做godoc的在线翻译<http://godoc-zh.golangnuts.com/>考虑过pkg的翻译，我计划是针对生成pkg的html文档做翻译，这样可以不用动源代码。翻译方式是按句翻译，这样更新可以通过模糊匹配自动来更新。如果是用hg的方式，我建议可以翻译一句就提交一句，这样可以达到类似的效果。

[mon...@gmail.com]

Wei guangjing wrote, On 03/17/2012 10:36 PM:
> 我在做godoc的在线翻译<http://godoc-zh.golangnuts.com/>考虑过pkg的翻译，我计划是针对生成pkg的html文档做翻译，这样可以不用动源代码。翻译方式是按句翻译，这样更新可以通过模糊匹配自动来更新。如果是用hg的方式，我建议可以翻译一句就提交一句，这样可以达到类似的效果。
>

我说说gnu.org上怎么做翻译的吧。

gnu.org上面的页面也都是纯html页面。翻译的话，会使用GNUN[1]通过html生成
pot文件，之后大家再通过pot文件做出各个语言的.po文件，最后，服务器上会通
过一个cron job定期把最新的.po文件利用gettext[2]更新对应语言的html文件。

这样的好处是：
1. 翻译人员可以不必考虑（太多）html，css，js等前台的因素，精力集中在文本
的翻译上
2. gettext，.po, .pot都是一套成熟的国际化/本地化的方案。很多程序也都在用
它。常给自由软件/开源软件做本地化的翻译者们都会熟悉。而且还有很多现成的
编辑器，或编辑器插件。

当然也有不少缺点。不过我没有自己独立通过GNUN做过完整的国际化/本地化的方
案，还不好做太多评论。大家可以参考一下这个方案。

1. http://www.gnu.org/software/gnun/
2. http://www.gnu.org/software/gettext/

[bor...@gmail.com]

2012/3/18 Hongwei Jin <ruo...@gmail.com>

好吧，这次讨论是我发起的，但最后却产生了意想不到的结果。不过到目前为止我仍然无法说服自己使用godoc的好处，我认为相对于wiki，godoc还存在以下的不足：

# 翻译的内容能否立即见效，在wiki中，哪怕你只改动一个错字，只要点击保存按钮，修改的东西就立即见效，而使用Mercurial写作显然要走更长的路；
# 这种通过认领翻译的方式真的好吗？在wiki中，我们根本不需要认领，只要谁临时翻译和修正了某一部分，直接将翻译的东西粘贴上去就行了，而其他人可以立即在你修改的基础上进行修改；
# 在网页中显示贡献者的名字，在wiki中，查看历史功能使得查看谁参与了贡献会一目了然，但使用godoc页面却没法直接看到，而必须要下载代码库使用相应的hg命令查看，这其实是个小问题，但多少有点不好；
# 简单性，wiki的操作流程显然要少很多，稍微难的是wiki语法，不过golang.org所使用的html标记很少，转到wiki真的很容易，相比起来，Mercurial要稍微难点，并且不是所有人都会，况且有些人可能喜欢git而不喜欢Mercurial；
# 可扩展性，是否我们的目标就只是一个和官方高度同步的代码库，而像blog.golang.org、Go Community
Wiki、go-lang.cat-v.org等等上面的东西其实也需要翻译过来（并且上面有许多文章还相当重要），另外许许多多的第三方项目也需要进行汇总和介绍的，还需要增加许多页面如术语列表、工作指导等等；
# wiki能轻易地在中文繁简体之间进行简化，而godoc却不行，这样是不是就将台湾、香港的参与者排除在外了？
# 我不完全明白这种和官方高度同步的做法工作量是不是太大？我们真的能做得好吗？而使用wiki，则完全允许我们的工作存在一定的滞后。

诚然，建立中文化分支并使用godoc是一种完美的方案，起码它能是界面、各种链接关系和官方保持高度的一致，只是这样一来，也可能会给我们带来很多的不便。我们是否过于追求完美了？可能我列举的这些有些吹毛求疵，但是我觉得大家还是需要对这些问题进行考虑。

既然大家一致同意使用godoc，我会先关闭golangwiki.org的用户注册（每天都有垃圾信息实在很烦人），等其上的内容完全转移到
http://zh-golang.appspot.com/ 后就将其关闭。本人近期内要忙毕业答辩的工作，等完成后也会踊跃参与翻译的。

wiki还是需要的， http://zh-golang.appspot.com/ 只是作为翻译官方的文档和PKG相关的东西，wiki里面添加我们原创的文档，邮件列表讨论的总结，或者翻译国外的一些文章。

[Oling Cat]

才发现go-zh里只有我一个人刚刚提交了点东西，不过要怎样才能在zh-golang.appspot.com看到效果呢？还有怎么通过css隐藏<div class="english"></div>？css要写在哪里？会不会达不到预期的效果？这都是问题啊，还望minux大解答。

--

Hello! This is Oling Cat!

2012/3/18 bor...@gmail.com <bor...@gmail.com>

[Hongwei Jin]

需要app engine的管理员更新代码才能看到效果。

要隐藏英文，在 go/doc/style.css 中添加

div.english  {

    display: none;

}

如果要通过点击对英文文档进行显示隐藏切换（toggle），需要编写相应的JavaScript。

--
Chingli

[minux]

2012/3/26 Oling Cat <olin...@gmail.com>

才发现go-zh里只有我一个人刚刚提交了点东西，不过要怎样才能在zh-golang.appspot.com看到效果呢？还有怎么通过css隐藏<div class="english"></div>？css要写在哪里？会不会达不到预期的效果？这都是问题啊，还望minux大解答。

非常感谢你做的工作，我最近一直都没做go-zh的事情，在Go 1发布前有些问题正在改。实在抱歉。我写了一个自动隐藏

英文的js的初始版本。示例：http://zh-golang.appspot.com/ref/spec?lang=en 和 http://zh-golang.appspot.com/ref/spec

前者会同时显示英文和中文版；后者只显示中文版；我原来考虑用template来解决这个问题，结果发现不行，因为很多

原来不用模版的页面里面包含很多{{之类，比如/ref/spec，要去掉这个还得改英文版，我觉得暂时没必要，就先用目前的

办法吧。

目前的解决方案的已知bug: 自动生成的目录不工作。我还没来得及改正。

目前appengine上的godoc还不能做到自动更新，这个还得开发。我还不熟悉Go版的appengine runtime，所以这个还得

等些日子。谁提交了新的翻译要zh-golang.appspot.com直接发信给我吧，我抽时间弄个自动上传的机制。

我看了下你提交的翻译，就有几个地方需要说明下：

1，html文件开头有一个注释里面是json格式的metadata，是给godoc用的，所以标题/副标题/版本这几个不用翻译，后面

的值当然翻译了没问题。另外，这段要是翻译且想要起作用的话，就得把英文的部分去掉。

2，EBNF语法那里如果要翻译的话，所有non-terminal请使用非数字开头，否则godoc会报错。

我草草写了一个http://code.google.com/p/go-zh/wiki/README 可以慢慢添加。

[Oling Cat]

OK、我去修正一下，谢谢minux大百忙之中还抽出时间来弄这个:-)

--

Hello! This is Oling Cat!

2012/3/27 minux <minu...@gmail.com>

--

[minux]

更新了一下go-zh项目。

创建了zh-go1分支跟踪上游的release-branch.go1。

我们集中力量翻译zh-go1分支吧，这个分支上游最近肯定没啥改动，这样我们不用频繁merge。

我觉得以后我们可以定位在只翻译release版，因为我觉得敢跟weekly甚至是tip的人肯定能看懂英文。

zh-golang.appspot.com也显示zh-go1分支的内容。

我最近就搞个脚本定时从zh-go1分支更新zh-goalng.appspot.com，我觉得可以保证延迟在30分钟之内。

PS: 更新了README。

还有，用<div class="english">的翻译方式我们只限定在可能频繁更新的技术文档，比如spec等等，

那些仅仅是引用其他文档的页面比如doc/reference.html之类就直接全翻译成中文就行了，这里没有

啥太专业的地方，估计也不用对比英文了，同时这里更新得并不频繁，merge的时候conflict就稍微

解决下也没啥大的工作量。大家觉得如何？

[Oling Cat]

创建了zh-go1分支跟踪上游的release-branch.go1。

我们集中力量翻译zh-go1分支吧，这个分支上游最近肯定没啥改动，这样我们不用频繁merge。

我觉得以后我们可以定位在只翻译release版，因为我觉得敢跟weekly甚至是tip的人肯定能看懂英文。

 

关于这点我比较同意。重点翻译release版自不必说，愿意跟tip的人肯定也愿意直接读原文。

我感觉这样做也行：先尽量把所有release文档全部译完，然后再慢慢跟进tip。语言已经成型了，文档的改动顶多不过3%-5%，所以有精力的话可以自发地跟进，这样以后在新版本出现之前也就可以自然地同步了。minux大感觉如何？

zh-golang.appspot.com也显示zh-go1分支的内容。

我最近就搞个脚本定时从zh-go1分支更新zh-goalng.appspot.com，我觉得可以保证延迟在30分钟之内。

这个等好久了，支持~！ 

PS: 更新了README。

还有，用<div class="english">的翻译方式我们只限定在可能频繁更新的技术文档，比如spec等等，

那些仅仅是引用其他文档的页面比如doc/reference.html之类就直接全翻译成中文就行了，这里没有

啥太专业的地方，估计也不用对比英文了，同时这里更新得并不频繁，merge的时候conflict就稍微

解决下也没啥大的工作量。大家觉得如何？

表示同意~！另外问下有没有什么方法可以快速插入div标签？我现在的方法是用搜狗的自定义短语来实现。直接按d然后空格是 <div class="english">，Ctrl是</div>，这样对于翻译分段可控，某些很短或关联性很强的段落可以合并翻译，不必每个<p>都要加上<div>。不知大家有什么高见？

[minux]

Update: 

1. 现在自动更新已经好了，延时一般会小于25分钟。（等有时间再直接用App Engine的backend

写一个延时更小的……）
2. 不知道有人发现了没有，主页的Run和Share两个按钮可以用了。

3. 未经过mikespook的同意就merge了ta的改动（十分感谢！），现在主页的视频改成了tudou的，

同时博客文章后面加上了自动翻译的链接（可惜Google Translate会把Go翻译成围棋…… 虽然确

实有这个意思，但是读起来十分别扭…… 哈哈）。

2012/4/4 Oling Cat <olin...@gmail.com>

创建了zh-go1分支跟踪上游的release-branch.go1。

我们集中力量翻译zh-go1分支吧，这个分支上游最近肯定没啥改动，这样我们不用频繁merge。

我觉得以后我们可以定位在只翻译release版，因为我觉得敢跟weekly甚至是tip的人肯定能看懂英文。

 

关于这点我比较同意。重点翻译release版自不必说，愿意跟tip的人肯定也愿意直接读原文。

我感觉这样做也行：先尽量把所有release文档全部译完，然后再慢慢跟进tip。语言已经成型了，文档的改动顶多不过3%-5%，所以有精力的话可以自发地跟进，这样以后在新版本出现之前也就可以自然地同步了。minux大感觉如何？

恩 最近一段时间go1分支肯定不会有改动，所以是翻译的绝好时机。最近Issue Tracker加了3个Label

分别是Go1.1, Go1.0.1和Soon，所以可见，短时间内不会推出Go1.0.1了，而且根据adg的说法短时间

内连weekly都不会推出。rsc说要开始merge CL 5279048了，这样一来，这么巨大的改动进来了release

就更得慎重点。

PS: 更新了README。

还有，用<div class="english">的翻译方式我们只限定在可能频繁更新的技术文档，比如spec等等，

那些仅仅是引用其他文档的页面比如doc/reference.html之类就直接全翻译成中文就行了，这里没有

啥太专业的地方，估计也不用对比英文了，同时这里更新得并不频繁，merge的时候conflict就稍微

解决下也没啥大的工作量。大家觉得如何？

表示同意~！另外问下有没有什么方法可以快速插入div标签？我现在的方法是用搜狗的自定义短语来实现。直接按d然后空格是 <div class="english">，Ctrl是</div>，这样对于翻译分段可控，某些很短或关联性很强的段落可以合并翻译，不必每个<p>都要加上<div>。不知大家有什么高见？

我觉得没问题。相关的段落组合一起对于后来merge改动也很有好处，这样明显提示了做合并的人，你只要

看这一段做改动就好了。

要是我会弄Vim的键盘映射。用V选择一个块然后自动在前面后面加上需要的东西（同时把英文拷贝一份到</div>

后面，我习惯翻译一点删除一点）。

[Xing Xing]

于 Thu, 5 Apr 2012 00:38:03 +0800
minux <minu...@gmail.com> 写道:

> Update:
> 1. 现在自动更新已经好了，延时一般会小于25分钟。（等有时间再直接用App
> Engine的backend 写一个延时更小的……）
> 2. 不知道有人发现了没有，主页的Run和Share两个按钮可以用了。
> 3.
> 未经过mikespook的同意就merge了ta的改动（十分感谢！），现在主页的视频改成了tudou的，同时博客文章后面加上了自动翻译的链接（可惜Google
> Translate会把Go翻译成围棋…… 虽然确实有这个意思，但是读起来十分别扭……
> 哈哈）。

在家用 googlecode 经常有问题，为了方便在 bitbucket 上 fork 了一个 zh
版本。

首页的调整仍在进行中，主要是想解决那个 /compiler
报错的问题，不过主要的显示部分都调整好了，merge 问题不大。

自动翻译那事儿……蛋定吧，本来就是“手闲”搞上去的。

另外，你们有没有遇到过向 googlecode push，hg 直接爆异常的情况。

>
> 2012/4/4 Oling Cat <olin...@gmail.com>
>
> > 创建了zh-go1分支跟踪上游的release-branch.go1。
> >> 我们集中力量翻译zh-go1分支吧，这个分支上游最近肯定没啥改动，这样我们不用频繁merge。
> >> 我觉得以后我们可以定位在只翻译release版，因为我觉得敢跟weekly甚至是tip的人肯定能看懂英文。
> >>
> >
> > 关于这点我比较同意。重点翻译release版自不必说，愿意跟tip的人肯定也愿意直接读原文。
> >
> > 我感觉这样做也行：先尽量把所有release文档全部译完，然后再慢慢跟进tip。语言已经成型了，文档的改动顶多不过3%-5%，所以有精力的话可以自发地跟进，这样以后在新版本出现之前也就可以自然地同步了。minux大感觉如何？
> >
> 恩 最近一段时间go1分支肯定不会有改动，所以是翻译的绝好时机。最近Issue
> Tracker加了3个Label 分别是Go1.1,
> Go1.0.1和Soon，所以可见，短时间内不会推出Go1.0.1了，而且根据adg的说法短时间内连weekly都不会推出。rsc说要开始merge

> CL 5279048<http://codereview.appspot.com/5279048/>
> 了，这样一来，这么巨大的改动进来了release 就更得慎重点。
>
> >
> > PS: 更新了README <http://code.google.com/p/go-zh/wiki/README>。

[minux]

2012/4/5 Xing Xing <mike...@gmail.com>

首页的调整仍在进行中，主要是想解决那个 /compiler
报错的问题，不过主要的显示部分都调整好了，merge 问题不大。

这个问题我在godoc里面改了。 

另外，你们有没有遇到过向 googlecode push，hg 直接爆异常的情况。

似乎有时会被墙。 

那你有啥更新了给我发邮件我来merge到google code的项目上吧。

[Uhioins Dell]

用tor翻墙解决

--

[东郭偃]

现在这个WIKI还是 http://golangwiki.org 吗

有待更新啊。首页右侧的最近更新还停留在 r60（2011/09/07发布） 阶段

[Oling Cat]

不了解版本控制的我又有问题了= =||

目前我是对zh-default做改动，那zh-go1要怎么弄= =？

--

Hello! This is Oling Cat!

2012/4/5 minux <minu...@gmail.com>

--

[minux]

2012/4/6 Oling Cat <olin...@gmail.com>

不了解版本控制的我又有问题了= =||

目前我是对zh-default做改动，那zh-go1要怎么弄= =？

hg update zh-go1 

[Oling Cat]

就是说我要同时对zh-go1和zh-default做改动么？

--

Hello! This is Oling Cat!

2012/4/6 minux <minu...@gmail.com>

--

[minux]

2012/4/6 Oling Cat <olin...@gmail.com>

就是说我要同时对zh-go1和zh-default做改动么？

先顾zh-go1吧。以后可以merge到zh-default去。

[Oling Cat]

现在zh-golang.appspot用的是zh-default？我昨天提交到zh-go1的改动没见更新啊？先顾zh-go1的话不就看不到效果了么？

Hello! This is Oling Cat!

2012/4/6 minux <minu...@gmail.com>

2012/4/6 Oling Cat <olin...@gmail.com>

就是说我要同时对zh-go1和zh-default做改动么？

先顾zh-go1吧。以后可以merge到zh-default去。

--

[minux]

2012/4/8 Oling Cat <olin...@gmail.com>

现在zh-golang.appspot用的是zh-default？我昨天提交到zh-go1的改动没见更新啊？先顾zh-go1的话不就看不到效果了么？

是zh-go1分支，不过我用来自动更新的服务器最近网络访问上有点小问题，估计下周就能恢复。

我今天只能手工更新了，已经上传。