close關閉
歡迎來到新Minecraft Wiki！查看遷移通知
引用本Wiki內容時務必註明出處。

遷移帳號 | 轉載須知 | 說明目錄社群專頁 | 管理員告示板 | 回報繁體中文問題QQ | 微博 | Discord

Minecraft Wiki:社群專頁/存檔8

出自Minecraft Wiki
跳至導覽 跳至搜尋
該頁面是Minecraft Wiki:社群專頁的存檔頁，請勿在此發布新的討論。

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

存檔

重新規劃生物分類

由於生物分類異常混亂且缺乏規則，我一點時間整理了這些內容。然而，介於這是一個不小的變動，對先前分類方式的完全顛覆，我希望在大動干戈之前能夠先取得社群共識。

草稿已經提交至沙盒，包含對生物條目和{{Entities/content}}的更改。

這個變更的主要內容是將生物分類由被動型/中立型/敵對型這三大類改為友好生物/敵對生物這兩類，拋棄中立型類別並將其中的生物送入前兩個大類的子分類。

如果達成共識，那麼所有生物條目的infobox內的生物類型也會更新，並且在這一方向將不再與En看齊。--Magnussiiftun1857[T/C/E] 2021年4月5日 (一) 07:29 (UTC)（最後編輯於2021年4月5日 (一) 13:24 (UTC)）

意見：支持 支持對生物分類進行變更，意見：反對 較反對全部改變到新分類方式。先不論文章實際內容（因為反正總得有個標準），拋棄中立型合併到其他類別的變更會給讀者造成直覺阻礙。雖然很多頁面都要說「中立型和敵對型」，然後再去除中立型裡面的動物，確實造成了表意贅餘，但是除了這種贅餘之外，是否還有更多需要改動的必要？
此外，兩個分類方式是否有原始碼層面的依據？目前的提案應該是來源自聲音事件分類，但是這似乎不能說「就和原始碼層面對Mob的處理」完全一致。如果有人能基於某一套反混淆（我建議yarn或者Mojmap）給出相應的依據，我覺得會更清晰一些。--  Lakejason0（論•功） 2021年4月5日 (一) 07:41 (UTC)
意見：支持 支持。和英文的一位編者討論了這個問題，實際上目前沙盒內的方案（也就是先歸入友好/敵對大類再歸入行為小類的方法其實很好地消除了歧義（但是在文章內需要把兩個分類都寫上去不然歧義就變大了）。目前的一個問題是如何讓讀者適應這個變化。--  Lakejason0（論•功） 2021年7月31日 (六) 00:47 (UTC)
意見：疑問 問題：友好生物/敵對生物如何判定？這只能主觀判定吧。-- Dianliang233 T•C https://static.wikia.nocookie.net/zhwikia/images/c/c5/PVT_wordmark.png/revision/latest/scale-to-height-down/16 2021年4月5日 (一) 08:33 (UTC)
per myself，根據sounds.json內的聲音事件類別。--  Lakejason0（論•功） 2021年4月5日 (一) 08:37 (UTC)
標準的選擇其實相當多……不過我傾向於，將是否被進度「怪物獵人」和「資深怪物獵人」追蹤，視為目前的決定性標準。
實際上，友好生物和敵對生物分類的內容來自先前的被動型和攻擊型，區別只有多了原本歸類於中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)
關於區分友好生物和敵對生物，遊戲裡本身也分不清楚（比如可以蜇人的蜜蜂屬於友好生物，豬布林屬於敵對生物，北極熊在Java版算友好生物在基岩版卻算敵對生物），所以我個人還是贊成保留現有的區分方法。--Lxazl5770zh.admin（論 ▪ 功） 2021年4月13日 (二) 02:51 (UTC)
意見：支持 現有分類方式確需改進意見：反對 不建議這樣更改。很多讀者可能已經習慣了現有的分類方式，這樣更改會使一些人難以接受。我認為基於現有的分類方式上進行合理的更改會更好。--Endearing Cat（討論） 2021年4月15日 (四) 13:55 (UTC)
現有分類的問題就在於他的最外層本身具有ambiguity，因為單純的「非完全敵對」不能完全概括生物行為。--  Lakejason0（論•功） 2021年7月31日 (六) 00:56 (UTC)（最後編輯於2021年7月31日 (六) 00:57 (UTC)）

重寫LootChest模組

本人受中文McWiki管理員邀請，重寫LootChest模組，原模組有以下問題：

  1. 程式碼雜亂，嚴重過長
  2. 資料結構複雜，維護困難
  3. 執行效率低

雖然原義只是修改後端程式碼而不動前端顯示效果，但基於以下原因，我也一併進行了重構：

  1. 原模組生成的表格過長，對於大表較難對應左邊和上面的標尺。
  2. 原模組生成表格將不同結構合併為一張大表，導致浪費空間多。
  3. 移動端顯示效果差。

因此我預計進行以下更改：

  1. 將資料儲存方式更改為原檔案的格式（JSON）,其他運算全部在模組內進行，不需要人工進行編輯。
  2. 提高了模組執行效率，從而可以一次性生成全部結構的表格，不需要儲物箱戰利品載入多個頁面的形式。
  3. 對於前端輸出顯示效果，一個結構輸出一個表格，透過flex布局的形式進行合併，從而最佳化查找資料方便程度和移動端顯示效果。

目前重寫後的模組存在以下問題：

  1. 由於拆分table的原因，雖然提高了查找效率，但表格不對齊對於觀感有部分破壞。
  2. 由於重寫為非人工編寫的資料儲存方式，可能有個別功能無法繼承（大部分都可以繼承）。

目前已發現的問題：

  1. 部分物品和全部結構名無法進行轉換，將會加入轉換表進行轉換。
  2. 同一個大結構裡的不同儲物箱結構無法歸於同一個整體，這個可以人工分段解決。
  3. java開發版和基岩版後續會加入支持。

目前的資料儲存頁面：

目前的進度：

  • 結構輸出：指定結構 ✓
  • 結構輸出：全部結構 ?
  • 物品輸出：單個物品 X
  • 物品輸出：全部物品 X

目前的示例頁面：

由於未知原因，相同的程式碼在mcwiki上無法實現效果，因此請先前往Test wiki進行查看。

請發表重構模組的建議，感激不盡。--Star Zero · 維基假期中 2021年5月1日 (六) 14:08 (UTC)

沒有什麼更好的建議了（在群裡都交流過了，但是似乎不太明朗），就意見：支持 支持一下重構吧。EN那邊感覺也找不到人解釋。--  Lakejason0（論•功） 2021年5月1日 (六) 15:36 (UTC)
意見：支持 支持重構，希望還能加入的一點就是java版和be版相同時的合併表格。--Snow dash（論 & 功） 2021年5月1日 (六) 16:16 (UTC)
意見：支持 支持，見前面。Sigma166（論/功） 2021年5月2日 (日) 09:40 (UTC)
分為共有，java版，基岩版三個部分如何。--Star Zero · 維基假期中 2021年5月2日 (日) 09:57 (UTC)
意見：支持 支持。--Minesunset1030（討論） 2021年5月2日 (日) 10:16 (UTC)
意見：支持 支持。也許可以用{{only|je}}和{{only|be}}？Sigma166（論/功） 2021年5月2日 (日) 10:41 (UTC)
可否考慮i18n？方便維護也方便遷移到其他wiki。--RealCuervo（討論） 2021年5月4日 (二) 16:36 (UTC)

