哲思官方群的帖子：

星期三十二月 29 22:19:48 CST 2010

在 2010年12月29日 下午6:59，monnand <monnand在zeuux.org> 写道：
...
>> - po 是标准的 软件i18N 模式,是否方便对文章进行处理?
>> - 我接触到的,多是零碎的界面词句的 po 翻译工程,对于有行文风格的文章,这种管理方式是否有助于所有参与成员快速掌握整篇文章的思想进行再创作?
>> - 建议使用 维基形式,永远以整体文章的形式来进行翻译和校对,也容易协同和统计贡献
>>     + code.google 的工程空间就内置一个可以通过版本管理系统 进行管理的维基
>>     + 在整体完成后统一转化成 po 汇入 GNU 空间?
>>
>
> 这个流程有待讨论。目前我觉得有一下几个问题需要解决：
> o 如果使用code.google的话，是否会产生不必要的版权问题。这个我目前还没有 看，需要看看与google的协议。

code.google 是支持各种许可证声明的,代码许可证就有GPLV3 的,
但是我们的翻译应该算 内容,内容许可证好象只有CC 可以选择的,,,
- 当然我们也可以将 .txt 的纯译稿视作代码,进行许可证聲明和協同

> o 使用wiki的形式自然不一定使用code.google，不过维基的方式是否为大家所接 受，则有必要听听大家的意见
> o 使用维基后如何转化为.po文件，倒也是个问题。虽然不大。
维基的文本是纯文本,很方便自动转化成 .po 的;
...
> 我个人表个态：凡是有利于提高生产力的，俺都喜欢。老实讲，比起直接编辑.po 文件，我觉得译言那样的方式倒是很不错。不过无论如何，后台的数据总归是要
> 用.po文件表示的。至于与翻译人员交互的界面是什么样，自然是越方便越好。可 能有人觉得emacs的po
> mode很不错，我也觉得很上手，不过我不能保证会有更好的 方式。
>
俺也是,储存中什么没有关系,但是从文章的撰写来说,强行按照原文的词/句/段落进行翻译是不可取的;
一定要有足够的自由度,才好进行自然的再次创作 ;-)

>>> 有些语句上的安排，用词等问题，个人觉得可以考虑发到邮件列表上，与翻译者本 人进行讨论。同时，大家也都能看到讨论的内容，提出自己各自的意见。
>>>
>> 这个非常同意,也很 easy;只是辛苦作者要维护和统计这种讨论了:
>> - 每篇文章的初译者,先用[fsfs]创建个线索?
>> - 相应有兴趣的,对应回复讨论?
>>
>
> 我的意见是：
> 校对在审校过程中，如果发现不能决定的地方，则*每处*翻译一个thread。审校结
> 束，再提交给翻译者本人查看。如果初译者觉得有些地方修改得不妥也是可以对* 每处*翻译一个thread。
>
> 所谓一处翻译，是指文章中的某句话，某个词。这样做比起一篇文章一个thread来 说，更加清晰。如果是一篇文章一个线索，那么可能这个线索内会同时讨论着多处
> 翻译，最终让整个主题分裂。劣势是一篇文章可能出现多个线索，让翻译人员和校 对无法准确找到各自负责的文章。个人建议对于这次审校工作，可以考虑使用以下
> 标签：
> [FSFS][初译人][校对人]主题
标签最好都是E文的,容易输入和过滤;

> 以此来方便翻译人员和校对过滤。初译人和校对人的名字以savannah上的注册id为 准。如果没有在savannah上注册，则以邮件地址中的用户名为准。
>
> 对于其他参与讨论的人，则根据各自感兴趣的主题来讨论
>>
>> ...

> 之所以折腾出这么复杂的程序，是调和以下互相矛盾的目的：
> 1. 翻译工作本身是一个创作过程。初译者本人应该对这个过程具有极大的自主权
> 2. 翻译的文章要提交到gnu.org上，作为官方的翻译，翻译质量必须有所保证
>
> 要满足条件1，则不得对翻译人员的工作进行任何干预，完全凭翻译人员本身来决 定。要满足条件2，则需要在有争议处尽量争取到读者的意见，根据读者投票表决。
>
> 我的基本思路是这样的：
>
> 上述两者都要满足，那么就是既要给初译者极大的自主权，又要保证翻译的质量。 这本身来说，是究竟要几分民主，几分自由的问题。因为我们无法保证初译者的初

