Minecraft Wiki

除另有声明,转载时均必须注明出处若簡繁轉換出錯,請以遊戲內為準请勇于扩充与修正内容有兴趣逛逛我们的微博沟通交流,欢迎到社区专页需要协助,请在告示板留言

了解更多

Minecraft Wiki
Advertisement
該頁面是Minecraft Wiki:社群專頁的存檔頁,請勿編輯該頁面。

可在目前討論頁發起新討論。

重新整理模板{{Blocks}}的方塊分類

下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 同意更新


目前導航模板{{Blocks}}中已收錄數百種方塊,展開長度過長,且其目前的分類情況較為混亂,遊戲每變更一次方塊的生成方式,模板中的部分方塊可能就要重新分類一次,如不注意維護很容易產生資訊過期的情況,而且這也不利於玩家查找方塊。建議重新整理此模板的方塊分類。

為此,我已整理了一個新的導航模板(見此),相比原來的導航模板作出的修改如下:

  • 棄用原有的方塊分類方式,以Java版的創造模式物品欄為基礎分類,並按照玩家的思維稍加改動,避免分類屬性交叉,查找方塊更加方便。
  • 將整個導航拆分為預設摺疊的四個部分,可以按照頁面介紹的方塊類型展開其中一部分,減少頁面占用空間。

具體的分類細則及使用方法已寫在文件頁面當中,如對此模板的分類規則和使用方法等方面有建議可在此提出。--葉月 § 2021年1月2日 (六) 04:21 (UTC)

 支持。--AblazeVase69188討論) 2021年1月2日 (六) 05:28 (UTC)
 建議:某些部分應按照種類(如冰磚藍冰)排列在一起,而非按照英文首字母排列。--AblazeVase69188討論) 2021年1月2日 (六) 05:37 (UTC)
那就需要為這種特殊情況制定統一的排列規則,避免排列混亂。--葉月 § 2021年1月2日 (六) 05:53 (UTC)
 建議:將每個分組下的方塊優先按照加入遊戲的時間排列,先加入者在前。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月2日 (六) 11:13 (UTC)
 反對:查閱方塊加入歷史的過程比較繁瑣,更難維護,且存在方塊在不同版本加入的時間差異等問題。--葉月 § 2021年1月5日 (二) 14:15 (UTC)
 支持--Snow Dash & ) 2021年1月5日 (二) 18:01 (UTC)
 支持,此外「生物」改成「動植物」也許會好一點。--Lxazl5770zh.admin) 2021年1月6日 (三) 05:38 (UTC)
不用「動植物」是因為蘑菇等方塊嚴格意義上屬於真菌,而且還存在垂泣藤和扭曲藤這樣的生物屬性模糊的方塊,這些特例不能很好地概括進去。--葉月 § 2021年1月6日 (三) 06:34 (UTC)
 已完成,模板已更新,同時已使用機器人補充所有方塊頁面的模板參數。關於此模板的其他建議可在其討論頁上提出。--葉月 § 2021年1月6日 (三) 09:05 (UTC)

跟進「中文MCW怎麼變成了這個樣子?」

我自己的MediaWiki站點上,我最近加入了一些英文的系統資訊。由於某些原因登出之後,發現也出現了相同的問題,即以Headeraccept-language: zh-CN,zh;q=0.9訪問頁面時,部分系統資訊會變成英文,但<html>標籤的lang屬性依然是zh-Hans-CN。我的wiki上只有有/en子頁面的資訊會變成英文。查看MediaWiki:Portal,發現也存在MediaWiki:Portal/en。個人認為這有可能是MediaWiki的錯誤。已知Headeraccept-language: zh-TW,zh;q=0.9沒有問題。希望這些資訊能夠幫助給予一些該問題的Workaround。-- LakeJasonFace Lakejason0) 2021年1月2日 (六) 08:36 (UTC)(最後編輯於2021年1月2日 (六) 08:39 (UTC))

已報告至Phabricator-- LakeJasonFace Lakejason0) 2021年1月2日 (六) 09:13 (UTC)
經排查,問題來源為本wiki自身頁面錯誤。修復需要上報wiki主管或fandom helper。MysticNebula70 T  2021年1月2日 (六) 10:52 (UTC)

刪除版本介紹頁面中的「新內容一覽表」

自Java版1.16快照更新起,有使用者從英文wiki的版本介紹頁面當中搬運了「新內容一覽表」,其形式為利用{{FakeImage}}{{Inventory}}模板製作出的方塊、物品展示列表。但此舉並未經過討論,目前的格式指導也並未寫出任何有關此列表的編寫規範。後來,英文wiki移除了這些列表,相關討論見此

雖然中文Wiki保留了這些列表,但由於未加以規範,隨著該列表被應用到越來越多的頁面,其暴露出的問題也越來越多:

  • 部分方塊(如粉雪)沒有物品形式,使用{{Inventory}}展示可能會誤導玩家。
  • 部分生物(如幻術師)沒有生怪蛋,無法以生怪蛋的形式展示。
    • 用生怪蛋來表示生物也並不直觀。
  • {{Inventory}}無法反映物品的材質變化。
  • 部分物品(如愚人節玩笑版本當中的物品)不適合收錄到Autolink當中,這些物品通常也沒有單獨的頁面介紹,放入列表會產生紅鏈,難以維護。
  • 部分物品的不太重要的衍生形式(如裝填了箭或煙火的)有時也會加入到列表當中,似乎沒有必要。
  • 部分加入很少新內容的版本(如20w14a)也使用了此列表,但空白較多,浪費頁面空間。
  • 部分加入大量新內容的版本(如教育版1.0.27)使用此列表後顯得極其凌亂。

綜上所述,我認為這類列表不適合展示在版本介紹頁面當中,加之很多使用者在加入這些列表時往往會忽略一些細節問題(如不注意Java版和基岩版的特性差異、寫錯版本標題以及描述文字),常常出現錯誤,質量較差,因此我建議移除版本介紹頁面當中的所有這類列表。相較而言,在指南和教學等頁面上使用這類列表可能更加合適,可以考慮轉移。--葉月 § 2021年1月9日 (六) 12:43 (UTC)

 建議
  • 在大型更新的頁面(如地獄更新Java版1.16基岩版1.16.0等)保留,而在開發版本(如20w06a基岩版1.16.0.51等)移除。
  • 至於物品的衍生形式(如半滿和全滿的束口袋之於空的束口袋),可以考慮保留其基本形式(如空的束口袋)。
  • 至於愚人節玩笑相關的物品,應待en的相關頁面完善並在本wiki得到同步之後再考慮在相關頁面加入{{Inventory}}
  • 對於加入了大量內容的版本,私以為應當按照一定順序排列(如物品的材料類型、在常規遊戲中獲得的先後順序等):
    • 一種物品的不同顏色、材料或變種形式(如各種顏色的染色玻璃、不同材料的工具以及鏽蝕程度不同的銅方塊)應考慮以動畫表示以減少其在列表中占用的網格,如
以上。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月9日 (六) 13:11 (UTC)(最後編輯於2021年1月12日 (二) 14:25 (UTC))
從我自己的角度來說,我真的看到有人會使用這種圖來分享到底有什麼新內容,因此我並不認為這個主意本身是壞的。但是的確,出現了一些維護問題,並且其實比你說的還多(尤其是繁簡轉換)。我偏向 保留,但是如果覺得真的不行,那我會堅持 轉移。-- LakeJasonFace Lakejason0) 2021年1月10日 (日) 06:17 (UTC)
 支持移除,當然這種簡介直觀的形式確實也有它的存在必要。如果確實有需要,可以在Java版指南之類的地方放吧?--Snow Dash & ) 2021年1月10日 (日) 06:36 (UTC)
我也偏向 保留,但如果那些維護問題沒法解決,那就最好 移除。--ChengBing討論) 2021年1月10日 (日) 08:24 (UTC)
個人傾向於將特性簡介統一 轉移至指南頁面。MysticNebula70 T  2021年1月10日 (日) 09:22 (UTC)
 回應——我倒是不希望完全移除,因為其可以非常直觀地讓讀者知道更新了些什麼東西。最好是將其移動到別處或者保留一部分,而不是entirely removed。--Lxazl5770zh.admin) 2021年1月10日 (日) 10:45 (UTC)
 再次回應——如上述,我認為大型更新的版本記錄(如Java版1.15)、更新主要內容頁面(如嗡嗡蜂群)和版本指南等保留新內容一覽表,其餘頁面包括愚人節版本全數移除。並寫入格式指導。--Lxazl5770zh.admin) 2021年1月14日 (四) 05:22 (UTC)
根據以上討論,即將移除所有開發版和非正式版頁面上的列表,並將其轉移到指南頁面和更新主題頁面當中。考慮到維護問題,正式版頁面上的列表也將暫行移除,待格式指導將其規範化(如可能)後再恢復並完善。--葉月 § 2021年1月14日 (四) 07:26 (UTC)

重新整理模板{{Items}}的物品分類

下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 同意更新


受到Hatsuki kiri的啟發,本人整理了一個新的導航模板(見此)。與新整理之後的{{Block}}同樣,{{Items}}根據遊戲內的創造模式物品欄重新歸類,但有所改動:

  • 資訊源和載具併入工具,裝飾併入功能性,武器和盔甲合併為戰鬥
  • 雜項裡新增礦物、動物子分類以減少原材料的物品數量
  • 烈焰粉、地獄疙瘩、龍之吐息歸為釀造;馬鞍歸為載具;藥物歸為功能性;金胡蘿蔔歸為食物;釀造台和鍋釜(皆為物品形式)歸為釀造
  • 移除了獨立的僅創造、僅指令和即將歸來子分類

最為重要的一點是,這樣的分法避免了「其他」子類別(用於歸類無法按常規歸類的孤兒們)的出現。

