Minecraft Wiki

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

了解更多

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

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

關於首頁大段空白的問題

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

討論結果為 已應用新佈局


本人的多個裝置以及部分嘗試了查看首頁的群友在打開首頁的時候均會在「Minecraft簡介」和「本週頁面」底部顯示大量空白。這是否是一個需要處理的問題? North kun留言) 2022年6月18日 (六) 04:12 (UTC)

 支持:中文表達所需空間比英文要少,套用以前英文版的排版必然會存在空白。不過其實現代漢語的版本還算好,文言版的首頁空白那才是慘不忍睹。--Yzy32767/ 2022年6月18日 (六) 04:30 (UTC)
之前也不是沒討論過,當時提出來的時候沒人理。至於已經停止支持的遊戲,我個人的意見是寫上去並標註好。至於MCD和Legends,MCD由於在MCD Wiki首頁中已經寫了,但是在這裏不寫又不是很合適,所以我建議可以略寫一下;Legends也是相同的道理。--KaplanSteve  T/C 2022年6月18日 (六) 07:10 (UTC)
似乎是為了和旁邊的「開始遊戲!」對齊。--McplayerFS討論 | 貢獻) 2022年6月18日 (六) 14:12 (UTC)
可以考慮縮減「開始遊戲!」的高度,但是我還是弄不明白這些框的大小是在哪裏指定的,希望不要動CSS。--Yzy32767/ 2022年6月19日 (日) 01:08 (UTC)
英文版本的版本資訊是放在下面的,這樣就無需考慮其高度問題。但同樣的,就得考慮其他部分的內容寬度和高度問題。-- LakeJasonFace Lakejason0) 2022年6月19日 (日) 13:13 (UTC)
我不認為這是需要處理的問題。目前沒有插入新欄目的打算。--Lxazl5770zh.admin) 2022年6月20日 (一) 02:33 (UTC)
並不是「插入」的問題,而是重新整理,重新排版的問題。-- LakeJasonFace Lakejason0) 2022年6月20日 (一) 03:01 (UTC)
重新排版確實有必要,不過目前暫時沒有比較好的設計。有的話可以提出來。MysticNebula70 T  2022年6月20日 (一) 05:30 (UTC)
仿效en的排版其實也不錯,把你知道嗎換成每週頁面如何呢?-- LakeJasonFace Lakejason0) 2022年6月21日 (二) 04:04 (UTC)
 意見:en的「你知道嗎」板塊也有留白,然而如果把每週頁面替換進去的話,有可能會空間不足。我建議是要嘛限制一下每週頁面的字數,要嘛把「關於Minecraft」擴寫一點。--KaplanSteve  T/C 2022年6月21日 (二) 14:38 (UTC)(最後編輯於2022年6月21日 (二) 14:39 (UTC))
en主頁上的版本資訊一欄內容所佔空間顯然比zh的多,如果仿照其把版本資訊一欄的寬度擴展到整個頁面的做法,其高度將明顯減少。雖然我沒有具體試過,但觀感肯定不好。--AblazeVase69188討論 | 貢獻 2022年6月24日 (五) 12:57 (UTC)
 留言:瀏覽首頁及相關頁面(Minecraft Wiki/style)可知,首頁的欄目佈局的代碼見於MediaWiki:Gadget-mainpage.css,其中與首頁欄目佈局相關的內容如下:
目前的佈局 ultim_0建議的佈局之一
a
b c
d
e f g
h i j
a
b
c d
e f g
h i j
其含義是:當頁面寬度較寬(大於等於990px)時,將各欄目按右表1所示的方式進行排版。「Minecraft簡介」(#fp-2)和「每週頁面」(#fp-4)對應的就是b和d的位置。
綜上所述,透過修改MediaWiki:Gadget-mainpage.css的相關內容(已在上文標出),即可在不改變首頁原始碼的情況下變更頁面排版形式。
 關於重新排版:經本地測試,將佈局改為右表2所示可明顯避免出現過多空白。
但是根據群友(既然北鯤使用了這個稱呼,那麼用在這裏應該也沒問題)反映,這會導致「每週頁面」在部分寬屏裝置上出現排版異常的情形(在下的畫面只有1366px寬,難以預覽大畫面下的情形),建議一併修改Minecraft Wiki/weekly/style。--ultim_0 ( USER | TALK | WORK ) 2022年6月21日 (二) 16:08 (UTC) (最後編輯於2022年6月25日 (六) 18:39 (UTC))
我根據Ultim的提案製作的最終提案如下。
還有一些其他的方案。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 06:07 (UTC)(最後編輯於2022年6月22日 (三) 06:42 (UTC))
由於測試過程中發現了一些新問題,在此說明一下問題以及一些新的提案。
問題1:首頁的每週頁面圖片有浮動,會把文字擠到一邊。這個在上方提案中修改為了居中來解決問題。
問題2:版本資訊一欄方格下方的列表觀感不好,詞彙會斷開,而且橫向列表在列表項目不多時展示效果較差。
基於以上發現的兩個問題,我又查看了其他語言站點的首頁,相關情況如下:
英文:版本資訊單獨出一整個橫欄,所有的購買連結和版本號放在一起。
西班牙語:重新設計了首頁,將版本資訊刪除。
由於版本資訊寫全似乎冗餘,在即時通信軟件中部分使用者對EN的目前方案給出的意見是負面的。西班牙語目前沒有人評論。大概是這樣。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 06:48 (UTC)
韓國語wiki首頁的佈局 ultim_0建議的佈局之二
a
b c
關於外來詞
e f g
h i j
a
b c
d
e f g
h i j
注意到韓國語wiki相對於en也對首頁排版進行了小幅度修改,如右表1所示,其中的「關於外來詞」是其獨有的欄目,對應zh的「每週頁面」,除此之外的各個字母表示的內容與zh相同。根據其樣式給出了方案二,如右表2所示,該方案可以避免方案一中「每週頁面」欄目因為寬度過小而出現排版異常的情況,因此無需同時修改該欄目的樣式。謹供參考。--ultim_0 ( USER | TALK | WORK ) 2022年6月22日 (三) 07:14 (UTC) (最後編輯於2022年6月25日 (六) 18:39 (UTC))
我在Editcopy中修改了一部分代碼,將購買連結和試玩連結直接加入到了版本資訊方格中。這樣就可以解決問題2(透過直接刪除、轉移到版本方格內的方式解決)。由於這樣的變更會導致先前的版本號合併不再可行(連結顯示會不完整),我暫時先放在那邊。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 08:01 (UTC)
在處理橫向列表的時候發現了EN的一個做法,就是把購買連結寫在對應的頁面,而不是直接寫到首頁。這樣也更便於維護。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 07:24 (UTC)

沒有人討論嗎?那我再把方案二需要修改的地方指出來:

至於版本資訊(「開始遊戲!」)的處理,個人並無較好的提案,建議將購買和試玩的連結移動到對應頁面的{{infobox}}中。

以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月6日 (三) 10:33 (UTC) (最後編輯於2022年7月6日 (三) 12:03 (UTC))

然而這個方案裡的「Minecraft簡介」留的空間太少,個人建議與旁邊的「開始遊戲」同寬。--Yzy32767/ 2022年7月6日 (三) 10:57 (UTC)
不太可能,那樣解決不了Minecraft簡介的空白過多吧?-- LakeJasonFace Lakejason0) 2022年7月6日 (三) 11:00 (UTC)
已經足夠了,在寬度為1366px的畫面上,該方案中的簡介欄高度與版本資訊相同。--ultim_0 ( USER | TALK | WORK ) 2022年7月6日 (三) 12:03 (UTC)
其實可以把Minecraft簡介改成en的Minecraft video game樣式,這樣無需改動佈局即可填充空白,我會在稍後將代碼放至editcopy下。旁邊的圖片尚未上傳,我會先注釋掉。--Yzy32767/ 2022年7月15日 (五) 07:28 (UTC)
 同意Yzy32767的做法,少去了更新佈局的麻煩,並且這樣也可以避免較多的留白。只是這樣的話需要保證每週頁面的內容不多不少(本週的烈焰使者就是個例子)才能避免留白過多或超出範圍。--KaplanSteve  T/C 2022年7月15日 (五) 07:38 (UTC)
沒事,周頁差不多都是這個長度,這週的甚至還超出了一點,導致1003寬度下版本留白過多。--Yzy32767/ 2022年7月15日 (五) 09:08 (UTC)
將代碼寫入editcopy後遇到了以下問題:
  1. 版本資訊處在2036px寬度後開始出現較嚴重的留白。
  2. 移動端窄視圖下「Minecraft遊戲」的右側圖示顯示過小。--Yzy32767/ 2022年7月16日 (六) 05:13 (UTC)
或許可以借鑑一下德語和西班牙語的首頁。有使用者提出「重要的東西除了版本號以外都縮在一個角落裏,換做誰也不想找。」「版本資訊圖示過大,和下面的小字相比就是失衡的。」而德語和西班牙語的首頁完美解決了這個問題,將重要的頁面如交易、釀造,包括MCD的內容都放在了首頁,版本資訊也使用了小圖示。只是如果我們也這麼做,可能會涉及到MCD的首頁的改動問題(比如把內容合併到主首頁或重新佈局)。並且這麼做的話等於現在為止做的全部都是白費。
總之,保留現在的設計也可以,但是要解決Yzy32767提出的問題;也可以推倒重來,做成像德語一樣的的首頁,只是不需要那麼多東西,可以刪減一些。如果採用德語的設計,個人建議把版本資訊收窄,放到右邊(德語的留白太多),然後把「你知道嗎」板塊改為「本週頁面」,並放到5個遊戲介紹(或者像西班牙語一樣拆開來變成7個)下面。
以上是我的提議。--KaplanSteve  T/C 2022年7月16日 (六) 05:29 (UTC)
問題1已透過flex-shrink: 0;樣式解決。為了讓圖示在移動端不佔據過多空間,對其進行了一定程度的縮小。此舉也使得整個「Minecraft遊戲」的高度降低,問題2稍有改善。然而考慮到主頁的版本區(「開始遊戲!」)沒有試玩和下載連結,留白較editcopy會更嚴重,故建議重新設計「開始遊戲!」板塊。--Yzy32767/ 2022年7月16日 (六) 23:01 (UTC)
版本板塊預計變更內容如下:
  1. 取消田字佈局,改為直接豎向排列。
  2. 取消每個版本的背景顏色,以分割線分割各版本。
  3. 文字居左(「更多」除外)。
  4. 將平台呈現方式從上圖下字換為圖文同行(需變更/platform,個人沙盒裡已有實驗性代碼)。
  5. 移除下方hlist。
群內已有預覽圖。--Yzy32767/ 2022年8月4日 (四) 09:58 (UTC)
版本的變更已在editcopy中完成,還有其他的建議請提出。--Yzy32767/ 2022年8月7日 (日) 04:43 (UTC)
Apple Safari瀏覽器在窄屏移動端視圖下,「Minecraft遊戲」裏面所有flex容器框都會異常拉伸,超出畫面左右兩邊,原因未知。--Yzy32767/ 2022年8月13日 (六) 01:34 (UTC)
已解決。目前還需要處理深色模式的適配,以及整理代碼。--Yzy32767/ 2022年8月26日 (五) 01:05 (UTC)
 已更新首頁。如有問題請開新話題。MysticNebula70 T  2022年9月4日 (日) 03:52 (UTC)

有關格式指導中圖像介紹的說明文字的末尾句號用法之問題與相關提議

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

討論結果為 將相應表述寫入格式指導


行政員Lxazl5770在處理使用者Louis0921gee有關畫廊中說明文字句號的編輯時,引起了該使用者對格式指導相關用法的疑問。

經查詢,此說明於第一個版本寫入格式指導,因此其實算是歷史悠久的。相關疑問在中文Minecraft Wiki使用者集中的地方也出現過數次(據使用者口述可能有四次之多),而根據後來各使用者的討論,發現由於這些疑問的討論,各使用者甚至管理員似乎存在一個錯誤的印象,即認為這個問題已經解決,且解決方案是按照中文維基百科目前的方案(也就是「存在於圖表中的短語式說明文字,其中部內容可用逗號,但末尾不用句號。就算是有些時候說明文字內容比較長,在前面的語段中已出現句號,最後的結尾處仍不用句號。」)執行。但這不是事實,這沒有寫入格式指導,且事實是這些疑問都是不了了之,並沒有得出結論。

由於執行標準不一,實施情況不同,根據維基百科標點符號用法(中華人民共和國國家標準GB/T 15834-2011)的相關說明,我在此提議變更格式指導有關圖像介紹的說明文字的末尾句號用法的說明:

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

新:圖像介紹的說明文字末尾不用句號。就算是有些時候說明文字內容比較長,在前面的語段中已出現句號,最後的結尾處仍不用句號。

