Minecraft Wiki

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

了解更多

Minecraft Wiki
Advertisement

社群專頁是為使用者討論編輯相關話題設立的。使用者也可以在對應頁面、使用者的討論頁討論。在發言後請記得加入~~~~簽名。

請了解,Minecraft Wiki在共識系統上運作而不是投票決定,清楚地闡述自己的理由比簡單地支持爭論的一方更有效。

涉及管理員權限的相關事宜請發布於管理員告示板。涉及繁簡字詞轉換等問題請到繁體中文問題報告中提出。

常用頁面

Minecraft Wiki不是客戶服務中心!遊戲問題請移步Minecraft說明中心或者玩家遊戲社群。

所有在該頁面上發表的無關話題都將被存檔至無意義話題處。

請點擊下面的「發起議題」按鈕或頁面上面的「加入話題」標籤在頁面底部發表新的議題。
如果您在頁面上發現有簡繁轉換錯誤或繁體中文譯名沒有正確顯示,請在這裡提出,我們將會儘快修復。


語言

最新Wiki新聞
  • 2023年8月31日 - 中文Minecraft Wiki確定將遷移至Weird Gloop(議題原文)。
  • 2023年7月4日 - 英文Minecraft Wiki公開發布了關於Minecraft Wiki是否要從Fandom遷移至別的站點的討論(連結)。
  • 2023年6月1日 - 新的巡查員Siiftun1857上任。
  • 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升級至1.39。
  • 2023年1月31日 - 新的管理員Anterdc99上任。
# 話題 發言條數 參與人數 發起者 最後發言者 最後發言時間(UTC)
1 重構SPConversion與Module:SPConversion 6 4 Lakejason0 Snow dash 2021年3月3日 (三) 12:13
2 InPageEdit使用滿意度小調查 1 1 機智的小魚君 機智的小魚君 2021年2月20日 (六) 05:25
3 儲物箱戰利品 5 4 Sigma166 Lxazl5770 2021年2月26日 (五) 01:20
4 各個版本「修復」部分中的連結 8 4 Sigma166 Sigma166 2021年2月28日 (日) 10:22
5 關於引用進度的標準 2 2 IcyPhantom Lxazl5770 2021年3月25日 (四) 08:52
6 新增關於字詞轉換的說明頁面 4 2 Lakejason0 Lakejason0 2021年4月23日 (五) 18:41
7 愚人節 3 2 119.237.10.81 119.237.10.81 2021年3月31日 (三) 11:34
8 製作了總討論頁的頂端目錄 6 2 star00 star00 2021年4月6日 (二) 14:42
9 重新規劃生物分類 7 5 siiftun1857 Endearing Cat 2021年4月15日 (四) 13:55
10 提議修改格式指導,以及再次更新Message box樣式 18 7 MysticNebula70 MysticNebula70 2021年5月4日 (二) 13:28
11 是否應加入有關盔甲和工具的重新導向 4 3 AblazeVase69188 AblazeVase69188 2021年4月30日 (五) 15:15
12 深層綠寶石(銅、煤)礦石的相關解釋需要改嗎? 2 2 Minesunset1030 Lxazl5770 2021年5月5日 (三) 15:56
13 重寫LootChest模組 8 6 Star00 RealCuervo 2021年5月4日 (二) 16:36
14 修改Minecraft Wiki:管理制度 8 6 Dianliang233 Powup333 2021年5月5日 (三) 19:41
話題

重構{{SPConversion}}Module:SPConversion

原標題為:重構{{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)

重新規劃生物分類

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

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

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

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

 支持對生物分類進行變更 較反對全部改變到新分類方式。先不論文章實際內容(因為反正總得有個標準),拋棄中立型合併到其他類別的變更會給讀者造成直覺阻礙。雖然很多頁面都要說「中立型和敵對型」,然後再去除中立型裡面的動物,確實造成了表意贅餘,但是除了這種贅餘之外,是否還有更多需要改動的必要?
此外,兩個分類方式是否有原始碼層面的依據?目前的提案應該是來源自聲音事件分類,但是這似乎不能說「就和原始碼層面對Mob的處理」完全一致。如果有人能基於某一套反混淆(我建議yarn或者Mojmap)給出相應的依據,我覺得會更清晰一些。-- LakeJasonFace Lakejason0) 2021年4月5日 (一) 07:41 (UTC)
 問題:友好生物/敵對生物如何判定?這只能主觀判定吧。-- Dianliang233 TC 16 2021年4月5日 (一) 08:33 (UTC)
per myself,根據sounds.json內的聲音事件類別。-- LakeJasonFace 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)

提議修改格式指導,以及再次更新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)

如果需要的話,您可以自行加入重新導向。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)

重寫LootChest模組

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

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

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

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

因此我預計進行以下變更:

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

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

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

目前已發現的問題:

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

目前的資料儲存頁面:

目前的進度:

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

目前的示例頁面:

  • 原始碼存放:模組:Sandbox/Star00/LootChest
  • 指定結構輸出:project:沙盒/LootChest
  • 全部結構輸出:Test wiki上的沙盒頁

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

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

沒有什麼更好的建議了(在群裡都交流過了,但是似乎不太明朗),就 支持一下重構吧。EN那邊感覺也找不到人解釋。-- LakeJasonFace 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)

