close关闭
欢迎来到新Minecraft Wiki！查看迁移通知
引用本Wiki内容时务必注明出处。

迁移账号 | 转载须知 | 帮助目录社区专页 | 管理员告示板 | 繁体中文问题报告QQ | 微博 | Discord

Minecraft Wiki:社区专页/存档13

来自Minecraft Wiki
跳转到导航 跳转到搜索
该页面是Minecraft Wiki:社区专页的存档页，请勿在此发布新的讨论。

可在当前讨论页发起新讨论。

存档

关于准心和准星

本主题或以下段落文字移动自Minecraft Wiki:编辑求助。

我通过搜索发现Wiki中充斥着大量的“准心”和“准星”，我比较好奇的是，它们是同义词？或是某词有错别字？这是否需要规范/纠正？

比如说：十字准心、十字准星。TeaSummer（留言） 2024年7月19日 (五) 01:20 (UTC)

简繁标准译名分别为“十字准星”和“十字準心”。──  Leo_leo_768（Talk｜Contributions） 2024年7月19日 (五) 01:26 (UTC)
简体页面也有“十字准心”这个词。 TeaSummer（留言） 2024年7月19日 (五) 01:56 (UTC)
那就是用错了嘛，就7个看到帮忙手改一下就好 ──  Leo_leo_768（Talk｜Contributions） 2024年7月19日 (五) 01:59 (UTC)
OK，已修改， TeaSummer（留言） 2024年7月19日 (五) 02:10 (UTC)

沙砾java版和基岩版名字不同

java版的名字是沙砾，基岩版是砂砾，我不知道这个是否有必要更改，以及如果有该如何更改 Yeliang（留言） 2024年7月24日 (三) 10:30 (UTC)

没必要更改，请以Java版的标准译名为准。-- XiaoXin666（T·C） 2024年7月24日 (三) 10:53 (UTC)
好的，感谢提醒 Yeliang（留言） 2024年7月24日 (三) 15:52 (UTC)
关于原因你可以参照Minecraft wiki:译名标准化。 Rowboat123（留言） 2024年7月26日 (五) 11:21 (UTC)

关于“小僵尸”与“幼年僵尸”

下列有关“小僵尸”与“幼年僵尸”的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已统一为“幼年XX”。

在编辑过程中发现“小僵尸”与“幼年僵尸”这两个词存在混用现象(包括僵尸村民与猪灵、僵尸猪灵也有此现象)，是否有必要进行统一？ Abigpigeon（留言） 2024年7月26日 (五) 11:55 (UTC)

 同意，我认为“小僵尸”为口语化说法，而“幼年僵尸”更官方化，的确有必要统一 Rowboat123（留言） 2024年7月29日 (一) 06:47 (UTC)
改成幼年更好，因为小没有具体说明有多“小” 无聊的 电脑b 2024年7月29日 (一) 10:00 (UTC)
的确，幼年僵尸和普通僵尸比幼年僵尸小，但普通僵尸和巨人比就显得小了。 Rowboat123（留言） 2024年7月29日 (一) 10:37 (UTC)
 支持统一为“幼年僵尸”。僵尸NBT字段布尔型IsBaby的值决定其是否为幼年僵尸，其中“Baby”也适合翻译为“幼年”。 Hos_Soh<T> 2024年7月29日 (一) 10:34 (UTC)
村民也有此类现象。记者会💣🎤（留言） 2024年7月29日 (一) 10:50 (UTC)
你认为统一为小僵尸还是幼年僵尸？ Rowboat123（留言） 2024年7月29日 (一) 10:55 (UTC)
我认为统一为幼年僵尸更好。记者会💣🎤（留言） 2024年7月29日 (一) 11:03 (UTC)
经搜索，“小僵尸”（及“小僵尸村民”、“小僵尸猪灵”）的用法多见于较早编写的页面，而“小猪灵”的用法似乎只在Tutorial:方块和物品复制出现1例。说混用可能有些夸张，也许只是当时编辑者的习惯如此。要改的话， 赞成，不过大量文字替换建议在MCW:BOTR申请。
另外值得注意的是：1、2023年生物投票服务器活动中有作为“迷你体型的普通僵尸”出现的“小僵尸”。2、在Tutorial:NBT与JSON中有作为命令输入文本的“快乐的小僵尸”。对于这两处、以及其他在口语化的语境内出现的“小僵尸”用法也许可以排除出需要修改表述的情形？ Don Trueno T/C 2024年7月30日 (二) 06:24 (UTC)
我认为在口语方面，（此处的“口语”指平常说话，或者线上讨论（比如论坛或讨论页））把“幼年僵尸”指作“小僵尸”是可以接受的。但是，在百科上，它将会作为很多人的参考对象。
任何东西都要有官方化的说法。若在公开的地方表述错误，则会使更多人表述错误，除非几乎所有人全部同意该说法，否则该说法还是混乱的，这时候，合理的统一是必然的。 Rowboat123（留言） 2024年7月30日 (二) 07:03 (UTC)
大家都习惯了小僵尸这个称呼。我认为应该把主页面的小僵尸统一为幼年僵尸，主页面一般用书面语。教程页面保持原样，因为大部分教程都是偏口语化的。记者会💣🎤（留言） 2024年7月30日 (二) 07:30 (UTC)
 我同意你的说法，原因和你说的一样。 Rowboat123（留言） 2024年7月30日 (二) 07:42 (UTC)
同意，但主页面和教程页面都得改（除了及其特殊的几个） Ggg（留言） 2024年7月30日 (二) 07:44 (UTC)
及其特殊的几个指什么？能说的具体一些吗？ Rowboat123（留言） 2024年7月30日 (二) 08:15 (UTC)
 支持统一为“幼年僵尸”。在 Wiki 上，还是使用“幼年僵尸”这种官方化的说法比较好。-- Az7627（留言丨贡献） 2024年8月8日 (四) 12:36 (UTC)
支持统一改成“幼年僵尸”，但在社区未达成共识前还是不要擅自修改 MC Satellite（留言） 2024年8月18日 (日) 14:09 (UTC)
该部分内容已经于半个月前完成修改 Abigpigeon（留言） 2024年8月18日 (日) 14:17 (UTC)
友情链接：Minecraft Wiki:机器人工作请求#文本替换申请：小XX→幼年XX LightChasing（留言） 2024年8月18日 (日) 23:04 (UTC)

网易百科疑似搬运Mincraft Wiki内容

绯色色的视频：

抛开视频中所说的错误不谈。监守者（00:16），瓶子草荚果（00:25），山羊角（00:33），古迹废墟（00:44）等回答的第一句话与Minecraft Wiki几乎完全一致。

Benben（留言） 2024年7月28日 (日) 02:51 (UTC)

wiki已经被太多AI或者工具NTR过了--Luoboju0 2024年7月28日 (日) 06:09 (UTC)
网易在中国大陆地区拥有Minecraft代理权，你可以把它类比做Mojang直接引用Wiki内容的行为。--AblazeVase69188（留言 | 贡献） 2024年7月28日 (日) 06:37 (UTC)
关于该问题详见Minecraft Wiki:转载须知，里面已经说明：需要署名，可网易并未标注来源。 Rowboat123（留言） 2024年7月29日 (一) 11:00 (UTC)
关于这个问题，请查看Minecraft Wiki首页的第一句话：欢迎来到这个完全公开、可自由编辑的Wiki，中文Minecraft Wiki。
从首页就可以发现，该wiki完全公开，于是并没有侵权。 Rowboat123（留言） 2024年7月29日 (一) 06:50 (UTC)
需要提醒的是，本wiki内容采用CC BY-NC-SA 3.0授权，并非是传统意义上的完全公开
对于本事件的态度我与AblazeVase的表态一致。 YukiSugar [Talk] 2024年7月29日 (一) 07:03 (UTC)
你这个也有道理，不过中国版的游戏百科错误是 肯定的。 Rowboat123（留言） 2024年7月29日 (一) 07:15 (UTC)
完全公开是指公开检视、公开编辑，不是指允许随便复制贴上本wiki内容而不带出处，如此解读有些离谱。 ──  Leo_leo_768（Talk｜Contributions） 2024年7月29日 (一) 07:22 (UTC)
它署名了吗？ 无聊的 电脑b 2024年7月29日 (一) 10:47 (UTC)
好像没 Ggg（留言） 2024年7月29日 (一) 10:50 (UTC)
你的署名是什么意思？是指标注来源吗？ Rowboat123（留言） 2024年7月29日 (一) 10:51 (UTC)
对 无聊的 电脑b 2024年7月29日 (一) 10:53 (UTC)
那也的确。 Rowboat123（留言） 2024年7月29日 (一) 10:58 (UTC)
那你想表达什么呢？或者说你认为Minecraft Wiki可以就此事做些什么呢？数列的通项公式（留言） 2024年8月1日 (四) 11:33 (UTC)
认为中国版并没有按CC BY-NC-SA 3.0授权来转载，即网易侵权。 Rowboat123（留言） 2024年8月2日 (五) 07:43 (UTC)
曾经似乎也发生过类似的事情。当时是怎么应对的？当时的应对方式可以作为本次事件的参考吗？ LightChasing（留言） 2024年8月9日 (五) 03:06 (UTC)
把七年前的讨论搬出来作为参考是不是不太合适...而且多玩在版权方面的争议特别多，典型的包括提供盗版下载，但网易在中国大陆地区持有Minecraft的独家代理权，个人认为两者不能相提并论。--AblazeVase69188（留言 | 贡献） 2024年8月9日 (五) 04:29 (UTC)
由于七年前的讨论的事情已经过于久老，当时的观点可能并不符合现今的状况，所以不因参考。 Rowboat123（留言） 2024年8月9日 (五) 05:49 (UTC)

关于拆分“门”页面的建议

如题，我观察到门这个页面包含了大量单独的门，我觉得可以把本页面拆分到不同的子页面，就像是关于页面楼梯的拆分。以及活板门船等页面。 原来的页面可以留着，当一个类别。By ☆ Eason2013（留言） 2024年7月30日 (二) 12:54 (UTC)（最后编辑于2024年8月1日 (四) 03:22 (UTC)）

 同意你的观点，可以拆分为铜门，铁门和木质门。门这个页面可作为消歧义页面使用。 Rowboat123（留言） 2024年8月9日 (五) 05:52 (UTC)
 支持，可以参考Minecraft Wiki:论坛/提议拆分台阶、楼梯、墙进行。--数列的通项公式（留言） 2024年8月18日 (日) 15:39 (UTC)
这个问题推荐在门页面提出讨论。 Rowboat123（留言） 2024年8月19日 (一) 02:49 (UTC)

调整音乐页面的分类

最近的更新中，Mojang将一些新加入的音乐设置为可在生存模式和主菜单中播放，而这些音乐在页面中仅被归类为主世界音乐。我提议将这些音乐同时添加到主菜单音乐分类中。数列的通项公式（留言） 2024年8月1日 (四) 11:29 (UTC)

 已完成 Rowboat123（留言） 2024年8月9日 (五) 05:52 (UTC)

关于公式显示问题

我观察到有关公式在显示时，开方不会出现根号，乘方指数也以普通大小显示。

同时在编辑页面时则可以观察到公式本身是没有问题的——的确具有开方、乘方运算。

如距离页面中欧几里得距离与水平欧几里得距离便是如此。

三卤甲烷（留言） 2024年8月4日 (日) 10:53 (UTC)

您使用的浏览器很可能不支持显示公式，请检查您的浏览器厂商和版本。 MysticNebula70 T  2024年8月4日 (日) 12:06 (UTC)

创建描述从Mojang服务器下载的资源文件的页面

自13w16a起，Mojang为资源文件引入了一种新的模式：从Mojang服务器单独下载，按散列值放置；散列值可以在一系列称为“资源索引文件”的json表中查询。语言文件、音效文件，以及后续引入的zip格式Unifont字体等按照这一方式存储。自22w42a起，资源索引不再按版本号命名，这意味着资源索引的工作方式不再能简单地描述。因此，或许需要创建一个页面描述这类文件的工作原理，以及资源索引名称到版本的对应关系。

我在个人沙盒里创建了User:Dovisutu/Sandbox/散列资源文件用于准备这些内容，现已基本完工，计划转正。目标页面的标题待定，希望能在这里讨论出结果。

关注度

就目前的内容而言，相关内容应该足以支撑一个页面。

音效、语言（可翻译文本），以及Unifont字体等内容（及相关的教程）需要引用该页面，以准确描述这些内容的存放位置。--Dovisutu（留言） 2024年8月7日 (三) 10:04 (UTC)

已自行移入主命名空间。修订意见可在相应讨论页继续提出。--Dovisutu（留言） 2024年8月8日 (四) 13:12 (UTC)

漏洞的表示方法

每个版本页面都会提及该版本修复的漏洞，然而在措辞上仍有分歧。

以Java版24w21a为例，“修复”中的“MC-170103 — 未驯服的狼仅在被激怒和跳跃时乞求食物。”所要表示的意思，到底是现在“未驯服的狼仅在被激怒和跳跃时乞求食物”，还是修复了“未驯服的狼仅在被激怒和跳跃时乞求食物”呢？

相比之下，基岩版的表示方法则有所不同。在1.21.30.22的页面中，“修复”段内则会加上“现在”“修复了”等字词，使得修复了什么一目了然，然而这种表示方法又不在“单纯表示漏洞”的范畴内。

而在早期页面中，漏洞的表示方式则又近似于现在Java版的表示方式。如果用一种页面的方式来理解另一种页面，将会出现巨大的问题。

因此，需要对漏洞的表示方法进行统一。

在此给出几种方案供选择，大家也可提出自己的方案：

方案1

单纯列举存在什么漏洞，如现在的Java版。

方案2

体现出漏洞的修复。如现在的基岩版。

Huanick（留言） 2024年8月12日 (一) 05:33 (UTC)Huanick

