Minecraft Wiki:格式指導

快捷方式

MCW:SG

MCW:STYLE

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

雖然維基百科已經提供了一份更通用的格式指導，但專用於Minecraft的特殊指導方針是有必要的。同理，只有專用於Minecraft Wiki的指導方針和其基本的格式規則才會被收錄在這裡。如果有任何衝突，本頁面的優先級永遠高於本頁面的子頁面和維基百科的格式手冊。

關注度

快捷方式

MCW:關注度

只有符合以下準則的條目可以放在主命名空間。不符合準則的條目可能會未經通知即被刪除或重新導向。

常規

1. 條目必須包含足夠的資訊以支撐一個完整的條目。如果它們沒有足夠的內容，就會被合併到其他相應的條目。
2. 條目必須在某種程度上直接涉及Minecraft。
3. 關於人物的條目只允許此人物是Minecraft的開發者或與Mojang Studios相關。
4. 目前還不存在於遊戲中的特性只能放入對應版本的提及特性條目。
   1. 這不包括已被移除的特性或開發版本中的特性，它們應在受其影響的條目與相關版本的條目中提及。
5. 可以建立已發布的版本的條目；其中每個開發版本都應該建立單獨的條目。
   1. 可以建立關於未發布版本的條目，前提是有證明未發布版本存在的顯著資訊來源。這些來源包括開發版本或是多項關於下一個更新的特性。未發布的開發版本的條目不可被建立。此外，這些版本應該作為一個子章節加入到計劃版本。
   2. 原主機版的版本若不同平台的更新有類似的更新內容的，內容應位於同一條目。
   3. Minecraft的啟動器各版本也應當建立單獨的條目。如果同一個版本在不同平台上有不同的版本號，將不同的的數字用「x」替換。

社區內容

1. 遊戲內容相關的攻略、教學等應作為教學的子條目。
   1. 包含如何進行建築等雜項的條目不會被視為教學。它們應放入使用者空間。這包括使用者創作的活動與挑戰。
2. 只允許加入Mojang Studios表示已經玩過的小遊戲。
3. 不可建立關於用戶端和伺服器端的Mod、第三方應用程序和地圖編輯器等內容的條目。
   1. 這些內容應當在Feed the Beast Wiki上建立。
   2. 儘管本wiki上仍然存在部分此類內容（主要是輔助程式與編輯器的子頁面），但它們僅作留檔之用。
4. 不可建立關於客製化伺服器的條目。
   1. 這些內容應當在Minecraft Servers Wiki上建立。

Wiki條例

1. 違反《Minecraft最終使用者許可協議》《品牌和遊戲資產使用指南》的行為一律禁止。

4. 請勿誤導讀者和編者，確保您的編輯有據可依。請勿加入臆測、惡搞、虛假內容。

5. 請勿加入廣告內容或宣傳玩家伺服器和社區的頁面。

6. 請勿從其他網站擅自轉載內容到本站。

在「User」命名空間的條目是關注度指導的例外。這些條目可以在遵守相關Wiki條例的條件下作任意用途。不過，仍然十分建議保持它們儘可能整潔，以免出現在維護分類中，以及因使用者不再活躍而被清空。

重新導向

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

1. 是目標條目的縮寫、廣泛使用的社區名稱、曾用譯名、其他中文書寫系統中的名稱，例如「流髑」之於「流浪者」、「豬布林」之於「猪灵」。
   1. 也包括Mojang Studios員工的姓名或暱稱，例如「Dinnerbone」「Nathan」之於「Nathan Adams」。
   2. 但不允許建立錯誤拼寫、錯誤的曾用譯名。
   3. 也不允許建立粗俗名稱、含有強烈主觀色彩的名稱。
   4. 如果曾用名未廣泛使用，則也不能建立。
2. 屬於合併或雜項條目的一部分，例如一種藥水、一種提及特性或同一啟動器版本在不同平台上的版本號。
3. 特別地，允許基岩版譯名的重新導向，但是除了重新導向頁面以外，主空間不應出現基岩版譯名。

一個頁面的重新導向數量需在合理範圍內。重新導向條目的目標不能是不存在的條目或另一個重新導向條目。

英文名稱不應被建立重新導向。

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

條目標題

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

