在 2010年12月29日 下午4:45，monnand <monnand在zeuux.org> 写道：
> 真抱歉，最近几天各种忙活。先回答一下ZQ的问题吧：
>>> 好象有些文档并没有翻译? e.g words-to-avoid.cn.html
>>> 掺合的基本问题:
>>> - 如何反馈校对意见?
>
> 个人赞同Xiangfu的意见，先把.html转成.po。这个过程中必然会阅读一部分文章 内容，发现简单的错误就顺手改一下。
>
也就是说,在之前 tar 包释放的所有 FSFS 文章,没有翻译的也将在这次 po 转换中统一翻译?
- po 是标准的 软件i18N 模式,是否方便对文章进行处理?
- 我接触到的,多是零碎的界面词句的 po 翻译工程,对于有行文风格的文章,这种管理方式是否有助于所有参与成员快速掌握整篇文章的思想进行再创作?
- 建议使用 维基形式,永远以整体文章的形式来进行翻译和校对,也容易协同和统计贡献
    + code.google 的工程空间就内置一个可以通过版本管理系统 进行管理的维基
    + 在整体完成后统一转化成 po 汇入 GNU 空间?

> 有些语句上的安排，用词等问题，个人觉得可以考虑发到邮件列表上，与翻译者本 人进行讨论。同时，大家也都能看到讨论的内容，提出自己各自的意见。
>
这个非常同意,也很 easy;只是辛苦作者要维护和统计这种讨论了:
- 每篇文章的初译者,先用[fsfs]创建个线索?
- 相应有兴趣的,对应回复讨论?

...
> 这样做的原因如下：
>  翻译工作本身是一次再创作的过程，对于翻译者本人，我希望能尽量尊重翻译 者的意见。因此，对于读者本人，可以对翻译人员说：我觉得你这样翻译不好。以
> 此来建议翻译人员修改他的翻译。但我不希望读者直接对翻译人员说：你应该这么 翻译。因为这样的话会影响了翻译人员的创造工作。当我们说一个翻译不好的时
> 候，意味着希望翻译人员再找到更好的翻译；而当我们说这个翻译必须是如此的时 候，则意味着翻译人员本身失去了一定的创作自由。当然，读者也可以建议某种翻
> 译形式，也可以让此翻译形式参与投票。
>
> 投票结果作为翻译人员和校对人员继续讨论的依据。对于某一个特定的翻译形式， 假如参与该处翻译讨论的（即，回复了这个thread的）人数为N，参与投票的人与
> 大于N/3（即，超过了三分之一的人参与了投票），且投``不满意''票的人数超过 了投票人数的一半（含），则该条翻译形式必须进行修改。
>

但是,这也不是完全民主的哪,作者有最终决定权的哈,就象一个项目的主持人一样

...
> 投票有效期为投票发起之日起后的一周时间。
>
> o 对于某处的翻译，如果一个月内没有讨论出最终结果，无论是否发起过投票，则 由翻译人员自行决定采用何种翻译形式。采用的翻译形式不得与之前投票否决的形
> 式相同。如果翻译人员无法在一周内决定采用何种翻译，则由校对人员决定，同样 不得采用已否决的翻译。如果一周后依然无法决定，则交给翻译小组协调人来负责
> 决定。这样算来，一处翻译在最坏情况下，会在一个半月内有结果。
>
好漫长,不过方便各自有事儿的大家,从容掺合...

但是,最好有个地方将整个 FSFS 翻译工程的进展体现出来,类似：
http://code.google.com/p/openbookproject/wiki/LovPyRush#%E5%8E%86%E5%8F%B2%E6%8E%A8%E8%BF%9B
特别是要标明，当前各个译文的主要作者，或是说主持人的ID，联系方式,,,


> o 为了方便大家阅读，对于任何``自由软件，自由社会''这本书的校对讨论的 thread，请加入标签[FSFS]
>
...
>
>>> - 现在是中E间杂形式的,很难阅读,最终版本也是这样?
>
> 我个人觉得这样的形式很不好。我能容忍的英文出现在中文翻译中的最多是：
>
> o copyleft 这东西之前好像不止一次讨论过，但是都没结果，不如保留英文原词。
> o GNU 不说了，实在没法翻译
> o 相关的首字母缩写，项目名称等
> o 不知道怎么读的人名
>

呃，俺说的不是译文中的间杂，而是 tar 包里，每个页面都是一段原文，一段译文，这种形式...
...

-- 
人生苦短, Pythonic!
俺: http://about.me/zoom.quiet
开: http://code.ijinshan.com/
豆: http://www.douban.com/group/zoomquiet
书: http://code.google.com/p/openbookproject
蟒: http://code.google.com/p/kcpycamp/wiki/PythoniCamp