请见MCW:格式指导/版本#修复。-- XiaoXin666（T·C） 2024年8月12日 (一) 05:36 (UTC)
因为"原文如此"，参见基岩版1.21.30.22的官方更新公告，其原文使用的就是"fixed"
顺便一提，在使用 ~~~~ 签名后无需再写一遍名字 YukiSugar [Talk] 2024年8月12日 (一) 05:56 (UTC)

关于方块碰撞箱

希望在方块的介绍页加入方块碰撞箱的高度宽度 莫莫莫提（留言） 2024年8月15日 (四) 08:31 (UTC)

个人 不赞成，方块模型有很多不规则的（例如漏斗和炼药锅）Colin_319（查 ▪ 论 ▪ 编） 2024年8月18日 (日) 12:36 (UTC)
他指的是对于一个方块模型，可以完整包括它的最小长方体的长宽高吧。--数列的通项公式（留言） 2024年8月18日 (日) 15:41 (UTC)
不规则方块在判定箱界面也有其表达方式 莫莫莫提（留言） 2024年9月8日 (日) 02:47 (UTC)
我认为应将“碰撞箱”改为“轮廓箱”，这样可以更好显示火把等无碰撞箱的方块，请详见判定箱。 Rowboat123（留言） 2024年8月29日 (四) 10:36 (UTC)
轮廓箱高度宽度在游戏内没有任何实际意义，碰撞箱高度宽度可以用来卡实体进行怪物分类之类的操作 莫莫莫提（留言） 2024年9月8日 (日) 02:49 (UTC)
简单来说，就目前而言，方块碰撞箱是一个复杂的概念，它根本不是前面某人提的所谓“方块的身高和腰围”。一些方块的碰撞箱自己就可以不是规则的长方体（堆肥桶和炼药锅等），一些方块还能依据自己的方块状态不同而有不同的碰撞箱（蛋糕和悬挂的告示牌等）。可以在Minecraft Block Property Encyclopedia（方块属性百科）上查阅到所有方块碰撞箱的原始数据。
总而言之，这不是“要不要”写的话题，而是“有没有”人能写且有空可以写的问题，只是上方的讨论明显偏题了。 Don Trueno T/C 2024年9月8日 (日) 03:57 (UTC)

为条目正文中表示稀有度的文本添加颜色

例如“史诗”文本可以显示为史诗等 Colin 319（留言） 2024年8月17日 (六) 07:06 (UTC)

这样表达最大的问题就是常见稀有度，难道它是白色？ Rowboat123（留言） 2024年8月18日 (日) 14:31 (UTC)
常见可以用黑色啊 --Colin_319（查 · 论 · 编） 2024年8月19日 (一) 00:23 (UTC)
常见用黑色？那如果在深色模式呢？ Rowboat123（留言） 2024年8月19日 (一) 02:34 (UTC)
我是想表达不上色的。。 --Colin_319（查·论·编） 2024年8月19日 (一) 03:31 (UTC)
那你的表述有误，这样到就可以了。 Rowboat123（留言） 2024年8月19日 (一) 04:07 (UTC)
可以参考{{exp}}用模板来实现：
{{rarity|common}} --> 常见
{{rarity|uncommon}} --> 少见
{{rarity|rare}} --> 稀有
{{rarity|epic}} --> 史诗
但是显然游戏中的颜色在Wiki的白色背景下有些刺眼。另外也需要考虑替换的工作量。UniIght17（留言） 2024年8月19日 (一) 01:15 (UTC)
游戏中颜色在wiki浅色模式中太刺眼，但是在深色模式中“常见”太暗淡，对于替换的工作量，你可以创建一个机器人账户。 Rowboat123（留言） 2024年8月19日 (一) 01:26 (UTC)
 反对。稀有度对于其他条目来说并不是一个重要的信息，并且有可能引起读者的不适与困惑（花花绿绿的这是啥呀）。仅在对应信息框的InvSprite中显示足矣。 Wilf233zhMCW（论·功） 2024年8月19日 (一) 01:42 (UTC)
没错。并且“常见”的颜色该如何显示？如果为白色，在浅色模式下几乎不可见；如果为黑色，在深色模式下也非常暗淡。而如果不上色（如果不上色，文字在浅色模式下为黑色，在深色模式下为白色），又违反了“为条目正文中表示稀有度的文本添加颜色”的条件，“常见”的颜色将有很大争议。 Rowboat123（留言） 2024年8月19日 (一) 02:37 (UTC)

页面创建建议

本主题或以下段落文字移动自Minecraft Wiki:论坛/页面创建建议。

建议创建新的页面：不祥试炼 原因：与不祥试炼同为不祥事件的袭击有对应的页面，而不祥试炼没有。且包括英文在内的8种语言都有此页面，而中文没有。

见英文wiki：Ominous Trial

--SongBellsen（留言） 2024年8月17日 (六) 07:42 (UTC)

我认为如果不详试炼需要单独创建页面，不如给试炼单独创建页面而不是消歧义，因为不详试炼是试炼的变种（像不详宝库是宝库的变种一样）。--数列的通项公式（留言） 2024年8月18日 (日) 15:44 (UTC)
“试炼”不是事件，“不祥试炼”是事件，看看英文wiki，对于试炼就没有创建页面 SongBellsen（留言） 2024年8月19日 (一) 06:40 (UTC)
 同意你的说法，如果你已经创建了沙盒或个人沙盒，请你将链接给出。 Rowboat123（留言） 2024年8月28日 (三) 10:13 (UTC)
个人沙盒已创建，链接：User:SongBellsen/沙盒/不祥试炼
目前内容全是英文，直接复制粘贴的英文wiki内容，且缺少文件 SongBellsen（留言） 2024年8月30日 (五) 12:50 (UTC)
现在页面已基本创建完成，已移动至沙盒。链接：Minecraft Wiki:沙盒/不祥试炼 SongBellsen（留言） 2024年8月30日 (五) 15:18 (UTC)

关于Wiki一些注释不一致的问题

注意到在中文Minecraft Wiki中有一些注释不统一的情况。

注释表示方式

  1. 在某些页面中，注释被放在了括号外，如金苹果：“（Enchanted Golden Apple）[注 1]”。
  2. 在其他页面中，注释被放在了括号内，如奶桶：“（Milk Bucket[注 1]）”和海龟蛋：“（Turtle Egg[注 1]）”。
  3. 还有页面中使用了不同的标记方式，如闪烁的西瓜片：“（Glistering Melon Slice[名称 1]）”和下界砖块：“（Nether Bricks）[n 1]”，以及小麦种子：“（Wheat Seeds）[1]”，皆与上面的“[注 1]”不同。

注释内容

  1. 有些注释仅指出基岩版中的名称，如金苹果：“在基岩版中，英文名称为Enchanted Apple。”。
  2. 有些注释同时指出了Java版和基岩版中的名称，如奶桶：“在Java版中被称为‘Milk Bucket’，在基岩版中被称为‘Milk’。”

除这些例子外，还有草丛、雪、光源方块、铁砧等页面都是如此。

上面那些注释例子其实都想表达同一个意思，就是用注释来说明不同版本的英文名。但问题就在于，明明是同一个意思却用了不同的表示方式，例如，有一些地方会使用<ref>来作为注释（例如下界砖块出现“[n 1]”），而有些地方会搭配{{in}}和{{fn}}一起使用（导致会出现“在基岩版中，称为”和“在基岩版中被称为”这种微小差异）。

综上所述，这里提供了2种办法作为参考：

  1. 对于注释的表示方式，将所有形如“[名称x]”“[n x]”及其类似注释名称全部统一为“[注 x]”；
  2. 类似英文Minecraft Wiki，用“sth. (in Java Edition) or sth. (in Bedrock Edition)”的形式。

对于注释内容，Wiki本身就已经给出了Java版的名称（无论是中文还是英文），但又在一部分注释中再次写到“在Java版中……”等字眼，造成重复，违反了格式指导#保持条目的简明与更新。所以删除注释中的此类字眼，并改为“在基岩版中被称为oo”即可。大家意见如何Txt（留言） 2024年8月18日 (日) 12:20 (UTC)

 赞成。是应该统一格式，个人认为方案一比较好，方案二就出现括号套括号了 Colin_319（查 ▪ 论 ▪ 编） 2024年8月18日 (日) 12:33 (UTC)
我认为应统一为[名称 x]，在括号外，内容为：“在基岩版被称为……”样式。 Rowboat123（留言） 2024年8月18日 (日) 14:35 (UTC)
补充：目前需要解决的是，1.这些注释应该放在括号内还是括号外；2.要统一成什么样子。Txt（留言） 2024年8月18日 (日) 14:53 (UTC)
的确，我的回复已经在上文给出。 Rowboat123（留言） 2024年8月19日 (一) 01:21 (UTC)
应该是历史遗留性问题，但不可否认的是，这对编者造成的困扰更大。所以我 支持统一其注释方式。 TeaSummer（Q&A|C） 2024年8月18日 (日) 15:14 (UTC)

对于随机页面的调整建议

本主题或以下段落文字移动自Talk:Minecraft Wiki。

随机页面作为一个功能按键，对用户的帮助无疑是巨大的，但在使用时常常会出现页面随机到其他游戏的情况（即使用户更本不会玩这款游戏）因此，我希望进入Minecraft wiki时，随机页面仅在Minecraft wiki内随机。Minecraft dungeons wiki和Minecraft legends wiki同理 MC Satellite（留言） 2024年8月20日 (二) 00:25 (UTC)

目前除教程外的内容命名空间中，侧边栏的“随机页面”文本下会有另一个“Minecraft”“Dungeons”或“Legends”文本，点击可以前往对应的命名空间。对于Special:随机页面，可以在后面加上命名空间的前缀，以跳转到指定的命名空间，例如：“Special:随机页面/教程”可以跳转到教程命名空间的任意一个页面。--AblazeVase69188（留言 | 贡献） 2024年8月20日 (二) 01:23 (UTC)
目前本wiki已有该功能。在特定游戏的页面时，“随机页面”下会有一个缩进可点选的游戏名称，点击即会在指定游戏wiki中随机。 ──  Leo_leo_768（Talk｜Contributions） 2024年8月20日 (二) 06:58 (UTC)

关于主菜单截图的格式指导和帮助

本人和其他编者共同写了一篇主菜单截图的格式指导和帮助，可在User:Wilf233/沙盒3阅读，但对于条目命名有一定的分歧。我们想到的方法有：合并入MCW:文件，将MCW:文件拆分出格式指导作为子页面，命名为Help:主菜单截图或Help:截图等等，欢迎大家给出意见。--Wilf233zhMCW（论·功） 2024年8月20日 (二) 07:51 (UTC)

文言不必要吧。 无聊的 电脑b 2024年8月21日 (三) 14:26 (UTC)
文言的图片基本都引用自本站，因此是必要的。 Wilf233zhMCW（论·功） 2024年8月23日 (五) 06:54 (UTC)
我认为你的看法没有任何问题。 Rowboat123（留言） 2024年8月28日 (三) 10:14 (UTC)

关于对“生电”的解释

生电机器大多都以机械化或半机械化生产某种或多种物品，能否将其解释为“生产红石电路”？ 或是对生电有两种解释： 1.狭义上，指“生产红石电路”，即机械化或半机械化生产某种或多种物品的红石电路 2.广义上，指“生存实用电路”，即原来的解释，只要是为生存模式服务的红石电路都算生电 此外，储电（如全物品）、TNT大炮（如珍珠跑）、航械（如世界吞噬者）等，它们虽然不生产物品，但为生存模式服务，是否可以算作广义生电？ --Cmprssntl（留言） 2024年8月22日 (四) 14:41 (UTC)

“生存实用电路，简称生电。生电的定义范围较广泛，通常集数电、模电、械电三家之长，主要特点是为生存模式服务，因而追求耗材少、卡顿低、稳定性强等。”援引自红石电路#生存实用电路，我认为这并不存在歧义，已经明确指出了这是一个广泛概念。 --YukiSugar [Talk] 2024年8月22日 (四) 15:28 (UTC)
是的，这确实是一个广泛概念。但是，这样定义“生电”，界限未免太模糊了。“为生存模式服务”本身就是一个主观的概念，不够严谨。
现在市面上的“生电机器”大多都以机械化或半机械化生产某种或多种物品（比如刷...机、刷...塔）作为工作目的（这也符合“为生存模式服务”），由此来定义“生电”为“生产红石电路”，界限分明，又严谨。
但是，在社区中又有许多经常和“生电”联系在一起的红石作品，比如储电（如全物品）、TNT炮（如珍珠跑）、航械（如世界吞噬者）、甚至是更新抑制器等，它们虽然不生产物品，但也“为生存模式服务”，在“生电”中也有一定地位。
所以，我的观点是：对生电有两种解释：一是狭义上，指“生产红石电路”，即以机械化或半机械化生产某种或多种物品作为工作目的的红石作品，就是“生电”；二是广义上，指“生存实用电路”，即原来对“生电”的定义，凡是被认为为生存模式服务的红石作品都算“生电” Cmprssntl（留言） 2024年8月23日 (五) 13:36 (UTC)
这需要看社区的看法。 Rowboat123（留言） 2024年8月28日 (三) 10:15 (UTC)
我觉得还是指“生存实用电路”。 Oak tree（留言） 2024年8月30日 (五) 04:23 (UTC)

以下留言与上一条留言间隔了32日。

我又有了新的观点。
  • “生电”中的“生”字同时有“生产”和“生存”的意思。
    • 如果与“储电”相对，则意思为“生产红石电路”；
    • 如果与团队制作、耗时长的大型红石作品相比，则意思为“生存实用电路”。
  • 我还认为这两种意思不是包含关系，而是并列关系，中间有一定交集。
    • 很多生产物品的机器并不实用，生存中实用的机器也不一定是生产物品的。
      • 比如普通生存中没有用的刷泥土机和很实用的物品分类器。