我的提議如上。希望各位使用者參與討論。-- LakeJasonFace Lakejason0) 2022年6月29日 (三) 10:38 (UTC)(最後編輯於2022年6月29日 (三) 10:55 (UTC))

 我的提議:一律不用句號,並且將原本的說明文字精簡到一句話以內。以簡化繁。--Lxazl5770zh.admin) 2022年6月29日 (三) 13:43 (UTC)
這種要求不一定都能實現。建議將我的提案作為保底規則,然後將您的提議作為優先規則。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 07:11 (UTC)
由於管理員提出了新的意見,我的新提案如下:
舊:圖像介紹末尾不應有句號,除非語句是一個完整的句子。
新:圖像介紹的說明文字應精簡到一句話以內。若且唯若圖像內容足夠複雜,需要使用超過一句話才能說明清楚時,可以超過一句話,但最後的結尾處不用句號。即使說明文字在多句話的前面的語句中已出現句號,最後的結尾處仍不用句號。
以上是我的新提案。如有更好的表述也歡迎提出。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 10:43 (UTC)(最後編輯於2022年6月30日 (四) 10:44 (UTC))
這應該是兩條:
  1. 圖像介紹應精簡到一句話,圖像內容足夠複雜、說明清楚需要超過一句話的除外;
  2. 圖像介紹末尾不應有句號,即使說明文字較長,前面的語段已出現句號。傳入神經元權限|討論|貢獻|日誌) 2022年6月30日 (四) 17:09 (UTC)
應該要求編者盡力把圖像介紹縮短至一句話。如果句末不加上句號,在前面的句子中又出現了句號,會顯得有點奇怪。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 01:06 (UTC)
說不清楚的怎麼辦?這種用法是國標,不奇怪。傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 02:10 (UTC)
我所提到的「奇怪」指的是對某些讀者來說不適應這種用法。當然如果一句話說不清楚,多加幾句話也沒問題。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 02:38 (UTC)
圖像描述過長還會影響網頁觀感(尤其是移動端)。若圖像內容足夠複雜,我建議先寫簡要介紹,再用注釋加上詳細描述。IbuckeeetFaceIBUCKEEET ·· 2022年7月2日 (六) 05:01 (UTC)
在本來就是說明文字的地方再加注釋,我不是很能接受這種做法。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 06:07 (UTC)
由於此議題沒有進一步推進,我再次提出提案,希望各位給出意見:
舊:圖像介紹末尾不應有句號,除非語句是一個完整的句子。
新:圖像介紹應精簡到一句話以內,圖像內容足夠複雜、說明清楚需要超過一句話的除外。即使圖像介紹的說明文字較長,其中靠前的語句已出現句號,末尾也不應有句號。
希望提案採納。-- LakeJasonFace Lakejason0) 2022年7月6日 (三) 10:52 (UTC)
 支持。--AblazeVase69188討論 | 貢獻 2022年7月9日 (六) 13:48 (UTC)
由於沒有更多反對意見,且先前的疑問基本已解決,相關提案 已應用。-- LakeJasonFace Lakejason0) 2022年7月16日 (六) 08:21 (UTC)

【重要】關於本wiki的封鎖準則

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

討論結果為 已設立封鎖準則


目前,儘管本wiki已經有了一則詳細的條例,但在處理封鎖方面仍無具體的準則。

為此,本人以行政員的身份擬定了一份封鎖準則的草案希望能夠聽取各使用者的意見並加以改進。

此事項相當重要。望各使用者積極建言獻策。祝各位編輯愉快。--Lxazl5770zh.admin) 2022年6月30日 (四) 12:50 (UTC)

粗略查看了一下。目前該準則缺少對於先前使用較多的「提示性封鎖」這一用法的說明。同時,我認為應當在該準則開頭以較為親切的口吻,使用Msgbox說明好,封鎖是wiki維護與破壞防治中靠後的環節,管理團隊不會對(絕對否定的說法可以自行修改為較為緩和的語氣)輕微的不熟練操作採取封鎖這一手段,等類似的內容。同樣,應該在Wiki條例當中提及違反條例會按照封鎖準則封鎖。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 12:55 (UTC)
我已經根據你的說法進行了適當修改。--Lxazl5770zh.admin) 2022年6月30日 (四) 13:16 (UTC)
  • 「目標使用者無視任意警告(例如撤銷編輯或討論頁警告)」「管理人員在條件允許下應當在目標使用者的討論頁裡留下{{User warning}}以提醒該使用者注意遵守Wiki條例」這些前戲應該統一,例如目標使用者無視管理人員在目標使用者討論頁留下的{{User warning}}。
  • 「匿名使用者不允許永久封鎖」推不出「封鎖時長應當不超過1年」,留後半句就夠了。
  • 未盡事宜應該有個限制,例如不違反條例和applicable law的行為不應受到懲罰性封鎖。
  • 為什麼設定那些不保留討論頁申訴權的情況?申訴權就是被封鎖使用者的權利,濫用申訴權的才應該撤銷。傳入神經元權限|討論|貢獻|日誌) 2022年6月30日 (四) 17:09 (UTC)
第二點把關聯詞移除掉就沒問題了。其他的都算有道理。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 18:38 (UTC)
 留言:對於使用可視化編輯器破壞頁面原始碼的行為,是否應當在封鎖摘要中說明?--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 02:28 (UTC)
我建議是先警告,若忽略警告再考慮封鎖。--KaplanSteve  T/C 2022年7月1日 (五) 02:33 (UTC)
已經修改。特別地,部分違規情況屬於極其惡劣的情況(例如發廣告和利用傀儡破壞),不應當給予其申訴權。--Lxazl5770zh.admin) 2022年7月1日 (五) 03:01 (UTC)
只要違反格式指導就給予一天封鎖太過嚴重。違反格式指導的理論上沒有封鎖的必要,只需要給予提醒即可。屢次不改本身就違反條例。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:08 (UTC)
以及,利用傀儡破壞本身並不絕對屬於極其惡劣的情況(取決於做出的破壞行為本身),因此不保留申訴權利並不合理。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:15 (UTC)
我寫了一下Msgbox的內容,希望加入頁面開頭。表述都可以適當調整。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:54 (UTC)(最後編輯於2022年7月1日 (五) 11:54 (UTC))
 特殊情形:對於僅涉及單個頁面的破壞行為(如導致苦力怕(消歧義)被半保護的事件),應當靈活處理。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 09:40 (UTC)
註冊使用者「插入具有營利性質的廣告」立即無限期封鎖——這樣做是不是太嚴了?我承認,廣告機械人建立帳號就是為了發廣告,但是有些開服玩家可能也寫wiki,他們會在使用者頁面宣傳自己的具有盈利性質的伺服器,而沒有注意到Wiki條例。TripleCamera留言) 2022年7月1日 (五) 11:48 (UTC)
可以在討論頁申訴吧?-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 11:59 (UTC)
無限期封鎖也可以透過申訴縮短封鎖時長嗎?無限期封鎖給人一種行為非常惡劣的感覺。TripleCamera留言) 2022年7月1日 (五) 12:07 (UTC)
這是未盡事項,所以我也不清楚。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 12:08 (UTC)
需要直接永久封鎖的是最惡劣的違規行為。如果是因為多次違規而導致永久封鎖的,由於三番屢次勸阻無效,一般不會出現減刑情況。--Lxazl5770zh.admin) 2022年7月1日 (五) 12:45 (UTC)
這些事應該寫清楚。 建議:不得因被封鎖使用者申訴減刑至低於適用細則最低標準。傳入神經元權限|討論|貢獻|日誌) 2022年7月1日 (五) 13:22 (UTC)
已經補充一條。--Lxazl5770zh.admin) 2022年7月1日 (五) 14:05 (UTC)
意思跟我的想法是反的,不過按認錯態度量刑也對。傳入神經元權限|討論|貢獻|日誌) 2022年7月1日 (五) 16:07 (UTC)
在使用者頁面另說,但是在主名字空間建立此類頁面是絕對不能接受的,見頁面「夢想世界」的日誌。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 12:09 (UTC)
有道理…我在這裏只討論了一種比較特殊的情況。TripleCamera留言) 2022年7月1日 (五) 13:47 (UTC)
插入商業性質廣告是Fandom使用條款中的規定的禁止行為,是極其惡劣的破壞行為,因此必須直接永久封鎖而不給予申訴權。--Lxazl5770zh.admin) 2022年7月1日 (五) 12:52 (UTC)
重罰更需要保留申訴權。傳入神經元權限|討論|貢獻|日誌) 2022年7月1日 (五) 13:24 (UTC)
Gamepedia是建立在Fandom的基礎上的,在Fandom進行活動表明使用者「已完全閱讀並同意Fandom使用條款」。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 13:33 (UTC)
本wiki建立於Fandom提供的wiki農場之上。任何違反Fandom使用條款的行為均屬於嚴重違規行為,不予申訴。--Lxazl5770zh.admin) 2022年7月1日 (五) 14:06 (UTC)
這不對吧,為啥嚴重違規不予申訴?申訴不是認錯,就是被認為嚴重違規的才更需要申訴權,如果嚴重違規不給申訴那輕微違規更不用申訴了。傳入神經元權限|討論|貢獻|日誌) 2022年7月1日 (五) 16:07 (UTC)
這是原則性的問題,沒有退讓或者妥協的可能。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 16:14 (UTC)
同上,Fandom服務條款是必須遵守的法律性文字,不是可以退讓和妥協的事情。任何違反Fandom使用條款的使用者屬於跨越紅線級別的違規行為,是極其嚴重和惡劣的行為,嚴重情況下甚至會有觸犯現實法律的行為。因此不予申訴權利。--Lxazl5770zh.admin) 2022年7月1日 (五) 17:02 (UTC)
Fandom服務條款是紅線,違反Fandom使用條款極其嚴重,這都沒有爭議。問題是認定嚴重違規需要給申訴權,這也應該是原則性的。傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 02:10 (UTC)
我看了下,目前草案上規定的立即永久封鎖的行為都是違反Fandom使用條款的行為,因此不予申訴權。--Lxazl5770zh.admin) 2022年7月2日 (六) 02:15 (UTC)

┌──────────────────────────┘
怎麼回到草案了?現在問題就是違反Fandom使用條款這種嚴重違規應該保留申訴權。傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 02:31 (UTC)

 你難道是想要給某些在使用者檔案頁裡發「新xx娛樂」的人求情嗎?在Fandom發佈小廣告的使用者,無一例外都被永久封鎖了,你卻還想著給這種蠹魚網開一面,這無異於割地求和。對敵人仁慈就是對自己殘忍,請深思。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 03:16 (UTC) (最後編輯於2022年7月2日 (六) 03:58 (UTC))
我說了這是極其嚴重的行為沒有爭議,沒人想對這種人網開一面。這和現在的話題有啥關係?傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 04:09 (UTC)

如果你的意思是禁止編輯討論頁而要求被封鎖使用者在專門的渠道申訴,這沒問題。傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 04:13 (UTC)

違犯使用條款的行為應目前往support.fandom.com進行申訴,不在本wiki的轄域內。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 04:19 (UTC)
剛才我查閱了使用條款:「您同意不會:發佈任何商業性廣告或潛在性的商業資訊。」此事屬實。TripleCamera留言) 2022年7月1日 (五) 13:47 (UTC)
 建議:IP位址可更換性強,對其的普通或輕微違規行為單次封鎖時長不應超過一週,嚴重或屢教不改的違規行為不應超過一個月。此外,還可以加上有關註冊使用者和匿名使用者封鎖時長具有差異的原因說明,避免被誤解。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 01:14 (UTC)
針對此前幾次頑固的IP封鎖,我覺得一個月很快就過去了,部分IP位址解封後仍然繼續作案,因此我考慮加到1年。--Lxazl5770zh.admin) 2022年7月2日 (六) 01:55 (UTC)
對於此,我 建議在匿名使用者首次違規時採用我上方提出的封鎖時長上限,每多違規一次就把上限上調一級。對於屢教不改的可以一次將上限上調到六個月或一年。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 04:07 (UTC)
 建議:在Wiki條例中,加入「禁止違反Fandom服務條款」的要求,列舉「插入盈利性廣告」等行為,並放在第一位(Minecraft條款放在第二位)。在封鎖準則中,把所有「永久封鎖且不予申訴」的懲罰進行醒目標記。既然懲罰非常重,那麼應事先警告使用者。--TripleCamera留言) 2022年7月2日 (六) 01:49 (UTC)
