使用筆記/起步篇
在安裝完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起步並沒有那麼難,只要你做得足夠好,足夠努力。
但是呢,還有一些東西可能不對勁⸺比如你的站台不夠好看,手機端看起來有點不太對勁,或者有的功能想實現但是好像比較困難。以下三篇會介紹一些東西,可能對你有所幫助。
接下來
主要頁面 | |
---|---|
正文 | |
外部連結 |