修改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)

 支持。我認為新的管理制度很好,提高了對管理人員申請的要求,也能有效防止「專制」的負面影響,等等。只有實行了更完善的管理制度才能讓我們的wiki變得更好。--Endearing Cat討論) 2021年5月5日 (三) 04:15 (UTC)(最後編輯於2021年5月5日 (三) 04:19 (UTC))
一個我比較擔心的一點是管理員並沒有CheckUser的權限——每一次都要申請職員去排除分身帳號是不現實的,加上Fandom註冊分身帳號極其容易,因此這種理論上較好的制度可能會因為這種原因而反應不出社群共識。-- LakeJasonFace Lakejason0) 2021年5月5日 (三) 04:23 (UTC)
同上,本人不認為只要是「自動確認使用者」就享有表決權,享有表決權應該設立以下限制:
  1. 必須是一名自動確認使用者
  2. 註冊時間須大於3個月,且總編輯數不少於50次
  3. 無重大封鎖記錄(違反Wiki條例且拒絕改正者須永久剝奪表決權)
滿足以上所有條件的使用者才能享有表決權。
以及,滿足以下任一條件的表決應被視為無效投票:
  1. 投票本身已經違反「一人一票」原則(例如重複投票和使用傀儡帳號投票)
  2. 沒有說明支持或反對原因
  3. 說明原因時離題或者使用不雅語言
  4. 投票後干擾別人的選擇,例如慫恿其改變想法等
為了保證本wiki的表決不受外界干擾,設立以上門檻是非常有必要的。--Lxazl5770zh.admin) 2021年5月5日 (三) 05:18 (UTC)
@Lakejason0Lxazl5770:意見剛剛已由本人加入到草稿。不過作為一個「投票」而不是「討論」,理由等還是免了吧。-- Dianliang233 TC 16 2021年5月5日 (三) 06:13 (UTC)
 支持修改管理制度。
但是本人也認為修改中的管理制度有上述的缺點,對表決權的擁有者的要求確實應該更高,以保證投票結果真實可信。能合理地選舉出巡查員、管理員和行政員的使用者應該在Wiki上活躍一段時間,對Wiki的內容和其他活躍社群成員有一定的了解,而且個人的品行也:不能讓其他社群成員感到反感。
由此提出下列關於對享有表決權的使用者的要求的建議:
  1. 是一名自動確認使用者
  2. 註冊時間超過三個月、總編輯數不少於70次
  3. 曾經在Wiki上活躍過至少一週時間
  4. 一個月內在Wiki上活躍過至少兩天
  5. 30天內無被封鎖記錄,一年內無被重大封鎖記錄(防編輯衝突等特殊原因除外)
此外,修改中的管理制度疑似沒有明確能夠正式成為巡查員的條件(如管理員的「在14日內,若至少70%的參與者支持,且沒有更多的真實爭議,則管理員申請透過」),在此提出疑問。--AblazeVase69188· 2021年5月5日 (三) 06:31 (UTC)
粗略地閱讀了一下新的管理制度,如果我沒猜錯的話,實際上是把行政員的權力架空了。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:46 (UTC)
  • 先從機制說起吧。明明在行政員的職責上寫著「賦予或撤銷使用者權限」,可是在流程上的任何地方都沒顯示和行政員有任何聯繫。按照你的流程,完全可以用一件外掛來替代,而且更高效便捷,提交者和投票者的資質審查完全可以交給機器處理且不會出錯。你的提案將行政員從「人」用規則束縛成了「機器」,這是對行政員的正當權利的直接損害,不可接受。
  • 談完機制談緣由。在幫助wiki對分配權限流程是這麼描述的:「如果你擁有許多管理員,你可能開始需要記錄過程管理他們的行為,例如,什麼時候應該保護一個頁面,還是不保護它好? 你甚至可能會達到一種情況——你需要一個檔案化程式來決定誰將成為一個管理員,以及應該撤銷誰的管理員權利,為了應付這種情況,你不妨提拔幾個使用者進入「行政員」使用者群組(少數你最信任的使用者)來管理分散提拔/撤銷管理員的工作量。在一些大型wiki上,使用者在被授予額外權限之前應由其他使用者投票決定,而管理組則透過指控委員會調查不當行為來撤銷其權利,除了最大的維基社群外,這些流程不太可能是必需的。」這其中明確指出行政員(按程式)有權限進行提拔和撤銷,而投票流程也可能不是必需的。這其中也沒有規定該程式需要「經過社群共識審批」,「嚴重違反了wiki基本法」的說法完全就是對它自身的歪曲解讀。
  • 在整篇提案中,你咄咄逼人地說「(現有制度)成了管理員濫權的工具」,「(wiki需要)走出長期存在的「專制泥沼」(來繼續發展)」,但完全沒有提供任何支撐,完全是紙上談兵。希望你能提供實例(不是「可能性」,而是已經發生的事實和資料)來證明現有制度被濫用,為什麼它與所謂的社群共識相左,它如何限制了發展(及發展的定義是什麼),和為什麼你的改革能確實地進行所謂的發展。

-- Powup333討論) 2021年5月5日 (三) 19:41 (UTC)

Advertisement