關於違反Fandom使用條款這一點,本wiki以及其他託管在Fandom的子網站都必須嚴格遵守Fandom使用條款。wiki條例只對本wiki進行特別的條例制定,不能完全替代Fandom使用條款,因此對於Fandom使用條款不再重複敘述。特別地,「插入盈利性廣告」這個情況在本wiki發生比較頻繁,因此為了使得部分不自覺查閱Fandom使用條款的使用者得知此事,特意寫在本wiki條例裡。--Lxazl5770zh.admin) 2022年7月2日 (六) 02:01 (UTC)
那麼,能不能給相關條例一個著重顯示呢?如果真的要永久封鎖+不予申訴的話(是不是要這麼做目前仍在討論中),應該提前告訴使用者這種行為是「極其嚴重和惡劣的」,並警告他們後果有多麼嚴重。--TripleCamera留言) 2022年7月2日 (六) 04:05 (UTC)
我想這個已經超出了本封鎖準則的範疇。另一方面,「Wiki不治眼瞎」。--Lxazl5770zh.admin) 2022年7月2日 (六) 06:47 (UTC)

本條例擬定於7月11日(一)生效。屆時將正式成為條例文字並不作進一步變更。現在處於商議期,還請各位繼續提議。--Lxazl5770zh.admin) 2022年7月3日 (日) 15:03 (UTC)

使用模板的大小寫與縮寫要求、以及部分模板及其參數的使用規範問題

我於數月前查看版本634496時,發現該編輯將{{only}}{{in}}等模板中的英文字母全部改為了小寫,並將使用了{{editions}}模板參數的文字進行了縮寫(如把java改為了je,bedrock改為了be)。此後,我也養成了在編輯頁面時順手對這些模板進行類似改動的習慣。不過到今天為止,我也不太清楚這麼做究竟有什麼意義,可能是為了統一格式。

首先,以{{in}}模板的使用為例:區分大小寫,我見到過三種用法:{{in}}、{{In}}還有{{IN}},是否應該把它們全部統一為小寫?例如,{{IN|BE}}統一為{{in|be}}。我的建議是將其全部統一為小寫,模板中的文字不作大小寫統一。

值得注意的是,在普通的頁面編輯中,提供的模板自動補全功能(例如,可以在編輯頁面時的編輯區內輸入{{ab,等待數秒就會出現一個以該字串為開頭的模板列表(包含重新導向),點擊任意一個即可將其自動補全為完整的模板名稱)會自動將模板的首字母大寫;可視化編輯也有可能在使用模板時將模板首字母大寫或全部大寫。

其次,部分模板具有其縮寫形式,如{{editions}}對應的{{el}}。那麼,在使用模板時,應該使用其全拼寫形式還是縮寫形式?我的建議是全部統一為縮寫,以減少編者的負擔。同時也需要注意,上文提及的模板自動補全與可視化編輯都會輸出完整的模板名稱。

第三,上述為例的{{in}}和{{only}}模板均引用了{{editions}}參數,以這些參數中最常用的java和bedrock為例,它們對應的縮寫分別為je和be。同上,在使用這些參數時,應該使用其全拼寫形式還是縮寫形式?我的建議也是全部統一為縮寫。與此同時,可視化編輯也可能把這些參數強制轉換成完整拼寫,可參見版本661837對第244行文字的變更。

第四,{{only}}模板接受short參數,該參數啟用時會將對應版本名稱縮寫,如將[僅基岩版]轉換為[僅BE]。那麼,此參數存在的意義是什麼,應該在什麼地方使用?我在這方面暫時沒有什麼想法,不過在en對於此模板的討論上,有人提到這個參數(由於我個人所限,我只從裏面提取到一句「把版本名稱縮短是一個好主意」),其他有能力的使用者可以去看看,能不能從那裏得到什麼有用的觀點。

第五,{{Sprite}}相關模板包括{{BlockSprite}}等,其作用是在頁面中加入一個特定的「精靈圖」。那麼,對於在這些精靈圖前後的文字,是否應該以一個空格將圖片和文字隔開?以{{BlockLink}}為例,使用dirt參數會輸出泥土的精靈圖、一個空格和泥土的連結,這就向我們展示了一般情況下,這類模板的使用需要在圖片後加上一個空格與文字隔開。與之對應,圖片的前面如果有文字,是否也應加上一個空格與之隔開?我的建議是,這類精靈圖的前後如果有文字,就要加上一個空格與之隔開,如果其前後為標點符號則不需要。

我發起上述議題的原因,主要是看到Wiki上仍然有很多地方的模板使用情況不統一,而又不知道是否應該統一;並且有時候我也對尋找並變更頁面中的大小寫、縮寫和{{editions}}參數感到厭煩,這些工作明明可以交給機械人來完成。但是,正如上文部分地方所提到的,官方提供的模板自動補全功能和可視化編輯的部分輸出結果又與我上面所提出的部分建議矛盾,是否應該採用還有待討論。

以上。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 09:28 (UTC)

首字母大小寫個人認為沒必要統一吧。不過真的要統一,還是小寫好一點,畢竟這樣編輯也方便。Sprite前面加個空格會美觀一些,但是MCD的裝備一類的sprite由於尺寸較大,甚至出現了空格過大的情況,這一點還是需要其他人考慮。至於其他問題我再考慮。—KaplanSteve  T/C 2022年7月2日 (六) 09:47 (UTC)
{{IN}}等模板有大小寫的原因是英文中有大小寫區分的必要,中文則沒有。出於方便(搬運進來或者搬運出去)考慮,此類區分大小寫的情況下,建議是「翻譯成英文的時候需要大寫的」大寫,反之小寫。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 09:48 (UTC)(最後編輯於2022年7月2日 (六) 09:51 (UTC))
那麼在en那邊區分這類大小寫,有沒有具體規則或格式指導?最好能把這些規則列入到本議案最終的解決方案中。--AblazeVase69188討論 | 貢獻 2022年7月3日 (日) 00:50 (UTC)
至於是否是要統一拼寫,個人認為沒必要,用得順手就行,這不會帶來太大的負擔,反而是強行統一會失去模板別稱的價值。至於Only模板,在Infobox裏面我會覺得要縮寫,還有一個用例是例如「某某某共有6[僅JE]/9[僅BE]個」,像這樣的,其他地方寫全也不會和英文一樣長得太長,改不改都沒什麼必要。Sprite模板我記得本身也就不應該單獨使用,我沒有辦法討論這裏的用例。強行前置空格會造成原始碼觀感差。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 09:55 (UTC)(最後編輯於2022年7月2日 (六) 10:06 (UTC))
我此處所說的「Sprite模板」是用來泛指包含BlockLink這一類模板的集合的。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 10:51 (UTC)
 留言
  1. 原則上首字母大小寫以及空格與下劃線的相互替換並不會影響被調用的模板、頁面或者使用者(例如user:ultim_0等效於User:Ultim 0),個人建議不做任何變更。
    • 而部分模板的參數同時接受大小寫(甚至是混合輸入),是因為這些模板在處理對應參數時使用了魔術字{{lc:}}來將輸入的參數轉化為全部小寫(如{{lc:Be}}會顯示為be),對於這些模板參數的大小寫,個人建議也不做任何變更。
  2. 至於同義參數,個人建議依使用者輸入習慣而異,與對模板別名的態度一樣,也不做任何變更。
  3. 至於{{only}}使用參數|short=的情形,個人認為應當在表格等內容擁擠的地方使用,以避免佔用過多頁面空間影響觀感。
  4. Sprite模板相關:個人認為在文段中,應當在Sprite後以及Sprite之間加入空格,無論是否為了單純列舉Sprite。
以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 09:59 (UTC) (最後編輯於2022年7月2日 (六) 10:18 (UTC))
所以目前大致的共識就是第一至四條沒有採用的必要,而第五條仍需討論。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 10:53 (UTC)
前三條沒啥不良影響,沒必要改。short的縮寫不夠標準,不如全稱好理解,建議能不用就不用。Sprite的空格應該是這類模板的標誌,模板外不用。傳入神經元權限|討論|貢獻|日誌) 2022年7月2日 (六) 12:43 (UTC)
的確部分讀者可能對short參數輸出的縮寫不是很熟悉。不過在Minecraft Dungeons等較長的版本名稱的使用上,顯然MCD比Minecraft Dungeons更短,在這些情況下還是可以更多地考慮使用縮寫。--AblazeVase69188討論 | 貢獻 2022年7月3日 (日) 00:50 (UTC)
 支持以上1、2、3的觀點,事實上我也是這麼做的。5的話我不建議加空格。--McplayerFS討論 | 貢獻) 2022年7月2日 (六) 12:53 (UTC)(最後編輯於2022年7月4日 (一) 04:27 (UTC))
請問您是否不慎在此處將「第四點」和「第五點」調換了?--AblazeVase69188討論 | 貢獻 2022年7月9日 (六) 13:56 (UTC)
目前貌似有部分編者不太理解我所說的第五點的內容,我在這裏舉個例子:
「村莊可以在平原生態域生成。」與:
「村莊可以在 平原生態域生成。」的區別。
{{BlockLink}}等模板中在精靈圖和連結文字之間加入了一個空格,因此對應地,如果精靈圖前面有文字,那也應該在它們之間加上一個空格。的確,{{BlockSprite}}等只包含精靈圖的模板不經常使用,但在使用時仍建議遵循{{BlockLink}}等模板加入空格的做法。不過由於部分情況下精靈圖前面沒有文字,不需要加上空格,而新增的參數可能會增加模板使用的複雜程度,因此目前可能只能採取有必要時在精靈圖前面加一個空格以將文字與之隔開的做法。--AblazeVase69188討論 | 貢獻 2022年7月2日 (六) 15:13 (UTC)
這麼做的問題仍然是原始碼層面的一個不太好看(因為沒有其他場合會需要一個額外的空格)。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 15:23 (UTC)
 提醒:一般來說並不建議在正文的文字段落內使用各種sprite連結模板,因為實際上觀感並不會比普通文字更好。MysticNebula70 T  2022年7月2日 (六) 16:07 (UTC)
既然這樣,如果格式指導裏面暫未提到相關內容,那是否可以在格式指導中加上一句「不建議在正文的文字段落內使用各種sprite連結模板」,並對Wiki現存的在文字段落內使用的Sprite連結模板進行替換,這樣就可以避免此處第五點所提到的情況?--AblazeVase69188討論 | 貢獻 2022年7月3日 (日) 00:50 (UTC)
 需要分情況討論。如新手手冊中有以下的敘述:

你可以取得的工具基於材料可以有不同的品質,這些工具包括,分別用於挖掘石製、木質和沙土類方塊。第四類工具是,其略有不同——一般會到後面使用,作為耕種的一部分,不過鋤可以用於更快地破壞輕的方塊(如樹葉)。類似於工具,同樣可以有不同的品質,但是用於攻擊動物和怪物而非破壞方塊。六種品質分別是木塊石頭鑽石獄髓,但是第一天你通常只能得到木塊和石頭,或許還有鐵。更精緻的工具可以更快破壞方塊,且耐久度更高,更精緻的劍可以造成更高的傷害。尤其對於鎬,很多方塊只有至少特定品質的工具才能收集,否則不會掉落任何掉落物:木鎬可以收集石頭煤礦,但是鐵礦青金石礦至少需要使用石鎬,更高級的礦物(如金和鑽石,第一天也不太可能遇到)至少需要鐵鎬才能挖掘。金是特例,儘量避免依賴於使用金質的工具、劍或者盔甲,因為金質工具的效率雖然很高,但耐久度卻很低。如果你在某些結構中的儲物箱(如廢棄傳送門)裡發現了金質物品,可以儲存起來,以後再使用。如果剛進入遊戲就發現了的金,可以僅做臨時防禦,有好裝備(鐵質及以上)了之後立刻更換。

該段落中使用了較多的sprite,因為新玩家不一定明白教學中提及的物品在遊戲中的樣貌,雖然可以透過點擊文段中的連結進一步查看,但是較為不便,因此建議在教學頁面適當保留。--ultim_0 ( USER | TALK | WORK ) 2022年7月4日 (一) 05:02 (UTC)
依上述討論,現列出解決草案如下:
1. 第一點、第二點、第三點不採用,各編者可保留原有使用習慣,不必強制統一。
2. 第四點,對於全稱過長的Minecraft Dungeons和Minecraft Dungeons Arcade,可以分別縮寫為MCD和MCDA。其他的縮寫儘量不使用;或只在表格等空間窄小的地方、較短的句子或詞組中使用。
3. 第五點,可以在格式指導中加上一句「不建議在正文的文字段落內使用各種sprite連結模板」,以避免第五點所提到的問題出現。如果有特殊情況需要在文字段落內使用,在精靈圖的前面不需要加入空格。
七日後將依新的討論給出最終解決方案。(六日後我才能再次開始活躍。)--AblazeVase69188討論 | 貢獻 2022年7月3日 (日) 09:36 (UTC)
現根據最新討論,給出最終解決方案如下:
1. 第一點至第四點的解決方案與草案相同,具體內容見上方。其中第四點的格式標準擬寫入{{only}}模板的文件頁面。
2. 第五點,在格式指導中加上一句「一般不在正文的文字段落內使用各種Sprite連結模板,教學頁面除外。在Sprite的前面不需要加入空格」。
如有其他意見請在三日內提出。--AblazeVase69188討論 | 貢獻 2022年7月11日 (一) 01:51 (UTC)
 已完成加入上述說明的工作,不過我還有一個建議在此提出:
原本我是因為看到了模板中精靈圖和文字中間的空格,才採用在Sprite前面加入空格的做法的。既然為了原始碼層面的美觀而不在Sprite的前面加入空格,那麼為了統一是否應該將各種Sprite連結模板中精靈圖和文字中間的空格移除?--AblazeVase69188討論 | 貢獻 2022年7月16日 (六) 01:33 (UTC)
這是模板的特性,不需要統一。傳入神經元權限|討論|貢獻|日誌) 2022年7月16日 (六) 07:05 (UTC)
 反對:如果去除空格會影響頁面的美觀性,如平原平原。--McplayerFS討論 | 貢獻) 2022年7月16日 (六) 09:08 (UTC)
 支持,後空前不空實在不太美觀。如果過於緊湊也可以前後都空。--Yzy32767/ 2022年9月24日 (六) 02:16 (UTC)

對parity一詞翻譯為趨同這一議題的疑問

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

討論結果為 維持目前譯名


兩個支持其他中立,這是不是一種共識呢?我覺得有待商榷。

自相關操作開始實施之後,我和其他的wiki使用者將相關的意見發佈到了各個地方(包括SPXX,這個是Mojira錯誤的一個第三方翻譯服務)和MCBBS(我的世界中文論壇)的新聞群(這是會翻譯到parity的地方)。

從我收集到的結果來說,沒有參與過討論的人對這一提議都表達的是不滿意,不願意服從。這對標準化是不利的,標準化的意義是在於,大家有一個共同適用的標準,而對於原版內容來說,這個共同是透過直接加入遊戲來保證的,其他的科技術語會是透過各種渠道進行宣傳。如果這個詞語不能夠達到目的,而且這個議題的結果其實遠遠不能稱得上是一個「共識」,那麼我在此提出異議,建議延緩這一議題的進行。如果這個議題的結果是無共識,請將相關詞彙的情況凍結。

補充:這個話題的產生只是因為wiki目前的「准許」的得出似乎不能夠代表wiki編者的意見,因此才提出的,而且提出的目的也只是希望暫緩這一操作,不是說對趨同一詞的反對。有關這個詞為什麼要翻譯成趨同,趨同的好處等等,這些請參考#請求敲定「parity」一詞的標準譯名為「趨同」,我不再贅述,總之理由是算充分的。

再補充:這個議題希望得到的是更為明確的同意或反對,或者是相關疑問的解決。

再再補充:本議題只是希望達成wiki編者之間的共識。其他地方不算在內。我對上述議題的疑問僅限於准許在較多中立或疑問的情況下被給出這一事實。

-- LakeJasonFace Lakejason0) 2022年7月3日 (日) 14:09 (UTC)(最後編輯於2022年7月5日 (二) 04:09 (UTC))

 中立,我反覆閱讀該討論,我還是沒看懂趨同的定義,是我英語不好還是因為我在台灣用語不同的關係ouo。總覺得英語搞那麼模糊,我們真的需要準確翻譯嗎?--Impulse Command Block 乳液Louis 對話 •貢獻 2022年7月4日 (一) 14:50 (UTC)
不從正確性的角度為前提討論,自然會得出像你這樣的結論。這也是MCBBS那邊詢問的結果。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 06:25 (UTC)
根據目前本人掌握的資料,看待這個問題的使用者可以分為三個群體:基岩版開發者、Java版開發者、其他人。基岩版開發者不用多說,多數贊成使用這一翻譯,但是Java版開發者不贊同,並且只是給出了「不是人話」這種無意義的理由,並且雙方翻譯者並不能很好地一起交流。其他人則是「好聽就行」。
我不認為這個議題會得出什麼共識。現在要解決的問題已經不是Parity怎麼翻譯的問題,而是兩個版本的開發者之間的偏見存在的問題。然而這個問題不可能本wiki能夠解決,偏見會一直存在。
實際上,「待同步特性」這個原本的翻譯也不是透過所謂的共識決定的,這個翻譯出自本人之手,只是我本人認為更老的翻譯「等價議題」顯得非常晦澀難懂,於是換成了相對更好的、更容易接受的。但是在Miemie發出上述敲定翻譯的請求前,根本就沒人去深究Parity的真正含義。--Lxazl5770zh.admin) 2022年7月4日 (一) 15:25 (UTC)
 留言:可否考慮從MCBBS等地引流,讓更多的自然人參與討論,從而達成真正的共識?--ultim_0 ( USER | TALK | WORK ) 2022年7月4日 (一) 15:35 (UTC)
意義不大,見lx的留言。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 04:01 (UTC)
換句話說,這個議題只是想要wiki編者之間真正達成共識,其他地方並不算在內。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 04:03 (UTC)
 疑問
  1. Java版編者(姑且認為等同於「Java版開發者」)反對的理由是什麼?真的「只是給出了『不是人話』這種無意義的理由」嗎?(追加:是我的理解出現了問題)
  2. 為什麼這次在社群專頁討論沒能達成共識?是社群專頁的問題還是人的問題?
  3. 這個問題已經上升到了「兩個版本的開發者之間的偏見存在的問題」嗎?真的無法解決嗎?
--TripleCamera留言) 2022年7月5日 (二) 04:46 (UTC)(最後編輯於2022年7月5日 (二) 09:11 (UTC))
lx所說的無意義的理由主要是指MCBBS新聞版的那些人並不認同從正確性角度優先考慮譯名,而是從是否順口的角度考慮。既然討論前提不同自然沒有意義。
為什麼我認為專頁未能達成共識是因為除了管理員,支持人數少,中立和疑問的人數多。只要有人再來幾個支持,或者行政員認為自己得出這是共識的過程沒有問題,那麼趨同的替換操作大可以繼續進行。
不清楚,不曉得,這個議題僅限於wiki內的使用,不會也不能涉及其他地方。標準化是要讓大部分人接受,但不接受也沒有辦法了。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 06:23 (UTC)
既然是這樣,那就沒有必要糾結了,畢竟texture的翻譯從「材質」變成了「紋理」,快一年了不買賬的玩家大有人在。--ultim_0 ( USER | TALK | WORK ) 2022年7月5日 (二) 08:30 (UTC)
聽了你的分析,看來這個譯名的正確性是站得住腳的。希望大家能早日達成共識。--TripleCamera留言) 2022年7月5日 (二) 09:11 (UTC)
只要譯名合理,就可以推行下去。--58.248.208.154 2022年7月5日 (二) 09:03 (UTC)

本人同意趨同的翻譯,確實是目前兼顧多方面較為合適的譯名。社群共識方面,紋理也不出現在遊戲中,wiki號召一個譯名還是可以的,儘管似乎沒有得到部分wiki譯者的贊同。--Ff98sha留言) 2022年7月5日 (二) 11:45 (UTC)

由於目前無其他疑問和意見,目前維持現有譯名。MysticNebula70 T  2022年7月9日 (六) 10:31 (UTC)

關於bilibili連結的規範

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

討論結果為 建立相應的模板{{BilibiliVideoLink}}


如題,最近注意到Minecraft Wiki有許多地方引用了嗶哩嗶哩(B站)的內容(影片、專欄、動態等),但是其中一些連結存在不規範的地方:有的編者會選擇直接複製粘貼嗶哩嗶哩手機用戶端生成的短連結或者這種連結展開後的連結(從瀏覽器地址欄複製)。

綜上所述,建議為站內的嗶哩嗶哩連結提供一個固定格式的模板。先前已在自己的使用者頁面中設計了一個嗶哩嗶哩影片連結的模板(User:Ultim 0/Template/BV),對標{{YouTubeLink}},但是不確定其中的功能是否為此規範所需,如有需要,會根據{{YouTubeLink}}稍作修改。

以上。大家如有意見或建議,煩請提出。--ultim_0 ( USER | TALK | WORK ) 2022年7月9日 (六) 08:05 (UTC)(最後編輯於2022年7月9日 (六) 09:19 (UTC))

我認為還可以給該模板加入連結到指定的嗶哩嗶哩專欄和動態的功能。--AblazeVase69188討論 | 貢獻 2022年7月10日 (日) 01:52 (UTC)
專欄和動態的內容目前引用得較少,暫時不考慮加入。--ultim_0 ( USER | TALK | WORK ) 2022年7月10日 (日) 02:46 (UTC)

若無異議,則將在168小時之內擇機將上述模板移動到Template:BilibiliVideoLink,並建立重新導向Template:BvlTemplate:Bv。--ultim_0 ( USER | TALK | WORK ) 2022年7月11日 (一) 15:20 (UTC)

 已完成上述模板的建立,接下來將逐步替換站內原有的bilibili連結。注意到Fandom本身的搜尋功能難以精確識別此類外鏈,建議使用中文MCW在bilibili的鏡像進行輔助查詢。--ultim_0 ( USER | TALK | WORK ) 2022年7月17日 (日) 15:29 (UTC)

關於「物品修飾器」內對象的遺漏

物品修飾器"set_count"函數中遺漏了"add"這一對象,是否需要補充 --Hastel04留言) 2022年7月12日 (二) 08:58 (UTC)

可以根據實際情況和en對應頁面自行補充。-- Anterdc99Face Anterdc99· 2022年7月12日 (二) 09:03 (UTC)

翻譯重心

我認為Wiki應該將翻譯重心集中到經常會使用的節目,如新手教學,這些頁面有些已經落後英文wiki許多,且存在一些語法錯誤和本地化翻譯的不足,這些內容又恰恰是新玩家最多看的;而最新版本介紹的翻譯由於具有特殊的時效性,應先翻譯重要內容,細節以後慢慢補足Leidaozan留言) 2022年7月15日 (五) 05:36 (UTC)

那就麻煩您貢獻了!--Impulse Command Block 乳液Louis 對話 •貢獻 2022年7月15日 (五) 06:17 (UTC)
自己動手,豐衣足食。--ChengBing留言) 2022年7月15日 (五) 06:28 (UTC)
  1. 自己動手,豐衣足食;
  2. 從往期我的了解來說,來wiki看哪怕是技術性教學的人(我還寫了兩篇)都很少,加之教學是本wiki的歷史遺留大問題,也只有可能是有人會補充這些內容才會有這些內容的改進。
除了基岩版大版本之外,Java版的版本更新內容並沒有你想的那麼難翻譯,說是先翻譯重要內容,可是翻譯完重要內容後,不重要的內容順道早就翻譯完了(尤其是先前沒人翻譯的錯誤,現在是有人提前抓取提前翻譯好的)。作為wiki向來的薄弱處基岩版,我覺得反而才更應該受到關注吧。
此外,管理員是可以看到一些資料的。我想他們如果能夠分享一些結果的話也不是不可以。在資料分析頁面,可以得到以下資料:
  1. 所有頁面訪問次數;
  2. 被搜尋關鍵詞排行;
  3. 訪客所在地;
  4. 訪問最多的頁面和檔案;
  5. 訪客使用的用戶端情況(手機和桌面端比例,桌面端瀏覽器比例)
  6. 使用者回訪率;
  7. 日編輯量。
這些資料都僅限管理員使用,未得到許可所有資訊不可與他人分享。我想得到許可後,分享一些資料自然可以明白哪些頁面是重點。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 07:36 (UTC)
「被搜尋關鍵詞排行」和「訪問最多的頁面」和幾年前情況大致相同,無非多了一些新內容,而這些頁面的維護一向到位。順便提一句,我在三五年前就與管理員們分享過類似資料,當時指出了一點:繁體中文的訪客佔到了30%以上(目前這個數字更高),因此有必要不斷最佳化繁體訪客的體驗。tr模板的維護、詞庫更新,繁中介面管理員的招募,以及繁簡轉換表的沙盒,都是為此的舉措。--Ff98sha留言) 2022年7月16日 (六) 02:17 (UTC)
 留言:en有許多低質量內容(比如紋理圖集),建議不要貿然搬運。--ultim_0 ( USER | TALK | WORK ) 2022年7月15日 (五) 09:46 (UTC)

自訂世界生成頁面內容的嚴重缺失,如何解決

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

討論結果為 密度函數頁面已被建立並完善


最近我正在製作一個Mod,發現自訂世界生成頁面上缺失了density_function和placed_feature(均加入於Java版1.18.2-pre1)這兩項重要的內容,同時對worldgen/noise(加入於21w42a)一項缺少解釋。我檢查了Minecraft原始碼,用兩天時間研究得出了這幾項內容的結構,並得出了每一個參數的作用。

