Author: rocksun
Date: Sat Oct 25 05:03:33 2008
New Revision: 1534
Log:
Modify some mistakes make build failed.
Modified:
trunk/zh/book.xml
trunk/zh/ch02.xml
trunk/zh/ch03.xml
trunk/zh/ch04.xml
trunk/zh/dedication.xml
Modified: trunk/zh/book.xml
==============================================================================
--- trunk/zh/book.xml (original)
+++ trunk/zh/book.xml Sat Oct 25 05:03:33 2008
@@ -29,6 +29,8 @@
<authorgroup>
<author><firstname>Karl</firstname><surname>Fogel</surname>
<contrib>(Author)</contrib></author>
+ <author><surname>（Rock Sun）</surname><firstname>孙岱军</firstname>
+ <contrib>(Translator)</contrib></author>
<author><surname>（Wang Peng）</surname><firstname>王 芃 </firstname>
<contrib>(Translator)</contrib></author>
<author><surname>(Zissan)</surname><firstname>管 清</firstname>
Modified: trunk/zh/ch02.xml
==============================================================================
--- trunk/zh/ch02.xml (original)
+++ trunk/zh/ch02.xml Sat Oct 25 05:03:33 2008
@@ -293,8 +293,8 @@
<para>但很不幸，你不可能在项目的开始就完成FAQ，好的FAQ不是写成的，而是长成的。它们是通过定义反应文档，随着人们对软件的日常使用而进化。因为不能预感到用户将会提出的问题，所以我们无法从头开始编写有用的FAQ。</para>
-
<para>因此，不要在这方面浪费时间了。但无论如何，你或许会发现创建一个FAQ的空白模板会很有用，很明显这样可以帮助人们在项目进行中贡献问题和答案。此时，最重要的性质不是完整，而是方便：如果添加FAQ非常简单，人们就会去添加。（正确的FAQ维护应该是特殊和迷惑性的问题，将会在<xref
linkend="managing-volunteers"/>的</phrase><xref
- linkend="faq-manager"/><phrase output="printed">详细讨论。）</para>
+
<para>因此，不要在这方面浪费时间了。但无论如何，你或许会发现创建一个FAQ的空白模板会很有用，很明显这样可以帮助人们在项目进行中贡献问题和答案。此时，最重要的性质不是完整，而是方便：如果添加FAQ非常简单，人们就会去添加。（正确的FAQ维护应该是特殊和迷惑性的问题，将会在<xref
linkend="managing-volunteers"/><phrase output="printed">的</phrase><xref
+ linkend="faq-manager"/>详细讨论。）</para>
</sidebar>
<sect3 id="documentation-availability">
Modified: trunk/zh/ch03.xml
==============================================================================
--- trunk/zh/ch03.xml (original)
+++ trunk/zh/ch03.xml Sat Oct 25 05:03:33 2008
@@ -117,7 +117,7 @@
<varlistentry><term>审核特性</term>
<listitem>
-
<para>在邮件发送到整个列表之前的“审核”是检查邮件以确保：a) 不是 垃圾邮件，以及b) 符合 主题。审核必须有人参与，但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para>
+
<para>在邮件发送到整个列表之前的“审核”是检查邮件以确保：a) 不是 垃圾邮件，以及b) 符合 主题。审核必须有人参与，但软件能很大程度的使之变得容易。后面还有关于审核的更多内容。</para>
</listitem>
</varlistentry>
@@ -575,7 +575,7 @@
<sect2 id="vc-choosing">
<title>选择一个版本控制系统</title>
-<para>在写本文的时候，自由软件世界中两个最流行的版本控制系统是<firstterm>并行版本系统</firstterm>（firstterm>CVS</firstterm>，<ulink
url="http://www.cvshome.org/"/>）和<firstterm>Subversion</firstterm>（<firstterm>SVN</firstterm>，<ulink
url="http://subversion.tigris.org/"/>）。</para>
+<para>在写本文的时候，自由软件世界中两个最流行的版本控制系统是<firstterm>并行版本系统</firstterm>（<firstterm>CVS</firstterm>，<ulink
url="http://www.cvshome.org/"/>）和<firstterm>Subversion</firstterm>（<firstterm>SVN</firstterm>，<ulink
url="http://subversion.tigris.org/"/>）。</para>
<para>CVS已经存在很长时间了。大多数有经验的开发者已经熟悉了它，它或多或少满足了你的需要，而且因为它已经流行了很长时间了，你可能不会陷入它是否是正确选择的争论。CVS有一些缺点，它不支持简单的引用多个文件的变更；它不支持版本控制下的（这样如果你需要识别出项目开始后的代码树，会非常头痛）文件重命名和拷贝；它对合并的支持很弱；它处理大文件和二进制文件不佳；以及在操作很多文件时操作会非常慢。</para>
Modified: trunk/zh/ch04.xml
==============================================================================
--- trunk/zh/ch04.xml (original)
+++ trunk/zh/ch04.xml Sat Oct 25 05:03:33 2008
@@ -1,98 +1,26 @@
<chapter id="social-infrastructure">
-<title>社会和政治的基础架构Social and Political Infrastructure</title>
+<title>社会和政治的基础架构</title>
<simplesect>
-<para>有关自由软件，人们经常问道的第一个问题是：“它是怎么做的？什么在推动计划运行？
-谁来做决定？”The first questions people usually ask about free software are
-"How does it work? What keeps a project running? Who makes the
-decisions?" I'm always dissatisfied with bland responses about
-meritocracy, the spirit of cooperation, code speaking for itself, etc.
-The fact is, the question is not easy to answer. Meritocracy,
-cooperation, and running code are all part of it, but they do little
-to explain how projects actually run on a day-to-day basis, and say
-nothing about how conflicts are resolved.</para>
-
-<para>This chapter tries to show the structural underpinnings
-successful projects have in common. I mean "successful" not just in
-terms of technical quality, but also operational health and
-survivability. Operational health is the project's ongoing ability to
-incorporate new code contributions and new developers, and to be
-responsive to incoming bug reports. Survivability is the project's
-ability to exist independently of any individual participant or
-sponsor—think of it as the likelihood that the project would
-continue even if all of its founding members were to move on to other
-things. Technical success is not hard to achieve, but without a
-robust developer base and social foundation, a project may be unable
-to handle the growth that initial success brings, or the departure of
-charismatic individuals.</para>
-
-<para>There are various ways to achieve this kind of success. Some
-involve a formal governance structure, by which debates are resolved,
-new developers are invited in (and sometimes out), new features
-planned, and so on. Others involve less formal structure, but more
-conscious self-restraint, to produce an atmosphere of fairness that
-people can rely on as a <foreignphrase>de facto</foreignphrase> form
-of governance. Both ways lead to the same result: a sense of
-institutional permanence, supported by habits and procedures that are
-well understood by everyone who participates. These features are even
-more important in self-organizing systems than in centrally-controlled
-ones, because in self-organizing systems, everyone is conscious that a
-few bad apples can spoil the whole barrel, at least for a while.</para>
+<para>有关自由软件，人们经常问到的第一个问题是：“它能行吗？如何运作一个项目？谁来做决定？”我一直对关于知识界精化、合作精神、代码会说话此类的平淡回复不感兴趣，事实是这个问题很难回答，知识界精化、合作精神和运行代码只是其中的一部分，但它们对于解释日复一日的项目运转贡献不多，对于如何解决冲突什么也没说。
+</para>
+
+<para>本章尝试展示支持成功项目的共同结构，“成功”不仅仅指的技术质量方面，而且也包含了运行健康状况和生存性。运行健康状况是指项目将新代码和新开发者吸收进来，并对到来的bug负责的持续能力。生存性是项目独立于任何单独参与者或赞助商而存在的能力—考虑一下如果项目所有的创始成员离开后项目继续运作的可能性。技术成功不难实现，但是如果没有健壮的开发者基础和社会基础，一个项目就不能处理由初始的成功带来的成长，或者有魅力个体的离开。</para>
+
+<para>获取此类成功有很多方法。有些涉及正式的管理结构，通过哪些争论被解决、新开发者被邀请加入（有时是离开）和计划的新特行等等。还有一些涉及不太正式的结构，但需要更有意识的自我克制，来产生一种人们可以依赖的正直氛围，作为<foreignphrase>事实上的</foreignphrase>管理形式。两种方式都产生相同的结果：一种由来已久的永恒感觉，由所有参与者都充分理解的习惯和程序作为支撑。这些特性在自我组织的系统中甚至比集中控制的系统更重要，每个人都知道一个坏苹果可以毁掉一桶，即使只是一会儿。</para>
<sect1 id="forkability">
-<title>Forkability</title>
+<title>分叉能力（forkability）</title>
+
+<para>能将开发者绑定在一个自由软件项目中的必需组成部分，能让他们在必要时愿意作出妥协，是代码的<firstterm>分叉能力</firstterm>：也就是任何人可以使用一个拷贝并使之成为一个竞争项目的能力，被称为<firstterm>分叉</firstterm>。怪异的是自由软件项目的中分叉<emphasis>可能性</emphasis>具备比实际的分叉更大的动力，很少会发生。因为分叉对于每个人都不好（<phrase
output="printed"><xref linkend="managing-volunteers"/>的</phrase><xref
linkend="forks"/>会解释详细原因），分叉的威胁越大，越期望的人就越会妥协去避免它。</para>
+
+<para>分叉，更确切说是分叉的可能性，是自由软件项目中没有真正独裁者的原因。考虑到在一个特定开源项目中听到某人被称为“独裁者”或者“暴君”是多么常见，这看起来是一个令人惊讶的断言。但是此类暴政是特别的，与一般意义上的字面理解非常不同。想象一下一个国王的臣民可以在任何时候复制整个王国，并搬过去按自己满意的规则统治。这与国王无论如何做，臣民都无法离开的情况是多么的不同？</para>
+
+<para>这也是为什么即使项目不是完全按照民主方式组织时，在实践中，重要决定还是通过民主方式产生。可复制性暗指了分叉能力；分叉能力暗指了意见一致。也可能是每个人都希望与一个领袖不同（最有名的例子是在Linux内核开发中的Linus
Torvalds），但那是因为他们<emphasis>选择</emphasis>如此，以一种非愤世嫉俗和非邪恶的方式。暴君没有项目的定身法，所有开源许可证都有一个关键特性，也就是在代码如何变更或使用上没有给任何组织更多的权力，如果一个独裁者突然开始做了一个坏的决定，就从此不得安宁，紧接着就是造反和分叉。除非，当然，很多时候不会到这一步，因为独裁者会首先妥协。</para>
-<para>The indispensable ingredient that binds developers together on a
-free software project, and makes them willing to compromise when
-necessary, is the code's <firstterm>forkability</firstterm>: the
-ability of anyone to take a copy of the source code and use it to
-start a competing project, known as a <firstterm>fork</firstterm>.
-The paradoxical thing is that the <emphasis>possibility</emphasis> of
-forks is usually a much greater force in free software projects than
-actual forks, which are very rare. Because a fork is bad for everyone
-(for reasons examined in detail in
-<xref linkend="forks"/><phrase output="printed"> in
-<xref linkend="managing-volunteers"/></phrase>), the more serious
-the threat of a fork becomes, the more willing people are to
-compromise to avoid it.</para>
-
-<para>Forks, or rather the potential for forks, are the reason there
-are no true dictators in free software projects. This may seem like a
-surprising claim, considering how common it is to hear someone called
-the "dictator" or "tyrant" in a given open source project. But this
-kind of tyranny is special, quite different from the conventional
-understanding of the word. Imagine a king whose subjects could copy
-his entire kingdom at any time and move to the copy to rule as they
-see fit. Would not such a king govern very differently from one whose
-subjects were bound to stay under his rule no matter what he
-did?</para>
-
-<para>This is why even projects that are not formally organized as
-democracies are, in practice, democracies when it comes to important
-decisions. Replicability implies forkability; forkability implies
-consensus. It may well be that everyone is willing to defer to one
-leader (the most famous example being Linus Torvalds in Linux kernel
-development), but this is because they <emphasis>choose</emphasis> to
-do so, in an entirely non-cynical and non-sinister way. The dictator
-has no magical hold over the project. A key property of all open
-source licenses is that they do not give one party more power than any
-other in deciding how the code can be changed or used. If the dictator
-were to suddenly start making bad decisions, there would be
-restlessness, followed eventually by revolt and a fork. Except, of
-course, things rarely get that far, because the dictator compromises
-first.</para>
-
-<para>But just because forkability puts an upper limit on how much
-power anyone can exert in a project doesn't mean there aren't
-important differences in how projects are governed. You don't want
-every decision to come down to the last-resort question of who is
-considering a fork. That would get tiresome very quickly, and sap
-energy away from real work. The next two sections examine different
-ways to organize projects such that most decisions go smoothly. These
-two examples are somewhat idealized extremes; many projects fall
-somewhere along a continuum between them.</para>
+<para>但分叉能力放置了一个上限（一个人在一个项目中发挥多少力量的上限）并不意味着项目的管理方式没有太大的区别。你不会希望每个决定都是某人要考虑分叉后的结果，下面两个小节会仔细检查组织项目平稳做出大多数决定的不同方法，这两个都是极端理想的例子；许多项目会处于中间状态。</para>
</sect1>
@@ -100,7 +28,7 @@
<!-- ======================== SECTION ============================== -->
<sect1 id="benevolent-dictator">
-<title>Benevolent Dictators</title>
+<title>慈善独裁者</title>
<para>The <firstterm>benevolent dictator</firstterm> model is exactly
what it sounds like: final decision-making authority rests with one
Modified: trunk/zh/dedication.xml
==============================================================================
--- trunk/zh/dedication.xml (original)
+++ trunk/zh/dedication.xml Sat Oct 25 05:03:33 2008
@@ -1,7 +1,7 @@
<dedication id="dedication">
-<para><emphasis>�Ȿ�����ҵ���λ�����ѣ��Ҳ������������ǣ�Karen
-Underhill��Jim Blandy��</emphasis></para>
+<para><emphasis>这本书献给我的两位好朋友，我不可能忘掉他们：Karen
+Underhill和Jim Blandy。</emphasis></para>
</dedication>
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