嗯嗯嗯,思考的非常全面,从俺看来,对于GNU 这一核心思想承载文字,想达到足够的精典参加者:
+ 应该有足够的开发经验
+ 应该有足够的自由软件社区体验
+ 应该有足够的项目管理体验
+ 应该有足够的文学经验
这样才能确保在真正理解 GNU 思想的基础上结合中国IT现实,用通顺的中文创作成具有足够感召力的文本!

所以,译稿要足够好才可以检入 GNU 仓库发布到官网!这是必须的条件;
建议:
- 译稿至少在内部进行两次交叉通校后才可以对外小范畴试阅
- 试阅最好找几个台湾的资深自由软件愛好者,年龄不小于25岁的
- 试阅后根据反馈,再进行一轮校
- 最后统一到1~2人,进行最终统稿
这样形成 1.0 版本检入,,,持续接受意见,继续完善!

...
> 投票的人）只有权利说：我不喜欢！没有权利说：你应该如此！
>
...
> 有必要再加入几条：
>
> o 如果审校人员提交了一个线索，要求讨论，而在提交了这条线索之后，翻译人员 一周内没有出现且给出个人意见，则在此处翻译上，校对的角色则转换为初译者。
> 即便之后初译者出现，在此处翻译上，校对本人将对其负责，具有初译者的权利。 换句话说，如果对于某处翻译，初译者没有对列表上的争议及时回复（时间以一周
> 为准），则自动认为他放弃对此处翻译的修改权。不过初译者依然可以作为普通成 员，参与讨论和投票，但不再对此处翻译具有决定权。在最终的翻译版本上，译者
> 依然是初译者。
>
那么,建议先将投票者也确定下来,以便保证足够的及时反馈..
译者:校者:阅者
1:3:7
至少这个比例的配置...

> o 为了防止协调员把翻译的地方出现口袋预案，规定协调员必须在翻译出现争议后 的2个月内给出最终修改意见。
>
> o 关于投票：我个人最希望是无记名投票。达到这个目的倒也不难，对于列表上的 各位，估计一个下午就能从零开始，搭建一个匿名投票平台。不过这是否有必要还

邮件线索中,简单的 +1 就可以快速知道了,投票的哈,又得维护一个系统,已经初始化投票,以及进行統計,不如大家都清楚规范的情况下,约定几个邮件行为就好,也确保了所有投票是永久性保存在列表归档中的,无法因为DB什么的问题而丢失...

> 是要看后面的操作。大家也可以发表意见。
...
>> 但是,最好有个地方将整个 FSFS 翻译工程的进展体现出来,类似：
>>
>> http://code.google.com/p/openbookproject/wiki/LovPyRush#%E5%8E%86%E5%8F%B2%E6%8E%A8%E8%BF%9B
>> 特别是要标明，当前各个译文的主要作者，或是说主持人的ID，联系方式,,,
>>
>
> 话说到现在，我已然想开发个小系统帮咱解决一下协调问题，实现我上面的一些功 能了（无记名投票，匿名指派等等）。而且我觉得这套流程可以留待以后参考。不
> 过这又是后话了。

是也乎,是也乎,这次也算练兵,找出这种高端文档的翻译協同需求,
的确可以引发一个靠谱的技术文档協同翻译平台工程的,是后话,也值得作...

...
>> 呃，俺说的不是译文中的间杂，而是 tar 包里，每个页面都是一段原文，一段译文，这种形式...
>> ...
>
> 哦，这个形式肯定不是这样了。详细的翻译流程参考：
> http://www.gnu.org/server/standards/README.translations.html
>>
>
>

-- 
人生苦短, 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

标题：[zeuux-press] [GNUCTT] [审校]自由软件，自由社会