www-zh-cn-translators
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUCTT] [审校]自由软件,自由社 会


From: monnand
Subject: Re: [GNUCTT] [审校]自由软件,自由社 会
Date: Wed, 29 Dec 2010 05:59:39 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7

Zoom.Quiet wrote, On 12/29/2010 04:06 AM:
在 2010年12月29日 下午4:45,monnand<address@hidden>  写道:
真抱歉,最近几天各种忙活。先回答一下ZQ的问题吧:
好象有些文档并没有翻译? e.g words-to-avoid.cn.html
掺合的基本问题:
- 如何反馈校对意见?

个人赞同Xiangfu的意见,先把.html转成.po。这个过程中必然会阅读一部分文章 内容,发现简单的错误就顺手改一下。

也就是说,在之前 tar 包释放的所有 FSFS 文章,没有翻译的也将在这次 po 转换中统一翻译?

没有翻译的就可以暂时忽略了。那个留待大家后来再翻译。只是针对已经翻译好 的。对于没有翻译和翻译了一半的,就算了。

- po 是标准的 软件i18N 模式,是否方便对文章进行处理?
- 我接触到的,多是零碎的界面词句的 po 翻译工程,对于有行文风格的文章,这种管理方式是否有助于所有参与成员快速掌握整篇文章的思想进行再创作?
- 建议使用 维基形式,永远以整体文章的形式来进行翻译和校对,也容易协同和统计贡献
     + code.google 的工程空间就内置一个可以通过版本管理系统 进行管理的维基
     + 在整体完成后统一转化成 po 汇入 GNU 空间?


这个流程有待讨论。目前我觉得有一下几个问题需要解决:
o 如果使用code.google的话,是否会产生不必要的版权问题。这个我目前还没有 看,需要看看与google的协议。 o 如果使用code.google,是否符合自由软件的精神。google code虽然也是一个自 由软件的发布平台,不过是否合得上GNU的胃口,就不好说了。这个也得考虑考 虑。作为GNU.org的官方中文翻译组,我们采用什么工具毕竟会产生一定的影响。 我希望这个影响是符合自由软件精神的。个人使用什么完全没问题,但是如果作为 我们小组的约定,我们使用的工具则需要考虑一下了 o 使用wiki的形式自然不一定使用code.google,不过维基的方式是否为大家所接 受,则有必要听听大家的意见
o 使用维基后如何转化为.po文件,倒也是个问题。虽然不大。

我个人表个态:凡是有利于提高生产力的,俺都喜欢。老实讲,比起直接编辑.po 文件,我觉得译言那样的方式倒是很不错。不过无论如何,后台的数据总归是要 用.po文件表示的。至于与翻译人员交互的界面是什么样,自然是越方便越好。可 能有人觉得emacs的po mode很不错,我也觉得很上手,不过我不能保证会有更好的 方式。

有些语句上的安排,用词等问题,个人觉得可以考虑发到邮件列表上,与翻译者本 人进行讨论。同时,大家也都能看到讨论的内容,提出自己各自的意见。

这个非常同意,也很 easy;只是辛苦作者要维护和统计这种讨论了:
- 每篇文章的初译者,先用[fsfs]创建个线索?
- 相应有兴趣的,对应回复讨论?


我的意见是:
校对在审校过程中,如果发现不能决定的地方,则*每处*翻译一个thread。审校结 束,再提交给翻译者本人查看。如果初译者觉得有些地方修改得不妥也是可以对* 每处*翻译一个thread。

所谓一处翻译,是指文章中的某句话,某个词。这样做比起一篇文章一个thread来 说,更加清晰。如果是一篇文章一个线索,那么可能这个线索内会同时讨论着多处 翻译,最终让整个主题分裂。劣势是一篇文章可能出现多个线索,让翻译人员和校 对无法准确找到各自负责的文章。个人建议对于这次审校工作,可以考虑使用以下 标签:
[FSFS][初译人][校对人]主题
以此来方便翻译人员和校对过滤。初译人和校对人的名字以savannah上的注册id为 准。如果没有在savannah上注册,则以邮件地址中的用户名为准。

对于其他参与讨论的人,则根据各自感兴趣的主题来讨论
...
这样做的原因如下:
  翻译工作本身是一次再创作的过程,对于翻译者本人,我希望能尽量尊重翻译 者的意见。因此,对于读者本人,可以对翻译人员说:我觉得你这样翻译不好。以
