问题 TikiWiki 才是我们需要的 Wiki 程序

TikiWiki 开发者并不认为这只是一个 Wiki 程序，他们称之为“CMS”，因为 TikiWiki 不仅有文章系统，还自带论坛、图库、下载、bug tracker、博客（多用户）、Newsletter（电子期刊）、地图（Google Maps）等等一系列功能。

不过，在我看来，除了它的 Wiki 功能，其它的都不重要，也做的不怎么好 —— “大而全”这种理念不太好，如果他们不改变设计思路，最终会被自己无限扩张、而又难以实现的意图所摧毁。

我最欣赏 TikiWiki 的是它的页面翻译功能：在同一个页面上，就有“语言选择”的下拉选单。普通访客可以选择自己喜欢的语言版本来阅读该页面（假如该页面有多语言版本的话），而编辑人员在登录后，就可以在语言选单的末尾看到多出来一个“翻译”选项，选择它就可以立即开始翻译当前页面内容。完成后点击“保存”，即可新增一个语言版本。

如果原始页面内容有了变动，作者可以在保存时发出一个“翻译提醒”，所有翻译过该页面的其他编辑将收到通知，从而同步更新其他语言的版本。

我想这个功能对于建造多语种的知识库、文档库，甚至是某些译文管理，都非常方便。

我曾经希望在 MediaWiki 上面看到这个功能，但是很遗憾，费了好大劲都没有找到。或许是我太笨，但是如果有给我这样的笨蛋设计的、更便于使用的 TikiWiki，我还要 MediaWiki 做什么？

我希望有兴趣研究群组软件与 Joomla! 整合的朋友，不要在其它 wiki 上面浪费时间了，不妨看看如何实现 TikiWiki 与 Joomla! 1.5 的整合吧。

期待有这么一个桥接器出现。

TikiWiki 的页面翻译功能需要在“管理设置”中开启，然后在前台登录后就能在页面上看到界面语言的下拉选单，在该选单底部就是“翻译”命令。

DokuWiki 也不错，这也是很受欢迎的一款 Wiki 程序。唯一遗憾是它使用文本文件来储存数据，而不是储存在 MySQL 数据库。而且感觉它的语言选择方式（图标）不如 TikiWiki 的下拉选单式漂亮。

有一群程序员对于 Tikiwiki 的庞大身躯很不满意，于是乎大刀阔斧将 Tikiwiki 的代码加以改造，从而诞生一个新的开源软件：BitWeaver。

前面提到，Tikiwiki 的功能非常丰富，除了 wiki 还有论坛、图库、文章等等。用户在安装完成之后，可以进入管理后台选择启用哪些功能。

但是 BitWeaver 的开发者认为，这样还是太臃肿，用户既然不需要那些功能，为何还要将代码保留？BitWeaver 改进为：在安装过程中，用户选择需要的功能，不勾选的功能，其代码根本不会安装到网站去。

这个看起来不错吧？我就是被这一点打动了。我甚至怀疑 BitWeaver 真的要超越 Tikiwiki 了。

但是昨天通过初步测试，就简单的“wiki 页面翻译”功能来说，BitWeaver 的程序员让我太失望了！

在 Tikiwiki 中，如果启用了“多语种内容”功能，就会在每一个 wiki 页面上显示“翻译”链接，点击后可以打开编辑窗口，而原版内容已经自动复制到了这个编辑窗口中，你可以一边翻译，一边对照，一边删除。当一个页面拥有超过一个语种的版本后，页面上会自动显示一个下拉选单，里面标出了现有的各个语种。如果当前读者拥有编辑页面的权限，他就会在语种列表最底部看到一个“翻译”命令，点击该命令就可以增加新的语种翻译。

我们来看看 BitWeaver 是怎么做的：毕竟是从 Tiki 衍生出来的，因此 BitWeaver 也具备“允许翻译内容”的功能。如果启用，则页面也能被翻译为多语种版本。但是！我在 BitWeaver 的页面上找不到“翻译”或者“Translate”这样的按钮！在哪里呢？你必须点击“编辑”按钮，然后在编辑窗口底部，会看到一个小按钮叫“翻译”，点击此处的“翻译”按钮之后，页面会切换到翻译功能，也有一个文本输入框，但是里面空空的，根本没有原文附在里面。也就是说，你要么提前复制一份原文放在记事本里参考，要么请您根据记忆来翻译原文。在增加了译文之后，页面顶部出现并列的国旗图片，大约 12px 大小（不到半个指甲盖），每个国旗代表一种现有的译文语种。

