On 2011年08月20日 10:41, alick wrote:
维护文档的格式。我觉得 csv 格式就不错,本身就是文本文件,适合协作。在
电子表格软件(如 gnumeric)里能进行统计和排序。而且几种(相似)的语言
在一起对照,也有助于理解(和沟通交流),不是很有必要转换到(几个分开
的) po 文件。
关于工作流程。我看到 Mika Ma 和 tiansworld 在 github 上已经做了交互。
应该还不错吧?是的话就这样吧。我总结
流程大概如下:(没问题就整理成文档吧)
==========
有一个中心仓库,现在在
https://github.com/tiansworld/chinese-glossary/
维护者目前是 tiansworld。
如何参与?
使用 git。分布式协作。维护一个 csv 文件。
在 github 上创建帐号,fork 维护者 的仓库到自己帐号下,为自己的
master 分支,参与人员平时与自己的 fork 版本交互(建 devel 分支,
编辑,提交到自己的 master 上),过一段时间向 维护者 发送
pull request,维护者 pull (fetch+merge)参与者的 master 分支。
其实,github 帐号帐号并不必须,只要自己有公开的(其他人可以 pull)的
仓库就成,比如其他的 git 托管站点,甚至自己开 git 服务。
==========
关于格式转换:yizhang 和 simonyan 用 perl 脚本做了 csv 到 wiki
格式的转换,效果很不错。csv 到电子表格格式的转换应该不难。
到数据库格式:我个人觉得目前可能不是很必要,但还是一个很好的 feature。
问题是实现和数据库的交互需要写个界面程序来,要协作可能还得架个站什么的。
但我挺鼓励 Mike Ma 做出来一个 :)
数据库。。其实我想的就是能更快搜索到一个文件。我不喜欢数据库。我先写一个
原型吧(用C)。大家如果觉得还缺点啥可以自己搭积木。
PS:为了能更好匹配,可能需要多一个注释行(在第一行),来指明以下某个位置
是什么内容。类似 shell 脚本。
PS2:如果需要多道转化,可能需要把整个文件读入内存来简化实现。 :-(
PS3:如果需要再简化,内存占用可能会达到文件大小的 2~3 倍,单纯搜索的话占
用不会很大。
其他建议:
可以加个 CREDITS 文件,记录贡献者信息;
csv 到 wiki 格式转换的脚本,也可以加进仓库。
担心:
git 会不会把一些人吓跑?
可以在线 fork+edit+commit,然后 pull request,不过需要github帐号。(也许
可以录一个视频教程)