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

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

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

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

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

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

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

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

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

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

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

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

原理

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 (中文)。

优点：

• 简单有效
• 利于融合

缺点：

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

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