半亩塘闲话 » wiki

利用dabr在twitter上做口碑营销

Shizhao — Wed, 02 Dec 2009 14:58:59 +0000

记不得看到是谁在twitter发推时，在来源处写了一个广告词。发觉那里真的是一个超棒的广告位。于是刚才闲的蛋疼，用dabr也折腾了一下。效果如图：

具体实现方式很简单，有dabr（这里有建立教程）的同学到Twitter oauth修改你注册的 application，Application Name改成你想好的广告词，例如我在图中修改成了“不让冯正虎回国是中国人的国耻！”，Description可以改成具体一些的关于你的广告的详细说明，不改也没关系，因为不会有什么人看到。Application Website改成你的广告指向的目标网站或网页，我改成了冯正虎的网站：http://www.fengzhenghu.com/ 。其他就不用改了。如果完美一点，可以把logo改一下。最后不要忘了保存。

然后打开dabr源代码中的twitter.php文件，查找你原来给dabr注册的 application名字，改成现在的广告词，例如我改成“不让冯正虎回国是中国人的国耻！”记住，名字有两处，都要改。保存后上传到你建的dabr的空间，覆盖原文件。

ok。大功告成，以后你所有发的推，都会显示你改的广告词。在twitter网站和绝大部分客户端上都会显示“from xxx”(xxx就是你写的那个广告)。换广告的话，就如法炮制，重新修改一遍就可以了。（注意：必须使用oauth方式登录才有效）

呵呵，twitter这个位置上的商业潜力无限呀。绝对是一个巧妙又很有推广效果的广告位。他体现了提供这个application的推特用户的品味，依靠用户的社会信任度和application的使用频度来达到广告效果。这也算是口碑营销的一种吧。

再来一个维基百科募捐广告！

解决黑莓手机无法使用google map3.2.0的办法

Shizhao — Sun, 25 Oct 2009 13:47:32 +0000

都说中国是块神奇的土地，什么事情都有可能发生。这次就让我碰到了一件如此神奇的事情。

google前些天推出了黑莓版的googl maps 3.2.0，增加了不少功能。但是我装上后却根本不能使用，折腾了半天，发现即使卸载掉3.2，重新装回旧版，连原来能够使用的旧版也不能用了。在网上查了一下，发现很多黑莓用户都有这个问题，主要集中在北京地区的用户。安装好gmap后，第一次启动时进度条会停留在1/4处就不动了，过一会会弹出一条消息：

提示：无法建立网络连接：此应用程序需要数据连接，某些黑莓设备需要重新配置才能正常运行。有关详情，请通过计算机访问www.google.com/gmm

然后软件就自动关闭了。下次启动仍然是这样。下面是英文版的截图：

在论坛上看到有人说去国贸附近用一次就可以解决这个问题，但是这实在太匪夷所思，实在令人难以置信。然而过了两天，再一次在论坛上看到有人说去天坛附近也可以，看来真的是基站问题？

今天下午闲来无事，抱着宁可信其有的态度，坐4号线地铁直奔城南，一路上不断测试google map是否能够使用，但是都不行，本来想换地铁去天坛，但是想想4号线到陶然亭，那里离天坛也不远，或许可以。但是到了陶然亭，测试了gmap，仍然无法使用。此时信心已经被打击掉大半，想想既然出来，干脆就再去天坛一趟吧。于是接着坐地铁，转乘到达天坛东门站。一路上测试gmap ,让然连不通。

神奇就在这里，一到天坛东门，手机居然cmnet不能用了，这下子急坏了，gmap要用cmnet，可是关键时刻掉链子，那不白跑了？于是在地铁月台里坐下，折腾手机。折腾一会儿才发现，这两天为了折腾gmap，曾经把APN中的cmnet给删掉了。以前手机不用填cmnet，也一样可以用cmnet，但是大约半个多月前，突然手机怎么用不了cmnet，最后是填上cmnet才好用的。而今天一路上用手机测试gmap，因为8900有个经常断网的毛病，因此每次测试gmap之前，都要开一下operamini测试一下cmnet是否可用。但是一路上联网状况都很正常，只是一到了天坛，cmnet就不能用了。在APN中填上cmnet，手机马上就恢复了联网状态。于是打开gmap，激动的一刻来临了！gmap神奇的能够使用了！

在回家的路上，又测试了几次gmap，生怕离开天坛，又不能用了。结果发现，果然如网上所说，再也没有出现不能使用的情况。

综上所述，这很可能是北京移动的基站问题，个人感觉可能是很多移动基站的DNS解析出了问题，因为google map开启要连接一个google服务器，很可能是基站的DNS解析无法解析这个域名，而天坛附近的基站则可以解析，而黑莓有DNS缓存功能，解析成功一次后，就会缓存在手机里，因此到了别处就也能正常使用gmap了。

个人猜测或许是最近北京在大量更新基站设备，引起了上述问题？（会不会和这次扩容有关？）对于无线通信一点不懂的我，不知道上述的猜测是否正确？

呵呵，这个基站激活功能实在是有够神奇的呀。另外，我装的是中文版的gmap3.2，在第一次初始化时，说有wikipedia图层，可是进去后，在图层选项里却没有找到wikipedia图层，难道只有英文版才有？

————————————-

更新：未到第4天，又出现断网了，看来这个sb也是不行。

这次gmap问题，连带出另外一个问题。很多8900的一个老毛病就是cmnet很容易断网。修复的办法就是拔电池重启。在讨论gmap的论坛里，有位朋友提供了一个sb，号称能够解决gmap问题，但是试用了这个sb后，发现gmap问题不能解决，倒是装了这个sb后，至今已经有2天，8900居然没有一次断网（不算在天坛的断网），或许这个sb能够解决断网问题？下面是这个SB的截图：

与我原来的sb只多了一个CMCC NET。（这里下载这个sb）只希望再过几天还不断网的话，那就证明是sb的问题了。