現在我的問題是:

  1. density_function應該放在一個獨立的主頁面上還是放在自訂世界生成頁面上?
  2. 自訂世界生成的歷史記錄嚴重缺失,需要完全把每一個參數的加入都寫進去,還是可以只寫「加入了一系列參數」?(1.18的變更記錄實在有點多,如果精確到每一個快照版本,加入歷史將會是一個巨大的工程)
  3. 我只有1.18.2的原始碼,但最新版本已經是1.19,我能否在頁面上只寫1.18.2的格式,然後註明「此內容僅限Java版1.18.2使用,並非最新內容」?
  4. density_function和placed_feature如何翻譯?

--QWERTY-5238留言) 2022年7月15日 (五) 08:29 (UTC)

先參考en怎麼做的(沒做就算了)。Density function直譯密度函數,我在該頁面上方放置的Misode的連結已經翻譯過了相關內容。Placed Feature目前我翻譯為已放置的地物。奇怪的話我也沒辦法。補肯定都要補,因為官方有反混淆表,不可能只寫1.18的內容。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 08:32 (UTC)
「已放置的地物」這名字實在有點容易誤會,和configured_feature難以區分。
en在歷史一節的詳細程度甚至不如中文wiki,也沒有density_function一節(不然我也不會去花兩天時間翻原始碼了)。
能否暫時只寫1.18.2的內容,可以放在一個子頁面裡(1.19的差別有點大,我沒搞清楚,寫不了)?--QWERTY-5238留言) 2022年7月15日 (五) 08:39 (UTC)
要不先更上,然後needs update裏面說1.19的內容少?至於難以區分這一點,原文也一樣的。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 08:59 (UTC)

允許加入「架設一個Mod伺服器」一欄

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

我提議允許加入「架設一個Mod伺服器」一欄,理由如下

  1. 外掛伺服器如Spigot在中文Wiki存在,而外掛對遊戲的做出的改變比Mod要大,為什麼架設外掛伺服器的教學可以存在而架設Mod伺服器會因為「Mod相關遊戲特性、非官方遊戲版本、遊戲伺服器等內容由於不受Mojang官方支持,且存在資訊雜亂、維護困難等問題,故在本wiki中一律視為垃圾資訊處理,因此請勿加入此類資訊或為其建立頁面」而受阻攔?
  2. 在外掛伺服器的中文Wiki的第一段有一句話「你可以嘗試使用Spigot。此教學將向你展示如何輕鬆架設伺服器並讓你的朋友加入,以及伺服器上使用的外掛與Mods列表。」示意了外掛和Mod在伺服器的作用基本相同,那麼為什麼外掛伺服器的架設教學可以在中文和英文wiki同時存在而中文Wiki不能發佈mod伺服器的架設教學?
  3. 在英文wiki的Technical一欄,有一項是 Installing Forge mods,翻譯過來就是「安裝forge mod」,可見安裝mod的教學是可以存在的,只是沒有各個mod功能的詳細百科而已。
  4. 在英文wiki的Servers一欄,有一項是 Setting up a Minecraft Forge server,翻譯過來就是「架設一個forge伺服器」,那麼請問為什麼在英文wiki存在的教學在中文Wiki就不能存在?如果是為特意為了造成差異化,那我認為中文Wiki就沒啥意義了。
  5. mod伺服器的架設區別於mod,架設僅僅限於架設而不會擴展到mod,所以我認為架設的教學是可以存在的。

Leidaozan留言) 2022年7月16日 (六) 08:52 (UTC)

沒人說不可以,不過Mod內容(教學除外)確實在本站體系下的各個Minecraft Wiki都不怎麼被允許了,因為都搬到FTB去了。不過我知悉,您的部分編輯內容似乎涉及到了一個國外知名伺服器,因而被過濾器攔截。雖然我不反對寫一個架設Mod伺服器的教學,但內容還是要注意的。-- LakeJasonFace Lakejason0) 2022年7月16日 (六) 09:00 (UTC)
正如我在相關頁面的討論頁回復的,只要內容不涉及具體的mod或其他任何的具體的東西,都可以允許存在,但如果此教學與其他教學較為相似,則有可能被刪除。-- Anterdc99Face Anterdc99· 2022年7月16日 (六) 09:02 (UTC)
教學的頁面建立標準相對其他主頁面來說相對寬鬆,只要不涉及特定的Mod、外掛或伺服器等,就可以保留這篇教學。您在此前提出了翻譯英文wiki的教學來補充中文Wiki對應內容的建議,這沒有問題,不過請注意,目前英文wiki的內容質量正日益下滑,並在一些內容的收錄與否的問題上與中文Wiki相去甚遠,因此建議您先篩選或者與其他Wiki編者討論,再搬運英文wiki的內容。--AblazeVase69188討論 | 貢獻 2022年7月16日 (六) 10:34 (UTC)
 留言
  1. mod類內容在Minecraft Wiki受到限制是有歷史原因的:早些時候Minecraft Wiki上存在一些非官方的mod,這些內容使用{{disclaimer}}標記;後來在Minecraft Wiki的自我整頓中,這些內容被刪除,但一些其他語言的Minecraft Wiki(如ru)仍然允許此類內容存在。
  2. 只要不在教學中對具體的mod進行過度描述,教學是可以接受的。
以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月16日 (六) 10:55 (UTC)

無意義話題的範圍拓展

最近,使用者雨後的晴天MCW:免責聲明等3個頁面的討論頁提出了不適宜的話題,其中兩個討論頁已刪除,剩下的一個討論串被存檔到無意義話題。但是注意到無意義話題頁面開頭有說明「這個頁面的子頁面用於存檔社群專頁管理員告示板上的各類無意義話題」,而目前無意義話題的出現範圍似乎有擴大的趨勢,已不限於前述頁面,是否需要修改對應描述以及相關模板?--ultim_0 ( USER | TALK | WORK ) 2022年7月17日 (日) 16:05 (UTC)

 已修正MysticNebula70 T  2022年7月28日 (四) 13:08 (UTC)

給Minecraft wiki出百科全書

根據wiki上某成員的建議,我決定在社群專頁討論頁上說這個請求: 首先,盈利方面我不盈利,而且,如果先拋開盈利問題的話可不可以?雨後的晴天留言) 2022年7月18日 (一) 00:26 (UTC)

首先,建議先好好了解一下什麼是CC BY-NC-SA 3.0。版權方面的問題我不太懂,但是如果要讓內容更換授權協議發佈,那麼得聯繫所有的貢獻者,這是不可能的。這也就是為什麼大家一開始看到就會思考盈利問題,因為要盈利就要變更內容的授權協議,這是不可能的。
其次,作為一個網站,他的內容是不斷變化的,而且沒有人能夠保證內容的準確性(雖然有人巡查)。因此,即使你立即下載一份全站快照出版,也很有可能立即過期。參考官方在國內出版的一些書籍,由於譯名標準化的變更已經變成了「不符合標準」的書籍了。這樣一個離線版Minecraft Wiki的書籍存在本身意義不大。
最後,如果你執意要遵守目前協議,請仔細思考如何做到正確的「署名」(BY),「非商業性使用」(NC),「相同方式分享」(SA)。在美國確實有書籍以該協議發佈,但不清楚其如何做到協議的相容。-- LakeJasonFace Lakejason0) 2022年7月18日 (一) 03:10 (UTC)(最後編輯於2022年7月18日 (一) 03:11 (UTC))
 留言:維基百科有出過紙質書籍,但是效果不佳,所以 不看好將Minecraft Wiki匯出為紙質書籍的行為。--ultim_0 ( USER | TALK | WORK ) 2022年7月18日 (一) 03:27 (UTC) (最後編輯於2022年7月18日 (一) 03:40 (UTC))

user warning模板拆分事宜

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

討論結果為 已完成拆分


目前的user warning模板是整合了數個警告類模板而成的一個大模板。如此編輯模板並不利於後期維護,也使得單個模板的長度過長。因此在此考慮拆分模板,仿照中文維基百科的做法,按嚴重等級和具體警告事宜製作一系列模板。目前需要考慮的問題有:

  1. 是否照搬中文維基百科的5個嚴重等級;
  2. 討論適合本wiki的具體警告事宜。

歡迎各位提出意見和建議。MysticNebula70 T  2022年7月18日 (一) 14:06 (UTC)

 支持將uw下的警告資訊拆分成多個模板。關於嚴重等級,我認為過於細分的等級在本wiki上並不實用,建議分成輕微情節警告和嚴重情節警告兩級即可。關於具體警告內容,我認為實用性較大的有破壞、可視化編輯、機器翻譯、頁面格式、上傳檔案、亂改亂用譯名。--葉月 § 2022年7月20日 (三) 20:13 (UTC)
議題沒人回復,主要是沒法下手。等級的話不清楚該怎麼辦,也許可以分個三級(提醒、輕微警告、嚴重警告?)。至於具體的內容,現有都拆開似乎也沒問題,畢竟這些內容的加入是因為wiki史上存在過對應的案例。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:55 (UTC)
命名的話,繼承EN應該沒問題。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:56 (UTC)
考慮了一下,本wiki分成三檔等級(提醒、警告、嚴重警告)應該足夠使用了。關於警告事宜,參照Hatsuki kiri和現有的也暫時夠用了。MysticNebula70 T  2022年7月29日 (五) 05:21 (UTC)
目前的拆分工作暫時完成,如有後續需求將會相應新增模板。MysticNebula70 T  2022年8月26日 (五) 14:36 (UTC)

關於將本wiki遷移至灰機wiki的建議

由於Fandom不是國內創辦的wiki農場,故其時常被牆(即使沒被牆時也非常卡,如本人從2015年起開始嘗試註冊Fandom賬號,最近才勉強成功),鑑於近年微軟與本站合作到期,故提出上述建議。114.103.49.42 2022年7月21日 (四) 10:22 (UTC)

歷史上灰機站長與本站的部分人員產生過矛盾,個人認為這是不可能發生的。
原因主要是BWIKI[原文如此]的鏡像。灰機方面認為BWIKI對本站的鏡像行為非法,態度為「深惡痛絕」。但自相關疑問產生後,BWIKI方面去除了頂欄的商業要素(NC),將歷史按鈕全部導向本站點(BY),註明了協議(SA),是符合CC BY-NC-SA 3.0的合法搬運。因此這邊建議,如果產生網路問題,去BWIKI那邊的鏡像查看相關內容。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:31 (UTC)(最後編輯於2022年7月21日 (四) 10:37 (UTC))
我不僅是想要查閱本wiki的內容,而且還想要作出編輯貢獻,使用BWIKI顯然不大現實。114.103.49.42 2022年7月21日 (四) 11:21 (UTC)
很遺憾,出於上述和下述各種各樣的理由,我們不可能為了某一個人而把整個站點遷走。也許你會說這樣會妨礙更多的貢獻者,但很遺憾這裏並不是只有中國大陸使用者,既然繁體訪客的比例更高,我覺得還是不遷移帶來的好處更多。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 05:35 (UTC)
網站遷移本身也是個問題。參考灰機的案例來說,當年從Fandom遷到灰機的站點,很多是Fandom也死了,灰機的也死了。究其本質是,流量本身遷移不走。Fandom也特別注重SEO最佳化,由於各種規定的限制,不太好做站點搬遷導向,因此貿然搬遷只會導致更多問題。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:42 (UTC)
您應該還需要知道一點,就是本站的繁體訪客數量比例是不斷增加的。出於這樣的原因,繼續改進繁簡字詞自動轉換應該比搬遷站點要更加對使用者友好。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 11:02 (UTC)
不建議這麼做,理由同上。當時灰機站長對中文MCW在BWIKI建立鏡像站的行為進行了猛烈抨擊,現在想要遷移過去恐怕也不是那麼好說的。據我所知,Fandom下的網站都沒有被牆過,有時候訪問速度緩慢、圖片無法載入都屬於正常現象(有其他Wiki使用者認為這純粹是自己的網路問題)。所以,如果要做出貢獻的話,您可以透過改善自己的網路環境來提高網站的訪問速度。--AblazeVase69188討論 | 貢獻 2022年7月21日 (四) 11:36 (UTC)
你的建議很好,但是我 拒絕,因為這裏是中文Minecraft Wiki,不是中國大陸Minecraft Wiki,非常抱歉。--Lxazl5770zh.admin) 2022年7月22日 (五) 05:34 (UTC)
 疑問您指的是港澳台地區的使用者訪問本站更方便嗎?還是遷移之後沒有繁簡轉換?Watermelontail留言) 2022年7月22日 (五) 07:05 (UTC)