补充：在社区中是“生存实用电路”。
我认为我的回复有一定的帮助，因此虽然距上一条留言超过30天，但我还是发布了。 Oak tree（留言） 2024年10月1日 (二) 06:44 (UTC)
同意“这两种意思不是包含关系，而是并列关系，中间有一定交集。”但大体上看“生存实用电路”是广义的，一般包括“生产红石电路”。（因为绝大多数的生产都是有价值的，都是为生存模式服务的。包括你提到的刷泥土机，也可以为大型建筑生产材料。）
此外，是否有必要将此话题移至论坛进行长期讨论？Cmprssntl（留言） 2024年10月1日 (二) 14:24 (UTC)
应该是没有必要。 Oak tree（留言） 2024年10月8日 (二) 07:02 (UTC)
最重要的就是“生”字的一字多义。 Oak tree（留言） 2024年10月8日 (二) 07:07 (UTC)
我注意到，一个“生存实用电路”之所以“实用”，无非只做了两件事：生产和储存物品。而生产物品的可以解释为“生产红石电路”。
因此，“生电”可以指：
1.狭义上： “生产红石电路”，即机械化或半机械化生产某种或多种物品的红石电路（通常是“生存实用电路”中的生产部分），例如：不带收集的袭击塔、刷冰机等。
2.广义上：“生存实用电路”，即为生存模式服务的红石电路【通常由生产部分（狭义生电）和收集部分（储电）组成，但不一定全部有，例如全物品没有生产部分、一些简易的“丐版”机器如刷花机依靠玩家自行捡起生产的物品，没有收集部分】
Cmprssntl（留言） 2024年10月18日 (五) 13:23 (UTC)
我觉得国外对于生电的描述更为准确，他们一般把这种叫做技术生存，技术是重要的内容，而非电路 Jumao（留言） 2024年11月2日 (六) 08:44 (UTC)

修订讨论页方针

下列有关修改方针的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已修改。

由于近期各讨论页上的挖坟行为时有发生，严重干扰了正常讨论秩序，我建议将“避免回复超过一年的话题”修改为“避免回复超过一个月的话题”。MysticNebula70 T  2024年8月27日 (二) 16:01 (UTC)

 同意，一个月时间不短了。 KaplanSteve  T/C 2024年8月27日 (二) 16:07 (UTC)
 支持。一般来说，一个月时间足够覆盖大多数的讨论。另外，建议将此规定修改为：避免回复超过一个月的话题，且不得回复超过一年的话题。   Anterdc99（论·功） 2024年8月27日 (二) 16:12 (UTC)
这样把“避免”和“禁止”区分开就很好，避免了我半小时前在群里提到的“两个月前内容页面讨论页的建议完成了如何回复”的矛盾。--QWERTY-5238（留言） 2024年8月27日 (二) 16:40 (UTC)
 支持，同时可为MCW:NOT添加对应说明，如“Minecraft Wiki不是聊天室”等。-- ultim_0 [talk][work] 2024年8月27日 (二) 16:14 (UTC)
 支持，本人认为应当缩短讨论页最长回复间隔时限。--QWERTY-5238（留言） 2024年8月27日 (二) 16:40 (UTC)
 支持，建议第一次警告第二次封禁，封禁讨论页编辑权限不低于1个月。 Lxazl5770zh.admin（论 ▪ 功） 2024年8月27日 (二) 16:53 (UTC)
 支持，而且我也认为应该修改为“避免回复超过一个月的话题，且不得回复超过一年的话题”。“避免”留下了一定余地：对于总是提醒别人要签名、不要回复超过一年的话题等的用户，可以认定为灌水，并予以警告乃至封禁；对于正常的讨论，则不进行处理。--AblazeVase69188（留言 | 贡献） 2024年8月28日 (三) 03:54 (UTC)
 支持，为避免建议性质话题在长期搁置后不便回复，建议仅当“已完成了话题提出者的请求；或对此话题有建设性意见”时允许回复。Don Trueno T/C 2024年8月28日 (三) 04:14 (UTC)
 反对，“一刀切”的做法有所不妥。对于求助类话题的回复可以适用一个月，例如Special:diff/966810、Special:diff/966806，此类留言应当避免出现。但是意见征求类的话题不适用一个月，例如Minecraft Wiki:论坛/音轨文件处理规范、Minecraft Wiki talk:管理团队、Tutorial talk:袭击农场、en:Minecraft Wiki talk:Style guide#Writing coordinates不应拘泥于一个月，我们仍然希望有人挖到这些并且继续讨论。 Wilf233zhMCW（论·功） 2024年8月28日 (三) 06:27 (UTC)
 补充，每种话题都有其时效性，对于即时需要改动的话题可能一个月也都算过长，但如果是征求意见类型的一个月可能不够，确实应当放宽期限，但如果是长达一年的话题的话，除了闲聊的话也确实太过分。 ChemistChang（Talk/Contributions) 2024年8月28日 (三) 07:36 (UTC)
 补充，感觉这些用户也并非故意捣乱，而是在不清楚一些编辑规定的条件下想参与讨论而导致的。或许应该思考是否可提供另外的渠道让这些新手用户发表观点，这样才能从根本上解决此类问题。--Luoboju0 2024年8月28日 (三) 07:56 (UTC)
 同意，个人觉得设置一个过滤器善意提醒比封禁更有用处。 ChemistChang（Talk/Contributions) 2024年8月28日 (三) 10:18 (UTC)
我 同意你的说法，应该设置一个过滤器，使社区环境良好。 Rowboat123（留言） 2024年8月28日 (三) 10:18 (UTC)
 不完全同意,对于社区专页、论坛及其他高流量讨论页，管理员已经在已经在把一个月无讨论的讨论存档了。所以对于这些页面不应有这种规定。 无聊的 电脑b 2024年8月28日 (三) 09:01 (UTC)
已根据反馈意见适当修订条例。如有其他意见请重开新话题讨论。MysticNebula70 T  2024年9月3日 (二) 08:46 (UTC)

关于引入表格式生物掉落物列表与村民交易列表

介于现有的基于文字描述的生物掉落物与村民交易选项存在不直观与在复杂掉落物的情况下表述不清（如女巫）的问题。故在此建议引入en的表格式生物掉落物列表与村民交易列表。具体效果可参见en的对应页面，类似于现有的箱子战利品表格。 --YukiSugar [Talk] 2024年8月30日 (五) 16:27 (UTC)（最后编辑于2024年8月30日 (五) 16:48 (UTC)）

 反对引入掉落物表格，因为功能还不完善，无法用来表示基岩版鲑鱼的掉落物分布。详见Discord#Wiki中7月13日13:54 (UTC+8)的聊天记录。 Wilf233zhMCW（论·功） 2024年8月30日 (五) 16:43 (UTC)（最后编辑于2024年8月30日 (五) 16:44 (UTC)）

关于顶栏模板问题

在现有的条目顶部的顶栏模板（如About、For、Distinguish），出现了其他游戏的导向链接，若Minecraft系列的衍生游戏越来越多，这些链接可能像“开火车”一样越堆越长。因此，本人建议将其他游戏中同名/相似的条目链接放置于条目底部的“参见”这个子标题下。--Emm（留言） 2024年8月31日 (六) 11:06 (UTC)

更建议写一个新的模板放在顶部来解决问题。--  Lakejason0（论•功） 2024年8月31日 (六) 12:44 (UTC)
 反对，顶注之所以为条目之最顶，就是为了快速消歧义，避免找错页面。放参见就失去了其功能。目前衍生游戏就那几个，并不算多，过长多是个别顶注写的方式不洽造成，单独修正其写法即可。例如：“关于Minecraft Dungeons中的XX请见‘Minecraft Dungeons:XX’，关于Minecraft Legends中的XX请见‘Minecraft Legends:XX’。”应改为“关于衍生游戏中的XX请见‘Dungeons:XX’及‘Legends:XX’。” ──  Leo_leo_768（Talk｜Contributions） 2024年8月31日 (六) 12:51 (UTC)
或者可以写一个新的模板替代Dungeons hatnote和Legends hatnote。关于其他游戏中的XX请见‘Dungeons:XX’、‘Earth:XX’或‘Legends:XX’。--Emm（留言） 2024年9月1日 (日) 10:55 (UTC)
考虑到顶注还可能包含其他项目，且依然要指定有哪些游戏，这么做省不了多少功夫，这也是此二模板现在几乎没有使用的原因。 ──  Leo_leo_768（Talk｜Contributions） 2024年9月1日 (日) 11:53 (UTC)

沙盒中的“不祥试炼”页面何时能够移出沙盒

Minecraft Wiki:沙盒/不祥试炼，是我自己创建的页面，何时能够移除沙盒

该页面原本是我的个人沙盒，基本完成后我将其移动到了沙盒，现在已即将完工，何时能够移出沙盒成为一个正式的页面 --SongBellsen（留言） 2024年8月31日 (六) 11:24 (UTC)

 支持 认为已经可以移入正式页面。一些语言表述上的问题我明天更改一下。 QWERTY-5238（留言） 2024年8月31日 (六) 15:10 (UTC)
呃，我想说一下，昨天您没有修改该页面，且仍未移入正式页面 SongBellsen（留言） 2024年9月2日 (一) 01:29 (UTC)
 反对。这篇文章更像是人为规定的、将一系列机制整合起来的一个事件，而非游戏代码内在。因此我建议写成教程的形式。 Wilf233zhMCW（论·功） 2024年9月2日 (一) 08:23 (UTC)
个人认为其启动与结束还是很明确的一个试炼生怪砖之游戏机制。如果这都不能算，那能算的没剩多少了。──  Leo_leo_768（Talk｜Contributions） 2024年9月2日 (一) 09:15 (UTC)
这个条目似乎有些尴尬，内容几乎是试炼生怪砖的子集，却又不如其详细。不过脉络性的确较直接看试炼生怪砖佳，再改写下置于教学也是不错。不过有一点，尽管不祥试炼只是普通试炼的变体，我们却要在没有一个页面专讲试炼的情况下转开一个页面讲不祥试炼？哪怕要移动至教学，这个不合理之处也得解决。我会希望再为其扩充一般试炼的内容，并并入教学:征服试炼密室。──  Leo_leo_768（Talk｜Contributions） 2024年9月2日 (一) 09:15 (UTC)
  1. 不祥试炼和袭击都是不祥事件，袭击由相应的页面，不祥试炼也应有相应的页面。
  2. 见英文Wiki的页面 Ominous Trial，且七种语言的Wiki中都有该页面，我认为中文Wiki也应有页面，且我创建该页面时就是参考的英文Wiki创建的。
  3. 普通试炼不属于游戏事件，英文Wiki里也没有普通试炼的页面。
所以我认为该页面应该创建。 SongBellsen（留言） 2024年9月2日 (一) 10:02 (UTC)
 提醒：“英文Wiki和其他语言都有这个页面，所以中文Wiki也要有这个页面”不是一个有效的理由。不同语言的Wiki并非只是其他语言Wiki的翻译版本，各语言Wiki的收录范围也有所不同。参考考古（en:Archaeology）页面。--AblazeVase69188（留言 | 贡献） 2024年9月2日 (一) 10:09 (UTC)
关注度从来都没写特殊游戏事件都要单独建一个条目，而只有谬谬两种的不祥事件也难以达成都要建条目的统一必要。或许等哪天，Mojang为不祥事件添加更多的独特内容时，可能真需要为各不祥事件单独开条目。但以现在的情况是不祥试炼只是一个仅牵涉到试炼生怪砖且与普通试炼相差不大的功能，并没有拉开需要另建条目的差距。条目究其还是要有用，而目前该页面非但无法为读者提供更多的帮助（作为另一个页面更不清楚的子集），还反而会增加维护障碍，建立之实际意义不明。 ──  Leo_leo_768（Talk｜Contributions） 2024年9月2日 (一) 10:59 (UTC)

一些生物掉落物没有写具体的掉落概率

一些生物会在死亡之后掉落物品，但是相关的页面并没有写出具体概率，而是只写了一个范围，如末影人掉落0-1个珍珠。这是否是有意的？（我不会看代码）--数列的通项公式（留言） 2024年9月2日 (一) 15:41 (UTC)

目前未特别注明皆应为均匀（等几率）分布。 ──  Leo_leo_768（Talk｜Contributions） 2024年9月2日 (一) 15:44 (UTC)
个人理解理论上对于这种情况掉落概率范围内的概率都是相同的，如果特殊的话会标出概率的。故应该不必标明。 ChemistChang（Talk/Contributions) 2024年9月6日 (五) 07:22 (UTC)

关于建立恶魂火球独立页面的建议

介于火球目前已经足够支撑起一个独立页面所需的内容量，且在其他分站有拆分的先例（EN、ES），且与发射器与烈焰人发射的小火球存在明显的不同，故在此建议建立独立页面。草案可参见Minecraft_Wiki:沙盒/火球 --YukiSugar [Talk] 2024年9月6日 (五) 17:07 (UTC)

那么我们是否应该拆分出浮漂、羊驼唾沫、潜影弹、末影龙部件、唤魔者尖牙、拴绳结？也许需要一个话题来讨论这个。--siiftun1857[T/C/E] 2024年9月6日 (五) 17:18 (UTC)
另外我无法理解为何“与发射器与烈焰人发射的小火球存在明显的不同”是支持拆分的原因之一。--siiftun1857[T/C/E] 2024年9月6日 (五) 17:19 (UTC)
已发布论坛话题Minecraft Wiki:论坛/条目中的关联实体拆分讨论。--siiftun1857[T/C/E] 2024年9月10日 (二) 18:26 (UTC)

有关“胜利屏幕”的移动

注意到制作人员名单因页面组织等原因重定向到了胜利屏幕，且可观察到有用户对此感到疑惑。

