Re: [CPyUG:89329] Re: 发布一个Python的协同文档翻译平台
Zoom.Quiet
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
>> >> >
>> >> > 希望大家能多提点意见，积极参与。
>> >> >
>> >> > --
>> >> > My Blog:http://jinhao.javaeye.com/
>> >>
>>
>>
>>
>> --
>> http://zoomquiet.org
>> '''过程改进乃是催生可促生靠谱的人的组织!'''
>> Free as in Freedom! 哲思自由软件社区:http://zeuux.org
>
>
>
> --
> My Blog:http://jinhao.javaeye.com/
>
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
向靠谱,反脑残! Kaopulity,小白退散!
Zoom.Quiet
> 综合对当前平台的发展进行了思考,记录在:
> ThinkDocspot - openbookplatform - docspot.org 发展规划和思考 - Google Code
> http://code.google.com/p/openbookplatform/wiki/ThinkDocspot
>
> 回复时,请使用回复全部,因为同时CC 给多个列表了 ;-)
> 先理解一下俺的建议,以便继续讨论 ;-)
>
哪个学校的毕业课题哪,居然可以用Python 的?
什么时候毕业? 想来金山不? 咔咔咔?
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
一个人如果力求完善自己,就会看到:为此也必须同时完善他人. 一个人如果不关心别人的完善,自己便不可能完善!
金浩
所以，在最初，最应该开始翻译的是Sphinx的文档，并且作为翻译者，有责任先认真地阅读该文档。
Zoom.Quiet
> 关于协同翻译平台的建设，我也在认真考虑和规划，今天初步加入了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...
--
http://zoomquiet.org
'''过程改进乃是催生可促生靠谱的人的组织!'''
Time is unimportant, only life important!
金浩
- 不会 SVN/Hg/Git 等等版本系统的普遍人,使用在线正式进行贡献
- 有项目体验的,通过版本系统提交文件来进行贡献,并自然形成版本(而不是DB中的)
Zoom.Quiet
> 关于
>
> + 但是在线翻译模式应该追加透过版本系统的离线模式:
> - 不会 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字段
好处是数据统一和简单以及标准化了!
问题是段落的分析和处理也必须文件化,需要修订代码...
--
金浩
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
'''过程改进乃是催生可促生靠谱的人的组织!'''
金浩
项目的技术文档：http://docspot.org/self-docs/index.html
不知道为什么，这个项目关注的人不是很多啊。
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
'''过程改进乃是催生可促生靠谱的人的组织!'''
多吃菜,少喝酒;听老婆的话,跟党走!
金浩
只要是基于文本的文档总能找到合适的方法对他们进行良好的分段，就像项目文档中写的那样，只需要写对应的 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的普及是非常不利的。
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/
>
金浩
也希望大家能够继续关注和对这个项目提出更多宝贵的意见。
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?!
>>
>> 一个项目或是社区想吸引到人，
>> 在中国，仅仅理念是不行的，只有积累到一定的内容和高人后，才有权威吸引力！
>> 所以，现阶段，真的是应该优化功能，加入翻译工程概念；
>> 以及，哲思社区的后续发展支持結合，
>> 所谓积厚薄发，
>> 只要坚持，总能成功的！
>>
>>
>>
>> 毫无疑问，文档翻译对于自由软件社区来说是至关重要的。但之所以一直进行的不好，和缺乏合适的工具有一定的关系。但在这个工具里，上缺乏翻译最核心的功能，”版本控制“，如果没有这个功能，那么在实际运转的过程中，大家就不会认可这个工具或网站。
>>
>> 想想如何加强一下这方面的功能？
>>
--