對此模板的分類規則和使用方法等方面有建議可在下方提出,我需要各位的建議。--Lxazl5770zh.admin) 2021年1月12日 (二) 14:19 (UTC)

這是好的。(我在想為啥斧和鎬鋤隔了那麼多桶,原來是按字母排的)--Ff98sha討論) 2021年1月12日 (二) 14:30 (UTC)
 回應現在的問題是如何重新定義「工具」(因為我覺得資訊源和交通工具也算是工具一類),遊戲裡的工具給的定義非常狹小且不能進一步細分。其他的基本上無大礙。--Lxazl5770zh.admin) 2021年1月14日 (四) 05:16 (UTC)
如果沒有人有異議的話過幾天就會實施。--Lxazl5770zh.admin) 2021年1月23日 (六) 00:58 (UTC)
 已完成。後續討論請新開話題。--Lxazl5770zh.admin) 2021年1月26日 (二) 06:29 (UTC)

關於同類索引條目的規範

雖然根據在社群專頁達成的共識,中文Minecraft Wiki已經引入了同類索引頁面,但是對於其規範尚有不明之處,故在此徵詢各位的意見:

  • 當與既有頁面重名時,應如何命名同類索引頁面?

在瀏覽中文維基百科時發現:對與其他條目重名的同類索引,中文維基百科一部分採用在頁面名稱後加注「索引」的方式(如wzh:試播集 (索引)),而另一部分仍沿用「消歧義」的後綴(如wzh:包青天 (消歧義))。試問本wiki應採用哪種方式區分同類索引頁面?

以上。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月12日 (二) 15:37 (UTC)

 回應現在看來似乎有很多消歧義要轉為同類索引。我覺得同類索引不需要加上「索引」後綴,反而現在把所謂的「消歧義」轉為同類索引才是首要工作。--Lxazl5770zh.admin) 2021年1月14日 (四) 05:12 (UTC)
以下是個人對「消歧義」與「索引」使用的看法。
  • 最好按照「消歧義」與「索引」的字面意思處理。
    • 說文解字,「消歧義」頁面是為了對很可能產生歧義的頁面進行區分的頁面。而「索引」應該是將同類事物羅列在一起的頁面。
  • 個人覺得,現在絕大部分的消歧義頁面都改成索引,但對於非常容易產生歧義的,或由於譯名變更而產生歧義的(eg:對於來說,可能指生物鱈魚,可能指物品鱈魚,也有可能指其它的魚,種子同理,但只需要區分金粒、金錠或黃金方塊),即使對應頁面做了區分(如魚(生物))也需要建立消歧義。
  • 對於其他的(比如不死生物窳民)只需要改成索引即可。

--ChemistChangTalk/Contributions) 2021年1月17日 (日) 15:44 (UTC) (最後編輯於2021年1月17日 (日) 15:44 (UTC))

關於16種染料的獨立頁面

下列有關合併頁面的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 同意合併


16種染料不僅有綜合頁面(染料),同時還有各自獨立的頁面(白色染料綠色染料黑色染料等)。不同顏色染料之間僅有取得方式上的差異,用途基本完全一致。我認為保留各個顏色染料獨立頁面沒有必要。可以全部整合進染料,而現狀也基本是如此。是否可以將16色染料的頁面合併到染料頁面? --Snow Dash & ) 2021年1月22日 (五) 15:03 (UTC)

 同意,其他有色物品(界伏盒蠟燭羊毛玻璃等)都是寫在一個頁面中的,可以借鑑。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月22日 (五) 15:57 (UTC)
 支持。--XiaoXin666T·C 2021年1月22日 (五) 16:37 (UTC)
 支持如今青金石等的部分具有染色功能的物品已經被專門的染料取代了,我覺得是可以合併的。順便合併之後我會去掉{{Items}}模板的染料子分類。--Lxazl5770zh.admin) 2021年1月23日 (六) 00:46 (UTC)
 支持可以減少維護工作量。135ty討論) 2021年1月23日 (六) 03:05 (UTC)
重新導向已完成,但有多個頁面出現合成配方錯誤的問題。--葉月 § 2021年1月23日 (六) 05:57 (UTC)
目前合成配方問題已解決。--葉月 § 2021年1月23日 (六) 09:24 (UTC)

刪除輔助程式與編輯器

英文wiki已經建議把第三方程式的相關內容全部移動到ftb,其中包括輔助程式和編輯器(見此)。對於中文wiki,此舉是否有必要?這些頁面是否活躍,有人維護?有人閱讀這些頁面嗎?--Dianliang233 2021年1月26日 (二) 02:17 (UTC)(最後編輯於2021年1月26日 (二) 02:22 (UTC))

中文ftb無受眾,轉到ftb將更沒人看。方法放寒假 (Talk - Contributions) 2021年1月26日 (二) 02:31 (UTC)
 反對,畢竟是輔助原版的輔助程式,我個人傾向於保留。應該還是有人會閱讀,但維護確實很少。如果真的要移動的話最好保留一個軟重新導向。--Snow Dash & ) 2021年1月26日 (二) 03:23 (UTC)
 意見:輔助程式與編輯器與mod一樣,不受Mojang等的支持,因此個人建議將這些內容全部移動至ftb,並保留軟重新導向。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月26日 (二) 03:30 (UTC)
那些輔助程式沒記錯的話一堆不見有人用的遠古玩意,更別說維護了……這類玩意留這裡也不見得有什麼用,移過去也沒什麼影響。——IcyPhantom 討論I貢獻 2021年1月26日 (二) 03:35 (UTC)
 意見:建議保留。輔助程式與編輯器也不是沒有人用,所以可能需要這些頁面,但是要刪去多數版本過舊的輔助程式與編輯器。--AblazeVase69188討論) 2021年1月26日 (二) 09:47 (UTC)

基岩版標籤

基岩版beta1.16.100.56中加入的查詢器query.any_tagquery.all_tag可查詢方塊或物品的標籤
即:基岩版有方塊和物品標籤
但至今ID_table模板仍無基岩版標籤參數
是否會考慮加入?
連結列出了一些Miemiemethod在源碼找的方塊標籤
方塊標籤(這個頁面是我水的
2190303755(T|C) 2021年1月28日 (四) 07:53 (UTC)

自己看著辦吧--Lxazl5770zh.admin) 2021年2月5日 (五) 14:39 (UTC)

對15w44b頁面修改被撤回的異議

在終界燭的頁面已經有提到在快照15w44b中加入了終界燭的合成配方,所以我認為在15w44b中加入這個應該沒啥問題,這與後文並不算衝突,前半句話是闡述終界燭合成配方被加入的事實,後半句話是合成的結果,刪去可能會失去在15w44b新加入的語義,望15w44b/變更/方塊/終界燭 變更為「加入了終界燭的合成配方,每次合成產出4根。」–該未簽名留言由Hanpi3626討論貢獻)在2021年2月5日 (五) 12:14 (UTC) 加入。請在您的回覆後面加上 ~~~~

「現在可以由底部放置爆開的歌萊果,頂部放置烈焰桿來合成。」這句話就已經表示加入了新的合成配方,後面再補一句會顯得資訊重複,沒必要。另外,這種只涉及小改動的話題請直接到對應的討論頁或相關使用者的討論頁上發布。--葉月 § 2021年2月5日 (五) 12:27 (UTC)

在頁面的「現在可以由底部放置爆開的歌萊果,頂部放置烈焰桿來合成。」這一句話只是說明的是這個物品的性質,如果是要這麼說的話那也可能說明這是在加入合成配方之前增加的性質,您說是不是這個理?而且,這也說明了終界燭擁有合成配方的時間。Hanpi3626討論) 2021年2月5日 (五) 14:08 (UTC)

我已經修改了原文以迎合你表達的意思。注意源代碼裡星號*表達的從屬關係。按照邏輯應該是先敘述是否存在配方再敘述如何合成,兩者本來是遞推關係,如果先敘述合成配方再敘述是否有這麼一個配方就顯得混亂而且不符合直覺。此外,社群主頁不應該用於匯報編輯問題,請到對應頁面下的討論頁或者執行者的討論頁進行留言。--Lxazl5770zh.admin) 2021年2月5日 (五) 14:37 (UTC)
此外,你說的「現在可以由底部放置爆開的歌萊果,頂部放置烈焰桿來合成」這句話不是終界燭固有性質,這句話僅僅只是在敘述它的合成配方。性質應該隨事物的出現而同時出現,或者消失時同時消失(簡單點說性質是與生俱來的)。顯然此處的合成配方是之後加上去的,這就談不上什麼性質了。--Lxazl5770zh.admin) 2021年2月5日 (五) 14:44 (UTC)

Java版資料值需要更新?

英文wiki跟中文Wiki不統一,Java版資料值需要更新,Minecraft Wiki:沙盒/Java版資料值211.140.201.9 2021年2月5日 (五) 15:39 (UTC)

等你學會了怎麼簽名再來說話。--Lxazl5770zh.admin) 2021年2月5日 (五) 13:20 (UTC)
自己動手豐衣足食,勿問「為什麼沒有oo?」。--Ultim 0 ( VIEW | TALK | CONT ) 2021年2月5日 (五) 14:53 (UTC)

編輯問題

能否在中文Wiki加入有可靠依據但沒有英文wiki上出現的修改?[Wiki小萌新]DSDlonDTX 2021年2月9日 (二) 09:36 (UTC)

可以。如有能力可以把資訊也補充到英文wiki上。--葉月 § 2021年2月9日 (二) 08:12 (UTC)

關於版本頁面問題

下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 按照Miemiemethod的方案進行更新


如題,舊事重提。攜帶版/基岩版的歷史版本頁面格式較為混亂,一直沒有得到妥善解決。

在和Miemiemethod進行討論後,於MCW:SGMCW:SG/V的基礎上在此提出一些方案。討論完後將會寫入MCW:SG/V中。