google wave 游记

Shizhao — Wed, 21 Oct 2009 17:06:31 +0000

首先声明：本人wave提名（邀请）早已用光，不要再问我要了。

自拿到wave帐号以来，着实在wave上好好玩了一把。和很多人一样，刚刚进入wave的世界，头一个印象就是不知所措，wave是一个需要学习过程才能使用的东西。很快上手后，感觉就是一个乱字。

wave具有一个天才的设计，将论坛，email，wiki, IM, SNS这些概念揉捏在了一起，一开始，进入一个wave后，感觉就象看到了QQ，充分的富文本编辑功能展现出鲜艳颜色的字体和大字号，一时感觉很山寨，慢慢用下来，一个wave给人的感觉就像是论坛的一个帖子，第一条消息后面的讨论就像跟贴，而且是即时性非常强的那种。而wave的wiki风格，带有浓重的google docs情结，也有人用它尝试做一些文档协作工作。当然，之前说乱字也体现在这里，因为他的wiki性，同时又具有强烈的IM和BBS性格，因此在一个wave里，任何人都可以修改和删除任何人的留言，任何人都可以吧自己的联系人加入一个wave，而被加入的人自己根本不知道。你只要看过一个wave，那么这个wave就在你的inbox（email性格在此体现）里了，而且你最多只能把它mute或者扔到垃圾箱，你永远也无法删除任何一个wave，甚至是包括你自己创建的都不能删除。当然对于我这种wiki熟手来说，倒是感觉比较游刃有余，而甚少接触wiki的人则一下子很难适应。其实wiki的一条规则在这里非常适用，那就是Be Bold。

说到email，这篇文章的观点倒是对我颇有启发性，把一个wave看作是一封电子邮件，每个人在wave里的讨论就是email之间的回复。把wave当作email来用，的确是一种很爽的想法，或许wave的设计就是如此的？

目前wave的功能还有太多不完善的地方，例如大家普遍抱怨的卡，wave只要里面内容稍微多一点，就会卡的不行，如果用了一些gadget之类的在里面，那就更消耗资源了，看来，wave是一个对机器配置要求非常高的一个家伙。而更糟糕的是，一个wave有容量限制，里面的内容超过一定大小就会被系统自动设为只读，任何人都无法编辑和修改。这几天和一些朋友在wave里玩成语接龙，已经彻底把3个wave搞成只读状态了。粗略算了一下，一个wave大约能容纳600-900条消息或者3000-5000个汉字的字符数量（不知道wave是如何计算容量的）最最不爽的是，设成只读之前没有任何提示，当你要修改或输入新的内容时，系统才告诉你wave已经是只读状态了。

在只读状态下，输入新消息时才出现的提示

对wave其实还是非常抱有希望的，如果他能把gmail, docs,gtalk等google其他应用整合到一起，那是一件非常爽的事情。换一个角度，如果wikipedia能够采用wave的这种实时编辑模式，对于解决编辑冲突问题也是非常有帮助的。目前也有人在尝试这个工作：http://mediawikiwave.org

wave宕机画面

国际奥委会折腾摄影师

Shizhao — Mon, 12 Oct 2009 16:52:32 +0000

上周，澳大利亚的一位社会媒体专家Richard Giles意外的收到了一封来自瑞士洛桑国际奥委会的威胁信。国际奥委会在信中警告他去年在北京奥运会上拍摄的一张运动员照片不能够进行商业性使用。

Giles的这张照片使用了创作共用协议的cc-by-sa条款，并不禁止商业使用。作为自由内容，这张照片也在维基百科上使用。而英国的一个书商也基于同样的理由，将在2010年出版的一本吉尼斯世界纪录的书中用这张图片。但是奥委会的信中指出，奥运会门票上有明确要求，在会场中拍摄的照片只能个人使用，未经奥委会同意不能用于商业目的。但是这样做又明显与cc协议有冲突，而且自己拍摄的原创照片，居然自己没有随意授权的权利，实在是一个很滑稽的事情。

这里是关于此事的较全面的综述。维基百科上大量的用户拍摄的奥运会照片又会遇到怎样的状况呢？

致《辞海》：维基百科也不是什么都收录的

Shizhao — Tue, 22 Sep 2009 13:21:15 +0000

（1937年版的《辞海》，摄影：Formulax，cc-by-sa2.0授权）

不知道是陈昕的原话，还是记者的杜撰。无论如何，感到高兴的是，辞海的出版单位也知道维基百科，不知道新版《辞海》有没有“维基百科”词条？

只是，维基百科也不是任何人都有权利注释，发明词汇，虽然它人认可以自由编辑。维基百科对内容要求可供查证：

维基百科内容的门槛，是可供查证（verifiability），而非真实正确——亦即是：加入维基百科的内容须要发表在可靠来源中能被读者查知，而不能仅由我们认定它真实正确。撰写良好百科全书条目的关键之一，就是要谨记百科全书应该依据已经获得具公信力的出版者发表过的事件、主张、理论、概念、意见和论证。编辑者应为条目中的引言，以及任何被质疑或可能被质疑的内容提供可靠来源，否则这些内容可被移除。

另外，维基百科的一个重要方针是非原创研究：

维基百科并不是发表原创观念的地方：维基百科的所有内容都应由已发表的可靠来源支持。

条目不应该包含有对已发表材料的新式分析和合成，如若这些分析与合成产生了原始来源中并未明确的立场。

再加上中立观点，这三项是维基百科的核心原则。

当然，或许值得维基百科像《辞海》学习他的收录原则，只是作为网络百科，快速也是一个很重要的特点，而这一点恰恰是纸质无法取代的。

文汇报：十年一剑《辞海（第六版）》面世.