模組重構第二階段

大家好，本模組的重構在今日已宣告基本完成，已經基本可用。新的模組具有以下優點：

  • 完全由結構化資料生成，避免失誤或版本交替造成的錯誤，這在原模組已經發現幾個了。
  • 極大最佳化程式碼，讓維護和加入功能變得輕鬆。
  • 使用了JSON表對資料的命名空間ID進行轉換，有利於管理和更新最新的譯名標準。
  • 極大的減少了在地化的難易度，任何在地化需要修改的內容都在子頁面進行。
  • 最佳化執行效率，避免出現一個頁面5個LoadPage的情況。
  • 最佳化all模式的顯示效果，增加了實用性。

但新模組剛出爐，不可避免的出現若干小問題，然而我因學業原因無法繼續下一步的修補，因此需要：

  • 另一位擅長Lua的編者接手維護工作。
  • all模式的注釋還未完全繼承原模組，需要按文件進行補充。

以下是模組使用的全部頁面：

我雖想完成後續的工作，但心有餘而力不足，因此需要各位的幫助，感激不盡。
Star Zero · 維基假期中 2021年8月31日 (二) 14:45 (UTC)

辛苦辛苦，感謝重構--Lxazl5770zh.admin（論 ▪ 功） 2021年8月31日 (二) 15:06 (UTC)

加入標籤儲存模組

在21w19a中Mojang加入工具加速破壞的方塊相關標籤後，{{ID table}}中包含標籤的方塊大幅度增加；且快照更改標籤相關內容的頻率有所提高。我希望將遊戲data資料夾中標籤相關的內容經過腳本整理後，儲存到Wiki模組。Template:Sandbox/GameTag/doc是一個樣板。用途有兩點：

  1. 類似於模組:SpecialConversion，在{{ID table}}的|blocktags=參數中返回涉及到的相關標籤。這樣便於維護，更改時只需要更新資料模組，且更新標籤從無到有或從有到無的相關方塊物品頁面即可。
  2. 在標籤的表格中使用。輸出標籤包含內容，引用的其他標籤也能自動生成連結以方便頁面內點擊跳轉，便於維護。

現就這些問題發布於社群專頁：

  1. 是否需要更改{{ID table}}以支持自動生成標籤或提供報錯分類。以提示過時的手動參數、空標籤或自動合併相同標籤。但技術難易度很大，現有的rowspan都是手動指定的。
  2. 現有的輸入都是手動輸入，更改需要不小的編輯量，在此申請社群共識認同。

謝謝。--Snow dash（論 & 功） 2021年5月16日 (日) 02:54 (UTC)

如果改的話，順便把基岩版的標籤也弄一下？不過基岩版目前標籤有億點點亂--2190303755(T|C) 2021年5月16日 (日) 03:49 (UTC)

對，忘說了，模組是Java版的標籤，基岩版沒有json定義，需要其他人來搞。。--Snow dash（論 & 功） 2021年5月16日 (日) 16:14 (UTC)

BE開發版歸屬問題

既然允許存在這種1.16.200+的開發版包含1.17的特性，那要不要把目前1.4.0的前四個開發版（1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12）還給1.2.13，更何況1.2.13正式版也加入了對應的實驗性玩法。與此同時我認為既然這樣的過渡版本開發版內容已經不再屬於目前的主版本號的更新主題，應該考慮為其劃分出獨立的定位，而不是直接放到一起。可以參考

[隱藏]Minecraft基岩版版本
版本
ItemSprite book-and-quill.png：Minecraft中book-and-quill的精靈圖 開發週期
EnvSprite sounds.png：Minecraft中sounds的精靈圖 資源更新

-Jingji132（討論） 2021年6月4日 (五) 08:00 (UTC)

意見：反對 不建議：自1.16.200發布以來，1.16.200+正式版從未出現過「Caves and Cliffs」這個實驗性玩法選項，即這些正式版不包含洞穴與山崖特性，而不像1.2.13那樣，可以透過實驗性玩法啟用水域更新的部分特性；況且這些開發版也不全都測試洞穴與山崖特性，也有其他內容（如1.16.200.53加入光追），且會發布到正式版中，並非過渡更新；直白地說，這些開發版如同一個實驗工具，用完了該放哪放哪。至於1.2.13的問題，參見：en:User talk:Ff98sha#1.3 builds don't exist (yet)。--XiaoXin666（T·C） 2021年6月4日 (五) 15:46 (UTC)
我的主要目的還是回過頭討論1.2.13開發版的歸屬問題，我認為目前的規則與1.2.13時所討論出的規則並不相符，1.2.13那時認為的包含新內容的後續開發版都屬於1.4，但它們本質上是1.2.13的開發版，甚至1.2.13正式版都加入了對應的實驗性功能；而現在1.16.200+的規則認為開發版加入了新內容，即使正式版不包含對應的實驗性功能，也保持從屬關係。我認為這兩個規則是近乎完全相反，按理應該選擇其一，個人傾向於1.16這種更合乎常理。在這一前提下，我再建議考慮為那些新增內容的開發版劃分出獨立區域，而非像現在這樣讓人以為1.16.200+是為了地獄更新搞了一堆開發版，具體的形式肯定不是能直接確定下來的，我只是提供參考，為的是說明目前確實存在一定弊端。-Jingji132（討論） 2021年6月5日 (六) 03:53 (UTC)
“

You'll see more 1.16 versions before seeing 1.17. Increasing the second octet is still a little ways off, even though we're still testing Caves and Cliffs features. At the end of the day, it's just a version number.

你將會在1.17發布之前見到更多的1.16版本。進一步加入新特性還要走很多路，即使我們現在仍在測試洞穴與山崖特性。最後，它只是個版本號。