此外,MCW:SG/V本身也不夠完善,希望能夠進一步改進。

這些頁面共同的問題有:

  • 大多數版本頁面的「修復」段落沒有具體內容(或未被翻譯,不顯示),也沒有使用{{Fixes}}模板(Java版等其他版本也存在這種情況)。
  • 「介紹」段落的第一句話,如「Beta 1.16.210.58是基岩版1.16.210的第8個開發版……」等前的「Beta」和「Alpha」首字母是否要大寫
    • 有些頁面沒有大寫。而由於英語的語言習慣,en全部都大寫了。
  • 仍然需要補全選單介面的截圖。

關於標題等內容的格式:

  • Miemiemethod的思路是,「版本號是為了區分的」,建議對區分無用的部分全部都刪掉,並且建議直接按照AndroidManifest.xml中的內容進行命名。
  • 我的思路則是儘量參照遊戲內顯示的版本號原文進行命名,畢竟Mojang寫在沒人看的地方(例如Microsoft Store等)的格式真的是千奇百怪。
  • zh的現行方案,既沒有完全按照遊戲內原格式,也沒有完全拋開遊戲內原格式,而是對遊戲內原文進行一定變形,顯然不夠恰當。
  • en的現行方案完全參照遊戲內原文。

攜帶版Alpha

年久失修。

標題可使用如下幾種格式:

  1. 携带版vx.x.x[.x] alpha[x][build x](遊戲中如此,en使用方案,zh經過我填海的頁面行文也使用此方案)
  2. 携带版Alpha x.x.x[.x][(x)][build x](zh現行方案,括號建議改為半形)
  3. 携带版x.x.x[.x][build x][(【内部版本号】)]携带版x.x.x'[.x][build x][_Rev]Miemiemethod的方案)

相關檔案的標題也可整理為這種格式,如en就將選單介面的截圖示題全部變更為File:Pocket Edition vx.x.x[.x] alpha[x]的格式。

相應地,{{Version nav}}|title=參數也需要進行變更,|protocol_manual=也受其影響。

頁面內當時使用舊版材質的物品、方塊和實體等前可加入繪製圖,參見Java版歷史版本頁面的格式。

攜帶版正式版

目前沒有發現顯著的問題存在。

現行格式為遊戲內原格式携带版alpha x.x.x.x携带版x.x.x

en把形如「攜帶版x.x.x」的頁面中{{Version nav}}|title=參數前全部都加上了v,這也是遊戲內原文導致的。

Miemiemethod的方案是去掉alphav等。

基岩版

同上,Miemiemethod的方案是建議去掉beta等。

鑑於時間倉促和個人能力有限,可能有特殊情況和其他問題沒有列出。--SkyE | Talk · Contributions · Logs 2021年2月9日 (二) 16:03 (UTC)

 附議,我建議只保留「xx版」及其版本號,示例「基岩版1.16.210.58」及「攜帶版0.2.1_Rev」、「攜帶版0.10.0.b9」;同理,就算攜帶版Alpha_0.2.0要拆分,也可以拆成「攜帶版0.2.0」、「攜帶版0.2.0_Rev」、「攜帶版0.2.0_j」和「攜帶版0.2.0_Lite」。「Alpha」、「Beta」及不必要的括號、空格都可以去掉。方法放寒假 (Talk - Contributions) 2021年2月9日 (二) 16:36 (UTC)
方案給的實在太多了……這樣看下來我也只能給 中立了。-- LakeJasonFace Lakejason0) 2021年2月9日 (二) 16:39 (UTC)
 支持MysticNebula70所描述的方案。-- LakeJasonFace Lakejason0) 2021年2月12日 (五) 09:05 (UTC)
個人 反對支持刪除前綴alphabeta因為這些前綴可以明確地表示該版本是開發版,並不是多餘的便於查找和輸入;其餘方案保持 中立。--XiaoXin666T·C 2021年2月10日 (三) 05:18 (UTC)(最後編輯於2021年2月11日 (四) 09:41 (UTC))
前綴alphabeta並非開發版的代表,但是我不想就這個觀點進行爭論。就算二者是開發版的代表,加與不加不會造成任何混淆,因為沒有兩個版本擁有相同的版本號但是一個帶beta一個不帶;並且,開發版與否可以直接看Infobox內以及第一段段首第一句話,標題帶著beta不僅累贅(不便於查找和輸入),而且和頁面內資訊重複,而且沒有起到任何和其餘版本區分的作用(因為加與不加兩個版本都能區分開,就算某個正式版與某個搶鮮版區分,他們最大的不同也是版本號不同而非有沒有beta)。因此 反駁你的觀點。方法放寒假 (Talk - Contributions) 2021年2月10日 (三) 12:21 (UTC)
 確實,前綴alphabeta沒必要保留,是我思慮不周,感謝你的反駁。--XiaoXin666T·C 2021年2月11日 (四) 09:41 (UTC)
 支持--RealCuervo討論) 2021年2月10日 (三) 12:45 (UTC)
我個人 同意Miemiemethod的方案。希望能夠就此方案進一步完善。 --SkyE | Talk · Contributions · Logs 2021年2月10日 (三) 14:49 (UTC)

總結一下上述方案:

  • 攜帶版版本應加前綴「攜帶版」。例如,「0.9.0」應被命名為「攜帶版0.9.0」。
    • 攜帶版開發版本應先加上前綴「攜帶版」,然後加上相關說明字樣。例如,「0.9.0」的第二個開發版應被命名為「攜帶版0.9.0.b2」。
  • 基岩版版本應加前綴「基岩版」。例如,「1.2.0」應該使用「基岩版1.2.0」這個標題。
    • 基岩版開發版本應先加上前綴「基岩版」,然後加上版本號數字。例如,「1.5.0」的第一個開發版本應被命名為「基岩版1.5.0.0」。

為方便查找,現行命名作為重新導向處理。如有其他意見請提出。MysticNebula70 T  2021年2月11日 (四) 02:48 (UTC)

 意見
  1. AlphaBeta等建議首字母大寫,畢竟是稱呼開發版本版本號的特有用語,不是一般英文單詞。
  2. 對於基岩版各版本的標題, 同意直接參照遊戲內格式進行命名,要不然太亂了。
  3. 對於基岩版開發版本標題的命名, 支持去掉AlphaBeta等英文,便於輸入與查找。
對於其餘方案則保持 中立。--AblazeVase69188討論) 2021年2月11日 (四) 08:57 (UTC)

Dianliang233的提議

我個人強烈 反對上述所有方案(除「攜帶版」「基岩版」前綴)。

我提議:按照en的命名方案,嚴格跟隨遊戲內命名

遊戲內命名可以消除絕大多數歧義:這樣的命名方案不但不會消除潛在的錯誤認知,而且使玩家的資料查詢變得無比便捷。遊戲內寫什麼,他們就搜什麼,這種方案最為直觀,符合人類的認知習慣。玩家也不需要在根據「wiki的命名」和「Mojang的命名」之間做毫無必要的猶豫。

若您認為我的這些觀點毫無邏輯,那麼請問一個版本的標題不是版本在遊戲內的命名有何意義!?

以上。-- Dianliang233 TC 2021年2月12日 (五) 11:58 (UTC)

首先要明確遊戲內版本到底是哪一個版本,如果按照遊戲內右下角,所有的beta和alpha都將被去掉。如此圖,遊戲內版本應該是v1.16.210.59。en目前所有的攜帶版版本頁面標題都帶著「v」前綴,但是基岩版都沒帶,但是所有的版本v前綴都是存在的。
Bedrock 1.16.210

如果你認為頂部顯示的是遊戲內版本,首先第一點就是正式版並沒有那個東西;第二點是,beta雖然擱那兒了,雖然和版本號挨著,但是它是不是「版本」的一部分都有待爭議,因為alpha也曾經在這個位置,當時沒有進入beta階段,那麼alpha是否屬於版本的一部分也有待爭議。如果認為beta是測試的意思,那alpha應該也是測試的意思,但是按照en的命名方法,所有的攜帶版前綴都有alpha,但是基岩版只有搶鮮版有beta前綴,這是不是一種矛盾?如果認為alpha是開發週期,那麼在某個時刻Mojang用beta字樣取代了同位置(在頂部的那個)alpha,那麼beta是否也是開發週期?大多數人不苟同,那麼又出現了矛盾。

好,就算我們不考慮矛盾,返回「遊戲內版本」的問題,以頂部字樣作為遊戲內版本只能對搶鮮版適用,但是搶鮮版和正式版右下角都有版本號,所以以右下角版本作為遊戲內版本號倒是可以對所有版本適用,那就算所有的版本條目的標題都改成「基岩版/攜帶版v1.xx.xx」,beta和alpha字樣也是不應該出現在標題內的。但是很明顯v是version的縮寫,本身肯定不是版本號的一部分,因為version 1.xx.xx就是「版本1.xx.xx」的意思,你應該不覺得「版本1.xx.xx」中的「版本」是「版本號」的一部分吧。那麼標題是不是應該為「基岩版/攜帶版1.xx.xx」其中最後那個1.xx.xx是遊戲內右下角v後面的東西

好,再退一步,就算不考慮遊戲內版本,你所說的「按照en的命名方案,嚴格跟隨遊戲內命名。」,可以明確的是en根本就沒有嚴格按照遊戲內命名,上面的文字已經說了好幾個en命名的矛盾之處,這也是本次討論為什麼會展開的原因。那麼單從版本號分析的角度來看,以「有沒有出現在標題中的意義」為角度切入,也是所有的alpha、beta和v以及括號、空格都不應該存在在版本號中,雖然存在也有一定意義,但是意義不大,沒有大到縮短標題能帶來的受益程度大。目前標題長而冗雜,按照你說的確實能在一定程度上幫助人們找到標題,但是大部分時候是找不到標題的。我個人是習慣直接用地址找頁面而非搜尋功能的,深知少一個空格,打錯一個字母,多一個空格,或者想找「基岩版beta 1.16.210.59」結果輸入了「基岩版v1.16.210.59」或者「基岩版1.16.210.59」萌新發現找不到頁面時多麼無措。你說用搜尋功能不就好了?那麼就算標題換成「基岩版1.16.210.59」,搜尋功能不依舊有用?甚至沒有了各種前綴後綴,搜尋效率不更高嗎?