在回答“超女”、“囧”等新词未被收入《辞海》的原因时，上海世纪出版集团总裁陈昕表示，《辞海》是具有权威性、科学性的工具书。它对词的收录原则作了这样的规定：“凡是正在发展或经常变动的词目，暂不收入。收词需经一定时间的沉淀，真正做到大浪淘金”，“《辞海》不像维基百科，任何人都有权利注释，发明词汇，《辞海》的现代性不是体现在见新词就录，更重要的是在对所收录的词条做出准确而科学的阐释上。”

热闹非凡的中文推特用户榜单

Shizhao — Thu, 10 Sep 2009 17:40:00 +0000

在@riku的带领下，一众中文推特用户掀起了在TweepML创建各种用户榜单的热潮。在Popular Lists里，现在已经有一半都被中文榜单占领，不知道会不会变成第二个yahoo meme的样子？

榜单的力量是无穷的，一天下来，我的gmail已经被推特的follow请求刷爆，其他入选了各榜单的推友们多少也是类似情况，甚至已经为此产生了一个新词：群fo。这对于一个已经被墙屏蔽的网站来说，简直是一个奇迹！

照猫画虎，我也做了一个榜单：推特中文用户穿越精选。之所以叫作穿越，因为里面各色人等都有，而不是像其他榜单那样有比较专一的主题。

没有上我的名单的推友不要怨恨，因为从几千的还有中筛选出这95位，是很花力气的，而且一个名单只能最多有100个人，取舍之间很难决定，而且也不免有所疏漏。上了榜单的也不要心生怨恨，真的没有想到这样的名单会有这样大的杀伤力，follow请求数直线上涨，被太多人群fo是一件很可怕的事情，同时这也说明大家需要更丰富的资讯交流。当然，通过榜单follow别人的，也最好不要图省事，直接群fo，还是仔细挑选一下follow对象再定吧。当然，就喜欢见人就follow的，那就当我什么都没说好了。

我的榜单的入选标准其实很简单，都是我的follower，基本上都是在网上或网下比较熟识的，大概知道其人做过一些什么事情，推特上比较活跃，近期一直在更新，仅此而已。

推荐几个其他的榜单：

维基百科首页栏目的RSS输出

Shizhao — Fri, 04 Sep 2009 15:36:37 +0000

用Yahoo pipes做了几个中文维基百科首页各栏目版块内容的RSS输出：

特色条目：维基百科上被社群评选出来的，认为是典范德条目。一周更新一次（在每周一）
优良条目：维基百科上被社群评选出来的，认为内容还不错的条目。每天更新一次
每日图片：主要是维基共享资源上的每日图片的同步，偶尔有中文维基社群评选出的特色图片。都是社群认为非常优秀的图片。每天更新一次
你知道吗：由用户评选出来的，写的还凑活的近期新建的条目。每日3次左右更新
新闻动态：近期发生的国际性新闻热点事件的相关背景条目。不定期更新
历史上的今天：在当天的历史上所发生的一些人事。每天更新一次

这个则是把上述各栏目的RSS进行合烧后的内容。

欢迎感兴趣的朋友取用。wikipedia的rss支持比较弱，输出的都是wikitext，而不是html，不方便阅读，因此需要其他的技术手段来改变这种情况。pipes真的挺好玩的，wikimedia要是能为wikipedia专门设计这样一种工具就好了。

也可以到这里直接获得各栏目的RSS。

维基共享资源2008年度图片评选结果揭晓了

Shizhao — Tue, 09 Jun 2009 13:46:12 +0000

经过几个月的评选，结果终于出来了。以下是前三名：

西班牙圣塞巴斯蒂安东南卞蒂斯山上的马，远方是艾阿科·哈里阿山。

比利时沙斯皮埃尔喷火术表演

1942年美国伊利诺斯州芝加哥铁路站场中停放的西北铁路局的蒸汽机车。

这里是入选最后一轮的所有图片。

投票吧…

Shizhao — Mon, 13 Apr 2009 17:06:09 +0000

如何输入间隔号

Shizhao — Sat, 14 Mar 2009 15:39:39 +0000

几种与间隔号类似的符号：

符號	字符實體參照	數字實體參照	Unicode碼點	備註
·	`·`	`·`	`U+00B7`	間隔號（MIDDLE DOT）
·		`·`	`U+0387`	希臘文分號（ano teleia）
ּ		`ּ`	`U+05BC`	希伯來文點號（dagesh or mapiq）
•	`•`	`•`	`U+2022`	項目符號（bullet），常用於列表
‧		`‧`	`U+2027`	連字點（HYPHENATION POINT，英語字典）
∙		`∙`	`U+2219`	bullet 運算子（數學）
⋅	`⋅`	`⋅`	`U+22C5`	dot 運算子（數學）
・		`・`	`U+30FB`	片假名中點（全角）
．		`．`	`U+FF0E`	英文句號（全形）
･		`･`	`U+FF65`	片假名中點（半角）

第一行为中文所使用的标准的间隔号。各种中文输入法中的输入方法：