”
——mattgartzke
由上可見，官方也把1.16.200+當作了版本號，從未將它們視為洞穴與山崖的版本（開發版也如此）。而且若照此劃分，許多版本的歸屬將會變得很奇怪，1.16.201、1.16.221，以及那些沒有加入洞穴與山崖特性而加入其他特性的開發版，如RTX beta、1.16.200.53、1.16.210.50等，也和洞穴與山崖有從屬關係？這一弄不就更讓人不解了嗎？不論如何，它們本質上就屬於1.16（地獄更新）的次版本或開發版，即使與地獄更新關聯不大，只不過它們被借去當作了測試洞穴與山崖特性的工具，沒必要給它們單獨搞個工具箱，用完了還是要回到1.16，不然Mojang不會在正式版移除這些特性。所以我還是認為意見：資訊 維持現狀即可。補充說明一下，我關心的是1.16.200+版本的問題，1.2.13的問題我不作討論。--XiaoXin666（T·C） 2021年6月5日 (六) 05:19 (UTC)（最後編輯於2021年6月5日 (六) 07:13 (UTC)）
你自始至終都沒有討論到人家的頻道上去啊，Jingji132也明確指出他贊同目前1.16的版本分類現狀，你「當做對方反對你的觀點然後額外贅述一堆這些話」是沒有必要的。他對於1.16的的觀點與你是一樣的，維持現狀。如果不討論1.2.13的問題，請不要發表不必要的言論。方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 15:58 (UTC)
本人只是就「新增內容的開發版劃分出獨立區域」的建議而討論，反對拆分獨立區域而已（一開始我寫的是反對拆分），不過沒有想到什麼好建議，只好維持現狀。--XiaoXin666（T·C） 2021年6月6日 (日) 16:23 (UTC)
意見：支持 贊同，無論是從發布時間來看，還是從「都是1.2.13.x」來看，還是從特性的繼承性來看，1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12都屬於1.2.13的測試版，而非1.4的，縱使有1.4的特性加入，但是1.2.13正式版將這些新特性重新放回實驗性玩法也不足以支持「這四個版本不是1.2.13」的開發版。首先，將新特性放入實驗性玩法只是改動一行程式碼的事情，1.2.13正式版是基於1.2.13.12而發布的；其次，將新特性放入實驗性玩法其實是正確的事，正式版是正式發布的，新內容可能尚有bug，沒有充分的測試自然不能當做正式特性加入遊戲，不管是這些特性放入beta，還是這些特性放入實驗性玩法，他們的目的都是一樣的，「測試新特性」，這是合乎常理的需求，跟「1.2.13正式版的測試版到底有誰」絲毫沒有關聯。目前把1.2.13的四個測試版歸為1.4正式版的內容據我所知有頁面分類和infobox、{{Development versions}}。希望速速更正。——方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 16:00 (UTC)
就是這個意思，至於我後面為的是提出「模板中無法突出洞穴與山崖這類更新從何版本進入開發階段」這一問題，給出方案僅對該問題提供參考而非推薦。（而且其實1.2.13的測試版也是透過實驗性玩法加入的水域特性，正式版是直接繼承）-Jingji132（討論） 2021年6月7日 (一) 02:06 (UTC)

廣告

廣告太多！有wiki的，還有google的。 173.255.254.49 2021年7月13日 (二) 09:33 (UTC)

這些廣告不是我們Wiki能控制的，因為我們（包括管理員等在內）沒有網站的實際控制權。您可以透過登入帳號以及使用瀏覽器插件來減少廣告的顯示。--Endearing Cat（討論） 2021年7月13日 (二) 09:41 (UTC)
你也可以使用廣告攔截插件（如Adblock Plus，AdGuard等）來去除廣告。正如Endearing Cat所說，廣告的投放是由Fandom進行的，Wiki的任何管理員、行政員（包括Wiki建立者在內）都無法控制廣告。——JerryHan3（討論） 2021年9月27日 (一) 10:13 (UTC)

更新攜帶版/基岩版版本紀錄中引用的連結

許多攜帶版版本頁面中（例如攜帶版0.4.0）底部引用的修復錯誤列表由於mojang.com遷移的原因均已失效。 三種修改方案：1.使用web.archive.org，訪問該頁面的存檔。缺點是國內無法訪問 2.使用bug.mojang.com的篩選器功能，篩選出在某個版本被修復的bug。 3.從英文站上直接複製。 MinecraftPig321（討論） 2021年7月14日 (三) 04:40 (UTC)

意見：資訊 建議使用方案3。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:05 (UTC)

沒辦法上傳圖片

設定完檔名及描述之後按上傳，會跳出一個視窗寫「過濾器在您的編輯自動檢測到了一項問題，您將暫時無法作出該操作。 與您此次編輯所匹配的過濾規則概述如下：上傳檔案時未選擇授權協議。」 用這個網頁才能正常上傳：上傳檔案 --Zica87（討論） 2021年7月23日 (五) 10:26 (UTC)

您上傳檔案時未選定授權協議，並且使用了中文檔案名，因此被過濾器檢測到，拒絕上傳。請您檢查您上傳檔案時的授權協議和檔案名。MysticNebula70 T  2021年7月23日 (五) 10:48 (UTC)
這其實是VE/2017SCE導致的問題，因為它們不支持選擇協定。-- Dianliang233 T•C https://static.wikia.nocookie.net/zhwikia/images/c/c5/PVT_wordmark.png/revision/latest/scale-to-height-down/16 2021年7月24日 (六) 13:19 (UTC)

【對於一系列伺服器小遊戲是否加入的討論】

我發現【掘一死戰】是一個wiki頁，為什麼不將【起床戰爭】，【空島戰爭】，【飢餓遊戲】等加入Wiki？順便加入一些技巧。

wiki不應該只加入客觀內容，如【在伺服器裡PVP】等屬於主觀內容是應該保留的！

183.209.144.184 2021年7月24日 (六) 12:39 (UTC)熱愛minecraft的某人

根據現行格式指導，「只允許加入Mojang Studios表示已經玩過的小遊戲」，否則這類頁面不具有足夠的關注度，因而不應建立。掘一死戰等頁面的存在實屬英文Wiki搬運時期的歷史遺留問題，而且值得注意的是英文Wiki已有使用者發起提議刪除這類頁面並將其轉移至Minecraft伺服器Wiki的討論（見此），並獲得相當數量的支持。所以非常意見：反對 不建議繼續建立這類頁面。--葉月 桐§ 2021年7月24日 (六) 12:56 (UTC)
我認為這些內容意見：反對 不應該加入到主頁面命名空間，但是可以加入到教學頁面。--222.216.84.54 2021年7月26日 (一) 01:15 (UTC)
我認為此類內容正如上面所說，不應該加入到本Wiki當中，而不只是主頁面命名空間。此前本Wiki也有過關於Mods的內容，但是也快被移動或刪除完了，因為它們不具有足夠的關注度，而且違反現行格式指導。--AblazeVase69188（論·功） 2021年7月26日 (一) 02:34 (UTC)

關於基岩版開發內容留存及去向問題

如題，中英文Minecraft Wiki上的基岩版開發內容（文件及教學）已經過時，嚴重程度不一。目前由於更新不及時（Mojang不更新en）以及基岩版開發Wiki的建立，這些內容的留存價值已經越來越小。

對於此問題，經初步討論，現存有以下方案：

  • 保持現狀不加改變，發揮其仍有的價值。包括參考翻譯等。
  • 一刀切，全部從Minecraft Wiki移除，並軟重新導向至開發Wiki。
  • 使用Tabber等方式使多版本並存。
  • 歡迎踴躍提議。

--SkyE | Talk · Contributions · Logs 2021年7月27日 (二) 15:47 (UTC)

我個人是傾向於全部重新導向到基岩版開發Wiki的，因為這裡還沒有專門的人去維護這些技術性內容頁面，而且容易過時導致參考價值變低。--Lxazl5770zh.admin（論 ▪ 功） 2021年7月28日 (三) 02:01 (UTC)
個人認為先提出一個較好的替代方案，再對舊的文件進行處理是一種比較好的方法。但如果僅僅只是把舊的文件一刀切，而對新的文件又沒有任何翻譯或其他措施去處理，倒還不如在開發wiki直接引條連結去en的原頁。 ACR研究小組編輯（討論） 2021年7月28日 (三) 03:48 (UTC)
從維護程度上考慮，我們無力維護這些文件，如果內容品質也沒法掌控，不如移交給更有能力的人去做。但是Minecraft Wiki的引流導向作用還是要仔細考慮發揮好，不能讓基岩版開發者找不到（如果真的）移除後的去處。--  Lakejason0（論•功） 2021年7月29日 (四) 07:18 (UTC)