綜上, 駁回方法放寒假 (Talk - Contributions) 2021年2月12日 (五) 12:25 (UTC)

 同意Miemiemethod的論述。

首先,這裡是Minecraft Wiki,不是Minecraft Java版 Wiki;既然Wiki上Java版的快照頁面標題能夠刪去「Java版」這一多餘元素,攜帶版/基岩版/教育版版本頁面的標題命名雖然無法刪去「攜帶版/基岩版/教育版」,但是多餘的其他任何元素都可以刪去。繁則同繁,簡則同簡;如果攜帶版/基岩版/教育版的版本頁面名稱不能得到有效簡化,請把Java版的快照前加上「Java版」——為什麼Java版的快照不命名成「Java版Minecraft 21w06a/snapshot」?

Dianliang233提出的論點「玩家也不需要在根據『Wiki的命名』和『Mojang的命名』之間做毫無必要的猶豫」,試問平日裡玩家溝通的時候有誰會帶著「Alpha」和「Beta」嗎?簡而言之,玩家不會去在意Mojang到底是怎麼命名的,沒有普通玩家會一字不落地記下Mojang的命名規則。這和譯名標準化有一定意義上的不同。

根據我之前提出的方案列表,我認為目前只有兩條路可走:

  1. 依照遊戲內顯示的名稱,幫en改正錯誤的命名並且應用到zh。
  2. 採用Miemiemethod的方案。

--SkyE | Talk · Contributions · Logs 2021年2月12日 (五) 12:57 (UTC)

相關內容已經寫到en的社群專頁。--SkyE | Talk · Contributions · Logs 2021年2月14日 (日) 08:07 (UTC)
 同意Miemiemethod的方案。另外插一句,現在Java版Alpha(用戶端)裡面也有前導的"v"(現行的Alpha(用戶端)與其他的都不一樣),是不是也可以考慮去掉一下。 Anterdc99Face Anterdc99· 2021年2月14日 (日) 08:25 (UTC)
 同意Miemiemethod的方案。玩家們平時交流也就只說1.16.100.56,沒有誰會@他說他沒加beta。上wiki搜要自覺加個基岩版也就算了,問題是這樣子還是搜不到(要做基岩版後面加beta_)。版本號是拿來區分版本的,不是拿來為難玩家的。刪除beta_不但不會影響玩家的認知,而且使玩家的資料查詢變得無比便捷。Miemiemethod的方案最為直觀,玩家也不需要在標題格式上做毫無必要的猶豫。--2190303755(T|C) 2021年2月15日 (一) 15:29 (UTC)
 同意Miemiemethod的方案。但對於0.15.0和0.16.0的開發版本,遊戲右下角顯示的版本號是沒有build之類的單詞的,只顯示數字、.v,如攜帶版Alpha 0.16.0 build 2顯示為「v0.15.90.1」,我認為它應該被命名為「攜帶版0.15.90.1」,其餘類似。--RedLightPOP討論 2021年2月17日 (三) 10:39 (UTC)

手機版頁面

手機版的頁面跟之前不一樣了 發生了個什,有懶人包嗎?101.12.85.96 2021年2月12日 (五) 08:28 (UTC)

請指出具體頁面。- Olvcpr423 Oak Sign JE2 BE2 / Book and Quill JE2 BE2 2021年2月12日 (五) 13:15 (UTC)
如果你是指「手機版視圖」,請見此頁面。該功能尚在測試中,所以會有一些問題。- Olvcpr423 Oak Sign JE2 BE2 / Book and Quill JE2 BE2 2021年2月12日 (五) 13:24 (UTC)
Gamepedia職員目前已經匯入FandomMobile的CSS。部分CSS可能已經修復。-- LakeJasonFace Lakejason0) 2021年2月13日 (六) 04:08 (UTC)
什麼懶人包啊--Lxazl5770zh.admin) 2021年2月14日 (日) 23:30 (UTC)
就......懶人包ㄚ.w.--61.224.171.83 2021年2月16日 (二) 17:38 (UTC)

關於編輯的問題

請問基岩版開發版本中洞穴與山崖的更新內容屬於1.17.0還是1.16.210?編輯時應該寫[新增:BE 1.16.210]還是[新增:BE 1.17.0]?

目前wiki上大部分都是1.17.0,少部分是1.16.210(例如礦石烤羊肉)。Wangruiheng討論) 2021年2月18日 (四) 12:29 (UTC)

鑑於1.16.200的開發版中加入的洞穴與山崖特性在1.16.200正式版中不可用,結合Mojang官方人員的推文(見此),可以推測1.16.210很可能也不會實裝這些特性。所以1.16.210中加入的洞穴與山崖特性應用[新增:BE 1.17.0]標記,其他特性用[新增:BE 1.16.210]標記。--葉月 § 2021年2月18日 (四) 12:55 (UTC)

使用者頁面不見了

如題,今天在wiki瞎逛游時發現只能看到自己的使用者頁面,而他人的使用者頁面則顯示「此使用者還沒有填寫個人資料頁」,並且登出後發現自己的使用者頁面也沒了。

所以想問一下是出了啥問題(不會是大家都把使用者頁面刪了吧)

Sigma166討論) 2021年2月19日 (五) 07:41 (UTC)

已知問題,fandom正在修復中。--Snow dash & ) 2021年2月19日 (五) 08:15 (UTC)
啊好像修好了(((Sigma166/ 2021年2月23日 (二) 14:08 (UTC)

關於rd-131655(Cave Game Tech Test)之前的「版本」

rt,我認為rd-131655之前的「版本」只是一些小改動,它們根本就沒有發布給任何人,也沒有明確的證據證明它們是獨立的版本,Notch也僅僅在IRC上簡單提及了它們的改動內容,所以,我認為這些所謂「版本」根本不能算是版本。這些內容應當合併到rd-131655中,並在一個子標題中描述這些改動。順便說一下,在英文wiki中,這些「版本」的「更新」內容都已經被合併到了rd-131655的頁面中。--KisinSagume286Talk!/Contribs...) 2021年2月19日 (五) 14:50 (UTC)

 贊成。前面的「版本」介紹中只有「效能提升」,一不足以支撐頁面內容,二更像Notch在除錯程式。Sigma166討論) 2021年2月20日 (六) 00:41 (UTC)
 可以:將多個較短的頁面合併成一個頁面有利於維護。--Ultim 0 ( VIEW | TALK | CONT ) 2021年2月20日 (六) 00:46 (UTC)
 贊成,前面幾個版本頁面太短了,合併更有利於閱讀。Wangruiheng討論) 2021年2月20日 (六) 02:00 (UTC)

好的。目前已經完成對rd-131655之前「版本」內容的合併。--KisinSagume286Talk!/Contribs...) 2021年2月20日 (六) 03:02 (UTC)

Java版alpha版本「v1.2萬聖節更新」介面「歷史」條目不全

似乎這些原始版本的「歷史」條目存在這個問題,建議應完善這些內容,引入專門的模版,謝謝。(awa)--Cobalt sayori討論) 2021年2月20日 (六) 07:57 (UTC)

上傳檔案前先閱讀注意事項!--Lxazl5770zh.admin) 2021年2月20日 (六) 10:57 (UTC)

關於本人編制的「教學/征服堡壘遺蹟」能否發表到教學中

這一教學已經編制完畢,本人認為值得發表,但具體能否達到發表要求還有待商榷,也煩請大家幫忙看一下,好嗎?--Cobalt sayori討論) 2021年2月22日 (一) 04:08 (UTC)

你寫好就可以移動,實際上不需要別人的意見。--Lxazl5770zh.admin) 2021年2月22日 (一) 04:13 (UTC)
謝謝提醒,但是移動完成之後我沒有權限刪除原先介面,因此可能還需要一些調整,謝謝--Cobalt sayori討論) 2021年2月22日 (一) 05:42 (UTC)
不需要的移動殘留重新導向可以加上{{delete}},會有人處理。--Snow dash & ) 2021年2月22日 (一) 07:00 (UTC)

本人願意承擔「教學/陷阱「篇目的修改工作

有關「教學/陷阱」篇目,存在大量的不妥當因素,需要進行一系列修改。 具體原因在於:

  1. 本教學是針對於多人聯機中其他玩家的陷阱,但篇目中存在很多針對於生物的內容,這些內容對於玩家基本上沒有用處。
  2. 對於掉落物的收集,仍需要完善。
  3. 建議透過陷阱的作用進行重新排版。

謝謝大家的幫助!--Cobalt sayori討論) 2021年2月22日 (一) 06:51 (UTC)

除大量變更以外,合理的編輯不需要在社群主頁請求共識,直接編輯即可。--Snow dash & ) 2021年2月22日 (一) 06:57 (UTC)

關於21w07a中對礦物的材質變更

21w07a變更了主世界中鐵礦、金礦、煤炭和紅石的材質,是否有必要將這些修改後的材質加入到wiki條目中,或者僅僅加入相關的截圖?--Cobalt sayori=鈷子 2021年2月23日 (二) 13:58 (UTC)

