标签:mediawiki

校内维基的构想与实现

在写下这一篇的时候,我们的维基还是一个知名度不高的校内网站。经过近一年的尝试调整,渐渐得到了发展的方向。去年的时候,我们开始构想一个校内百科。动机很简单,我们觉得每个大学都会需要一个百科全书样的东西。我们的参考目标是维基百科,依靠mediawiki和理想化的社群模式运作。而在这之前,至少有五个类似的网站已经失败。

开始的时候我们有一系列定位和发展规划。制订了内容收录规范,以及社群守则。因为蓝本是维基百科,所以我们觉得它会像维基百科一样依靠用户贡献发展。问题是很多事情不一样。

首先是网站本身的意义。学生们并不是非常需要了解学校的历史,建筑和人物。即便需要的时候,他们也会去查询谷歌搜索。基本的信息维基百科都可以包含,我们只是做了一个更详细的工作,却花费了太多时间。既然是内容主导的网站,什么样的内容最被需要才是关键。

然后说说用户群体。我们的用户群体,是本校学生和教师。我们希望大家能通过此平台分享知识,互助协作。然而师生对此理念并不了解,网站在大多数人眼里仍是一个放内容的工具。一个开始就没有内容的网站,如何让用户参与其中呢?他们会怀疑网站未来的延续问题。

在技术上同样存在麻烦。mediawiki的内容编辑是通过代码实现的,十分复杂,而且不够直观。这严重阻碍了一般用户的参与。

我们的运营也有不少失误。太多的限制和质量要求让早期的内容积累举步维艰。像版权问题,我们并没有能力去验证,实际上是形同虚设的要求。

后来我们陆续进行了几项改变。

收录内容范围扩充,计划成为校内资料库。包含校内信息,在线教材,学习经验,共享文件等。

组建内部编辑组,积累原始内容。我们还通过技术从其他网站导入信息。内容积累足够多,用户对它的认可度也会增加。

在可视化编辑器部署之前,我们通过提供简捷的帮助,降低用户参与的难度。

同时也取消了不可执行的规则,以促进早期的内容积累。

现在的校内维基,已经改变了很多。我们很希望它会是一个成功的网站。

MediaWiki MathJax数学公式

原理

MediaWiki的插件一般由php脚本和javascript脚本组成,直接上传到服务器,并在配置文件内添加插件路径即可使用。

Math插件的安装比较繁琐,因为它还依赖于其他本地应用程序,如mineTex。Math是一个统一化的接口,用户使用同样的数学公式代码,却可以通过不同方式生成公式。这些方式包括:PNG图片,LaTex,Tex,HTML,MathML等。而Math并没有实现这些功能的模块,需要调用其它应用程序。

目前默认的后端是Texvc,它可以生成PNG图片。这种方式需要服务器安装mineTex本地应用程序。然而对于共享空间上的站点来说,可能无法安装软件。PNG图片的显示效果也不好,在屏幕分辨率高的情况下不够清晰平滑,不能随文本缩放。因此,MediaWiki未来将会采用另一种表现更好的方式——Mathjax。

MathJax是一个开源的JavaScript数学公式显示引擎,适用于几乎所有现代浏览器。它被广泛应用于Wiki,WordPress博客等站点。使用它非常简单,只要在网页上的head标签内加入

<script type="text/javascript"
   src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML"></script>

即可。对于WordPress,MediaWiki等平台,若需要在整个站点启用此特性,则应在站点皮肤的HTML/PHP脚本中添加。

可以看出,这实际上是调用了MathJax在线引擎,JavaScript脚本存放于远程服务器上。若是在本地局域网内不能访问国际互联网,则可以下载MathJax并安装在本地,链接修改为本地站点。

步骤

对于MediaWiki,通过Math插件添加更加方便控制,且能应用于所有皮肤中。

第一步,下载Math插件

第二步,上传Math插件。将插件解压并将文件夹上传到extension目录中,命令文件夹为Math。

第三步,注册Math插件。打开LocalSettings.php,在插件注册部分添加:

require_once("$IP/extensions/Math/Math.php");

第四步,配置Math插件。打开/extensions/Math/Math.php,更改如下几条配置信息:
1.关闭Tex

$wgUseTeX = false;

2.开启MathJax

$wgUseMathJax = true;

3.设MathJax为默认

$wgDefaultUserOptions['math'] = MW_MATH_MATHJAX;

Math默认调用MathJax官方网站的引擎。若你在不连接国际互联网的情况下使用,或者希望使用自己的服务器提高效率,可以安装自己的MathJax引擎。

第一步,下载MathJax引擎

第二步,上传MathJax到服务器。

第三步,修改Math插件配置:

$wgMathJaxUrl = 'http://yoursite.org/mathjax/MathJax.js?config=TeX-AMS_HTML';

URL修改为你的MathJax引擎所在的位置。

对于学校内,企业内,组织内的网络系统,可以搭建一个开放MathJax引擎,供所有内部站点使用。

自定义名字空间及别名

名字空间的作用

名字空间可以理解为类似C++,Java的命名空间。名字空间能够对维基页面进行组织,划分页面的本质属性或者内容区分。这比页面分类更加显著,从名字便可以判断。名字空间还能够避免重名,如维基百科的“维基百科:首页”和“首页”就是不同的,一个是站点的首页,一个是名为“首页”的词条。

名字空间的原理

