|
|
|
|
| [精华] 建议利用wiki模式来翻译linux文档 |
  [精华] 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-20 09:04 | 1,510 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - jeffshia [ 2005-05-30 13:20 | 38 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - stone5 [ 2005-03-07 16:20 | 146 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-03-08 09:17 | 186 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - bbbush [ 2005-01-21 19:41 | 758 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 21:43 | 120 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-22 08:17 | 124 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - szjungle [ 2005-01-22 14:46 | 143 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-23 09:22 | 1,137 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-24 14:56 | 468 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-25 08:39 | 132 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-25 09:37 | 120 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-25 14:39 | 163 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-26 10:54 | 159 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-25 08:31 | 432 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-22 08:34 | 96 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 12:43 | 39 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 12:37 | 9,437 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-21 16:04 | 144 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-22 08:28 | 238 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-24 15:15 | 498 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - Qiang [ 2005-02-19 13:58 | 685 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-03-11 07:56 | 333 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - xRAIN [ 2005-03-28 12:44 | 63 byte(s)]
Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-02-22 14:56 | 44 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-25 08:14 | 423 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-22 08:57 | 8 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 12:18 | 198 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 16:53 | 2,848 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 12:10 | 3,129 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - gpanzl [ 2005-01-21 11:58 | 6,081 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - szjungle [ 2005-01-20 17:12 | 390 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-23 08:27 | 112 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-24 15:19 | 75 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - szjungle [ 2005-01-23 11:25 | 198 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-21 10:27 | 255 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-21 11:17 | 111 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-21 14:33 | 246 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-21 16:18 | 319 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-22 08:11 | 226 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-24 15:23 | 101 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - szjungle [ 2005-01-21 12:10 | 268 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - zongyaotang [ 2005-01-21 14:11 | 355 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - suowei1979 [ 2005-01-20 17:21 | 10 byte(s)]
[精华] Re: 建议利用wiki模式来翻译linux文档 - xuming [ 2005-01-20 15:57 | 70 byte(s)]
[精华] 是个好建议~~~~ - DHGrand [ 2005-01-20 10:41 | 8 byte(s)]
|
|
|
|
[Original]
[Print]
[Top]
|
我去你的 wiki 涂了一下。
挺好玩！
用于翻译，与原文之间的关系太远。不知如何处理。
编辑窗口太小，而且不习惯。我只用 vi。
批量进入有无措施？ 即比如我有已经翻译过的文件。
我不能忍耐一句一句的用鼠标移动。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
|
我觉得可以和你的GETTEXT方法参照一下，现在的翻译模式确实有些问题。我对WIKI模式不了解，不知道方便性和维护性如何。
|
|
----
@ 拜托!大家都是神仙,留下点回忆好不好?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
Wiki的介绍
何为Wiki（维客）？
首先，我们要搞清楚：wiki概念的发明人是Ward Cunningham。wiki这个字到底是什幺意思呢？根据FAQ的说法，WikiWiki一词来源于夏威夷语的“wee kee wee kee”，原本是“快点快点” (quick)的意思。实际上 wiki 也真的是既简单又快速，你可以看到 wiki 每天都在成长。
新概念的定义总是让人有点摸不着头脑，wiki 也不例外。先看看简单解释：Wiki——一种多人协作的写作工具。Wiki站点可以有多人（甚至任何访问者）维护，每个人都可以发表自己的意见，或者对共同的主题进行扩展或者探讨。
还不明白，那就给你看看更复杂、更晕眩的解释：Wiki指一种超文本系统。这种超文本系统支持面向社群的协作式写作，同时也包括一组支持这种写作的辅助工具。我们可以在Web的基础上对Wiki文本进行浏览、创建、更改，而且创建、更改、发布的代价远比HTML文本为小；同时Wiki系统还支持面向社群的协作式写作，为协作式写作提供必要帮助；最后，Wiki的写作者自然构成了一个社群，Wiki系统为这个社群提供简单的交流工具。与其它超文本系统相比，Wiki有使用方便及开放的特点，所以Wiki系统可以帮助我们在一个社群内共享某领域的知识。
Wiki技术和规范
wiki是任何人都可以编辑的网页。在每个正常显示的页面下面都有一个编辑按钮，点击这个按钮你就可以编辑页面了。有些人要问：任何人都可以编辑？那不是乱套了幺？其实不然，w iki体现了一种哲学思想：“人之初，性本善”。wiki认为不会有人故意破坏wiki网站，大家来编辑网页是为了共同参与。虽然如此，还是不免有很多好奇者无意中更改了w iki网站的内容，那幺为了维持网站的正确性，wiki在技术上和运行规则上做了一些规范，做到既持面向大宗公开参与的原则又尽量降低众多参与者带来的风险。这些技术和规范包括：
1）保留网页每一次更动的版本，即使参与者将整个页面删掉，管理者也会很方便地从纪录中恢复最正确的页面版本。
2）页面锁定，一些主要页面可以用锁定技术将内容锁定，外人就不可再编辑了。（虽然wiki都有这个功能，但我看到使用它的甚少，这可能跟w iki倡导的精神相违背吧）。
3）版本对比，wiki站点的每个页面都有更新纪录，任意两个版本之间都可以进行对比，wiki会自动找出他们的差别。
4）更新描述，你在更新一个页面的时候可以在描述栏中写上几句话，如你更新内容的依据、或是跟管理员的对话等。这样，管理员就知道你更新页面的情况。
5）IP禁止，尽管wiki倡导“人之初，性本善”，人人都可参与，但破坏者、恶作剧者总是存在的，wiki有纪录和封存IP的功能，将破坏者的I P纪录下来他就不能在胡作非为了。
6）Sand Box(沙箱)测试，一般的wiki都建有一个Sand Box的页面，这个页面就是让初次参与的人先到Sand Box页面做测试，Sand Box与普通页面是一样的，这里你可以任意涂鸦、随意测试。
7）编辑规则，任何一个开放的wiki都有一个编辑规则，上面写明大家建设维护wiki站点的规则。没有规矩不成方圆的道理任何地方都是适用的。
Blog和Wiki的不同之处
毫无疑问，你完全可以用Wiki（工具）架设你的blog站点。但是我认为从比较严格的意义上来说，blog和wiki是完全不同的东西，服务这完全不同的目的。
简单来说，blog更是一种无主题变奏，一般来说是少数人（大多数情况下是一个人）的关注的蔓延。一般的blog站点都会有一个主题，凡是这个主旨往往都是很松散的，而且一般不会去刻意地控制内容的相关性。blog注重的是个人的思想（不管多幺不成熟，多幺地匪夷所思），个性化是blog的最重要特色。blog注重交流，一般是小范围的交流，通过访问者对一些或者一篇blog文章的评论和交互。blog也有协作的意思，但是协作一般是指多人维护，而维护者之间可能着力于完全不同的内容。这种协作在内容而言是比较松散的。任何人，任何主体的站点，你都可以以blog方式展示，都有它的生机和活力。
Wiki则不同。Wiki站点一般都有着一个严格的共同关注，Wiki的主体一般是明确的坚定的。Wiki站点的内容要求着高度相关性。最其确定的主旨，任何写作者和参与者都应当严肃地遵从。Wiki的协作是针对同一主题作外延式和内涵式的扩展，将同一个问题谈得很充分很深入。Wiki非常适合于做一种 “All about something”的站点。个性化在这里不是最重要的，信息的完整性和充分性以及权威性才是真正的目标。Wiki由于其技术实现和含义的交织和复杂性，如果你漫无主题地去发挥，最终连建立者自己都会很快的迷失。Wiki使用最多也最合适的就是去共同进行文档的写作或者文章/书籍的写作。特别是技术相关的（尤以程序开发相关的）FAQ，更多的也是更合适地以Wiki来展现。
Wiki站点一览
2003年8月，cnic.org把Wiki翻译成中文维客。百科全书：http://www.cnic.org ,它是一个基于维客和GNU FDL的百科全书网站系统。该系统于2003年9月投入运行.
中文Wiki站点
http://www.cnic.org/ 一个自由开放的中文百科全书
http://wiki.linux.org.hk/
http://zh.wikipedia.org/ 中文Wikipedia
http://www.cnblog.org/wiki/ CNBlog的Weblog百科
http://wiki.online-edu.org/elearning/index.pl E-learning百科目录
http://www.hsfz.net.cn/coo/wiki/ 一个中文的WIKI引擎：CooCooWakka
http://wiki.sinv.com WikiSinv
http://barb.51.net/cgi-bin/tavi/
http://wiki.3382.net/ 浮云Wiki 主页
http://w2.uibe.edu.cn/moinzh/_e9_a6_96_e9_a1_b5 贸大wiki
http://www.acumox.org/grass/wiki/ 针灸研究和教学
原文摘抄（已省略部分内容）
http://www.blogchina.com/new/source/180.html
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我现在觉得自由软件文档的翻译，工具和方法倒不是很重要，关键在于如何对整个翻译小组的管理。
应该和软件项目管理一样，需要一套机制，实现职责分配，成员沟通，进度控制，质量控制等等。
因为是自由软件项目，该如何平衡自由度和责任感，需要好好琢磨一下;)
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
台湾也有人利用wiki来进行翻译
朱學恒與網路翻譯義勇軍
讓你用中文上MIT！
撰文－卜繁裕 攝影－邱如仁
2004年10月 e天下雜誌
半年內有超過400人，義務加入翻譯500種MIT課程；
不久後，MIT的中文開放式課程將免費上線，甚至還有真人講授。
因翻譯《魔戒》而聲明大噪的朱學恒，最近又上了媒體，這次是因為網路志工。
半年內有超過400人，主動加入翻譯至少500種國外大學、研究所專業課程教材的行列。在台灣，這股由網路志工集成的巨大知識力量，正為美國麻省理工學院（MIT）的開放式課程（OCW，Open Course Ware）進行中文化，無人支薪。這是網路社群力量的最佳實證！
今年9月13日，中央大學與奇幻文化藝術基金會簽約，將導入MIT的開放式課程進校園。中央大學校長劉全生表示，除了鼓勵老師將MIT開放式課程的精華融入現有教學，更希望學校現任、退休老師，積極加入這個大型翻譯計畫。
MIT開放式課程導入台灣，中央大學學習科技研究中心、網路學習科技研究所所長陳德懷認為，可分兩個階段觀察。一個是MIT英文教材中文化，另一個則是MIT中文教材網路教學。
WIKI讓翻譯無國界
目前擔任奇幻文化藝術基金會執行長的朱學恒，在2003年9月接觸到這個計劃後，便開始期待能貢獻心力。經過半年的思索與等待，他決定自己跳出來推動。因此今年2月，他邀集幾個有興趣的人開始這個龐大的中文翻譯計劃。
與各國翻譯團隊的不同之處，在於成員的組成。相較其他國家的翻譯團隊以機構、企業、專案方式進行，朱學恒領導的中文翻譯團隊不但全部是由志工組成，而且跨越政治藩籬的界限，來自全球華人社群，翻譯出來的課程同步提供簡、繁中文版本給所有華文社群使用。
為了讓專有名詞能與各地華人慣用語詞達成統一，朱學恒的翻譯團隊採用「WIKI」系統，讓所有參與翻譯計劃的人，都能夠翻譯出最適當的文句。WIKI是一套發展中的網路技術，是一種提供多人寫作的網站系統。每個參與者都可修改其開放的頁面，且若遭到惡意修改，亦可快速讓網頁回復到未受修改前的狀態。
朱學恒舉例，以「column」一詞來說，在中國大陸的簡體中文裡，一般翻譯為「列」，台灣則翻成「行」。進行中文翻譯時，有必要為各地讀者做出最適切的翻譯，而這套系統將可有效處理這個問題。
華文翻譯計劃發起後，朱學恒靠網路社群間的討論，響應人數從計劃發起初期的2人到今年4月的百人志工。至今，這個團隊已經突破400人，認領超過500種課程進行翻譯。這群翻譯者6成上具有碩士以上學歷，多數具有豐富實務工作資歷。而中研院副院長曾志朗，亦加入這個翻譯計劃，擔任審定委員會學門召集人的工作。在全球各地華人響應下，這個翻譯計劃正堂堂邁入下一個新階段：MIT中文教材的網路教學。
亞卓市找真人教MIT課程
「就算你家旁邊有全世界最大的圖書館，但是如果不能吸引你走進去，一切無效，」中央大學網路學習科技研究所所長陳德懷強調，網路教案的吸引力遠不及多媒體真人授課。
因此，陳德懷認為可以與台灣最大的網路學習平台「亞卓市」合作，由亞卓市旗下的全民學校招募有意願授課的老師，再搭配現有的MIT中文教材，直接在網路上以多媒體方式教授，教學效果較好。
想上MIT補充知識卻又害怕英文嗎？不久以後中文界面的MIT開放式課程將與大家見面。一如中央大學校長劉全生的說法，「受益者是所有喜歡知識的人！」你，準備好了嗎？
http://www.cocw.net/index.htm
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
wiki的另一篇介绍，讲了wiki的一些缺陷
作者：李安科
2004年年末，WIKI News推出。“新闻创作方式的颠覆”、“每个人都可以成为记者”，冲浪者奔走相告，种种赞美言辞漂浮在浩瀚的互联网上。WIKI的早期开发者之一Larry Sanger更是宣称：WIKI迎来了一个伟大的时代。
但就在一个月之前，《大不列颠百科全书》的前任主编Robert McHenry在谈到WIKI时，使用了一个不无尖刻的比喻。他把到Wikipedia（维基百科全书）上查看某一词条、确认某项事实比作去公共厕所： “它可能看起来很脏，让人不得不小心翼翼；它也看起来很干净，让人们因而放松警惕。但人们似乎永远也没办法搞清楚：刚才到底是谁使用了这里面的设备？”
网上有一些缺乏见识的论调，说Robert之所以使用如此恶毒的比喻，是因为WIKI百科全书与《大不列颠百科全书》构成了竞争。这种可能性存在吗？数字说话——Wikipedia英文版首页上清清楚楚地写着：从2001年起，这里一共积累了445464个词条。（中文版始于2002年10月，仅有 17936条目，均为2005年1月10日凌晨1:46统计。）而1768年首次出版、1974年推出第15版的《不列颠百科全书》全套共32册，其学术性和权威性已为世人所公认。其在线版于1994年正式发布上网后，更是受到各方好评。二者之间能够构成竞争吗？
或者说，Robert嫉妒的，正是WIKI全民创作、让所有人创作面向所有人进行传播的新媒体理念？
鬼才信~~！板砖迎击而上。Robert所抨击的，正是WIKI理念的不合时宜！
Robert的言论引发了小范围内对于WIKI理念的激烈质疑。好玩的比喻层出不穷：
“使用WIKI，就好比是把你的汽车开进修理厂，但里里外外不管什么人都要跑过来给你修理。”
“一个厨师有一种主张，一百个厨师有一百种主张。当他们争吵起来的时候，你会发现你吃不吃菜已经无关紧要了。”
……
争论的议题始于WIKI词条的可信度。很多人建议WIKI需要像传统媒体一样，有一个明确的内容生产流程，词条需要给原作者以署名权，已确定的词条即不能改动，等等。WIKI理念的维护者自然对此嗤之以鼻，认为如果WIKI这样做，那就违反了与BLOG同出一脉的草根性。
从草根谈开去，又有人建议，WIKI需要一支精干的专家队伍，以保证内容词条的准确性。于是形成了三个讨论分支：草根与精英的分离；民主与独裁的对抗；商业与免费的对立。
草根与精英的分离
多年来技术的突进，已经赋予每个人足够多的获取信息的手段。很多人早已对此前仅由传统媒体的精英所把持的话语权、议程设置权厌恶到死，好不容易找到这么一个可以汇聚草根力量的社区，如何能够又向传统的百科全书编纂一样，扯一大推精英进来呢？WIKI社区的信条是：“共同创作本应是人类生存进步的方式。”并热烈邀请大家：Be Bold（勇于参与）！但实践经验表明，没有经过特别训练的人（亦即非专家学者），实在是难以胜任百科全书的编篡工作。去年编目专家Lubetzky以 105岁高龄辞逝，网友Cat Wizard在Wikipedia上查阅其生平，看到了这样一段对于Lubetzky贡献的描述：
Lubetzky’s theory of cataloging went far beyond the Dewey Decimal System. He divised a colorful yet tactful way of identifying but ordering books where even the most simple person could find it.
Cat wizard对于此段的评价是：“完全不知所云，显然是外行所写。当时尚不知维基百科是何方神圣，只惊异于百科全书也可如此随意。”网友泅水大象也因此说道：“要真的拿维基百科当工具来使用的人本身，需要有相当程度的判断力。”
民主与独裁的对抗
作为一种技术，WIKI在互联网上一直被视为自由、民主利器。诚然，对于每一种事物，每个人都可以有自己与众不同的理解——就如有人认为黑色沉稳，有人认为黑色暴戾；有人认为西施最漂亮，有人认为老婆最美。但作为一种应用，WIKI百科全书则无法容忍为所欲为、畅所欲言。这也就是WIKI上最为人所诟病的 Trolls（可意译为“扯皮”）现象所形成之深层原因。WIKIer们信奉“没有锁的门是最不怕被撬的门”的古谚，结果家里就经常被翻腾得乱七八糟。我曾在一篇文章中使用过这样的案例：《中国大百科全书·电影卷》中对“导演”的解释是：把文学剧本搬上银幕使其成为影片的主要艺术家。可当你把这个词条的解释放到WIKI，过了几天你发现内容被人改为“导演都是大流氓”，那时你准成八大山人，哭之笑之了。
另外，WIKI中文词条中也有很多颇具后现代恶搞特色的，最为著名是当数“稻米”了。登录http://zh.wikipedia.org，在搜索框中键入“稻米”敲回车，然后你就可以看到猫扑走召弓虽贴式的介绍：
稻米的烹调：
如果煮的时候多放点水，煮熟后称稀饭，也叫粥；但水放得太多，煮熟后称撩命汤。如果煮的时候水放的比较少，煮熟后称干饭；只加一点水的煮后叫夹生饭，不加水的叫爆米花。用油炸的叫锅巴。煮成的饭有的生、有的熟、有的焦的叫三层楼。饭煮好后加水的叫泡饭。也可以把煮好的饭和蔬菜，肉，海鲜等一块翻炒，这种做法叫炒饭。著名的有扬州炒饭。
外国人也有搞出这种内容的，兹举一例：前不久Google Blogoscoped推出的新玩意Google Encyclopedia（Google大百科），就是利用Google的define operator，再加上翻译功能来组成百科全书。其中关于Adult的词条，解释是：
A person who has stopped growing at both ends and is now growing in the middle.
你无法否认这种内容的价值——多高的娱乐性啊。但你同时也无法否认：这样的内容不应该出现在WIKI百科全书当中。
网友Keven认为，Wiki需要一个志同道合的民主社群。这句话足可作为完美WIKIer虚拟乌托邦倾向的印证。在完全开放的WEB环境上，“志同道合的民主社群”的建立，谈何容易？著名社会软件学者Clay Shirky于2003年4月份在O’Reilly Etech大会上发表了关于虚拟社群的一个演讲，谈及完美虚拟社群建立之困难性，题目就叫做：A Group Is Its Own Worst Enemy. 那似乎就可以得出这样的结论：在现有情况下，没有绝对的民主，亦无绝对的独裁，那WIKI社区所生产的内容质量，实在是无法保证。
WIKI技术在新闻媒体上的应用（WIKI News），则足以想象其中最为激烈的反映：隔离墙亘立在约旦河西岸，以色列人与巴勒斯坦人共同在WIKI上维护此新闻，那这条新闻就会永远处于BETA版。至于真相……这个世界上有真相吗？
商业与免费的对立
自全球互联网业复苏以来，先哲们曾经高举的FREE大旗，眼见着被腰斩了一片。WIKI是仅存的、标有典型的彻头彻尾FREE字样的互联网应用之一。
在如何促使WIKI成为一个高质量的百科全书方面，批评家K.G. Schneider旗帜鲜明地提出，Wikipedia应当由一个高素质的专家队伍来建立，并适时维护更新。但这就绝对不是免费的了，而理所当地应该给这些专家的劳动以回报。
因为此等说法，KGS或许会被人比做“万恶不赦”的美国唱片业协会、美国电影协会，也就是曾经抵制MP3、一度剿灭了Naspter的郐子手们。但假如你每天都从Wikipedia上获取了足可信赖的知识，对你的工作生活构成便利，这个问题还需要争论吗？
反正MPAA（美国电影协会）已经四处开始抓BT了；而Bter（俗称“网络盗版电影爱好者”）还在喊冤叫屈。
错误的定位？
问题的核心就在于，素有“思想源泉”美誉的Ward Cunningham（2003年底加盟微软，任“规定性架构指南”部门设计师）所发明的基于WEB的协同编写工具，何以就被应用到了“在线百科全书”上面呢？
在百科全书之外，WIKI技术有着非常成熟的应用。在开源软件的大本营www.sourceforge.net上，很多程序员无暇编写软件的FAQ，只好搭建一个WIKI系统，让用户及其他人在试用软件之后，来帮忙撰写帮助文档。记不清是哪个软件了，其俄罗斯裔作者赞道：想不到用了WIKI，以前让他头痛的英文文档，竟然不到一星期就搞定了！
翻译工作者可以很好地使用WIKI（如果是中英互译，记得找一款中文支持比较好的WIKI系统）；中国图书出版界N多集体攒书的体力劳动者也是。还有坊间风传GOOGLE、Microsoft、Motorola等大公司在内部架设了WIKI系统供员工交流与协作的。
可是，谁让他们把这套系统拿来用做百科全书，还用了一套华丽的梦境一般的语句，来描述其灿烂的乌托邦前景的呢？
百科全书，一般来说，是对于既往已经确定了的知识的汇聚与总结，是静态的、被动的，一般般的人不能去经常质疑的。喜欢百科全书的孩子，注定是有出息的孩子。就像盖茨，从小就喜欢阅读百科全书，微软公司拽起来之后，盖茨想要拓展公司家用产品线，头一个想到的产品就是电子百科全书。当他与大英百科全书接洽时，对方一口回绝。微软转而与另一家并不起眼的百科全书出版商合作，1993年推出了Microsoft Encarta——第一个专为计算机设计的多媒体百科全书，获得了巨大的成功，并直接导致了《大不列颠百科全书》在信息时代的势微。
在Encarta 之后，尚有多家大型出版商涉足电子百科全书的，比如富豪沃伦·巴菲特旗下的《世界百科全书》（World Book）。而且，几乎所有的老牌百科全书出版商，都考虑往网络转型——前面提及的大不列颠百科全书在线版，还有集成进MSN的Encarta，等等，信息量与现有的Wikipedia相比绝不是一个重量级的，且有着良好的、商业意味浓厚的新知识加入的体系与制度，有无数经过认证的专家，领着薪水，在为这些事情贡献智力与智慧。
还有GOOGLE。这个巨无霸的意图索引上下五千年人类知识的搜索引擎，也几乎成了百科全书的代名词。（上文曾提及，他们也在既有搜索技术体系之上，推出了专门的百科全书服务Google Encyclopedia。）要寻找一个问题的答案，只需要在GOOGLE的输入框中键入关键词，敲回车，翻屏，你总不会失望而归的。凡此种种，我们真的需要一个像WIKI一样由大家共同编写的百科全书吗？
另外，不得不承认的一点是：现有的Wiki系统，都存有着严重的技术缺陷。且不说囿于网络传输速度的多媒体化，简单的WIKI语法甚至连个稍微复杂一些的图表都画不出来；搜索功能只能是最简单的找出结果来了事，统计、排序、计算等功能是不敢提的。或许，或许还应该算上这桩：程序执行效率极慢，即便是在本机上，即便是数据库中的内容少到可以忽略的地步，还是慢。
要依照现在的内容更新速度，要使Wikipedia在内容的权威性、实用性、可检索性等达到《大不列颠百科全书》、Microsoft Encarta的高度，当真连上帝都要痛哭：我怕等不到那个时候了……
所以，这是一个大家都无法忽略的事实：用WIKI做百科全书，立意过于宏大；而编辑方式，在现阶段是无法保证其质量的。这是一个WIKI技术典型的失败应用案例，而其在近三年的发展过程中，充分验证了“酒与污水定律”在虚拟社区依旧颠扑不破：把一匙酒倒进一桶污水，得到的是一桶污水；如果把一匙污水倒进一桶酒，得到的还是一桶污水。或许还可以证明一个朋友的玩笑话：在一百个上网的人当中，总会有一两个心怀鬼胎。
那么，对于这个颤栗当中的乌托邦，我们需要说些什么安慰之语吗？
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
你做了不少试验，最后得到这样的结论。
我也认为是管理问题。
比如关于翻译，同样的句子，各人坚持自己的译法可能是常见的事情。如果各人相持不下怎么办？总得有个仲裁的办法。wiki 大概不会去确定谁的好。规则应该由人来定。
所以一开始要制定游戏规则。
如果用 wiki 应该先请有经验的人来介绍经验。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我说的用 PO 来翻译目的是为了只翻译一次，之后就复用。
因为原文和译文在一起，相关性好。
为了通用可能要牺牲一些特定场合的译法。
如果把文件切分到句子。用什么工具翻译是无所谓的。
当然应该有游戏规则来保证翻译的质量。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
非常感谢。
现在开始明白什么是WIKI了，看来这个技术比较适合合作开发和翻译，虽然WIKI的成员复杂，但是只要有一组核心成员维护，应该不是问题。
|
|
----
@ 拜托!大家都是神仙,留下点回忆好不好?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
刚才看了WIKI的介绍，WIKI的设想和你的设想没有什么重叠的地方，可以先用WIKI翻译，然后用GETTEXT维护。就是不知道怎么整合他们。
但是WIKI翻译MAN格式大概会有问题，MAN不是纯文本文件，翻译的时候需要注意格式符。如果用WIKI辅助翻译，就需要人手把待译件转化成HTML文件，翻译完成后再转回来。我做过一次这个工作，感觉挺费时间的。
|
|
----
@ 拜托!大家都是神仙,留下点回忆好不好?
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
man转到html有现成工具
Texinfo - The GNU Documentation System
中文翻译
http://www.linuxforum.net/books/texinfo-cn.html
英文主页
http://www.gnu.org/software/texinfo/
Texinfo is the official documentation format of the GNU project. It was invented by Richard Stallman and Bob Chassell many years ago, loosely based on Brian Reid's Scribe and other formatting languages of the time. It is used by many non-GNU projects as well.
Texinfo uses a single source file to produce output in a number of formats, both online and printed (dvi, html, info, pdf, xml, etc.). This means that instead of writing different documents for online information and another for a printed manual, you need write only one document. And when the work is revised, you need revise only that one document.
Programs:
a2ps, for generating printable files from plain text, has a Texinfo style option.
docbook2x, conversion from Docbook to Texinfo.
gdoc, for extracting Texinfo (and other format) documentation from source files.
help2man, for generating good man pages from --help output.
ltxindex, for typesetting indices of LaTeX documents with Texinfo's texindex program.
man2texi, generate Texinfo from man pages.
my-bib-macros.texi, a start at bibliography support via Texinfo macros. For a start at integration with BibTeX, see the Web2C manual sources.
pinfo, a curses-based Info reader with color support and a lynx-like interface.
sgmltexi, Texinfo authoring via SGML tools.
Scheme Scribe, which can convert Texinfo to Scribe and generate Info files.
texi2html, an (actively maintained) alternative translator for generating HTML, roff, and chm.
texi2latex, converting Texinfo to LaTeX via XML.
texi2roff, an old standalone program that converts to troff format; it is not maintained and not up to date.
tkinfo, a Tk-based Info reader.
If you know of free software or documentation that would be useful to add here, please email bug-texinfo@gnu.org.
或者用man2html
这里还有很多小工具
http://www.ibiblio.org/pub/Linux/utils/text/!INDEX.short.html
反过来，从html到man
有perl写的html2man本论坛中老贴中有，搜索一下
|
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
wiki 即使作为文档，问题也很多，我觉得最主要的问题是通用的 wiki 没办法维护页面之间的链接，尽管它看上去很简单，实际上维护很困难，而发布也很困难。如果文档只有一页当然很好，但是如果分成章节就很麻烦了，因为没办法为它们编号，也没办法自动生成一个目录页。linuxsir 有一个 wiki，以及一个文档大家写项目，但是现在已经没多少人关心了，因为不知道应该写什么，没办法组织到一起。那个 wiki 也过于开放，不用登录就可以改，所以现在里面乱七八糟的。
除非是像 zope 的帮助手册，基本的内容是无法由所有人更改的，匿名只能添加新内容；或者像 freedesktop 那样需要登录，只有这个项目的成员才可以修改这个项目的文件；或者文泉驿那样的专用 wiki，只能以固定的方式修改特定的内容。总之，要将文档组织到一起，就不能依赖于文档的内容
如果要和 gettext 结合，那么像文泉驿那样的做法最好。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我比较注重翻译源头的文档。因为翻译是要跟随它们来更新的。
如果有 man2html 和 html2man 能来回不失真的转换当然翻译哪种格式就不是问题了。
但是要有一个清晰的数据流和与之相配的管理策略。以保证翻译的质量会越来越好。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
man 中的有些标记要在行首。使得看起来很难受。
我曾经想把在句子中的这类标记先拉到上下文中，使顶行首的现象消除，在翻译完后再恢复。
相当于只把这些标记html 化。
见附件，应该知道是怎么回事了吗? :-)
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
当时(2002年)是因为从 texinfo 生成 html 时中文有问题，才绕了个圈子，先转换成 sgml 格式，再生成 html。
现在的方法是直接从 texinfo 转换。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
我感觉所看到的cvs翻译的几处，在wiki 里说明得比较详细。别的地方就不清楚了。
主要是翻译的流程没有强调清楚。
我一开始感觉到的是 html 的。后来才明白原始的是texi。
因为企图让很多人翻译同一个文件要有个策略。
比如有１千人同时翻译一个１千句的文件。
如果约定好，一天之内大概可以完成。
如果用 PO 的格式，以CVS 即 1.1 版。 一校还是可以按句校对。但主要校语法。
他可以先快速的把认为通得过的从一个文件移到另一个文件。有疑问的可以慢慢来。同样的 PO，第二个文件比第一个的要好。
看策略，可以设二校，比如二校注重上下文。
他改掉了上下文方面的问题。三次校对比如重在统一风格和术语。每一校产生的文件都比前一个的要好。
这里分了三次校对，每条PO从一个文件流到另一个文件。
来保证越来越好。
即使此时没有完全校好，也有完全翻过的译文结果。
到底设几次校对，可以按目标来确定。
所谓的通过标准也要确定。
如果对通过三校的修改，则要通过特殊途径。
已经翻译过的句子，不再分发。
这里是三级校对的策略。
总之要有个流。流来流去要保证会好起来。
即使在 wiki 里。没有策略保证，会无所适从的。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
一点都不难，一个人从不了解 wiki 到建成，最多一个周末的时间。
我选的是 phpwiki，开源的。
各种语言的 wiki 都有开源的版本，然后找一个支持对应语言的服务器，其他没什么要求了。
|
|
[Original]
[Print]
[Top]
|
|
[Original]
[Print]
[Top]
|
三级校对的策略恐怕相当费劲，小文件也就算了，大文件仅从头读一遍也要几个钟头。而且每一校的目的不同，意味着每一校的代价差不多。而我用自己的方法校对的时候，每一读都要比上一校轻松许多的哦。也许是我自己的方法不够专业吧，反正第一遍校对别人的文章时，感觉好象重翻译了一遍似的。
翻译大文件的时候，我感觉维持一个风格和统一术语是挺麻烦的事情。因为是业余时间翻译，每天只抽出来一两个钟头，大概处理四五段的样子，翻到后面早就忘了前面是什么了 :-(
|
|
----
@ 拜托!大家都是神仙,留下点回忆好不好?
|
|
[ | | |
声明: 本页内容为中国Linux论坛的内容镜像，文章的版权以及其他所有的相关权利属于中国Linux论坛和相应文章的作者，如果转载，请注明文章来源及相关版权信息。