首先，“胜利屏幕”及“鸣谢及著作权屏幕”是出自Mojang官方反混淆表的类名（WinScreen、CreditsAndAttributionScreen）。但可以预料到的是，这两个名字没有已知关注度。考虑到SEO问题，原本关注度可能较高的制作人员名单这一页面不应该成为重定向（会被搜索引擎误认为本站没有相关内容）。我要求讨论并得出整理相关页面的共识。--  Lakejason0（论•功） 2024年9月19日 (四) 02:18 (UTC)（最后编辑于2024年9月19日 (四) 02:19 (UTC)）

在我整理链入的过程中，我见到了“鸣谢名单”“制作人员名单”“鸣谢与著作权说明”等很多说法，因此这东西究竟叫什么可能需要研究。根据即时通讯内的讨论，我认为即使要创建页面，那么页面的标题应该是“鸣谢名单”而不是“制作人员名单”。
我采用“胜利屏幕”是出于以下考量：
  • 这是一个非常直观的名字，能让读者了解这是一个“游戏赢了！”（打败末影龙）之后出现的东西。
  • 这个名称表示了这是一个界面元素，类似“暂停屏幕”“主菜单”“选项屏幕”等内容，介绍其技术性属性和玩家如何在其中用键盘和鼠标导航。
  • 这个名字具体出自反混淆表提供的类名WinScreen。
“鸣谢与著作权说明屏幕”取自本地化字符串credits_and_attribution.screen.title和类名CreditsAndAttributionScreen。
重新创建“终末之诗”自然是因为这是一个高流量页面，不可没有这个页面，用于专门介绍终末之诗的相关历史和著作权问题我认为是合适的。
需要指出，从未有过“制作人员名单”这一页面，“原本关注度可能较高的制作人员名单这一页面不应该成为重定向”的“原本”更是无从谈起。最初的组织方式是把所有内容全放在了“终末之诗”页面，此名称的页面的缺失并不是此次移动导致的结果，也不可能是这一过程进行时可能或应该考虑到的问题。如果没有“制作人员名单”这一页面导致了问题，那么移动其他页面也不可能对这一问题有影响。--siiftun1857[T/C/E] 2024年9月19日 (四) 02:54 (UTC)（最后编辑于2024年9月19日 (四) 05:29 (UTC)）
了解了。希望下次在移动时能够更明确地标注名称来源。--   Lakejason0（论•功） 2024年9月19日 (四) 06:58 (UTC)
那么我想你应该是曾错误地认为“制作人员名单”是曾经存在的页面。既然这一点已经被证伪，那么这个话题的前提算是不成立的。就这样吧。--siiftun1857[T/C/E] 2024年9月19日 (四) 09:03 (UTC)
“终末之诗”页面原本是包含了“制作人员名单”以及最后的“引言”，可能对于读者来说这些也是“终末之诗”的一部分，或者说wiki之前传达的意思就是终末之诗包含了这些部分，所以我认为应该讨论“终末之诗”到底指什么，包含了什么，以及终末之诗页面是否需要提一下后续播放的制作人员名单，甚至于页面是否应当移动。在该页面被移动前，页面最上方放置了{{move}}模板，该模板中写明了“中文Wiki的移动页面需要在讨论批准后进行”，这也是我认为移动该页面需要讨论的原因之一。
--MCluoluo（讨论·贡献） 2024年9月19日 (四) 11:13 (UTC)
这个话题是在讨论移除“制作人员名单”页面导致的问题。然而“制作人员名单”这个页面从来不存在，因此话题的前提不成立，一致认为此话题已经结束了。请不要挪用别的话题发布离题讨论，尤其是你已经在别处发了一样的话题的情况下。--siiftun1857[T/C/E] 2024年9月19日 (四) 12:14 (UTC)

2024年Block & Quill成员选举：提名已开始

2024年Block & Quill成员选举现在已经开始提名阶段。Block & Quill Ltd是所有语言版本的Minecraft Wiki的法律实体。虽然成员大会也有一些企业管理的任务，其主要任务还是确保公司做出的决定和社区的利益相符合。

我们希望Block & Quill的成员大会能够代表Minecraft Wiki社区的多样性。因此，我们正在寻求下一届成员大会的成员。

请你们鼓励他人参与选举，如果可以的话自己参与选举。

成员的责任是什么？

成员的责任主要有：

  • 监督wiki的运行，并代表wiki社区向我们的托管方Weird Gloop沟通。
  • 作为和第三方（例如Mojang）的正式沟通方式
  • 在wiki代表的帮助下，确保公司的决定和所有wiki的编辑者的利益相符合。
  • 帮助制定公司的长期策略。
  • 帮助参与公司的日常治理，包括：
    • 审核公司管理层的绩效；
    • 批准预算，审核预算申请；
    • 定期参加成员大会，讨论以上事项和其他事项。
参加选举需要满足什么条件？

满足以下条件的用户有被选举权：

  • 当前没有在任何一个Minecraft wiki上被封禁。
  • 不是选举委员会的成员或Block & Quill Ltd的受薪合同工或员工
  • 必须“品行良好”，即：
    • 不得犯严重罪行或任何涉及不诚实或欺骗的罪行；
    • 不得因管理不善或行为不当而被非营利组织或其他公司免职；
    • 选举委员会有权进行背景调查来检查这一点。
  • 必须年满18周岁，并达到其母国和/或居住国的成年年龄；
  • 有可靠的联系方式，也就是个人邮箱地址；
  • 必须愿意在非公开的公司登记册上登记自己的真实姓名和地址。

强烈推荐达到的条件：

  • 不太可能有利益冲突；
  • 至少有对话级别的英语知识（至少满足CEFR B1）；
  • 对整个Minecraft Wiki计划感兴趣并积极参与其中，而不仅是一个语言wiki。

要参与选举或了解更多信息，请您访问meta:2024 elections（英）。

-- GIM Dianliang233 T C 2024年9月20日 (五) 00:31 (UTC)

奇怪的Category:1

标题中的链接、样式代码、模板、魔术字或解析器函数已被移除。

如题，是有意为之还是模板错误？目前有477个页面属于本分类。--Colin_319（查·论·编） 2024年9月20日 (五) 11:45 (UTC)

Special:Diff/974552。编者征用临时分类来为正在进行的工作提供页面列表是常见的情况，“1”这一分类在过去也经常被使用于类似的用途，不必大惊小怪。--siiftun1857[T/C/E] 2024年9月20日 (五) 11:49 (UTC)
实际上这个分类昨天还有近六百个页面，完全清理还需要一些时间。--siiftun1857[T/C/E] 2024年9月20日 (五) 11:55 (UTC)
您的签名无法被模块正常识别，建议修改。--AblazeVase69188（留言 | 贡献） 2024年9月20日 (五) 13:49 (UTC)
签名？我以为这个只会识别用户名？ --Colin_319（查·论·编） 2024年9月20日 (五) 22:46 (UTC)
模块代码见Module:Topic list（昨天打了补丁因而现在正常运行了）。另外建议不要在签名中使用外部链接（如[https://zh.minecraft.wiki/w/User:]）链往自己的用户页，你可以使用内部链接（如[[User:]]）。Don Trueno T/C 2024年9月21日 (六) 10:27 (UTC)
 已改，主要是之前不知道怎么写跨语言的超链接 --Colin_319（查·论·编） 2024年9月22日 (日) 00:39 (UTC)

关于拆分"人类"页面的建议

原因：此页面在en wiki中已被拆分成“生物”（已移除生物）与“怪物”两个页面。虽然它们的模型和纹理一样，但实际上是两个独立的实体。而且“人类”似乎并未在游戏中使用，因为显示名称分别为“生物”和“怪物”（Java版1.9之前数据值为48和49的生物蛋）。Villager-bloc-h 2024年9月21日 (六) 16:36 (UTC)

同时人类页面可保留作为消歧义页面 Villager-bloc-h 2024年9月21日 (六) 16:43 (UTC)

关于大事记页面的书写规范

现有的大事记页面没有一个准确的收录标准以致于mcc，minecraft experience 似乎不能收录其中，并且存在某些格式不规范问题，是否应该将mcc和minecraft experience此类活动收录其中，并且规范minecraft live的书写格式？ Misividkoukou（留言） 2024年9月28日 (六) 10:45 (UTC)

同意。大事记应该以minecraft的各类活动为基础，加上简略的版本记录。
minecraft live差不多每年都有，规范格式是必须的。 Oak tree（留言） 2024年10月1日 (二) 06:23 (UTC)
：同意。mcc和minecraft experience等活动在玩家社区有一定影响力，是Minecraft的大事 Cmprssntl（留言） 2024年10月12日 (六) 13:42 (UTC)

修复物品配方到底该放在哪个段落？

如题，我发现这个事很奇怪，有的被放在“合成”段落下面（例如剪刀 § 获取和盔甲 § 获取），另一种是和“砂轮”“铁砧”段落合并组成“修复”段落（例如盾牌 § 获取），我觉得有必要统一--Colin_319（查·论·编） 2024年10月1日 (二) 12:18 (UTC)

中国版文件的许可协议是否合适

近日有编者提出疑问，当前中国版文件（如独有皮肤）的许可协议为{{License Mojang}}，但网易的服务条款与Mojang的不一样。中国版文件的许可协议标记为“著作权属于Mojang”是否合适？如果不合适，应该如何解决？ AblazeVase69188（留言 | 贡献） 2024年10月1日 (二) 14:41 (UTC)

改成 {{License copyright}} 模板可行吗42KDiscuss 2024年10月19日 (六) 17:41 (UTC)

远古城市”基岩版与Java版“的战利品表有些许错误

1．该战利品表中从上往下数第二个附魔书后面的注释［战利品2］应改为［战利品7］ 原因：［战利品2］的解释是”所有魔咒出现的几率相同，可以施加灵魂疾行和迅捷潜行以外的宝藏型魔咒”。但是即使不打开实验性玩法来体验远古城市＂基岩版(即将到来)＂或＂java版（即将到来）＂的新战利品表，你仍然有约23%的几率在远古城市箱子中找到带有随机等级的迅捷潜行魔咒的附魔书，这也就说明远古城市能开出两种不同的附魔书，一种的逻辑如［战利品2］所说能开出灵魂疾行和迅捷潜行以外的魔咒，还有一种能开出迅捷潜行。因此该战利品表中注释因改为带有随机等级的迅捷潜行魔咒，即与［战利品7］注释相同（经用指令找远古城市几百次打开箱子统计，且多个外国wiki也有一样的计载。）2409:8A00:2644:4220:ACBC:AE4A:1634:1F72（留言）2024年10月5日 (六) 15:18 (UTC)（最后编辑于2024年10月5日 (六) 15:25 (UTC)）

 已修复。--XiaoXin666（T·C） 2024年10月30日 (三) 15:43 (UTC)

关于后续版本指南的撰写

鉴于目前游戏内容更新已转变为drop（小更新）的形式，若每个小更新都单独写一个指南，其数量可能过多。我个人主张将所有小更新都合并到一个页面，例如将勇气之袋和冬季小更新的内容并入“xx版指南/1.21版本”，同时把棘巧试炼的指南移动至上述页面，在页面中用小标题分开即可。若这种方式被认可，我也会把犰甲狼兵的内容并入“1.20版本”的指南。

基岩版勇气之袋的更新内容我已写入棘巧试炼指南中，等正式版发布后再分开。对于沙盒中已创建的两个指南，我提议将其删除，一是内容不全（搬运en），二是目前还没讨论出共识，先不急于写。各位也可在下面提出自己的看法，感谢。

注：这种用版本号命名指南的方式之前也有先例。-- McplayerFS（讨论 | 贡献） 2024年10月20日 (日) 06:57 (UTC)（最后编辑于2024年10月23日 (三) 14:32 (UTC)）

首先需要注意的是，小更新的版本归属定义如何。例如1.20.6属于犰甲狼兵吗？ 无聊的 电脑b 2024年10月21日 (一) 12:59 (UTC)
其实我是反对将小版本的变更指南放到大版本里的，因为指南其实起到了“说人话的更新介绍”的作用，小更新只是体量较小，跟大更新没半点关系，其仍需要有更新指南给人看。页面过多吗，我们都有巨量的每个快照一个页面了，再说小更新本身和其对应的版本都是独立的页面不是么，1.20.5的内容没写在1.20，犰甲狼兵更不会是足迹与故事的子段落，独立的更新独立的条目合情合理。条目数量从来都不在考量范围，划分合理才是，而我个人是乐见这些Drop能使指南具更有意义的划分。总之， 反对 将所有小更新都合并到一个页面。 ──  Leo768（Talk｜Contributions） 2024年10月21日 (一) 13:10 (UTC)
那就要更改Navbox Java Edition versions模板了，现在看来就是表示了小更新属于大更新的一部分。 无聊的 电脑b 2024年10月23日 (三) 12:45 (UTC)

想到冬季小更新的内容可能较多，合并到一个页面不合适，故我放弃我的主张，仍按原来的惯例一个版本一个指南。-- McplayerFS（讨论 | 贡献） 2024年10月23日 (三) 14:32 (UTC)

我们或许应当捋一下小更新和大更新的关系了，目前我认为可以有以下看法：
1.小更新是大更新的特殊的一部分，例：1.20.5属于足迹与故事，但它也属于犰甲狼兵,1.20.6也属于足迹与故事，但不属于犰甲狼兵；
2.小更新和大更新是接续的，例：足迹与故事的范围仅限于1.20-1.20.2，1.20.3-1.20.4属于蝙蝠和陶罐，1.20.5-1.20.6属于犰甲狼兵；
3.小更新是从大更新中分离开来的一段，例：1.20-1.20.2、1.20.4、1.20.6属于足迹与故事1.20.3属于蝙蝠和陶罐，1.20.5属于犰甲狼兵。
把这个关系弄明白了，才能讨论关于指南的问题。--无聊的 电脑b 2024年10月25日 (五) 10:11 (UTC)

是否应将愚人节版本的特性拆分为单独界面

下列有关页面拆分的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为拆分相关页面。

在寻找愚人节版本的特性时，我们可能会在页面中花费大量时间来寻找相关资料，这很让人苦恼。我认为应该将愚人节版本的特性像英文Wiki那样拆分为多个子界面，方便玩家查找。MChtc（留言） 2024年10月29日 (二) 04:03 (UTC)

没必要，一是关注度太低，二是内容太多太冗杂。 ChemistChang（Talk/Contributions) 2024年10月29日 (二) 06:58 (UTC)
同意上一条回复，但是可以将一些关注度较高的条目拆分，例如粉红凋灵 Unreal-75417/Calm4.ogg 2024年11月5日 (二) 12:56 (UTC)
同意。 MChtc（留言） 2024年11月8日 (五) 12:28 (UTC)
或许可以建一些重定向？例如Hash跳转到24w14potato#物品 Colin_319（查·论·编） 2024年11月16日 (六) 00:27 (UTC)
 信息：en为大部分愚人节版本的特性都建立了独立页面或放到了介绍同类内容的页面中（如同其他正常版本内容），例如en:Copper Spleaves、en:It's very slippery和en:Potion#Joke potions。这类页面虽然平时总体上关注度可能不太高，但对于一段时间内正在游玩这些版本的玩家会很有帮助。目前在中文Wiki的问题可能是工作量太大，如果要进行拆分可能要专门开个计划。从读者角度看，目前查找其中某个特性的详细信息较为困难，我个人是更 支持拆分的。近几年的愚人节版本内容都较为充足，我个人近期就在玩愚人节版本，查阅相关内容时时常感到步骤较为复杂：搜索→进入对应版本页面→按快捷键输入查找的内容→查找后阅读（可能还找不到想要的信息，例如某个该版本独有方块的爆炸抗性或音效等内容），而在en搜索就能直接进入对应特性页面查阅，且内容更加详细。--Endearing Cat（留言） 2024年11月16日 (六) 15:51 (UTC)
