在Mambo 汉化翻译的探讨(一) 的讨论中，没有多少人提意见，那就当翻译作品的版权归原版作者所有，反正这里都是开源系统的文档，遵循《GNU自由文档许可证》，大家都可以自由使用，至于版权属于谁应该无关紧要，不过汉化翻译者们可就辛苦了，大家更多的是付出！

在这项更多的是付出，却几乎没有任何实质收获的艰苦劳动中，却存在很多重复的工作，大家由于缺少交流和沟通，经常各自为政，多人各自汉化同一个系统的现象时有发生，结果出现了不同的汉化版本，不仅仅造成自身的重复劳动，也混淆了用户，真是吃力不讨好，很令人痛心。

为了杜绝重复劳动，使 Mambo 系统和插件的文档高效地进行翻译和汉化，我个人认为需要做好以下步骤：

1、建立术语库
2、收集要汉化的系统
3、分配任务
4、收集作品，发布
5、记录汉化者的工作成绩
  
上述5个步骤看起来很简单，执行起来却很难，主要表现在：
1、大家如何很好的沟通和交流？使用什么工具、手段？
2、收集和发布的工作很繁琐，如何简化？
3、很难详细区分和记录汉化者的工作成绩，比如有些是共同汉化，有些插件前后有多人汉化。

问题不只上面3条，望大家抽空探讨一下，共建良好的汉化翻译环境。

我的意见:
汉化是mambochina.net的核心内容(包含修改为中国使用习惯)

0.我认为交流应该还是通过论坛.建立汉化小组,及开办汉化项目专门论坛版块.仅为汉化小组成员专用.

1.首先是提案要规范化.例如A看到一个比较优秀的组件,想独立进行汉化或寻求合作者一起工作.那么A应在论坛发一贴.其内容应该详细介绍改组件的功能和使用感受,应以中文方式写出..便于快速了解该组件.格式待讨论.

2.如果已经有朋友B汉化过,或正在汉化中.B可以回帖进行沟通,并可以提供以完成或部分的汉化资源共享以加速A的汉化过程.

3.没有人汉化过但有人意向合作汉化,例如C和D,C和D可回帖沟通,发贴者A为该汉化项目的组长,可分配工作以进行良好的互相协助.

4.所有组件升级版本都应该在一贴内完成..例如AkoBOOK1.0汉化完成后,1.2的更新版本也应该回帖在该贴后. 组长应编辑主题贴,指明各版本所在页码.

5.汉化完成后有组长发布.需要写清楚所有参与汉化的朋友.也同时在主题贴指明各参与者的工作量.

6.LANG3根据汉化的组件的难度和工作量给组员分配波币.

这样我觉得比较有条理,过程也很清晰.

img 提议不错
最好是有个数据库记录下每次翻译的东西。。

何不直接加入Mambo本地化项目组？

引用:

原帖由 img 于 2005-7-13 21:17 发表
我的意见:
汉化是mambochina.net的核心内容(包含修改为中国使用习惯)

0.我认为交流应该还是通过论坛.建立汉化小组,及开办汉化项目专门论坛版块.仅为汉化小组成员专用.

1.首先是提案要规范化.例如A看到一个 ...

搞个CVS之流的版本管理系统如何？

或者采用Subversion？

现在好多开源项目改用Subversion管理。

[ 本帖最后由 yd_xzn 于 2006-1-12 22:02 编辑 ]