提議修改指令語法格式

根據我和Miemie method的討論，以及遊戲內的情況，提議修改指令語法格式，按照遊戲內文字表示：

  1. 不再翻譯原來的[]<>()內的內容，同時取消斜體；
  2. 按遊戲內方式使用[]<>()。由於Java版和基岩版格式不同，因此需要分別表示。

以上兩條同時寫入格式指導內。

有其他想法歡迎提出。MysticNebula70 T  2021年7月29日 (四) 03:15 (UTC)（最後編輯於2021年7月29日 (四) 03:18 (UTC)）

實際上，在討論這個問題的時候，技術性內容方面，座標的表示方法也有待統一。目前遊戲內的表示方法（指令返回文字）裡為x, y, z，但作為頁面來說這麼寫分割感/可辨識度不強，我們初步提出了使用(x, y, z)的表示方法。此外，單獨表示某一軸的座標也有待統一，比如Y=255。由於Minecraft座標系與數學上右手系的標註不太一致，在討論時有人建議將XYZ強制大寫。希望在此議題中能夠一併解決這個問題。
有關此次指令參數語法表示的修改，我認為若遊戲內的表示方法具有統一性（基岩版是呼叫遊戲內部類的所以應該是統一的）且滿足wiki的表意需要，直接採納即可。問題在於，雖然根據遊戲內部機制，不翻譯是對的（沒人會翻譯類名），但「不翻譯括號內內容」可能會造成讀者看不懂參數，反而造成讀者體驗的下降。如果能用一種方式達到表意和遊戲內實際的結合，那我認為會更好。--  Lakejason0（論•功） 2021年7月29日 (四) 07:28 (UTC)（最後編輯於2021年7月29日 (四) 07:28 (UTC)）
為什麼會看不懂參數把參數內容在下面解釋清楚就行了，應該夠了吧（MysticNebula70 T  2021年7月29日 (四) 11:30 (UTC)
若無更多意見，將按照目前的提議修改指令語法格式。MysticNebula70 T  2021年8月2日 (一) 03:16 (UTC)
意見：支持 同意。--  Lakejason0（論•功） 2021年8月2日 (一) 07:27 (UTC)

把「概念性」的armor一詞的翻譯改為「護甲」

眾所周知，armor在Minecraft英文語境下有兩種主要用法，一是表示人實際著裝的一種衣物，常用語xxxx armor（XX盔甲）的詞組，二是做概念性用法，表示一種虛擬的技術性詞彙，比如armor value（盔甲）、armor toughness（護甲韌性）。正如我例子中所述，我提議，前者的armor一律翻譯成盔甲不變，後者的armor改譯成護甲。除了用於作語義區別之外，還有理由如下：1. 以盔甲為例，盔甲非常正常，而盔甲值要麼使人不明所以，要麼使人聽懂但是說起來拗口；2. 社群在這種語境下用護甲的明顯要比盔甲多，這說明盔甲一詞不足以完全勝任armor的翻譯，需要與護甲配合才能表達armor的全部意思。方法放寒假 (Talk - Contributions) 2021年8月2日 (一) 07:15 (UTC)

意見：資訊 FYI相關遊戲內字串的鍵名：attribute.name.generic.armorattribute.name.generic.armor_toughness。--  Lakejason0（論•功） 2021年8月2日 (一) 07:30 (UTC)

棄用原有Infobox，改用PortableInfobox

原有的Infobox是基於Lua和<table>構建的。在UCP遷移後，我們又可以使用Fandom提供的PortableInfobox方案。

兩種方案的優缺點：

原有方案

意見：已完成 優點：

  • 可自訂程度強
  • 與en相同，方便搬運

意見：禁止 缺點：

  • 編寫複雜
  • 樣式不現代，且有很大的歷史包袱（參考FandomDesktop夜間模式）（en的樣式已經變更）
  • 使用<table>
PI

意見：已完成 優點：

  • 可根據社群樣式自動適應，樣式現代
  • SEO略好一些
  • 編寫較簡單，甚至有GUI工具

意見：禁止 缺點：

  • 可自訂性較差
  • 與en方案不同，需要花精力轉換
  • 會忽略頁內轉換規則（雖然在本wiki中頁內轉換使用不多，而且Infobox內貌似也沒有此類用例）

現已有Lakejason0製作的實驗性方案（使用了style，其實不需要）。

關於PI：

-- Dianliang233 T•C https://static.wikia.nocookie.net/zhwikia/images/c/c5/PVT_wordmark.png/revision/latest/scale-to-height-down/16 2021年8月3日 (二) 08:11 (UTC)

小聲提醒一句，某個鏡像並不支持PI，所以如果轉向了PI，恐怕也還是要同時維護兩個（雖然壓力沒聽起來那麼大）。--  Lakejason0（論•功） 2021年8月3日 (二) 09:18 (UTC)

新頁面

其實我一直想幫中文Minecraft Wiki新增頁面，可是中文Minecraft Wiki就好像萬事俱備，已經沒有什麼東西要加下去了。所以我有什麼新頁面可以加的嗎？–該未簽名留言由ChiaLeeChuen（討論 • 貢獻）在2021年8月5日06:35(UTC) 加入。請在您的回覆後面加上 ~~~~

為社群做貢獻不只有新增頁面這一種途徑.--Snow dash（論 & 功） 2021年8月5日 (四) 07:58 (UTC)
找錯別字、移除失效連結、同步歷史段落資訊、擴充已有教學……這些都可以去做，不必拘泥於建立新頁面。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:12 (UTC)

請問Wiki點數的計算公式是什麼

就是這個頁面：Special:WikiPoints

Wiki上沒找到相關規定，搜尋也沒有相關結果。--QWERTY-5238（討論） 2021年8月9日 (一) 05:47 (UTC)

It's a secret. 這裡的使用者都不知道。但可以告訴的是，相同條件下，首次編輯頁面的分數會高一些。Plus，不要為了貢獻點數去編輯。--Ff98sha（討論） 2021年8月9日 (一) 05:53 (UTC)
意見：資訊 意見：但行好事，莫問前程。--ultim_0 ( USER | TALK | CONT ) 2021年8月9日 (一) 05:58 (UTC)


關於教學頁的幾個問題

  1. 請問「原創教學」的定義是什麼？如果有人轉載了其他網站的一篇教學，然後其原作者也過來完善教學，那麼這到底算「原創教學」還是不算？Wiki是可以供所有人編輯的，因此「原創」到底按照哪個人的視角來看？頁面建立者嗎？
  2. 如果一篇教學即是「原創教學」又是「建築教學」（或者其他類型），是否需要將這個教學放兩個連結到{{tutorials}}模板上？我看到很多」原創教學「都沒有這樣做，如教學/跑酷，然而教學/NBT與JSON又即是原創教學又是技術性教學，那麼到底應不應該在{{tutorials}}上建立兩個連結？

求解。--QWERTY-5238（討論） 2021年8月12日 (四) 12:23 (UTC)（最後編輯於2021年8月12日 (四) 12:44 (UTC)）