• 關於遊戲內方塊，物品和實體等特性的條目應使用Java版遊戲內譯名。目前，這些譯名由中文Minecraft Wiki管理團隊管理。完整的譯名列表可見此處。
  • 基岩版的譯名質量差，不應使用。
  • 如果某特性無遊戲內名稱，就應遵照其他同類型條目的相同形式，例如，生物雞騎士。
  • 如果條目是關於遊戲內多項事物的，標題應同等地代表所有名稱。例如，關於木質與鐵質門的條目應命名為門。
  • 如果某特性尚無確定的中文譯名，則使用其英文名稱作為占位，其相應條目的編輯應一律在公共沙盒中進行。待中文名稱確定後，再將條目移動至相應的中文名稱處（不留重新導向）。如譯名由於特殊原因在短期內無法確定，可酌情考慮將其移動至主命名空間，標題採用英文名稱，直至其譯名正式確定。
• 關於人物的條目應該包含姓氏與名字，而不是他們的Minecraft或Twitter暱稱。
• 消歧義條目在標題已被某條目使用時才應該包含「（消歧義）」。
• 若是以英文命名的條目，且條目類型未在此列出，則應選用句子型大寫（第一個單詞首字母大寫）的最確切的標題，而不應用標題型大寫（各單詞首字母大寫），除非其為一個特定的名詞。

關於遊戲版本條目標題的命名格式，請見版本#標題。

編寫

參見：Help:官方資源

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

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

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

教學資訊，包括對方塊或紋理的延伸特性，應只寫在教學條目。如果有重要關係，教學條目被主要條目連結。

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

保持條目的簡明與更新

快捷方式

MCW:更新

簡單來說，條目應該只包含最新的資訊，即在最新的「完整」遊戲版本所呈現的內容。任何的過期內容應該移動到條目的歷史段落。當有變更時，應在歷史段落中記錄並移除條目其他段落中的過期資訊。提及某一特定的特性在何時實現並不必要；這個特性也應當保留於條目的歷史段落。例如這樣的句子：「交易，實現於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。

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

未來

快捷方式

MCW:未來

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

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

引用

所有引用的內容應當和原文完全一致。引文中需要額外加入的內容應當以方括號[]標出。如果原文存在錯誤，則引用時應當在出錯處用{{sic}}標註。

段落等級

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

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

關於段落次序的資訊，參見本格式指導的頁面布局段落。

斜體

中文和英文的斜體使用方式有所差異。在本wiki中，斜體的使用規範如下：

• 一般情況下，任何中文內容都不應使用斜體。
  • 強調內容時可以適當使用粗體；包含中文的書籍、電影等作品名稱應使用書名號「《》」標記。
• 只包含英文的作品名可以使用斜體，如Minecraft: The Voyage。在英文句子中強調內容時，也可以使用斜體。
  • 正文中的Minecraft、Minecraft Earth和Minecraft Dungeons是僅有的三個例外，不應使用斜體。
  • 其他情況下，英文內容都不應使用斜體。
• 在計算公式等特殊內容中，可以適當使用斜體標記參數。

另外，有時為了防止機器人在批量替換文字時破壞模板參數，部分正文內容也會使用斜體標記。這類標記會在文字替換完成後由機器人自動去除。

英文內容

條目正文內除開頭的關鍵詞外，一般不應出現英文。關鍵詞的英文應當遵循遊戲內名稱（如有）或常規的美式英語拼寫。含有大段英文內容的條目應當移動至沙盒。

圖像

快捷方式

MCW:圖像

當往頁面加入畫面截圖時，確保截圖用的是原版紋理與UI。使用客製化紋理包、UI模組與其他客製化內容的畫面截圖是不被允許的，但關於模組的頁面除外。

為清楚顯示截圖內容，除非目的是展示平視顯示器（HUD）相關內容，否則需要隱藏HUD（可透過按F1切換隱藏）。

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

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

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

二次上傳英文wiki的圖像時應當使用原圖，而不是低分辨率的版本。

連結

快捷方式

MCW:連結

  關於完整的連結指導，請見「連結格式守則|wikipedia:zh:Wikipedia:格式手冊/連結|連結格式守則」。

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

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

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

連結的指導方針如下：

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

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

坐標

遊戲內的單個坐標應當大寫，並且不需要加入空格（即「Y=1」而不是「y=1」或「y = 1」）。體積標識應當按照X、Y、Z的順序寫出，中間使用乘號（「×」，×）隔開；例如，「4×3×2」表示一個沿X軸4格、Y軸（豎直方向）3格、Z軸2格的區域。更深入的坐標表示正在討論中。