(来自：http://tech.ccidnet.com/art/1060/20041203/185163_1.html)

谈谈CVS由来与发展  
作者：北京信息工程学院 李宁 王慧思 发文时间：2004.12.03

    软件的开发和维护过程，离不开版本管理。对于一份文件，我们经常需要按不同的版本进行归档，或者从资料库里找出反映文件修改历史的不同版本。这样一方面可以使各个阶段的代码和文档变得井然有序，另一方面可以在当前版本出现问题的时候，找回先前的版本。当然，人们希望的还不止这些，例如，人们希望规定谁在什么时候可以如何存取某个版本的内容，也希望差异不大的版本按增量的方式存成一个文件，以节省存储空间……毫无疑问，我们需要一种对文件版本进行控制管理的工具，以有效地控制产品的质量，提高项目开发管理水平。

    CVS（Concurrent Versions System）就是一个能让很多程序开发者同时进行软件开发的、强大的版本管理控制工具。CVS并不是Internet的产物，而它的出现却是历史的必然。Richard Stallman倡导的开源软件运动大大加速了这一过程。

    起因

    开源软件的一个重要特点就是可以从世界任何地方获得代码和改进代码，这是传统软件开发所不具备的。这意味着开源软件的开发在全球开发者的协作下成为一个不间断的过程，每个人都可能成为开发队伍的一员，并且每个人都会随时流动。一个地域上分散的志愿者组织显然不能投入很多的时间来训练其成员彼此合作，这就需要一套项目管理办法，确保新成员能较容易地适应工作；同时有一个自动的机制接收外来代码，使每个成员能及时得到最新修改的代码。当然，这不仅仅是开源社区的需要，只是开源社区的人员分散、资源不易管理，更需要一个版本管理工具。这样的一个工具首先应该支持世界范围的协作，保持发布版本的一致性；其次它能够容易地汇集各个特定版本的Bug，并在全球范围同步一致地进行修改；再者它需要使任何一个开发者能够追踪软件的变化；而在开发者为软件增加新功能的同时，不能妨碍一般用户使用一个相对稳定的版本。

    CVS很好地解决了这一问题。 除了开发人员可以使用CVS很容易地把代码变化存入代码库之外，它还为不同角色的人员设置了不同的访问权限。例如，不需要修改代码的人员可以以匿名只读方式访问代码库。而需要修改代码的开发人员每个人都能在自己的机器上建立一个开发树，当需要在一个特殊的代码区工作时，首先通过简单的命令，使开发树获得更新，以保持全球范围开发状态的同步一致。这样就可以避免出现这样的问题：花了半天时间修改的Bug，在提交的时候发现别人已经解决了。一旦确认代码中的Bug别人还没解决，开发者可以马上开始工作。当这些问题解决后，CVS会自动产生补丁，并将补丁发送给维护人员进行检查，最后可能将其并入主项目树中去。

    发展历程

    早在CVS之前，就出现过对变化前后的文件进行比较，并根据异同形成“补丁”（Patch）的工具。例如，Unix上使用的Diff和Lany Wall写的Patch，这两个工具对程序代码的传播和维护起到了重要作用。但是，后来出现的许多要求Diff和Pach都显得无能为力，例如，发现修补出错而需要退回到以前未修改的状态等。这就要求有一个保存项目历史纪录的系统。

    当时初步具备这个功能的工具是SCCS（Source Code Control System），是贝尔实验室的Marc Rochkind在1972年写成的。SCCS是一种基本的源文件版本控制工具，适用于正文文件的版本维护。它基于单一文件的版本控制，代码库和要维护的文件通常在同一目录下。SCCS有一个专门的SCCS文件保留源文件的各编码版本，其中记录了足够的信息来恢复一个版本，并记录了谁对文件有修改权、有版本锁的功能。SCCS是AT&T Unix发行版的一部分。

    然而，自由软件项目最终选择了Walter F. Tichy的版本控制系统（RCS）来满足他们的需要。RCS在SCCS基础上加以改进，界面也更加友好，是BSD Unix发行版的一部分。它可以追踪文件的改变，在工作组中对文件的共享和访问进行控制，通常用于维护源代码；也能追踪文件的修改历史。RCS包含一套命令，用于设置RCS源码库中的文件属性、检入检出文件、清除文件、比较修订版本，以及合并文件等。由RCS管理的文件可以既可以是纯文本文件，也可以是二进制文件。

    然而，RCS仍存在几个重要缺陷，其中最主要的是由于使用单一目录控制与档案锁，无法让多个编程人员同时开发。因为RCS本身不是针对网络环境写的，开发者只能在RCS代码库所在的机器上工作，难以在分布式环境下开发。这些缺点后来在CVS中都得到了改进。1956年Dick Grune写了一段Shell脚本来简化RCS的使用。1986年10月，它的第6个发行版被放到USENET新闻组comp.soures.unix之中。1989年3月，Brian　Berlinor用C语言重新设计并编写了CVS的代码。后来，Jett Polk帮助Brian完成了CVS模型设计，增加了一些关键特性。1993年前后，Jim Kingdon最终将CVS设计成基于网络的平台，开发者们能从Internet任何地方获得程序源代码。

    特点

    CVS本身是开源项目，通过其方便的功能使众多的人们加入到开源软件项目之中，促进了开源运动的发展。反过来，开源项目的成功又促使版本管理工具不断完善。现在大多数开源软件项目都使用CVS做为版本控制和协作开发的工具，其中不乏像GNOME、KDE、Apache这样的庞大的项目，充分显示了CVS做为版本控制工具的成功。

    归结起来，CVS为开源项目做出的贡献大致有两点：一是由于它通过众人的参与使开源软件质量不断提高；二是它方便了全球软件工作者的协作，使软件成为全人类智慧的结晶。这大概就是今天CVS在自由软件世界中处于主导地位的原因了。

    尽管CVS的功能和使用方法看起来颇为庞大复杂，其实CVS最重要的只有两点，即记录保存和协作。人们有时要将一个程序的当前状态与先前某一状态做比较。例如，在为程序添加新功能的过程中，有人可能会通报试用版的Bug。为了找到问题之所在，一方面程序必须可以找回原来某时的可用状态。事实上，开发者可以简单地说一句，把以前程序的状态给我，或者说把最新公开发行的版本给我，这就是CVS对历史记录的保存作用。另一方面，CVS系统要顺利工作，开发者必须彼此知道在某个时刻准备做什么工作。CVS能够在代码提交的时候提醒开发者代码是否存在冲突；当某人因为权限问题不能工作的时候，彼此能很快地沟通。这就是CVS协同工作、跟踪冲突的能力。CVS的一般任务主要是访问已有的代码库、创建新项目、检出工作拷贝、进行更改、检测并解决冲突、浏览记录信息、检查并还原更改等。

    CVS现已成为广泛使用的版本管理系统，普遍应用在软件开发过程中，是基本的软件工程配置管理工具之一。不论是一个庞大的工程，如GNOME、Apache，还是个人开发一个小软件，都可以方便地使用CVS来管理开发过程，提高效率，方便管理。

(来自：http://tech.ccidnet.com/art/1060/20041203/185163_1.html)

创始者

    CVS的开发队伍共有18个人，其管理者都是对CVS的发展有过突出贡献的。CVS由开发者们共同决定如何发展，要做什么关键的改进。但是这个过程并不完全民主。仅在吸收新的开发成员时，须有多数人同意才行。其它方面大多不必如此，更不用投票。

    CVS主要开发者Jim Kingdon认为，在自由软件项目中过分民主会陷入无休止投票的泥潭，导致效率低下。而指定单一人员来维护，对于自由软件的开发来说是最通行、最成功的做法，当然也是倍受争议的。对于软件的每一处修改，需要这个维护人员的同意，也只能通过这个单一的维护人员授权给其它下层维护人员。诚然，开源软件的成功要依靠众人的参与，但是，愿意为软件效力的每个人并不都具备编码的水准，都了解局部改变和整体的关系，因此不能谁说了都算，而是要把目光集中在真正有可能给软件带来贡献的那些人身上。

    CVS走过了一段坎坷的路程。Jim Kongdon既是一个了不起的程序员，又具有商人的特质。Jim Kingdon毕业于美国俄亥俄州的Oberlin学院，之后曾为自由软件基金会（FSF）工作过。1993年之后，除了开发CVS之外，他还是Cygnus的工程师，为GDB修补Bug。他自己开过一个Cyclic公司。Cyclic是靠提供CVS支持服务来赚钱的公司。Jim Kingdon 1995年白手起家，到了1998年经营收入已达到了13.5万美元。离开Cyclic之后，Jim Kingdon在Red Hat工作了一年，后来频繁“跳槽”。2002年之后，他在加利福尼亚Fremont的Enlighta公司当程序员，为Web/SQL做测试。他的自我发展目标是甘愿当一个程序员，与同事、客户、合作伙伴一道创造和维护高质量的软件。他本人兴趣甚广， 除了编程，他还热衷太空市场，学习西班牙语、日语和世界语等。

    长期以来，Cyclic维护着CVS的“官方”网站http://www.cvshome.org/。但是，除少数人员的重合外，Cyclic和CVS的开发队伍基本上是独立的。1999年，Jim Kingdon突然宣布他要离开Cyclic去Red Hat工作，他将Cyclic卖给了Source Gear公司，同时Cyclic也发布了一个声明，说它不再正式支持CVS。这带来一场不小的震动。

    Source Gear也是一家销售和维护软件的公司，它希望能够作为CVS的供应商，使CVS变得有利可图，最终成为CVS发展的领头羊。尽管实际情况不尽人愿，一些CVS的开发者并不买他们的账，但Source Gear还是为CVS做了一些实质性的工作。而CVS的开发者迅速成立了一个新的项目CVS Continuity Project，其目的是使CVS开发、维护工作能够继续正常进展下去。现在CVS的网站挂在Yankee Group麾下CollabNet公司的SourceCase网站上，SourceCase是专门为全球志愿的开发人员协同开发软件提供的Web空间。

    除了Jim Kingdon以外，CVS开发队伍中的一些关键人物是：
    ◆Steve Willer为CVS社团做了大量的服务工作，在邮件组中回答各种问题，并向开发团队报告具有共性的Bug。
    ◆Pascal Molli负责网站http://www.loria.fr/~molli/cvs-index.html的维护。这个网站上面放着最新版本的CVS和各种CVS文档，以及与相关资源的链接等。
    ◆David Klann维护着info-cvs MINI-FAQ（常见问题解答），并定期更新。这个FAQ链接着各个相关的地址，提供各种公众需要的信息。
    ◆David W. Eaton维护着comp.software.config-mgmt FAQ。这是一项艰巨的工作，因为他试图把整个配置管理领域都囊括进去，而不仅仅是CVS。

    版本与相关项目

    目前，最新的CVS版本是2004年3月13日发布的1.12.6，稳定版本是2004年3月11日发布的1.11.14。CVS支持的平台包括Windows 32、Linux和Unix等。

    CVS有多个发展方向，相关的开发项目主要有：
    ◆Anonymous CVS Access Via ssh 加强CVS的安全。
    ◆Bonsai 为CVS增加基于web的图形界面。
    ◆CHalogen The Change Log Generator，产生HTML形式的变化日志。
    ◆Component Software CVS for Windows Windows平台下的CVS前端。
    ◆CVS Access Control List Extension 为CVS远程代码库增加ACL访问控制。
    ◆CVS Code Historian 在MS VisualStudio或浏览器中，利用CVS记载的信息进行文件比较或分析。
    ◆CVS for MVS 把CVS移植到MVS/OS390/USS主机。
    ◆CVS Monitor CVS代码库浏览器。
    ◆CVS version control for web development 为Web开发者写的CVS工具。
    ◆CVS via FTP 通过FTP实现CVS网站镜像。
    ◆cvs2cl CVS日志转换。
    ◆cvsdude 在Windows和类Unix客户端平台上用命令行访问CVS。
    ◆CVSGrab 通过防火墙获得CVS树。
    ◆cvs2html 将CVS日志转成HTML格式。
    ◆cvsknit A CVS automation suite，粘合多个CVS代码库的自动工具。
    ◆cvslock 维护和检视多个代码库，保持同步。
    ◆CVSNT 在Windows NT/2000下运行的CVS服务器。
    ◆Cvsplot 为CVS控制的文件提供统计信息。
    ◆CVSSearch 通过CVS命令来检索代码片断的工具。
    ◆CVSspam Notification of CVS committs, by email。当CVS有变化提交时发出E-mail。
    ◆CVSSupport 用Perl写的CVS工具。
    ◆CVSToys CVS变化提交时的通知工具。
    ◆CVSTrac 基于Web的Bug和补丁跟踪系统。
    ◆CVSup 通过网络发布和更新批量文件的软件包。
    ◆CVSweb for Windows 95/NT/2000 为在Windows PWS/IIS上运行CVS Web提供的指令。
    ◆CVSweb (Henner Zeller version) 用Perl脚本通过RCS命令为CVS加上Web接口。
    ◆StatCvs 产生HTML和PNG格式的CVS代码库的统计信息。
    ◆ViewCVS 用Python写的类似CVS Web工具。
    ◆ViewCVS for Windows ViewCVS到Windows平台的移植，运行于IIS。

    要想了解关于CVS更多的信息，可以参看下面的网址http://www.cvshome.org；http://www.loria.fr/~molli/cvs-index.html；http://www.soforge.com/cvsdoc/zh_CN/book1.html；http://cvsbook.red-bean.com/；http://cvsgui.sourceforge.net/。

    CVS是一个广泛使用的版本控制系统，随着互联网的普及，分布在世界各地的程序员会越来越多地采用它进行版本控制和开发。（T111）

Subversion比CVS更好用

(来自：http://tech.ccidnet.com/art/739/20041116/177827_1.html)

作者：顾宏军 发文时间：2004.11.16

    长久以来，在开源世界中，CVS（Concurrent Versions System）一直都是版本控制的首选。但是现在用户有了另一个选择，就是Subversion。Subversion是下一代版本控制系统，能替代CVS，项目主页是http://subversion.tigris.org。

    Subversion是一个自由、开放源码的版本控制系统。它是一个通用系统，可用来管理任何类型的文件， 其中包括程序源码。

    它的初始目标很明确，实现绝大部分CVS的已有功能；充分考虑现有的CVS用户，在使用方式上模仿CVS，同时开发了一系列工具，使得基于CVS的项目能够顺利迁移到Subversion上。和CVS相比，它有很多优点，例如目录版本控制、不可分割的提交、一致的数据处理方式和更有效率的分支与标记等。

    安装与初始化

    Subversion建立在一个可移殖的APR (Apache Portable Runtime，链接库)上。这使得Subversion可以工作在任何可以执行Apache的操作系统上。

    Subversion有两种运行方式，一是可以作为Apache 2.0的一个模块， 以WebDAV/DeltaV协议与外界连通；另外，也可使用Subversion 自带的小型服务器程序。该程序使用的是自带的通讯协议， 可以很容易地透过SSH以tunnel方式使用。

    最简单的安装Subversion的方法就是使用其提供的二进制版本（在项目网站上，有RPM、DEB和PORTS等格式的文件下载）。根据系统选择下载所需的文件，这里使用的Red Hat，所以选择了RPM格式。

#rpm -Uvh apr-0.9.5-0.2.i386.rpm
#rpm -Uvh apr-devel-0.9.5-0.2.i386.rpm
#rpm -Uvh apr-util-0.9.5-0.1.i386.rpm
#rpm -Uvh apr-util-devel-0.9.5-0.1.i386.rpm
#rpm -Uvh neon-0.24.4-1.i386.rpm
#rpm -Uvh neon-devel-0.24.4-1.i386.rpm
#rpm -Uvh subversion-1.0.0-1.rh90.i386.rpm
#rpm -Uvh subversion-devel-1.0.0-1.rh90.i386.rpm
#rpm -Uvh subversion-server-1.0.0-1.rh90.i386.rpm
#rpm -Uvh subversion-tools-1.0.0-1.rh90.i386.rpm



    设置环境变量，命令如下：#export EDITOR=vi

    创建文件库，命令如下：#svnadmin create /opt/proj/fox

    将目录doc的内容，直接导入至文件库的fox目录里，命令如下：#svn import /root/doc file:///opt/proj/fox

    Subversion组件

    安装好之后，Subversion 会有数个不同的工具，主要分为客户端组件和服务器组件两类。

    客户端组件供使用者使用，主要包括以下两个组件：
    svn 是命令行客户端程序，用来管理数据。
    Svnversion 用来查看工作拷贝的混合版本状态。

    服务器组件供管理员使用，包括以下几个组件：
    svnlook 用来查看Subversion的文件库的工具。
    Svnadmin 用来创建与调整Subversion的文件库的工具。
    mod_dav_svn 给Apache2.0网页服务器使用的模块；可以用来将用户的文件库透过网络对外开放。

    Svnserve 一个独立的服务器程序，可以作为服务器进程执行，或是被SSH启动，让用户的文件库在网络上可供其它人存取的方法。

(来自：http://tech.ccidnet.com/art/739/20041116/177827_1.html)

优势所在

    Subversion在使用方式上与CVS相像，但是某些新的功能与设计和CVS是有区别的。下面谈谈两者的区别，让用户切实感受Subversion的优势。

    不同的修订版号
    在CVS中，每个文件修订版号是不同的。这是因为CVS基于RCS。每一个文件在文件库都有对应的RCS文件，而文件库的结构，大致上就是依照目录结构展开。

    目录版本
    Subversion也会追踪文件树结构，而不只是文件内容。Subversion中目录像文件一样，也有修订版号。“svn add”与“svn rm”命令可在目录上使用，就像在文件上使用一样。“svn copy”与“svn move”也是如此。但是这些目录不会马上让文件库有任何的变化。相反地，工作项目只是“预定”要被新增或删除。除非用户执行“svn commit”，不然文件库不会有任何变动。这一点有点像Windows下删除文件，只是在fat表作删除标记，而未真删除。

    离线功能
    Subversion的工作副本是针对网络带宽瓶颈做优化。.svn与CVS目录一样，都是管理用的目录，但是svn还多存放了文件的原始副本。这让用户能够离线进行许多事，举例如下：
    “svn status”显示本地更新；
    “svn diff”显示详细的更新细节；
    “svn revert”移除用户的本地更新。
    另外，Subversion客户端在提交文件副本时只传送差异。这点是CVS没有的。


区分状态与更新
    在Subversion中，我们试着要解决“cvs status”与“cvs update”命令之间的混淆不清。“cvs status”命令有两个目的，一是显示使用者在工作副本中的本地更改；二是显示使用者过时的文件。但是CVS显示的内容不易理解，许多CVS的使用者完全无法善用这个命令。取而代之地，就是执行“cvs up”来看他们的更新。
    Subversion试着让“svn status”输出的数据易于让人理解，来解决上面这个问题。另外，“svn update”只会显示被更新的文件信息，而不会显示本地的更新。

    属性
    Subversion的一个新功能，就是用户可以将任何的资料附加到文件与目录上。这些资料被称为属性。用户要设定或取得属性的名称，可使用“svn propset”与“svn propget”命令；要列出一个对象上所有的属性，可使用“svn proplist”命令。

    冲突消解
    CVS会在文件内放置“冲突标记”，将冲突地方标示出来，但CVS做得并不够。许多使用者记不住（或没看清）在终端上快速闪过的带有冲突标志的代码。
    Subversion解决这个问题的方法是让冲突更明确地标示出来。它会记得文件处于冲突的状态中，除非用户执行了“svn resolved”命令，否则它不会允许用户提交。

    二进制文件与文本文件
    Subversion比CVS更善于处理二进制文件。 因为CVS使用RCS的关系，所以对于一个变动中的二进制文件，它将每个更新的副本都储存下来。但是Subversion不管文件是文本还是二进制类型，在内部都是以二进制差异比较算法来表示文件的更新部分。这表示所有的文件在文件库中都是以差异的形式储存。而且在网络上传输的，都是较小的文件差异部分。
    CVS使用者必须以“-kb”标记二进制文件。Subversion不进行任何的关键词或列尾符号转换，除非用户要求这么做。Subversion内部会维护文件是否为“文本”或“二进制”文件的记录，将其保存在工作副本中。在执行“svn update”的过程中，Subversion 会对本地的文本文件进行内容合并，但是不会对二进制文件做这样的事。

    小结

    Subversion有一份很好的文档——《Version Control with Subversion》（http://svnbook.red-bean.com/）。它提供了有关Subversion的各方面内容，如使用、管理和开发等。

    经过数年的开发，以替代CVS为目标的Subversion，终于出了1.0版本。相信以其强大的功能，对CVS良好的继承性，一定会有很好的发展。（T111）

版本管理，用CMVC如何？：）

建议建一个类似于版本控制的构件,确切地说是简化的版本控制的构件,来解决目前因为不统一而造成的人力资源浪费的现象.制定一些较规范的规则,让各个开源爱好者能正确地有目的性的不重复别人的贡献自己一份力量.
最好能再建一个QQ群.

太麻烦了，我觉得大家充分利用现有条件，如本站wiki，
1，有人组织，在wiki上进行分类，对各组件英需要翻译部分，直接贴到上面（不适合组件，仅适合组件相关文档汉化）但应该对已翻译部分（指程序）进行修正调整
2、我刚刚在上面写了关于facileforms组件部分内容，（仅仅是框架）本人文化程度不高，英语就更差，都是用词霸凑合的，仅仅是抛砖引玉，希望高手参加，完善
3、就我这菜鸟都在上面胡写乱画。－－－重要的是行动！