原創教學指的是「不從英文Minecraft Wiki翻譯而來的教學」，如果是轉載其他中文網站的教學，其大部分情況下不符合協定，那個頁面有可能會被刪除。這是一個遺留問題，與早年中文Minecraft Wiki的編輯方針有關。至於模板中如何擺放的問題，之前在群裡有爭論，但是沒有結論，個人感覺可以放兩次，但是我自己的教學只放了一次（放在資料包裡面）。--  Lakejason0（論•功） 2021年8月12日 (四) 12:30 (UTC)
意見：資訊 意見：
  1. 從其他網站轉載教學到中文Minecraft Wiki尚無成功案例。
  2. 中文Minecraft Wiki的原創教學是與從英文Minecraft Wiki翻譯的教學相對而言的。
  3. 意見：支持 支持將原創教學在{{tutorials}}標記為使用者原創教學的同時放在相應的類別。
    1. 意見：資訊 具體描述：移除該模板中的「原創教學」分類，轉而使用特殊的標記點出原創教學，並在模板開頭說明。
    2. 現試舉一例以供大家探討，見個人沙盒。
以上。--ultim_0 ( USER | TALK | CONT ) 2021年8月12日 (四) 12:34 (UTC)（最後編輯於2021年8月13日 (五) 08:01 (UTC)）
意見：警告 !這個對於「原創教學」的定義著實有點奇怪。我這裡的轉載指的是符合規定的轉載（例如已經獲得作者許可，或作者明確可以轉載），那麼這種轉載能算「原創教學嗎？按你這個定義倒是算，但是分明是轉載變成原創也不太合適吧。
對於經歷了「中文Minecraft Wiki是英文的子語言項目」到「中文Minecraft Wiki已經不只是子語言項目」的過渡的編輯者來說，只能說很正常，如果要更改的話我覺得也不是不行，但是原來是「翻譯」的文章我認為還是要有一定的標註。--  Lakejason0（論•功） 2021年8月12日 (四) 14:37 (UTC)
意見：資訊 意見關於那個放兩次還是放一次的問題，感覺Wiki現在很亂（兩種均可？）該整改一下了。我個人的建議是放兩次。--QWERTY-5238（討論） 2021年8月12日 (四) 12:46 (UTC)
意見：資訊 意見：
  1. 我個人認為，原創教學是指中文使用者自己編寫的教學。既然是原創，那麼這個過程中應該幾乎不依靠從英文Wiki的教學翻譯、或是從其他地方轉載等方式進行編寫。
  2. 目前來看，我意見：支持 支持將原創教學在{{tutorials}}模板上標記為使用者原創教學的同時放在相應的類別中。但是我個人傾向於把原創教學這個類別從{{tutorials}}模板中刪除。--AblazeVase69188（論·功） 2021年8月13日 (五) 05:41 (UTC)
意見：支持 支持User:Ultim 0將原創教學進行特殊標記的方法，但認為可能需要使用另外的標記，如底線。--AblazeVase69188（論·功） 2021年8月13日 (五) 09:06 (UTC)
意見：資訊 意見怎麼沒人回應了？
將原創教學進行標記是一個不錯的決定。建議移除原創教學分類，並用紅點和底線突出原創教學。
如果沒有人反對的話，明天就可以正式實施了。--QWERTY-5238（討論） 2021年8月24日 (二) 09:51 (UTC)

「歷史」頁面命名問題

在英文Wiki中，某些篇幅較長的歷史條目統一被命名為「XX（的）歷史」（History of XX，如History of textures）；而目前中文Wiki沙盒中的命名則是「XX§歷史」，把分節符放到頁面名稱中顯然極不合理。所以懇請各位討論決定一下頁面命名規範：究竟是直接按照英文wiki的方式命名頁面，還是將「歷史」放到子頁面，或是有更好的方案可供另行採取？

（另外，「紋理歷史」相關頁面需要大量上傳/移動圖片，最好使用機器人完成這些任務）

--Thgabs（討論） 2021年8月20日 (五) 03:54 (UTC)

我認為放在子頁面更合適一些。--Endearing Cat（討論） 2021年8月20日 (五) 04:14 (UTC)
子頁面可能有SEO問題（來源請求），不過無論是子頁面還是直接叫「XX歷史」我都能接受。--  Lakejason0（論•功） 2021年8月20日 (五) 04:47 (UTC)
意見：資訊 意見：放在哪裡其實並不重要。統一使用「頁面名稱/History」的格式，如「Java版已移除特性/History」。--ultim_0 ( USER | TALK | CONT ) 2021年8月20日 (五) 08:05 (UTC)（最後編輯於2021年8月20日 (五) 08:48 (UTC)）
審題，「篇幅較長的歷史條目」已經表明可以支撐頁面。--  Lakejason0（論•功） 2021年8月20日 (五) 08:31 (UTC)
意見：資訊 中立偏意見：反對 反對，總感覺「XX的歷史」有點彆扭……--ItemSprite potion-of-resistance.png：Minecraft中potion-of-resistance的精靈圖ChemistChang（Talk/Contributions） 2021年8月20日 (五) 09:05 (UTC)
這似乎是維基百科的編輯習慣，因為維基百科的條目命名空間並不支持建立子頁面。--ultim_0 ( USER | TALK | CONT ) 2021年8月20日 (五) 09:11 (UTC)
還有，如果要改的話，那就別管篇幅長短，最好都統一。--ItemSprite potion-of-resistance.png：Minecraft中potion-of-resistance的精靈圖ChemistChang（Talk/Contributions） 2021年8月20日 (五) 09:16 (UTC)

重改Food模板

如題。

根據遊戲內程式碼重寫了一個{{food}}模板，可在沙盒內找到。

但目前有個問題是：甜莓和螢光莓可作為食物也可作為方塊放置。這兩個東西需要一個方法處理。

以上。

--SorairoMafura（討論） 2021年8月20日 (五) 07:05 (UTC)

首先，不需要刻意去區分肉類；其次，我不知道「總是可食用」什麼意思（可能是金蘋果這類的）。然後就是狀態效果，由於版本差異這會導致infobox看起來很臃腫，不建議加上。甜莓直接在後面補充一個{{food}}模板即可。--Lxazl5770zh.admin（論 ▪ 功） 2021年8月20日 (五) 08:56 (UTC)
某些補充：肉類（meat）、總是可食用（alwaysEat）、狀態效果（effect）都是在程式碼裡註冊食物時便已經定義的屬性。--SorairoMafura（討論） 2021年8月20日 (五) 09:14 (UTC)

關於寶藏型附魔的疑惑：既然它們無法從附魔台上取得，為何擁有附魔權重？

是否應該移除相關內容？–該未簽名留言由Minecraftwater（討論 • 貢獻）在2021年8月21日 (六) 11:41 (UTC) 加入。請在您的回覆後面加上 ~~~~

意見：反對 不建議：事實上，權重是由遊戲原始碼決定的，儘管它們從不在附魔台出現，但是仍然有權重存在。Cnmilkcnmilk（討論） 2021年8月21日 (六) 12:07 (UTC)

關於模板version nav中的internal參數