加入到歷史段落。請不要在社群專頁濫發小問題(這樣會被禁言,你已經連續水了五個帖了!),請到Wiki QQ群向群友諮詢。--Lxazl5770zh.admin) 2021年2月23日 (二) 14:05 (UTC)
抱歉,但我好像已經不在wiki的qq群了,稍後我會甩一個申請到群裡,謝謝,另外,以後這些小問題我也不會再往這裡發了,謝謝。--Cobalt sayori=鈷子 2021年2月23日 (二) 14:08 (UTC)

「進度」頁面的列舉部分變更為列表

如題,論理由的話:en如此。tooltip只能在滑鼠懸浮時顯示,查看起來很不方便,也不易於複製、點擊裡面的內容。變更成列表可以方便玩家查看,同時可以查閱其中的內容。

若同意此方案的話,存在的問題是:

  • 如何插入這個列表;
  • 現在的模板在放入列表時會因「字數已達上限」出錯,需要在哪些地方最佳化這個模板。

以上。——IcyPhantom 討論I貢獻 2021年2月24日 (三) 16:25 (UTC)

 支持,列表可以以表格或html列表的形式配合{{ItemLink}}{{BlockLink}}來顯示;達到上限只能考慮拆分成子頁面,但請注意和{{load advancements}}的相容性,避免無法識別。這兩問題應該都能參考en吧?順便,嚴肅場合個人建議不要用刪除線--Snow dash & ) 2021年2月24日 (三) 16:31 (UTC)

重構{{SPConversion}}Module:SPConversion

由於簡繁的地區翻譯差異,我們有轉換表,用於自動地將文章內的詞彙更換為簡體/繁體使用者所熟悉的詞彙,以提升閱讀體驗。但是,部分詞彙轉換的使用量低,或者詞彙太長影響轉換效率,因此Leo leo 768製作了模組Module:SPConversion(模板同名)。但目前,這個模板的預設輸入是簡體文字,由於遊戲文字可能產生變化,這種輸入方案可能會導致大量不必要的變更來修復。並且據意見回饋,該模組目前的代碼品質不夠高。考慮到目前此模組主要用於來源為遊戲內文字的轉換,提出以下提案:

  • 將模板目前的匿名參數輸入改為遊戲內的本地化鍵名。使用ID有利於維護語言中立,即所有編者都可以較為方便地使用轉換,而不需要刻意的都去使用簡體文字,且本地化鍵名較為固定,可以減少因遊戲內文字變化而導致的大量改動。
  • 仍然保留|type=的同等功能參數。由於這個模組實際上也用於故事模式的轉換,而故事模式的文字實際上並不存在遊戲內id,也不可能把這些頁面內的文字全部替換成輸入id的形式(源代碼層面很影響觀感),所以仍然有必要保留。此外,部分教學頁面不存在嵌入的需求,而在頁面內反覆使用模板又很累贅,所以仍有必要保留。

此討論由Snow dashMysticNebula70和我個人在私下提出,現放在社群專頁徵求共識。-- LakeJasonFace Lakejason0) 2021年2月17日 (三) 04:00 (UTC)(最後編輯於2021年2月17日 (三) 04:09 (UTC))

我們希望將模板改為透過{{sc|本地化鍵名}}的方式調用,輸出繁簡轉換。包含字幕與統計相關字串,因此主要用在音效段落等相關位置。現有的調用使用機器人批量轉換為上述調用。
順便也會改一下模組名字,我個人認為SpecialConversion可能會更好--Snow dash & ) 2021年2月17日 (三) 04:58 (UTC)
引用本地化鍵名可能 不直觀,在語義上也不通暢,能做到英語輸入中文變種輸出是不是更方便,也可以和目前的autolink一同更新。--RealCuervo討論) 2021年2月18日 (四) 14:08 (UTC)
考慮到{{sc}}的使用場合,個人認為引用本地化鍵名並不存在太多語義上的問題。例如用量最多的音效段落,其使用方式為模板{{sound table}}的一個參數,使用本地化鍵名並無不妥。不存在鍵名的場合也不需要隨用隨調的情形,而是採取類似於-{H|...}-的方式將需要轉換的文字全部包含進來,也無需輸入英文名稱。而且使用英文名稱反而存在更新不夠及時以及維護更麻煩的問題。MysticNebula70 T  2021年2月19日 (五) 16:37 (UTC)(最後編輯於2021年2月19日 (五) 16:40 (UTC))
進度:沙盒中的Module:Sandbox/SpecialConversion基本完工,支持Java版1.16.5所有遊戲內字串,快照資料模組分開維護,有報錯分類,輸入本地化鍵名使用。但暫時還沒有頁面內全局轉換。--Snow dash & ) 2021年3月1日 (一) 09:17 (UTC)
進度2:模組已基本成型,頁面內全局轉換也加入,沒有高消耗的反查。--Snow dash & ) 2021年3月3日 (三) 12:13 (UTC)

InPageEdit使用滿意度小調查

大家好,我是小工具inPageEdit的開發者,當初自用的小外掛如今被這麼多人使用這麼多次,承蒙大家厚愛了!

為了更直觀地取得InPageEdit使用方面的意見回饋,方便後期開發維護,特此邀請ipe的使用者,耽誤大家大約3分鐘的時間,來填寫一個問卷,問卷採取匿名形式,內容絕對不會用作商業用途。

https://www.wjx.cn/vm/mtTpOXX.aspx

再次感謝大家,鞠躬。 機智的小魚君⚡ (給我留言✨) 2021年2月20日 (六) 05:25 (UTC)

儲物箱戰利品

對於儲物箱戰利品來說,Java版基岩版有完全一樣的部分(比如地獄要塞),但是戰利品部分中仍然將Java版和基岩版分開說,是否應該合併以去除重複?(但這玩意好像涉及到模板,因此我需要幫助。)Sigma166/ 2021年2月23日 (二) 07:48 (UTC)

 同意我個人認為,同樣的模版確實影響觀感,如果要修改模版的話,建議可以翻閱編輯手冊--Cobalt sayori=鈷子 2021年2月23日 (二) 07:55 (UTC)
 反對,技術問題,加判斷、修bug帶來的人力消耗換來的只是合併表格,非常不划算。--Snow dash & ) 2021年2月23日 (二) 08:46 (UTC)
額人力消耗嘛……我倒是可以找時間搞(可是我不會啊啊啊——)那就等我會了再說吧Sigma166/ 2021年2月23日 (二) 14:13 (UTC)
 拒絕——根據現有{{LootChestItem}}模組代碼,不能實現Java版和基岩版分開。重構是一件非常麻煩的事情。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:20 (UTC)

各個版本「修復」部分中的連結

在本wiki的各個版本介紹頁面中,有小部分頁面在「修復」部分加入了連結(比如18w43a12w06a),而大部分頁面並沒有。本人現有如下想法,並徵求大家的意見:

  1. 所有版本介紹頁面中的「修復」部分添上連結(艱巨的任務)
  2. 所有版本介紹頁面中的「修復」部分刪去連結(為保持一致並減少工作量)
  3. 不做改動,保持原狀(省事是省事,就是看著彆扭)

個人 支持1,在「修復」部分加入連結有利於讀者更便利地了解該版本修復的內容。

帶著興趣直接跳轉到一個子段落的讀者必須依然能找到一個連結。

Sigma166/ 2021年2月26日 (五) 00:52 (UTC)

你說的連結是指訪問官方錯誤追蹤器的連結嗎?但是我點進去18w43a的連結只會顯示「No issues were found to match your search」,毫無用處。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:17 (UTC)
不不不,就是最普通的內鏈([[xxxx]]的形式)。Sigma166/ 2021年2月26日 (五) 01:21 (UTC)
這個任務可能相當的艱巨,因為需要補充的連結太多,而補充連結的過程也相當麻煩,個人 支持2--Cobalt sayori=鈷子 2021年2月26日 (五) 01:25 (UTC)
快照少的也有兩三個錯誤,多的可能有二三十個--Cobalt sayori=鈷子 2021年2月26日 (五) 01:26 (UTC)
可加可不加,要好好利用頁面頂部的搜尋欄。但是要記住插入過多內鏈是不允許的(斑駁的顏色導致閱讀問題)。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:28 (UTC)

因為最近我一直在做錯誤列表相關工作,所以我來說明一下具體情況:

  • 一般來講,最近依據錯誤補全計劃補全的(我編輯的)並且使用了fixes模板的錯誤列表,列表全文一般沒有連結,有連結的屬於少數情況。
  • 較老的列表(1.4以前)的,一般都有。當然這是從英文wiki帶過來的情況,所以我在翻譯的時候也保留了這些連結。
  • 還有一些以前其他貢獻者翻譯的內容,其實存在大量這樣有連結和無連結混合的情況,還有模板使用不正確的問題(就比如Lxazl577018w43a遇到的情況一樣,是fixes模板使用不當導致的)。

至於你提出的選項,我個人 支持2或者是3。因為如果要全部加上的話,少說幾百個版本頁面中的內容都要修改。
且大多數版本中修復的錯誤大約有30-40個,甚至多的會有70+,另外還要算上主要更新版本(例如:Java版1.8),這些版本的錯誤修複列表往往非常巨大,這是由於這樣的頁面需要合併所有開發版本中的內容導致的。
所以在做加入連結的工作前,建議先考慮好這樣是否合算。 Anterdc99Face Anterdc99· 2021年2月26日 (五) 02:04 (UTC)(最後編輯於:2021年2月26日 (五) 02:05 (UTC))

經過本人思考,認為1的確過於艱巨,2更現實一些。但若採用2的話是否應在格式指導中說明?(另外我因為開學難以繼續編輯,這事還需大家幫助,謝謝!)Sigma166/ 2021年2月28日 (日) 10:22 (UTC)

關於引用進度的標準

昨天有人在說這個事。因為進度本身的判定有著比較具體的目標,所以昨天寫了個引用標準的草稿:https://pastebin.com/k3Bpah0m

所以就是:

  • 是否有必要對進度引用提供一個標準;
  • 這個草稿內有無可能需要改進的地方。