我想明眼人一看就知道孰优孰劣！

且不论如果有40个语种译文，国旗都挤不下；且不论把“翻译”功能降格为“编辑”功能的子功能；单单是翻译时没有原文参考，就足以让人晕倒！

我真的不知道该赞美 Bitweaver 的革新精神，还是该批评他们的愚蠢设计？

因此，我还是继续选用 Tikiwiki。我想您也会同意吧？

大家都知道 wiki 的联编功能非常强大，由于其强大的版本控制功能，因此成为很多“用户生成内容”（UGC）网站或栏目的首选程序。但是 wiki 的特殊标记语法也让人望而却步。它既不是标准的 HTML 标记代码，也不是论坛常见的 BBcode 标记代码，而是全新的一套 wiki 标记代码。

更可怕的是，很多 wiki 还有自创的标记语法！MediaWiki 的标记语法在 Tikiwiki 里面就不能识别（除非安装一个插件），DocuWiki 的语法在 MediaWiki 里面也行不通！这简直让人又回到了秦始皇统一六国之前的状态：车不同轨，书不同文！

Tikiwiki 的开发人员或许也是看到这个情况不利于普通网民参与 wiki 编辑，因此他们在 Tiki 中开始引入“所见即所得”编辑器的功能。他们选择的编辑器核心是大家熟知的 FCKeditor（Joomla! 平台的 JoomlaFCK 就是用这个核心）。这个做法非常好！第一，大多数网民不用学习就能迅速学会使用 WYSIWYG 编辑器；第二，使用成熟的 FCKeditor 作为核心，避免了开发另一个“所见即所得”编辑器的麻烦，也使得编辑器的质量有保障。

在本站的 wiki 栏目中，我一直在使用“所见即所得”编辑器来编辑页面，没有发现有什么不方便之处。

如果有兴趣，可以看看 编辑 Tikiwiki 页面时如何插入图片 这篇 wiki 文章，该文章就是用 FCKeditor 编辑的，里面的插图有该编辑器的外观。

通过 Tikiwiki 后台自带的“自定义页头”功能，我们可以将 Joomla! 模板顶部的 Logo 图片及水平导航菜单都添加到 Tikiwiki 模板顶部，从而实现全站外观统一。虽然用户同步没有解决，但是外观整合也算一个小进步吧。

参看本站教程： 《通过自定义页头 + CSS 实现 Joomla! 与 Tikiwiki 的外观整合》

前几天本站会员 adfansor 说 在本站的 wiki 栏目中登录后没有找到翻译按钮 ，这个问题我也发现了。让我感到迷惑的是，并非每个页面都找不到翻译按钮，而是在个别页面上找不到翻译按钮。

经过一番摸索，今天终于找到了原因：当一个页面还未被指定语种，也没有被翻译时，如果锁定这个页面，就会隐藏“翻译”按钮。

原来我当时的做法是：当我输入一篇英文原版文章之后，我只希望其他汉化作者创建中文或其它语种的翻译页面，不希望他们编辑（改动）英文原版页面，于是我就在保存英文原版页面之后立即锁定了英文页面，却没有注意到一旦点击“锁定”按钮，“翻译”按钮就立即消失了！

今天经过仔细观察才看到这个细微的变化。

正确的做法是：

首先创建英文原版页面并保存，然后点击“翻译”按钮，创建一个语种的翻译（例如简体中文），但是并不需要完成这个译文，直接点击“部分翻译”按钮结束翻译过程。这时就会有两个版本：一个英文原版，一个未完成的简体中文译文。然后返回英文原版页面，点击“锁定”按钮，这时候页面顶部的“翻译”按钮还会消失，不过，在页面左侧的“工具箱”上，选择语言的下拉选单仍然在显示，点击该下拉选单，里面会显示 English 和 简体中文 两个语言，同时选单的底部有“翻译”链接，点击后还能创建其它语种的译文。

其他汉化作者访问该页面时，无法编辑英文原版（因为被锁定了），但是可以在“工具箱”这里选择“简体中文”版本，然后编辑（相当于完成翻译）；或者在“工具箱”这里点击“翻译”链接，创建其它语种译文（例如繁体中文）。

我想这是 Tikiwiki 设计上的一个缺陷。我认为应该这样设计：

如果系统探测到管理员已经启用了“多语种页面”功能，那么，当某个用户创建新页面时，就在编辑器窗口下方的选项中增加一项“选择此页面的语种”，强制要求页面创建者为该页面选择语言种类。