每一个名字空间都有自己唯一的ID,ID是不会变更的。这个ID是页面的属性,将页面绑定在这个名字空间内。而ID对应的名字空间的名字,则可以变化更改。若新建的名字空间与原来曾有的名字空间同名,并不会令那些页面转移到新名字空间下。就像一个人可以改自己的名字,但这个人的本质不变;当然,其他重名的人,也不是这个人。

名字空间具有名字和别名,就像一个人会有好几个名字。名字是默认显示的,而别名会链接到名字。别名让同一个名字空间具有多种书写方式,这样做的好处很多。首先如果你输入WP别名,会比输入Wikipedia更快,简写有时很有效;其次,可以避免混淆,误把近义词当作名字空间,结果没产生任何实际效果;还有就是本地化,中文用户可能更喜欢输入“分类:”“维基百科:”而不是“Category:”“Wikipedia:”。

MediaWiki具有一系列系统名字空间,比如主名字空间,帮助,项目,分类,模板,特殊及相应的讨论等等。这些名字空间不可更改。它们占据了0-99的名字空间ID,虽然并未全用。因此我们只能使用100以后的名字空间。

自定义名字空间

和大多数设置一样,自定义名字空间需要在LocalSettings.php里面完成。因此第一步就是打开站点的LocalSetting.php文件。

自定义设置一般都会写在配置文件的末尾,以免和系统默认设置混淆。加一段注释,如#Namespace Setting,会让配置文件更加清晰。

名字空间ID是整数,为了避免大意出错,通常会设置一个常量。因为一般会将名字空间和相应的讨论页名字空间定义在一起,所以它们总是成对出现。使用NS_前缀可以清晰地表达这个常量是一个名字空间ID。来看看下面这个例子:

define("NS_FOOL", 100);
define("NS_FOOL_TALK", 101);

然后就可以自定义新的名字空间了。

$wgExtraNamespaces[NS_FOOL] = "Fool";
$wgExtraNamespaces[NS_FOOL_TALK] = "Fool_talk";

如果你想要将这些名字空间设置为内容名字空间:

$wgContentNamespaces = array( NS_MAIN, NS_HELP, NS_FOOL, NS_TALK );

*这里的常量都代表着一个数字,NS_MAIN是0,NS_FOOL是100。
*内容名字空间和主名字空间本质相同,也会出现在主名字空间的搜索结果中。

这样,我们就为一对名字空间赋予了名字。以后在这些名字空间下创建的页面,会自动被归入相应的ID下。当名字空间的名字被修改后,那些页面也会随着变化。

最后,让我们来为它们添加别名。一个名字空间可以拥有无数多的别名,无论英文,中文还是保定话。

如果你只想设置一两个名字空间别名:

$wgNamespaceAliases['F'] = NS_FOOL;
$wgNamespaceAliases['F_talk'] = NS_FOOL_TALK;

如果你想设置一大堆名字空间别名:

$wgNamespaceAliases = array(
        'F' => NS_FOOL,
        '笨蛋' => NS_FOOL,
        '二傻' => NS_FOOL
    );

好了,现在维基站点就能够使用这些名字空间了,用名字和别名都可以。

多语言维基

多语言维基的实现,有三种方式。他们的架构及运作原理有很大差异。

多语言站点

为每种语言建立一个维基站点。这些站点具有独立的数据库和维基软件,可以看作是两个完全独立的网站。

它们通过二级域名,或目录进行区分,如 http://zh.wikibooks.org/ ,http://wikibooks.org/zh/ 。这样能够明显的看出站点之间的独立性。

多语言站点之间通过跨语言链接映射对应页面。这通常要由人工完成,也可以由机器人辅助添加。

优点:

  • 各语言站点之间保持相对独立,拥有更大的自由,独立进行维护改进,建立特有的方针指引
  • 用户浏览方便,单一站点能够在各方面进行本地化,如模板、界面、操作方式
  • 内容之间不具有强制的对应关系,适合发展本地化内容

缺点:

  • 占用更多资源,如数据库、存储空间、服务器负担
  • 维护难度大,需要管理更多站点,问题更多,需要更多人手参与工作
  • 内容发展不均衡,各语言之间难以同步发展

适用于那些用户量巨大,且各种语言都有,内容差异性大,且更新迅速的维基网站。如维基百科、openSUSE。

多语言子页面

在唯一的维基站点上,建立以英语,或者本地语言为主的内容页面。然后为每个页面建立多语言子页面,如 http://wiki.zju.edu.cn/浙江大学/en/ 。

优点:

  • 占用资源少,结构紧凑
  • 易于管理,工作量小
  • 内容易于同步,避免分化问题

缺点:

  • 浏览不方便,默认肯定要以英语(或某种语言)为主,为非英语用户阅读带来困难
  • 管理过于集中,如模板、社区规则、功能等,不易于根据本地化特征进行灵活控制
  • 造成一种语言独大的局面,其他语言受主要语言的把持

适用于那些用户较少,内容比较固定,以某一种语言(如英语)为主要源头的小型维基网站。如Blender Wiki。

多语言共存

即在一个站点上同时存在各种语言的页面,它们之间通过名称的差异区别,都是主页面。

如:Wikibooks,维基教科书;IBM,IBM (中文)。

优点:

  • 简单有效
  • 利于融合

缺点:

  • 不利于本地化
  • 结构杂乱
  • 主流语言主导

适用于那些以单一语言为主,但少量页面供多语言浏览的维基网站。如维基解密。