Minecraft Wiki

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

了解更多

Minecraft Wiki
Advertisement

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

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

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

常用頁面

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

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

請點擊下面的「發起議題」按鈕或頁面上面的「加入話題」標籤在頁面底部發表新的議題。

如果您在頁面上發現有簡繁轉換錯誤或繁體中文譯名沒有正確顯示,請在這裡提出,我們將會儘快修復。
最新Wiki新聞
# 話題 發言條數 參與人數 發起者 最後發言者 最後發言時間(UTC)
1 關於首頁大段空白的問題 30 9 North kun Yzy32767 2022年8月7日 (日) 04:43
2 使用模板的大小寫與縮寫要求、以及部分模板及其參數的使用規範問題 20 6 AblazeVase69188 McplayerFS 2022年7月16日 (六) 09:08
3 user warning模板拆分事宜 5 3 MysticNebula70 MysticNebula70 2022年7月29日 (五) 05:21
4 音樂 6 4 Cyron Choi 182.90.218.225 2022年8月8日 (一) 14:57
5 新手手冊編寫問題 2 2 20.239.51.29 182.90.218.225 2022年8月8日 (一) 14:57
6 自訂世界生成頁面的嚴重問題 4 2 QWERTY-5238 Lakejason0 2022年8月10日 (三) 14:58
7 關於pvp相關部分的大幅動 3 3 竹琴之 Zhangzixuan2010 2022年8月10日 (三) 07:58
話題

關於首頁大段空白的問題[]

本人的多個裝置以及部分嘗試了查看首頁的群友在打開首頁的時候均會在「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.png Lakejason0) 2022年6月19日 (日) 13:13 (UTC)
我不認為這是需要處理的問題。目前沒有插入新欄目的打算。--Lxazl5770zh.admin) 2022年6月20日 (一) 02:33 (UTC)
並不是「插入」的問題,而是重新整理,重新排版的問題。-- LakeJasonFace.png Lakejason0) 2022年6月20日 (一) 03:01 (UTC)
重新排版確實有必要,不過目前暫時沒有比較好的設計。有的話可以提出來。MysticNebula70 T  2022年6月20日 (一) 05:30 (UTC)
仿效en的排版其實也不錯,把你知道嗎換成每週頁面如何呢?-- LakeJasonFace.png 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.png Lakejason0) 2022年6月22日 (三) 06:07 (UTC)(最後編輯於2022年6月22日 (三) 06:42 (UTC))
由於測試過程中發現了一些新問題,在此說明一下問題以及一些新的提案。
問題1:首頁的每週頁面圖片有浮動,會把文字擠到一邊。這個在上方提案中修改為了居中來解決問題。
問題2:版本資訊一欄方格下方的列表觀感不好,詞彙會斷開,而且橫向列表在列表項目不多時展示效果較差。
基於以上發現的兩個問題,我又查看了其他語言站點的首頁,相關情況如下:
英文:版本資訊單獨出一整個橫欄,所有的購買連結和版本號放在一起。
西班牙語:重新設計了首頁,將版本資訊刪除。
由於版本資訊寫全似乎冗餘,在即時通信軟體中部分使用者對EN的目前方案給出的意見是負面的。西班牙語目前沒有人評論。大概是這樣。-- LakeJasonFace.png 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.png Lakejason0) 2022年6月22日 (三) 08:01 (UTC)
在處理橫向列表的時候發現了EN的一個做法,就是把購買連結寫在對應的頁面,而不是直接寫到首頁。這樣也更便於維護。-- LakeJasonFace.png 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.png 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)

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

我於數月前查看版本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.png 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.png 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.png 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)

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.png Lakejason0) 2022年7月21日 (四) 10:55 (UTC)
命名的話,繼承EN應該沒問題。-- LakeJasonFace.png Lakejason0) 2022年7月21日 (四) 10:56 (UTC)
考慮了一下,本wiki分成三檔等級(提醒、警告、嚴重警告)應該足夠使用了。關於警告事宜,參照Hatsuki kiri和現有的也暫時夠用了。MysticNebula70 T  2022年7月29日 (五) 05:21 (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.png Anterdc99· 2022年8月3日 (三) 05:09 (UTC)
 留言
  1. 不宜按照生態域細分,會產生許多包含較少內容以及內容產生交叉的分組。
    • 以「沼澤音樂」概括「只會在森林、叢林、蒼鬱洞窟、沼澤播放的音樂」欠妥當,因為這些生態域的共性是「繁茂」而非「沼澤」。
    • 按照不同維度、遊戲模式和選單中的不同位置劃分就已經很合適了。
  2. 「水下音樂」一般情況只會在主世界中的特定生態域且頭部處於水中時播放,可以考慮作為「主世界音樂」的子類。
以上。--182.90.218.225 2022年8月8日 (一) 14:57 (UTC)(ultim_0)

新手手冊編寫問題[]

新手手冊內的內容有些都是重複的,但有些寫的詳細,有些寫的不精確,一眼就能看出是多個人寫的,極不統一。新手手冊是最重要的頁面,就打算這樣編寫?–該未簽名留言由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.png Lakejason0) 2022年8月10日 (三) 14:55 (UTC)
每一節加上還是太多了,整個頁面本身分版本,在開頭寫舊版本連結比較好。-- LakeJasonFace.png 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)
Advertisement