同意。 MChtc（留言） 2024年11月19日 (二) 05:36 (UTC)
按过去的共识及现行措施，愚人节内容放入一般特性页面虽有疑虑，但只要有人愿意写，愚人节版本开子页面（主空间可能要再讨论）将部分内容放过去是可以接受的。这中间最大的阻碍其实是有人有兴趣愿意写（活跃编者中玩愚人节版本的不多），过去也有人尝试后半途而废（如User:Emm/光线追踪）。若几位愿意主笔编写和拆分，我个人很乐意支持。 ──  Leo768（Talk｜Contributions） 2024年11月19日 (二) 05:55 (UTC)
谢谢。MChtc（留言） 2024年11月21日 (四) 13:06 (UTC)
 题外话：本人并未放弃过愚人节页面的编写，只是忙于Legends命名空间的基建，愚人节页面只是被暂时搁置了。--Emm（留言） 2024年11月24日 (日) 05:08 (UTC)
 支持240E:345:503:B800:592D:10F:AA3B:F1A8 2024年11月21日 (四) 13:53 (UTC)
我不反对拆分愚人节版本页面。但是en能建立独立的愚人节特性页面的很重要的一个原因是它的活跃编者要远多于中文wiki，同时拆分愚人节页面的工作量实在是有些大，因此我更倾向于暂时 不拆分，而是多补充愚人节版本页面的内容。 Villager-bloc-h 2024年11月22日 (五) 15:30 (UTC)
根据以上讨论，最大的问题或许是目前本Wiki上有兴趣且愿意编写这类页面的用户并不多。然而读者的需求仍然存在。
我的新建议是“软拆分”，即不集中拆分这些页面，而是允许用户为其中某个或某类特性单独创建（子）页面，待相关内容完成后再适当删减主页面，以此来逐渐改善阅读体验并使相关内容得到扩充。
这可能会持续很长一段时间，但在人手不足同时照顾读者体验的情况下可能是一个比较好的解决办法。 --Endearing Cat（留言） 2024年11月22日 (五) 16:45 (UTC)
 反对。一是自动值（Autovalue）不能支持，需要修改现有模块；二是自动链接（Autolink）也无法支持，因为缺少标准化译名；三是与其他内容放在一起可能会导致困惑，需要增补格式指导来规定其与常规特性的区分。至于找不到的问题，可以使用浏览器的查找功能来寻找页面信息，拆分并不会让寻找特别方便，只是收录的内容会更加详细。如果我们能解决上面三个问题，主要是前两个，那么即使我们人再少，我也 支持拆分，细水长流。 Wilf233zhMCW（论·功） 2024年11月22日 (五) 16:59 (UTC)
 完全同意你的说法。缺失对应的技术支持很不利于编辑，对这些页面的影响特别大。如果有人愿意解决和维护这些技术性问题，相关内容的扩充才更有利于推进。我可以从英文Wiki翻译相关页面的大部分内容过来，但由于自动值与自动链接不支持，且不懂得如何修改相关模块，导致几乎无法正常写完一个条目。 --Endearing Cat（留言） 2024年11月22日 (五) 17:26 (UTC)
谢谢各位的支持。 MChtc（留言） 2024年11月23日 (六) 01:49 (UTC)
Autovalue和Autolink从来都不是问题。一来愚人节本就不适合也没必要使用Autovalue，已移除特性不也没有用Autovalue。二来单独一个页面就不会有译名问题了吗？该处理的不会因为拆分而增多。退一步说，若因无Autovalue和Autolink导致讯息缺少，再如何也不会比目前集中在一个页面的情况来的缺少，以此理由反对就有点本末倒置了。 ──  Leo768（Talk｜Contributions） 2024年11月23日 (六) 06:34 (UTC)
支持拆分。个人认为编写工作量大、缺少标准译名和技术支持等都不能算是不拆分的决定性理由。
已移除的特性，未使用的特性中也有少部分被拆分为独立页面，均通过特殊手段绕过了自动值之类的门槛。且愚人节版本特性仍有大量的读者需求，因此编写详细内容是很有必要的。
对于译名标准化问题，由于并不是正式的名称，讨论出一个中文名并不是什么特别大的阻碍，并且为了防止和正式译名的混淆，可以设计信息框等表示页面中包含非标准译名。
BoredYukolin（留言） 2024年11月23日 (六) 05:35 (UTC)
 题外话：我之前在用户页里翻译过一些愚人节玩笑的单品页面，见User:Ultim 0/Joke/April Fools。--ultim_0 [talk][work] 2024年11月23日 (六) 05:42 (UTC)
 题外话：我已经将en:Moon Cow翻译至我的个人沙盒（User:Villager-bloc-h/Sandbox/月球牛），欢迎各位前来改进此页面。 Villager-bloc-h 2024年11月23日 (六) 08:19 (UTC)
感谢各位的帮助与支持，让我们共建更好的zhMCW！ MChtc（留言） 2024年11月24日 (日) 02:19 (UTC)
 支持拆分，近期也看到了大家对这一计划的推动与付出。但同时想提个建议，由于该计划规模极大，建议对条目的创建和编写顺序进行一些规划。 Abigpigeon（论/功) 2024年11月30日 (六) 01:23 (UTC)

目前正在尝试对少量的方块、物品和实体页面进行创建，确保没有技术上的问题。--Wilf233zhMCW（论·功） 2024年11月27日 (三) 08:10 (UTC)

请大家注意，在所有需要的模板模块创建完之前，以及编辑中出现的各种问题解决完之前，请不要大量创建页面，感谢理解。对于在编辑中出现的各类问题，欢迎在下方继续讨论。--Wilf233zhMCW（论·功） 2024年12月9日 (一) 15:32 (UTC)

个人认为，“因为目前无法直接写到最好就先不准写”并非一个合适的做法。先求有再求好，在过去也没这么多方便模版和良好规范的情况下我们还不是写了一个个页面，之后才去慢慢改进。再说从上次您说要等，等到现在也完全没看到等出了个什么东西进展，或是等到什么时侯才能继续的征兆。不管怎么看，未来在已有页面的前提下为其用上发展出的新方法总比从零开始写页面轻松。至于所谓因为未来还要改，导致目前付出的一部分劳力很可能被浪费，我认为这是建立页面的编者自己情愿付出的。 ──  Leo768（Talk｜Contributions） 2024年12月9日 (一) 16:30 (UTC)
目前主要是在等手动传参的挖掘表，因为手写实在太坐牢了，而且之后还要批量替换。 Wilf233zhMCW（论·功） 2024年12月9日 (一) 16:34 (UTC)

加载器Mod的称呼是否应统一

标题中的链接、样式代码、模板、魔术字或解析器函数已被移除。原标题：加载器Mod的称呼是否应统一

我在编辑Wiki时偶然发现，在不同页面甚至相同页面中，对于加载器Mod的称呼似乎各有差异，例如：

建议使用任意如下方法进行修正/不进行修正：

全部修改
  • 将所有页面中的mod/MOD/模组修改为Mod（由机器人完成）。
保守方法
  • 不修改现有的错误，但今后编辑应使用Mod而非其他。
不修改

Afulai2333（留言） 2024年11月2日 (六) 03:34 (UTC)

同意 MChtc（留言） 2024年11月2日 (六) 03:40 (UTC)
我的建议是不修改。
上述几个名称均为玩家常用的，没有什么区分，且限制只能使用同一个说法可能会让Wiki编辑举步维艰。 Liaoxiangbin（留言） 2024年11月2日 (六) 03:54 (UTC)
同意修改 无聊的 电脑b 2024年11月2日 (六) 10:49 (UTC)
 反对修改，看得懂就行了，没必要限制。 Wilf233zhMCW（论·功） 2024年11月2日 (六) 16:53 (UTC)

2024年度最活跃新人评选

下列有关2024年度最活跃新人评选的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为2024年度最活跃新人为TeaSummer。

候选人和评选标准

参见：User:Lxazl5770/AnnualActiveNewcomers

2024年度最活跃新人评选活动已经开始了，共有18位候选人。

年度最活跃新人奖评选标准：

  1. 必须是一名注册用户，且不是傀儡账号。
  2. 该用户的首次编辑日期，或者是首次活跃的日期为评选年份上一年的10月1日至当年的9月30日。
  3. 活跃期需满3个月且无任何重大封禁记录。
  4. 该用户的编辑应该以非用户页空间为主。
  5. 原则上每年只会评选一位用户，评选完成后不取消其称号，除非其出现重大封禁记录。
  6. 若当年没有用户完全满足以上条件，则取最接近者获得称号。
  7. 评选的重要依据是该用户的用户贡献。
2024年度活跃新人
用户名 编辑总数[注 1] 本地用户组
Eletron ProCoress 666 （无）
Hos Soh 590 （无）
Mygane 510 （无）
CaN2crow987 3680 巡查豁免者
Emm 4584 巡查豁免者
Jandy 172 （无）
Ggg 584 （无）
SpCo 1624 巡查员
YukiSugar 2877 巡查豁免者
TeaSummer 3677 巡查员
Dovisutu 1014 巡查豁免者
Rosa hybrida659 110 （无）
Abigpigeon 823 （无）
Colin 319 489 （无）
SongBellsen 754 （无）
Jumao 360 （无）
BoredYukolin 894 （无）
春风得意 352 （无）
  1. ↑ 截至2024年11月2日12:30 (UTC+8)

选举人条件

选举人同时需要满足以下三个条件：

  • 是一名自动确认用户，且账号注册日期早于评选开始日期（即2024年11月2日）
  • 不是机器人账号或傀儡账号
  • 选举期间账号未处于封禁状态

评选方法

本次评选采用Schulze方法，即为18位候选人进行排序，1代表最喜欢，18代表最不喜欢。

请注意：您可以为多个候选人填入相同的数字，也可以对不喜欢的候选人不填任何数字。

投票链接：点此进入

投票时间：即日起至2024年11月30日23:59 (UTC+8)，您可以在截止时间之前更改您的选票。

如对选举有问题，请在下方提出。 --Wilf233zhMCW（论·功） 2024年11月2日 (六) 07:18 (UTC)

评选结果

本次投票共有22位用户参与，列表如下：

其中Minecraforever因为账号处于封禁状态不满足选举条件，Wilf233作为选举负责人应放弃投票权防止利益冲突，因此2人的选票未计入。其余20位投票人均满足选举条件。

下表是根据投票结果的直接排序。3行2列中的“11/4”表示11名投票人将TeaSummer排在CaN2crow987之前，4名投票人将CaN2crow987排在TeaSummer之前。因为投票人可以给候选人相同的排名或没有排名，所以这意味着每个单元格中的数字加起来可能不等于20。