雖然話題已經結束了,但是我稍作解釋:我們的訪客中,繁體使用者佔了不少於40%的比例,如果因為「國內訪問速度不好」而遷移至國內農場,這對繁體使用者而言非常不公平。何況遷移之後繁簡轉換系統如果出現問題,我們wiki的聲譽將會大打折扣。--Lxazl5770zh.admin) 2022年7月25日 (一) 08:15 (UTC)
這些不是重點,至少從上方來說,遷移了的好處比不遷移的好處少。如果從遷移的原因上來說也不合適(也就是並不是本站的大多數使用者都在遇到網路問題)的話,行政員自然從原因上反駁,以此作結,其他原因肯定也不考慮。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 07:23 (UTC)
我個人不是沒想過和灰機wiki合作,只是還沒開口就被對面噴死了。--Ff98sha留言) 2022年7月22日 (五) 07:46 (UTC)
具體情況是怎樣的?Watermelontail留言) 2022年7月22日 (五) 07:55 (UTC)
你可以搜一搜知乎。不過問題中很多回答有過期,包括所謂職員的回覆這裏實際上也是有雙方誤解的成分在裏面。如果有需求的話我可以聯繫Fandom聯絡人,興許可以讓他們查查看是個什麼情況。從我還記得的結果來說,其實Fandom或者先前的Gamepedia肯定沒有權利阻止其他人複製站點內容,只要遵守協議要求(我在上方說了爭議開始後鏡像方做了調整以符合協議),鏡像行為是沒問題的。退一步,從當時疑似侵權的角度來說,灰機站長認為這個鏡像行為是有人恰爛錢,從中攫取了利益,因此開始破口大罵,然後深惡痛絕,但事實是並沒有人拿到任何物質利益。總之爭議行為本身應該算是消失了,但是就風評和敵對態度來說,我覺得灰機方面肯定不會再考慮讓本站再搬到他們那邊去。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 08:51 (UTC)(最後編輯於2022年7月22日 (五) 09:06 (UTC))
已閱,了解本站與灰機wiki之間的矛盾。但既然矛盾已幾乎消除,再與其處於敵對狀態是不利於發展的,也沒必要再記仇什麼的了(插一嘴,網易的廣告是真多)Watermelontail留言) 2022年7月22日 (五) 09:27 (UTC)
同樣的,mcwzh方面也肯定不會再考慮讓本站再搬到灰機那邊去。--Ff98sha留言) 2022年7月25日 (一) 10:55 (UTC)

音樂

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

討論結果為 已完成


現在,音樂的分類上很有問題,我根據遊戲內建重新分類了所有音樂,如此:Special:Diff/672700。希望各位參與討論,謝謝。Choi Chin Long 2022年8月1日 (一) 08:28 (UTC)

感覺部分分類過於分散,例如「緋紅森林音樂」「地獄荒原音樂」等應該歸於「地獄音樂」。我 建議將「創造模式音樂」和「選單畫面音樂」分類出來,新分類包括「主世界音樂」「地獄音樂」「終界音樂」「水下音樂」「創造模式音樂」和「選單畫面音樂」。將水下音樂和創造模式音樂分類出來的原因是若條件滿足,這些音樂在多個維度中都能播放。--AblazeVase69188討論 | 貢獻 2022年8月1日 (一) 09:32 (UTC)
資源包上的音樂資料夾是這樣的:[1] Choi Chin Long 2022年8月1日 (一) 10:30 (UTC)
C:\Program Files\WindowsApps\Microsoft.MinecraftUWP_1.19.1101.0_x64__8wekyb3d8bbwe\data\resource_packs\vanilla_music\sounds\music目錄下找到的基岩版1.19.11的音樂檔案目錄如下:
--AblazeVase69188討論 | 貢獻 2022年8月1日 (一) 11:31 (UTC)
基於Java版1.19.1,我製作了一份詳細的音樂列表,由於內容過長不便在此展示,可前往User:Anterdc99/Archives/Java版1.19.1音樂樹查看。
根據上面AblazeVase69188的說法,並根據實際情況,可得出Special:Diff/672700中的分類法有以下問題:
  • 機械地以目錄為分類依據,不考慮各音樂間的關係。
  • 部分分類內容過少,更適合將其按一定規則與其他內容合併。
實際來說,就是「沼澤音樂」以及僅播放於地獄特定生態域的音樂是否有必要拆分的問題。
  1. 對於「沼澤音樂」,其並不需要單獨列出。根據其對應的聲音事件ID,除了包含music.menu(播放於選單畫面)外,其餘ID與其他主世界音樂對應的ID並無用法上的區別。即便是music.menu,根據前例(參見22w16a之變更),在1.20開發過程中也有可能移除。沼澤音樂之所以在目錄中單獨列出,可能即是根據此(在選單畫面外僅在沼澤播放的音樂)而作。因此,這幾個音樂只需在第二欄標註播放位置即可,不需要單獨列出。
  2. 對於地獄各音樂,其也不需要單獨列出。一般的地獄音樂nether1.ogg、​nether2.ogg、​nether3.oggnether4.ogg也可以在緋紅森林、地獄荒原和靈魂砂谷中播放,因此也可以僅在第二欄標註播放位置以示區分,不需要單獨列出。
基於以上論斷,故 支持AblazeVase69188所提出的分類法。
當然,如果要將credits.ogg也列入終界音樂中,則對應段落中的描述需要做相應修改,否則會與實際不符。-- Anterdc99Face Anterdc99· 2022年8月3日 (三) 05:09 (UTC)
 留言
  1. 不宜按照生態域細分,會產生許多包含較少內容以及內容產生交叉的分組。
    • 以「沼澤音樂」概括「只會在森林、叢林、蒼鬱洞窟、沼澤播放的音樂」欠妥當,因為這些生態域的共性是「繁茂」而非「沼澤」。
    • 按照不同維度、遊戲模式和選單中的不同位置劃分就已經很合適了。
  2. 「水下音樂」一般情況只會在主世界中的特定生態域且頭部處於水中時播放,可以考慮作為「主世界音樂」的子類。
以上。--182.90.218.225 2022年8月8日 (一) 14:57 (UTC)(ultim_0)
所以頁面可以改動了嗎?這個議題已經放在這裏一個月了。--AblazeVase69188討論 | 貢獻 2022年9月3日 (六) 09:45 (UTC)
已於版本682922中重新分類音樂,分類後有「主世界音樂」「地獄音樂」「終界音樂」「創造模式音樂」和「選單畫面音樂」五個分類,其中「水下音樂」已歸為「主世界音樂」的子類。--AblazeVase69188討論 | 貢獻 2022年9月3日 (六) 14:05 (UTC)

新手手冊編寫問題

新手手冊內的內容有些都是重複的,但有些寫的詳細,有些寫的不精確,一眼就能看出是多個人寫的,極不統一。新手手冊是最重要的頁面,就打算這樣編寫?–該未簽名留言由20.239.51.29討論)在2022年8月5日 (五) 07:37 (UTC) 加入。請在您的回覆後面加上 ~~~~

 留言:Minecraft Wiki是由諸多像您這樣的使用者構建的,如果您覺得某些頁面存在質量較低的問題,可以自行補正。--182.90.218.225 2022年8月8日 (一) 14:57 (UTC)(ultim_0)

自訂世界生成頁面的嚴重問題

Minecraft Wiki的自訂世界生成頁面的「歷史」一節非常不完整,甚至有「為結構雜訊設定加入標籤字段。」這種相當於沒說的話,1.18和1.19的更新內容幾乎沒有。

但是,1.18和1.19的變更實在太多(Misode整理的就有上百條),Minecraft Wiki短時間內很難(甚至幾乎不可能)把所有的變更都寫出來,並跟上一週一次的快照更新速度。

為了能更好地為資料包作者提供參考,我在此提出建議:

  1. 刪除雜訊設定的「預設設定」一節,其本身版本未知,落後許多個版本,容易誤導讀者。
  2. 重新編寫/開始編寫每一節預設設定(可參考slicedlime的原版地生資料包),取消表格(表格難以描述複雜的密度函數了),改為列出JSON內容,並標註最後版本
  3. 在每個JSON格式前寫上最後更新版本。
  4. 舊版本內容不要刪除,而是保留每一個大版本的內容(1.16.5,1.17.1,1.18.2)移動到子頁面,在每一節的最前方加入舊版本連結。
    1. 這是因為歷史章節內容必將十分冗長,如果只保留最新版本內容,就會讓舊版的資料包作者只能對比每一條歷史變更來確定自己版本的格式,花費不必要的時間。
  5. 參考Misode,完善歷史章節。

--QWERTY-5238留言) 2022年8月10日 (三) 03:23 (UTC)

補充:寫個世界生成示例,避免過於抽象。--QWERTY-5238留言) 2022年8月10日 (三) 04:09 (UTC)
 支持,不過還是要儘量保留資訊的,預設的具體設定可以不寫,但是相關參數的實際意義還是要說明清楚。-- LakeJasonFace Lakejason0) 2022年8月10日 (三) 14:55 (UTC)
每一節加上還是太多了,整個頁面本身分版本,在開頭寫舊版本連結比較好。-- LakeJasonFace Lakejason0) 2022年8月10日 (三) 14:58 (UTC)

關於pvp相關部分的大幅動

目前pvp頁面之中,存在大量因為版本更替出現的過時內容,導致格式以及內容冗雜而難以保證簡潔。個人建議新設一個「pvp/java1.9之前」的條目,並將原條目中的過時內容予以刪除。竹琴之留言) 2022年8月10日 (三) 04:36 (UTC)

 支持,這個頁面太長導致難以維護。--McplayerFS討論 | 貢獻) 2022年8月10日 (三) 06:58 (UTC)
 支持,pvp頁面的確存在您說的內容,分開管理比較好。Zhangzixuan2010留言) 2022年8月10日 (三) 07:58 (UTC)

關於世界界限與世界邊界兩個頁面的過時現象

在世界界限與世界邊界兩個頁面中存在嚴重過時與不符合遊戲的現象,關於這些現象的具體表述請見 世界界限 的討論頁--Wodemc留言) 2022年8月25日 (四) 11:31 (UTC)

申請中文玩家社群新增連結

本主題或以下段落文字移動自Talk:Minecraft Wiki

申請加入苦力怕論壇 目前苦力怕論壇已成為國內基岩版論壇中下游,並在先前轉型為基岩版社群,並未直接與mcbbs為同類論壇 謝謝

172.105.234.90 2022年9月9日 (五) 12:21 (UTC)苦力怕紙

苦力怕論壇提供了安卓平台的盜版遊戲安裝包,因此我猜測此請求會被拒絕。(我不是管理層人員,無權處理此類請求)--AblazeVase69188討論 | 貢獻 2022年9月9日 (五) 12:47 (UTC)(最後編輯於2022年9月9日 (五) 13:35 (UTC))
先前申請在本站加入友鏈的Minebbs論壇也提供了安卓平台的盜版遊戲安裝包,所以這不是一個很好的拒絕理由。請無視我先前的發言。--AblazeVase69188討論 | 貢獻 2022年9月9日 (五) 13:35 (UTC)
提交友鏈申請請勿以匿名使用者身份。建議由苦力怕論壇的管理人員來申請。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 12:58 (UTC)
不好意思,我們不接受來自匿名使用者的外交請求。如果你是苦力怕論壇的管理員,請建立帳號並提供相應的證據來表明你的身份。--Lxazl5770zh.admin) 2022年9月9日 (五) 13:00 (UTC)

申請中文玩家社群新增連結(2)

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

討論結果為 准許


我是苦力怕論壇管理員苦力怕紙,郵箱klpbbs@qq.com或admin@klpbbs.com,再次申請加入苦力怕論壇,連結:https://klpbbs.com 辛苦了,謝謝 回復一下前面那個回復,現在站內已將mc破解版分離,轉為了其他網站,並且我們也在積極引導玩家入正。圖片連結 McKlpbbs留言) 2022年9月9日 (五) 13:54 (UTC)苦力怕紙(最後編輯於2022年9月9日 (五) 13:57 (UTC))

回復前面留言的時候,您無需新開一個另外的話題,直接在原話題下留言即可。此外,在加入~~~~的字串之後,儲存編輯時系統會自動輸入您的簽名,您無需在其後再重複一次您的簽名。--AblazeVase69188討論 | 貢獻 2022年9月9日 (五) 13:56 (UTC)
好的,感謝提醒McKlpbbs留言) 2022年9月9日 (五) 14:22 (UTC)苦力怕紙
上傳檔案請透過Special:上傳檔案,請勿使用編輯器內提供的上傳檔案。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 13:59 (UTC)
其次,這樣的截圖無法作為證明。由於所提供的論壇,其QQ群無法訪問,其提供的管理員QQ無人回信,因此這邊不好驗證。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 14:01 (UTC)
(給站內沒有入QQ群的人的告知)申請友聯的相關人員已進入QQ群說明情況。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 14:12 (UTC)
 同意請求。--Lxazl5770zh.admin) 2022年9月10日 (六) 08:54 (UTC)

Breaking row模板顏色含義問題

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

討論結果為 已修改


{{breaking row}}顏色表示的含義目前存在一些模糊之處,例如只有使用絲綢之觸才掉落物品,在目前沒有統一的表示顏色。是否應當為這種情況設立專門的顏色?MysticNebula70 T  2022年9月11日 (日) 11:08 (UTC)