以上。——IcyPhantom 討論I貢獻 2021年3月18日 (四) 14:18 (UTC)

個人認為按照共識去進行整理即可,並不需要刻意去編寫標準(因為這個只是頁面內容的一小部分罷了)。--Lxazl5770zh.admin) 2021年3月25日 (四) 08:52 (UTC)

新增關於字詞轉換的說明頁面

寫了一個關於字詞轉換的說明頁面,見此(修訂版本連結)

設立這個頁面的主要目的是為了讓想幫忙參與轉換表/字詞轉換建設,或者只是一般讀者的繁體使用者能夠更明確地明白本wiki的字詞轉換方針。另外,也可以以這個頁面為基礎,完善現有頁面(尤其是標準化相關的)對繁體的說明。目前標準化頁面沒有明確提及「本wiki頁面源代碼內的名稱以簡體中文的實際核定情況為準」的相關明確語句,可能還是會導致繁體人士編輯時的迷惑。此外,目前wiki上沒有從簡繁體的核定速度等情況出發作「為什麼wiki優先套用簡體翻譯」這類問題的簡單說明,雖然我知道wiki儘可能保持語言中立,可能出於這個原因沒有明說,但是個人認為明說更有利於和繁體讀者溝通,提升更多人的閱讀體驗。

此外,這個說明頁面的關注度可能需要手動提升,不僅需要放在繁體中文問題報告和相關Navbox裡面,可以的話我希望在Sitenotice裡面在「請以遊戲內為準」那一行也加上到這個說明頁面的連結。

這個頁面的內容我已經提前提交給一部分本地人看了看,收集了一部分修改意見,現放在社群專頁以獲得進一步的共識與建議。-- LakeJasonFace Lakejason0) 2021年3月20日 (六) 17:09 (UTC)(最後編輯於2021年3月25日 (四) 08:28 (UTC))

 支持可以放到sitenotice。--Lxazl5770zh.admin) 2021年3月25日 (四) 08:57 (UTC)

頁面已建立,見Help:字詞轉換。 LakeJasonFace Lakejason0) 2021年3月25日 (四) 15:24 (UTC)

推進。希望管理員能寫一下Sitenotice。-- LakeJasonFace Lakejason0) 2021年4月23日 (五) 18:41 (UTC)

愚人節

不如4月1日的時候開啟一次非官方文章,並於4月2日無封鎖提刪--119.237.10.81 2021年3月31日 (三) 06:41 (UTC)

 拒絕可能你不知道Java版2.0這個玩笑在n年前就開過了。--Lxazl5770zh.admin) 2021年3月31日 (三) 10:49 (UTC)
好吧--119.237.10.81 2021年3月31日 (三) 11:34 (UTC)

製作了總討論頁的頂端目錄

本人製作了用於總討論頁的頂端目錄,可以方便的查看目前存在的論題及相關資訊,具有多種的標記功能(功能一看就懂就不贅述了),效果如下。

如覺得不錯可考慮應用於Minecraft Wiki:社群專頁Minecraft Wiki:管理員告示板的header中。--Star Zero · 維基假期中 2021年4月3日 (六) 07:13 (UTC)

 問題:就目前來看此模組仍存在較多影響正常使用的問題,因此暫持保留意見。MysticNebula70 T  2021年4月3日 (六) 07:53 (UTC)
問題已全部解決。--Star Zero · 維基假期中 2021年4月4日 (日) 04:05 (UTC)
根據你的成果重寫了模組,如測試無問題且無異議即可將其轉正。MysticNebula70 T  2021年4月4日 (日) 13:36 (UTC)
感謝貓貓的協助。--Star Zero · 維基假期中 2021年4月6日 (二) 14:42 (UTC)
另此模板還需要修改討論透過論題後的顏色,原透過模板背景顏色與24小時內更新顏色不易區分。--Star Zero · 維基假期中 2021年4月6日 (二) 14:42 (UTC)

提議修改格式指導,以及再次更新Message box樣式

下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 同意更新


目前中文wiki的msgbox是放在infobox之後的,這並不符合大多數wiki的主流布局。我建議按照多數wiki的做法來,先msgbox然後infobox,並修改格式指導。

然後,目前的msgbox樣式不能適應以上的調整,需要相應修改。大致需要變更的內容有:

  1. 將所有非mini的msgbox統一寬度;
  2. 增加msgbox的外邊框;
  3. 兩個相鄰的msgbox取消間隔;
  4. msgbox內的文字改為左對齊。

另外,msgbox可以使用預設的顏色(目前有7個:red、​orange、​yellow、​green、​blue、​purplemagenta),以不同的顏色表示不同類型的資訊(如紅色表示需要立即執行的操作,橙色表示頁面有內容方面的問題,等等),同時仍然支持自訂顏色。

此處可以預覽新樣式。

現在此徵詢社群的意見。MysticNebula70 T  2021年4月16日 (五) 12:24 (UTC)

 支持。不過和英文的差別還是很大,和正經Ambox的差距倒是很小。-- LakeJasonFace Lakejason0) 2021年4月16日 (五) 14:07 (UTC)
大部分 支持。只不過那個灰色的border我不大喜歡。-- Dianliang233 TC 16 2021年4月16日 (五) 14:11 (UTC)
需要修改的還有消歧義模板。正常的順序為消歧義-訊息框(msgbox)-資訊框(infobox)。
對於預設顏色,我建議使用type(模式),每個模式對應一種顏色,然後選擇模式。以及我個人建議不同命名空間設定不同樣式。
對於文字左對齊,我認為現在mcw的訊息框寬度太小了,居左可能不太好看,如果要居左最好寬度拉長點,視具體情況而定。--Star Zero · 維基假期中 2021年4月16日 (五) 14:12 (UTC)
 支持,預覽看著不錯。不過調換很多頁面的順序確實是個很麻煩的工作。。--Snow dash & ) 2021年4月16日 (五) 14:14 (UTC)
 同意,新樣式挺好看--Lxazl5770zh.admin) 2021年4月16日 (五) 15:35 (UTC)

目前有部分成員提出不加入灰色邊框。對此條建議有其他看法的請在此回復。MysticNebula70 T  2021年4月17日 (六) 11:33 (UTC)

移除了灰邊框,效果請自行對比。MysticNebula70 T  2021年4月20日 (二) 10:28 (UTC)

預設顏色的用途

各個預設顏色的使用場合是什麼?有關想法請在此提出。對配色本身有意見也在此提出。MysticNebula70 T  2021年4月17日 (六) 02:26 (UTC)

忽然才意識到這些配色在我的顯示器上很素,很暗。如果改的更亮一點呢?-- LakeJasonFace Lakejason0) 2021年4月17日 (六) 03:40 (UTC)

目前英文wiki選取的顏色用途:

  • red:disclaimer和提刪;
  • purple:建議頁面移動、拆分、合併;
  • orange:頁面存在內容問題;
  • yellow:頁面存在格式問題;
  • green:標記頁面的其他狀態(例如是stub、正在編寫中);
  • blue:標記版本相關(例如版本獨有、將在下個版本加入);
  • magenta:未使用/自訂。

以上內容可供參考。

另:若按照type來選取顏色,則仍然需要確定一些預設的type用來對應顏色。如果同意使用type,可在此提議type。MysticNebula70 T  2021年4月17日 (六) 11:43 (UTC)(最後編輯於2021年4月17日 (六) 12:31 (UTC))

 建議:新增顏色gray,用於表示丟失(如{{Lost version}}{{Lost pre-reupload}})、未發布(如{{Unreleased}})或者可能不存在(如{{Unproven}})的版本。--Ultim 0 ( VIEW | TALK | CONT ) 2021年4月17日 (六) 12:21 (UTC)(最後編輯於2021年4月17日 (六) 12:39 (UTC))
這樣的type咋樣:
  • red->important
  • purple->pageaction
  • orange->problem
  • yellow->notice
  • green->pagestatus
  • blue->version
-- LakeJasonFace Lakejason0) 2021年4月17日 (六) 12:44 (UTC)(最後編輯於2021年4月17日 (六) 12:45 (UTC))
 不認可:都不怎麼樣,行為和程度混雜,單詞和雙詞混雜,而且和用途不搭,建議全部重定。--Star Zero · 維基假期中 2021年4月19日 (一) 01:40 (UTC)
建議方案:
類型(顏色) \ 命名空間 條目命名空間 檔案命名空間 討論命名空間
delete(red) 請求刪除
move(purple) 移動、拆分和合併 移動和重新命名 合併,拆分和重新命名
content(orange) 內容問題 嚴重警告和問題 大部分警告和提醒
style(yellow) 格式問題 較輕警告和問題 較小警告和提醒
protection(grey) 保護
version(blue) 版本 \ \
notice(default) 條目注意 注意 通知和訊息
Star Zero · 維基假期中 2021年5月4日 (二) 10:43 (UTC)
建議補充green,用於標示正在進行的工作以及未完成的頁面。--Ultim_0 ( USER | TALK | CONT ) 2021年5月4日 (二) 10:54 (UTC)
修改版本:
類型(顏色) \ 命名空間 條目命名空間 檔案命名空間 討論命名空間
warning(red) 警告訊息和請求刪除 請求刪除
move(purple) 移動、拆分和合併 移動和重新命名 合併、拆分和重新命名
content(orange) 內容問題 嚴重警告和問題 大部分警告和提醒
style(yellow) 格式問題 較輕警告和問題 較小警告和提醒
protection(grey) 保護
version(blue) 版本 \ \
status(green) 狀態 \ \
notice(default) 條目注意 注意 通知和訊息
Star Zero · 維基假期中 2021年5月4日 (二) 11:33 (UTC) (最後編輯於2021年5月4日 (二) 11:35 (UTC))
模板已更新,各用到msgbox模板的模板需要單獨更新。MysticNebula70 T  2021年5月4日 (二) 13:28 (UTC)