此来建议翻译人员修改他的翻译。但我不希望读者直接对翻译人员说:你应该这么 翻译。因为这样的话会影响了翻译人员的创造工作。当我们说一个翻译不好的时
候,意味着希望翻译人员再找到更好的翻译;而当我们说这个翻译必须是如此的时 候,则意味着翻译人员本身失去了一定的创作自由。当然,读者也可以建议某种翻
译形式,也可以让此翻译形式参与投票。

投票结果作为翻译人员和校对人员继续讨论的依据。对于某一个特定的翻译形式, 假如参与该处翻译讨论的(即,回复了这个thread的)人数为N,参与投票的人与
大于N/3(即,超过了三分之一的人参与了投票),且投``不满意''票的人数超过 了投票人数的一半(含),则该条翻译形式必须进行修改。


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


之所以折腾出这么复杂的程序,是调和以下互相矛盾的目的:
1. 翻译工作本身是一个创作过程。初译者本人应该对这个过程具有极大的自主权
2. 翻译的文章要提交到gnu.org上,作为官方的翻译,翻译质量必须有所保证

要满足条件1,则不得对翻译人员的工作进行任何干预,完全凭翻译人员本身来决 定。要满足条件2,则需要在有争议处尽量争取到读者的意见,根据读者投票表决。

我的基本思路是这样的:

上述两者都要满足,那么就是既要给初译者极大的自主权,又要保证翻译的质量。 这本身来说,是究竟要几分民主,几分自由的问题。因为我们无法保证初译者的初 译稿是足够好的,更无法保证初译者本人是全身心投入其中,或者初译者本人有着 某种恶趣味,与大众口味不符。所以我们必须要有这个审校过程。而审校过程本身 又不能无限制地持续下去,必须在一定时间后作出决定。对于决定的过程,我们优 先采用初译者本人的意见,如果该意见存在争议,进而请求投票表决,并且表决结 果证明多数读者对此翻译不满意,那么我们就要求初译者修改他的翻译。至于翻译 如何修改,改成什么样,这里留给译者,让他们有足够的创作空间。当然,其他 人,包括审校人员也可以提供修改意见,并且要求投票表决。初译者可以采用表决 的结果作为参考意见。而最终的选择权还是归初译者所有。读者(准确说,是参与 投票的人)只有权利说:我不喜欢!没有权利说:你应该如此!

在具体实施的过程中,由于条件限制,我们只能让小组内部人员参与投票,我们假 定小组内部人员的品味代表了大多数读者的意见。对于投票结果的判定,我们假定 在投票人数超过一定程度,并且不满意人数超过一定比例的情况下,认定该翻译不 可用。当然,前面提到的三分之一和二分之一的分法有些不合理,稍微做一下数学 运算就能看出来。有待讨论。

最后,因为不能让讨论无限制地进行下去,所以规定一个月内必须有结果,之后权 利以次交给初译者,审校人员和小组协调人。

有必要再加入几条:

o 如果审校人员提交了一个线索,要求讨论,而在提交了这条线索之后,翻译人员 一周内没有出现且给出个人意见,则在此处翻译上,校对的角色则转换为初译者。 即便之后初译者出现,在此处翻译上,校对本人将对其负责,具有初译者的权利。 换句话说,如果对于某处翻译,初译者没有对列表上的争议及时回复(时间以一周 为准),则自动认为他放弃对此处翻译的修改权。不过初译者依然可以作为普通成 员,参与讨论和投票,但不再对此处翻译具有决定权。在最终的翻译版本上,译者 依然是初译者。

o 为了防止协调员把翻译的地方出现口袋预案,规定协调员必须在翻译出现争议后 的2个月内给出最终修改意见。

o 关于投票:我个人最希望是无记名投票。达到这个目的倒也不难,对于列表上的 各位,估计一个下午就能从零开始,搭建一个匿名投票平台。不过这是否有必要还 是要看后面的操作。大家也可以发表意见。

o 关于协调员的指定:如果一处翻译在争论一个半月后依然没有决定,则交给协调 员做最终决定。目前我们翻译组有6个协调员(Project Admins),最好能够随机 指派一个协调员来处理某处的翻译,并且是匿名的。一周内没有结果再随机指派另 外一人。不过这是理想情况下了。是否能够做到匿名和随机也完全看是否有这个需求。

...
投票有效期为投票发起之日起后的一周时间。

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 包里,每个页面都是一段原文,一段译文,这种形式...
...

哦,这个形式肯定不是这样了。详细的翻译流程参考:
http://www.gnu.org/server/standards/README.translations.html





reply via email to

[Prev in Thread] Current Thread [Next in Thread]