根据排序得出的直接结果
TeaSummer CaN2crow987 YukiSugar SpCo Emm Dovisutu BoredYukolin Eletron ProCoress Abigpigeon Jumao Ggg Rosa hybrida659 春风得意 Hos Soh Mygane Jandy Colin 319 SongBellsen
TeaSummer 11/4 11/3 8/2 14/1 13/1 16/1 15/1 14/1 16/1 18/0 18/0 17/0 17/0 18/0 16/2 18/0 18/0
CaN2crow987 4/11 7/6 8/8 11/6 9/3 12/4 11/2 12/4 12/3 12/3 14/1 14/1 13/0 13/1 12/1 14/1 14/0
YukiSugar 3/11 6/7 7/6 7/5 7/3 11/4 12/2 9/3 12/2 14/2 14/1 15/1 14/0 14/0 12/1 14/1 14/0
SpCo 2/8 8/8 6/7 9/3 9/3 10/4 11/3 9/4 12/2 15/1 14/2 14/0 14/0 15/0 13/2 15/0 15/0
Emm 1/14 6/11 5/7 3/9 7/4 10/4 11/4 9/4 12/3 13/2 15/1 14/2 14/2 14/1 14/2 14/1 15/1
Dovisutu 1/13 3/9 3/7 3/9 4/7 8/8 9/3 7/5 9/4 10/3 10/1 11/2 10/1 10/1 9/1 10/1 11/0
BoredYukolin 1/16 4/12 4/11 4/10 4/10 8/8 6/4 5/5 7/1 11/2 10/2 13/1 11/1 12/0 10/3 12/0 12/0
Eletron ProCoress 1/15 2/11 2/12 3/11 4/11 3/9 4/6 5/5 7/2 7/3 7/1 8/2 7/0 9/0 7/2 8/1 8/0
Abigpigeon 1/14 4/12 3/9 4/9 4/9 5/7 5/5 5/5 8/1 10/2 9/0 11/1 9/1 9/0 7/2 11/0 11/0
Jumao 1/16 3/12 2/12 2/12 3/12 4/9 1/7 2/7 1/8 8/4 6/4 9/3 7/2 8/1 6/4 9/1 9/0
Ggg 0/18 3/12 2/14 1/15 2/13 3/10 2/11 3/7 2/10 4/8 6/5 8/4 7/4 7/4 5/5 7/4 8/2
Rosa hybrida659 0/18 1/14 1/14 2/14 1/15 1/10 2/10 1/7 0/9 4/6 5/6 4/3 4/3 5/3 3/4 6/2 7/1
春风得意 0/17 1/14 1/15 0/14 2/14 2/11 1/13 2/8 1/11 3/9 4/8 3/4 3/4 5/4 5/5 4/3 5/3
Hos Soh 0/17 0/13 0/14 0/14 2/14 1/10 1/11 0/7 1/9 2/7 4/7 3/4 4/3 3/1 4/3 5/2 5/1
Mygane 0/18 1/13 0/14 0/15 1/14 1/10 0/12 0/9 0/9 1/8 4/7 3/5 4/5 1/3 4/3 5/3 5/2
Jandy 2/16 1/12 1/12 2/13 2/14 1/9 3/10 2/7 2/7 4/6 5/5 4/3 5/5 3/4 3/4 5/3 6/1
Colin 319 0/18 1/14 1/14 0/15 1/14 1/10 0/12 1/8 0/11 1/9 4/7 2/6 3/4 2/5 3/5 3/5 3/2
SongBellsen 0/18 0/14 0/14 0/15 1/15 0/11 0/12 0/8 0/11 0/9 2/8 1/7 3/5 1/5 2/5 1/6 2/3

第一名的结果显而易见，但后续位次的排序仍有同票情况，因此基于Schulze方法，得出下表：

基于Schulze方法中强度比较过程后的最终结果
TeaSummer CaN2crow987 YukiSugar SpCo Emm Dovisutu BoredYukolin Eletron ProCoress Abigpigeon Jumao Ggg Rosa hybrida659 春风得意 Hos Soh Mygane Jandy Colin 319 SongBellsen
TeaSummer 11/0 11/0 8/0 14/0 13/0 16/0 15/0 14/0 16/0 18/0 18/0 17/0 17/0 18/0 16/0 18/0 18/0
CaN2crow987 0/11 7/0 7/0 11/0 9/0 12/0 11/0 12/0 12/0 12/0 14/0 14/0 13/0 13/0 12/0 14/0 14/0
YukiSugar 0/11 0/7 7/0 7/0 7/0 11/0 12/0 9/0 12/0 14/0 14/0 15/0 14/0 14/0 12/0 14/0 14/0
SpCo 0/8 0/7 0/7 9/0 9/0 10/0 11/0 9/0 12/0 15/0 14/0 14/0 14/0 15/0 13/0 15/0 15/0
Emm 0/14 0/11 0/7 0/9 7/0 10/0 11/0 9/0 12/0 13/0 15/0 14/0 14/0 14/0 14/0 14/0 15/0
Dovisutu 0/13 0/9 0/7 0/9 0/7 0/0 9/0 7/0 9/0 10/0 10/0 11/0 10/0 10/0 9/0 10/0 11/0
BoredYukolin 0/16 0/12 0/11 0/10 0/10 0/0 6/0 0/0 7/0 11/0 10/0 13/0 11/0 12/0 10/0 12/0 12/0
Eletron ProCoress 0/15 0/11 0/12 0/11 0/11 0/9 0/6 0/0 7/0 7/0 7/0 8/0 7/0 9/0 7/0 8/0 8/0
Abigpigeon 0/14 0/12 0/9 0/9 0/9 0/7 0/0 0/0 8/0 10/0 9/0 11/0 9/0 9/0 7/0 11/0 11/0
Jumao 0/16 0/12 0/12 0/12 0/12 0/9 0/7 0/7 0/8 8/0 6/0 9/0 7/0 8/0 6/0 9/0 9/0
Ggg 0/18 0/12 0/14 0/15 0/13 0/10 0/11 0/7 0/10 0/8 6/0 8/0 7/0 7/0 4/0 7/0 8/0
Rosa hybrida659 0/18 0/14 0/14 0/14 0/15 0/10 0/10 0/7 0/9 0/6 0/6 4/4 4/4 5/4 4/4 6/0 7/0
春风得意 0/17 0/14 0/15 0/14 0/14 0/11 0/13 0/8 0/11 0/9 0/8 4/4 4/4 5/4 4/4 5/0 5/0
Hos Soh 0/17 0/13 0/14 0/14 0/14 0/10 0/11 0/7 0/9 0/7 0/7 4/4 4/4 4/4 4/4 5/0 5/0
Mygane 0/18 0/13 0/14 0/15 0/14 0/10 0/12 0/9 0/9 0/8 0/7 4/5 4/5 4/4 4/4 5/0 5/0
Jandy 0/16 0/12 0/12 0/13 0/14 0/9 0/10 0/7 0/7 0/6 0/4 4/4 4/4 4/4 4/4 5/0 6/0
Colin 319 0/18 0/14 0/14 0/15 0/14 0/10 0/12 0/8 0/11 0/9 0/7 0/6 0/5 0/5 0/5 0/5 3/0
SongBellsen 0/18 0/14 0/14 0/15 0/15 0/11 0/12 0/8 0/11 0/9 0/8 0/7 0/5 0/5 0/5 0/6 0/3

因此我宣布，2024年度最活跃新人为TeaSummer。选举结果将公示一周，如有疑问可在期间提出。

选举负责人：--Wilf233zhMCW（论·功） 2024年11月30日 (六) 18:49 (UTC)

关于改进“随机页面”

我认为应该改进一下随机页面，毕竟进入了随机页面后，很大概率跳转到一些测试版本的内容和地下城内容，如“18w44a”“启动器1.5.3”“Legends:孢背兽”等，影响用户体验，可以加一些选项“我不要测试版本内容”和“我不要Minecraft传奇/地下城内容”等，这有利于探索minecraft的冷门知识（应该）Freeorange（留言） 2024年11月7日 (四) 12:18 (UTC)

随机页面也是老问题了。英文Wiki近期写了一个改善随机页面体验的小工具以期解决该问题（见讨论）， 建议引入。 ──  Leo768（Talk｜Contributions） 2024年11月7日 (四) 12:28 (UTC)
 支持引入小工具。 Wilf233zhMCW（论·功） 2024年11月7日 (四) 12:43 (UTC)
支持。 MChtc（留言） 2024年11月7日 (四) 12:54 (UTC)
 已添加此小工具。MysticNebula70 T  2024年11月7日 (四) 14:49 (UTC)
我该如何使用？Freeorange（留言） 2024年11月8日 (五) 04:42 (UTC)
此小工具默认启用，您可以在参数设置中开关。--AblazeVase69188（留言 | 贡献） 2024年11月8日 (五) 04:55 (UTC)

辅助程序与编辑器页面存废讨论

本主题或以下段落文字移动自Talk:辅助程序与编辑器。

如题，目前这些页面中记载的内容都严重过时，也没人更新，甚至“服务器面板”页面还挂着待翻译。本wiki没有义务收录第三方内容，我建议将其删除，同时清除所有链入。

目前有两种方案：

  1. 直接删除本页面及其子页面。
  2. 存档至用户页（参考另类玩法）或其他地方。

-- McplayerFS（讨论 | 贡献） 2024年10月20日 (日) 08:07 (UTC)

补充一下，en把它移到了教程子页面，不过我不太建议这样，教程本身已经是天坑了，再往里面倒垃圾不好。 -- McplayerFS（讨论 | 贡献） 2024年10月20日 (日) 08:11 (UTC)
 支持删除，Wiki没有义务记录非官方内容，更何况这些内容已经严重过时，对读者来说没有什么用处。--AblazeVase69188（留言 | 贡献） 2024年10月20日 (日) 08:11 (UTC)
 支持删除，在3年前的讨论中的问题现在仍然未解决，足以证明这个页面没什么人看，且维护难度相当大。个人认为没有存留的必要。 Abigpigeon（论/功) 2024年10月27日 (日) 05:22 (UTC)
 支持，理由同@AblazeVase69188 Aiden8115(Talk) 2024年11月12日 (二) 06:50 (UTC)
 支持删除。Afulai2333（留言） 2024年11月14日 (四) 13:49 (UTC)
 支持存档至用户页。这些页面内容较多，即使已严重过时，也具有一定价值，直接删除略感到浪费。考虑到日后可能仍有玩家需要这些信息（例如经常游玩旧版本游戏的玩家），万一有人真的需要查看这些内容也可浏览存档后的页面。（存档到其他合适位置？如果有那也行，至少我不太同意删除）--Endearing Cat（留言） 2024年11月14日 (四) 15:35 (UTC)
 信息：MCW:N#C3.2已经提到，这些页面中的一部分目前仅做留档之用，除非该条方针更改，否则我更倾向于 保留。--Endearing Cat（留言） 2024年11月15日 (五) 00:02 (UTC)
方针并非不可修改的。话题结束后可以根据讨论结果修改或移除该条方针。--XiaoXin666（T·C） 2024年11月23日 (六) 05:50 (UTC)
 支持您上述的观点。 ——陈Jerry呀~（T/C） 2024年12月14日 (六) 04:32 (UTC)
 倾向保留，考虑到近期wiki.vg内容并入Minecraft Wiki的新情况，而这些页面有在wiki.vg上受到较好的维护。若我们也愿意翻译保留wiki.vg的内容，那该页面也将作为合并与更新的一部分。 ──  Leo768（Talk｜Contributions） 2024年11月30日 (六) 06:28 (UTC)（最后编辑于2024年11月30日 (六) 13:42 (UTC)）
支持删除 120.230.101.218 2024年12月12日 (四) 23:18 (UTC)
 疑问 移动到用户页是否有不打算被读者发现的意图？用户页实在是一个不容易被发现的地方。如果不是今天看到这个讨论，我不会知道曾经有过“另类玩法”页面。 Silverteal（留言） 2025年1月5日 (日) 09:46 (UTC)
存放到用户页只是因为正式的 Wiki 页面不合规（例如过时、不符合关注度等原因）而需要删除或存档，并没有“不打算被读者发现的意图”。Wiki 本身就是一个 Minecraft 的百科，为什么要让某个页面不易被人发现呢？等到页面恢复，自然又可以在正式页面中找到它。 Hopə [ Talk | Cons ] 2025年1月6日 (一) 12:26 (UTC)
我观察到的事实是，存档后的页面更难以被需要的用户发现。我不是很清楚存档的页面有恢复到主命名空间的历史。感谢您的解释。 Silverteal（留言） 2025年1月7日 (二) 00:13 (UTC)

关于整理维护模板的提议

“维护模板”大致可分为“信息框维护模板”和“行内维护模板”两类，如今已遍布Wiki的各个角落。但是由于缺乏一定的使用标准，以上模板或多或少都遭到了滥用或不合理使用。以下是部分存在的问题以及改进建议：

功能重复

{{Needs testing}}（[需要测试]）和{{Verify}}（[需要验证]），除了“{{Verify}}除在游戏中测试，也可以指查看源代码等方式验证”之外，两者可以认为几乎没有功能和指示范围上的区别。而这点区别大可不必使用不同的模板以及分类进行维护，因为几乎所有的维护模板都可以通过查看源代码（基岩版情况特殊见下文）的方式消除。

类似地，{{Info needed section}}与{{Missing information}}的功能也近乎完全重复。对于{{Stub}}，和以上两个模板以及{{Wip}}相比，也可以认为其功能可完全被替代。

解决方案：将以上模板适当合并删减，并替换链入内容。

分类不当

目前可以认为，大量编者在Java版和基岩版之间只有一个版本是略精通的，然而大部分维护模板的都没有在条目维护分类中将版本区分开，这使得通过分类大量清除以上模板的编者容易因为简单的版本原因就受到极大阻挠，进而甚至会导致愿意批量测试验证信息的编者减少，阻碍Wiki更新进程。

尤其是对于{{Check the code}}这类涉及技术性内容的维护模板，以上问题更为突出。由于基岩版使用C++编写并直接编译为可执行文件，使得其源代码逆向的难度远大于Java版，可以认为大部分通过分类批量检查源代码补充内容的编者以Java版内容为主，然而这些编者同样会受到版本的门槛阻碍。

解决方案：为以上模板添加指示具体版本的功能，并应用到条目维护分类中。

错误使用

以{{When}}模板为例，虽然使用该模板的页面不多，但当前有不少数的用例为在历史章节中指示未确定发生时间的事件。{{History}}模板已经提供了将未知版本的内容集中到分类里的功能，因此此模板的正确使用场合应当为历史章节之外的部分。

再以{{Info needed}}为例，不知出于何种原因，该模板作为行内模板在许多场景下作为正文文字的一部分出现，某种程度上我认为这是不符合书写规范的。

解决方案：取缔以上用法，将模板删除或替换为正确的写法。

