可在目前討論頁發起新討論。
重新整理模板{{Blocks}}的方塊分類
下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。
討論結果為 同意更新。
目前導航模板{{Blocks}}中已收錄數百種方塊,展開長度過長,且其目前的分類情況較為混亂,遊戲每變更一次方塊的生成方式,模板中的部分方塊可能就要重新分類一次,如不注意維護很容易產生資訊到期的情況,而且這也不利於玩家查找方塊。建議重新整理此模板的方塊分類。
為此,我已整理了一個新的導航模板(見此),相比原來的導航模板作出的修改如下:
- 棄用原有的方塊分類方式,以Java版的創造模式物品欄為基礎分類,並按照玩家的思維稍加改動,避免分類屬性交叉,查找方塊更加方便。
- 將整個導航拆分為預設摺疊的四個部分,可以按照頁面介紹的方塊類型展開其中一部分,減少頁面佔用空間。
具體的分類細則及使用方法已寫在文件頁面當中,如對此模板的分類規則和使用方法等方面有建議可在此提出。--葉月 桐§ 2021年1月2日 (六) 04:21 (UTC)
- 支援。--AblazeVase69188(討論) 2021年1月2日 (六) 05:28 (UTC)
- 建議:某些部分應按照種類(如冰、冰磚和藍冰)排列在一起,而非按照英文首字母排列。--AblazeVase69188(討論) 2021年1月2日 (六) 05:37 (UTC)
- 建議:將每個分組下的方塊優先按照加入遊戲的時間排列,先加入者在前。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月2日 (六) 11:13 (UTC)
- 支援--Snow Dash(論 & 功) 2021年1月5日 (二) 18:01 (UTC)
- 支援,此外「生物」改成「動植物」也許會好一點。--Lxazl5770zh.admin(論 ▪ 功) 2021年1月6日 (三) 05:38 (UTC)
- 已完成,模板已更新,同時已使用機械人補充所有方塊頁面的模板參數。關於此模板的其他建議可在其討論頁上提出。--葉月 桐§ 2021年1月6日 (三) 09:05 (UTC)
跟進「中文MCW怎麼變成了這個樣子?」
在我自己的MediaWiki站點上,我最近加入了一些英文的系統資訊。由於某些原因登出之後,發現也出現了相同的問題,即以Header-- accept-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。
Lakejason0(論•功) 2021年1月2日 (六) 08:36 (UTC)(最後編輯於2021年1月2日 (六) 08:39 (UTC))
已報吿至Phabricator。--
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)
- 建議:
- 以上。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月9日 (六) 13:11 (UTC)(最後編輯於2021年1月12日 (二) 14:25 (UTC))
- 從我自己的角度來説,我真的看到有人會使用這種圖來分享到底有什麼新內容,因此我並不認為這個主意本身是壞的。但是的確,出現了一些維護問題,並且其實比你説的還多(尤其是繁簡轉換)。我偏向 保留,但是如果覺得真的不行,那我會堅持 轉移。--
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:對於魚來説,可能指生物鱈魚,可能指物品鱈魚,也有可能指其它的魚,種子、金同理,但金只需要區分金粒、金錠或金磚),即使對應頁面做了區分(如魚(生物))也需要建立消歧義。
- 對於其他的(比如不死生物或窳民)只需要改成索引即可。
--ChemistChang(Talk/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)
- 支援。--XiaoXin666(T·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)
刪除輔助程式與編輯器?
英文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_tag和query.all_tag可查詢方塊或物品的標籤
即:基岩版有方塊和物品標籤
但至今ID_table模板仍無基岩版標籤參數
是否會考慮加入?
連結列出了一些Miemiemethod在源碼找的方塊標籤
方塊標籤(這個頁面是我水的
2190303755(T|C) 2021年1月28日 (四) 07:53 (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)
關於版本頁面問題
下列有關更新模板的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。
討論結果為 按照Miemiemethod的方案進行更新。
如題,舊事重提。攜帶版/基岩版的歷史版本頁面格式較為混亂,一直沒有得到妥善解決。
在和Miemiemethod進行討論後,於MCW:SG和MCW: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
年久失修。
標題可使用如下幾種格式:
携带版vx.x.x[.x] alpha[x][build x](遊戲中如此,en使用方案,zh經過我填海的頁面行文也使用此方案)携带版Alpha x.x.x[.x][(x)][build x](zh現行方案,括號建議改為半形)携带版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的方案是去掉alpha和v等。
基岩版
同上,Miemiemethod的方案是建議去掉beta等。
鑑於時間倉促和個人能力有限,可能有特殊情況和其他問題沒有列出。--SkyE | Talk · Contributions · Logs 2021年2月9日 (二) 16:03 (UTC)
- 關於之前的討論進度及記錄,詳見此。另外,參見填海:User:SkyEye FAST/Sea。--SkyE | Talk · Contributions · Logs 2021年2月9日 (二) 16:08 (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)
方案給的實在太多了……這樣看下來我也只能給 中立了。--
Lakejason0(論•功) 2021年2月9日 (二) 16:39 (UTC)- 支援MysticNebula70所描述的方案。--
Lakejason0(論•功) 2021年2月12日 (五) 09:05 (UTC) - 個人
反對支援刪除前綴alpha和beta,因為這些前綴可以明確地表示該版本是開發版,並不是多餘的便於查找和輸入;其餘方案保持 中立。--XiaoXin666(T·C) 2021年2月10日 (三) 05:18 (UTC)(最後編輯於2021年2月11日 (四) 09:41 (UTC))- 前綴
alpha和beta並非開發版的代表,但是我不想就這個觀點進行爭論。就算二者是開發版的代表,加與不加不會造成任何混淆,因為沒有兩個版本擁有相同的版本號但是一個帶beta一個不帶;並且,開發版與否可以直接看Infobox內以及第一段段首第一句話,標題帶着beta不僅累贅(不便於查找和輸入),而且和頁面內資訊重複,而且沒有起到任何和其餘版本區分的作用(因為加與不加兩個版本都能區分開,就算某個正式版與某個搶鮮版區分,他們最大的不同也是版本號不同而非有沒有beta)。因此 反駁你的觀點。方法放寒假 (Talk - Contributions) 2021年2月10日 (三) 12:21 (UTC)- 確實,前綴
alpha和beta沒必要保留,是我思慮不周,感謝你的反駁。--XiaoXin666(T·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)
- 意見:
Alpha和Beta等建議首字母大寫,畢竟是稱呼開發版本版本號的特有用語,不是一般英文單詞。- 對於基岩版各版本的標題, 同意直接參照遊戲內格式進行命名,要不然太亂了。
- 對於基岩版開發版本標題的命名, 支援去掉
Alpha和Beta等英文,便於輸入與查找。
- 對於其餘方案則保持 中立。--AblazeVase69188(討論) 2021年2月11日 (四) 08:57 (UTC)
Dianliang233的提議
我個人強烈 反對上述所有方案(除「攜帶版」「基岩版」前綴)。
我提議:按照en的命名方案,嚴格跟隨遊戲內命名。
遊戲內命名可以消除絕大多數歧義:這樣的命名方案不但不會消除潛在的錯誤認知,而且使玩家的資料查詢變得無比便捷。遊戲內寫什麼,他們就搜什麼,這種方案最為直觀,符合人類的認知習慣。玩家也不需要在根據「wiki的命名」和「Mojang的命名」之間做毫無必要的猶豫。
若您認為我的這些觀點毫無邏輯,那麼請問一個版本的標題不是版本在遊戲內的命名有何意義!?
以上。-- Dianliang233 T•C 2021年2月12日 (五) 11:58 (UTC)
- 首先要明確遊戲內版本到底是哪一個版本,如果按照遊戲內右下角,所有的beta和alpha都將被去掉。如此圖,遊戲內版本應該是v1.16.210.59。en目前所有的攜帶版版本頁面標題都帶着「v」前綴,但是基岩版都沒帶,但是所有的版本v前綴都是存在的。
如果你認為頂部顯示的是遊戲內版本,首先第一點就是正式版並沒有那個東西;第二點是,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的命名規則。這和譯名標準化有一定意義上的不同。
根據我之前提出的方案列表,我認為目前只有兩條路可走:
- 依照遊戲內顯示的名稱,幫en改正錯誤的命名並且應用到zh。
- 採用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(用戶端)與其他的都不一樣),是不是也可以考慮去掉一下。
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
/
2021年2月12日 (五) 13:15 (UTC)
- Gamepedia職員目前已經匯入FandomMobile的CSS。部分CSS可能已經修復。--
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?編輯時應該寫
目前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)
關於rd-131655(Cave Game Tech Test)之前的「版本」
rt,我認為rd-131655之前的「版本」只是一些小改動,它們根本就沒有發佈給任何人,也沒有明確的證據證明它們是獨立的版本,Notch也僅僅在IRC上簡單提及了它們的改動內容,所以,我認為這些所謂「版本」根本不能算是版本。這些內容應當合併到rd-131655中,並在一個子標題中描述這些改動。順便説一下,在英文wiki中,這些「版本」的「更新」內容都已經被合併到了rd-131655的頁面中。--KisinSagume286(Talk!/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之前「版本」內容的合併。--KisinSagume286(Talk!/Contribs...) 2021年2月20日 (六) 03:02 (UTC)
Java版alpha版本「v1.2萬聖節更新」界面「歷史」條目不全
似乎這些原始版本的「歷史」條目存在這個問題,建議應完善這些內容,引入專門的模版,謝謝。(awa)--Cobalt sayori(討論) 2021年2月20日 (六) 07:57 (UTC)
關於本人編制的「教學/征服堡壘遺蹟」能否發表到教學中
這一教學已經編制完畢,本人認為值得發表,但具體能否達到發表要求還有待商榷,也煩請大家幫忙看一下,好嗎?--Cobalt sayori(討論) 2021年2月22日 (一) 04:08 (UTC)
本人願意承擔「教學/陷阱「篇目的修改工作
有關「教學/陷阱」篇目,存在大量的不妥當因素,需要進行一系列修改。 具體原因在於:
- 本教學是針對於多人聯機中其他玩家的陷阱,但篇目中存在很多針對於生物的內容,這些內容對於玩家基本上沒有用處。
- 對於跌落物的收集,仍需要完善。
- 建議透過陷阱的作用進行重新排版。
謝謝大家的幫助!--Cobalt sayori(討論) 2021年2月22日 (一) 06:51 (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 dash、MysticNebula70和我個人在私下提出,現放在社群專頁徵求共識。--
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)
- 拒絕——根據現有
{{LootChestItem}}模組代碼,不能實現Java版和基岩版分開。重構是一件非常麻煩的事情。--Lxazl5770zh.admin(論 ▪ 功) 2021年2月26日 (五) 01:20 (UTC)
各個版本「修復」部分中的連結
在本wiki的各個版本介紹頁面中,有小部分頁面在「修復」部分加入了連結(比如18w43a、12w06a),而大部分頁面並沒有。本人現有如下想法,並徵求大家的意見:
- 將所有版本介紹頁面中的「修復」部分添上連結(艱巨的任務)
- 將所有版本介紹頁面中的「修復」部分刪去連結(為保持一致並減少工作量)
- 不做改動,保持原狀(省事是省事,就是看着彆扭)
個人 支援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)
- 不不不,就是最普通的內鏈([[xxxx]]的形式)。Sigma166(論/功) 2021年2月26日 (五) 01:21 (UTC)
因為最近我一直在做錯誤列表相關工作,所以我來説明一下具體情況:
- 一般來講,最近依據錯誤補全計劃補全的(我編輯的)並且使用了fixes模板的錯誤列表,列表全文一般沒有連結,有連結的屬於少數情況。
- 較老的列表(1.4以前)的,一般都有。當然這是從英文wiki帶過來的情況,所以我在翻譯的時候也保留了這些連結。
- 還有一些以前其他貢獻者翻譯的內容,其實存在大量這樣有連結和無連結混合的情況,還有模板使用不正確的問題(就比如Lxazl5770在18w43a遇到的情況一樣,是fixes模板使用不當導致的)。
至於你提出的選項,我個人 支援2或者是3。因為如果要全部加上的話,少説幾百個版本頁面中的內容都要修改。
且大多數版本中修復的錯誤大約有30-40個,甚至多的會有70+,另外還要算上主要更新版本(例如:Java版1.8),這些版本的錯誤修複列表往往非常巨大,這是由於這樣的頁面需要合併所有開發版本中的內容導致的。
所以在做加入連結的工作前,建議先考慮好這樣是否合算。
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裏面在「請以遊戲內為準」那一行也加上到這個說明頁面的連結。
這個頁面的內容我已經提前提交給一部分本地人看了看,收集了一部分修改意見,現放在社群專頁以獲得進一步的共識與建議。--
Lakejason0(論•功) 2021年3月20日 (六) 17:09 (UTC)(最後編輯於2021年3月25日 (四) 08:28 (UTC))
頁面已建立,見Help:字詞轉換。
Lakejason0(論•功) 2021年3月25日 (四) 15:24 (UTC)
- 推進。希望管理員能寫一下Sitenotice。--
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樣式不能適應以上的調整,需要相應修改。大致需要變更的內容有:
- 將所有非mini的msgbox統一寬度;
- 增加msgbox的外邊框;
- 兩個相鄰的msgbox取消間隔;
- msgbox內的文字改為左對齊。
另外,msgbox可以使用預設的顏色(目前有7個:red、orange、yellow、green、blue、purple和magenta),以不同的顏色表示不同類型的資訊(如紅色表示需要立即執行的操作,橙色表示頁面有內容方面的問題,等等),同時仍然支援自訂顏色。
此處可以預覽新樣式。
現在此徵詢社群的意見。MysticNebula70 T 2021年4月16日 (五) 12:24 (UTC)
- 支援。不過和英文的差別還是很大,和正經Ambox的差距倒是很小。--
Lakejason0(論•功) 2021年4月16日 (五) 14:07 (UTC)
- 大部分 支援。只不過那個灰色的border我不大喜歡。-- Dianliang233 T•C
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)
- 忽然才意識到這些配色在我的顯示器上很素,很暗。如果改的更亮一點呢?--
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
- --
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)
| 類型(顏色) \ 命名空間 | 條目命名空間 | 檔案命名空間 | 討論命名空間 |
|---|---|---|---|
| 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除了皮革盔甲之外沒有其他相關的重新導向了。
如題,加入的理由有如下:
- 某些編輯者可能更傾向於輸入
[[钻石盔甲]]而非[[盔甲|钻石盔甲]]; - 一些初來乍到的編輯者對Wiki是否有這樣的重新導向不熟悉,可能會直接輸入
[[钻石盔甲]];發現Wiki上沒有這樣的重新導向之後,為了方便此編輯者可能會輸入钻石[[盔甲]],這樣不符合部分讀者的習慣——他們可能會在看不清楚的情況下點擊「鑽石」而非「盔甲」。
綜上,我認為有一定的必要加入相關重新導向,現在此提出意見,徵求社群的共識。--AblazeVase69188(討論 | 貢獻) 2021年4月23日 (五) 14:18 (UTC)(最後編輯於2021年5月1日 (六) 03:55 (UTC))
- 如果需要的話,您可以自行加入重新導向。MysticNebula70 T 2021年4月23日 (五) 14:31 (UTC)
相關重新導向已全部建立,如有異議請在此提出。--AblazeVase69188(討論 | 貢獻) 2021年4月30日 (五) 15:15 (UTC)
深層綠寶石(銅、煤)礦石的相關解釋需要改嗎?
如題,21w17a的數據包中已經可以生成這三種礦石的深層變種,但數據包的更新內容需要和正式更新內容一起寫嗎?--Minesunset1030(討論) 2021年4月30日 (五) 22:15 (UTC)
修改Minecraft Wiki:管理制度
- 背景
中文Minecraft Wiki現行與過去的管理員選舉機制存在明顯錯誤和缺陷,為某些圖謀不軌的管理員施行專政封閉的管理提供了可乘之機。幾年前發生過的反pow團隊割裂現象,推進了管理制度的制定。但是,它反而成了管理員濫權的工具。因此,有必要重定管理員選舉制度,主要是管理員與巡查員的產生辦法。
- 原因
- Minecraft Wiki:管理制度的制定和後續修訂均未經過社群共識審批。
- Minecraft Wiki:管理制度中所規定的「行政員保留無理由撤銷管理層職務的權利」」在職務到期時由行政員根據其表現決定是否刷新和延長時限」「不多於n名在職管理員對其就職提出反對」「3⁄4以上的在職管理員認可其對Wiki的貢獻。」使管理員可以「欽定」管理員、巡查員的就職和任免,嚴重違反了wiki社群共識高於一切的基本法。
- 現今中文wiki社群環境已經成熟,共識系統可以確立,「人少」「效率低」已不是藉口。
- 修改辦法
見Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。請善用比較功能查看差異。修改內容主要有:
- 全面擯除專制選舉的陋制
- 加入管理員投票選舉制度和巡查員符合要求即授予制度
- 提高了巡查員和管理員的要求
- 總結
這是社群從選舉層面堅持和完善社群共識制度體系、確保wiki長治久安的必要之舉,充分體現了正當性和進步性。相信透過選舉制度的完善,Minecraft Wiki一定能夠走出長期存在的「專制泥沼」,集中精力完善內容、添磚加瓦,再創發展奇蹟。僅代表個人,不代表Fandom意見。希望得到各位的支援。-- Dianliang233 T•C
2021年5月5日 (三) 03:14 (UTC)
- 支援。我認為新的管理制度很好,提高了對管理人員申請的要求,也能有效防止「專制」的負面影響,等等。只有實行了更完善的管理制度才能讓我們的wiki變得更好。--Endearing Cat(討論) 2021年5月5日 (三) 04:15 (UTC)(最後編輯於2021年5月5日 (三) 04:19 (UTC))
- 一個我比較擔心的一點是管理員並沒有CheckUser的權限——每一次都要申請職員去排除分身賬號是不現實的,加上Fandom註冊分身賬號極其容易,因此這種理論上較好的制度可能會因為這種原因而反應不出社群共識。--
Lakejason0(論•功) 2021年5月5日 (三) 04:23 (UTC) - 同上,本人不認為只要是「自動確認用户」就享有表決權,享有表決權應該設立以下限制:
- 必須是一名自動確認用户
- 註冊時間須大於3個月,且總編輯數不少於50次
- 無重大封鎖記錄(違反Wiki條例且拒絕改正者須永久剝奪表決權)
- 滿足以上所有條件的用户才能享有表決權。
- 以及,滿足以下任一條件的表決應被視為無效投票:
- 投票本身已經違反「一人一票」原則(例如重複投票和使用傀儡賬號投票)
- 沒有説明支援或反對原因
- 説明原因時離題或者使用不雅語言
- 投票後干擾別人的選擇,例如慫恿其改變想法等
- 為了保證本wiki的表決不受外界干擾,設立以上門檻是非常有必要的。--Lxazl5770zh.admin(論 ▪ 功) 2021年5月5日 (三) 05:18 (UTC)
- @Lakejason0和Lxazl5770:意見剛剛已由本人加入到草稿。不過作為一個「投票」而不是「討論」,理由等還是免了吧。-- Dianliang233 T•C
2021年5月5日 (三) 06:13 (UTC)
- @Lakejason0和Lxazl5770:意見剛剛已由本人加入到草稿。不過作為一個「投票」而不是「討論」,理由等還是免了吧。-- Dianliang233 T•C
- 支援修改管理制度。
- 但是本人也認為修改中的管理制度有上述的缺點,對表決權的擁有者的要求確實應該更高,以保證投票結果真實可信。能合理地選舉出巡查員、管理員和行政員的用户應該在Wiki上活躍一段時間,對Wiki的內容和其他活躍社群成員有一定的了解,而且個人的品行也:不能讓其他社群成員感到反感。
- 由此提出下列關於對享有表決權的用户的要求的建議:
- 是一名自動確認用户
- 註冊時間超過三個月、總編輯數不少於70次
- 曾經在Wiki上活躍過至少一週時間
- 一個月內在Wiki上活躍過至少兩天
- 30天內無被封鎖記錄,一年內無被重大封鎖記錄(防編輯衝突等特殊原因除外)
- 此外,修改中的管理制度疑似沒有明確能夠正式成為巡查員的條件(如管理員的「在14日內,若至少70%的參與者支援,且沒有更多的真實爭議,則管理員申請透過」),在此提出疑問。--AblazeVase69188(論·功) 2021年5月5日 (三) 06:31 (UTC)
- 巡查員應該是達到條件直接給予的。不過還是有些問題,我近期會修正的。-- Dianliang233 T•C
2021年5月6日 (四) 12:50 (UTC)
- 巡查員應該是達到條件直接給予的。不過還是有些問題,我近期會修正的。-- Dianliang233 T•C
- 粗略地閱讀了一下新的管理制度,如果我沒猜錯的話,實際上是把行政員的權力架空了。--Lxazl5770zh.admin(論 ▪ 功) 2021年5月5日 (三) 15:46 (UTC)
- 先從機制説起吧。明明在行政員的職責上寫着「賦予或撤銷用户權限」,可是在流程上的任何地方都沒顯示和行政員有任何聯繫。按照你的流程,完全可以用一件外掛來替代,而且更高效便捷,提交者和投票者的資質審查完全可以交給機器處理且不會出錯。你的提案將行政員從「人」用規則束縛成了「機器」,這是對行政員的正當權利的直接損害,不可接受。
- 談完機制談緣由。在幫助wiki對分配權限流程是這麼描述的:「如果你擁有許多管理員,你可能開始需要記錄過程管理他們的行為,例如,什麼時候應該保護一個頁面,還是不保護它好? 你甚至可能會達到一種情況——你需要一個檔案化程式來決定誰將成為一個管理員,以及應該撤銷誰的管理員權利,為了應付這種情況,你不妨提拔幾個用户進入「行政員」使用者群組(少數你最信任的用户)來管理分散提拔/撤銷管理員的工作量。在一些大型wiki上,用户在被授予額外權限之前應由其他用户投票決定,而管理組則透過指控委員會調查不當行為來撤銷其權利,除了最大的維基社群外,這些流程不太可能是必需的。」這其中明確指出行政員(按程式)有權限進行提拔和撤銷,而投票流程也可能不是必需的。這其中也沒有規定該程式需要「經過社群共識審批」,「嚴重違反了wiki基本法」的説法完全就是對它自身的歪曲解讀。
- 在整篇提案中,你咄咄逼人地説「(現有制度)成了管理員濫權的工具」,「(wiki需要)走出長期存在的「專制泥沼」(來繼續發展)」,但完全沒有提供任何支撐,完全是紙上談兵。希望你能提供實例(不是「可能性」,而是已經發生的事實和數據)來證明現有制度被濫用,為什麼它與所謂的社群共識相左,它如何限制了發展(及發展的定義是什麼),和為什麼你的改革能確實地進行所謂的發展。
-- Powup333(討論) 2021年5月5日 (三) 19:41 (UTC)
- 管理員和行政員確實就應該是執行社群共識的機器。請問行政員的正當權益是什麼?行政員和管理員的權限,就是基於社群給予你的信任!別忘了你來自哪裏!
當不當管理員應該沒什麼大不了的。
- 最近聽説你wiki已經把社群自治列入wiki規則了?同上一條,要明白,wiki上一切用户所有的權利都是共識給予的,你的權限同樣也應該是社群共識收回的。另外,help wiki作為權威參考我是絕對支援的,但是我認為某位用户用來調侃我的話也同樣適用來回應你:
wiki不是可口可樂,不是全世界的wiki都有一樣的制度
- 如果有「實例」的話,你我還用在這裏長篇大論?為什麼現有制度可能是管理員濫權的工具我已經講的很明白了。潛在的問題就不是問題?至於你wiki管理層獨裁的事實證據那倒是有。鐵證都可以在一個叫做ag的用户的言辭上看到。我是後輩,這方面您比我更有經驗吧?
- 個人言論,不代表Fandom。--34.92.62.159 2021年5月6日 (四) 12:40 (UTC)(最後編輯於2021年5月6日 (四) 13:23 (UTC))
- 忘記登入了,Dianliang233對此留言負責。-- Dianliang233 T•C
2021年5月6日 (四) 12:43 (UTC)
- 忘記登入了,Dianliang233對此留言負責。-- Dianliang233 T•C
- 「管理員和行政員確實就應該是執行社群共識的機器」這話我就不懂什麼意思了,既然這樣的話我覺得可以寫一個外掛讓它來當管理員,如果mw的執行機制允許這麼做的話。至於ag,欲加之罪,何患無辭呢(可以參考ag對某位名叫MashKJo的用户發生的經歷)。
順帶提一提管理制度本身就有個缺陷:沒有規定管理員/行政員數量。這意味着只要實行所謂的「投票制」,理論上是可以無限增加管理員/行政員的數量的。但是我們都知道這樣做只會導致權力高度分散而出現拉幫結派(或者説所謂的「多黨制」)的場面,這顯然不利於wiki的健康發展。--Lxazl5770zh.admin(論 ▪ 功) 2021年5月6日 (四) 13:36 (UTC)- 正是因為不可能實現才有的管理員。
- 管理員數量確實不設限,但是能做管理員的用户數量是有限的、社群自己的容忍度是有限的。-- Dianliang233 T•C
2021年5月6日 (四) 21:01 (UTC)
- 什麼叫正當權益?正道權益就是能在規則下行使權利的自由。打個銀行卡的比方,我有能在我賬號存取錢的正當權益,銀行可以設定限制説「一天最多取走一定金額」,「月底卡裡必須剩餘一定金額」,這也是銀行的正當權利。但銀行不能説「你無權自行進行存取操作」,「你必須在收到銀行通知後存取銀行規定的金額」。這合理嗎?這不合理。你的提案完全剝奪了行政員(在常態下)行使「賦予或撤銷用户權限」的自由,這就叫損害了正當權益。
- 那麼現在,就輪到你來解釋你的核心理念了,請你翻譯翻譯什麼叫社群共識。社群有多廣,共識又有多深?這社群是包括了上萬名的讀者,上千名的用户,還是目前157名的活躍用户,目前參與了目前話題討論的6個人?共識是指全體一致,絕對半數,三分之二,或是某百分比?過去的共識能否限制未來的共識,而未來的共識又能否推翻過去的共識?最初的社會共識是否需要獲得社群共識的認可,目前社群共識又能否定義未來的社群共識?你又如何證明那不是現在的情況的另一個版本呢? Powup333(討論) 2021年5月7日 (五) 05:31 (UTC)
- 我再重申一遍,行政員「賦予或撤銷用户權限」的自由,本就是我社群共識授予你的。至於需不需要收回,什麼時候收回,這也是社群共識説了算的。至於你舉的銀行卡的例子,完全是顛倒黑白:銀行卡裡的錢倒是你的所有,wiki可是你的所有?
- 作為「業務熟練」的管理員,我很驚訝的是你連共識的基本概念都不清楚?是不是獨裁久了忘記民主觀念了?是裝糊塗還是真糊塗?在此對你wiki某些管理員的業務能力提出質疑。我懶得説,自己去看wikipedia:zh:WP:共識!
- 希望閣下下次提出質疑能提出一些合理、正確、有建設性、自己點擊儲存按鈕的時候問心無愧的問題,不要再把閣下狼狽的那一面展現給大家了。-- Dianliang233 T•C
2021年5月7日 (五) 22:47 (UTC)
- 插:請兩位在討論的過程中友善發言,不要進行人身攻擊,圍繞論題進行。--Star Zero · 維基假期中 2021年5月8日 (六) 01:47 (UTC)
- 我想説明的是:我提出來修改選舉制度,完全就是臨時起意的產物。我沒有想到的是,這刺痛了某管理員的痛點,面對質疑,不但不正面回復、反思,還顛倒是非、進行詭辯。我看到了人的陰暗面。對於這種人,其心可誅。-- Dianliang233 T•C
2021年5月8日 (六) 06:19 (UTC)
- 你是不是對pow有着很大的偏見和不滿?如果僅僅是這樣,那麼你們倆的事完全可以透過私下裏溝通來解決,而不是把事情上升到全體管理層,甚至是管理制度的層面,把私仇變為公憤。--_Regera_ 2021年5月8日 (六) 08:38 (UTC)
- 再次重申:我與pow完全沒有任何私人恩怨。請閣下在留言前自己確認留言是否合適,不要進一步激化矛盾。-- Dianliang233 T•C
2021年5月8日 (六) 10:23 (UTC)
- 再次重申:我與pow完全沒有任何私人恩怨。請閣下在留言前自己確認留言是否合適,不要進一步激化矛盾。-- Dianliang233 T•C
- 詩云:「兄弟鬩於牆,外御其侮。」請大家不要把個人情緒代入到中文Minecraft Wiki的討論,這對管理團隊甚至中文Minecraft Wiki都不利。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 08:52 (UTC)(最後編輯於2021年5月8日 (六) 11:51 (UTC))
- 你是不是對pow有着很大的偏見和不滿?如果僅僅是這樣,那麼你們倆的事完全可以透過私下裏溝通來解決,而不是把事情上升到全體管理層,甚至是管理制度的層面,把私仇變為公憤。--_Regera_ 2021年5月8日 (六) 08:38 (UTC)
- 首先,我上述留言中,只點出了:1)你wiki管理制度有缺陷,縱容行政員欽定管理員;2)你wiki管理層在各項事物上普遍存在獨裁傾向或實際行為;3)所謂管理制度本身也是欽定的產物;4)所有管理層成員都是欽定討論出的;5)某(些)管理員(貌似)連wiki基本理論都不大了解。而沒有點出:1)有人曾經濫用過管理制度,以其作為保護傘;2)所有管理層成員都有獨裁欽定行為;3)我在留言最開始是假定惡意;4)所有管理層成員都尸位素餐,沒有實力。平心而論,我對各位管理員和巡查員都心懷感謝:感謝你們為wiki的辛勤付出;感謝你們對我wiki經驗的成長中的批評、指正和寬容。但是,某(些)管理員的醜惡面孔,大家都已經看到了……-- Dianliang233 T•C
2021年5月8日 (六) 06:52 (UTC)
- 為什麼拉幫結派的情況不太可能發生,我已經闡述過了。如果説行政效率變低我倒是同意,不過人事任免的效率不大需要多快。被外界干擾已經被「投票權」的門檻擋住了。-- Dianliang233 T•C
2021年5月8日 (六) 06:24 (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:DEM、WP:POLL、WP:BATTLEGROUND和WP:FAITH。--Lxazl5770zh.admin(論 ▪ 功) 2021年5月9日 (日) 09:32 (UTC)
- 感謝管理的真誠回應。其他的就不多説了,決裂過的人也沒必要再挽回了。--
Lakejason0(論•功) 2021年5月9日 (日) 10:23 (UTC)
- 這裏指的不是電量。我甚至都不認為哪一個(只有一個例外)決裂的人是因為wiki事務才決裂的。--
Lakejason0(論•功) 2021年5月9日 (日) 10:24 (UTC)(最後編輯於2021年5月9日 (日) 10:38 (UTC)) - 討論及決定的不是管理組,是社群本身,即本討論。--Star Zero · 維基假期中 2021年5月10日 (一) 14:18 (UTC)
- 這裏指的不是電量。我甚至都不認為哪一個(只有一個例外)決裂的人是因為wiki事務才決裂的。--
- 對於Cuervo/a2的發言我就不用説太多了;因為已經很久沒有在這裏編輯過了,又因為每一次出現都能被説是舊病復發,我知道我沒有多少發言權。關於管理員(此處尤其指某位行政員)是否能夠一手遮天的問題,我想有過遭遇的自然會知道答案。如果中文 Minecraft Wiki 真的能夠做到長久以來虛無的「皿煮」的話,那我就在幕後為你們的成功慶祝吧。另外,好像看到有一名馬迷成功上任了管理員,這個也一定要祝賀一下,這是墜吼的!
Minecraft Wiki Anti-* Safe House. --SkyFuInMC (DI/CO) 2021年5月27日 (四) 14:46 (UTC) from Onion Network
- 對於Cuervo/a2的發言我就不用説太多了;因為已經很久沒有在這裏編輯過了,又因為每一次出現都能被説是舊病復發,我知道我沒有多少發言權。關於管理員(此處尤其指某位行政員)是否能夠一手遮天的問題,我想有過遭遇的自然會知道答案。如果中文 Minecraft Wiki 真的能夠做到長久以來虛無的「皿煮」的話,那我就在幕後為你們的成功慶祝吧。另外,好像看到有一名馬迷成功上任了管理員,這個也一定要祝賀一下,這是墜吼的!
命令描述頁面,把「示例」挪到「效果」與「輸出」之前
本主題或以下段落文字移動自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)
- 反對。首先明確「命令」下面的子頁面是手冊頁性質的,而不是教學性質的。而無論什麼手冊頁,示例都是放在最後,或者乾脆不放示例。
- 就比如,在runoob上描述函數的順序就是「描述」(對應「導言」),「聲明」(對應「語法」),「參數」,「回傳值」(對應「效果」和「輸出」)和「實例」(對應「示例」)。
- 在man7(甚至沒有示例)或者其他地方的類似內容基本也是同樣的順序。
- 另外,我 同意IcyPhantom的意見。--
Anterdc99(論·功) 2021年6月8日 (二) 04:51 (UTC)(最後編輯於2021年6月8日 (二) 04:58 (UTC)) - 這是壞的,因為抄示例不會讓新手變的更強……雖然大部分新手很可能沒有耐心看完語法。嘛,也算是一種矛盾,本來之前準備寫如何閱讀命令相關頁面的教學的,但是不太好寫就咕了,嗯。以及個人意見,新手要用好命令頁面,絕不應該一上來就往示例裏面看。--
Lakejason0(論•功) 2021年6月8日 (二) 05:23 (UTC)
- 順便我們有一個東西叫做目錄,如果新手想看的話完全可以直接點目錄就是。雖然我們都知道就算目錄擺在那裏我們也一次都不會點(真是矛盾)。--
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)
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)