Snow dash關心的問題還是被提出來了啊……我簡單地提議一下(前提都是使用了正確的工具):
顏色 含義
綠色 挖掘後,無論如何都會掉落自身
黃色 只有使用絲綢之觸才會掉落自身,否則不會掉落或掉落其他東西
紅色 挖掘後總是不會掉落自身,而是有可能不會掉落或掉落其他東西
鑑於絲綢之觸的常用性,我認為我的提議算是比較清晰的。例如生怪磚蛋糕歸類為紅色,冰和草地歸類為黃色,其他不一一列舉。--Lxazl5770zh.admin) 2022年9月11日 (日) 11:22 (UTC)
二編:如果單純使用三種顏色來表達目前所有方塊的可取得性是完全不夠用的,需要用注釋來加以輔助。而且,如果使用紅淺綠三種顏色以外的顏色,普通讀者很難理解其中的意思。因此,在表格下插入注釋文字是非常有必要的。--Lxazl5770zh.admin) 2022年9月18日 (日) 08:50 (UTC)
思考了一段時間,確實主要內容需要靠文字說明,顏色過多並不利於理解。MysticNebula70 T  2022年9月19日 (一) 14:14 (UTC)
已按照Lxazl5770的提議修改。MysticNebula70 T  2022年9月20日 (二) 13:49 (UTC)

關於拆分和最佳化Java版已移除特性

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

討論結果為 已完成拆分


那個板塊也過於長了吧,為什麼到現在還沒拆分--栗色粗布留言) 2022年9月12日 (一) 05:32 (UTC)

很簡單——沒有人討論這個話題。且慢,等我把那個頁面的用詞全部改通順再拆。--AblazeVase69188討論 | 貢獻 2022年9月12日 (一) 05:38 (UTC)
自己動手,豐衣足食。--Lxazl5770zh.admin) 2022年9月12日 (一) 06:40 (UTC)
這不是自己不敢拆嗎--栗色粗布留言) 2022年9月12日 (一) 06:50 (UTC)
您可以先提出具體的方案並徵求社群的意見。或者您可以準備採用en的拆分方式,讓社群討論。--AblazeVase69188討論 | 貢獻 2022年9月12日 (一) 06:57 (UTC)
如果需要更加及時的討論方式,見您的討論頁。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 07:27 (UTC)
我已經對頁面用詞不通順的地方完成修改,初步認為需要先將方塊分離到子頁面,它實在是太長了。--AblazeVase69188討論 | 貢獻 2022年9月12日 (一) 07:35 (UTC)
請注意,拆分後的頁面也需要好好寫導言(也就是首段)和跨wiki連結。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 08:13 (UTC)
很抱歉,我僅是將原始碼複製過去了,這幾個頁面確實需要完善,不過我今天先暫時編到這裏,下次有空再來或是等別人來最佳化吧。--栗色粗布留言) 2022年9月12日 (一) 08:18 (UTC)
未完成頁面已被移動到沙盒。另外,強烈建議您加入QQ群以便溝通。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 08:20 (UTC)
建議拆分到Java版已移除特性/方塊等子頁面,方便查找與維護。--AblazeVase69188討論 | 貢獻 2022年9月12日 (一) 08:32 (UTC)
這樣的話,我建議一併拆分基岩版已移除特性。--Yzy32767/ 2022年9月12日 (一) 09:54 (UTC)
好主意--栗色粗布留言) 2022年9月12日 (一) 09:57 (UTC)
Java版已移除特性已拆分並最佳化完成,能不能從沙盒中移出來。(之前此訊息錯發到管理員告示板中了,深感抱歉)--栗色粗布留言) 2022年9月12日 (一) 10:43 (UTC)

Minecraft Dungeons生物類型描述問題

目前地下城生物頁面使用了類似「被動型」、「中立型」等名詞描述生物種類,原版生物似乎已不再使用此類描述,主要區分友好生物、敵對生物,並在友好生物下分出無攻擊能力、條件敵對等子類。

是否應統一Minecraft Dungeons與原版的相關術語?Minecraforever留言) 2022年9月12日 (一) 15:23 (UTC)

原版修改的原因是原本的分類系統理論上需要把大量生物都歸入中立,且此分類系統與遊戲機制無關。Minecraft Dungeons中如果本身有遊戲機制可以區分的話則可以按此提案。如果沒有遇到相關問題則不必。-- LakeJasonFace Lakejason0) 2022年9月13日 (二) 04:02 (UTC)
地下城遊戲關卡中出現的動物生物幾乎不具有主動攻擊玩家的能力,中立及被動兩種表述界限不是很清晰,個人認為統一為友好生物之後與敵對生物區分更明確,也更能體現動物大類之間的共性。Minecraforever留言) 2022年9月13日 (二) 14:46 (UTC)
看了一下,可以改。-- LakeJasonFace Lakejason0) 2022年9月13日 (二) 15:05 (UTC)
好的,隨後會進行變更。Minecraforever留言) 2022年9月13日 (二) 15:50 (UTC)

關於譯名標準化的子頁面格式不統一的問題與提議

下列有關譯名標準化子頁面格式的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 已應用提案2


MCW:譯名標準化/translation頁面的括號有過多的意思——可能是替代翻譯,可能是語境,可能是可省略不譯出,可能是取代某一個字。

我個人提議是再加一列備註表示語境,用<br>分割多個翻譯,用括號表示省略。若有多個翻譯,且存在首選的翻譯,使用粗體表示首選翻譯。不翻譯的,譯名打橫槓,注釋內標明不翻譯。

更新:參見提案2提案1

有更多意見在下方討論。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 07:24 (UTC)(最後編輯於2022年9月17日 (六) 08:39 (UTC))

我認為用半形中括號[]來表示省略會更緊湊,易於理解,用括號()來表示意思相同或相近的譯名,用換行來表示不同義項,加一列或用注釋來表示語境--栗色粗布留言) 2022年9月17日 (六) 07:28 (UTC)
緊湊並不表示美觀,且一般而言方括號也不表示省略。注釋如果用ref標籤,那麼最終是堆在一起,其實也不便於查閱。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 07:30 (UTC)
術語線上裡就是用[]來表省略,我認為效果很好,第一眼就能知道這方括號是什麼意思,而括號(尤其是全形)並不能做到相同效果,有較大歧義--栗色粗布留言) 2022年9月17日 (六) 07:33 (UTC)
我查閱了《GB/T 15834-2011 標點符號用法》,意見是用[]來表示省略,用()來標示注釋內容、補充說明(即語境),用分號;來表示分項列舉的並列詞語(即意思相同或相近的譯名),用換行br來表示意思不同的義項。示例:sprite 拼合圖;精靈圖(通常不翻譯) argument [實際]參數 Parity 趨同(用於Vanilla Parity等)br 奇偶[性](用於...)--栗色粗布留言) 2022年9月17日 (六) 07:52 (UTC)
美觀性請參考沙盒中譯標提案1和譯標提案2介面自行評判–該未簽名留言由栗色粗布討論貢獻)在2022年9月17日 (六) 08:26 (UTC) 加入。請在您的回覆後面加上 ~~~~

意見

這裏是給提案們的意見。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 09:20 (UTC)

投票

在下方投票。對某個提案的意見請在這個子標題上方加子標題。請只選擇一個。有新提案時,原本選擇舊提案的但要選擇新提案的及時劃票。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 08:50 (UTC)(最後編輯於2022年9月17日 (六) 09:20 (UTC))

 支持提案2。我個人認為如果用中括號括起來的話,難以理解為省略的意思。--AblazeVase69188討論 | 貢獻 2022年9月17日 (六) 12:25 (UTC)
 支持提案2,但是有一點,如果用全形括號的話,個人感覺有點丑。但這樣最直觀。--KaplanSteve  T/C 2022年9月23日 (五) 09:19 (UTC)
 支持提案2 --Lxazl5770zh.admin) 2022年10月28日 (五) 13:05 (UTC)
 已應用提案2。-- LakeJasonFace Lakejason0) 2022年10月28日 (五) 13:37 (UTC)

關於地物和結構模板使用的問題

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

討論結果為 已完成重新分類並刪除{{Generated structures}}模板


目前,{{Generated structures}}{{Environment}}{{Structures}}三個模板內容存在較大重複,意思混亂,內容雜糅。

因此,個人認為應將三個模板進行拆分,分為「地形特徵」、「結構」兩個模板,完成後將{{Environment}}模板進行精簡(主要是考慮到某些內容不會包括在前兩個模板裡)。包括生成結構頁面也可以移動至「結構」。

我的提議可能有點簡單,不過我大概提出了一個思路。以上。--KaplanSteve  T/C 2022年9月17日 (六) 08:17 (UTC)

建議先考慮同步en的en:Template:Generated structuresen:Template:Environment再考慮是否進行拆分。以及意思混亂、內容雜糅的其實不只是模板,模板裡的頁面的內容和分類也都存在混亂的問題。--Chixvv留言) 2022年9月17日 (六) 08:39 (UTC)
{{Generated structures}}之前已經同步過一次。另外此模板一直處於未使用狀態,所以如果問題較大的話,可以考慮刪除(主要是en有一些zh沒有的內容)。-- Anterdc99Face Anterdc99· 2022年9月17日 (六) 09:42 (UTC)
我認為可以將Generated structures合併至Structures,並將Environment中結構頁面的連結(如獨石柱、地獄反應器)移動至Structures中。--AblazeVase69188討論 | 貢獻 2022年9月17日 (六) 12:10 (UTC)
我已在個人沙盒中將Environment中結構頁面的連結(如獨石柱、地獄反應器)移動至Structures(已同步至模板頁面),並移除了Generated structures中不存在的頁面連結。其中Generated structures以生成器種類為分類方式,Structures以生成結構和地形特徵為分類方式,二者內容幾乎完全一樣,我認為前者的分類方式更好,故計劃將Structures合併至Generated structures。不過這樣貌似不如將這兩個模板分為「地形特徵」、「結構」兩個模板的做法好,如果要採取這種做法,則需要將「結構生成」和「裝飾器生成」的部分內容放入「結構」,其他的放入「地形特徵」。具體怎麼做還有待各位討論。順帶一提,en似乎對Generated structures的分類做了調整,個人沙盒中的模板暫時不打算進行同步。--AblazeVase69188討論 | 貢獻 2022年12月6日 (二) 14:20 (UTC)
2023年1月20日,結構頁面被拆分為生成結構地物兩個頁面,並補充了大量內容,隨後由Nickid2018整理了{{Structures}}模板。我認為目前這個模板已經能夠代替{{Generated Structures}},可以直接刪除後者;{{Environment}}模板保留現狀即可。--AblazeVase69188討論 | 貢獻 2023年2月10日 (五) 12:38 (UTC)
鑑於結構和地物相關內容已完成補充和整理,{{Environment}}{{Structures}}模板內容頁已區分開來,{{Generated structures}}模板內容已被{{Structures}}收錄。因此{{Generated structures}}模板可被刪除,此話題將被關閉。如有關於地物和結構模板以及各頁面的內容分類問題,可另外討論。-- Anterdc99Face Anterdc99· 2023年2月11日 (六) 08:05 (UTC)

搜尋欄中翻譯不正當

搜尋欄中熱度榜中顯示「指令」而非「指令」,望修改。Emplovety留言) 2022年9月17日 (六) 09:55 (UTC)

那裏顯示的是使用者搜尋量最高的前幾個詞,不是可以變更的東西。--Lxazl5770zh.admin) 2022年9月17日 (六) 11:44 (UTC)
那東西真是使用者搜尋的?怪不得源碼找不著這些字 Emplovety留言) 2022年9月18日 (日) 07:23 (UTC)
我們的熱搜榜是客觀公正的,哪像某些三流網站就是喜歡篡改熱搜資料呢~ --Lxazl5770zh.admin) 2022年9月18日 (日) 08:45 (UTC)
但是怎麼提取關鍵字的呢,既然提取了關鍵字何不將指令提取為指令,雖然涉及這個方面應該很難改動。Emplovety留言) 2022年9月23日 (五) 13:40 (UTC)
具體問題請恰fandom。-- Anterdc99Face Anterdc99· 2022年9月23日 (五) 13:42 (UTC)
「洽」,不是「恰」。-- LakeJasonFace Lakejason0) 2022年9月24日 (六) 05:02 (UTC)(最後編輯於2022年9月24日 (六) 05:03 (UTC))

關於消歧義頁面的標點使用問題

下列有關消歧義頁面的標點使用問題的討論已經結束,請不要再編輯此段。任何想要進一步探討的編輯者應該新建一個話題。

討論結果為 已完成變更。


今天在整理並擴充消歧義頁面時,發現條目標題與後面的解釋內容中間的標點符號使用不統一,有短劃線、破折號、逗號等,並且解釋內容後面有的有句號,有的沒句號。