最后，以上问题的解决工作大多需要批量重复性地检查链入页面，且部分需求不便使用机器人批量操作，因此建议由拥有巡查豁免者权限的用户完成。

BoredYukolin（留言） 2024年11月25日 (一) 05:35 (UTC)

我明确说明几点，Info needed section是Missing information的章节版本捷径。stub仅用于内容过于短小而不成章节或条目（小作品），不可用于表示缺失特定讯息的完整条目。wip仅用于说明条目正处于编辑焦点中，此几个模板可以说功能几乎不相关且不可更不应替代。反而是应打击部分将stub当Missing information的用法。
再来，“几乎所有的维护模板都可以透过查看源代码”是颇大的误解，本wiki可不是只有测试游戏内特性。更进一步讲，Needs testing及Checkthecode是Verify在游戏特性描述中使用的两种特化。不是所有东西都该翻源代码好解决（本wiki也有过些纯翻源代码没找到或理解错误导致的编辑问题），对于几率、特定定义数值或源代码中的复杂判断条件这种，自然适合翻完源代码解决的就挂Checkthecode。但也有许多可以或是适合直接在游戏中尝试以确认的则该用Needs testing，这尤其是包含非程式码直接结果或bug及基岩版的内容。至于放置模板时不确定能用哪种方法都不太合适甚至非一般游戏内特性则可以直接用更广泛的Verify。
总之，Checkthecode加版本标注与清下When我是支持的，Info needed当句子要素看到能顺手改好看点，其他关于功能重复的部分强烈反对。──  Leo768（Talk｜Contributions） 2024年11月25日 (一) 10:11 (UTC)
对{{Stub}}和{{Info needed section}}的考虑确实有所欠妥，事实上原本想表达的就是“打击将stub当Missing information的用法”。但我仍然认为{{Needs testing}}是冗余的。对于一些源代码中耦合复杂度高的问题是应该阅读源代码还是实际测试解决，想必在编者在实际尝试检查源代码后就会心中有数。而且当前的事实说明，将“需要测试”单独分出一个维护模板并不能起到多少防止“纯翻源代码导致的错误”，一来这种情况本就是少数难以避免，二来仍然会有手里拿着源代码的编者顺手一起清“需要测试”分类中的页面。
BoredYukolin（留言） 2024年11月25日 (一) 11:05 (UTC)
抱歉没有表达清楚，我这边只是想说翻源代码不一定是必要的。该模板细分很大程度上是方便而已——让无法轻易查看源代码的编者能帮忙清Needs testing。而比较有技术力的编者能优先处理标注Check the code的。毕竟并非全部人都能翻能懂源代码。 ──  Leo768（Talk｜Contributions） 2024年11月25日 (一) 12:19 (UTC)
已经为ctc添加标识基岩版功能。 BoredYukolin（留言） 2024年11月28日 (四) 00:12 (UTC)
关于三种verify，我有一个想法：用verify+参数来控制是通用验证还是源码还是实测，这样也可以与既有的版本参数配合。例如{{verify|code=1|je=1}}->“需要验证：JE源码”，{{verify|ingame=1|be=1}}->“需要验证：BE实测”，等等。无参情况就是普通的“需要验证”。--dovisutu（msg丨edits） 2024年11月28日 (四) 08:25 (UTC)
是一个好想法，不过这样似乎有一个小问题：既然检查源代码需要按版本分类，那么统一到一个模板后所有的“需要测试”“需要验证”“需要检查源代码”都需要按版本再分类，如此下来就会有“需要验证/需要检查源代码/基岩版”这种多层分类，是否会显得分类过于繁杂？ BoredYukolin（留言） 2024年11月28日 (四) 09:17 (UTC)
可以归可以，但这么做有必要吗？合并也不会令该模板有更好的用例，但增加的参数复杂性却会使其变得更难用。 ──  Leo768（Talk｜Contributions） 2024年11月28日 (四) 09:38 (UTC)
但是同时少了两个模板的学习需要，对新编者入门来讲其实应该要更方便些。使用的复杂程度相较于三个模板共存时总共的复杂程度也没多大区别。 BoredYukolin（留言） 2024年11月28日 (四) 09:40 (UTC)
要打得更长了，页面源代码变得更难直接读懂了，要考虑的参数更多了。合并模板学习成本更多是上升而非下降，复杂的参数组合据我所知是学习用模板的难点之一。合并其实并非使学三个模板变学一个模板。相反，这使得需使用或查看其一模板时被迫同时学三个模板的组合。不过这也没到很严重，但在可以不改的情况向我倾向于不改，毕竟改还有修正既有的用法及编者的习惯等成本。 ──  Leo768（Talk｜Contributions） 2024年11月28日 (四) 09:58 (UTC)
如即时通讯群组中所言，合并三个模板其实并不是我坚持的要求，我希望的是为这三个模板都添加指示版本的功能，并将分类集中到“需要验证”及其子分类。现在看来，最好的方案是将{{verify}}替换为{{Sandbox/Verify}}中的内容，并将{{needs testing}}和{{ctc}}替换为对{{verify}}的包装。 BoredYukolin（留言） 2024年11月28日 (四) 10:05 (UTC)

代替过时管理员指南的巡查员指南

下列讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为实施。

目前Minecraft Wiki:管理团队中巡查员的申请条件之一是仔细阅读过管理员指南，但文章内容已不符合本站现状。结合本站实际情况和一年有余的巡查经验，本人写了巡查员指南，欲代替原有管理员指南，转正后保护级别应当为半保护。现请大家审阅并提出意见，谢谢。--Wilf233zhMCW（论·功） 2024年11月30日 (六) 01:58 (UTC)

uw相关模板只有巡查员及以上级别用户可以直接使用，建议在指南中简单提及。--AblazeVase69188（留言 | 贡献） 2024年12月1日 (日) 02:54 (UTC)
我简单提及了活用此类警告模板，至于使用人问题应当写在模板文档中，并非本议题主题。 Wilf233zhMCW（论·功） 2024年12月3日 (二) 03:05 (UTC)
 建议：还可以加入向管理员提名巡查豁免者的操作、对待巡查豁免者编辑的态度（据我所知，巡查豁免者的编辑只是不需要再点个巡查而已，还是有可能会被巡查员看一眼的）。--AblazeVase69188（留言 | 贡献） 2024年12月11日 (三) 10:49 (UTC)
对于操作，管理团队每个月月底都会进行讨论，无需写入指南；对于态度，这个我认为不必写进指南，对我而言是否会二次检查取决于很多因素，例如担任时长、历史上和近期犯错误次数情况、编辑的主要内容以及活跃情况等等，写进指南似乎过于复杂了，不如自行积累经验。 Wilf233zhMCW（论·功） 2024年12月11日 (三) 11:56 (UTC)

鉴于长时间无人回复并且没有明显争议，我提议在2025年1月1日起实施。--Wilf233zhMCW（论·功） 2024年12月29日 (日) 08:55 (UTC)

是否建创建基岩版官方附加包的相关页面

如题。基岩版市场的一些附加包是微软授权给一些开发者制作的，如2024年愚人节的毒马铃薯附加包。现在讨论是否要在中文Wiki创建相关页面。

以下是几种可能的方法：

1.不创建。

2.创建相关页面，不为附加包内的特性创建子页面（即所有特性都编写在同一页面，这也是英文Wiki对此采用的方法）。

3.创建相关页面，为附加包内的特性创建子页面（这也是对愚人节特性编写采用的方法）。

Wms987（留言） 2024年11月30日 (六) 11:51 (UTC)

基岩版市场内容不受官方支持（见MCPE-119646），不属于官方内容，因此 反对创建。--AblazeVase69188（留言 | 贡献） 2024年11月30日 (六) 12:18 (UTC)
考虑到Mojira上也有MCPE-187836，该错误回报似乎不足作为依据。 ──  Leo768（Talk｜Contributions） 2024年11月30日 (六) 12:26 (UTC)
这似乎不是个问题，因为我们实际上已经有附加包页面15周年派对用品、和各个失落的传奇等了，所以单就“附加包（或更广泛的市场）能不能建页面”我想答案毫无疑问就是“可以”，否则要推翻可需删不少页面。至于其中特性单开不开页面，我不太觉得会有人愿意去写，故不大可能成立。哪些附加包可以建哪些不行，建议参照en:MCW:N#Marketplace_content。另外若仅细究非官方开发，那我们也已经有神话、MinecraftEdu、15年之旅、MCC x Minecraft 15 周年庆典派对乃至Minecraft编程一小时等等内容了。 ──  Leo768（Talk｜Contributions） 2024年11月30日 (六) 13:07 (UTC)
个人认为可以视辅助程序与编辑器的存废决定而决定，并与本话题所述页面一起作为后续第三方页面加入的标准。同时，鉴于最近wiki开的坑够多了，因此提议 暂缓加入此类页面。 Abigpigeon（论/功) 2024年11月30日 (六) 13:36 (UTC)(最后编辑于2024年11月30日 (六) 14:23 (UTC))
这些东西和辅助程式与编辑器有所不同。辅助程式与编辑器是真的社群自行开发的第三方工具，而这些是在说市场中由官方授权或委托的或具有官方IP许可宣传的第二方（？）内容，不可一概而论。市场也有其他非官方的真正“第三方”内容，是否为其建立页面已是另一个几乎不可能通过的话题。再怎么说我们近期也已经编写很多市场内容页面了，不是现在才说要建。
是说“这两个页面”是指？另外题外话：阁下给的连结似乎有误，建议修正。 ──  Leo768（Talk｜Contributions） 2024年11月30日 (六) 14:03 (UTC)
感谢提醒。个人认为二者都带第三方内容的色彩，而如您所述，基岩版市场内的内容更为接近第二方内容。如果辅助程序与编辑器这样的真正的“第三方内容”能得到保留，那么似乎本话题所述的相关页面也应该得到创建。相反，如果辅助程序与编辑器相关页面被删除，那么本话题所述内容的创建就应该被画上问号。根本上是对于第三方内容的态度问题。Abigpigeon（论/功) 2024年11月30日 (六) 14:23 (UTC)

建议建立Minecraft Wiki读者群聊/频道

如题。在我本人经历与参与的半年多的维基建设与讨论中，发现在因为格式角度/表述等原因出现矛盾时，编者往往会带入读者的视角来说明自己主张的必要性。但问题在于，不管是在事务群或者是茶馆群，甚至于在论坛和社区专页的讨论也少有纯粹的读者参与讨论。固然，一名维基编者同时也可以作为一名维基读者，但在对于维基的熟悉程度与访问维基的目的上，编者和读者有着较大的差异。换句话说，就是在讨论中带入读者视角，实际上并不能完全反映读者看法。而目前维基的官方和半官方讨论渠道，均有其局限性而不利于读者的想法表达。同时，中文Minecraft Wiki所涉及的游戏范围相当广泛，如果能开设读者群聊/频道，广泛采纳读者意见，更有助于建设维基，同时也能招揽一些不同游戏领域的新鲜血液。固然，建立此类群聊/频道可能会引发一些问题，如难以筛选与管理，可能引发的不必要纠纷，但个人认为其还是利大于弊的。

对于这一议题，个人给出以下几个具体建议：

  • 1.先设立一个QQ群/dc频道，观察一个月左右，如果对于维基有建设性作用就保留，没有就解散或者与Minecraft Wiki脱离隶属关系。
  • 2.如果在未来加入群聊的读者增多，可以考虑对qq群进行扩员或增设2群，3群。
  • 3.在群聊成员筛选管理上，可以设置一些中等难度问题（如列举几个可再生物品）作为门槛，平常允许讨论除维基以外的其他内容，但若有需要征求读者意见的问题则优先讨论该问题。用户名称采取[平台名称]+用户在该平台的用户名的形式来进行识别。

--Abigpigeon（论/功) 2024年12月10日 (二) 15:19 (UTC)

说实在，我还没看过开这种群的，又不是wiki粉丝同好群，意见回馈管道一般不会是开群聊的形式。再说读者进来平时是能聊什么，这种群又要怎么吸引人加入。有事征求意见什么的也应交由wiki社群媒体收集。我是认为搞这个不如多多宣传讨论页，提醒读者若发现条目有可改进之处欢迎在讨论页提出等比较有实际意义。P.S.可再生拜托别，我可能会心脏病发。 ──  Leo768（Talk｜Contributions） 2024年12月10日 (二) 15:57 (UTC)
Leo大概确实没看过。个人意见，大陆相对不算不常见？不知道，萌百反正有群，原神那边旅行者酒馆也有群的样子我记得。讨论页毕竟对于境内大环境来说实在是“不好用”（我也很遗憾，Discussion Tools都有了为什么还是会抗拒用讨论页），所以开群聊倒也不算是什么子虚乌有的需求。顺便，3太有既视感了，真的有想讨论的来某茶馆不就是了。--  Lakejason0（论•功） 2024年12月11日 (三) 01:18 (UTC)
 信息 原神旅行者酒馆的读者群实际上已经是游戏交流群了，原神Wiki另有一个编者群（类似茶馆）。对于原神Wiki，大部分来自非活跃编者的建议是通过 BWIKI 评论区收集的。 Silverteal（留言） 2025年1月5日 (日) 02:10 (UTC)（最后编辑于2025年1月5日 (日) 09:09 (UTC)）
在哪里呀？ Yangtianxiao（留言） 2025年1月5日 (日) 09:05 (UTC)
抱歉我可能表达不清，上面的“编者群”指的是原神Wiki的编者群。 Silverteal（留言） 2025年1月5日 (日) 09:08 (UTC)
同意因为wiki当中讨论比较严格。而在群聊当中大家可以集思广益畅所欲言提出一些内容。 Yangtianxiao（留言） 2024年12月29日 (日) 10:56 (UTC)