是否應加入有關盔甲工具的重新導向

我最近在Wiki上進行某些條目的翻譯工作時,想使用和en一樣的重新導向(比如說[[Diamond Armor]][[Iron Armor]],均會被重新導向到[[Armor]]),但是發現中文Wiki除了皮革盔甲之外沒有其他相關的重新導向了。

如題,加入的理由有如下:

  1. 某些編輯者可能更傾向於輸入[[钻石盔甲]]而非[[盔甲|钻石盔甲]]
  2. 一些初來乍到的編輯者對Wiki是否有這樣的重新導向不熟悉,可能會直接輸入[[钻石盔甲]];發現Wiki上沒有這樣的重新導向之後,為了方便此編輯者可能會輸入钻石[[盔甲]],這樣不符合部分讀者的習慣——他們可能會在看不清楚的情況下點擊「鑽石」而非「盔甲」。

綜上,我認為有一定的必要加入相關重新導向,現在此提出意見,徵求社群的共識。--AblazeVase69188討論 | 貢獻) 2021年4月23日 (五) 14:18 (UTC)(最後編輯於2021年5月1日 (六) 03:55 (UTC))

如果需要的話,您可以自行加入重新導向。MysticNebula70 T  2021年4月23日 (五) 14:31 (UTC)
 支持 這種確實對新手會產生困擾,我以前也體會過hhhhh Yfohdit討論) 2021年4月23日 (五) 17:46 (UTC)

相關重新導向已全部建立,如有異議請在此提出。--AblazeVase69188討論 | 貢獻) 2021年4月30日 (五) 15:15 (UTC)

深層綠寶石(銅、煤)礦石的相關解釋需要改嗎?

如題,21w17a的資料包中已經可以生成這三種礦石的深層變種,但資料包的更新內容需要和正式更新內容一起寫嗎?--Minesunset1030討論) 2021年4月30日 (五) 22:15 (UTC)

資料包的內容不大可能和常規內容共存,因為它已經不屬於原始玩法。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:56 (UTC)

修改Minecraft Wiki:管理制度

背景

中文Minecraft Wiki現行與過去的管理員選舉機制存在明顯錯誤和缺陷,為某些圖謀不軌的管理員施行專政封閉的管理提供了可乘之機。幾年前發生過的反pow團隊割裂現象,推進了管理制度的制定。但是,它反而成了管理員濫權的工具。因此,有必要重定管理員選舉制度,主要是管理員與巡查員的產生辦法。

原因
  • Minecraft Wiki:管理制度中所規定的「行政員保留無理由撤銷管理層職務的權利」」在職務到期時由行政員根據其表現決定是否刷新和延長時限」「不多於n名在職管理員對其就職提出反對」「3⁄4以上的在職管理員認可其對Wiki的貢獻。」使管理員可以「欽定」管理員、巡查員的就職和任免,嚴重違反了wiki社群共識高於一切的基本法。
  • 現今中文wiki社群環境已經成熟,共識系統可以確立,「人少」「效率低」已不是藉口。
修改辦法

Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。請善用比較功能查看差異。修改內容主要有:

  • 全面擯除專制選舉的陋制
  • 加入管理員投票選舉制度和巡查員符合要求即授予制度
  • 提高了巡查員和管理員的要求
總結

這是社群從選舉層面堅持和完善社群共識制度體系、確保wiki長治久安的必要之舉,充分體現了正當性和進步性。相信透過選舉制度的完善,Minecraft Wiki一定能夠走出長期存在的「專制泥沼」,集中精力完善內容、添磚加瓦,再創發展奇蹟。僅代表個人,不代表Fandom意見。希望得到各位的支持。-- Dianliang233 TC 16 2021年5月5日 (三) 03:14 (UTC)


應當事人要求就此摺疊上述討論。--Lxazl5770zh.admin) 2021年5月10日 (一) 14:27 (UTC)


利益不相關:作為非本維基管理組,透過我在WP的認知和我在某維基擔任主要管理者的經驗來談談維基中的民主體制。
聲明:本人不清楚本維基管理層情況,請根據實際情況實行。
引子
目前來說,對於社群民主實踐最深的維基網站來說,毫無疑問是維基百科,在維基百科中有著這樣的描述:

(是否是管理員)不應該有什麼大不了的。

——吉米·威爾士

管理員沒有任何高於其他使用者的特權,唯能實現社群討論所得的共識。

但是這並非所有維基都要遵循這樣的理念,因為每個維基的現狀不同,維基百科有著獨特的實踐條件(後文會提及),重新引用上面的引用語:

wiki不是可口可樂,不是全世界的wiki都有一樣的制度

——某位使用者
上面的討論,我認為過多的使用了其他維基的條文來討論「制度應該是怎麼樣的」,我認為不必過多的參考其他維基,而是從實際情況出發,我簡要的談談實際情況中我的認知。
維基百科具有以下的條件:
  • 維基百科編者眾多
  • 編者具有社群選舉的參與度
  • 編者有相關的選舉觀念
而到了本維基,我們就不得不思考以下幾個問題:
管理組的人數是否需要控制?
毫無疑問是需要的,基於一個社群中管理員適宜的占比以及上文提到的「拉幫結派」原因,管理員應該被控制在一個數量。
上文電量量有說到社群會自己控制管理員的數量,但是:
我們的編者是否對於管理員選舉有認知?
本維基沒有維基百科長期的民主政治歷史,因此本維基的編者真的有充分對於「一個人是否應該成為管理員」的認知嗎?相反,由於社群較小,社群中的編者大都互相認識,由於關係親近,對於相熟的人自然會帶有自己的偏移,給予更放鬆的透過條件(比如說大家對於界管權限的認知)。
以目前Mcwiki的社群討論環境,很有可能會發生上面的情況,且大部分社群成員對於管理員上任的重要性可能沒有概念,不參與或盲目投支持票,而不考慮社群是否需要更多管理員,管理員和社群考慮的方向是有區別的,再者:
我們編者的人數真的足夠進行透過民主投票,表現社群真正公正的共識嗎?
實際上,維基百科由於其編輯者的眾多,進行投票的人數非常廣泛,而我們維基進行投票會有多少滿足條件的編者參與社群投票?
電量量說「社群條件已成熟」,而我從我這段時間的觀察來說可能未必,況且是滿足條件的編者,比如,現在發投票,能有20個人參與嗎?
如果參與投票的人數沒有達到一定規模,那麼投票的結果就無法反映社群意見,而可能會發生上文提到的「傾向性投票」。依據現狀,很有可能沒有足夠的人參與到社群討論投票中,導致投票結束無限拉長。
我們真的需要完全民主嗎?
綜上所述,Mcwiki完全改制可能還為時過早。讓我們思考以下,目前的寡頭制管理組織形式真的很不堪嗎?當然不是,寡頭制管理有效率高等優點,社群也有足夠的空間進行民主討論,但最大的問題是寡頭制過於依靠幾位管理者的道德品質與個人能力,可能會導致濫權的發生,因此要考量的是:管理組現在真的有存在濫權專制的現象嗎?這就要看本維基具體情況了。
最後
其實我個人是比較欣賞社群民主體制和電量量的改革精神,我自己在管理的維基也進行過多次這方面的改革,但是這可能不太符合實際情況。
我本人對本提案不持有立場,內容僅供引發思考,也望電量量放下立場,思考這些內容是否合理。
我個人認為現階段不必操之過急,不必直接使用投票制度而是逐漸加入管理者的限制,減少可能使管理人專制的條件,將權利逐漸分散到社群中。
另:如果巡查員要改為即授予制,可能要選擇降低一下巡查員的權限,目前權限確實有點超過使用者群組應有的權限。
Star Zero · 維基假期中 2021年5月8日 (六) 09:56 (UTC)
 同意Star Zero的觀點。之前我考慮不周,盲目地表達自己觀點。中文Minecraft Wiki的社群環境確實不夠成熟,而且目前管理層濫權的可能性也不大,個人認為現階段的任務應該是努力發展Wiki與其社群成員。由於我個人對本wiki的深層和歷史情況也不是非常熟悉,所以持 中立態度。
不過我覺得適當提高對進入管理層的使用者的要求也是合理的,但我認為沙盒中的管理制度上變更的要求未免有點高了,例如對巡查員的要求「在中文Minecraft Wiki的編輯記錄達600條以上」以及對管理員的要求「在中文Minecraft Wiki的Template(模板)命名空間編輯記錄達100條以上」。--AblazeVase69188· 2021年5月8日 (六) 13:06 (UTC)
我不知道我應該做出什麼評價。
少打一點感嘆號,少打一點問號,少打一點粗體。能正常說話就不要寫那麼多反問句。不要讓越來越強烈的語氣演變成咄咄逼人的攻擊性。
這個話題崩潰的一塌糊塗,上頭了的話就應該先去洗把臉清醒一下。--Magnussiiftun1857[T/C/E] 2021年5月8日 (六) 11:18 (UTC)(最後編輯於2021年5月8日 (六) 11:20 (UTC))
 支持EPIC! MC中文wiki的毒菜問題也不是一天兩天了,不徹底根治的話只會持續發酵下去,沒個好的,加速編者流失。不過毒菜問題真的能靠自下而上的提案讓毒菜結束嗎?--Kaniol233討論) 2021年5月8日 (六) 14:35 (UTC)
 意見

肉食者謀之,又何間焉?

——《左傳》
私之棲於Minecraft Wiki,尚不足期年,箇中條例,猶有不通,故 不予置評。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 15:34 (UTC)

以下部分段落文字,移動自管理員告示板

對「修改Minecraft Wiki:管理制度」話題的回應:

首先,懇請大家先了解一點:不是所有事物都是非黑即白(binary)的。
眾決沒錯,但是要依情景而論
對於眾決好不好,對效率有何影響,政治科學、管理學、組織行為學等都有涉及,知乎之類也有很多高論,我才疏學淺不敢高談闊論。但是我想簡單引用弗雷德·菲德勒權變理論來解釋我上述的這個論點。簡要地說,工作結構的不同,需要採取不同的職務權力才能達成合適的效果,而沒有完全眾決一定是最好的簡單的非黑即白的說法,否則上述幾個學界的研究者恐怕也沒有存在的必要了。當然在Wiki裡行政員和管理員也都應該是普通的編輯者,不過我想在一定程度上進行仲裁對於日常運作還是有必要的。
中文Minecraft Wiki已經非常開放
就拿英語Minecraft Wiki來說,據我所知沒有任何管理員推舉公示的制度,而英語Wiki的規模少說有中文Wiki的10倍。本wiki上全保護頁面也已經儘量減少,就連首頁也有部分片段可以開放給所有註冊使用者編輯,這一點上就算不是絕無僅有也是非常少的。之前的Wiki條例修訂,也經過了公示諮詢,絕對不存在哪個行政員、管理員一手遮天的情況
所有編輯者都是善意的,包括管理員
提出修改管理制度也是為了Wiki的良好發展才做出的,這一點我願意相信。但是可否請大家也相信管理員有自己的堅持也是為了Wiki的良好發展?在這裡我想稍微辯護幾句,對Wiki最惡意的人最該做的就是不來編輯(請不要把這句話反過來理解,編不編輯是個人的自由),而不是參與在其中「浪費」自己的時間,能參與討論的,已經都是非常關心Wiki的同好了。如果大家都能有這個前提的話,我相信交流當中也會少一些矛盾。
之後的安排
我們會討論修改管理制度,同時行政員、管理員的組成也會再加考慮,請各位耐心等待。
--一名編輯者RealCuervo討論) 2021年5月9日 (日) 08:47 (UTC)
我想說的話大體上已經在編輯者QQ群裡說完了,我在這裡順便補充一些需要了解的東西:WP:DEMWP:POLLWP:BATTLEGROUNDWP:FAITH。--Lxazl5770zh.admin) 2021年5月9日 (日) 09:32 (UTC)
補充一張《反駁金字塔》圖,作為鎮樓用途。
Graham's Hierarchy of Disagreement

格雷厄姆的反駁金字塔

--Lxazl5770zh.admin) 2021年5月9日 (日) 14:07 (UTC)
感謝管理的真誠回應。其他的就不多說了,決裂過的人也沒必要再挽回了。-- LakeJasonFace Lakejason0) 2021年5月9日 (日) 10:23 (UTC)
這裡指的不是電量。我甚至都不認為哪一個(只有一個例外)決裂的人是因為wiki事務才決裂的。-- LakeJasonFace Lakejason0) 2021年5月9日 (日) 10:24 (UTC)(最後編輯於2021年5月9日 (日) 10:38 (UTC))
討論及決定的不是管理組,是社群本身,即本討論。--Star Zero · 維基假期中 2021年5月10日 (一) 14:18 (UTC)
對於Cuervo/a2的發言我就不用說太多了;因為已經很久沒有在這裡編輯過了,又因為每一次出現都能被說是舊病復發,我知道我沒有多少發言權。關於管理員(此處尤其指某位行政員)是否能夠一手遮天的問題,我想有過遭遇的自然會知道答案。如果中文 Minecraft Wiki 真的能夠做到長久以來虛無的「皿煮」的話,那我就在幕後為你們的成功慶祝吧。另外,好像看到有一名馬迷成功上任了管理員,這個也一定要祝賀一下,這是墜吼的!
Minecraft Wiki Anti-* Safe House. --SkyFuInMC (DI/CO) 2021年5月27日 (四) 14:46 (UTC) from Onion Network

指令描述頁面,把「示例」挪到「效果」與「輸出」之前

本主題或以下段落文字移動自MCW:管理員告示板

如題。

目前指令介紹頁面的格式大致是:語法,參數,效果,輸出,示例,歷史。

對於一條指令,想要查找資料的初學者,示例顯然比輸出更重要。把示例往上放到參數下面應該更好,這樣也便於閱讀者對比示例中的例子用到了上面的什麼參數。

如:/clear

請自行用預覽功能嘗試

在讀示例的時候會輕鬆很多,去對比參數與語法。

en版是把示例示例放最後了?算了跟我們無關……我是覺得改一下更好--Dahesor討論) 2021年6月7日 (一) 20:21 (UTC)

「應由大眾討論的事項請布告於Minecraft Wiki:社群專頁。」--Snow dash & ) 2021年6月8日 (二) 00:16 (UTC)
 贊同:明晰而立竿見影的案例比晦澀且難以理解的說教更具動力。
 收回前言:案例固然重要,但不是指令子頁面的必需。--Ultim_0 ( USER | TALK | CONT ) 2021年6月8日 (二) 03:59 (UTC)(最後編輯於2021年6月8日 (二) 05:13 (UTC))
 反對。本來就是給指令提供參考的頁面,對於初學者來講是上面那麼回事,其他人呢?針對不太依賴示例的人來講,確認指令的輸出更實際點。而且我也沒見事情本身的特性沒解釋完就寫例子的玩意,真那麼寫的多半都給人一種莫名其妙編排混亂的感覺。至於對比,我覺得開MC手寫指令去對比更實際點,而且實踐一直都是學習的方法之一。順帶提一句,指令介紹頁本身就不是放教學的地方。——IcyPhantom 討論I貢獻 2021年6月8日 (二) 04:35 (UTC)
 資訊依我薄見,還是示例更重要。這不是教學不教學的關係。隨意點進該頁面的讀者在看完參數後顯然更需要示例,而不是深入才會涉及到的,詳細的效果表,或是只有用execute store才會涉及到的輸出。對於有興趣者當然會自己下滑,特地要查找資料的讀者也自然會尋找。還有我不認為這會造成編排錯亂。Wiki是必經給人看的資料,沒必要一定照標準。綜上,我 +堅持己見,將示例挪到參數之後,或至少,將示例挪到效果之後,輸出之前。--Dahesor討論) 2021年6月8日 (二) 05:21 (UTC)
 反對。首先明確「指令」下面的子頁面是手冊頁性質的,而不是教學性質的。而無論什麼手冊頁,示例都是放在最後,或者乾脆不放示例。
就比如,在runoob上描述函數的順序就是「描述」(對應「導言」),「聲明」(對應「語法」),「參數」,「回傳值」(對應「效果」和「輸出」)和「實例」(對應「示例」)。
在man7(甚至沒有示例)或者其他地方的類似內容基本也是同樣的順序。
另外,我 同意IcyPhantom的意見。-- Anterdc99Face Anterdc99· 2021年6月8日 (二) 04:51 (UTC)(最後編輯於2021年6月8日 (二) 04:58 (UTC))
 這是壞的,因為抄示例不會讓新手變的更強……雖然大部分新手很可能沒有耐心看完語法。嘛,也算是一種矛盾,本來之前準備寫如何閱讀指令相關頁面的教學的,但是不太好寫就咕了,嗯。以及個人意見,新手要用好指令頁面,絕不應該一上來就往示例裡面看。-- LakeJasonFace Lakejason0) 2021年6月8日 (二) 05:23 (UTC)
順便我們有一個東西叫做目錄,如果新手想看的話完全可以直接點目錄就是。雖然我們都知道就算目錄擺在那裡我們也一次都不會點(真是矛盾)。-- LakeJasonFace Lakejason0) 2021年6月8日 (二) 05:28 (UTC)
 反對。不管是技術類教科書還是指導書還是其餘的手冊/教學性質的文字,都只有兩種排版方式:1. 根據示例來講效果;2 列舉效果最後放個例子。MCW的指令子頁面很明顯不適合第一種(第一種的頁面應該歸到教學的子頁面)。對於初學者不想看「效果」與「輸出」的話可以直接跳到最後看示例,但是根據內容完整度或連貫度來看,示例不應該提前。(我甚至想把示例直接刪掉)。——方法放寒假 (Talk - Contributions) 2021年6月8日 (二) 05:24 (UTC)
 留言。好吧,那既然大家都反對,我就放棄辯論啦--Dahesor討論) 2021年6月8日 (二) 05:32 (UTC)

關於「你知道嗎」段落的規範化

目前「你知道嗎」段落內容泛濫,是時候要加以規範了。這是en搬運來的格式指導,不知各位的意見如何。--Lxazl5770zh.admin) 2021年6月8日 (二) 15:48 (UTC)

 支持,這個指導內容很詳細明確。--Snow dash & ) 2021年6月8日 (二) 15:50 (UTC)
 提醒:這些格式指導的內容與MCW:SG/F#你知道嗎大致相同,只是未見規範效果。--葉月 § 2021年6月8日 (二) 15:56 (UTC)
已經有了????那沒事了--Lxazl5770zh.admin) 2021年6月11日 (五) 06:06 (UTC)

fandom INTERNAL_SERVER_ERROR, 500

我之前在試用wiki的新外觀fandomDesktop,發現參數設定裡還有第三個外觀,是mobile開頭的。 選上這個外觀然後儲存設定之後,就再也打不開Minecraft wiki了,任何頁面都是500錯誤,只好透過清除cookie解除登入狀態才能打開wiki。現在我重新登入後依舊是提示500。fandom什麼時候能修復這個bug?有沒有什麼臨時的解決方案(除了退出登入以外)?--207.180.203.231 2021年6月10日 (四) 17:10 (UTC)

終於找到解決辦法了,在網址後面加上 ?mobileaction=toggle_view_mobile 之後就能進去了。fandomsb --(和上面是同一個人的)145.239.77.243 2021年6月11日 (五) 00:54 (UTC)
Advertisement