同时，当页面保存之后，即使管理员（或者其他有此权限的用户）锁定了该页面，也不要隐藏“翻译”选项，因为“锁定”只是对该页面的锁定，目的在于阻止他人改动此页面，而不是阻止他人翻译该页面。

补充：我将上面帖子中提到的“锁定页面后翻译按钮消失”的问题在 Tikiwiki 官方论坛作了汇报，我认为是一个设计缺陷，并提出了我的建议。

今天得到反馈，官方论坛的资深会员 chibaguy 也同意我的看法 ，他已经向 Tikiwiki 核心开发团队提交了 bug report，据他预测，可能会在09年3月份的新版本中得到修正。

rally 上次在本站 wiki 中测试时遇到的“点击保存按钮出错”的问题我也碰到了，不过，尽管显示了错误提示，但该页面还是保存了。我重新回到该页面 URL 就能看到已经保存的内容。

这个问题不仅仅是出现在中文标题的页面上，我发现即使页面标题是纯英文，也会出现。因此这可能是一个 bug，我还没有来得及跟官方反馈。

Mediawiki 固然强大，但是它好像还没有 WYSIWYG 编辑器？我对 wiki 语法一点都不喜欢，何必制造那么多规则呢？用“所见即所得”一样能编辑页面啊。

另外，我喜欢 Tikiwiki 的主要原因是它的翻译功能，这一点 Mediawiki 似乎赶不上。尽管 Tiki 也同时具有很多 CMS 功能，但我不认为有“重复”的担忧，因为在 Tikiwiki 后台可以禁用其它功能，只保留 Wiki 部分。

尤其是当我发现能够 通过自定义页头 + CSS 实现 Joomla! 与 Tikiwiki 的外观整合 后，我更坚定了信心使用 Tikiwiki。Mediawiki 或许更强大，但是对我这样不懂编程的菜鸟来说，想要让它与 Joomla! 外观也这么容易整合几乎不可能。

同时，我认为无论采用哪个 Wiki 程序，都不宜开发桥接器组件，而只需要一个针对 Joomla! 1.5 的“身份验证”插件即可。也就是说，撇开用户同步登录功能不谈，那么让我选择 Wiki 的标准就是：哪个更容易与 Joomla! 外观整合就选哪个，因为针对哪个 wiki 开发“认证插件”难度都是一样的。

据我所知，目前已经有针对 DocuWiki 的“认证插件”了，如果 DocuWiki 也能方便地实现外观整合，那么就等于完全与 Joomla! 1.5 融合了。不过，DocuWiki 没有页面多语种版本功能，我目前还不考虑用它。

本站 wiki 栏目是用 Tikiwiki 搭建的，安装之后做了一些设置（具体记不清了）。随后几天，发现在编辑页面之后，点击“保存”按钮就出错。

例如，我们新建了一个页面名称是 Module_positions，输入内容之后，点击“保存”按钮就看到一个空白页面，上面只显示了如下的错误消息：

Not Found

The requested URL /wiki/Module_positions&saved_msg=y was not found on this server.

上次 rally 认为可能是对中文 URL 支持不够好，实际上不是，上面这个例子是我今天下午刚刚遇到的，可以看到，我用的页面标题是纯英文，而且没有空格等特殊符号，为什么还是出错？（实际上页面都已经保存了，只是无法返回那个页面去）

经过一番搜索，终于找到了原因：

在安装 Tikiwiki 之后，我当时设置功能时启用了 SEF 友好网址功能，我认为这样就可以享用 SEF 了。

但是，在那之后我一直没有看到 SEF 网址生效，也没有其它问题。后来就发生了保存页面时“Not Found”的问题，但是我没有想到可能与这个 SEF 设置有关。

在官方网站找到了答案，就是与 SEF 功能有关系。Tikiwiki 自带的 .htaccess 规则默认是在根目录下保存为 _htaccess 这个文件。如果在 Tikiwiki “设置”中启用了 SEF，就必须将将根目录下的 _htaccess 文件改名为 .htaccess。

本站的 Tikiwiki 在我启用 SEF 功能之后，当时忘记了给 _htaccess 文件改名了。

解决办法：

启用 SEF 功能之后，将 Tikiwiki 根目录下的 _htaccess 文件改名为 .htaccess 即可。

不过，Tikiwiki 的所谓 SEF 与我们已有的概念不同。Tikiwiki 的 SEF 只是“接受 SEF 形式的 URL 访问请求”，而不是“输出 SEF 形式 URL”。

