发布一个Python的协同文档翻译平台
金浩
关于本协同文档翻译平台：
本协同文档翻译平台基于 Python+Django 搭建，目前主要专注于Python及其相关项目的文档翻译，同时也不排除以后组织翻译其他项目的文档的可能性。
智能分段，协同翻译：将一篇文档分段成多个具有足够上下文信息的段落，通常表现为 段落标题+段落内容 的形式。
Zoom.Quiet
> 网址：http://docspot.org/
> 关于本协同文档翻译平台：
sooooo great !
中文技术领域的确需要统一方便的文档维护平台！
而且可以进一步和出版社对接，形成快速的出版渠道！
建议精心运维和哲思联合，作大作深！
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Time is unimportant, only life important!
金浩
Can Xue
默认字号有点小，标点符号不易辨认。
--
XUE Can
金浩
如果不自动换行，出现横向滚动条的话会在看原文时比较麻烦。
其实像Django的REST文档写的比较好，在快每行超过80个字符时，他们都是手动换行了。
目前已经调大了一号字体。
Can Xue
因为需要在有限的宽度内同时显示原文和翻译区域，所以字体设的太大的话会导致很多不必要的自动换行。
如果不自动换行，出现横向滚动条的话会在看原文时比较麻烦。
其实像Django的REST文档写的比较好，在快每行超过80个字符时，他们都是手动换行了。
目前已经调大了一号字体。
明白，至少目前可以分清标点符号了。
你这个系统是如何处理原文的版本更新的呢？
--
XUE Can
金浩
如果提供其他方式比如hg，或下载地址的，就先通过各种方式下载到本地，然后在本地建一个svn仓库，对这些文档再使用SVN进行版本控制。
所以最后只需要通过pysvn这个库，来取得版本信息和版本间的变化就可以将SVN中的文档与数据库间进行同步了。
Can Xue
如果项目文档本身是提供SVN的访问方式就从svn下载文档，
如果提供其他方式比如hg，或下载地址的，就先通过各种方式下载到本地，然后在本地建一个svn仓库，对这些文档再使用SVN进行版本控制。
所以最后只需要通过pysvn这个库，来取得版本信息和版本间的变化就可以将SVN中的文档与数据库间进行同步了。
获取最新版本的原始文件并不困难，我想了解是否采用了某种机制能够合并已翻译的文档和更新了的源文档？
比如，基于 libintl 的 i18n，类似 poEdit 这样的工具允许你打开一个已经翻译好的 .po 文件，当源代码升级时，我们可以生成一个新的 .pot 模板文件，然后使用类似“从 POT 文件更新”的功能合并新的版本，一致的将被保留，新的为翻译的条目将被添加，不复存在的条目将被删除……
当然，对于文档的翻译，由于源文档制作了一点修改（比如修正拼写错误）就删除相应条目要求重新翻译代价有点大，这时候是否可以采用某种模糊匹配的机制，列出系统猜测的可能的翻译或者自动运用这些翻译并进行某些标记？
--
XUE Can
@@
金浩
--
XUE Can
Can Xue
是的，在一个文档进行了更新时，从每个文档分离出的段落会先寻找是否在数据库中存在完全匹配的段落，如果没找到，再寻找是否有接近匹配的段落，如果有则原段落作为新段落的历史记录，同时如果原段落有相应翻译的话，最后一个翻译结果页会带给新段落。
赞！
如果感兴趣，具体步骤可以看整理后发布的源代码。
期待源码的发布。
--
XUE Can
大郎
--
百才招聘(baicai.com).产品部
Email: k...@baicai.com
Gtalk: qicha...@gmail.com
twitter.com/qichangxing
soldier
金浩
soldier
柠檬园主
这个的平台很不错的，只可惜也是英文文档更新更跟上，对应的英文版那边已经出django1.0的了，而这边的文档还是基于0.96的。
但这个平台的协同翻译方法我个人比较喜欢。
On 6月14日, 下午2时14分, 金浩 <jinhao7...@gmail.com> wrote:
> 界面只是直接取自django的admin后台的CSS，不过那个界面作为后台管理的确很通用。
>
> 2009/6/14 soldier <8863...@gmail.com>
>
>
>
> > 个人觉得做得很赞， 界面很喜欢。
> > 界面一直是我个人的一大难题。
>
> > 2009/6/13 大郎 <qichangx...@gmail.com>:
> > > 2009/6/13 金浩 <jinhao7...@gmail.com>
>
> > >> 网址：http://docspot.org/
>
> > > 呀，做得很好啦，不过有很多重复的项目，要是看到这些作者们能够合并来做这个平台就好啦。
> > > --
> > > 百才招聘(baicai.com).产品部
> > > Email: k...@baicai.com
> > > Gtalk: qichangx...@gmail.com
taotao
On 6月13日, 下午3时32分, 金浩 <jinhao7...@gmail.com> wrote:
> 网址：http://docspot.org/
>
> 关于本协同文档翻译平台：
> 本协同文档翻译平台基于 Python+Django
> 搭建，目前主要专注于Python及其相关项目的文档翻译，同时也不排除以后组织翻译其他项目的文档的可能性。
>
> 目前已经有Django，Google App
> Engine，Jinja2，Pylons，PyMOTW，Python，Sphinx，SQLAlchemy，TurboGears这几个项目的翻译，其他翻-译项目将陆续增加。
> 虽然其中某些文档已经有人翻译或部分翻译过了，但是与其他项目的情况不同，这将是一个长期的项目，并且将集各种Python文档与一个平台上，方便资料的查找。
> 并且对于已经有人翻译过的文档，我将会尽可能将这些已有翻译转换到这个新的平台上。
>
> 平台特点：
> 智能分段，协同翻译：将一篇文档分段成多个具有足够上下文信息的段落，通常表现为 段落标题+段落内容 的形式。
> 版本控制，同步更新：英文文档是在不断变化中的，中文文档也需要及时跟进，所以对英文文档进行了版本变化的跟踪，使中文的翻译过程与英文文档的更新可以同步进行-。
> 格式输出，即翻即转：Python及其相关项目的文档通常采用Sphinx或reStructuredText的格式进行编写，翻译时的格式也是一样，所以可以-输出成和英文文档相同的多种格式。同时对于翻译的文档也是翻译后马上可以看到HTML格式输出的效果。
金浩
2009/6/14 金浩 <jinha...@gmail.com>:> 关于这是一定有方法的,而且,当前DB为主的文档管理正式会造成最终图书发布环境的DB依赖也不是最好的数据管理方式;
>
> + 但是在线翻译模式应该追加透过版本系统的离线模式:
> - 不会 SVN/Hg/Git 等等版本系统的普遍人,使用在线正式进行贡献
> - 有项目体验的,通过版本系统提交文件来进行贡献,并自然形成版本(而不是DB中的)
> 这一点，我记得以前似乎就因为有人喜欢Web方式，有人喜欢透过版本系统直接分成了2派，各自翻译相同的东西。
>
> 而且在一个平台上实现上Web方式和版本系统方式共存也很难实现，
> 因为翻译后的文本一个是透过Web直接存入数据库的，一个是普通的文本文件，很难将两者的翻译结果有效的合并。
>
- 没有数据一致性的保证
- 和 Sphinx 实例形式相差太远
至少有几个融合的方向:
1. DB为主:
+ 每个修订自动输出成文件并检入SVN中;
+ 使用SVN的用户不直接检入生产仓库,而是分支,再次通过DB后才可以检入自动编译用的生产仓库;
好处是对当前系统变更小,而且SVN的冲突管理也令高级用户可以及时获得更新,进行主动修订;
问题是原版图书文件升级后,无法方便的汇入DB;
2. SVN为主:
+ SVN用户的修订直接驱动编译脚本生成最终页面
+ 页面用户的修订通过DB合并成文件后,检入SVN 从而完成编译
好处是版本是自然和绝对的,吻合高级用户习惯;也容易升级原版内容,或是追加新图书;
问题是两种用户的内容同步复杂;需要修订代码...
3. 只用SVN:
+ 自动编译通过 SVN HOOKS 驱动,一但有正确检入就自动编译对应图书;
+ 网页用户实际操作文件,而不是DB字段
好处是数据统一和简单以及标准化了!
问题是段落的分析和处理也必须文件化,需要修订代码...
>
> 2009/6/14 Zoom.Quiet <zoom....@gmail.com>
>>
>> 2009/6/14 金浩 <jinha...@gmail.com>:
>> >
>> > 关于协同翻译平台的建设，我也在认真考虑和规划，今天初步加入了OpenID登录的支持，当然现在的平台上的数据还只是作为预览项目功能用的，也只在这个邮件列表上公布了项目地址，应该还会进行再次开发并正式上线。
>> >
>> > 先说一下平台的开发现状：
>>
>> 以下你的想法,建议汇集到:
>> http://code.google.com/p/openbookplatform
>> 俺已经将你追加為管理员了,
>> 可以将代码检入到:
>> https://openbookplatform.googlecode.com/svn/trunk/docspot
>> 而将项目开发的规划,想法永久性的使用维基记录下来;
>>
>> 有关现阶段的开发:
>> + 基于 reST 的Sphinx 框架是个趋势,应该好好研究:
>> - 如何快速上手?
>> - 如何方便的将以前各种方案的图书都转换為 Sphinx 平台支持?
>> + 但是在线翻译模式应该追加透过版本系统的离线模式:
>> - 不会 SVN/Hg/Git 等等版本系统的普遍人,使用在线正式进行贡献
>> - 有项目体验的,通过版本系统提交文件来进行贡献,并自然形成版本(而不是DB中的)
>> + 当前的翻译模式应该更加友好和简单
>> - 就地翻译比对照翻译要自然
>> - 评注也应该就地
>> + 当前图书项目的组织应该以查阅为线索,而不是翻译
>> - 图书列表点击后,应该就是浏览内容
>> - 每个图书项目应该有就地的简短介绍
>> - 翻译的文件,应该有顺序,根据阅览的自然顺序?
>> - 应该将图书项目以一定分类进行划分,以便 在首页人们可以第一时间进入自个儿需要的:
>> 比如说:
>> Python 语言:
>> +-- Python
>> +-- PyMOTW
>> ...
>> Python 作品:
>> +- Django
>> +-- Turbogears
>> ...
>> Python 模块:
>> +-- Shpinx
>> ...
>> + 当前应该先增补说明文档:
>> - 含截屏的友好说明当前支持的图书翻译工程流程
>> - 团队现状和召集需要
>> + 我愿意作一部分SA 和项目协调
>> - Sphinx 环境的本地架设,编译,调试説明
>> - ...
>>
>> 等等,现在要紧的已经不是开发,而且更好的收集反馈意见,冷静全面的规划下阶段开发;
>> 所以,建议,利用现有的工程空间:
>> http://code.google.com/p/openbookplatform
>> 包含版本管理/知识管理/提案管理 的轻便项目空间!
>>
>> 让开始使用 docspot.org 的大家将意见统一的汇总到 Issue 中:
>> http://code.google.com/p/openbookproject/wiki/UsageIssue
>> 将想作的特性也记录在 Issue 中,
>> 统一的进行规模,以便将力量用到最需要的方向,
>> 而且有个整个的步骤和计划,也便于切分,模块化,引入新的开发力量;
>> 以及TDD...
>>
>>
>>
>> >
>> > 目前主要以处理Sphinx类型的文档为主，Sphinx是最初专门用来给Python自己及其相关项目来写文档，使用的标记语言是reStructuredText。
>> > 在Sphinx的官网上有一个已经使用Sphinx来作为文档格式的项目列表：
>> >
>> > http://sphinx.pocoo.org/examples.html
>> >
>> >
>> > 这个列表包括了Python的很多的重要项目，而且很多Python项目应该也用了类似的reStructuredText格式来写文档。所以原则上来讲，将这些项目的文档同步到这个平台上来并不难。
>> >
>> >
>> > 难点在于社区的组织，我最初的想法是任何人都可以直接参与到翻译的过程中，但是由于Sphinx特有的文档格式，对于翻译者来说最好还是需要先学习相关的知识再进行翻译工作，不然很多翻译的段落会由于格式问题，导致编译出来的文档出现很多奇怪的错误。
>> > 所以，在最初，最应该开始翻译的是Sphinx的文档，并且作为翻译者，有责任先认真地阅读该文档。
>> > 并且以后平台的翻译的权限开通还需要进行重构，以保证翻译的质量，不然会给审阅的工作带来很多不必要的麻烦。
>> >
>> >
>> > 另外，从http://djangobook.py3k.cn/hero/ 的贡献列表上就可以看到，少部分人贡献了绝大都数的翻译。所以，对翻译者的准入条件进行把关还是有必要的。
>> >
>> > 关于平台的可持续发展，有以下几点想法：
>> >
>> > 1、在导出的文档中可以尝试加入翻译者的名字等信息，使读者可以知道贡献的来源，对于其中的翻译错误，如果需要，也可以直接与翻译者取得联系。
>> >
>> >
>> > 2、实名的E-mail地址注册，由于有版本更新的功能，所以在某个段落有更新时，可以考虑给给相关翻译者自动发送提醒邮件，以提醒他们及时更新相应翻译。
>> >
>> > 3、我不知道翻译的项目文档是否可以作为出版物出版，如果可以，那么还可以考虑与出版社进行合作出版，并将相关报酬回报给翻译者。
>> >
>> > 4、项目文档只是学习资料的其中一种，另外一种常用的学习资料是书籍，如果可能，可以考虑开发书籍的协同翻译功能。
>> >
>> > 目前项目缺的人手：
>> > 0、项目组织者：领导，协调，组织项目的正常进行，以及与相关社区的联系和合作。
>> > 1、美工人员：设计一个美观，统一的网站风格，Logo等
>> > 2、页面设计及JS程序员：目前翻译的过程是左右两列，左列语法高亮显示原文，右列通过edit in
>> > place，提交翻译。我个人觉得这样的好处是与原文的对比比较直观，但是不好的地方是由于宽度限制，容易产生自动换行，这可能会影响到文档的格式问题。
>> > 3、Linux系统管理员：负责服务器的维护，安全管理等事务。
>> > 4、程序开发和维护：这个目前我可以继续进行开发，如果谁有兴趣也可以加入进来。
>> >
>> > 其他：
>> >
>> > 实际上，在开始做这个项目时，就考虑了国际化的问题，所以，在项目代码中尽量使用了英文，然后通过Django的国际化组件进行汉化，因为不仅仅是中文用户存在英文的阅读问题，其他像很多国家也存在。所以这个app对与其他国家的Python社区也可以发挥同样的作用，可以考虑在其他国家的Python社区也进行推广。
>> >
>> >
>> > 2009/6/14 Zoom.Quiet <zoom....@gmail.com>
>> >>
>> >> 综合对当前平台的发展进行了思考,记录在:
>> >> ThinkDocspot - openbookplatform - docspot.org 发展规划和思考 - Google Code
>> >> http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
>> >>
>> >> 回复时,请使用回复全部,因为同时CC 给多个列表了 ;-)
>> >> 先理解一下俺的建议,以便继续讨论 ;-)
>> >>
>> >> 这方面的平台在中国还是个新兴产业,是和维基有些对立但是性质相同的高效知识汇聚行为,
>> >> 对于当前的中国是非常需要的;而且也不排除出版社也有需要来架设针对性平台来组织作者们的撰写活动..
>> >> 可能性是无穷的,但是要先形成厚实的基础...
>> >>
>> >>
>> >> 2009/6/13 金浩 <jinha...@gmail.com>:
>> >> > 域名是我自己买的，不属于学校。
>> >> > 目前网站是运行在rashost的LINUX VPS上，有完全的控制权限。不过我自己对linux的运行和管理不是很在行，尤其是安全管理方面。
>> >> >
>> >>
>> >> >
>> >> >
>> >> > 因为文档是从原文档的sphinx模板或HTML模板生成的。所以每个项目文档风格肯定跟原文档一样的。如果这涉及到版权的话，可以自己写一套统一的模板给所有项目或使用sphinx本身提供的模板。
>> >> >
>> >> >
>> >> >
>> >> > 网站目前所有页面的HTML结构和CSS直接继承自Django的admin，我以为django既然是开源的，那么admin部分的css应该也可以直接用。
>> >> >
>> >> > 关于 在线编辑框
>> >> >
>> >> >
>> >> > 的兼容性，目前在firefox和IE6，7，8都经过测试没问题，但是IE中似乎有一个很隐蔽的问题就是在提交后，重新显示的翻译后内容从第二行开始会有点缩进，但是再次点击进行翻译时，这个缩进又不见了。
>> >> >
>> >> >
>> >> > 其实关于网站统一风格和相关的版权问题，以及在线编辑框的问题。主要是由于我自己不太擅长前端的工作。如果开源后能够有人处理这方面的工作应该会好点。
>> >> >
>> >> > 的确，通过在线编辑 REST格式的文档，即使有原文区域的语法高亮提示，手动处理那些标记对翻译工作还是有很大的不便。
>> >> >
>> >> > 这个翻译平台本身的源代码组织就是以Django
>> >> >
>> >> > APP的方式，所以只要在settings和urls添加相应设置就可以直接使用。不过相关的项目文档还没有编写，我会尽快写完后，发布在google
>> >> > code上。
>> >> >
>> >> >
>> >> >
>> >> > 实时编译是支持的，我看了您翻译的那个标题，可能是由于格式错误，在========和========之间用两行同时写了英文和中文标题，所以编译没通过就无法即时看到效果了。我后来修改了一下只保留中文标题就可以看到即时编译的效果了。
>> >> >
>> >> >
>> >> >
>> >> > 关于平台的宗旨，准入规划，管理模式，宣传模式，内容反馈模式等这些内容，我的确没有考虑的那么多，因为我最初建立这个平台的的想法就是任何人，只要利用自己很少的一点空余时间来投入到翻译中，那么积少成多，最终翻译的效果应该还是不错的。
>> >> > 其实，我也一直在考虑这些，但是本身真的没多少网站运营方面的经验，所以希望有其他合适人选能组织领导这个项目的后续发展。
>> >> >
>> >> > OpenID 的认证方式应该有现成的Django app解决方案，这个比较容易。
>> >> >
>> >> > 关于 开放文档编译后台的部署文档,鼓励镜像,分散访问压力, 但是统一社区形象：
>> >> > 由于源代码是以django
>> >> > app方式组织的，所以任何人只要有源代码的话就可以搭建类似的平台，但是我担心的是这样一来是否会分散翻译者的力量，导致最终的进展问题。
>> >> >
>> >> > 关于与其他已有翻译项目的沟通和迁移方面的技术问题，这是个长期但是很必要的问题。
>> >> >
>> >> > 最后，我觉得这个项目真的是很有意义和对Python在国内发展的帮助。
>> >> > 希望大家能讨论一下，如何运作这个项目，才能最好的发挥他最大的作用。
>> >> >
>> >> >
>> >> > 我本身是真的没什么开源项目和网站运行的经验，所以Zoom.Quiet如果你愿意的话，希望你能够领导这个项目的发展，我能够专门做后续的开发就已经满足了。
>> >> >
>> >> > 2009/6/13 Zoom.Quiet <zoom....@gmail.com>
>> >> >>
>> >> >> 2009/6/13 金浩 <jinha...@gmail.com>:
>> >> >> > Thanks,这最初只是我的毕业设计的题目，所以没有专门的组织或公司来运营，我自己对项目的运营也擅长。
>> >> >> > 如果可以，希望有人能带头，领导并作为开源项目进行长期的发展。
>> >> >> >
>> >> >> 哲思社区非常愿意主持和协调；
>> >> >> 当前俺感觉到的优势:
>> >> >> + 有个简洁合适的域名（不是学校的吧）
>> >> >> + 有个统一的编辑和成员管理平台
>> >> >> 问题有:
>> >> >> - 系统运营空间是否稳定？是否有长期运维的准备？什么系统？是否有后台管理权限?
>> >> >> - 所有文档项目都使用了原有的样式风格,这有隐患:
>> >> >> - 因为内容是CC的话，网站的风格是可以有版权的，原先的 opeb book plafrom 就是因为使用了 Django
>> >> >> 的风格而受到了警告；
>> >> >> - 建议统一到自个儿的风格，以便形成VI 方面的统一，树立中文技术文档中心的形象
>> >> >> - 通过在线编辑框进行编译对网络和游览器依赖太大，而且无法令用户使用自个儿习惯的编辑器
>> >> >> - 建议开通SVN 渠道,和 code.google 类似,将版本和翻译活动真正融合
>> >> >> - 没有完成实时编译的支持,俺尝试修订了一下 Python 文档,但是没有立即在输出URL 中看到结果
>> >> >> ...
>> >> >>
>> >> >> 当然,一切,都有解决方案的,
>> >> >> 关键是没有见到平台的:
>> >> >> + 宗旨
>> >> >> + 准入规划
>> >> >> + 管理模式
>> >> >> + 宣传模式
>> >> >> + 内容反馈模式
>> >> >> ...
>> >> >>
>> >> >> 即,没有整体的运营社区概念,希望及时想一下,
>> >> >> 公开在网络中,吸引同道的同时形成自个儿的团体 ;-)
>> >> >>
>> >> >> 另外,建议:
>> >> >> + 支持 OpenID 的认证方式,以便外部应用的结合
>> >> >> + 开放文档编译后台的部署文档,鼓励镜像,分散访问压力,但是统一社区形象
>> >> >> + 及时和各种已经完成翻译的团队建立沟通,免费提供空间,将大家的成果集中起来
>> >> >>
>> >> >> 最后,俺愿意义务作 docspot.org 的SA 和 协调人,而且也愿意将 OBP 工程中的相关图书内容也迁移统一过来;-)
>> >> >>
>> >> >>
>> >> >> >
>> >> >> > 2009/6/13 Zoom.Quiet <zoom....@gmail.com>
>> >> >> >>
>> >> >> >> 2009/6/13 金浩 <jinha...@gmail.com>:
>> >> >> >> > 网址：http://docspot.org/
>> >> >> >> > 关于本协同文档翻译平台：
>> >> >> >>
>> >> >> >> sooooo great !
>> >> >> >> 中文技术领域的确需要统一方便的文档维护平台！
>> >> >> >> 而且可以进一步和出版社对接，形成快速的出版渠道！
>> >> >> >> 建议精心运维和哲思联合，作大作深！
>> >> >> >>
>> >> >> >>
>> >> >> >> > 本协同文档翻译平台基于 Python+Django
>> >> >> >> > 搭建，目前主要专注于Python及其相关项目的文档翻译，同时也不排除以后组织翻译其他项目的文档的可能性。
>> >> >> >> >
>> >> >> >> > 目前已经有Django，Google App
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > Engine，Jinja2，Pylons，PyMOTW，Python，Sphinx，SQLAlchemy，TurboGears这几个项目的翻译，其他翻译项目将陆续增加。
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > 虽然其中某些文档已经有人翻译或部分翻译过了，但是与其他项目的情况不同，这将是一个长期的项目，并且将集各种Python文档与一个平台上，方便资料的查找。
>> >> >> >> > 并且对于已经有人翻译过的文档，我将会尽可能将这些已有翻译转换到这个新的平台上。
>> >> >> >> >
>> >> >> >> > 平台特点：
>> >> >> >> > 智能分段，协同翻译：将一篇文档分段成多个具有足够上下文信息的段落，通常表现为 段落标题+段落内容 的形式。
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > 版本控制，同步更新：英文文档是在不断变化中的，中文文档也需要及时跟进，所以对英文文档进行了版本变化的跟踪，使中文的翻译过程与英文文档的更新可以同步进行。
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > 格式输出，即翻即转：Python及其相关项目的文档通常采用Sphinx或reStructuredText的格式进行编写，翻译时的格式也是一样，所以可以输出成和英文文档相同的多种格式。同时对于翻译的文档也是翻译后马上可以看到HTML格式输出的效果。
>> >> >> >> >
>> >> >> >> > 翻译效果：
>> >> >> >> > Django文档的英文首页：http://docspot.org/django/en/index.html
>> >> >> >> > Django文档的中文首页：http://docspot.org/django/zh-cn/index.html
>> >> >> >> >
>> >> >> >> > 希望大家能多提点意见，积极参与。
--
Zoom.Quiet
> 我昨晚想了一下，主要有以下几个难点：
perfect! 这些深入的推导正是俺提醒的要点哪!
收集到了:
http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
> 1、Web方式是以段落为单位进行翻译的提交，而SVN方式是以文件为单位提交。
> 2、不仅要保证Web方式和SVN方式提交过去的翻译保持同步和防止冲突，而且还要与英文原版之间建立某种联系，以便及时发现更新，同步翻译。
>
> 另外关于Web方式和SVN方式，我觉得从面向的翻译者人群来考虑，因为这是相对比较专业的文档翻译，所以对于翻译者来说，能够使用SVN进行翻译提交应该是一个很基本的能力要求。
> 而且，使用svn方式，可以使用自己熟悉的编辑器，这对于REST文档格式正确的保证是有很多好处。
> 不过，我觉得当前主要的问题并不是采用哪种方式进行翻译或是技术实现上的问题，即使以前已经在使用的纯SVN方式其实可以说是已经很不错了。
>
> 主要的问题在于：
> 1、翻译者的参与积极性，目前Python在国内的开发人数还是小众，其中愿意长期，稳定地抽出时间来进行翻译工作的人也是少之又少。
> 2、翻译进程的持续性，由于文档和书籍是两种不同的形式，文档的特点是会保持更新，而目前组织的翻译项目，基本都没有考虑如何与英文文档保持同步，而是直接从某个时间点开始，签出英文文档，在这基础上进行翻译，翻译完成后就不再更新。
> 3、翻译者之间的协调和交流，相互激励，像Web方式的，虽然可以通过评注使用户之间可以进行某种程度的交流，但是这种方式有效性还有待商榷。而以前的SVN方式更像是一次豪华的聚会，开始积极性很高，但是随着翻译的结束，就很少再去考虑如何将翻译成果展示给更多有这个阅读需要的人。
> 基于以上原因：
> 我觉得作为翻译平台，考虑的更多的应该是：
> 1、为翻译者之间提供自动化的协调工作：比如任务的领取，翻译术语同步，进度的相互督促，以及其中的各种问题交流，另外非常重要的一点：在原文档有更新时，应该有一种很好的方式提醒相关责任者进行相应更新。
> 2、如何最大程度的提高，保持翻译者的参与积极性，这是个和国内IT环境相关的问题，大家平时就很忙了，难得有休息时间也会有其他自己的事要做。
>
>
> 所以归根结底，问题是如何有效的组织，运作一个翻译团队。
是也乎,是也乎!
这是 Web 2.0 的核心价值观,
一个有发展的提供的不应该是功能集合,而是种 COOL 的生活方式 ;-)
首先得自个儿用 的爽了,才有可能吸引同好!
> 因此，我觉得翻译平台可以从以下几点考虑：
> 1、只使用SVN方式进行翻译的提交，以Web方式提供翻译者之间的协调，进度控制，以及与英文文档的同步问题，以及与阅读者之间的问题反馈。
> 2、建立某种“永久性”的文档维护者机制，比如某个人专门负责Django 文档中 Model
> 那部分相关的文档翻译，维护，更新工作。这样既使翻译内容在一定程度上保持一致，也利于翻译的可持续发展。
> 3、翻译平台提供文档的自动编译，当通过SVN提交翻译后，使阅读者可以最快的见到翻译成果。
> 4、与其他社区，出版者进行合作，为翻译者的无私奉献提供一定程度的回报。
>
以上的推导式思想方式对了,
不过,结论得进一步详细分析了,下班了俺们继续,
PS, 简历什么时候发送? 有些事儿,电话沟通更加快些的 ;-)
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
林
我想改到gae上 造福大众:P
Zoom.Quiet
> Djangobook的平台我也喜欢 这个是开源的么？还是djangobook自己做的？
> 我想改到gae上 造福大众:P
GAE 容易被和諧的，有自个儿的主机要稳定的多;-)
> On 6月14日, 下午6时03分, 柠檬园主 <qih...@gmail.com> wrote:
>> http://djangobook.py3k.cn/
>> 这个的平台很不错的，只可惜也是英文文档更新更跟上，对应的英文版那边已经出django1.0的了，而这边的文档还是基于0.96的。
>> 但这个平台的协同翻译方法我个人比较喜欢。
>>
>> On 6月14日, 下午2时14分, 金浩 <jinhao7...@gmail.com> wrote:
>>
>> > 界面只是直接取自django的admin后台的CSS，不过那个界面作为后台管理的确很通用。
>>
>> > 2009/6/14 soldier <8863...@gmail.com>
>>
>> > > 个人觉得做得很赞， 界面很喜欢。
>> > > 界面一直是我个人的一大难题。
>>
>> > > 2009/6/13 大郎 <qichangx...@gmail.com>:
>> > > > 2009/6/13 金浩 <jinhao7...@gmail.com>
>>
>> > > >> 网址：http://docspot.org/
>>
>> > > > 呀，做得很好啦，不过有很多重复的项目，要是看到这些作者们能够合并来做这个平台就好啦。
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
向靠谱,反脑残! Kaopulity,小白退散!
YoungKing
主页: http://djangobook-cn.appspot.com/
项目网址: http://bitbucket.org/youngking/djangobook-cn
--
润普公司:zopen.cn
易度项目在线管理平台:everydo.com
个人博客:blog.xmu.me (GAE已挂，还是老老实实用wordpress)
金浩
makestory
看来要熟悉一下svn
我也想尽点微薄之力。
金浩
项目的技术文档：http://docspot.org/self-docs/index.html
不知道为什么，这个项目关注的人不是很多啊。
Can Xue
Can Xue
>
> 2009/6/15 金浩 <jinha...@gmail.com>:
> > 我昨晚想了一下，主要有以下几个难点：
> perfect! 这些深入的推导正是俺提醒的要点哪!
> 收集到了:
> http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
>
在考虑如何善用这个平台的同时，现阶段是不是重点还是应该放在让这个平台更完善呢?
**扩展能处理的格式：**
有许多文档还不是基于 Sphinx 的，还有不少项目采用 LaTeX、docbook 或者其它方案编写文档。比如，wxWidgets
的文档（OT：我准备八月份开始来填这个挖了好几年的坑）采用 Oxygen 编译，用于生成手册的文档源文件仅存在于 trunk 中(在
tags 中从未看到这部分文件)，不管是不是 API 参考，全部以 .h 的形式存在，这个系统是否有良好的可扩展机制来实现这些？
**完善授权许可（authz）机制：**
这是想要能够很好的组织和管理的基础。加入 OpenID 的支持只不过是丰富了 authn 的手段，但是要在 QA 上有所保证，完善的
authz 机制应该是必要的。不能仅仅靠吸引更多的眼球来保证品质。
**定制更适合中文特性的样式**
举个简单的例子，斜体在中文中其实很无厘头的事情。假设正文使用的是宋体样式的话，大多数英文中适用斜体的情况都适合使用类似楷体或者仿宋的字体替代。类似的还有类似符合中文习惯的
text-indent 等样式。
**定制更适合中文特性的插件**
reST 书写大段英文可以方便的使用多行，对于英文来说自动将换行替换为空白字符是正确而有意义的，对中文则不是这样。我不了解是否已有类似的模块可以处理这件事，在行末使用“\”不是很方便，使用编辑器的
word-wrap 在中英混排的段落有时很难看。类似的舶来架构不能很好的适合国情的情况应该还有一些，是否均能够有效处理？
**在实用性上进一步做文章**
全局的以及项目领域内的共享词库？标点符号的半角/全角自动检查？提供 XML-RPC
或类似接口以便可以使用桌面程序进行工作？当系统真正强大，关注的人和参与的人肯定会增加的。
--
XUE Can
Bruce Wang
源代码已经整理并发布： http://openbookplatform.googlecode.com/svn/trunk/doc_trans
项目的技术文档：http://docspot.org/self-docs/index.html
不知道为什么，这个项目关注的人不是很多啊。
--
simple is good
http://brucewang.net
http://twitter.com/number5
Zoom.Quiet
> 2009/6/15 Zoom.Quiet <zoom....@gmail.com>
>>
>> 2009/6/15 金浩 <jinha...@gmail.com>:
>> > 我昨晚想了一下，主要有以下几个难点：
>> perfect! 这些深入的推导正是俺提醒的要点哪!
>> 收集到了:
>> http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
>>
>
>
> 在考虑如何善用这个平台的同时，现阶段是不是重点还是应该放在让这个平台更完善呢?
>
建议将以下你的针对性思考和计划汇总到:
http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
另外， docspot.org 的工程环境是:
http://code.google.com/p/openbookplatform
专用邮件讨论列表:
openboo...@googlegroups.com
以及，在进行代码维护时，提醒写完善的注释，否则:
http://code.google.com/p/openbookplatform/source/list
在 Changeset 查阅时，就不知道为什么作这次修订了!
而且:
http://code.google.com/p/openbookproject/wiki/IssueFlow
可以配合 Issue 的使用将问题和代码紧密关联起来！
> **扩展能处理的格式：**
>
> 有许多文档还不是基于 Sphinx 的，还有不少项目采用 LaTeX、docbook 或者其它方案编写文档。比如，wxWidgets
> 的文档（OT：我准备八月份开始来填这个挖了好几年的坑）采用 Oxygen 编译，用于生成手册的文档源文件仅存在于 trunk 中(在
> tags 中从未看到这部分文件)，不管是不是 API 参考，全部以 .h 的形式存在，这个系统是否有良好的可扩展机制来实现这些？
>
> **完善授权许可（authz）机制：**
>
> 这是想要能够很好的组织和管理的基础。加入 OpenID 的支持只不过是丰富了 authn 的手段，但是要在 QA 上有所保证，完善的
> authz 机制应该是必要的。不能仅仅靠吸引更多的眼球来保证品质。
>
> **定制更适合中文特性的样式**
>
> 举个简单的例子，斜体在中文中其实很无厘头的事情。假设正文使用的是宋体样式的话，大多数英文中适用斜体的情况都适合使用类似楷体或者仿宋的字体替代。类似的还有类似符合中文习惯的
> text-indent 等样式。
>
> **定制更适合中文特性的插件**
>
> reST 书写大段英文可以方便的使用多行，对于英文来说自动将换行替换为空白字符是正确而有意义的，对中文则不是这样。我不了解是否已有类似的模块可以处理这件事，在行末使用“\”不是很方便，使用编辑器的
> word-wrap 在中英混排的段落有时很难看。类似的舶来架构不能很好的适合国情的情况应该还有一些，是否均能够有效处理？
>
> **在实用性上进一步做文章**
>
> 全局的以及项目领域内的共享词库？标点符号的半角/全角自动检查？提供 XML-RPC
> 或类似接口以便可以使用桌面程序进行工作？当系统真正强大，关注的人和参与的人肯定会增加的。
>
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
usage 7-zip to replace WinRAR/WinZip; You can get the truely Freedom 4 software.
Zoom.Quiet
> 源代码已经整理并发布： http://openbookplatform.googlecode.com/svn/trunk/doc_trans
> 项目的技术文档：http://docspot.org/self-docs/index.html
>
> 不知道为什么，这个项目关注的人不是很多啊。
>
当然了，翻译一直就是吃力不讨好的活儿，要不 hacker 5大类型中，怎么专门指出文档维护有功的也是 hacker?!
一个项目或是社区想吸引到人，
在中国，仅仅理念是不行的，只有积累到一定的内容和高人后，才有权威吸引力！
所以，现阶段，真的是应该优化功能，加入翻译工程概念；
以及，哲思社区的后续发展支持結合，
所谓积厚薄发，
只要坚持，总能成功的！
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
多吃菜,少喝酒;听老婆的话,跟党走!
zzj fnsoxt
zzj fnsoxt
金浩
只要是基于文本的文档总能找到合适的方法对他们进行良好的分段，就像项目文档中写的那样，只需要写对应的 file_handler ，系统会自动找到并调用。
这个系统主要的目的是翻译人写的文档，不适合翻译API文档，因为API通常是有工具从源代码自动分析得来的，翻译API就相当于要翻译每个源代码文件了。
不知道 wxWidgets 的文档是不是就是这里： http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/ ，这里的很多txt文件应该就是人写的文档了，很明显，这些文档和rest的形式很像，所以也很容易分段并重组，至于文档的编译，虽然可能做不到自动编译，但是至少肯定可以将数据库中的翻译后文档导出成和原文档一样的目录结构，然后进行手动编译。
**完善授权许可（authz）机制：**
就像在发布的源代码中看到的一样，这个项目是作为dajngo app的形式组织的，所以authz并不是本项目考虑的重点，当然可能出于用户权限管理的需要，最后另外单独做一个app来专门进行这方面的处理更合适。
**定制更适合中文特性的样式** 及 **定制更适合中文特性的插件**
这个字体和样式的问题或许可以通过在输出成HTML时，为中文版本另外写一套CSS样式进行解决，
中文的手动换行与英文的确在最后生成文档是有区别的，但是可以通过如在逗号，句号处进行手动换行，减少这种差别带来的影响。
**在实用性上进一步做文章**
对于全局或项目的共享专业术语的功能得有，不然翻译的结果会显得非常不统一。
至于其他统功能扩展方面那是很长远的事了。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
实际上，我觉得作为一个翻译平台来说，最后可能碰到的最大难题是没有多少人愿意稳定，长期地参与翻译(Python本来就小众，再要符合有时间，有志愿，有能力进行翻译这些条件的人更是少之又少了。)，毕竟这是一个相当花时间和精力，而且可以说是对自己没有直接回报的事。
对于很多人来说，有空余时间不如自己写些小程序或学习新技术来得实在。
另外，尤其是《Python核心编程》那样的事发生之后，我想很多人对于志愿翻译这样的事都还应该怀有一种心有余悸的心情。
想到这里，我觉得其实不如组织翻译一些更入门，更简单的东西来得实际，因为通常有中文阅读需求的人，是为了更快的对Python这个语言或相关项目进行入门或有个基本的了解，而对于需要深入了解其中技术细节的人来说，英文阅读是必备的技能，否则，在这条路上也不可能走的更远。
为什么Ruby在国内发展的势头比Python猛？很大程度上就是中文入门资料匮乏，版本落后的原因的造成的。直到现在Django的第一本书才出版，Python的书也基本只有那本《Python核心编程》可以说是质量和版本都跟上了。这与ROR的书籍形成了鲜明的对比。
所以，我觉得这个翻译平台所面向阅读者，应该是没有或只有较少Python基础，但是对这方面知识有兴趣的用户。
该平台的目标是致力于“推广和普及”Python在国内的发展，专门面向初级读者。
其实，要说Python的入门资料，已经翻译的很好的也不是没有，比如前几天刚刚有人发布了的 PyMOTW 1.4 中文版。
但是很遗憾的是，这些资料只发布了PDF版本，而且或许也仅仅在这个邮件列表上发布了。
我觉得对于这些资料发布，首先，提供一个可供在线浏览的HTML版本是绝对必须的，因为这可以让搜索引擎索引到，被用户搜索到，用户想看一可以直接在线浏览，否则实在太对不起翻译者的辛苦劳动了。
第二，或许Python用户都学到了Python社区低调务实的作风，而不像ROR社区那样会炒作，宣传，但是这对于Python的普及是非常不利的。
大郎
--
百才招聘(baicai.com).产品部
Email: k...@baicai.com
Gtalk: qicha...@gmail.com
twitter.com/qichangxing
金浩
另外，现在 http://docspot.org/ 上的项目都只是作为功能预览之用。
项目代码还会重写，以另外一种方式组织翻译者。
Zoom.Quiet
> **扩展能处理的格式：**
> 只要是基于文本的文档总能找到合适的方法对他们进行良好的分段，就像项目文档中写的那样，只需要写对应的 file_handler ，系统会自动找到并调用。
> 这个系统主要的目的是翻译人写的文档，不适合翻译API文档，因为API通常是有工具从源代码自动分析得来的，翻译API就相当于要翻译每个源代码文件了。
> 不知道 wxWidgets 的文档是不是就是这里：
> http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/
> ，这里的很多txt文件应该就是人写的文档了，很明显，这些文档和rest的形式很像，所以也很容易分段并重组，至于文档的编译，虽然可能做不到自动编译，但是至少肯定可以将数据库中的翻译后文档导出成和原文档一样的目录结构，然后进行手动编译。
>
> **完善授权许可（authz）机制：**
> 就像在发布的源代码中看到的一样，这个项目是作为dajngo
> app的形式组织的，所以authz并不是本项目考虑的重点，当然可能出于用户权限管理的需要，最后另外单独做一个app来专门进行这方面的处理更合适。
>
>
> **定制更适合中文特性的样式** 及 **定制更适合中文特性的插件**
> 这个字体和样式的问题或许可以通过在输出成HTML时，为中文版本另外写一套CSS样式进行解决，
> 中文的手动换行与英文的确在最后生成文档是有区别的，但是可以通过如在逗号，句号处进行手动换行，减少这种差别带来的影响。
>
> **在实用性上进一步做文章**
> 对于全局或项目的共享专业术语的功能得有，不然翻译的结果会显得非常不统一。
> 至于其他统功能扩展方面那是很长远的事了。
>
其实，就是一个类似 tag 云机制的，可以长期积累，方便维护的专业翻译辞典对照表!
英中繁简编程术语对照
http://jjhou.csdn.net/terms.htm
可以在手边儿快速查阅使用的...
> ＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
> 实际上，我觉得作为一个翻译平台来说，最后可能碰到的最大难题是没有多少人愿意稳定，长期地参与翻译(Python本来就小众，再要符合有时间，有志愿，有能力进行翻译这些条件的人更是少之又少了。)，毕竟这是一个相当花时间和精力，而且可以说是对自己没有直接回报的事。
> 对于很多人来说，有空余时间不如自己写些小程序或学习新技术来得实在。
> 另外，尤其是《Python核心编程》那样的事发生之后，我想很多人对于志愿翻译这样的事都还应该怀有一种心有余悸的心情。
>
嗯嗯嗯，从深层心理分析，大家并不是反感和回避文档的翻译和维护，
而是和 博客 vs Blog 之争一样，关心:
+ 如何确保我的贡献是安全/永久保存/方便迁移/搜索有利?!
+ 如何确保我的贡献是明确的可识别,不会冒认的?
+ 如何保证我的贡献是备受关注的,有及时反馈的,可持续修订的?
+ 如何保证我的贡献是唯一的无冲突的?有人作相同翻译时,我们是可以合作的?
因为翻译文档,对于技术精进是非常有好处的!
但是各种翻译平台的不稳定性,以及数据备份/管理/版本控制等等的不完备,
导致贡献者要花费比直接看原文高的多的多的付出!
以上核心关注,平台无法保证的话,那么,大家是宁可观望的 ;-(
> 想到这里，我觉得其实不如组织翻译一些更入门，更简单的东西来得实际，因为通常有中文阅读需求的人，是为了更快的对Python这个语言或相关项目进行入门或有个基本的了解，而对于需要深入了解其中技术细节的人来说，英文阅读是必备的技能，否则，在这条路上也不可能走的更远。
>
这正好是译言的关注领域,
短小的,有趣的,惊人的文章,谁最快翻译谁NB;
但是在技术领域,任何方面的技术都无法通过小文章来阐述清楚的,
如果作类比的话,短小的实用代码片段比文档要有用的多,也不用翻译,注释几处就好,
哪正好是各种 代码片段分享服务支持的方面;
然而,真正对于想用好某类技术的人,有完整思想,完备叙述的图书,才是真正有用的,
没有深入了解方面技术的整体,没有形成正确的技术语感,仅仅用小技巧永远无法写出靠谱软件的!
所以,图书翻译/发布/分享/维护 服务是必定需要的!
而且当前因为技术发展太快,各种社区组织的图书,都有 CC 许可的倾向,
只要聚集起一定量的翻译和维护团队来, docspot.org 一定可以成为中文技术世界的核心服务之一的;-)
> 为什么Ruby在国内发展的势头比Python猛？很大程度上就是中文入门资料匮乏，版本落后的原因的造成的。直到现在Django的第一本书才出版，Python的书也基本只有那本《Python核心编程》可以说是质量和版本都跟上了。这与ROR的书籍形成了鲜明的对比。
>
技术图书在中国,当前只是个鸡肋,除非考证相关的,其它的都是赔钱的，
而且当前网络这么发达，图书对于技术选择的影响力，实在不高了...
> 所以，我觉得这个翻译平台所面向阅读者，应该是没有或只有较少Python基础，但是对这方面知识有兴趣的用户。
> 该平台的目标是致力于“推广和普及”Python在国内的发展，专门面向初级读者。
>
这方面的基础就是 docspot.org 首要核心职能：
- 提供友好翻译／原创技术图书平台(充分挖掘 Sphinx 框架的功能！)
- 汇聚高品质中文开发资料
- 聚集界内有心有余力能人，形成Python 社会影响力
> 其实，要说Python的入门资料，已经翻译的很好的也不是没有，比如前几天刚刚有人发布了的 PyMOTW 1.4 中文版。
>
> 但是很遗憾的是，这些资料只发布了PDF版本，而且或许也仅仅在这个邮件列表上发布了。
>
> 我觉得对于这些资料发布，首先，提供一个可供在线浏览的HTML版本是绝对必须的，因为这可以让搜索引擎索引到，被用户搜索到，用户想看一可以直接在线浏览，否则实在太对不起翻译者的辛苦劳动了。
>
这方面就是 docspot.org 另一核心职能：
- 权威收集技术图书中文高质量版本
- 提供友好查阅
- 提供搜索支持
> 第二，或许Python用户都学到了Python社区低调务实的作风，而不像ROR社区那样会炒作，宣传，但是这对于Python的普及是非常不利的。
>
宣传CPyUG 有各种媒体平台，和CSDN 等等官方媒体都有联系，只要需要，宣传不是问题！
关键是，是否应该和怎么保持！
这又是回到作品是否成熟的本质要求了 ;-)
>
> 2009/6/17 Zoom.Quiet <zoom....@gmail.com>
>>
>> 2009/6/16 金浩 <jinha...@gmail.com>:
>> > 源代码已经整理并发布： http://openbookplatform.googlecode.com/svn/trunk/doc_trans
>> > 项目的技术文档：http://docspot.org/self-docs/index.html
>> >
>> sure! 好哪！
>>
>> > 不知道为什么，这个项目关注的人不是很多啊。
>> >
>> 当然了，翻译一直就是吃力不讨好的活儿，要不 hacker 5大类型中，怎么专门指出文档维护有功的也是 hacker?!
>>
>> 一个项目或是社区想吸引到人，
>> 在中国，仅仅理念是不行的，只有积累到一定的内容和高人后，才有权威吸引力！
>> 所以，现阶段，真的是应该优化功能，加入翻译工程概念；
>> 以及，哲思社区的后续发展支持結合，
>> 所谓积厚薄发，
>> 只要坚持，总能成功的！
>>
>>
>> --
>> http://zoomquiet.org
>> '''过程改进乃是催生可促生靠谱的人的组织!'''
>> 多吃菜,少喝酒;听老婆的话,跟党走!
>
>
>
> --
> My Blog:http://jinhao.javaeye.com/
>
Can Xue
>
> 不知道 wxWidgets 的文档是不是就是这里： http://svn.wxwidgets.org/viewvc/wx/wxWidgets/trunk/docs/ ，
> 这里的很多txt文件应该就是人写的文档了，很明显，这些文档和rest的形式很像，所以也很容易分段并重组，
> 至于文档的编译，虽然可能做不到自动编译，但是至少肯定可以将数据库中的翻译后文档导出成和原文档一
> 样的目录结构，然后进行手动编译。
trunk/docs 里面的 txt 绝不是 wxWidgets 文档的重点，重点是 trunk/docs/doxygen/* 里面的 .h 文件和
trunk/interface/wx/ 里面的 .h 文件。因为 wxWidgets 的特殊性，trunk/interface 里面的代码实际上根本
不会被实际的实现(如 wxMSW，wxGTK, etc)使用到，只是作为文档存在的。
--
XUE Can
Can Xue
Heresy.Mc
目前我已经翻译了一部分GAE文档，回头整理上去，瓦咔咔，希望给社区做点贡献～
金浩
也希望大家能够继续关注和对这个项目提出更多宝贵的意见。
2009/6/16 金浩 <jinha...@gmail.com>:源代码已经整理并发布： http://openbookplatform.googlecode.com/svn/trunk/doc_trans 项目的技术文档：http://docspot.org/self-docs/index.htmlsure! 好哪！不知道为什么，这个项目关注的人不是很多啊。当然了，翻译一直就是吃力不讨好的活儿，要不 hacker 5大类型中，怎么专门指出文档维护有功的也是 hacker?! 一个项目或是社区想吸引到人， 在中国，仅仅理念是不行的，只有积累到一定的内容和高人后，才有权威吸引力！ 所以，现阶段，真的是应该优化功能，加入翻译工程概念； 以及，哲思社区的后续发展支持結合， 所谓积厚薄发， 只要坚持，总能成功的！
毫无疑问，文档翻译对于自由软件社区来说是至关重要的。但之所以一直进行的不好，和缺乏合适的工具有一定的关系。但在这个工具里，上缺乏翻译最核心的功能，”版本控制“，如果没有这个功能，那么在实际运转的过程中，大家就不会认可这个工具或网站。
想想如何加强一下这方面的功能？
Zoom.Quiet
> 非常感谢大家的意见，我会认真总结，并重新制订下一步的开发计划，以更好的适应各种用户的需求。
>
> 也希望大家能够继续关注和对这个项目提出更多宝贵的意见。
>
> 2009/6/17 Bill Xu <bi...@zeuux.org>
>>
>>
>> Zoom.Quiet 写道:
>>
>> 2009/6/16 金浩 <jinha...@gmail.com>:
>>
>>
>> 源代码已经整理并发布： http://openbookplatform.googlecode.com/svn/trunk/doc_trans
>> 项目的技术文档：http://docspot.org/self-docs/index.html
>>
是否也检入了SVN？
自动根据提交自动编译？
那么，其它有权限的成员就可以在此基础上进行增进了哪，
也可以在此基础上设计出有中国特色的图书样式了哪 ;-)
另外，如何使用 Sphinx 来组织图书工程，也应该是dospots.org 的看家文档之一哪 ;-)
>> sure! 好哪！
>>
>>
>>
>> 不知道为什么，这个项目关注的人不是很多啊。
>>
>>
>>
>> 当然了，翻译一直就是吃力不讨好的活儿，要不 hacker 5大类型中，怎么专门指出文档维护有功的也是 hacker?!
>>
>> 一个项目或是社区想吸引到人，
>> 在中国，仅仅理念是不行的，只有积累到一定的内容和高人后，才有权威吸引力！
>> 所以，现阶段，真的是应该优化功能，加入翻译工程概念；
>> 以及，哲思社区的后续发展支持結合，
>> 所谓积厚薄发，
>> 只要坚持，总能成功的！
>>
>>
>>
>> 毫无疑问，文档翻译对于自由软件社区来说是至关重要的。但之所以一直进行的不好，和缺乏合适的工具有一定的关系。但在这个工具里，上缺乏翻译最核心的功能，”版本控制“，如果没有这个功能，那么在实际运转的过程中，大家就不会认可这个工具或网站。
>>
>> 想想如何加强一下这方面的功能？
>>
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
Davies Liu
本协同文档翻译平台基于 Python+Django 搭建，目前主要专注于Python及其相关项目的文档翻译，同时也不排除以后组织翻译其他项目的文档的可能性。
目前已经有Django，Google App Engine，Jinja2，Pylons，PyMOTW，Python，Sphinx，SQLAlchemy，TurboGears这几个项目的翻译，其他翻译项目将陆续增加。虽然其中某些文档已经有人翻译或部分翻译过了，但是与其他项目的情况不同，这将是一个长期的项目，并且将集各种Python文档与一个平台上，方便资料的查找。并且对于已经有人翻译过的文档，我将会尽可能将这些已有翻译转换到这个新的平台上。平台特点：
智能分段，协同翻译：将一篇文档分段成多个具有足够上下文信息的段落，通常表现为 段落标题+段落内容 的形式。版本控制，同步更新：英文文档是在不断变化中的，中文文档也需要及时跟进，所以对英文文档进行了版本变化的跟踪，使中文的翻译过程与英文文档的更新可以同步进行。格式输出，即翻即转：Python及其相关项目的文档通常采用Sphinx或reStructuredText的格式进行编写，翻译时的格式也是一样，所以可以输出成和英文文档相同的多种格式。同时对于翻译的文档也是翻译后马上可以看到HTML格式输出的效果。翻译效果：Django文档的英文首页：http://docspot.org/django/en/index.htmlDjango文档的中文首页：http://docspot.org/django/zh-cn/index.html希望大家能多提点意见，积极参与。
金浩
hairui
On 6月16日, 下午10时59分, 金浩 <jinhao7...@gmail.com> wrote:
> 源代码已经整理并发布：http://openbookplatform.googlecode.com/svn/trunk/doc_trans
> 项目的技术文档：http://docspot.org/self-docs/index.html
>
> 不知道为什么，这个项目关注的人不是很多啊。
不要奢望一举成名，坚持下去自然会有成功的一天
我个人就很关注你的项目，不过最近比较忙，呵呵
>
> 2009/6/15 Zoom.Quiet <zoom.qu...@gmail.com>
>
> > 2009/6/15 金浩 <jinhao7...@gmail.com>:
> > > 2009/6/14 Zoom.Quiet <zoom.qu...@gmail.com>
>
> > >> 2009/6/14 金浩 <jinhao7...@gmail.com>:
> > >> > 2009/6/14 Zoom.Quiet <zoom.qu...@gmail.com>
>
> > >> >> 2009/6/14 金浩 <jinhao7...@gmail.com>:
> ...
>
> 阅读更多 >>