<本站文本内容除另有声明外,转载时均必须注明出处。(详情…本站文本内容除另有声明外,转载时均必须注明出处。(详情…中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!Minecraft中文Wiki微博正在更新!或许有兴趣去看看Minecraft中文Wiki微博正在更新!或许有兴趣去看看想与其他用户进行编辑上的沟通?社区专页正是为此创建的。想与其他用户进行编辑上的沟通?社区专页正是为此创建的。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。需要管理员的协助?在管理员告示板留言也许可以帮到您。需要管理员的协助?在管理员告示板留言也许可以帮到您。>

Minecraft Wiki:格式指導

出自Minecraft Wiki
跳到: 導覽搜尋

此條目旨在提供一份為所有Minecraft Wiki條目遵守的綜合的格式指導。 在選擇使用哪些格式規則上經常會有爭議,而一部官方的格式指導有希望幫助解決這些爭議,同時也能幫助大家達成共識。

雖然維基百科已經提供了一份更通用的格式指導,但專用於Minecraft的特殊指導方針是有必要的。同理,只有專用於Minecraft Wiki的指導方針和其基本的格式規則才會被收錄在這裏。

關注度

快捷方式
Project:關注度

只有符合以下準則的條目可以放在主名字空間。不符合準則的條目可能會在未通知的情況下被刪除。

常規
  1. 條目必須包含足夠的信息以支撐一個完整的條目。如果它們沒有足夠的內容,就會被合併到其他相應的條目。
  2. 條目必須在某種程度上直接涉及Minecraft。
  3. 關於人物的條目只允許此人物是Minecraft的開發者且/或有一部分或十分密切地與Mojang AB相關。
  4. 目前還不存在於遊戲中的特性只能放入對應版本的提及特性條目。
    1. 這不包括已被移除的特性或開發版本中的特性,它們應在受其影響的條目與相關版本的條目中提及。
  5. 關於Minecraft版本的條目,可以創建已發佈的版本的,其中每個開發版本都應該創建單獨的條目。
    1. 可以創建關於未發佈版本的條目,前提是有證明未發佈版本存在的顯著信息來源。這些來源包括開發版本或是多項關於下一個更新的特性。未發佈的開發版本的條目不可被創建。
    2. 原主機版的版本應放入原主機版版本記錄,未發佈的版本應加入到計劃版本
    3. Minecraft的啟動器各版本也應當創建單獨的條目。如果同一個版本在不同平台上有不同的版本號,將不同的的數字用「x」替換。
社區內容
  1. 遊戲控制相關的攻略,教程等應作為教程的子條目。
    1. 包含如何進行建築等雜項的條目不會被視為教程。它們應放入用戶空間。這包括用戶創作的活動與挑戰。
  2. 只允許加入Mojang AB表示已經玩過的小遊戲。
  3. Mod內容正在被導出至FTB Wiki,所有關於Mod的文章都應該在那裏創建。
  4. 關於定製伺服器的條目只允許此伺服器是對公眾開放的。
Wiki條例
4. 忠於事實 - 不要在編輯條目時對內容進行惡搞/諷刺/扯淡/二次創作/夾帶私貨以免誤導玩家。
5. 不允許創建為特定伺服器或其他產品做廣告的條目。
6. 禁止創建有關玩家論壇的條目,以免造成廣告內容相關的糾紛。
7. 請不要從其他Minecraft相關的網站直接複製信息到本Wiki。

在「User」名字空間的條目是關注度指導的例外。這些條目可以在遵守相關Wiki條例的條件下作任意用途。

重新導向

重新導向條目有特別的關注度原則,且其必須重新導向到一個符合關注度指導的條目。如果重新導向到另一個Wiki,必須使用軟重新導向{{soft redirect}}。重新導向條目在符合以下條件之一時可被創建:

  1. 屬於替代或縮寫的名稱,而此名稱被廣泛使用,例如「栓繩」之於「拴繩」。曾用於遊戲中的名稱也是允許的。
    1. 也包括其他中文語言中的名稱。
    2. 也包括Mojang員工的姓名或暱稱,例如「Dinnerbone」、「Nathan」之於「Nathan Adams」。
    3. 錯誤拼寫、筆誤、非正規的格式和粗俗內容是被不允許的。
  2. 屬於曾用的條目標題,包括被移動到其他Wiki的條目,例如「流髑」之於「流髑」。
    1. 如果曾用標題未廣泛使用則除外。
  3. 屬於合併或雜項條目的一部分,例如一種藥水、一種提及特性或同一啟動器版本在不同平台上的版本號。
  4. 升為其他版本的預發佈版的父版本,例如「1.7」之於「1.7.2」,因為「1.7-pre」是"1.7.2"的預發佈版本。

重新導向條目的目標不能是不存在的條目或另一個重新導向條目。

英文名稱和基岩版譯名不應被創建重新導向。

「User」名字空間下的條目可以重新導向到任意位置,但仍需遵守上述原則。

條目標題

條目應遵從基於其類型的常規命名格式。

  • 關於遊戲內方塊,物品和實體等特性的條目應使用Java版遊戲內譯名。目前,這些譯名由中文Minecraft Wiki管理團隊管理。完整的譯名列表可見此處
    • 基岩版的譯名質量差,不值得使用。
    • 如果某特性無遊戲內名稱,就應遵照其他同類型條目的相同形式,例如,生物雞騎士
    • 如果條目是關於遊戲內多項事物的,標題應同等地代表所有名稱。例如,關於木質與鐵質門的條目應命名為
    • 如果某特性尚無確定的中文譯名,則使用其英文名稱作為佔位,待中文名稱確定後將條目移動至相應的中文名稱處(不留重新導向)。
  • 關於人物的條目應該包含姓氏與名字,而不是他們的Minecraft或Twitter暱稱。
  • Java版應使用版本號命名,例如「1.8」或「14w02a」。
    • 目前英文Wiki在版本號前加入了「Java Edition」(Java版),中文Wiki不需要(限正式版)。請在搬運時去除。
    • 預發佈版的格式應為父版本與「pre」之間加一個單獨的(英文的)破折號。如果預發佈版的末尾有一個數字,那麼「pre」與數字間不應有任何東西。例如:「1.8-pre1」。
  • 攜帶版版本應加前綴「攜帶版」。例如,「Alpha 0.9.0」應被命名為「攜帶版Alpha 0.9.0」。
    • 攜帶版Alpha開發版本應先加上前綴「攜帶版」,然後加上小寫的「build」字樣。例如,「0.9.0」的「build 2」應被命名為「攜帶版Alpha 0.9.0 build 2」。
    • 攜帶版開發版本應先加上前綴「攜帶版」,然後加上小寫的「alpha」字樣。例如,「1.1.0.1」應被命名為「攜帶版alpha 1.1.0.1」。
  • 基岩版版本應加前綴「基岩版」。例如,「1.2.0」應該使用「基岩版1.2.0」這個標題。
    • 基岩版的預覽版本應先加上前綴「基岩版」,然後加上版本號數字。例如,「1.5.0」的第一個預覽版本應該使用「基岩版beta 1.5.0.0」這個標題。
  • 其他版本應加上相應的版本前綴。例如,教育版的「1.9.0」應該使用「教育版1.9.0」這個標題。
  • 消歧義條目在標題已被某條目使用時才應該包含「(消歧義)」。
  • 若是以英文命名的條目,且條目類型未在此列出,則應選用句子型大寫(第一個單詞首字母大寫)的最確切的標題,而不應用標題型大寫(各單詞首字母大寫),除非其為一個特定的名詞。

編寫

參見:Help:官方資源

由於本Wiki的目的是記錄事實,您應該始終避免推測的與無來源的信息。一般來說,如果可以直接地在遊戲或其他明顯的地方被看到,這些信息就不需要來源。然而其他的信息,比如來自Mojang員工的引言和並不廣為人知的信息,必須以適當的參考標明來源。{{citation needed}}模板應被放置在任何需要來源的信息之後。不要在條目中加入你無法找到來源的內容。

在主名字空間的條目應該保持第三人稱的口吻且不使用對讀者來說需要參考的術語,但教程頁面除外。也儘量嘗試不使用縮略語。舉例來說,「你不該靠近苦力怕,因為他們會爆炸然後把你殺掉。」應該寫成「玩家不應該與苦力怕靠的太近,因為它們會爆炸,並有殺死玩家的可能。」

強調重點時應該用粗體,而不能用斜體

教程信息,包括對方塊或材質的延伸特性,應只寫在教程條目。如果有重要關係,教程條目被主要條目連結。

Mod信息不應包含在與Mod無關的條目。Mod條目也不能從與Mod無關的條目連結。

保持條目的簡明與更新

快捷方式
Project:更新

簡單來說,條目應該只包含最新的信息,即在最新的「完整」遊戲版本所呈現的內容。任何的過期內容應該移動到條目的歷史段落。當有更改時,應在歷史段落中記錄並移除條目其他段落中的過期信息。提及某一特定的特性在何時實現並不必要;這個特性也應當保留於條目的歷史段落。例如這樣的句子:「交易,實現於1.3.1,是一種允許玩家通過交換綠寶石(此前是紅寶石)來獲取其他物品的特性。」應當寫成「交易是一種允許玩家通過交換綠寶石來獲取其他物品的特性。」

這裏有一個不好的條目編寫的示範,使用的是原木條目之前的版本。這段是完整的介紹內容。用黃色高亮的是多餘內容,而粉色的是歷史內容。

原木(Log)(舊稱木塊(Wood)),是一種首次出現於Minecraft創造模式0.0.14a的方塊。它們的四個側面有類似樹皮的外表,頂面和底面則是橫切面。在Beta 1.2與所有之前的版本中,只有普通橡木原木能在區塊中生成,而松樹與樺木將生成於更新一些的區塊中。作為樹的組成,原木在自然生成的地圖中非常豐富。原木可以用手挖下,但使用斧會更快。原木也是可燃的。

在現有的原木中,樺木是最稀有的品種。原木、木塊常用於組成植物,樹和木屋。在生存測試中,原木挖掘後掉落3 - 5個木材。而在Indev、Infdev、Alpha和Beta挖掘原木會則掉落一個原木。這使得原木可以作為建築材料,也能合成出木材。

原木唯一的合成用途是製作成4個木材。另外,原木可以在熔爐中燒制來製作煤炭的替代品木炭。

自2011年1月13日更新的Beta 1.2以來,總共有四種原木。一種是普通的原木(橡木),另一種像樺木,還有一種像普通原木,但更黑且出現在生長於寒冷生態域的松/針葉樹,第四種與橡木相似,但顏色稍有不同且斜向一邊。這些原木方塊依舊可以通過合成製作4個木材。不同種類的原木在物品欄里不會堆疊,但是木材可以。由不同種類的原木做成的木材完全相同。樺木的葉子比一般的葉子略微暗淡,松樹有松針,叢林木樹葉茂密且有水果樣的花紋。

第四種原木加入於快照12w03a,只生長在叢林生態域,組成它們專屬類型的樹。最高的樹使用這種類型的原木,尺寸為2x2而不是通常的1x1。

這部分的問題是陳舊信息散佈於新信息中。介紹應該陳述方塊在最新發佈版本的當前內容。歷史信息是好的,但為清晰起見,這些信息應該按時間順序寫在單獨的地方:條目的歷史段落。

未來

快捷方式
Project:未來

在未來更新中加入的內容應加入到條目的主內容中,被寫入的特性要用{{upcoming}}標記且是在預覽版本中出現過的。如果更新包含相關條目的巨大更改,那麼這些內容應在主段落中作為一個子段落提及,或是放在一個名為「即將到來」的專有段落。即將到來的特性必須同時在「歷史」段落,使用特定的「即將到來」的標頭提及。

更新發佈後,所有過期的內容都需要移動到歷史段落或移除,且所有使用的{{upcoming}}模板都應被移除。

英語語法

Wiki上的條目應使用美式英語,除非遊戲中名稱是英式英語。例如,「colour」應為「color」,而「centre」應為「center」。

英文使用

中文Wiki僅在一個條目的核心詞第一次出現時在括號給出其英文名稱。如果某特性更改了其英文名稱,而中文名稱不變,則在相應的歷史段落內說明。

段落等級

頁面主段落應以二級標題開始(兩個等號),每一子段落增加一級。永遠不要使用一級標題(一個等號)。

段落之間應有一個空格,等號與段落名稱也應有一個空格以方便編輯。如果使用了「主條目」連結或縮略圖,將其直接放在段落標題之下,然後在開始段落內容之前,接着輸入一個空格。

關於段落次序的信息,參見本格式指導的頁面佈局段落。

斜體

所有中文(及全角符號)內容都應使用斜體,且正文中的「Minecraft」也應使用斜體,但英文作品名稱應使用斜體,例如:Team Fortress 2(軍團要塞2)。對於正文中出現的書籍、電影等作品名,應按照中文書面語習慣規範使用書名號「《》」來進行標記,同樣應使用斜體。

圖像

快捷方式
Project:圖像

當往頁面加入屏幕截圖時,確保截圖用的是原版材質與UI。使用定製材質包、UI模組與其他定製內容的屏幕截圖是不被允許的,但關於模組的頁面除外。

圖像介紹末尾不應有句號,除非語句是一個完整的句子。

往頁面中加入的圖像應符合以下指導方針:

  • 圖像應展現頁面主題的一種屬性。
    • 圖像不應出現無意的怪異或搞笑之類的行為,例如生物「坐在」階梯上。
    • 圖像不應只有展示錯誤的目的,而錯誤應到官方追蹤器報告。
    • 圖像應避免展示具體特性的裝飾用途。
  • 頁面應只用一張圖片展示頁面內容的某一項獨立屬性。例如,一隻殭屍穿着盔甲。
  • 圖像應展示包含描述內容的最新版本的Minecraft。
    • 圖像如果過期則應被移除。

二次上傳英文Wiki的圖像時應當使用原圖,而不是低解像度的版本。

連結

快捷方式
Project:連結

對連結的使用是在為讀者提供使其能流暢閱讀頁面的足夠實用連結與干擾到閱讀流的多餘連接之間的艱難平衡。

連結缺失會使讀者困惑,因為可能會出現一些只能通過搜索選項或其他說明來源的關於頁面內容的問題,這些問題會打斷並干擾讀者。

連結過多可能會干擾讀者,因為連結常使用不同顏色來吸引眼球。此外,如果同一個詞在同一個段落被多次使用連結,會使讀者產生這些連結是否指向不同頁面的疑問。

連結的指導方針如下:

  • 單個頁面用於連結的詞不能超過10%。
  • 除非對句子的詞語組成或可讀性產生不利影響,兩個連結不能緊挨在一起,以致看起來像單個連結。
  • 任何單一術語的連結不能在同一頁面多餘地重複創建。多餘連結的定義是在某行或某自然段對同一術語創建多次,使其在讀者屏幕上總會不必要地出現。記住,連結的目的是在讀者需要更多信息,而要臨時繞道時,引導他們到一個新的地方。
  • 在頁面中離上一次出現有一定距離的地方重複創建重要連結應是很合適的。如果一個重要術語在一個長頁面中多次出現,但只在頁面最開頭的地方用了連結,就應當用下劃線標明。確實,帶着興趣直接跳轉到一個子段落的讀者必須依然能找到一個連結。但對於這種問題要小心對待,重複連結的距離關乎編輯者的喜好,然而如果存疑那就在更遠的地方重複。

連結到重新導向頁比用管道連結更好,除非是在模板和其他可能會被引用的頁面。如果無法避免使用管道連結,就不應將其指向重新導向頁。舉例:請用[[白桦原木]]而不是[[原木|白桦原木]]

紅石結構

紅石電路與機械的寫作應遵循Wiki的單一慣例。

文件

快捷方式
Project:文件

文件的名稱應當簡潔,且能表明文件的內容。需要注意:

  • 不應該只用日期來給文件命名(這經常發生在截圖上,請修改文件名)。
  • 文件名不應該包含中文字符。
    • 全角符號也被視為中文字符,請在上傳時改為半角。
  • 文件名也不應該包含「px」之類的尺寸說明。
  • 除了一些特殊文件另有用途外,請勿上傳Grid開頭的圖標,這些圖像統一收集在「小精靈」圖像中。
  • 確保文件名中沒有多餘的空格。
  • 文件後綴名一律小寫。

Infobox內的圖像名稱必須和遊戲內英文名稱一致,且應當是等軸視圖。為方便起見及保持名稱的一致性,這類文件的各材質版本命名格式為<特性名称> JEm BEn.png,其中「m」和「n」是此材質在對應Java版或基岩版中更新的次數(從1開始),隨材質的更新而遞增。<特性名称>.png作為重新導向指向最新的修訂版本。例如,File:Grass Block.png是一個重新導向,指向最新的File:Grass Block JEm BEn.png

頁面佈局

出於一致性的目的,特定類型的所有頁面都應遵循此常規佈局。

  • 在最頂部,可使用橫幅與模板,比如給一個版本用{{Version nav}},給方塊類頁面用{{Block}},等等。
  • 介紹,使用綜合性的描述。
  • 頁面正文,從第一個段落開始。

如果頁面目前尚未擁有佈局,可以在討論頁中提出;否則,就嘗試使用與已存在的佈局格式相近的佈局。目前頁面的佈局包括:

刪除頁面

為了防止出現孤立頁面,請勿直接清空一個頁面,而應當在頁面頂部使用{{delete}}模板提示管理員或巡查員刪除此頁面。使用了此模板的頁面會加入到Category:等待刪除分類中。