指令

指令格式應當嚴格遵循遊戲內的提示。

Java版

需要按原樣輸入的內容（字面量）沒有其他任何修飾（如/data merge）。需要以合適的值替換輸入的內容（變數）使用尖括號標註（如<target>）。可選的內容以方括號標註，但方括號不能取代其他標註（例如，[<size>]是可選的變數，而[size]是可選的字面量）。必須從一組字面量中選擇一個輸入的內容用圓括號標註，以管道符分隔（如(eyes|feet)）。可選的從一組字面量中選擇一個輸入的內容用方括號標註，以管道符分隔（如[destroy|replace|keep]）。

以/advancement (grant|revoke) <targets> only <advancement> [<criterion>]為例，/advancement和only是需要原樣輸入的字面量，(grant|revoke)是需要從grant和revoke中選擇一個輸入的字面量，<targets>和<advancement>是必需的以合適值替換的變數，[<criterion>]是可選的以合適值替換的變數。

檔案

快捷方式

MCW:檔案

檔案的名稱應當簡潔，且能表明檔案的內容。需要注意：

• 不應該只用日期來給檔案命名（這經常發生在截圖上，請修改檔案名）。
• 檔案名不應該包含中文字元。
  • 全形符號也被視為中文字元，請在上傳時改為半形。
• 檔案名不能是無意義的字母、數字和符號的組合，或者是image、photo和picture等無具體含義的單詞。
• 檔案名也不應該包含「px」之類的尺寸說明。
• 除了一些特殊檔案另有用途外，請勿上傳Grid開頭的圖示，這些圖像統一收集在「小精靈」圖像中。
• 確保檔案名中沒有多餘的空格。
• 檔案後綴名一律小寫。

Infobox內的圖像名稱必須和遊戲內英文名稱一致，且應當是等軸視圖。隨著遊戲的更新，這類圖像往往會產生多個修訂版本，為方便起見及保持名稱的一致性，這類檔案的各紋理版本命名格式及使用要求如下：

• 以<特性名稱> JEm BEn.png為格式統一命名。
  • 「m」和「n」是此紋理在對應Java版或基岩版中更新的次數（從1開始），隨紋理的更新而遞增。
• 將<特性名稱>.png作為重新導向指向遊戲最新正式版中使用的修訂版本，並應用在Infobox中。
  • 例如，File:Grass Block.png是一個重新導向，指向最新正式版中使用的紋理File:Grass Block JEm BEn.png。
  • 若遊戲開發版本使用了原有遊戲內容的新紋理，應待其所屬的正式版本發布後再將該重新導向指向新紋理。
  • 對於遊戲開發版本加入的新內容，該重新導向應指向最新開發版本當中使用的紋理。
• 需要額外註明其他特徵的，檔案名應當遵循<特性名稱> (<特徵>) JEm BEn.png的形式。
  • 其中<特徵>部分一般應小寫，例如Oak Door (item) JEm BEn.png。

如圖像含有大量需要繁簡轉換的內容，應當單獨上傳適用於各自地區的版本，檔案描述內相互註明其他地區和Category:漢化圖像。為方便起見及保持名稱的一致性，這類檔案的各地區版本命名格式為<圖像原名稱> Simplified.png、<圖像原名稱> Traditional.png和<圖像原名稱> Traditional HK.png，其中Simplified代表內含大陆简体的圖像、Traditional代表內含台灣正體的圖像、Traditional HK代表內含香港繁體的圖像，並建立<圖像原名稱>.png到<圖像原名稱> Simplified.png的重新導向。

頁面布局

出於一致性的目的，特定類型的所有頁面都應遵循此常規布局。一般條目從上往下分別是：

1. Hatnote（頂注）；
2. Message box（訊息框）；
3. Infobox（資訊框）；
4. 關於條目的簡要介紹；
5. 條目主體部分；
6. 另見/另請參閱；
7. 注釋和參考；
8. 合適的底部導航；
9. 分類；
10. 跨語言連結。

條目頂部內不應有過多的訊息框。必要的時候，請將訊息框移動至與其最相關的段落頂部。

特定類型的布局

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

• 特性類
• 紅石類
• 版本類

刪除頁面

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