先前有關討論請見en:MCT:Community portal/Archive 32#Pocket/Bedrock Edition version pages。

{{version nav}}的文件沒有提到參數|internal=的用法。目前其中所填寫的內容不應稱為「內部版本號」（Internal version no.），而應為「完整版本號」（Full version no.）。

「內部版本號」實際上指的是一長串數字；在Android上其儲存於檔案AndroidManifest.xml中，在其他平台上亦然，儲存在某個檔案裡。同時，完整版本號也可以在其中找到。舉個例子，攜帶版1.1.3的內部版本號為871010352，完整版本號則為1.1.3.52。

由現在所找到的攜帶版/基岩版APK檔案來看，同一版本會對應多個安裝包，雖然完整版本號相同，但內部版本號不同。在攜帶版0.6.1之前，每個版本應有且僅有一個內部版本號；這些版本的版本頁面有必要按照內部版本號進行拆分（目前按照完整版本號寫在同一頁面內，有一個段落單獨列出內部版本號）。目前，Google Play上的同一版本會有4個不同的內部版本號，分別對應ARM和x86架構的32、64位元裝置。當然，不只是Android上存在內部版本號，其他平台的版本號仍然需要考證。同時，PlayStation 4上的「完整版本號」較為特殊，和其他平台不一致。鑑於版本號錯綜複雜的情況，需要各位進行討論。

綜上，有必要進一步完善{{version nav}}。關於參數|internal=的顯示，實現方式可能類似於|protocol_manual=，新增一個模組以儲存資料。剩餘事項歡迎各位踴躍提議。--SkyE | Talk · Contributions · Logs 2021年8月22日 (日) 13:09 (UTC)

冰與18w15a資訊不正確

在18w15a後怪物可以在冰面上生成，這一點在歷史一欄中有寫到，可是在生物部分中卻說「北極熊以外的生物無法生成在冰上。」 我同樣去查閱了英文版wiki，發現生物這部分已經被移除

而在18w15a中，中文wiki沒有提到冰面上現在可以生成怪物，而英文版裡確實有這麼一段話 Mobs>Spawning "Mobs can now spawn on top of ice."

兩個錯誤我試著修改，但被維護人員退回了，希望管理員修改這些誤導性很嚴重的錯誤

餵龍（討論） 2021年8月27日 (五) 15:46 (UTC)Fed_Dragon 2021/8/27

意見：已完成 已完成。順帶一提，回退你的編輯的理由是你沒有在編輯摘要中給出證據，以及使用了可視化編輯導致頁面程式碼結構被破壞。--Lxazl5770zh.admin（論 ▪ 功） 2021年8月28日 (六) 03:49 (UTC)

為什麼頂部導覽列的文字變成了繁體？

如題。頂部導覽列原來是簡體文字，但是現在變成了繁體，同時MediaWiki:Wiki-navigation頁面內卻仍是簡體！這是怎麼回事？——JerryHan3（討論） 2021年9月27日 (一) 10:26 (UTC)

簡單來說是Gamepedia wiki特有的系統訊息快取問題。目前Fandom仍在修復，可以嘗試刷新幾次，可能會恢復正常。--  Lakejason0（論•功） 2021年9月27日 (一) 16:27 (UTC)（最後編輯於2021年9月27日 (一) 16:28 (UTC)）
現在已經恢復了，謝謝！——JerryHan3（討論） 2021年9月28日 (二) 09:02 (UTC)

將煙火和火藥球造成的效果的名稱從「爆炸」改為「爆裂」

煙火和火藥球和傷害條目中有關這種傷害方式的描述都是「爆炸」，但已經有一個名字叫爆炸的遊戲機制了。雖然物品資料和實體資料裡是Explosion，煙火的效果可以說絕對不是「爆炸」，並且相關音效字幕的原文也是Firework blasts。

這一系列的條目在表述上造成了嚴重的遊戲機制混淆，所以，建議將煙火造成的效果由「爆炸」改為「爆裂」。同時涉及到的一個JE在地化字串的鍵值是subtitles.entity.firework_rocket.blast，如果達成共識的話就也一起改掉吧。

不過有一個問題是煙火有一個形狀叫Burst，目前被翻譯成了爆裂……不確定要不要也改掉，把這個詞的位置讓出來。--siiftun1857[T/C/E] 2021年8月24日 (二) 17:59 (UTC)

意見：支持 支持，也建議在有關條目開頭寫上相關注釋。如果有人覺得沒必要刻意區分，參見材質和紋理。--  Lakejason0（論•功） 2021年8月24日 (二) 18:12 (UTC)
鞘翅#滑翔：{{Distinguish|飛行}}
這種事情實際上不止一次了。--siiftun1857[T/C/E] 2021年8月24日 (二) 18:16 (UTC)
意見：疑問 疑問，感覺刻意將其與爆炸分開較為不妥。資料裡已經是Explosion了，說明已經將其定義為某種爆炸了。此外述詞有一個判據叫is_explosion，而使用煙火造成的傷害會返回true，也就是在某種意義上承認它屬於爆炸。（不過字幕不是explosion應該可以改）——IcyPhantom 討論I貢獻 2021年8月24日 (二) 18:58 (UTC)（最後編輯於2021年8月25日 (三) 06:51 (UTC)）
個人覺得「爆裂」一詞易讓人想到「爆開的歌萊果」，煙火和焰火之星是有火藥引燃的爆炸，本質上和歌萊果的爆裂是不一樣的，故意見：反對 反對。--ItemSprite potion-of-resistance.png：Minecraft中potion-of-resistance的精靈圖ChemistChang/LYyousa（Talk/Contributions） 2021年8月25日 (三) 01:01 (UTC)

是否需要將infobox header同步為英語wiki的樣式

如題，在之前遷移至Fandomdesktop外觀時，英語wiki修改了infobox header的樣式，此新樣式也被許多其他語言的mcwiki使用。中文wiki是否跟進？MysticNebula70 T  2021年9月30日 (四) 08:20 (UTC)

意見：支持 同意主要還是去除硬編碼，防止深色模式下出現辣眼睛顏色。--Lxazl5770zh.admin（論 ▪ 功） 2021年9月30日 (四) 09:26 (UTC)
意見：已完成 已更新。MysticNebula70 T  2021年10月5日 (二) 13:05 (UTC)

關於Internal version模組及版本拆分

目前攜帶版Alpha部分的版本號的整理已經接近尾聲，但這個模組的實際應用有待討論。原先的方案是整合進{{version nav}}中，但是這還涉及到目前的|internal=參數修改問題。是否有必要在頁面上新增一個段落，以表格或其他形式存放這些資料（部分遠古版本已經有了相關段落）？

這個模組的初衷是為了區分版本，同時作為版本清單。在其實際應用時，必然需要按照其內容拆分版本頁面。主要問題如下：

該模組的編寫工作仍在繼續。後續需要拆分的版本有待整理。--SkyE | Talk · Contributions · Logs 2021年10月3日 (日) 10:23 (UTC)

如果拆分版本，勢必需要考證版本更新的內容。--SkyE | Talk · Contributions · Logs 2021年10月3日 (日) 10:24 (UTC)

意見：使用者框模板組織

參見：Minecraft Wiki:計劃/整理使用者框