希望有人給個提案,如果可以的話建議開機械人進行更換。--KaplanSteve  T/C 2022年9月18日 (日) 02:33 (UTC)

 建議:條目標題與後面的解釋內容中間使用空格+短劃線+空格隔開(例如:鑽石 − 一種……)。如果有解釋內容,解釋的後面全部加上句號;如果沒有解釋內容就不加句號。此提案引入自鑽石(消歧義)頁面。--AblazeVase69188討論 | 貢獻 2022年9月18日 (日) 02:59 (UTC)
我也是這麼寫的,感覺這種的美觀性最強。--KaplanSteve  T/C 2022年9月19日 (一) 02:59 (UTC)
請將本話題轉移至機械人請求頁。--Lxazl5770zh.admin) 2022年9月18日 (日) 08:48 (UTC)
似乎還沒有一個共識結果,先討論一下。--KaplanSteve  T/C 2022年9月19日 (一) 02:59 (UTC)

教學譯名變更意見

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

討論結果為 拒絕變更


wiki中的一個教學翻譯有誤(教學/機械)(當然也包括其他紅石教學中相同用詞),機械(machinery)是機器(machine)和機構(mechanism)的總稱,而原文是mechanism,因此我認為改為機構會更好。大家可以在下方踴躍討論。--栗色粗布留言) 2022年9月23日 (五) 12:28 (UTC)

這個教學的內容更像機器,不如改成機器。傳入神經元權限|討論|貢獻|日誌) 2022年9月23日 (五) 12:53 (UTC)
還是遵從原文比較恰當吧--栗色粗布留言) 2022年9月23日 (五) 12:56 (UTC)
中文Wiki的頁面內容沒有必要按照英文wiki的內容生搬硬套,可以作適當的修改。--AblazeVase69188討論 | 貢獻 2022年9月23日 (五) 13:14 (UTC)
根據術語線上,機構表示「由兩個或兩個以上構件透過活動聯接形成的構件系統」,機器表示「由零件組成的執行機械運動的裝置」,機械則是機構和機器的總稱。我認為它們之間的區分較為模糊,直接使用「機械」一詞即可。正如上面所說的,沒有必要拘泥於英文wiki的原文。--AblazeVase69188討論 | 貢獻 2022年9月23日 (五) 13:21 (UTC)
「機構」單獨作為頁面標題時,由於缺乏上下文或修飾文字且其自身具有多重含義,故極不適合作為單獨的頁面標題,且現有標題並不影響表意,故 反對改動。-- Anterdc99Face Anterdc99· 2022年9月23日 (五) 13:28 (UTC)
應從頁面內容上命名,而沒必要考慮英語原文。
既然機械是統稱,那麼不管頁面裡的內容更像機構還是更像機器,以「機械」為標題總沒有太大問題。
機構在機械領域是專業術語,但日常中文裏機構一般指工作單位,而非機械構件。
題外話,雖然在中文機械專業領域機械確實是機器和機構的總稱,但英文「machinery」並不是machine和mechanism的總稱。--Chixvv留言) 2022年9月23日 (五) 13:35 (UTC)
路過,「機構」一詞一般會和社會科學上的「組織」(Organization)劃上等號,用來形容機械是不恰當的。--Lxazl5770zh.admin) 2022年10月28日 (五) 13:04 (UTC)

關於Subchunk的譯名討論

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

討論結果為維持「子區塊」這一翻譯,並 已完成加入譯名標準化。


最近發現wiki上對於subchunk的譯名不統一,主要原因還是沒有單獨的介面,這個詞主要存在於村莊刷新有關的內容,如村莊、殭屍圍城、突襲等條目都有提及,不同的編者可能就按自己的意見翻了。因此我希望這個詞在wiki中能以標準譯名的形式得到統一,在這之前我想在這裏討論一下。先說一下這個詞(subchunk)的含義,大致是指F3+G打開的區塊顯示中每個由藍色線條框選的部分,單詞本身也很簡單,就是詞綴sub-加chunk。有不少優秀的譯名,比如「亞區塊」、「次區塊」、「子區塊」、「分區塊」等,當然我最喜歡的是「子塊」,因為它言簡意賅,個人認為這是個最(較)佳的選擇。我希望大家能在這裏踴躍的討論,發表自己的意見。最後,由於匿名使用者的局限性,希望討論結束後能有人幫忙去譯名標準化介面寫入此詞條,謝謝。--172.105.202.11 2022年10月4日 (二) 14:32 (UTC)(最後編輯於2022年10月4日 (二) 14:53 (UTC))

先前我們在一個閒聊群討論過,結論是,子區塊和區段這兩個詞對應的原詞一個在JE,一個在BE。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:33 (UTC)
稍微具體一點:Java版的反混淆是「LevelChunkSection」,可以翻譯為區段(但wiki內較新的內容也翻譯為子區塊),但根據其他描述,代碼內也有叫子區塊的。BE則由相關人員予以確認是子區塊。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:35 (UTC)(最後編輯於2022年10月4日 (二) 14:56 (UTC))
再看了一下,好像討論的東西不太一樣。具體我會再問問會反混淆的使用者。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:39 (UTC)(最後編輯於2022年10月4日 (二) 14:59 (UTC))
稍微問了一下。subchunk,或section,均分整個區塊,是區塊的組成部分,範圍是16×16×16(單位是方塊)。因此叫子區塊毫無問題,不需要改為子塊(塊單用一般對應某block)。但是我沒有在本wiki遇到subchunk譯名不統一的問題,全部都翻譯為子區塊。不知道您所說的不統一是在哪些地方,包括是否有適用範圍的區別。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:48 (UTC)(最後編輯於2022年10月4日 (二) 14:54 (UTC))
之前確實有看到,不過好像早就被修正了(好打臉),巡查員確實給力--172.105.202.11 2022年10月4日 (二) 15:15 (UTC)
已加入標準化列表。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 15:19 (UTC)

申請:wiki中能否加入有關敵對生物出現誤傷,而導致互相攻擊的特性。

根據個人測試,敵對生物(如主世界的骷髏)特別是在扎堆或擠在狹小空間時若對玩家進行攻擊,容易對同類或異類敵對生物產生誤傷(甚至產生仇恨導致相互攻擊)。 備註:1.或許誤傷也是取得透過骷髏用弓箭擊殺苦力怕掉落唱片的方式;2.當玩家掉落劍或部分裝備(除護甲外)時,骷髏有機率撿起並替換手裏的弓箭。 詳情請見:https://www.bilibili.com/video/BV1ey4y1x7qS?spm_id_from=333.999.0.0(第一次写议题,望采纳,谢谢) 小王666留言) 2022年10月20日 (四) 08:36 (UTC)小王666

敵對生物只說了「一些情況」,這塊應該寫詳細點。相關的技巧可以往教學/戰鬥寫。傳入神經元權限|討論|貢獻|日誌) 2022年10月20日 (四) 11:14 (UTC)

目前測試結果為主世界的殭屍,骷髏,蜘蛛,女巫容易在受到誤傷後互相傷害(遠程和範圍攻擊時機率更高),其餘生物還再測試當中。令:謝謝回復與幫助。小王666留言) 2022年10月20日 (四) 13:09 (UTC)小王666

關於en的Experimental feature模板

該模板用於標註某一條目或段落的內容包含Java版的實驗性特性。官方自22w42a開始透過內建資料包測試一些實驗性內容,類似於基岩版的實驗性玩法,而zh目前還沒有類似的模板,建議引入。

個人認為該模板應與{{Experimental}}合併,在個人沙盒中有該方案的實驗性代碼。也可以照en的做法,把模板獨立出來。各位意見如何?--Yzy32767-T/C- 2022年10月23日 (日) 02:34 (UTC)

目前Java版的實驗性內容功能還處於胚胎階段,很難說這就是和基岩版相同的運作方式。如果確實要合併的話,要考慮一下兩個版本之間的Experimental feature能不能劃上等號——Java也會和基岩版那樣子開啟永久性的測試嗎?如果不會,那就沒法進行合併操作。此外,我認為頁面頂部的資訊框不要掛太多,因為這一堆資訊框只會給讀者造成困惑,畢竟大部分人都是來看頁面內容的,不是來看注意事項的。--Lxazl5770zh.admin) 2022年10月28日 (五) 12:55 (UTC)
補充一點,在{{Experimental}}加一個控制版本的參數應該就沒啥問題了,用來控制只顯示其中一個版本,或者都顯示。--Lxazl5770zh.admin) 2022年10月28日 (五) 13:02 (UTC)

isSolid()的翻譯

本主題或以下段落文字移動自User talk:Snow dash

很多固體不屬於Solid材料。這個Solid是不是應該理解成緻密?傳入神經元權限|討論|貢獻|日誌) 2022年11月3日 (四) 08:11 (UTC)

方塊屬性頁面麼?。。。好久以前搞的了,那個是代碼層面的東西,搞不清楚mj咋想的。沒法提供建議。。--Snow dash & ) 2022年11月3日 (四) 11:07 (UTC)
那我改成緻密吧。傳入神經元權限|討論|貢獻|日誌) 2022年11月3日 (四) 11:56 (UTC)

以上段落移動自使用者討論頁。由於此次變更在wiki編者所在的群內產生了一些分歧,故決定在此討論。-- LakeJasonFace Lakejason0) 2022年11月3日 (四) 12:59 (UTC)

整理格式指導

隨著MCW:格式指導逐漸擴充,目前已含有許多與格式無關的內容,使得其不再符合標題。因此,考慮將格式指導重新整理,將其中不屬于格式的要求移動至其他頁面內。另外,也可將其他相關指導(如MCW:書面漢語指導)一併整理。此提議需要社群成員參與並認同,因此發佈到社群專頁上。對提議本身有想法或者對整理方案有想法都可提出。MysticNebula70 T  2022年11月10日 (四) 14:13 (UTC)

缺少MCD相關內容(尤其是檔案名,已經是爛攤子了);關注度應當拆除,只保留重新導向連結。另有問題過一會在說。--KaplanSteve  T/C 2022年11月10日 (四) 15:22 (UTC)
建議新建幾個獨立頁面將裏面的內容拆分,個人認為拆分成獨立頁面沒有什麼壞處,只需要有一個頁底導航收集起來即可。--Lxazl5770zh.admin) 2022年11月11日 (五) 14:27 (UTC)

能否將啟動器的版本記錄和Dungeons啟動器的版本記錄合為一頁?

在英文Minecraft Wiki中,啟動器介面包含了Minecraft啟動器和曾經的MCD啟動器,中文版要不要將其合併?Vjfjng留言) 2022年11月21日 (一) 09:22 (UTC)(最後編輯於2022年11月21日 (一) 10:02 (UTC))

 不需要,會丟失很多資訊,另外頭圖也不一樣,更新內容也有區別。--KaplanSteve  T/C 2022年11月25日 (五) 04:26 (UTC)

是否使用bool而不是byte表示NBT標籤的布林值

目前在Wiki中,NBT格式中的布林值都以byte表示。這主要是因為NBT中不包含布林值標籤,而是使用TAG_Byte進行寫入,用0代表false,用1代表true。但是目前看來,使用byte進行表示可能不是最好的選擇,原因如下:

  1. 雖然NBT中沒有代表布林值的標籤,但是SNBT卻可以使用true/false,玩家對於NBT接觸更多的其實是SNBT,所以將標籤使用bool代替不會造成玩家困惑。
  2. 根據代碼來看(Mojang Mapping),寫入布林值的方法被稱為putBoolean,讀取布林值的方法被稱為getBoolean。之所以使用TAG_Byte寫入布林值,是因為這會讓寫入檔案更方便。
  3. 目前Wiki對於這些布林值的描述是這樣的: xxx:1或0(true/false)- xxxx。每一個布林值都有這些文字重複。如果使用bool代替,描述會變成: xxx:xxxx。變得更加簡潔而且可以讓玩家更好的理解這些標籤的作用。

目前我想出的做法是:

  1. 將Wiki內所有使用byte表示的布林值全都替換為bool,並變更相應的描述。
  2. 修改NBT格式頁面,並說明SNBT中的布林值和NBT中TAG_Byte的關係等。

--Nickid2018留言) 2022年11月30日 (三) 03:39 (UTC)

如果你有精力去全部改掉的話,我 支持你的看法。--Lxazl5770zh.admin) 2022年11月30日 (三) 09:30 (UTC)

The Word of Notch已失效

關於遊戲創始人Markus Persson的網站notch.com已失效,是否需要變更或刪掉–該未簽名留言由39.154.160.9討論)在2022年12月14日 (三) 07:24 (UTC) 加入。請在您的回覆後面加上 ~~~~(最後編輯於2022年12月14日 (三) 07:28 (UTC))

屬於已知問題,此前已有計劃變更。具體來說,可以改為使用Internet Archive。-- Anterdc99Face Anterdc99· 2022年12月14日 (三) 07:44 (UTC)
Advertisement