使用笔记/起步篇
在安装完MediaWiki后,事情并没有结束。如果你是一个熟练的wiki编者,你马上就会想把自己所熟悉的模板啊模块啊都搞过来。没错,MediaWiki并不附带这些东西,都需要用户自己写(我的意思是,至少你所搬运的内容也得有人从零开始写)。
那么,该怎么做呢?
继续相关设置
啊,不是说要搬东西了吗?
不是,在这之前其实还有很多东西要做。比如,你想搬运的东西,很可能其实需要MediaWiki自带功能以外的很多东西呢⸺比如动态页面列表(不过如果是真要用我举的这个例子,还是建议三思)。
以下是一些常见的模板依赖项。
Scribunto
实现模块的扩展程序是Scribunto。根据官网,虽然他是个自带扩展程序,但是很可能其实并不能工作。
一些点包括Lua解释器没有可执行权限,PHP禁用函数导致MediaWiki无法新建进程以运算模块代码,以及防跨站设置open_basedir
导致模块无法正常执行等。
Linux上文件的可执行权限相关问题可以查阅网络上关于chmod的相关教程,讲的比我详细。
PHP禁用函数和防跨站通常是面板导致的问题。面板安装PHP时,会“很贴心的考虑到安全问题”,把一些确实很危险的函数禁用掉,也会设置一些防跨站,但是这么做会导致模块这个需要额外可执行程序的功能无法正常使用。因此,你需要查阅PHP与面板的相关文档,让错误日志显示出来,并关闭防跨站与启用部分禁用函数。
模板样式与模板数据
模板样式是一个允许绕过系统消息而应用样式的扩展程序。部分wiki会把模板的样式拆分到这里面来,如果不想把这部分样式混到站点全局里面则需要。
模板数据是一个提供对模板使用的额外标记的扩展程序。这些数据对可视化编辑器的完整运作至关重要,其本身也可以在模板文档内通过机器生成出一个十分简明的参数表格。如果有模板的文档使用了它,则推荐安装。
LanguageConverter
如果你要搬运的站点的站点语言是“中文 (zh)”,那么这个站点就是开启了中文字词转换的。开启字词转换的站点会额外支持字词转换语法,而这些语法在未开启字词转换的站点上直接按原样显示。
如果你的站点没有多变体需求,那么在搬运后需要手动去除字词转换相关的部分。如果其实有,那么把站点语言改成“中文 (zh)”就行。
字词转换的语法见本段落的主页面。
开始搬运
第一个模板:文档模板
你要搬运的第一个模板,不是信息框,不是消息框,不是大家族模板,不是别的,就是{{Documentation}}
,文档模板。
文档模板是什么
文档模板是用于给模板/模块(当然包括它自己)提供文档的模板。有了这个模板,你就可以在不影响模板内容本身的情况下为模板提供一些使用方法等的说明。
文档模板对分类树的影响
文档模板也会影响到另一个要素:分类树。
一个wiki站点何以变得有序?分类树就是一个很重要的方式。
简单来说,分类可以把很多有相同的点的东西放在一起,比如我把所有关于格式的模板放在一个分类里面,这样我如果想对所有关乎格式的模板进行快速浏览或者修改,只需要对着这个分类自动生成的列表就好了。
但是如果分类们都是各分各的,有的时候还是很麻烦。比如,我想同时看到格式模板和通知模板以及更多种类的模板,就还得自己找找看有什么模板分类。
分类树,则是把这些原本孤立的分类也分个类,比如各种各样的模板的分类都归属在模板这个分类里面,这样就可以通过一个分类找到更多小分类。像这样把一个个点(单个分类)串成一个树/网(对分类进行分类),最终通过一个总分类就可以到达所有分类,这就是制作一个分类树的过程和结果。
文档模板为什么会影响分类树呢?这和每个文档模板的运作方式有关。我站的文档模板来自中文Minecraft Wiki,这个文档模板在加载文档时可以做到“把所有分类写在模板文档里的同时正确地让模板处于模板的分类,模板文档处于模板文档的分类”,而其他的文档模板则可能需要把模板的分类写在模板代码里面,包上一层<noinclude>
,没法做到把所有东西写在一处。因此,文档模板会影响一个wiki站点的模板/模块的文档格式,而如果你搬运的来源比较多,那么文档格式的统一就会变成一个比较难做的事情。
额外的注意事项
就和上面说的一样,因为文档模板不一定只用于模板,所以对于模块的文档,有的文档模板要求更改Scribunto自带的系统消息才能正确显示模块文档。
正式搬运与可能出现的情况
对于数量不大的页面来说,你大可以点开每个页面的“编辑源代码”然后把内容复制到你的站点的同名页面里面。但是,我们有个特殊页面叫Special:Export,这么做其实更方便。使用特殊页面导出的XML文件需要在Special:Import里面上传,这样就可以把你选定内容传送到你的站点上。
如果有什么东西不对劲,那么肯定是漏了什么东西。
比如所有文字都在但是样式全丢了?如果那个站点没有TemplateStyles,那么看看MediaWiki:Common.css、MediaWiki:Mobile.css和Special:小工具,里面可能会有你需要的样式。如果CSS写的足够贴心,注释里面甚至会注明每一段对应哪一个模板。
比如出现红链了?有时可能说明你没有搬完(比如红链以“Template:”开头),把这些红链对应的内容也搬过来。如果是文档示例里面某个指向条目内容的,则可以考虑换个链接。如果是分类是红链,就创建这个分类。比如你搬运了文档模板,带来了一个分类文档模板,那么创建这个分类,且内容填写为这个分类对应的上一级分类,比如写入[[Category:模板]]
。如果模板这个分类也没创建,那么把模板这个分类也创建了,写入上一级分类。我站在这里就把模板这个分类归到了上述所说的“总分类”,索引。当然,这么做就是在建立分类树了。
比如出现Lua错误了?除了模块没搬完以外,也有可能你并没有配置好Lua。看看官网,或者搜一搜类似的情况可能会有帮助。
如果有的模板的显示正常,但是功能不运作,可能是JS没有搬运过来。小工具和上述所说对应的Common.js与Mobile.js都看看,如果注释写得好的话也会附带上“这个部分对应哪个模板所需的JS”。
总之,最终,第一个模板被你搬运来了⸺这样,其他的模板就照做即可了。
还有什么模板要搬运
一个wiki站点,最基础的几个模板,包括消息框(Msgbox/Mbox)、信息框(Infobox)、导航框/大家族模板(Navbox)、顶注(Hatnote)与底注(Footnote)、标签模板(Tag)等。这些模板的实现方式各有不同,名称也不大一样。
信息框
信息框(Infobox)是一类用于展示图片与信息点的表格状模板。比如,介绍某个城市的条目,通常在右侧会有一个框,里面会展示这个城市的某一张图片,它在其省中的位置,它的纬度和经度,它的人口数量,它的区域面积,等等。
这种模板可以让读者迅速知道这个条目的基础信息,可以提升阅读体验,也有利于条目格式。
在Fandom上,大部分信息框使用了扩展程序PortableInfobox,其模板内容会包含很多的XML标签。这种信息框必须使用这个扩展程序才能正确运作。
你可以参考萌娘百科、维基百科,甚至我站的{{Infobox}}
。如果有能力的话,自己写一个Infobox也是不错的。
消息框
在维基百科页面上,有的时候顶部会有一个左边有颜色条的框,提示“这个条目有什么问题”“关于这个页面的提示”等等。这就是消息框(Message box)。这种很醒目的消息框的用途就是标识文章的问题或一些提示。
比如{{cleanup}}
。在顶部悬挂一个,就很显眼,提醒这个页面需要整理。
其他消息框的用法也包括“什么都用消息框”,把很多模板都做成消息框。这种行为多见于萌娘百科。个人认为这种用法会导致消息框醒目的特点消失,起不到原本的作用。比如,在维基百科上使用顶注样式的部分消歧义模板,在萌娘百科就成了页顶的消息框。
其他一些比较模糊的界限包括{{stub}}
。在维基百科上,这用于标注小作品,由于小作品都比较短,所以做成了底注,也比较小,醒目程度略有下降,但是电脑版还是能在第一屏看见。在中文Minecraft Wiki上,则做成了消息框,语义也有所不同,意思是“页面不完整”。
原则上来说,消息框只应当用作标注文章(可能)存在的问题。但是由于醒目程度,部分wiki也会打破这个规则。如果你希望保持模板功用的纯洁性,那么也可以考虑自己编写另一种同样醒目但用途不同的元模板。
顶注与底注
顶注(Hatnote)是放在页面最上方,有一点缩进的标注,一般用于内容页面内的消歧义。
底注(Footnote)放在页面最底部,在维基百科上用于一些不那么需要醒目的标识。
导航模板
导航模板(Navbox)是一种集合了某个共同话题下所有页面链接的大表格型模板,也称大家族模板。
它也放在页面底部,通常由于特别长还会折叠起来。展开后便是分门别类排列好的很多相关条目和页面的链接,所以说“导航”。
Minecraft Wiki使用了叫做{{SimpleNavbox}}
的模板。这个模板配合所需的CSS,可以做到使用Wikitext表格语法就能做出一个Navbox。维基百科和萌娘百科的大家族模板则更为复杂,有了一些“子组”等这类更细化的导航层级。SimpleNavbox不需要模块,而其他的由于过于复杂是可能需要模块才能运作的。
SimpleNavbox配合{{LoadBox}}
实现了真正的“折叠”⸺不展开时甚至不会加载实际的导航模板,减少了一开始的加载时间。
标签模板
标签模板(Tag)是一类在行内标注某个句子或词语的模板。最经典的例子莫过于{{cn}}
,来源请求。
在维基百科上,有的标签模板是框住具体的文字的。这样可以更好的标识“哪些部分是标签模板所想标识的”。
参考来源模板
这一部分与wiki的性质有关。
一般来说,由于<references>
很长,所以会事先包装起来待用,比如{{Reflist}}
。而具体的参考来源有可能会有命名上的格式需求,因此可以按照自己wiki所需的格式自己写一个很简单的类似于定型文一样的文字模板。维基百科使用比较复杂的引用格式模板,参考{{wzh:Template:Cite web}}
等。
讨论页模板
讨论页是你站点上用户沟通的一种方式。为讨论页设计的模板也是有必要搬运的。
意见模板
维基百科等wiki使用的是许多个独立的意见模板,比如{{wzh:Template:投票模板}}
里面列出的。
Minecraft Wiki由于使用了Sprite,因此把意见模板的图标也是用了Sprite去实现,且把所有意见模板全部整合到了同一个模板{{Comment}}
里面。如果你不需要这么复杂的意见模板,直接搬运维基百科的一部分意见模板即可。
留言标识模板
在删除不合适的留言时,为了保证留言记录的连续性,应当用点模板去表明这玩意被移除过,比如来自维基百科的“不合适的评论”模板。
留言需要签名,如果有人没有签名或者签名出错了,应当用点模板去提醒他签名,比如“未签名”模板。
如果一个话题已经结束了,应当用点模板表明这个讨论已经结束了不应该再做多修改,比如{{Close topic}}
。
定型文模板
如果一个用户做出了不合适的行为,又不想每一次都写一遍警告,那么可以提前准备一些警告的定型文,比如中文Minecraft Wiki的“用户警告”模板。
正式开始
工欲善其事,必先利其器。现在你已经把基础的模板搬运过来了,就可以开始写页面了。
此处我假定你的站点有一个具体的主题,并且你已经为你的站点准备好了足够多的美术素材。
Logo与Favicon
在开始写页面之前,你的网站在装好的时候应该会在界面的某个位置展示一张图片,提醒你去设置$wgLogos
。这个图片的位置就是你Logo会显示的位置。
一般地,$wgLogos
所设置的1x
的MediaWiki的Logo文件大小应当是135px*135px。准备好Logo文件之后,我个人建议把Logo通过MediaWiki自带的文件上传放到你的站点上。上传后,点击查看原图,这样就能知道这个Logo传上去之后实际文件在哪里。比如,我站的Logo,Wiki.png就在/images/b/bc/Wiki.png
。这么做的好处是Logo文件会和站点的其他文件一样拥有MediaWiki的历史记录,并且不需要登录到后台就可以更改。
但是135*135还是太小了,用一些设备去看会很糊的。这个时候也可以设置$wgLogos
的更多参数,为每个缩放定义一个Logo文件。
同样地,以上建议适用于$wgFavicon
(但是默认来说文件上传不允许ico格式因此需要自行打开)、$wgAppleTouchIcon
。
首页
首页是你站点的门面,当然要装饰的好一点啦。
也许你会HTML和CSS,以前也做过简单的网页,也许你甚至很会排版,很会做网页,甚至当场撸了一个首页出来,但是总有那么些人就是不会写网页.jpg
如果你是不会写网页的人,那么请查阅MediaWiki.org官网的首页。没错,这也是可以抄的。虽然要抄过来的CSS比较多就是了。实在不行写表格也行。
一个首页最起码需要包括一个网站的基础描述,以及通往各个主要页面和方针等的链接。为了使首页看上去更有生气,我们通常也会使用一些魔术字去展示自己网站的数据,比如有多少个条目,多少名活跃用户,这些。如果你使用了一些皮肤,可能他们的侧栏会有类似于最近更改的东西,但是如果没有的话,首页上也不妨放一个“最近创建的页面”。如果需要的话,也可以在首页放上一个新闻动态。
首页做出来之后,一定要用手机再看一遍(如果你装了MobileFrontend或者使用了类似于Timeless这类原生支持响应式的皮肤),确保首页在大部分屏幕尺寸上的显示都是正常的。当然,任何一个页面都应当检查一遍手机上的效果。
如果你想抄Fandom站点的首页的话,由于Fandom自带一些扩展所以有的东西不是很好抄。
内容页面
通常来说一个内容页面会有很多东西,总之源代码层面的排布是这样的:
- Hatnote
- Msgbox
- Infobox
- 简介
- 正文(内容段落)
- 标题从二级标题开始,向下继续分段使用直至第四级标题,第五级标题考虑使用伪标题语法(其实是定义列表语法)
; Pseudo title
去处理- 每个标题的等号与实际标题内容之间加上空格,比如
== Title ==
- 每个标题的等号与实际标题内容之间加上空格,比如
- 每形成一个段落需要换两次行
- 每个段落也按照Hatnote、Msgbox、Infobox的顺序(如果有)
- 尽量做到见源代码知实际效果,也就是保持源代码整洁明了
- 标题从二级标题开始,向下继续分段使用直至第四级标题,第五级标题考虑使用伪标题语法(其实是定义列表语法)
- 参见/另见
- 参考文献
- Footnote
- Navbox
- Category
- Interwiki
这种布局依据wiki实际会有所变化。比如ArchWiki是把Interwiki和Category丢在页面源代码顶部的。
通常来说,虽然源代码里面只写了这些东西,但是MediaWiki还会贴心地帮你生成一个目录(Table of contents)。这通常是好的,但是有的时候目录会特别长。这个时候就需要通过对__TOC__
的一些处理去让目录处于文章中一个更合理的位置。{{TOC}}
就是这样的一个模板,可以试一试。
项目页面
项目页面不是说你要写个计划的页面,而是指有关wiki本身的页面。这些页面都在Project
命名空间下。
通常来说,一个wiki需要一个方针,比如我站就是Wiki条例。方针是一个wiki运作的纲领性文件。根据所使用皮肤的不同,皮肤的Footer可能还会预先提供一些你需要填写的项目页面。编辑框的提示信息里面也会有一个项目页面,Project:版权或Project:著作权需要你去填写。
一个wiki通常也需要一个供全体用户讨论同一个重大议题的页面,通常也会在项目空间下。比如我站就是管理员告示板和社区主页。在维基百科这种页面叫互助客栈(Village pump)。
系统消息
你可以帮助我们扩充关于该主题的更多信息。
原因:移动端相关的特殊CSS和JS等的targets
系统已经于1.42删除,不再有任何作用
系统消息是MediaWiki系统所需的界面文本、CSS和JS,位于MediaWiki
命名空间下。在页面网址的URL参数中添加uselang=qqx
(通常在添加时会有?
或&
,这里的格式请自行搜索到底是怎么回事)可以看见页面上的文本都由哪一条系统消息去处理(有的可能不准确,比如nstab-
开头的)。
除了界面上的一般文本,一些系统消息也控制部分表单的下拉栏选项,比如MediaWiki:Licenses、MediaWiki:Filedelete-reason-dropdown、MediaWiki:Revdelete-reason-dropdown、MediaWiki:Revdelete-reason-dropdown-suppress、MediaWiki:Deletereason-dropdown、MediaWiki:Protect-dropdown、MediaWiki:Ipbreason-dropdown等。
也有一些系统消息会改变生成的页面的结构,比如MediaWiki:Sidebar(改变侧边栏)、MediaWiki:Sitenotice(在页面最顶端展示通知)、MediaWiki:Pagetitle(改变生成的HTML文档的页面标题格式)。
也有一些系统消息控制扩展程序的功能,比如MediaWiki:Gadgets-definition等。
控制CSS和JS的系统消息包括MediaWiki:Common.css、MediaWiki:Common.js、MediaWiki:Mobile.css、MediaWiki:Mobile.js、MediaWiki:Gadgets-definition、MediaWiki:Gadget-*.js、MediaWiki:Gadget-*.css、MediaWiki:Gadget-*等。Common控制桌面设备,Mobile控制移动设备,而Gadgets则是根据每个Gadget的ResourceLoader设置。
帮助页面
除了根据自身主题写出适合自己站点的帮助页面以外,也可以从MediaWiki官网或者其他wiki站点上抄。
语气视情况可以放轻松。
分类页面
之前已经提到过分类树了。
在你搬运模板形成分类树的时候,实际上就在写分类页面了。
如果你比较懒,一下子写不完分类树,那么每个分类页面只留上级分类不写分类简介也可以,只要你的分类名称足够清晰。
当然,更推荐写一些分类简介。比如,由某个模板自动生成的分类里面写明由哪个模板生成。
文件页面
每个文件在上传后需要有适合的文件描述模板(当然也可以没有,只是用上传页面自带的段落格式)和文件协议模板。每个文件的命名也是很重要的,应当具有一定的规范性。
如果你的站点开启了繁简转换,此时若图像文件包含大量的文字信息,那么应当提供两份,一份简体一份繁体。如果每个变体的差异还很大那么视情况增加,比如Minecraft的简体、台湾繁体、香港繁体有三个翻译,此时如果有一个包含盔甲名称的图表,就最好来三份。用的时候通过繁简转换标记去插入图片。
用户页和用户讨论页
由用户自己决定。在内容上依然要符合你站的方针。
用户页和用户讨论页不是必需的⸺如果你的wiki只有你一个人(好惨)的话不写也没关系。用户页主要是用来简短介绍自己,以及做一些自己的事情(比如测试一个尚不成熟的模板)。用户讨论页用于用户之间的交流,因此如果你的wiki只有你一个人(再次好惨)那么没有也没关系。
永无止境地写
一个关于时常更新的主题的wiki是永远不会被完成的。内容页面、分类、文件、帮助等,都有可能在你的wiki进一步发展之后需要再次被填充。
大纲上来说,就是这么多啦。wiki起步并没有那么难,只要你做得足够好,足够努力。
但是呢,还有一些东西可能不对劲⸺比如你的站点不够好看,手机端看起来有点不太对劲,或者有的功能想实现但是好像比较困难。以下三篇会介绍一些东西,可能对你有所帮助。
接下来
主要页面 | |
---|---|
正文 | |
外部链接 |