其一：使用者框模板不應放置在計劃命名空間，也不應放在子頁面中。

  • 模板應在模板命名空間中存在；
  • 前綴並不利於模板使用；
  • 模板小並不是不放置在模板命名空間中的理由；
  • 這不符合大多數wiki的慣例。

其二，不應使用-作為分隔符。

  • 不符合模板命名的慣例。

以上兩條，其應如這樣命名：模板:Userbox GitHub

以下還有幾條個人意見，是否皆可。

其三，命名不必太拘束

其四，如使用者不願移動到模板命名空間，則保持現狀即可。同時，活動頁也不對這些使用者子頁面進行介紹，如果使用者人數多則建立同樣的模板在模板命名空間。
使用者子頁面是其個人空間，無需以相似為理由不建立模板命名空間的模板。此類無難易度模板無需基於著作而照顧作者。

Star Zero · 維基假期中 2021年10月5日 (二) 12:18 (UTC) （最後編輯於2021年10月5日 (二) 12:21 (UTC)）

重新排版一些舊頁面

一些舊頁面的排版不符合目前標準，建議重寫。

例如攜帶版的舊版頁面。 HornCopper(T·C·W·U·M) 2021年10月23日 (六) 13:21 (UTC)

更正Spore Blossom的翻譯

中文翻譯組的各位大佬好：

我想提出一個翻譯上的建議。這項建議可能非常具有冒犯性質，因為它要求一個物品的名稱超出原本的意思。
事情是這樣的，在接下來的1.18更新之中，物品「孢子花」會被加入遊戲。但是從生物學本身而言，孢子植物我們不認為它是有真正意義上的花的。這也就是說，孢子和花這兩個詞不能同時直接出現。所以我想提出這樣一項建議，即，將「孢子花」一名改成「葆籽花」，或者改成「孢子擬花」，總之，不能向使用者傳達錯誤的知識。
希望社群翻譯者能夠考慮我的這一項建議。同時因為無法在官方社群留言，因此這項建議我也無法遞交到官方社群。如果各位翻譯組成員有條件的話，勞煩您將我的這一提議向社群官方進行回饋。我真切希望minecraft能有較為嚴謹的命名機制而不為人所詬病。
感謝您的閱讀。

--112.2.251.67 2021年10月23日 (六) 13:31 (UTC)青雅音（b站） 呈上

Wiki內不討論遊戲本身的譯名。相關建議倒是可以傳達一下。--  Lakejason0（論•功） 2021年10月23日 (六) 13:39 (UTC)（最後編輯於2021年10月23日 (六) 13:42 (UTC)）
你這麼改有什麼區別嗎？--ItemSprite potion-of-resistance.png：Minecraft中potion-of-resistance的精靈圖ChemistChang/LYyousa（Talk/Contributions） 2021年10月23日 (六) 13:44 (UTC)
我想說的是這是架空世界遊戲。 — 冷·热· Light  ▢  2021年10月23日 (六) 14:18 (UTC)
勞駕閣下移步Crowdin討論，請。--ultim_0 ( USER | TALK | CONT ) 2021年10月23日 (六) 14:32 (UTC)
我認為遊戲就是遊戲，有些東西和現實中不符很正常。再者，英文原文如此，我們也沒法。--  KaplanSteve（論•功） 2021年10月23日 (六) 14:35 (UTC)
意見：資訊在該字串的討論區中看到一條comment，感覺有點意思，故把它引用過來以供參考。Comment來自banz3369：「 嗯，它釋放的孢子好像是那些苔蘚的源頭，我自己猜測官方應該是想這樣表達啦，不然我也不知道他要孢子幹嘛」--Olvcpr423 / 2021年10月24日 (日) 04:21 (UTC)

轉換大量圖片商議

由於Template:Message box的特性（與Minecraft同義），png格式的圖片放在image處可能會帶來很糟糕的感覺，就好像高度近視了根本看不見，請求轉換一些通知模板所使用的圖片，經測試，.svg可以很清楚地顯示，故申請將通知模板的.png轉換為.svg矢量圖。 HornCopper(T·M·C·W) 2021年10月24日 (日) 14:09 (UTC)

補充說明一下，這個特性在我自己的MCR Wiki中復現。 HornCopper(T·M·C·W) 2021年10月24日 (日) 14:57 (UTC)
Fandom使用自己的vignette系統對圖片後處理，與原版MediaWiki的預設機制不同。--  Lakejason0（論•功） 2021年11月15日 (一) 17:34 (UTC)

哪些紅石電路可以算教學

例如教學/隨機發生器、教學/計時器寫的是基本電路的方案，是否應移動到隨機電路、計時電路？或者把各大基本電路歸到教學？傳入神經元（討論） 2021年11月3日 (三) 16:12 (UTC)

可以將簡單、不夠篇幅的電路集合到基本電路，複雜到可以獨立成篇的可以獨立做教學。--Snow dash（論 & 功） 2021年11月3日 (三) 16:27 (UTC)
基本電路都是獨立成篇的，您的意思是全部歸到教學，把簡單的教學作為新的基本電路意見：疑問 ?傳入神經元（討論） 2021年11月4日 (四) 01:11 (UTC)
意見：反對 反對，因為根本就不是那麼回事。兩個教學更偏重於實用機械而非紅石電路，如果有利用遊戲機制或指令的案例也可以寫進去。我弄個利用隨機刻的觸發器也算隨機發生器；我用資料包弄個計時器也算個計時器。而基本電路裡描述的屬於——紅石電路，已經把範圍限制到了紅石上。雖然這倆教學使用的紅石電路案例有點多，但不代表可以就那麼移到基本電路裡去。——IcyPhantom 討論I貢獻 2021年11月3日 (三) 16:54 (UTC)
隨機發生器和計時器僅能提供隨機和計時的訊號，需要結合其他電路使用，不屬於實用機械。如果利用遊戲機制的屬於教學，傳輸電路、時鐘電路、脈衝電路也有利用遊戲機制的方案，是不是該作為教學？描述紅石電路的不算教學、描述指令的就算教學的話也不合適。傳入神經元（討論） 2021年11月4日 (四) 01:11 (UTC)
紅石電池僅能提供無電源的紅石訊號，需要結合其他電路使用，因此不屬於實用機械。「提供隨機訊號」和「提供計時訊號」也是個功能，就因為無法直接利用所以不算實用機械，我覺得這沒道理。對於第二個問題，只要你願意，的確可以寫篇教學出來，我又沒說不能這麼做。我也沒說「描述紅石電路的不算教學」，只是教學可不止會介紹紅石電路，但基本電路這個頁面只能介紹紅石電路（因為它就是「紅石電路」這個頁面的子章節）。那些教學和基本電路是兩個性質的東西，你可以把教學裡的電路複製到基本電路裡去，但完全沒有需要移動的道理。——IcyPhantom 討論I貢獻 2021年11月4日 (四) 05:23 (UTC)
從教學/機械給的定義看隨機發生器和計時器應屬於元件而意見：反對 不是機械，而且輸出的是訊號，不像物理元件那麼實用。我意見：支持 同意不移動教學到基本電路，意見：疑問 問題是該不該留在教學。傳入神經元（討論） 2021年11月4日 (四) 10:37 (UTC)
因為可以實現教學裡說明的功能，所以應該留在教學裡。——IcyPhantom 討論I貢獻 2021年11月4日 (四) 13:57 (UTC)
大前提在哪？傳入神經元（討論） 2021年11月4日 (四) 14:12 (UTC)
你把我問蒙了——這玩意要大前提？解釋一下你這問題要表達什麼。——IcyPhantom 討論I貢獻 2021年11月4日 (四) 14:55 (UTC)
總之結論就是：第一個問題持意見：反對 反對態度，第二個問題算是意見：支持 支持吧。但這個話題結束後會做什麼？——IcyPhantom 討論I貢獻 2021年11月4日 (四) 15:17 (UTC)
如果決定移哪個就移唄。傳入神經元（討論） 2021年11月4日 (四) 15:24 (UTC)