SCIM的智能拼音：izd
微软拼音输入法、智能ABC输入法、全拼输入法、极点五笔输入法、王码五笔输入法以及郑码输入法（中文标点状态）：Shift+2
谷歌拼音、黑马神拼、紫光拼音、搜狗拼音输入法、拼音加加输入法：直接按键盘左上方的“`”键（在ESC键下面的“`”/”~”键)。
- 拼音加加输入法亦可输入“jgh”
区位码：0104
倉頡輸入法：zxaq
微軟新注音及新倉頡輸入法（需按以下說明切換「中文/英數模式」或「半形/全形模式」）：
- 方法一：在中文模式下，按前導字元鍵（通常是鍵盤左上方的“`”）接ub7
- 方法二：在中文模式下，按Ctrl+Alt+”,”切換到標點符號模式，按”.”鍵，選出間隔號（需先作以下設定：點擊語言列右下方倒三角符號→設定值→屬性→進階→「標點符號自動確認輸入」選取「不使用」）
- 方法三：在中文模式下，按前導字元鍵接”.”鍵後，選出間隔號（需先作方法二同樣的設定）
- 方法四：在全形模式下，按”.”鍵後，選出間隔號（需先作方法二同樣的設定）
拼音加加输入法及搜狗拼音输入法：yd
嘸蝦米：直到5.7b版，繁體中文（，，Ｔ）模式下無法打出。^[1]簡體中文中式打法（，，Ｃ）或簡體中文台式打法（，，ＣＴ）：,.
大易：=.再選數字鍵盤的2
行列輸入法：W1，第二頁第六個。
速成輸入法：zq2或按Shift+Space（預設）再按.（會變成．）
九方輸入法：於數字鍵部分輸入：.00000002
在一些其它的五笔输入法中（如SCIM的五笔输入法），可以输入ubkg（即间隔号）。

以上资料整理自中文维基百科。

中国143种语言面临濒危

Shizhao — Wed, 04 Mar 2009 17:34:41 +0000

根据刚刚推出的《联合国教科文组织新版世界濒危语言图谱》的统计，中国有143种语言被列入不安全以上级。其中有102种语言被列入危险，有9种语言已经灭绝（全部在台湾地区）。该图谱涵盖了全球各种语言，通过谷歌地球，无论位置多小都尽可能精确的将每一种濒危语言的位置在图谱上标注出来，可以按照适当的范围和精确程度进行过滤。

图谱的数据显示，在目前存世的6000多种语言中，超过200多种语言在三代后灭绝，538种情况危急，502种非常危险，632种危险，607种不安全。

联合国教科文组织最近出版的《信使》杂志中有文章说，每一种语言都是结构独特的思想世界，它们独特的联想和比喻、思维方式、词汇、发音系统和语法，以犹如建筑般精妙的结构结合起来，但这种结构极易受到损伤，一不小心就会永远消亡。我们人类应该像关心世界动植物物种消失以及生物多样性那样关心濒危语言。

联合国教科文组织总干事松浦晃一郎说：“一种语言的消失导致许多非物质文化遗产形式的消失，特别是使用这种语言的团体——不必说诗和传说，更不必说谚语和笑话——传统和口头表达组成的珍贵传承。语言的消失同样损害人与生物多样性之间保持的关系，因为语言荷载着丰富的自然以及宇宙知识。”

对于这些语言的保护，各国/团体采取了不同的计划和举措：澳大利亚有些语言曾被认为已经消亡数代，但后来发现它们只是“休眠”而已，于是重新使用这些语言的运动活跃起来并取得了成功。新西兰通过“语言小巢”计划——即将语言传给年轻一代的托儿所——拯救了几乎被人们遗忘的毛利语。但是那些获得国家支持并具备基础设施的计划是最成功的，如威尔士语和加泰罗尼亚语分别在威尔士和加泰罗尼亚再次使用，这两个欧洲地区在我们有生之年就已取得成功，当然还有希伯来语作为以色列的民族语言也得以复兴。那么通过wiki的形式是否也能保存这些语言呢？

维基百科的一次编辑统计

Shizhao — Mon, 23 Feb 2009 17:46:09 +0000

条目         访问次数   编辑次数   当日浏览量排名   不同用户数   备注                                         参与率
Wiki                  6981               1         1                    1   bot编辑，半保护      0.01%
红色高棉    5010              18                        2                    2                                                                 0.36%
维基百科          4880              2                         3                     2             半保护，新手破坏                    0.04%
Favicon.ico   3952              0                          4                    0             重定向页，
很可能是来自错误访问的流量   0%
學警狙擊           3636           27                         5                    15   很多是匿名编辑，3天前创建   0.74%
葉問                  2283             0                          6                     0                                                                  0%
光陰的故事      1979              7      7   5      其中5次是匿名编辑               0.35%
守護甜心!          1795      1                           8   1 重定向页，匿名编辑                  0.06%
中文维基百科   1621           3                           9                    3                用户破坏，1次bot编辑   0.19%
Av女優              1564      1                         10      1               0.06%
陳怡蓉               1511      2   11   1                      匿名编辑   0.13%
田中千繪           1429            0                           12                 0                     重定向                                    0%
牛博网   1302      0                          13      0          0%
模范棒棒堂       1231            5                           14                 3                           3次匿名编辑      0.41%
中越战争    1214   3    15      3                        匿名破坏，bot编辑 0.25%
40388   70       2.47                                                                0.17%

这是利用http://wikistics.falsikon.de 上09年2月18日的数据制作的一个表格。统计了当日浏览量最高的15个条目的访问次数和编辑次数，“参与率”是编辑次数与访问次数之比。

可以看到，在访问最多的15个条目上（访问量的很大一部分应该来自其他网站或搜索引擎），基本上1000此访问才有1－2此的编辑，或者说，1000次的访问，才会出现1－2次的用户参与编辑。

看来还是看的人多，真正肯参与的人太少。

看看wikimedia项目价值几何？

Shizhao — Wed, 04 Feb 2009 13:06:20 +0000

$TIMATOR可以根据网站在搜索引擎中的所占的各项权重来估算一个网站的价值。当然，这更多只是一个娱乐而已。那么就拿wikimedia各项目娱乐一下看看(貌似$TIMATOR不能估算某些二级域名)：

wikipedia: 66,737,185

wiktionary: 1,406,563

wikibooks: 185,058

wikiquote: 156,814

wikisource: 60,743

wikinews: 122,221

wikiversity: >170000 (不知为何，其他最多1分钟就算完了，唯独这个算了10分钟数字还在滚动，或许是个bug?)

mediawiki: 755,502

所有wikimedia.org域名下的网站：2,573,232

网址前加www和不加www的价值不同，以上都是不加www的数据。只有wikisource不加www则报错，不知为什么，因此只好加上了www。

虽然这不能太当真，但是也能从一个侧面看出wikimedia各项目的网络认可度和用户参与程度。

顺便一提，本blog的估值是202，而原来的talk.blogbus.com则是93,543。估计是因为刚刚独立的原因。

如何用mediawiki建一个wikiblog

Shizhao — Wed, 14 Jan 2009 14:53:59 +0000

刚刚用mediawiki（wikipedia所使用的wiki平台）建了一个wikiblog(又叫作bliki)——维基观察，就是一个建立于wiki平台上的blog。所使用的主要的mediawiki扩展如下（这里可以看到我所使用的全部扩展）：

WikiSkin：优点是可以完全定制自己wiki网站的版面布局（在这里定制），缺点是原来系统自带的所有CSS样式斗废掉了，全部要自己在Common.css里重写，当然这样会更灵活和方便。在LocalSettings.php里设定：

require_once(“extensions/Wikiskin.php”);
$wgWikiSkinArticle=Wikiskin;

HeaderFooter：定制自己每个页面的头部和脚部，这里头部是页面中条目标题开始处，脚部是条目内容结束处，不是整个页面的头部和脚部。这个扩展非常灵活，甚至可以对每个页面都定义不同的脚部和头部，搭配wikiskin就更加强大灵活。设定：

require_once( “$IP/extensions/HeaderFooter/2.0.1/HeaderFooter.php” );

StubManager：HeaderFooter扩展所需的东西。设定：

require_once( “$IP/extensions/StubManager/1.3.0/StubManager.php” );

ArticleComments：为wikiblog的每篇文章增加blog风格的留言系统。设定：

require_once(‘extensions/ArticleComments.php’);
$wgArticleCommentsNSDisplayList = array(NS_MAIN, NS_TALK, NS_USER_TALK); //设定在哪些名字空间显示留言板
$wgArticleCommentDefaults['showurlfield'] = true; //是否显示url填写区域

DynamicPageList2：根据你设定的条件显示内容。我的wikikblog的側边栏和首页等都是用他生成的，这样就不用像平常的wiki那样一页一页手工更新内容了。可能的问题是，过于复杂的DPL会增加服务器的负荷。设定：

require_once(“$IP/extensions/DynamicPageList/DynamicPageList2.php”);

WikiArticleFeeds：blog怎能没有feed？但是mediawiki所提供的几个rss输出的都是wiki化文本，不是浏览器可读的HTML。这个扩展则可以在某个页面生成该页面的rss。但是问题是这个扩展对于中文系统的支持有问题，中文下无法检测出作者和日期。设定：

require_once(‘extensions/WikiArticleFeeds.php’);
$wgFeed = false; //禁止掉系统自带的rss
$wgMaxCredits =-1;

各种条件判别等比需有ParserFunctions，这样你的wiki才够强大，才可以作很多事情。如果你要向我一样弄个分类云，则要装ParserFunctions (extended)和Variables：

require_once(“$IP/extensions/ParserFunctions/ParserFunctions.php”);
require_once( “$IP/extensions/Variables/Variables.php” );

blog上还会用上许多Widgets，那就装上它：

require_once(“$IP/extensions/Widgets/Widgets.php”);
$widgetNamespaceIndex = 274;
$wgGroupPermissions['sysop']['editwidgets'] = true;

不要让人随便编辑，那么就装上EditOnlyYourOwnPage。这样其他注册的用户就只能编辑自己的用户页和用户对话页。和ArticleComments搭配非常完美，用户可以通过它在对话页留言。

有了这几个扩展，一个wikiblog就基本建成了。为了增强更多的功能，更像一个blog，可以设置一下：

$wgUseTrackbacks = true; //启用Trackback功能。但是貌似只能提供本站的Trackback，而不能ping别人（我自己顺便测试一下）
$wgNoFollowLinks = false; //对http://这样的连接不使用NoFollow
$wgShowSQLErrors = true; //调试用
$wgHideInterlanguageLinks = true; //把mediawiki上的跨语言连接功能去掉
$wgUseCommaCount = false; //文章计数方式
$wgAllowExternalImages = true; //可以直接引用外部图像

设定网站的logo：

$wgStylePath = “皮肤所在路径”;
$wgLogo = “{$wgStylePath}/common/images/logo.png”;

设定网站的favicon.ico（可以用这个在线制作）

$wgFavicon = “$wgScriptPath/favicon.ico”;

设定好cache，优化访问速度：

$wgUseFileCache = true; /* default: false */
$wgFileCacheDirectory = “$IP/cache”;

如果要使用维基共享资源上的图片，可以这样设定（必须是1.13以上版本才支持）：

$wgForeignFileRepos[] = array(

   'class'                   => 'ForeignAPIRepo',

   'name'                    => 'shared',

   'apibase'                 => 'http://commons.wikimedia.org/w/api.php',

   'fetchDescription'        => true, // Optional

   'descriptionCacheExpiry'  => 43200, // 12 hours, optional

   'apiThumbCacheExpiry'     => 43200, // 12 hours, optional, but required for local thumb caching

);

现在基本上看不出太多的wiki痕迹了。但是还有一些问题目前不好解决。一个是评论功能只能一篇文章显示它最近的一条评论，而不能按照顺序列出一篇文章的多个评论。二是目前的这个wikiblog没有tag功能，貌似wiki天生就看不上tag，我这里就是勉强用分类来代替tag。三是文章的存档还是必须自己来弄，系统不会自己生成。

另外，用medawiki建立blog并不是只有这一种方法。例如用wiki左右编辑平台，而文章出版平台用wordpress，见WikiToWordPress。或者是用wordpress的评论功能作为wikiblog的留言系统，见WordPress Comments。甚至以用户为单位的blog系统：My blog。（这个适合作多用户的wikiblog，或者叫做WBSP？哈哈）如果你有服务器的操作权限，你也可以用wikilog这个扩展建立blog（这个扩展相当不错）。可以参考这个wikiblog。这个是我见过的第一个中文wikiblog。

wikimedia即将举行授权方式转换的投票

Shizhao — Mon, 12 Jan 2009 12:52:36 +0000

从2月20日至3月20日全维基媒体项目将对从GFDL1.2转为GFDL1.3以及CC-姓名標示-相同方式分享双重授权的投票。这里有这次讨论的Q&A。

wikimedia基金会的wing以个人角度详细阐释了这个改变的重要性和所带来的影响：

我个人认为目前的解决方案不是最理想的方案，但是是最可行的方案。

我想在这里对上面的这些说法做一个比较详细的解释。这个解释与Meta上面的问与答的解释有可能有不同的地方，因为这完全是我个人的理解。

我们目前做这个转换最主要的原因是历史原因。2002年维基百科刚刚开始的时候还没有创作共用（CC），当时维基百科寻找一个自由协议的时候我们只有GFDL这一个选择。GFDL是自由软件基金会（FSF）推出的。如名所说，FSF最主要的目的在于推广自由软件，而不是自由内容。GFDL最初推出时的目标在于为自由软件的说明书提供一个自由的版权协议。而不是为维基百科这样的项目设计的。软件说明书的编辑与维基百科条目的形成有很大的不同。其中最大的不同在于软件说明书参与的人要少得多。一般来说一份比较详细的软件说明书的幅度也比维基百科条目的幅度大。因此GFDL里比如有要求列出最后五名重要贡献者的名字等等的要求。

维基百科刚刚开始的时候这些要求比较容易满足，但是随着时间的发展它们对于维基百科中条目的编辑和使用逐渐地产生了很大的限制和造成了技术性困难。比如维基百科中往往一个条目中的内容会被拷贝到另一个条目中去，一个很常见的例子是比如一个国家的历史部分被拆开分成一篇独立的文章。技术上来讲假如需要完全符合GFDL的话那么新文章的历史中应该列出老文章历史部分的最后五名主要贡献者，实际上当然我们从来没有这样做过。维基百科的文章假如集中在我们的网站上的话那么至少理论上我们随时可以找出过去编辑的历史。但是假如维基百科的文章被转载到其它网站上去了，或者甚至于被印成书或者DVD了，这就非常麻烦了。设想台湾这样的文章有数以千计的编辑，要定义哪些编辑是最后五个主要编辑者非常困难，而且肯定会造成许多争议，因此目前的做法是把所有参与作者的名字都列出来，但是像台湾这样的文章印到纸上的话光是把所有作者列出来幅度与真正文章之间的比例就已经非常大了。事实上把维基百科的内容转到其它媒体造成的版权技术性问题是使得基金会考虑改变使用GFDL最主要的原因。因为GFDL对我们的限制实在太大了。

这也是为什么CC比GFDL普及的原因。CC比GFDL出现得晚，它出现的时候维基百科已经决定使用GFDL了。CC实际上更加符合维基百科这样的使用，其中最主要的就是它本身就是为了维基百科这样的自由内容设计的，因此避免了上面所说的GFDL的这些毛病。

CC比GFDL普及还造成了另一个矛盾：理论上我们在维基百科中不能使用CC的内容，包括CC-姓名標示-相同方式分享的内容，因为CC-BY- SA的规定比较松（比如就列举作者方面）。因此实际上把CC-BY-SA的内容加入维基百科实际上是违反GFDL的要求的（在中文维基百科上实际上我们至今为止没有去考虑过这个问题）。也就是说至少在理论上许多网上有的自由内容被放进维基百科中是违法的。这同样对我们造成了一个非常大的限制。

出于同样的原因维基百科上的内容也不能转到使用CC-BY-SA的网站上去，也就是说虽然大家同样追求同一目标：自由内容，但是互相之间又造了一堵墙。

出于许多这些原因基金会从四年前开始就开始与FSF和CC在讨论怎样克服这些问题，以及怎样克服CC与GFDL之间的不相容性。这个讨论持续了四年，其中数度濒临失败，可见其中的困难重重。这里有各种各样的原因，其中包括技术上的原因、思想形态上的原因、人际间的原因，我就不一一列举了。对于 FSF来说，他们最主要的目标是自由软件，因此他们所有的协议、工作全部是集中在这个目标上的，他们当然不希望因为维基百科而使得在他们的方面发生困难，但同时他们当然也认识到我们的困难。因此大家要一起在这些矛盾中找到一个折衷方案。

而这个这种方案就是目前提出的GFDL1.3和CC-BY-SA双重授权的方案。如我一开始已经说过，我认为这个方案不是最理想的，但是是目前最可行的。

这个方案给予维基百科过渡到CC-BY-SA的可能性，来避免上面所说到的困难，而同时又保护了GFDL本身固有的为自由软件说明设立的规定和要求。

在这个规定下维基百科的内容既按照CC-BY-SA的规定发表，又按照GFDL的规定发表，CC-BY-SA是主要的授权方式，同时过去按照 GFDL1.2发表的内容可以自动地转化为双重授权。维基百科的内容从此后可以被转换为CC-BY-SA（比如转到其它网站，印成书等等的时候），也可以转到纯粹使用GFDL的网站。

那么为什么我说这个方案不理想呢？

首先这个转换是有时间期限的。维基百科（或者其它目前使用GFDL1.2的网站）必须在2009年7月31日以前决定它们是否转换。2009年8 月1日以后这个可能性就消失了。这个期限是FSF提出的，因为他们不希望这个转换是随时的和任意的。对于他们来说这个转换仅仅是为了方便维基百科的，他们不希望许多网站效仿。

第二个最大的矛盾时转换后纯粹使用GFDL发表的内容无法在维基百科中使用。原因是纯粹使用GFDL的要求比CC-BY-SA的要求要严格。而按照规定在2009年8月1日以后不能进行转换。我个人觉得这是这个方案中最大的弊病。因为它忽略了许多模仿维基百科使用GFDL的网站。这些网站必须在 2009年7月31日前也把他们的版权协议转换为GFDL1.3和CC-BY-SA，否则的话维基百科就无法使用它们的内容了。这里涉及到比如香港网络大典或者伪基百科等等网站。因此我也在这里呼吁认识和参与这些社群的维基人把这个讨论提到这些社群中去，2009年7月1日还有半年时间，但是这个时间在社群讨论过程中实际上是很短暂的。

在基金会的邮件列表（foundation-l）中有人提出以下这些批评，我个人认为这些批评不正确：

首先有人提出通过利用一些CC中的空子可以使得自由内容转化为非自由内容。就我所知这个指责不正确，因为首先至今为止没有发现有这样的做法，其次例子中所设计的方法非常地复杂，而且按照CC的律师的看法这个做法实际上不是使用规定中的空子，而是违法的。

其次有人担心CC本身可能会在今后版本中使得CC-BY-SA变得越来越不自由。我觉得这个指责没有根据。CC的目标也是促进自由内容。CC不像 FSF那样极端，它提供的其它版权协议有些限制自由使用（比如非商业性使用），但是我看不出任何根据CC为什么要改变CC-BY-SA的宗旨。

如上所述，我个人认为目前的方案不是最理想的方案，它有它的弊病，但是它是多年讨论获得的最佳可行结果。因此我会从个人角度投赞成票。

在昨天刚刚结束的基金会理事会会议上理事会也一致通过了一个决议，呼吁社群赞成这个转换。总的来说它对于我们未来的工作会提供更多的便利。这个呼吁将在近期内发表。–Wing (留言) 2009年1月12日 (一) 11:46 (UTC)

因此，这里也呼吁其他使用GFDL的wiki网站，尽快在2009年7月31日之前把版权协议转换为GFDL1.3和CC-BY-SA。

谷歌的赤壁之战地图

Shizhao — Tue, 23 Dec 2008 14:08:31 +0000

（很明显，从上面的官方截图可以看出谷歌中国的员工用的是chrome浏览器）

谷歌中国员工利用20%时间发布了赤壁之战地图，地图非常精美。声明中说：

本地图为谷歌中国团队制作。赤壁之战地图中所使用的各种数据，为参考《后汉书》、《三国志》、《资治通鉴》、《三国郡县表》等书籍资料，以及维基百科等网站，整理获得。

看到维基百科几个字，于是特意仔细找了半天，却没有看到地图及其说明文字上有任何指向维基百科的链接。于是又查了一下这个地图的项目页面（非常高兴看到地图层的源码是GPL发布的），在人物介绍的源码部分可以看到维基百科上相应人物条目的链接，例如：

{“name” : “程普” , “zi” : “德谋” , “hao” : null , “event_ids” : [25 , 32] , “element_ids” : [35 , 39] , “birth” : null , “death” : null , “birthplace” : “右北平土垠” , “desc” : “早年在州郡担任官吏，后跟随孙坚四处征战，数有战功。初平二年，孙坚战死，程普继续跟随孙策到淮南起兵。孙策入主会稽时，程普立功最多，封为吴郡都尉，治于钱唐。后先后被封丹杨都尉、荡寇中郎将，领零陵太守。建安五年孙权继任后，程普巡视三郡，讨平不服之人，与周瑜同为左右都督，建安十三年大破曹操于乌林，乘胜进攻南郡，拜为裨将军，领江夏太守。建安十五年，周瑜逝世，程普代领南郡太守。孙权与刘备结盟，将南郡分给刘备，程普还领江夏，升为荡寇将军，不久逝世。” , “kindom” : “吴” , “wiki” : “http://zh.wikipedia.org/w/index.php?title=%E7%A8%8B%E6%99%AE&variant=zh-cn” , “pic” : “http://laiba.tianya.cn/laiba/images/274/12295246982042868945/A/1/o.png” , “center” : {“lat” : 31.037 , “lng” : 114.203}},

只是很奇怪为何没有把链接放到地图的人物说明里？另外，我们也可以从这个源码中看到，繁体版的赤壁地图也在开发中（文件名后面带tc的就是繁体版的），只是不知道何时会上线？

另外，我也想知道，google的mapplet脚本可以用到别出去吗？例如在World Wind中使用？

在mediawiki上使用wikicommons的图像资源

Shizhao — Sat, 29 Nov 2008 10:11:07 +0000

维基百科的姊妹计划之一——维基共享资源（wikimedia commons）是一个储存自由版权图像，视频和音频的wiki网站，其目的是为维基百科等维基媒体计划提供多媒体资料库。上传到维基共享资源的图片可以在维基百科等计划中直接调用，从而不必重复上传。

此前这些图像资源一直只能在维基媒体计划中使用，其他的用mediawiki架设的wiki网站不能调用维基共资源上的图片。但是自1.13版以来，这已经可以实现了。在LocalSettings.php文件中加入以下语句：

$wgForeignFileRepos[] = array(
   'class'                   => 'ForeignAPIRepo',
   'name'                    => 'shared',
   'apibase'                 => 'http://commons.wikimedia.org/w/api.php',
   'fetchDescription'        => true, // Optional
   'descriptionCacheExpiry'  => 43200, // 12 hours, optional
   'apiThumbCacheExpiry'     => 43200, // 12 hours, optional, but required for local thumb caching
);

更多请看这里。

支持维基百科！

Shizhao — Thu, 06 Nov 2008 12:07:03 +0000

维基百科又开始捐款了，这次的目标是600万美元，现在已经筹集到了1/3。

上面的宣传条幅代码：

Knol vs Wikipedia (Knol初体验)

Shizhao — Fri, 25 Jul 2008 06:48:51 +0000

google Knol，一款号称对抗wikipedia的产品上线了。knol，百度百科，维基百科三者之间存在很大的不同，甚至这三者之间的比较或许都不是可以比得，因为定位不同。

knol注重于人，注重于作者之间得社会性和互动。更像是一个百科社区，而不是百科全书。从内容上来说，维基百科走的是传统百科全书的路子，每一个主题词就是一个条目；百度百科虽然叫做百科，但是更像是一个资料收集处，而Knol则更像是一个以主题词区分的论文收集处，而不是百科（其实Knol从未称自己是百科）。G日报误称之为“谷歌百度全书”实在是形象不过。

倒是Knol对文章中的外部连接采用了nofollow标签，和维基百科一样，杜绝强大的spam，只是不知道作者负责的模式，对于spam有何有效的对策？或许和百度百科一样，背后还有一个神秘的内容管理团队？

维基百科是wiki的典型代表，但是百度百科和Knol虽然也有版本历史等wiki的特性，但是都不把自己称作wiki，很有趣的态度。

在版权方面，维基百科全部文字内容采用GFDL授权，属于严格意义上的copyleft，所谓病毒式授权。而Knol虽然默认的授权方式是cc-by（比GFDL更加宽松，就像BSD之于GPL），但是还有cc-by-nc（非商业使用）和版权所有二者可供作者选择，而且作者可以随时修改授权协议，这对于他人对作品的使用来说存在一定的风险（当然在中国可以忽略不计）。最奇怪的是，Knol不给出cc-by-sa的协议选项（类似GFDL），不知道葫芦里卖的什么药？而百度百科则是一个揣着明白装糊涂的版权声明，所有的内容都可以为他所用，但是别人不能用他的东西。

Knol在内容质量上的把握，一是借助于作者的信任度和权威性，二是通过作者邀请其他人社会评审的模式，来检查错误，这不像是维基百科依靠所有参与者的力量，大家既是作者，也是评审。至于這二者之间谁好谁坏，一时很难有定论。至少维基百科的模式在实践中更容易发现错误和纠正错误。

目前knol支持多语言，但是并不像维基百科一样根据不同语言分设，而是所有语言混在一起。例如这篇在knol上中文的文章。knol的文章的url有点像维基百科，根据标题自动产生，但是只支持拉丁语系，中文标题的话，则是在url上产生一段乱序的字符（或许是某种编码？），例如这个。

Knol的编辑界面是所见即所得的，而且也有比较丰富的功能，虽然功能上距离维基百科还有很大的距离，但是比百度百科要强很多了，至少能够写一些稍微复杂一点的东西了。在功能上，维基百科的优势很明显，可以编辑复杂的表格，还有可以嵌入的强大模板功能，时间线，TEX支持的数学公式，甚至支持埃及的象形文字，而且支持视频和音频。Knol的参考文献功能也比百度百科强，但是似乎还存在一些bug（点击文章中的文献标号只是重载页面，没有其他反应，按理来说应该直接定位到相应的参考文献上）。

当然，目前knol可能是文章较少，因此首页的布局非常差劲，难怪遭人批评。但是google强大的财力和技术，只要对这个产品足够重视的话，揉合google的其他产品，应该会变得相当强大。只是同一个主题允许多篇文章存在的模式，实在不太喜欢。过于注重人，而不是注重内容，不会上演SNS变形记吧？

网站的共生

Shizhao — Tue, 10 Jun 2008 17:24:33 +0000

经过一些实践和观察，看到了三个网站之间的共生关系，比较有趣。三个网站是：solidot, 译言和中文维基百科。

solidot作为一个geek类的科技资讯网站，用户提交的内容多为IT和科技方面的有趣消息，尤其以外文的消息为多，又非常及时。 solidot更好的一点是必须至少提供一个消息链接。这为中文维基百科提供了相关条目内容更新的消息来源，可以把最新的内容补充到维基百科的条目中去。反过来，维基百科又为solidot提供了新闻的背景知识（通过链接的形式）。

译言作为外语内容的翻译网站，上面有很新的外文文章，一些用户也会翻译一些英文或其他语言维基百科的条目内容，这些翻译的维基百科条目，依据GFDL协议，又可以被直接整理复制到中文维基百科上，尤其是在中文维基百科访问不畅的情况下，可以帮助维基百科补充一些条目内容。而译言上的一些新鲜的外文文章，又可以作为solidot消息来源的中译参考，或者直接作为solidot的消息来源。而反过来，solidot上的外文消息中的消息来源，又可以作为译言上一些文章翻译的来源。

三个网站之间得这种有趣的互生关系，或许是一种别样的web2.0？或者这才是真正的web2.0?

半亩塘闲话 » wiki

利用dabr在twitter上做口碑营销

相关日志

Recent Comments

解决黑莓手机无法使用google map3.2.0的办法

相关日志

Recent Comments

google wave 游记

首先声明：本人wave提名（邀请）早已用光，不要再问我要了。

相关日志

Recent Comments

国际奥委会折腾摄影师

相关日志

Recent Comments

致《辞海》：维基百科也不是什么都收录的

相关日志

Recent Comments

热闹非凡的中文推特用户榜单

相关日志

Recent Comments

维基百科首页栏目的RSS输出

相关日志

Recent Comments

维基共享资源2008年度图片评选结果揭晓了

相关日志

Recent Comments

投票吧…

相关日志

Recent Comments

如何输入间隔号

相关日志

Recent Comments

中国143种语言面临濒危

相关日志

Recent Comments

维基百科的一次编辑统计

相关日志

Recent Comments

看看wikimedia项目价值几何？

相关日志

Recent Comments

如何用mediawiki建一个wikiblog

相关日志

Recent Comments

wikimedia即将举行授权方式转换的投票

相关日志

Recent Comments

谷歌的赤壁之战地图

相关日志

Recent Comments

在mediawiki上使用wikicommons的图像资源

相关日志

Recent Comments

支持维基百科！

相关日志

Recent Comments

Knol vs Wikipedia (Knol初体验)

相关日志

Recent Comments

网站的共生

相关日志

Recent Comments