举例说明：

目前已知本站 wiki 中有一个页面名称是 Module_positions，我们希望在访问该页面时，浏览器的地址栏里面显示出：

但实际上 Tikiwiki 目前做不到，它还是显示：

不过，如果你直接在浏览器中输入 http://www.joomlagate.com/wiki/Module_positions 这个地址并访问，还是能看到相同的页面。

也就是说，Tikiwiki 能够接受并解析用户输入的 SEF 网址，但是它的内部仍然继续使用 non-SEF 网址。

今晚有幸在 IRC 上面与 Tikiwiki 的开发人员聊了几句，他们说，目前 Tikiwiki 开发小组并不认为 SEF 是一个很重要的功能，他们还有很多方面期待改进，SEF 的重要性排在后面。估计在 4.0 或 5.0 版本中才会考虑全面实施 SEF，因为这需要大量的代码修改。

CLWE 是 Cross Lingual Wiki Engine Project 的缩写，意思是：跨语种联编引擎，或者叫“多语种联编引擎”更明白一些。

Tikiwiki 中所用的“多语种 wiki 页面翻译”功能，就是由 CLWE 驱动的。有意思的是，CLWE 的网站竟然也是采用 Tikiwiki 搭建的！我几乎怀疑这两帮人是一个团队了，然而不是。

CLWE 是面向所有 wiki 程序的，只不过现在 Tikiwiki 将它运用的最好。

本站选择 Tikiwiki 作为在线联合翻译平台，看来是选对了！  ;D

如果哪位还想创建类似的联合翻译平台，我强烈推荐你选用 Tikiwiki。因为 CLWE 还在不断发展中，这就表示 Tikiwiki 的这种“多语言版本页面”功能有着令人放心的前途。

最近在本站 wiki 管理后台创建新帐号时发现，Tikiwiki 竟然不支持中文用户名！

可是本站的注册系统（SMF）是支持中文用户名的，而且已经拥有了大批注册了中文 ID 的会员。如果说这些人想要参与 wiki 栏目的汉化，为了保持 ID 统一，我就只能在论坛给他们修改 ID 为英文版。且不说这样手工修改费时费力，从用户角度来讲也不情愿：毕竟那个中文用户名也是人家喜欢的 ID，为什么要修改呢？

我也觉得责任应该在 Tikiwiki，在这个全球化的时代，竟然不支持英文之外语言的用户名，岂不是太狭隘了？

不过，我终于在 Tikiwiki 的官方论坛发现了一名中国用户 outcrop 提供的解决方案，测试之后完全有效。因此分享如下：

打开 /tiki-setup_base.php 文件，在大约第 167 行，找到如下代码：
修改为：

即可支持中文用户名。

原帖地址： Non-english characters in usernames

再次感谢 outcrop 的分享！

最近，Tikiwiki 官方发布了 2.3 稳定版和 3.0 beta1 测试版。

下载地址：

点击此处下载 Tikiwiki 2.3 中文版

点击此处下载 Tikiwiki 3.0 beta1 测试版

官方宣布，大概在 2009年4月会发布 3.0 正式版。Tikiwiki 3.0 有很多不错的改进，详细介绍参看： Tikiwiki 3.0 ChangeLog

xzcxzc 说的没错，http://www.wikimatrix.org/ 网站是汇总、比较各种 wiki 程序的一个权威网站。想要研究 wiki 程序的人应该去看看。

我在选择“能够实现多语种页面互相翻译”的 wiki 时，曾经简单测试了一下 Dokuwiki，结果发现它的语种按钮不合我意；后来看到 Tikiwiki 有专门的 [url=forum/topic-13827/#18022]Cross Lingual Wiki Engine Project 引擎[/url]，我就认定 Tikiwiki 这个多语种功能不错，于是就选用了。

至于 Dokuwiki 的多语种功能是否也很强大，我没有深入测试。如果你有兴趣，欢迎作出详细比较并与大家分享。谢谢！

刚才我在最新的 Tikiwiki 2.4 stable 上面测试了 rally 提到的这个问题，我尝试了中文 wiki 内部链接，不管我在哪个括号后面加空格都不能成功，最终结果并不是一个链接，而是按照文本输出。不知道是我哪里设置不对？我用的是 wiki editor 编辑器。

我同时又测试了一下英文内容的内部链接，完全正常。因此可以断定对中文的处理还是有问题。

回头我再测试一下 3.0 RC1 是否有这个问题。