重構頁籤面，並使用GameTagTable

由於標籤頁面內容較大，原始碼瀏覽較為複雜。我製作了GameTagTable模板來簡化頁面編輯。樣板在MCW:沙盒/標籤。現徵求社群修改意見與共識。--Snow dash（論 & 功） 2021年11月4日 (四) 13:52 (UTC)

刪除基岩版Beta版本的平台資訊

眾所周知，基岩版Beta僅發布在Android、Xbox One和Windows 10平台，故我認為除非聲明了版本獨有，那麼均可註明平台。

就是指{{Version nav}}的date參數，通常有註明。

我的意思即去除三平台發布的那種：Android, Xbox One, Windows 10-xxxx年xx月xx日
— HornCopper(T·M·C·W) 2021年11月12日 (五) 08:32 (UTC)

意見：疑問 疑問萬一該測試版僅發布於某一平台呢？這種情況怎麼辦？--  KaplanSteve（論•功） 2021年11月12日 (五) 09:08 (UTC)
對於僅發布於某一平台的基岩版Beta版本，我的意見是單獨聲明，舉個栗子：
xxx是%母版本%的第%序数%個開發版，僅在%platform%平台上發布於%yy%年%mm%月%dd%日。

— HornCopper(T·M·C·W) 2021年11月12日 (五) 09:25 (UTC)

將基岩版的「開發版本」更改為「測試版本」

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

討論結果為意見：已完成 已完成。

如題，幾乎所有社群都使用「測試版」這一稱呼，加之基岩版自身有名為「開發者版本」的版本，容易引起混淆，因此提議修改。現徵詢各位的意見。MysticNebula70 T  2021年11月13日 (六) 01:57 (UTC)

我認為基岩版的alpha，beta就叫測試版，所有的非正式版都統稱「開發版本」。至於基岩版的dev，可以搞個消歧義？--  KaplanSteve（論•功） 2021年11月13日 (六) 03:50 (UTC)
：目前基岩版的測試版採用x.x.x.x四位數字命名，不用擔心區分alpha和beta的問題，且攜帶版Alpha和Java版Beta、Java版Alpha一樣，都屬於平台的一個開發階段，不譯，而所有alpha和beta，在基岩版中被譯為開發版，譯為測試版更妥。
— ThaumiCopper(T·C·W)zh.user 2021年11月13日 (六) 05:26 (UTC)
意見：支持 支持，找遍所有官方語料，可以看到官方只在針對Java版時使用Development Version一詞，這個詞在MCW被翻譯做「開發版」；針對基岩版時官方使用的詞彙是beta，beta一詞在各種文章中都充當著相當JE的Development version一詞的含義，此時的beta不再是什麼開發階段，而是代表和release相對的版本屬性，應譯作「測試版」。另外如上，基岩版確有developer version一詞，其所代表的含義與beta（以及development version）牛頭不對馬嘴，所以不建議在BE中以JE專用的術語「開發版」稱之，建議全部替換成「測試版」，包括基岩版官方文件裡的beta。--方法放寒假 (Talk - Contributions) 2021年11月14日 (日) 14:29 (UTC)
根據之前私底下以及目前給出的原因，給一個意見：支持 支持。--  Lakejason0（論•功） 2021年11月15日 (一) 17:33 (UTC)

在Version nav中加入對BDS參數的支持

我查了一下en那邊，他們在次要更新那個地方有BDS下載，我認為zh應該同步這個，Java版也提供了伺服器端，基岩版為什麼不呢？

另，散步BDS不違反eula。

— ThaumiCopper(T·C·W)zh.user 2021年11月13日 (六) 06:45 (UTC)

已刪除的生態域處理方法？

如題，1.18刪了一些生態域的變種。這些變種怎麼處理

如果留著，如何表示。如果直接刪除，下面的資料值刪不刪 Dahesor（討論） 2021年11月30日 (二) 18:20 (UTC)

按照先例（如雨林等頁面），已移除的生態域可以拆分為單獨的頁面，資料值等資訊也可以轉移到對應的頁面上。之後還需要把相關資訊補充到Java版已移除特性和基岩版已移除特性上。--葉月 桐§ 2021年11月30日 (二) 19:03 (UTC)
所以這麼做？還是先等幾天看看？--Dahesor（討論） 2021年11月30日 (二) 19:09 (UTC)
再次考慮後感覺拆分並不是個好辦法，還是暫時先把資訊留在原頁面上並註明屬於已移除特性。不過現在可以把這些生態域的資訊補充到已移除特性相關頁面上。--葉月 桐§ 2021年11月30日 (二) 19:13 (UTC)
建議先暫時把生態域類頁面退回昨天1.18發布前的版本，對已移除內容暫時打一個已移除標記。主要是目前在en那邊還涉及到重新分類的過程，可以等他們那邊穩定下來以後再弄。具體更改可以參考21w40a中的相應段落進行。--  Anterdc99（論·功） 2021年12月1日 (三) 05:21 (UTC)（最後編輯於2021年12月1日 (三) 05:29 (UTC)）
意見：支持 支持Anterdc99的建議，已對山地的內容進行了一些處理，謹供參考。--ultim_0 ( USER | TALK | CONT ) 2021年12月1日 (三) 05:42 (UTC)
個人建議如果拆分的話會產生非常多的頁面。我建議統一移動到某一個頁面，專門介紹已移除的生態域。當然也可以看看en的處理方法。--  KaplanSteve（T•C） 2021年12月1日 (三) 07:44 (UTC)

將基岩版開發者文件重新導向

本wiki上的各篇基岩版開發者文件均過時已久，且由於其技術性過強而無人維護。提議將這些文件移除，只保留到微軟文件的軟重新導向。

上述做法的一個問題是，微軟的文件暫時沒有中文翻譯。

若有其他想法也可提出。MysticNebula70 T  2021年12月7日 (二) 03:12 (UTC)

不知基岩版開發wiki是否有相應文件的完備翻譯，如有，可考慮鏈入。--ultim_0 ( USER | TALK | CONT ) 2021年12月7日 (二) 05:42 (UTC)
基岩版開發wiki上並沒有相應翻譯。MysticNebula70 T  2021年12月8日 (三) 08:41 (UTC)
文件已全部重新導向。MysticNebula70 T  2021年12月8日 (三) 11:02 (UTC)
取自「https://zh.minecraft.wiki/w/Minecraft_Wiki:社区专页/存档8?oldid=1048139」