介于相似议题反对意见较多，加上社群内对群聊是否真正起到作用的怀疑(参见译名群中的讨论情况)，本人宣布 撤回此提案。但是，我仍然建议通过其他合适的渠道加强与读者的交流。Abigpigeon（论/功) 2025年1月19日 (日) 14:34 (UTC)

主题色调

本主题或以下段落文字由 Leo768（Talk｜Contributions）移动自Talk:Minecraft_Wiki/editcopy。

其他大部分语言的主题色调都改成了苍白之园的灰色色调了，我们要不要也改一下？ 120.230.93.131 2024年12月12日 (四) 13:10 (UTC)

我拒绝，白色调太晦气。-- Lxazl5770zh.admin（论 ▪ 功） 2024年12月17日 (二) 15:10 (UTC)

建议删除仅通过结构自然生成的方块的Block distribution模板

如题，例如床、箱子、刷怪笼等。

原因很显然：意义不明。这个模板在这种情况下不能提供任何有用的信息。 IcenPhantom（留言） 2024年12月13日 (五) 08:56 (UTC)

 中立。这些图对玩家来说一定程度上很有趣，虽然它们确实不能提供什么有用的信息。关键问题可能是如何认定这些信息是否有用。--AblazeVase69188（留言 | 贡献） 2024年12月13日 (五) 09:11 (UTC)

Template:Navbox Minecraft (franchise)同步en格式

标题中的链接、样式代码、模板、魔术字或解析器函数已被移除。原标题：Template:Navbox Minecraft (franchise)同步en格式

为方便日后处理周边和联动信息，Template:Navbox Minecraft (franchise)应同步en格式。（本人已在模板讨论页提出，至今没有回应。） Clayblockunova（留言） 2024年12月17日 (二) 07:45 (UTC)

建议在冬季时默认冬季主题皮肤

本主题将在符合存档条件后存档至此，在此之前请在Minecraft Wiki:社区专页 § 建议在冬季时默认冬季主题皮肤讨论。

介绍重定向页面？

需不需要添加一个介绍重定向页面的页面？--Mudongly(T) 2024年12月19日 (四) 12:09 (UTC)

您可以参阅mw:Help:Redirects。--dovisutu（msg丨edits） 2024年12月19日 (四) 12:37 (UTC)
可在Special:重定向列表查看本站的所有重定向页面。--ultim_0 [talk][work] 2024年12月19日 (四) 13:09 (UTC)
 反对重定向是基本的格式，MediaWiki使用者都应该知道，我认为无需单独添加帮助，并且2022款源代码编辑器和可视化编辑器都内建了相关帮助 佩奇君（留言） 2024年12月22日 (日) 14:43 (UTC)

建议增加一个“退出确认”小工具

如题，刚才不小心点到右上角的“退出”了，发现居然没有二次确认的过程，故建议添加。 ultim_0 [talk][work] 2024年12月21日 (六) 15:43 (UTC)

连结支援：wzh:MediaWiki:Gadget-confirm-logout.js。不过我感觉这东西可以有需要再自己写到common.js就好 ──  Leo768（Talk｜Contributions） 2024年12月21日 (六) 15:56 (UTC)
让群友帮copy了一份代码，但是在用小号测试（User:Ultim 1/common.js）的时候发现并不能达到预期效果（点了弹窗中的“确认”，但并没有退出），但自己又不太懂JavaScript的机制，推测是缺少依赖项导致，还是希望能够作为小工具引入。--ultim_0 [talk][work] 2024年12月22日 (日) 11:00 (UTC)
可尝试敝人修正的版本：User:Leo768/javascript/confirmLogout.js。 ──  Leo768（Talk｜Contributions） 2024年12月22日 (日) 11:39 (UTC)

关于NBT在Wiki源代码中的低可读

我在编辑猪灵的实体格式时，源代码难以理解：

=== 实体数据 === {{el|je}}： {{main|实体数据格式}} 猪灵有与之相联系的包含许多该[[生物]]属性的存档数据。 {{/ED}} {{el|be}}： {{see also|基岩版存档格式/实体格式|基岩版存档格式/实体格式/组件}}

ED, el等模板无法理解其含义

实体独有的NBT在源代码中无法寻找到

对于NBT，应当使用更加简洁，易于理解的当时在wikitext源代码表达，或添加他们的教程到编辑手册中

佩奇君（留言） 2024年12月22日 (日) 11:20 (UTC)

ED是指实体数据（Entity Data），el是指版本链接（Edition Link）。 Wilf233zhMCW（论·功） 2024年12月22日 (日) 11:22 (UTC)
那么应该将他们加入格式手册中，目前格式手册的内容不包含NBT，模板，实体数据等，它们都应该被加入 佩奇君（留言） 2024年12月22日 (日) 11:32 (UTC)
见Minecraft Wiki:格式指导/NBT及JSON。 Wilf233zhMCW（论·功） 2024年12月22日 (日) 11:38 (UTC)
一般而言，这种将内容嵌入至其他页面的做法，皆需要提供编辑连结供不熟悉的编者能查看或编辑源代码（例如LoadPage、Navbox等）。但NBT相关（包含Nbt inherit、/BE、/ED等）却没有此设计，可考虑改进。 ──  Leo768（Talk｜Contributions） 2024年12月22日 (日) 12:37 (UTC)
 我同意这很有帮助 佩奇君（留言） 2024年12月22日 (日) 13:28 (UTC)

愚人节特性条目格式规范

近期拆分愚人节特性条目的工作已经开始，有不少编者已经开始热情高涨地大量编写相关页面。然而，愚人节特性条目的格式规范涉及到许多问题，其中仍有一些亟待解决，故在此新开一个议题以便讨论。

正在编写中的愚人节玩笑特性格式指导页面见此。

目前尚未解决的问题

  • {{LootChest}}仍不支持生成愚人节版本的战利品表表格，且手写表格工作量极大。
    • 等待有能力的编者改写相关模块中。
  • 部分场景下的本地化过程中对“保留英文原文”和“使用中文翻译”的取舍以及排版。
    • 重灾区：进度表格。以下是我个人对本问题的看法：
      • 进度表格属于“应当遵循游戏内显示内容”的部分，然而其中不乏一些长难句子，因此适当地翻译又是必要的。因此应当考虑的是英文和中文谁作主体。我认为较好的方案是在名称和游戏内描述两列都用英文原文写大字，用小字写出相应的中文大意，这样能够体现出与其他有标准翻译的进度的不同。
  • 对于一些针对常规特性小规模更改而产生的愚人节版本特性，应当如何处理。
    • 既然已经说是小规模，就说明单写条目不合适了，但是并入常规特性页面似乎更显然是不妥的。大部分此类特性只需要写入涉及到的有独立条目的特性对应的条目就够了，但是也有小部分极端情况是完全只涉及常规特性的更改，这类特性可能会就此无法在版本页面之外的地方出现。

BoredYukolin（留言） 2024年12月22日 (日) 14:31 (UTC)

个人认为一些几乎没有实际用途的特性（例如en:Longer String）可以并入一个页面（例如愚人节玩笑特性/23w13a_or_b），每个特性单开一个段落进行叙述。Afulai2333（论·功） 2024年12月22日 (日) 15:10 (UTC)
这本质上和被迫留在版本页没有多大区别。而且这样的页面基本全部是和版本页重复的内容，根据MCW:关注度就不应该创建。此外，Longer String作为一个独立的物品是需要条目的。 BoredYukolin（留言） 2024年12月23日 (一) 14:22 (UTC)
个人认为完全只涉及常规特性的更改直接写入版本页就行了，因为这类特性的数量很少，而且大多数关注度也不高。 Villager-bloc-h 2024年12月23日 (一) 14:55 (UTC)

需要建立模板指引

模板真的需要单独建立指引，否则新人根本不会用佩奇君（留言） 2024年12月23日 (一) 08:13 (UTC)

每个模版都有独立、对应的模版页面。例如{{message box}}，里面详细的说明了各项参数的作用和使用方法，仔细阅读就能知道如何使用。另外，多编写 Wiki 也是一种快速有效的了解 Wikitext 的方式。--Hopə [ Talk | Cons ] 2024年12月23日 (一) 11:37 (UTC)
那我也得知道有哪些模板和模板的名字吧 佩奇君-查•论•不许编 2024年12月23日 (一) 15:02 (UTC)
所有页面，请。--ultim_0 [talk][work] 2024年12月23日 (一) 15:57 (UTC)
您可以加入中文Minecraft Wiki事务群寻求帮助。 Abigpigeon（论/功) 2024年12月23日 (一) 14:58 (UTC)

wiki内似乎有自定义多方块结构渲染模块，但我不知道如何使用

希望给出相应模板／模块以及文档佩奇君-查•论•不许编 2024年12月24日 (二) 05:25 (UTC)

您可能在找：Template:Block structure renderer或Template:Layered blueprint。--dovisutu（msg丨edits） 2024年12月24日 (二) 05:29 (UTC)

对于Anonymous xxxx-xxx用户，是否违反用户名方针

  • 我认为，这种用户名暗示并非真人（根据封禁记录User:用户信息已删除和方针判断），所以我认为这类用户名违反方针，应该封禁
  • 很明显，这类用户属于过长用户名，应该封禁
  • 附：部分名单：

Anonymous 778596c4-a8bd-4f77-8c95-c91ff58d7255 佩奇君-查•论•不许编 2024年12月24日 (二) 16:23 (UTC)

这些是被强制改名的用户，原因可能是用户名违反方针或已注销。--ultim_0 [talk][work] 2024年12月24日 (二) 16:30 (UTC)（最后编辑于2024年12月24日 (二) 16:31 (UTC)）
不用着急，这个用户很可能已经无法使用这个账号做出编辑，等他真的做出编辑再封都不迟。--AblazeVase69188（留言 | 贡献） 2024年12月25日 (三) 00:55 (UTC)

用户页面图片能否使用非站内链接

img 标签似乎不会生效（当然也可能是写法问题） 但是如果直接在模板内填写链接，最终展示的是 [[File:https://xxxx/raw/userprofile.webp]] 的形式 所以有没有什么可以链接到站外的方法（模板或html代码均可，如果没有办法就算了 ） --薄奚梦灵 那张尾页的书签 那天带泪的笑颜 依然勇敢 依然耀眼（留言） 2024年12月25日 (三) 05:28 (UTC)

你可以把同样的图片在本站再上传一份。CSS里的图片可以直接使用站外的，但是用户页应该不行。 Wilf233zhMCW（论·功） 2024年12月25日 (三) 05:52 (UTC)
 反对MCW已经有了自己的托管系统，完全无需外链，应当在本站上传。 佩奇君-查•论•不许编 2024年12月25日 (三) 06:17 (UTC)
正在担心这种做法是否会浪费站内资源.jpg --薄奚梦灵 那张尾页的书签 那天带泪的笑颜 依然勇敢 依然耀眼（留言） 2024年12月25日 (三) 12:16 (UTC)
如果你实在想要用站外，可以用这种格式，但是不推荐:
<div style="width:图片宽;height:图片高;float:left(左)或right(右);background-image:url('图片地址')"></div>
佩奇君-查•论•不许编 2024年12月25日 (三) 12:46 (UTC)
上传时附带用户图像分类即可。（edited）--Rosa hybrida659（讨论或贡献） 2024年12月28日 (六) 03:27 (UTC)

Minecraft 树莓派版是否该加入终止支持列表？

本主题或以下段落文字移动自Minecraft Wiki:论坛/Minecraft 树莓派版是否该加入终止支持列表？。

最近，我发现 Minecraft 树莓派版已经很久没有更新了，我不知道官方是否正在维护这个版本。所以希望能够将其添加进终止支持列表。

AkarinLiu（留言） 2024年12月27日 (五) 06:51 (UTC)

请问您指的是那个终止支持列表？如果您指的是Template:Navbox Minecraft，那么该版本实际上已经加到“终止支持”一栏之中了。Abigpigeon（论/功) 2024年12月27日 (五) 08:23 (UTC)
我想停止支持也在情理之中，毕竟现在的树莓派 5B 可以运行 Minecraft 了。 AkarinLiu（留言） 2024年12月27日 (五) 08:54 (UTC)

教程界面是否有必要添加历史章节？

目前一些教程界面拥有历史章节(如Tutorial:飞行器和Minecraft Wiki:沙盒/教程/更新抑制)，但这些历史章节所述内容大多在该页面其他章节中已经收录，似乎存留意义不大。同时，此类章节维护难度较大，添加内容的标准也很难统一。鉴于教程已经是天坑了，且格式指导中并无有关规定，因此个人建议删除此类章节，后续除非特殊情况也不再添加。 Abigpigeon（论/功) 2024年12月28日 (六) 10:20 (UTC)

 补充在Special:diff/794200、Special:diff/794201和Special:diff/794202中，该问题曾经也进行过讨论，但如上所述，历史章节的内容已经于其他章节中得到收录，且集合在一个章节的意义也不大。 Abigpigeon（论/功) 2024年12月28日 (六) 10:24 (UTC)
我认为没有必要做统一的规定，各个教程之间有很大区别，应该具体情况具体分析，部分教程收录历史是非常有必要的。 Wilf233zhMCW（论·功） 2024年12月29日 (日) 09:17 (UTC)

命令示例板块需要统一

大部分命令页面都有示例板块，可是示例的命令栏给予的命令格式不统一。

如命令/effect和命令/damage，示例中的命令带斜杠。又如命令/clear和命令/kill，命令没有斜杠。171.213.188.38 2024年12月29日 (日) 10:27 (UTC)

个人认为有没有斜杠都差不多--Luoboju0 2025年1月18日 (六) 14:51 (UTC)
没有必要统一，读者能够理解、每段落的格式相同即可。如果非要统一，那么我更支持斜杠命令。 TeaSummer（Q&A|C） 2025年1月18日 (六) 14:53 (UTC)
取自“https://zh.minecraft.wiki/w/Minecraft_Wiki:社区专页/存档13?oldid=1048144”