社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解，Minecraft Wiki在共识系统上运作而不是投票决定，清楚地阐述自己的理由比简单地支持争论的一方更有效。
Minecraft Wiki不是客户服务中心！游戏问题请移步Minecraft帮助中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至无意义话题处。
语言
- 快捷方式
- MCW:CP
- MCW:PORTAL
- MCW:社区
- 最新Wiki新闻
- 2023年8月31日 - 中文Minecraft Wiki确定将迁移至Weird Gloop（议题原文）。
- 2023年7月4日 - 英文Minecraft Wiki公开发布了关于Minecraft Wiki是否要从Fandom迁移至别的站点的讨论（链接）。
- 2023年6月1日 - 新的巡查员Siiftun1857上任。
- 2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升级至1.39。
- 2023年1月31日 - 新的管理员Anterdc99上任。
| # | 话题 | 发言条数 | 参与人数 | 发起者 | 最后发言者 | 最后发言时间（UTC） |
|---|
关于成文的译名使用指导
下列讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 同意建立。
长久以来，本Wiki在如何使用译名，以及如何处理译名变动的问题上，是有一些习惯的。我认为，如果这种习惯能够以文本的形式固定下来，应该可以使译名管理更加规范化。
所以，这次我向社区提出将这些习惯性、不成文的做法，以格式指导补充条款（即“译名使用指导”）的形式，形成正式的指导性文本。
此次提交社区讨论的文本的大多数内容是对既有习惯性做法的描述，可以在Minecraft Wiki:沙盒/Minecraft Wiki:格式指导/译名使用指导处查阅。恳请各位对此文本提建议。
另外，还有一个问题需要提交社区讨论：内容页面历史段落中，译名不同步更改时应当如何处理？（之前的讨论见：Talk:末地水晶#关于末影水晶和末地水晶这两个译名）-- 
Anterdc99（论·功） 2022年4月20日 (三) 10:30 (UTC)
- 建议添加BE相关的译名事项，如BE名称没有同步JE的情况下如何使用译名（JE的风袭丘陵和BE的峭壁）、什么情况不可使用基翻、什么情况只能使用基翻原文（如选项名称）。--XiaoXin666（T·C） 2022年4月23日 (六) 05:02 (UTC)
“漏洞”章节的必要
下列讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 同意删除。
如题，“漏洞”章节只有一句话和一个前往Mojira的链接，内容单薄，且没有什么用途。
据考古，这个章节最早在2013年3月出现。当时是一个用JS加载的列表。在2013年五月左右改为了目前的一个链接形式。据en:Template:Issue list，这是因为Jira的API出现了一些错误。在这之后，漏洞章节再也没有得到更改。
如今，漏洞章节是否还有存在的必要？-- Dianliang233 T•C 
2022年4月21日 (四) 01:03 (UTC)
- 建议删除，这个段落在各种页面中千篇一律，除了提示前往漏洞追踪器之外一无是处，大有凑数的嫌疑。--ultim_0 ( USER | TALK | WORK ) 2022年4月21日 (四) 01:24 (UTC)
- 同意，
{{issue list}}模板导致分类:本地化模块需更新这个分类里的条目迟迟无法消除。--Lxazl5770zh.admin（论 ▪ 功） 2022年4月23日 (六) 03:16 (UTC) - 同意删除，凑数段落，还给编辑添加麻烦。--KaplanSteve T/C 2022年4月23日 (六) 03:19 (UTC)
- 意见，可以改为mojira的固定链接以消除本地化模块更新的问题。当然我也支持完全删除段落。--Snow dash（论 & 功） 2022年4月23日 (六) 03:22 (UTC)
- 同意删除只含有issue list的“漏洞”章节。--
Anterdc99（论·功） 2022年4月23日 (六) 04:35 (UTC) - 除了部分因为不受支持的游戏要素需要标注Mojira不受理之外，其余的删除也可。-- Lakejason0（论•功） 2022年4月23日 (六) 04:46 (UTC)
- 同样 支持。--McplayerFS（讨论 | 贡献） 2022年4月23日 (六) 15:32 (UTC)
- 但，它的作用就是弄出一个指向相关内容的漏洞列表的链接，以及说明与此内容相关的漏洞会被怎么处理。不受支持的内容会在这一栏里写明不接受漏洞报告，而调试棒等少数特例会有额外说明。如果要全部删除，则需要给“不接受漏洞报告”和“漏洞报告特例”之类的说明找个位置；如果只把这些东西的“漏洞”章节留下来，只能说一致性喂了狗了。而且en那边还留着，虽然en的意见在这里不适用，我建议各位去那边问一下他们是怎么看待的。（如果他们也觉得没必要那我没啥想说的）——IcyPhantom 讨论I贡献 2022年4月24日 (日) 14:21 (UTC)
- 支持移除只含有
{{issue list}}模板的“漏洞”一段，其他有特别说明的 建议保留，我也暂时想不到其他适合放置这些特别说明的段落。虽然有用户认为部分保留该段落可能会破坏页面一致性，但是我认为这与“你知道吗”一段的有无是一个道理，这类内容应该是有必要才加入到页面中去，没有就不加。--AblazeVase69188（讨论 | 贡献） 2022年4月29日 (五) 13:02 (UTC)（最后编辑于2022年5月1日 (日) 07:59 (UTC)） - 注意到此话题被搁置了。大家都支持删除的只含有
{{issue list}}模板的“漏洞”段落，如果开始删的话，应该如何删除呢？--KaplanSteve T/C 2022年5月1日 (日) 07:43 (UTC)- 大概是把所有仅有
{{issue list}}模板的“漏洞”一段移除，余下有特别说明的就不移除。这类操作应该是需要机器人的。--AblazeVase69188（讨论 | 贡献） 2022年5月1日 (日) 07:59 (UTC)
- 大概是把所有仅有
Sound table
Template:Sound table→User:烨凌/Sandbox/Sound table+模块:Sound table--烨凌（讨论） 2022年4月22日 (五) 18:51 (UTC)
- 请具体说明此次更改的内容及益处，不要通过抽象的方程式让别人理解您的意图，否则此话题将被存档至MCW:BT。另外，请及时按照讨论页方针整改您的签名。--葉月 桐§ 2022年4月22日 (五) 20:19 (UTC)
- 本来的音效模板又不是不能用--Lxazl5770zh.admin（论 ▪ 功） 2022年4月23日 (六) 03:07 (UTC)
- 支持重构，这个模板的代码实在辣眼睛，但请多沟通需求与设计，社区达成共识后再正式应用。--Snow dash（论 & 功） 2022年4月23日 (六) 04:46 (UTC)
- 重构是有必要的，但请先遵守社区规则，取得大家的一致意见后操作。-- Lakejason0（论•功） 2022年4月23日 (六) 04:47 (UTC)
“Slot”译名标准化
本主题或以下段落文字移动自MCW:管理员告示板。
如题，现在Minecraft Wiki中对于“Slot”的译名有两种，即“栏位”与“槽位”，各条目使用混乱，需要统一修改。
另外，“栏位”的使用频率比译名标准化中的“槽位”更高。（搜索“栏位”大约得到900项结果，“槽位”则是400项）--Yzy32767（讨论） 2022年5月1日 (日) 02:18 (UTC)
- 译名标准化列表和游戏内都写的是“槽位”。——IcyPhantom 讨论I贡献 2022年5月1日 (日) 03:26 (UTC)
- 记得之前讨论过，应该使用槽位。而fandom搜索功能比较垃圾，因为“栏”字和“位”字使用的比较多，自然搜索结果比较多。使用b站镜像精确搜索，使用槽位的页面约有300个，而使用栏位的页面不足一百个。-2022年5月1日 (日) 03:59 (UTC)–该未签名留言由Chixvv（讨论 • 贡献）在2022年5月1日 (日) 03:59 (UTC) 添加。请在您的回复后面加上 ~~~~
- 这个可以使用机器人处理，请移步MCW:BOTR。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月1日 (日) 10:32 (UTC)
未命名话题
额...我感觉主页放大过的"Minecraft Wiki" 的logo不清晰 请问可不可以给我合适的像素比（比如长x宽）。 这样我可以很快就清晰化完毕。谢谢 低分辨率的logo Batele Jackson（讨论） 2022年5月6日 (五) 22:05 (UTC)
“X制物品”与“X质物品”之统一
下列有关用词一致性的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为将相关表述统一为“X质”。
目前wiki上X制/质物品和工具的表述较为不统一，交流群内的多次讨论结果仍有分歧，因此有必要在社区专页进行进一步的讨论。
个人倾向于选择X制，在搜索引擎上搜索木制和木质，木制的搜索结果多为木头做成的物品，木质的搜索结果多形容木头本身的特性；石制和石质的结果类似。且搜索“木质品”或重定向到“木制品”。
当然，X制/质也可能需要根据具体搭配做出区分。--Ff98sha（讨论） 2022年5月7日 (六) 05:00 (UTC)
- 留言：使用“o工具/装备”（如木工具、皮革装备）可好？--ultim_0 ( USER | TALK | WORK ) 2022年5月7日 (六) 06:22 (UTC)
- 其实这种表述也很不错，不过对品质和盔甲材料页面中×质的表述应如何处理呢？特别是其中的表格只有“×质”的文字，我觉得改为诸如只有“皮革”“铁”的文字貌似不太恰当。--AblazeVase69188（讨论 | 贡献） 2022年5月7日 (六) 09:32 (UTC)
- 盔甲材料#材料中表格第一列内容多是“某某质”，唯独锁链和海龟壳没有“质”，
搞特殊是吧。而且，第一列表头是“材料名”，并不存在一种材料叫“铁质”，删去质很合理。而对于品质，即使不改Tiers的翻译，由于品质里说“品质（Tiers）指的是工具和武器不同的等级和’’’材料’’’”，且材料与“品质”是一一对应关系，品质#概述中的描述删去质也没有任何问题，即“目前游戏里有6种品质：木、石、铁、钻石、金和下界合金”。其他多数涉及质的页面，比如方块的挖掘时间表，都可以采取同样手段规避。当然这是退而求其次的办法，规避了“制”“质”争议，我 更倾向于采取清秋的建议（见下引文）。--Mamaruo（讨论） 2022年5月10日 (二) 05:18 (UTC)
- 盔甲材料#材料中表格第一列内容多是“某某质”，唯独锁链和海龟壳没有“质”，
- 其实这种表述也很不错，不过对品质和盔甲材料页面中×质的表述应如何处理呢？特别是其中的表格只有“×质”的文字，我觉得改为诸如只有“皮革”“铁”的文字貌似不太恰当。--AblazeVase69188（讨论 | 贡献） 2022年5月7日 (六) 09:32 (UTC)
- 品质和盔甲材料中均使用了×质的表述，我个人 更倾向于使用×质的表述。我认为×制表示是用什么材料合成的，不过我实际上不太清楚Wiki现使用的×质的意思。--AblazeVase69188（讨论 | 贡献） 2022年5月7日 (六) 09:27 (UTC)
- 建议：盔甲讲材料，用“制”；工具讲品质，用“质”。传入神经元（权限|讨论|贡献|日志) 2022年5月7日 (六) 10:05 (UTC)
- 我个人同样 更倾向于使用×质的表述。--McplayerFS（讨论 | 贡献） 2022年5月8日 (日) 05:35 (UTC)
- 留言：我查阅了说文解字。不了解维基规则，就不放书的链接了。制：裁也。从 刀、从 未。未，物成，有滋味，可裁斷。一曰止也。𠝁，古文制如此。质：以物相贅。从貝，从斦。闕。由此得知，质没有制造的意思，材质的意思是现代引申的，而制本意的制造是合适的。相关讨论CFPAOrg/Minecraft-Mod-Language-Package#1961。--Zhang anzhi（讨论） 2022年5月8日 (日) 12:02 (UTC)
- 留言：基于一致性原则，应当统一使用×质这种说法，原因：
- 描述不同对象用语的一致性：应统一使用“×制”或“×质”的说法，不宜将此处用词按类别分开讨论。
- 词性一致性：除“制”或“质”字外，其余部分均为名词形式。在《现代汉语词典》中，此处涉及的“制作”“制造”等词，“制”均作动词使用。此处涉及的“质地”一词中，“质”作名词使用。
- 另外，如使用“×制”这种说法，由于其动词性质，加上词组本身不包含主语的情况，有产生歧义的可能性。-- Anterdc99（论·功） 2022年5月8日 (日) 12:19 (UTC)（最后编辑于2022年5月8日 (日) 12:27 (UTC)）
- 注意，两者在代码层面上是不同的概念，合并会使概念混淆。比起讨论这玩意我觉得应该先规范下那个页面的用语：为什么“盔甲材料”的定义是“材质”？“盔甲材料品质”是什么意思？盔甲材料就是盔甲材料，不是品质也不是材质。顺带一提品质之所以叫品质是因为Mojang在混淆映射表里那么写了，有些非官方映射表写的是“工具材料”。——IcyPhantom 讨论I贡献 2022年5月8日 (日) 15:02 (UTC)（最后编辑于2022年5月8日 (日) 15:14 (UTC)）
- CFPA那边的规定是使用制或不写，我这边对用哪个字没有意见，但最好统一起来。——IcyPhantom 讨论I贡献 2022年5月8日 (日) 15:02 (UTC)
- 群内是讨论过的，我的观点依然是“无正确解”，两个用法都存在，而且似乎没人纠错。完全从现代汉语去解释（用文言语料解释现代汉语我觉得参考价值有待讨论），那我们有“木制品”这个短语（怎么断我不知道，制品似乎也是个词），但同样的名词也可以修饰名词，所以木制工具还是木质工具似乎都没有语法上的问题。群内讨论还有一个有意思的现象，就是一些人觉得“木制工具”“铁制工具”，但又“下界合金质工具”。我依然认为这是由于存在木制品这样的固有短语导致的，而这个现象的结果就是，不是固有短语用“制”不符合部分人的语感。我真的没有什么特别好的意见，统一就行，既然上面已经给出了一个mod项目的决定，那么仿照先人决定也未尝不可。另外，如要使用“制”这个字，请确认转换表是否可以工作（表制作用“製”）。-- Lakejason0（论•功） 2022年5月8日 (日) 15:16 (UTC)
- 改表时注意两个变体部分材料的译名不统一，需要分别写规则。-- Lakejason0（论•功） 2022年5月8日 (日) 15:19 (UTC)（最后编辑于2022年5月8日 (日) 15:20 (UTC)）
- 改表时注意两个变体部分材料的译名不统一，需要分别写规则。--
- 另外，原版语言文件中存在两处使用x质的地方，分别是字幕“铁质盔甲：铿锵”[1]，进度描述“用金质物品吸引猪灵”[2]，应当一并更改。
- 铁质 - 百度搜索丨铁质 - Google 搜索
- 铁制 - 百度搜索丨铁制 - Google 搜索
- 一些观点：
我昨晚考虑了很长时间，也查了一下原版wiki使用x质的地方，x质基本可以说有以下三种用途：
- 形容工具的材料，统共来说有抽象和具体两种语境用法，抽象指的是根据某些工具的用料统一而将它们归摄于x质之下：木头做的就是木质，石头做的就是石质；而具体指的是1.12的木质压力板这种，然而这两者其实只是在语境上有区分，语义上都是第一种，即用料都是x。
- 用于形容某类方块，比如木质方块、石质方块等，这个基本能够和第一点统一：x质工具是用x质方块制作而成的。
- 品质也用到了x质，先不谈tiers翻译为品质这个是有多牛马，某某工具的品质是x质，这是在说它的品质是x品质吗？可是x质好歹还能让人望文生义为制作用料是x，怎么可能会有人理解为x品质？若tiers翻译成品级/品阶，后续顺势翻译为木级/阶，甚至为了简洁只保留“木”一个字，那不是更好让人理解？凡是wood通通翻译为木质，语境不分情况，这压根不是翻译，那是抄字典。
我不知道MC百科那边内部是有什么意见，但是对于我们这边，我个人的观点是：
- 1.12.2 除了木质/石质压力板外，其他的x质均需改为x或是x制；而在方块类别上采用x类。
- 1.12.2版本以上，不得保留x质。
- 品质/挖掘等级只能保留x级/x，不得使用x质。
- 质形容的是材料的性能，不应理解成用料，但“x质”表示的是材料本身的特性，也确实不该用来表达品质。 支持您后三条观点。传入神经元（权限|讨论|贡献|日志) 2022年5月9日 (一) 01:30 (UTC)
- 插一句，关于tier的翻译，它实际上就是“等级”，“品级”和“品阶”在汉语语境下都有特殊的含义，不能单纯地表达为“等级”，现在翻译成品质是暂时最好的结果；如果要考虑改成X制，还有顺带考虑下tier的翻译问题。至于游戏里的tier，它不仅仅表示工具等级，还表示了村民的交易等级，换句话说它还是“等级”，只是不是我们通常认为的经验等级。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月9日 (一) 02:02 (UTC)
- 对上面给出的清秋的说法，我表达一下观点：
- x质的三种用途：其中前两种没有什么问题，描述也基本符合事实。而第三点，抛开品质页面中的用词不谈（虽然此页面本身问题也比较大），以读者视角（或者说不熟悉wiki或不熟悉游戏的读者）来看，正常的理解路径应当是看到此处用字之后，再去扩展此字所代表的含义。由于不同读者对此会有不同理解，“质”也不一定是指“品质”。事实上，包含“质”字并可合理用于此处的词语还有很多，例如“质感”“质地”等，因此，局限于“品质”这一种解释而否定在短语中使用“质”字的可能性是不合理的。
- “根本没有x质这一说法”：在此引述中并没有其他内容来印证这句话。关于为什么没有“x质”的说法，需要给出明确的证据证明，不然这可被认为是主观臆断的结果。
- 最终用词的三点做法：很明显，这里引用的三点做法是针对语言文件中的用词而作出的。经查阅，目前原版简中语言文件中，此类型的表述中使用的均是“质”，而“制”完全没有出现。需要明确的是，根据话题提出者的描述，此话题涉及的是wiki内容页面上的表达问题，并不涉及语言文件。而语言文件中的相关内容又以单独表示某个具体物品为主，故这三点做法不适用于原始议题。
- 另外，关于是否为了避免争议而去除这个字，我认为，在表格以及专门描述此类内容的页面上，去除这个字是合理的，也是可操作的。但对散布于各页面的相关表述而言，此字不能省略。很明显，“木工具”或“木制/质工具”出现在某一句话当中，明显是“木制/质工具”要更顺口。
- 对于“制”“质”这两个字本身的区别，两个字都体现了由原材料制作为成品的过程。“制”代表制作，表示了物品由什么原材料制成，是强调过程；而“质”代表质地，表示了成品具有怎样的属性，是强调结果。因此，在短语前后内容均为名词的情况下，“质”这个表示结果的字，就能与短语中前后内容拥有相同的词性，这也正是我之前所提出的。
- 以上。-- Anterdc99（论·功） 2022年5月10日 (二) 07:38 (UTC)（最后编辑于2022年5月10日 (二) 07:49 (UTC)）
- 对上面给出的清秋的说法，我表达一下观点：
- 语言文件的做法不一定不适用于wiki，还得讨论。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 08:48 (UTC)
- 回应：Wiki的作用是描述游戏，用语理应和游戏中一样——尽管现在游戏内的X质已经非常少了。--Mamaruo（讨论） 2022年5月10日 (二) 09:53 (UTC)
- 回复：正如我在上面提到的，如果真要按照游戏文本，那就只可能用“质”，因为“质”还有几处使用，而“制”则没有被使用。-- Anterdc99（论·功） 2022年5月10日 (二) 10:03 (UTC)
- 回应：怪我没说清楚，我观点见上方发言“另外，原版语言文件……应当一并更改。”--Mamaruo（讨论） 2022年5月10日 (二) 10:11 (UTC)
- 回复：
- 既然在原版语言文件里已经统一用了“质”，说明之前翻译相关内容的译者是有意识统一这方面的用词的。也就是说，可能之前在这方面已有共识或者标准，只是我们不清楚确切的内容。
- 与出版物或学术刊物相比，搜索引擎得出的结果会相对不可靠。也就是说，如果有相应的出版物或学术刊物，那么这些来源中的内容应当优先考虑，而不是仅凭搜索结果推定。
- “制”与“质”之争本质上是用语习惯问题，没有对错之分（见上方Lakejason0的留言），只是谁能给出更合适的理由来论证某种用法更好的问题。明显地，除了从搜索结果出发论证“制”更好外，“制”支持者并没有从更高优先度来源的角度论证这个问题（除上面用《说文解字》论证的，但《说文解字》不适用于使用现代汉语的本wiki）。-- Anterdc99（论·功） 2022年5月10日 (二) 10:48 (UTC)（最后编辑于2022年5月10日 (二) 10:51 (UTC)）
- 回复：
- 回应：怪我没说清楚，我观点见上方发言“另外，原版语言文件……应当一并更改。”--Mamaruo（讨论） 2022年5月10日 (二) 10:11 (UTC)
- 回复：正如我在上面提到的，如果真要按照游戏文本，那就只可能用“质”，因为“质”还有几处使用，而“制”则没有被使用。--
- 回应：Wiki的作用是描述游戏，用语理应和游戏中一样——尽管现在游戏内的X质已经非常少了。--Mamaruo（讨论） 2022年5月10日 (二) 09:53 (UTC)
- 语言文件的做法不一定不适用于wiki，还得讨论。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 08:48 (UTC)
┌──────────────────────────┘
现代汉语词典中“质”一个义项是“物质：流～|铁～的器具”，看来有这个说法，而且没有不好的理由。所以 别统一了，随便用吧。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 12:51 (UTC)
- 留言：查阅了更多的词典，摘录如下：
- 《新华字典》第12版 ①本体，本性：物~|流~|铁~|实~。
- 《新华词典》第4版 ③质料，构成事物的材料。铁~|流~。
- 《现代汉语学习词典》③物质；质地：杂~|流~|食物木~的家具。
- 《新时代汉英大词典》3 matter;substance;material丨a kettle made of aluminium;analuminium kettle 铝~壶丨iron utensils 铁~器皿→流~；木~；杂~ --Mamaruo（讨论） 2022年5月10日 (二) 17:05 (UTC)
回复：我的意见是，使用《说文解字》找到两个字的定义，支持“质”的话，需要找到变迁出来“质”的支持者想要的“质”的意思的有关论证，也就是为什么不适用于现代汉语的Wiki，这两者之间一定是有可查证的历史变迁记录，否则凭借“个人经验”的意思理解都是废话。--Zhang anzhi（讨论） 2022年5月10日 (二) 16:01 (UTC)
根据上述意见，拟将“X制”和“X质”统一为“X质”。如仍有疑问，请在一天内提出。--Ff98sha（讨论） 2022年5月12日 (四) 08:36 (UTC)
粒子问题
发现很多提及某个粒子的文章都没有写粒子名称，请大家注意修改。20.205.111.253 2022年5月7日 (六) 05:05 (UTC)
剩余漏洞章节的处理
下列有关剩余漏洞章节处理方法的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 移除段落，特殊页面参照下方意见处理，附加信息为：“PC Gamer演示版”——更名为“已知问题”；“语言”——与“你知道吗”合并；其他——移除段落。
虽然目前机器人已批量删除只含有{{issue list}}模板的“漏洞”章节，后期也手动移除了一些只含有漏洞报告提示的“漏洞”章节。但此段落在一些页面中仍有遗存，由于在原话题讨论时尚不掌握其具体内容，故对这些页面的处理方式的讨论被暂时搁置。
现已将这些页面列出以供讨论。这些页面可分为以下两类：
- Java版远古版本页面：描述了这些版本中会出现的漏洞。
- 其他（PC Gamer演示版和语言）
目前已经将这些页面中的漏洞章节全部抄录到一起，以供参考。由于文本过长，故不直接放置在此处，可进入User:Anterdc99/Archives/漏洞查看。
经过在交流群中与Lxazl5770的初步讨论，对Java版远古版本页面，Lxazl5770提出了2种处理方法：
- 直接移除段落，不保留任何信息。
- 将这些段落合并至统一位置。
“PC Gamer演示版”和“语言”由于其漏洞章节内容的特殊性，需要另外讨论。
我认为，Java版远古版本页面基本上描述的都是一些过时漏洞，且无利用价值，应该可以直接移除。“PC Gamer演示版”描述的内容更像是这个版本中的独有特性，应该可以将此章节更改为其他名称。而“语言”描述了一些现今仍存在，且影响范围较大的漏洞，这些内容有一定的保存价值，只是具体怎么保存还需要讨论。-- Anterdc99（论·功） 2022年5月11日 (三) 11:50 (UTC)（最后编辑于2022年5月11日 (三) 12:07 (UTC)）
- 意见：
- 1. 把Java版远古版本页面上列出的漏洞删除，理由同上；且其他Java版版本页面都没有对该版本中所出现的漏洞进行详尽描述，为了格式统一也应该删除。
- 2. “PC Gamer演示版”和“语言”的漏洞一段，将前者的段落名称改为“已知漏洞”，后者移动至“你知道吗”一段下作为单独的子段落，保留“漏洞”的段落名称。--AblazeVase69188（讨论 | 贡献） 2022年5月13日 (五) 11:06 (UTC)
由于目前没有更多人参与此话题，为避免无限期搁置，现拟参考AblazeVase69188的意见以结束此话题。如有其他不同意见，请于1日内提出。-- Anterdc99（论·功） 2022年5月26日 (四) 05:33 (UTC)
关于部分页面将漏洞情况加入非“修复”段落的问题
各位好，如题目所示，我认为不能将漏洞的情况添加至非“修复”段落中，否则内容将会非常杂糅，且不统一，我的观点是删除所有不在“修复”段落的漏洞修复信息。
——
Thaumic Copper（吐槽·考古） 2022年5月13日 (五) 09:58 (UTC)
- 例子？-- Dianliang233 T•C 2022年5月13日 (五) 10:00 (UTC)（最后编辑于2022年5月13日 (五) 10:01 (UTC)）
- 耕地#历史——Thaumic Copper（吐槽·考古） 2022年5月13日 (五) 10:01 (UTC)
- 见MCW:SG/F#历史中所述的例外情况。-- Anterdc99（论·功） 2022年5月13日 (五) 10:05 (UTC)
- 见MCW:SG/F#历史中所述的例外情况。--
- 耕地#历史——
- 反对：有些漏洞修复实际上也是特性更改，尤其是基岩版，如果全部放到修复反而不好。（一般很多人读更新日志都会跳过大段修复章节）像现在这样挺好的，只要规范一下就可以了。Tzql1104048（讨论） 2022年5月21日 (六) 03:51 (UTC)
Screen相关译文待更新
部分页面（如调试界面、菜单界面）应将其中对应“Screen”的“界面”更换为“屏幕”使其与Crowdin译文保持一致。 -Jingji132（讨论） 2022年5月18日 (三) 10:24 (UTC)
关于教程中有关旧版本的内容
如题，许多教程包含“某特性从某版本开始可用或在某版本之后不可用”之类的描述，我认为应当对这些内容进行一定程度的删减，因为Minecraft Wiki的教程是随着新版本发布而一同更新的，不可能兼顾所有版本的玩家，因此建议做出如下更改：
- 在教程中列出当前最新版本可用的内容或特性，将“某特性从某版本开始可用”的描述移除。
- 将过时的内容或特性归档到相应页面的结尾，并用
{{Outdated feature}}标明失效的版本及原因。
大家如有不同的看法，烦请在下面陈述。--ultim_0 ( USER | TALK | WORK ) 2022年5月18日 (三) 15:33 (UTC)
- 意见：过时的内容或特性可以放置在
/××之前子页面，并以{{loadPage}}或{{main}}模板链接至对应的教程页面。--AblazeVase69188（讨论 | 贡献） 2022年5月20日 (五) 10:10 (UTC) - 支持。--McplayerFS（讨论 | 贡献） 2022年5月28日 (六) 02:27 (UTC)
关于中国版缺乏介绍的问题
发现关于中国版的介绍只有中国版这一个页面，关于家园系统，网易自己制作的游戏地图等缺乏介绍。–该未签名留言由59.149.163.248（讨论）在2022年5月23日 (一) 05:00 (UTC) 添加。请在您的回复后面加上 ~~~~
- 由于潜在的法律风险，中国版独有内容在Minecraft Wiki不受支持，感谢您的理解。另请参阅讨论页存档。--ultim_0 ( USER | TALK | WORK ) 2022年5月23日 (一) 05:49 (UTC)
- w:Special:CreateNewWiki-- Dianliang233 T•C 2022年5月23日 (一) 05:54 (UTC)
- 本Wiki不收录更多关于中国版的内容。请寻求国内的Wiki农场的协助或者在Fandom申请新的Wiki（上方链接）试着自己编写。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月23日 (一) 07:14 (UTC)
- 签名请用半角波浪线。传入神经元（权限|讨论|贡献|日志) 2022年5月23日 (一) 07:44 (UTC)
关于“萤火虫”的内容收录问题
下列讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 建立独立的萤火虫页面。
目前，关于萤火虫的为数不多的信息被安放在Java版提及特性里。然而，萤火虫并不是Java版独有特性，它甚至在基岩版里有了源代码（但在最新的测试版里被移除）。换句话说，可以通过一些方法来在即将发布的基岩版1.19.0或者在它的测试版本里将其调用出来，这对于基岩版开发者而言是非常简单的事情（已经有开发者做到了）。
这里就不再展开详细介绍。现在的问题是，萤火虫作为非版本独有特性，该将更多的内容放置在哪？在Java版提及特性页面里插入基岩版内容是不明智的做法，而在基岩版提及特性里插入更多内容也会导致重复叙述；萤火虫本身就不属于版本独有的内容，如果将其强行放置在区分版本的特性页面里是非常不明智的做法。
或许可以考虑单开一个页面来放置萤火虫的相关信息，但是本wiki并没有为单独一个提及特性建立一个页面的先例；如果将会萤火虫视作“已移除的特性”，实际上也仅仅加入了代码，无法在游戏里使用正常命令生成，还不构成视作“已移除特性”的惯例。
我个人是不希望因为上述问题阻碍了对单个特性的更多内容的收录，更不用说“萤火虫”是最近讨论热烈的话题。我希望能够获得各位的看法。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月26日 (四) 04:58 (UTC)
- 意见：天域
（重定向至Java版提及特性/天域）就是一个先例，完全可以参照这个特性，为萤火虫建立一个单独的页面（如基岩版提及特性/萤火虫）。--ultim_0 ( USER | TALK | WORK ) 2022年5月26日 (四) 05:02 (UTC)（最后编辑于2022年5月26日 (四) 05:12 (UTC)）
- 我觉得 没什么问题，毕竟萤火虫在基岩版属于已经进行了一定程度的开发并且虽然被隐藏了但是还是加入了基岩版并且通过一定手段可以调出来的内容。方法放寒假 (Talk - Contributions) 2022年5月26日 (四) 06:25 (UTC)
- 支持单开页面。--KaplanSteve T/C 2022年5月26日 (四) 07:14 (UTC)
- 关于萤火虫的更多信息我放在我的沙盒里了，请各位查看一下。我想这些内容已经足够支撑一个页面（有趣的是，萤火虫还有实体Sprite，并没有移除）。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月26日 (四) 12:59 (UTC)
- 我已经收集到了充分的信息。在开发者版本的基岩版里，萤火虫不仅有刷怪蛋，而且能够使用命令生成。Mojang在编译零售版的时候把萤火虫的相关代码去除了，但是仍然有目标选择器的残留。开发者版和零售版是并行的，同样属于原版。显然，在开发者版里，萤火虫是属于原版附加包的内容的，只是如果想要在普通用户玩到的版本中实现萤火虫，确实需要加载外部的附加包来实现。综上所述，萤火虫不算是提及特性，它属于即将被移除的特性。因此既不需要改动格式指导，也允许单独一个页面介绍。如果没有更多人持反对意见，我会完善后移动到主命名空间里。祝各位编辑愉快。--Lxazl5770zh.admin（论 ▪ 功） 2022年5月27日 (五) 17:31 (UTC)
关于“最近更新”
我们关于“最近更新”版块，我们可以在最近更新版面里添加快照版本的更新。这样就可以让玩家们跟进何时发布的快照更新。 Batele Jackson（讨论） 2022年5月27日 (五) 17:38 (UTC)
- 反对，已经有类似的内容了，见于“开始游戏！”的“开发/测试版本”。另，涉及首页内容相关的话题应当在首页的讨论页进行讨论。--ultim_0 ( USER | TALK | WORK ) 2022年5月27日 (五) 17:51 (UTC)
关于“画廊”章节的文字说明
我发现每个页面的“画廊”章节图片下的文字说明部分存在一个问题，就是句末要不要加句号的问题。虽然无伤大雅，格式指导里也没有，但是我认为这种细节问题还是统一一下比较好，统一了观感上也有提升。--KaplanSteve T/C 2022年5月28日 (六) 08:42 (UTC)
修改四个~签名
本主题或以下段落文字由ultim_0 ( USER | TALK | WORK )移动自Minecraft Wiki:管理员告示板。
可不可以在使用四个~签名时自动在前面加上“--”？
原版：
用户名 日期
修改：
--用户名 日期（相当于--~ ~ ~ ~）
--Java.lang.NullPointerException（讨论） 2022年6月3日 (五) 06:15 (UTC)
弃用“数据标签”一词
建议弃用“数据标签”一词，全面更改为“NBT标签”或“NBT”。
- 社区几乎不使用，实在没见过有哪个玩家在交流时会带上“数据标签”一词。
- 游戏内已不使用该词。“数据标签”对应的原文是“Data Tag”，这个词组只存在于较早期的Minecraft中，当前版本直接使用“NBT”一词，中文也全部照写“NBT”。
- “数据”一词概念过于广泛，方块状态也可以属于数据，而“NBT”能更好的指明它是什么。--Yzy32767（讨论） 2022年6月4日 (六) 00:02 (UTC)
请求敲定“parity”一词的标准译名为“趋同”
请求敲定parity一词的标准译名为趋同，理由分述如下：
- 现状
- 当前parity一词本身无单独翻译，Parity Issue词组被MCW翻译为待同步特性，Vanilla Parity被MCBBS相关更新日志页面翻译为特性同步。
- 敲定该词的标准译名的必要性
-
- 在部分官方文章中parity一词单独出现，或与其他更多单词一起组成词组出现，导致不便或无法翻译，例如parity request、feature parity等。参考页面为：https://feedback.minecraft.net/hc/en-us/articles/360015877192 ；Minecraft Feedback网站亦有名为Parity的分类。
- parity无标准译名会导致玩家或开发者（尤其是开发者）无法对这个词语产生既视感，亦不便于玩家或开发者在Minecraft Feedback或Mojira上进行相关反馈或在其他涉及到的地方使用。
- parity一词的解释
- 词根-par-来自于拉丁语par、paris，意为相同、类似。率先被数学界确立为术语，parity表示数学中一种类似但对称/对等变化的事物：奇偶性。随后被经济学确定为不同国家货币单位的一种对称/对等变化：平价，被物理学确定为“宇”（即空间）的一种对称/对等变化性质：宇称。随后被计算机界确立为一种校验两个程序是否具备相同功能的过程，通过比较1的数量（是奇还是为偶）是否一致来确定程序功能是否一致，被称为：奇偶校验（来自于微软术语库），而作为该过程的结果，即两个对称/对等变化的程序功能的一致程度，称为功能的奇偶一致性（来自于微软术语库）。Mojang选取了这一概念，并作出了改编和进一步解释：在官方文章Parity Requests and You: A Guide中，给出解释“Parity is a word that we use a lot here. We use it to mean "ways we can make Minecraft be the same experience as much as possible, regardless of what 'engine' you are using to play". Starting with Update Aquatic, our team renewed its commitment to developing the same features for all versions being updated in Minecraft at the same time.”。注意，这是一种自我免责的说法，“we can make Minecraft be the same experience as much as possible”，这里所说的是提供相同的体验，而非相同的功能，这是一种具备很大最总解释权的说法；而后一句话，也仅是在说从海洋更新开始，我们（才）承诺同时提供相同的功能，事实上这句话并不是在说parity问题了。同时更新相同的功能属于更新问题而非我们所谓的“将一方的特性（feature，其实应该翻译为功能）移植到另一方上的问题”（当然也正是因为这个原因本来在BE开发者版中基本上都做好的萤火虫和白桦树（可能）因为JE产能不足给删了，当然这就是另一个指的探讨的问题了，和本问题无关）。可以看出，Mojang的parity显然来自于微软对于parity奇偶校验的词义，但是，该词只选取了使功能（或者说体验）尽可能相同的说法，而没有进行所谓的真正的“奇偶校验”。微软的“奇偶校验”翻译不可取。
- 当前翻译的错误性
- 接上一段，我们可以看出，parity并非同步。Mojang选取parity一词作为特性移植的代名词，而不是uniform、consistency、port、synchronize等，很可能是由于parity词义模糊，可以充分解释，进行自我免责。同时，Minecraft Feedback网站上也有很多提出的parity申请被表示不会在可视时间内移植（类似于Mojira的not fix）。parity并非承诺同步，亦非承诺一致、同化、等价……。这是当前的同步不可取的原因。而特性一词更是无中生有，如果必须保留这种翻译，那么parity request、单独的parity等翻译也就必须“曲线救国”，绕圈调整至类似的翻译的样子。不可长久，亦不可取。
- 给parity一词下个定义
- 经过上述分析，Mojang给出的parity意为对JE和BE之间的功能对称调整，使其体验趋于相同的过程。解释：调整tweak的是功能feature，tweak意味着微调而非一致化的保证，该词亦是官方更新日志选取的词汇；趋同的是体验experience，与官方的解释相一致。
- 社区讨论过程
- 由我先提出等称的翻译，改编自物理学翻译宇称。由于晦涩难懂，在贡献者群试讨论被全盘否定，移至基岩版开发术语讨论群投票，被否定。在基岩版开发术语讨论群中讨论并征集译名，在分析parity的发展与含义后陆续否定所有绝对性词汇，同时否定的原因也有不符合一词一译的原则（例如一致应为uniform或consistency，同步应为synchronize等，会产生术语冲突，提高翻译成本），最终得出趋同一词作为术语，在场人员全部持赞同或中立赞同立场，发起投票，尚无反对票产生。
- “趋同”的优势
-
- 符合定义，趋同即JE与BE游戏体验的趋同，虽然“调整功能”这一含义没有体现，但是也暗含其中。
- 群众接受成本低，趋同为“顺口词汇”，不像等称等翻译让人无法接受。
- 不会产生术语冲突，趋同一词为中文纯文学性词汇，对应的英文只有文学性的converge/convergence。而converge/convergence作为非文学性/专业词汇时应翻译为收敛，因此不会产生术语冲突，便于行文翻译。
- 总结
- 在几乎所有能够想出的词汇都被以充分的理由否决之后，趋同一词以其独有的优势看似成为了该术语的译名敲定最优解。因此，请求敲定parity一词的标准译名为趋同。
- 相关翻译
- parity 趋同
- feature parity 功能趋同
- vanilla parity 原版趋同
- parity issue 趋同问题
- parity request 趋同请求
方法放寒假 (Talk - Contributions) 2022年6月8日 (三) 16:52 (UTC)
- 支持。趋同一词是目前社区提出的相对符合parity在MC中含义且顺口的词汇了
QianShanyao（留言） 2022年6月8日 (三) 17:12 (UTC)
- 这就是太长不看效应吗？唔，作为参与了讨论初期的人，我表示parity issue翻译成趋同问题会有理解成“趋同是一种问题”的嫌疑。-- Lakejason0（论•功） 2022年6月9日 (四) 01:08 (UTC)
- 附议：可以将parity issue翻译为趋同事项。--AblazeVase69188（讨论 | 贡献） 2022年6月9日 (四) 01:41 (UTC)
- 唔......作为parity翻译的提案，在此处我个人关注的更多还是parity，而有关parity issue的翻译，这应该是issue在此处翻译的问题，而非parity吧（且我也是全程参与了在术语群的讨论的qwq） ——QianShanyao（留言） 2022年6月9日 (四) 09:34 (UTC)
- 同意，改用“趋同”加强了翻译间的统一性，且贴近原文而直观。
- 另外，关于“parity issue”，“趋同问题”或者“趋同议题”这样的直译就行。--Yzy32767（留言） 2022年6月15日 (三) 12:38 (UTC)
- 意见：可否考虑把parity issue翻译成“趋同事项”？--ultim_0 ( USER | TALK | WORK ) 2022年6月17日 (五) 15:31 (UTC)
- 意见：总觉得“趋同事项”“趋同问题”这些翻译虽然准确，但是挺怪的……Tolly9180（留言） 2022年6月18日 (六) 10:15 (UTC)
远古之城页面缺少结构图片
1.19都更新了，远古之城页面结构图片还没有吗？请大家赶紧上传。 —-146.19.174.201 2022年6月9日 (四) 04:49 (UTC)
- 1.“Ancient City”的正式翻译为远古城市；
- 2.请问您是指游戏中所生成的结构的逐层构造吗？本Wiki的这些逐层构造并非由图片构成，而是由
{{layered blueprint}}模板输出； - 3.若您有能力，您可以注册一个账户，并至Minecraft_Wiki:计划/结构蓝图开始完善远古城市相关结构。--AblazeVase69188（讨论 | 贡献） 2022年6月9日 (四) 10:08 (UTC)
- 远古城市的结构较为复杂，无论是单个结构的等轴渲染图还是蓝图的制作都难以一蹴而就，还请您理解。--ultim_0 ( USER | TALK | WORK ) 2022年6月9日 (四) 10:15 (UTC)
关于首页大段空白的问题
本人的多个设备以及部分尝试了查看首页的群友在打开首页的时候均会在“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)
- 英文版本的版本信息是放在下面的，这样就无需考虑其高度问题。但同样的，就得考虑其他部分的内容宽度和高度问题。-- Lakejason0（论•功） 2022年6月19日 (日) 13:13 (UTC)
- 我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770zh.admin（论 ▪ 功） 2022年6月20日 (一) 02:33 (UTC)
- 并不是“插入”的问题，而是重新整理，重新排版的问题。-- Lakejason0（论•功） 2022年6月20日 (一) 03:01 (UTC)
- 并不是“插入”的问题，而是重新整理，重新排版的问题。--
- 重新排版确实有必要，不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 T 2022年6月20日 (一) 05:30 (UTC)
- 仿效en的排版其实也不错，把你知道吗换成每周页面如何呢？-- 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的排版其实也不错，把你知道吗换成每周页面如何呢？--
- 留言：浏览首页及相关页面（Minecraft Wiki/style）可知，首页的栏目布局的代码见于MediaWiki:Gadget-mainpage.css，其中与首页栏目布局相关的内容如下：
| 目前的布局 | ultim_0建议的布局 | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
| |||||||||||||||||||||||||||||
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
/* ... */
#fp-1 {
-ms-grid-area: a;
grid-area: a;
}
#fp-2 {
-ms-grid-area: b;
grid-area: b;
}
/* #fp-3到#fp-9同理 */
#fp-10 {
-ms-grid-area: j;
grid-area: 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月22日 (三) 06:16 (UTC)）
- 我根据Ultim的提案制作的最终提案如下。
对于首页的CSS：
/** Responsive main page layout **/
#main-page.main-page {
display: -ms-grid;
-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
-ms-grid-template-columns: 1fr;
display: grid;
grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
#main-page.main-page {
-ms-grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
-ms-grid-template-columns: 1fr 1fr 1fr;
grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
grid-template-columns: 1fr 1fr 1fr;
}
}
对于每周页面的图片：
<onlyinclude>[[File:{{{img|}}}||{{{img-size|}}}|border|center|class=banner-image nomobile]]<div style="line-height:2em;display:table;min-width:25%;">{{{content|}}}
<p class="nomobile">
{{{img-desc|}}}</p></div></onlyinclude>
- 还有一些其他的方案。-- Lakejason0（论•功） 2022年6月22日 (三) 06:07 (UTC)（最后编辑于2022年6月22日 (三) 06:42 (UTC)）
- 由于测试过程中发现了一些新问题，在此说明一下问题以及一些新的提案。
- 问题1：首页的每周页面图片有浮动，会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。
- 问题2：版本信息一栏方格下方的列表观感不好，词汇会断开，而且横向列表在列表项目不多时展示效果较差。
- 基于以上发现的两个问题，我又查看了其他语言站点的首页，相关情况如下：
- 英文：版本信息单独出一整个横栏，所有的购买链接和版本号放在一起。
- 西班牙语：重新设计了首页，将版本信息删除。
- 由于版本信息写全似乎冗余，在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。-- Lakejason0（论•功） 2022年6月22日 (三) 06:48 (UTC)
| 韩国语wiki首页的布局 | |||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||
- 注意到韩国语wiki相对于en也对首页排版进行了小幅度修改，如右表所示，其中的“关于外来词”是其独有的栏目，对应zh的“每周页面”，除此之外的各个字母表示的内容与zh相同。--ultim_0 ( USER | TALK | WORK ) 2022年6月22日 (三) 07:14 (UTC)
- 我在Editcopy中修改了一部分代码，将购买链接和试玩链接直接添加到了版本信息方格中。这样就可以解决问题2（通过直接删除、转移到版本方格内的方式解决）。由于这样的更改会导致先前的版本号合并不再可行（链接显示会不完整），我暂时先放在那边。-- Lakejason0（论•功） 2022年6月22日 (三) 08:01 (UTC)
Minecraft Wiki自动下载文件
几乎每次访问时均会自动下载f.txt与cm。我认为可能有攻击者修改了源代码。以下是我找到的可能与自动下载有关的源代码(在head区内)：
<script src="https://securepubads.g.doubleclick.net/gpt/pubads_impl_2022061501.js?cb=31068115" async=""></script>
希望管理员可以修复，谢谢！
183.193.129.221 2022年6月22日 (三) 08:10 (UTC)柚子柚子