Minecraft Wiki:社区专页

社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。

请了解，Minecraft Wiki在共识系统上运作而不是投票决定，清楚地阐述自己的理由比简单地支持争论的一方更有效。

涉及管理员权限的相关事宜请发布于管理员告示板。涉及繁简字词转换等问题请到繁体中文问题报告中提出。

常用页面

• 计划
• 格式指导
• 版本格式指导
• 红石格式指导
• Wiki条例
• 编辑手册
• 讨论页方针
• 书面汉语指导
• 特殊页面
• 快速参考页
• 沙盒
• 维基百科的编辑指南

Minecraft Wiki不是客户服务中心！游戏问题请移步Minecraft帮助中心或者玩家游戏社区。

所有在该页面上发表的无关话题都将被存档至无意义话题处。

请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。

语言

• čeština
• Deutsch
• Ελληνικά
• English
• español
• français
• magyar
• italiano
• 日本語
• 한국어
• Nederlands
• polski
• português
• русский
• ไทย
• Türkçe
• українська

快捷方式

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上任。

存档

• 2014年11月－2018年12月
• 2019年1月－2019年6月
• 2019年7月－2019年12月
• 2020年1月－2020年4月
• 2020年5月－2020年6月
• 2020年7月－2020年12月
• 2021年1月－2021年6月
• 2021年7月－2021年12月
• 2022年1月－2022年6月
• 2022年7月－2022年12月
• 2023年1月－

#	话题	发言条数	参与人数	发起者	最后发言者	最后发言时间（UTC）
1	携带版Alpha版本名称问题	5	5	Redpop1	RedLightPOP	2020年8月13日 (四) 02:09
2	我怎么创建我的用户页？	8	4	冰川橘子	Drlee lihr	2020年8月3日 (一) 09:24
3	求大佬帮我往模板mojang studio里加个人	3	2	冰川橘子	冰川橘子	2020年8月4日 (二) 08:47
4	关于社区专页和管理员告示板的话题处理	15	6	MysticNebula70	MysticNebula70	2020年8月9日 (日) 13:55
5	关于贡献提纲	43	10	117.181.15.209	Lakejason0	2020年9月6日 (日) 02:16
6	关于记分板与标签、队伍	5	3	Skyicecn1	Skyicecn1	2020年8月19日 (三) 02:13
7	希望添加新的页面	5	5	117.44.229.151	36.161.160.35	2020年8月12日 (三) 12:44
8	如何回退文件？	2	2	Duowan channel	Drlee lihr	2020年8月17日 (一) 01:23
9	是否有必要将已移除特性拆分为独立的页面	19	13	Hatsuki kiri	Lxazl5770	2020年8月14日 (五) 14:20
10	猪灵条目需要猪人信息	2	2	Duowan channel	Hatsuki kiri	2020年8月14日 (五) 03:21
11	MC地下城Wiki微标需要优化	2	2	Duowan channel	Lakejason0	2020年8月14日 (五) 03:31
12	关于内含文字的图片的繁简转换	19	6	Lakejason0	RedLightPOP	2020年8月26日 (三) 20:28
13	关于一个有歧义的句子	1	1	冰川橘子	冰川橘子	2020年8月20日 (四) 12:43
14	关于版本页面格式	4	3	[[User:SkyEye_FAST SkyE] |SkyEye_FAST SkyE] ]]	RedLightPOP	2020年8月28日 (五) 16:19
15	是否应该将网易版的“新玩法”加入wiki？	3	3	112.23.187.225	Ultim 0	2020年8月24日 (一) 08:50
16	关于版本文件格式	2	2	RedLightPOP	[[User:SkyEye_FAST SkyE] |SkyEye_FAST SkyE] ]]	2020年8月28日 (五) 07:53
17	告知 InPageEdit 插件使用者	1	1	Xiaoyujun	Xiaoyujun	2020年8月30日 (日) 17:10
18	拆分末路之地	3	3	RedLightPOP	Jeremylin0511	2020年9月12日 (六) 07:11
19	关于notch	3	2	122.96.40.87	117.71.48.151	2020年9月11日 (五) 07:38

话题

携带版Alpha版本名称问题

目前携带版Alpha版本在Wiki的命名方式有Alpha 0.x.x、v0.x.x alpha等（包括但不限于页面标题、{{version nav}}模板的|title=参数等），除页面标题较统一外，其余名称极其不统一。游戏内，在0.13.0之前全部采用v0.x.x alpha的命名方式，0.14.0及之后全部采用v0.x.x的命名方式，0.13不详。可将页面内的版本名称作统一，统一为Alpha 0.x.x或v0.x.x alpha与v0.x.x。

携带版Alpha版本页面标题也可采用类似游戏内的携带版Alpha v0.x.x的命名方式，和Java版Alpha差不多。--Redpop1·讨论 2020年7月31日 (五) 04:57 (UTC)

Redpop1以ip：0.13使用v0.x.x alpha。开发版本疑似全部使用v0.x.x alpha build x。—171.210.37.144 2020年8月1日 (六) 08:38 (UTC)

见MCW:格式指导#条目标题。 MysticNebula70 ( ^T / _C ) 2020年8月1日 (六) 13:53 (UTC)

@RedLightPOP：，请问为何要删去{{version nav}}的|title=参数？MCW:SG并没有这么说，应按照游戏内版本标注。--SkyE | Talk · Contributions · Logs 2020年8月7日 (五) 05:28 (UTC)

我想让它自动显示正确的协议版本，而不是改|protocol_manual=，模块:Protocol version/Versions里就像那样。如果用游戏内的，可以改模块的版本，或让它正确地转换成模块里写的版本。--RedLightPOP·讨论 2020年8月13日 (四) 02:05 (UTC)（最后编辑于2020年8月13日 (四) 02:09 (UTC)）

我怎么创建我的用户页？

我想创建可以自定义、个性化的用户页，然而不管是在地址栏里输入xxxdd（这部分是域名）/User:冰川橘子 还是直接使用搜索功能搜索“User: 冰川橘子”都会跳转到“UserProfile: 冰川橘子”。我应该怎么办？--冰川橘子（讨论） 2020年8月3日 (一) 08:36 (UTC)

在Special:参数设置中更改为“使用标准的用户页”就不跳转了。--化学家唱哥（T|C） 2020年8月3日 (一) 08:39 (UTC)

难搞，我调到你说的选项之后还是没用，我检查过我有没有提交成功了--冰川橘子（讨论） 2020年8月3日 (一) 11:31 (UTC)

@ChemistChang：好像你自己也没设置的样子--SkyE | Talk · Contributions · Logs 2020年8月3日 (一) 09:15 (UTC)

@SkyEye FAST：现在我设置了--化学家唱哥（T|C） 2020年8月3日 (一) 09:33 (UTC)

欸？我怎么设置完保存完了之后还是增强版用户资料页啊？--化学家唱哥（T|C） 2020年8月3日 (一) 09:36 (UTC)

建议：1.F5 2.去看看有没有保存成功--SkyE | Talk · Contributions · Logs 2020年8月3日 (一) 09:43 (UTC)

或者可以在访问的时候使用index.php?title=User:用户名&profile=no，就不会跳转到UserProfile页面了 -- Drlee lihr 讨论/贡献 2020年8月3日 (一) 09:24 (UTC)

求大佬帮我往模板mojang studio里加个人

就是这个人：Thomas Guimbretière 那个模板太大了，加起来太麻烦了--冰川橘子（讨论） 2020年8月4日 (二) 08:21 (UTC)

 已完成。遇到这种情况请善用Ctrl+F。--葉月 桐§ 2020年8月4日 (二) 08:43 (UTC)

主要是找姓氏为g开头的太难了，一大堆g看得我眼花缭乱--冰川橘子（讨论） 2020年8月4日 (二) 08:47 (UTC)

关于社区专页和管理员告示板的话题处理

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

讨论结果为 建立专门的页面。

---

近一段时间以来，本专页和管理员告示板的话题数量明显增加，这些话题中有相当一部分是各种无关的垃圾话题，都予以了折叠等处理。尽管如此，页面的存档速度仍然明显加快。为此，有必要重新考虑存档页面和话题处理的方法。

我在此提出一个想法：建立Spam Archive n之类的子页面（具体名称可以讨论），专门用于存档各类垃圾话题。另外，正常的存档页面可以适当拉长（即里面的话题可以变多，反正是存档页），只需要保证当前页面上没有过多过期话题即可。有其他想法也可提出。 MysticNebula70 ( ^T / _C ) 2020年8月5日 (三) 14:05 (UTC)（最后编辑于2020年8月5日 (三) 14:11 (UTC)）

 中立偏向 支持。的确增长速度太快，而且大部分话题都无太大作用。--  Lakejason0（论•功） 2020年8月5日 (三) 14:07 (UTC)

 支持。不过我认为管理员告示板和社区专页的垃圾话题可以存档在同一个页面，如有必要，标明存档自哪个页面即可。--葉月 桐§ 2020年8月5日 (三) 14:13 (UTC)

 支持。这种情况下至少可以在存档页里把有用的弄出来，减少无关垃圾信息。——Icyphantom 讨论I贡献 2020年8月5日 (三) 14:18 (UTC)

 支持这样可以排除垃圾话题，还可以提高每次存档时间间隔。-- 北狐 2020年8月6日 (四) 05:57 (UTC)

 支持——垃圾话题查证价值不大，混在有益话题里面我觉得很碍眼。--Lxazl5770_zh.admin（论 ▪ 功） 2020年8月6日 (四) 09:09 (UTC)

垃圾话题存档页

这样的页面社区专页和管理员告示板是分开存档还是合并存档？页面名称应该是什么？ MysticNebula70 ( ^T / _C ) 2020年8月6日 (四) 08:56 (UTC)

如果这些话题基本上都是一些错置话题（且趋向一致），那么合并也无不可。--  Lakejason0（论•功） 2020年8月6日 (四) 09:06 (UTC)

另建存档就行了，比如无益话题存档123……虽然看起来像公 开 处 刑--Lxazl5770_zh.admin（论 ▪ 功） 2020年8月6日 (四) 09:11 (UTC)

这话怎么这么熟悉呢。--  Lakejason0（论•功） 2020年8月6日 (四) 09:39 (UTC)

取名的话可以稍微中性一点，比如折叠话题存档页之类的（这个名字很烂不要用）。--  Lakejason0（论•功） 2020年8月6日 (四) 09:39 (UTC)

管理员告示板上的折叠内容和社区专页的大方向似乎并不完全一致，而且管理员告示板上的部分折叠话题其实应该在社区专页提出。 MysticNebula70 ( ^T / _C ) 2020年8月6日 (四) 14:38 (UTC)

同样是无意义话题，同样不具备参考价值，两者没有什么不同的地方，我觉得还是合并好一点。--Lxazl5770_zh.admin（论 ▪ 功） 2020年8月7日 (五) 15:28 (UTC)

那么，这些话题的存档页完整名称就取成Minecraft Wiki:无意义话题/存档n了。 MysticNebula70 ( ^T / _C ) 2020年8月8日 (六) 02:28 (UTC)

页面已建立，见MCW:BADTOPIC。 MysticNebula70 ( ^T / _C ) 2020年8月9日 (日) 13:55 (UTC)

关于贡献提纲

目前有些大型的页面内容杂乱，分类错综复杂。但有些编辑者不明所以，仍然往页面内添加一些虽然符合wiki相关条例，但不符合页面实际情况的东西。所以，建议为一些大型的，或者重要的页面添加贡献提纲，写明这个页面目前最需要的是什么，已经有的是什么，还需要完善的是什么等等。我个人认为，这样有助于增加页面条理性，让页面看上去更加整洁美观。117.181.15.209 2020年8月8日 (六) 00:28 (UTC)

虽然是一个看上去很好的提议，但是个人认为这个方案 不符合Wiki实际。--  Lakejason0（论•功） 2020年8月8日 (六) 03:58 (UTC)

也许每个页面给一个{{needs update}}足矣。--  Lakejason0（论•功） 2020年8月8日 (六) 04:02 (UTC)

怎么说呢，我的意思是，如果一个页面需要一个像wiki条例一样详细的注意事项，就不能用{{needs update}}了117.181.15.209 2020年8月8日 (六) 05:53 (UTC)

你所说的情况 应该并不存在，如果有那么复杂的页面的话，那种页面也只会逐步拆分掉。为了维护方便，应该也不会允许如此复杂的页面存在吧。也许你想的东西不是你说的，但是就你所说的内容而言，我认为 不符合Wiki的维护需要。我非常 理解对页面维护没有什么太多规范感到的不安，但是我们毕竟有格式指导。如果你指的是教程的话，那么很遗憾Wiki目前没有人有能力巡查教程。--  Lakejason0（论•功） 2020年8月8日 (六) 06:13 (UTC)

以及，个人认为维护一个如此长的页面的更新注意事项，这本身和更新这个页面本身一样麻烦，因此我依然认为{{needs update}}（这个模版可以写入需要更新的原因）足以胜任目前的编辑提示/贡献指导的作用。--  Lakejason0（论•功） 2020年8月8日 (六) 06:13 (UTC)（最后编辑于2020年8月8日 (六) 06:19 (UTC)）

也许你可以举一些例子来更好的描述你的想法。以及，如果可以的话，可以尝试注册账号。--  Lakejason0（论•功） 2020年8月8日 (六) 06:15 (UTC)

不不不，我所说的“和Wiki一样详细的注意事项”只是举个例子。而且，我并不理解“Wiki目前没有人有能力巡查教程”，当然，这不是重点。已经有事实证明格式指导并不像想象中的管用，一个较长的页面的几个项目之间难免有些内容上的重复，但因此就把它放到另一个项目去，又不太合适。而将页面拆分也有弊端。如果有一个专门为指定页面编写的贡献提纲，就能杜绝或减少这样的现象的发生。如果你们认为我指教程页面，其实就算“Wiki目前没有人有能力巡查教程”也没太大关系（当然是指非恶意编辑的情况），个人认为写出贡献提纲后，至少能给积极的IP编辑者一个奋斗的方向，迟早能把页面规范化。117.181.15.209 2020年8月8日 (六) 06:31 (UTC)

教程无人巡查主要指的是大部分教程都“过时”了。一些教程甚至是在Beta时期写的，又由于教程实在太繁杂，所以“没有人有能力定期（像主页面一样的细致）巡查”和像主页面一样维护。至于“有一个专门为指定页面编写的贡献提纲，就能杜绝或减少这样的现象的发生”，我认为这并不一定。虽然存在这么一个东西是好的，但是这个东西维护起来如果非常麻烦，那就是得不偿失。至于重复内容等格式问题，如果你发现了，可以当场修复并且写明编辑摘要。--  Lakejason0（论•功） 2020年8月8日 (六) 06:42 (UTC)

教程可不只是过时，标点和格式等乱七八糟的东西也令人头疼（我深有体会）。Sigma166（讨论） 2020年8月8日 (六) 06:46 (UTC)

以及，如果给用户奋斗方向，你依然可以挂{{stub}}或者{{needs update}}并在模板参数里写明原因。如果需要很多行，也可以<br>。--  Lakejason0（论•功） 2020年8月8日 (六) 06:42 (UTC)

也许你也可能指的是在更新条目计划内搞一个类似于条目问题之类的子页面吧，我不知道实际维护难度怎么样（毕竟还没试过），但是我不持肯定态度。--  Lakejason0（论•功） 2020年8月8日 (六) 06:42 (UTC)

这玩意没人写，而且更新维护比原页面更麻烦，故此 强烈反对。--  Dianliang233 ^T•_C 2020年8月8日 (六) 06:36 (UTC)

如果有些页面的确比较混乱，或者不符合实际情况什么的，那就像Lakejason0说过的一样——“Do it yourself”。Sigma166（讨论） 2020年8月8日 (六) 06:41 (UTC)

Wiki更需要的是解决问题而非仅仅去发现问题。如果发现问题立马就能解决掉，那就解决，不能解决就挂模板。行动可能更重要一些。--  Lakejason0（论•功） 2020年8月8日 (六) 06:56 (UTC)

难道因为更新维护麻烦就对原页面格式不规范不作为吗（不针对个人或集体）？如果认为维护麻烦，不能将其整合进原页面吗？（确实有可能受到恶意编辑，但请相信IP用户能自觉撤销该类编辑）是维护一个格式杂乱无章的页面麻烦，还是一个格式有条有理的页面麻烦？鉴于以上几点，我对Dianliang233的说法表示 反对。而且，你们怎么就认为这东西维护起来很麻烦？难道以前试过？所以，我对认为贡献提纲维护麻烦的各位管理员表示 反对。对于建议使用模板代替贡献提纲的各位管理员，我也不得不表示 中立偏向 反对。因为有些页面的复杂程度远超想象，但又因为各项目之间有着千丝万缕的关系，不好拆分。因此，用模板代替贡献提纲在一些页面是不可行的。“Wiki更需要的是解决问题而非仅仅去发现问题”？要是我能自己解决问题，还来社区专页提议干嘛？因此，在这种场合下，我对这种说法表示 部分反对。117.181.15.209 2020年8月8日 (六) 07:05 (UTC)

很抱歉，刚才的语气确实强烈了些。不过，这不表示我对任何一个人有个人意见，如果认为贡献提纲有哪些不可行的地方，请说出来，我可以提一些建议。117.181.15.209 2020年8月8日 (六) 07:13 (UTC)

还是希望你举出来哪一些页面存在这种问题。一部分人依然认为不存在。--  Lakejason0（论•功） 2020年8月8日 (六) 07:51 (UTC)

比如教程/不该做的事117.181.15.209 2020年8月8日 (六) 08:21 (UTC)

讲个笑话，教程/另类玩法。--  Lakejason0（论•功） 2020年8月8日 (六) 08:23 (UTC)

emmm，那好吧，希望你能够写点东西出来（毕竟看上去没几个人想动这种东西）。教程是个大坑，你要真有个办法也行。--  Lakejason0（论•功） 2020年8月8日 (六) 08:26 (UTC)

也许各位管理员对贡献提纲持怀疑态度。不过我认为可以为一个常有用户编辑的、格式谈不上规范的大型页面以子页面形式试验性地编写一个贡献提纲，看看效果如何，到时再做决定。117.181.15.209 2020年8月8日 (六) 07:30 (UTC)

沙盒，请。--  Lakejason0（论•功） 2020年8月8日 (六) 07:42 (UTC)

恕我们并没有这么多精力去写，不过你可以在沙盒里写一个出来。--  Lakejason0（论•功） 2020年8月8日 (六) 07:43 (UTC)

 收到非常感谢各位的支持，我会尽我所能。117.181.15.209 2020年8月8日 (六) 07:49 (UTC)

沙盒总是有用的。36.161.160.35 2020年8月12日 (三) 12:52 (UTC)

贡献提纲还真做出来了一个

MCW:沙盒/教程/不该做的事/贡献提纲。你们认为这份提纲是否有起到“让页面整洁美观”的作用？如果内容有用，是否有更好的办法让这个子页面的关注度提升？大部分人的论点是“没人会看”（类似于没人会看许可协议一样），因此如果这个提纲还行，关于此类贡献提纲关注度又该如何做呢？--  Lakejason0（论•功） 2020年8月9日 (日) 01:11 (UTC)（最后编辑于2020年8月9日 (日) 01:11 (UTC)）

 中立，本人感觉有没有差不多。--ChemistChang（Talk/Contributions） 2020年8月9日 (日) 01:16 (UTC)

目前还不能下结论，建议在28天后或84个百字节以上的编辑后再下结论.117.181.15.209 2020年8月9日 (日) 03:28 (UTC)

放在讨论页

Snow dash提出将贡献提纲放在讨论页。对此方案的评价请在这个子话题下提出。--  Lakejason0（论•功） 2020年8月9日 (日) 01:14 (UTC)

 反对放在讨论页，但本人认为放在个人用户页是可行的。--ChemistChang（Talk/Contributions） 2020年8月9日 (日) 01:16 (UTC)

个人用户页的关注度更低，个人认为并不符合话题提出者的意图。--  Lakejason0（论•功） 2020年8月9日 (日) 01:18 (UTC)

 反对如果放在讨论页，用户们不容易关注到它，贡献提纲的作用便会削弱。117.181.15.209 2020年8月9日 (日) 03:12 (UTC)

 中立虽然看起来比较简洁，但是很难找到（比如我）。36.161.160.35 2020年8月12日 (三) 12:39 (UTC)

作为子页面并添加/改造现有的{{msgbox}}（或者Editnotice）

或者还是作为独立页面，但在主页面开头整一个msgbox，告诉编辑者在编辑之前先认真阅读此页面的贡献提纲。--ChemistChang（Talk/Contributions） 2020年8月9日 (日) 01:38 (UTC)（最后编辑于2020年8月9日 (日) 01:41 (UTC)）

有关此方案的评价请在此子话题下提出。--  Lakejason0（论•功） 2020年8月9日 (日) 01:41 (UTC)

 中立如果{{msgbox}}/Editnotice能起到明显效果，我支持。117.181.15.209 2020年8月9日 (日) 03:57 (UTC)

 支持在开头放一个msgbox。--Skyicecn1（讨论） 2020年8月9日 (日) 06:45 (UTC)

 支持，无论何时，一个目标总是很重要的。Sigma166（讨论） 2020年8月9日 (日) 10:43 (UTC)

 支持加入Editnotice，个人认为能起到较明显效果。-- Drlee lihr 讨论/贡献 2020年8月19日 (三) 10:35 (UTC)

将贡献提纲移出沙盒

就目前来看，贡献提纲基本适应了教程/不该做的事，并起到较为明显的作用。因此，建议将其移出沙盒。117.181.11.122 2020年9月5日 (六) 09:41 (UTC)

已根据意见将该沙盒的内容改造为msgbox并应用。如有不妥，敬请指出。--葉月 桐§ 2020年9月5日 (六) 10:13 (UTC)

并不太确定是不是真的起到了作用。不过换成{{Msgbox}}的方式我认为 可以。--  Lakejason0（论•功） 2020年9月6日 (日) 02:16 (UTC)

关于记分板与标签、队伍

标签、队伍已经从记分板中拆分了出来，但记分板主条目仍有相关介绍的段落：记分板#标签、记分板#队伍。要如何处理这些段落？--Skyicecn1（讨论） 2020年8月9日 (日) 06:45 (UTC)

希望删除，因为相关内容和记分板已经没有联系。--Skyicecn1（讨论） 2020年8月9日 (日) 06:45 (UTC)

 支持。-- 北狐 2020年8月10日 (一) 07:13 (UTC)

 支持(是强迫症的都会这么说)。36.161.160.35 2020年8月12日 (三) 12:41 (UTC)

 已完成。--Skyicecn1（讨论） 2020年8月19日 (三) 02:13 (UTC)

希望添加新的页面

hypixel这种全球知名的服务器居然没有吗？ 我想查一下hypixel里面Zombies中Dead End的手枪强化后的数据都没有。到处都找不到。–该未签名留言由117.44.229.151（讨论）在2020年8月10日 07:37 (UTC) 添加。请在您的回复后面加上 ~~~~

本Wiki的收录范围为原版内容（Mod内容正在逐步迁出），并不收录任何服务器内容。英文站我记得有一个收录服务器的Wiki，也许你想找的是那个。--  Lakejason0（论•功） 2020年8月10日 (一) 08:00 (UTC)

这里是Minecraft Wiki，不是Minecraft Server Wiki 。--  Dianliang233 ^T•_C 2020年8月10日 (一) 08:02 (UTC)

 拒绝：不在本Wiki的信息收录范围内。--葉月 桐§ 2020年8月10日 (一) 08:47 (UTC)

 拒绝：为什么不去FTB Wiki看看呢？36.161.160.35 2020年8月12日 (三) 12:44 (UTC)

如何回退文件？

我是个萌新，但我不知道回退图片文件。--  Duowan channel（论•功）2020年8月12日 (三) 04:39 (UTC)

图片-- Drlee lihr 讨论/贡献 2020年8月17日 (一) 01:23 (UTC)

是否有必要将已移除特性拆分为独立的页面

发现近期有用户将英文Wiki上已移除特性的相关页面搬运到了公共沙盒当中，准备效仿英文Wiki将其拆分成独立的页面，但这些特性大多都只存在了几个版本，可介绍的内容并不多，独立页面相较原有的已移除特性页面也并没有增加多少有效信息，似乎没有拆分的必要。而且英文Wiki上将这些特性拆分成独立页面的工作基本都是User-12316399一人所为。

我认为将这些信息保留在对应的已移除特性页面即可，不需要拆分。也请各位发表自己对此的看法。--葉月 桐§ 2020年8月12日 (三) 06:38 (UTC)

我觉得没必要。本来每个已移除特性的内容就不多，拆开的话内容可能“不足以支撑页面”。Sigma166（讨论） 2020年8月12日 (三) 09:58 (UTC)

 支持保留。--Skyicecn1（讨论） 2020年8月12日 (三) 13:17 (UTC)

 支持保留，因为会把内容拆得七零八落，不便于用户阅读。117.181.11.249 2020年8月13日 (四) 01:42 (UTC)

 中立偏向 支持保留，如果现在拆分出来的内容有更多的信息量，我认为可以合并回原来的页面。--  Lakejason0（论•功） 2020年8月13日 (四) 01:44 (UTC)（最后编辑于2020年8月13日 (四) 01:45 (UTC)）

 意见：个人认为拆分的标准在于单独页面的信息量是否足够。如果是都不够，那么我认为合并就可以了。如果一部分单独页面比目前合并页面的信息量更大，我认为可以拆分，并在合并页面的原段落加一个{{main}}。--  Lakejason0（论•功） 2020年8月14日 (五) 03:33 (UTC)

 中立偏向 反对保留，per below。--  Lakejason0（论•功） 2020年8月14日 (五) 10:13 (UTC)

 支持保留，看了一下，信息量根本不大，很多是一些滥竽充数的段落。个人认为存在信息量虚高的问题，应该合并回原来的段落。--  Lakejason0（论•功） 2020年8月14日 (五) 11:17 (UTC)（最后编辑于2020年8月14日 (五) 11:21 (UTC)）

 中立偏向 反对保留，因为如果不将Java版已移除特性拆分，那么每次搜索已移除特性（如拉娜、齿轮）时都会重定向到该页面，而该页面内容较多，加载时间长，且不全都是搜索者想要查看的内容，这对使用流量上网者不友好。--Ultim 0（讨论） 2020年8月13日 (四) 05:34 (UTC)

 轻微反对，可部分拆分，芍药、砖块变化、门的细节这些……就不用了。--RedLightPOP·讨论 2020年8月13日 (四) 05:53 (UTC)

 意见：可以拆分一些内容较多的特性，较少的保留。-- 北狐 2020年8月13日 (四) 13:48 (UTC)

 中立，但 偏向反对。一方面，主词条的确存在内容过多的问题，但另一方面，拆分又有可能会导致内容过于破碎，似乎更不易维护…？--Minesunset1030（讨论） 2020年8月14日 (五) 01:52 (UTC)

 反对保留来源en。--  Duowan channel（论•功） 2020年8月14日 (五) 03:11 (UTC)

“来自英文Wiki”并不是有效的理由，此话题讨论的本来就是是否需要仿照英文Wiki的做法。而且英文Wiki页面质量下降的现象多数用户都有所体会，万事都效仿英文Wiki的做法并非明智之举。--葉月 桐§ 2020年8月14日 (五) 03:18 (UTC)

 中立偏向 反对保留。部分有足够信息量的信息完全可以拆为单独的页面，这样易于读者查询信息。但有些纯装饰和旧想法就显得不必要单开个页面。（顺带一提，填“支持”的话不应该是“支持拆分”吗……）——Icyphantom 讨论I贡献 2020年8月14日 (五) 03:46 (UTC)

这边的预定假设是保留，所以大家都对保留提出意见。--  Lakejason0（论•功） 2020年8月14日 (五) 03:58 (UTC)

 反对保留，很多已移除特性在主词条的介绍太少，需要单独拆分出页面来。--ChemistChang（Talk/Contributions） 2020年8月14日 (五) 10:03 (UTC)

没有的内容照样可以合并回原来的段落。--  Lakejason0（论•功） 2020年8月14日 (五) 11:22 (UTC)

 支持保留。不符合关注度原则，然后就是页面内容少得可怜，不足以支撑起一个页面，何况还是过时很久的信息。不是说变成独立页面就一定是好事。--Lxazl5770_zh.admin（论 ▪ 功） 2020年8月14日 (五) 14:20 (UTC)

猪灵条目需要猪人信息

我看过en:Piglin里的历史了，有猪人详细内容。--  Duowan channel（论•功） 2020年8月14日 (五) 03:17 (UTC)

 拒绝。根据之前的讨论，我们已决定不加入猪人的信息。中英文Wiki的社区共识可能有所差异，请您不要将英文Wiki的做法全部应用到本Wiki当中。--葉月 桐§ 2020年8月14日 (五) 03:21 (UTC)

MC地下城Wiki微标需要优化

en比较流畅，zh比较粗糙。MC地下城Wiki微标需要优化并同步en。--  Duowan channel（论•功） 2020年8月14日 (五) 03:23 (UTC)

 已同步。另，中文Wiki的共识运作不应完全受到EN的干扰。--  Lakejason0（论•功） 2020年8月14日 (五) 03:31 (UTC)

关于内含文字的图片的繁简转换

目前，中文MCW上除去转换表、手动转换和{{SPConversion}}等繁简转换，对于图片内容里含有文字的繁简转换似乎不多。

目前有的繁简转换，其格式也大多为：

• 英文站的文件原名（重定向到简体）
• 英文站的文件原名+空格+Simplified（Category:汉化图像）
• 英文站的文件原名+空格+Traditional（Category:汉化图像）

部分图片的文件描述会相互提示简繁体。

目前存在的例子，比如File:DifficultyButton.gif、File:ArmorDamageFormula.svg、File:Smithing Table GUI.png、File:AdvancementsInterface.png、File:Subtitles.png等。

使用这些图片的方法也比较单一，就是在页面内部使用{{tr}}，分别插入两个图片。

目前的疑问是，是否有更便利的方式插入这些图片？是否需要进一步补全？是否将这些写入格式指导的图片和文件段落？又如何制作这些图片？目前个人做这些图片主要通过Snipaste来截取界面大小为2的游戏画面。希望大家能够一起商讨。--  Lakejason0（论•功） 2020年8月14日 (五) 03:54 (UTC)

恕我没有更多的时间参与讨论。如果该话题在存档之前都无任何进展，请将目前所做的一个模板正规化，谢谢。关于格式指导也请各位管理员帮忙写出。--  Lakejason0（论•功） 2020年8月19日 (三) 14:41 (UTC)

插入方式？

有关插入方式的回答和建议请在这里提出。--  Lakejason0（论•功） 2020年8月14日 (五) 03:54 (UTC)

直接tr算是最粗暴的方法——在有更佳替代方案的情况下通常不会直接用的。可能的话可以弄一个模板来实现，但要保证这个模板和插入文件的语法差不多。——Icyphantom 讨论I贡献 2020年8月14日 (五) 04:02 (UTC)

目前的问题在于，一部分标签内部并不支持简繁转换语法，比如<gallery>，以及原英文名的重定向没有使用。--  Lakejason0（论•功） 2020年8月14日 (五) 04:04 (UTC)

這樣應該可以--Leo_leo_768(Talk|Contributions) 2020年8月16日 (日) 06:10 (UTC)

这样写的话，直接写文字描述不会被转换。--  Lakejason0（论•功） 2020年8月16日 (日) 08:30 (UTC)

不过文字描述用{{tr}}似乎可以。但是{{Inventory slot}}的话……用{{tr}}写文字描述就不行。--  Lakejason0（论•功） 2020年8月16日 (日) 08:34 (UTC)（最后编辑于2020年8月16日 (日) 08:35 (UTC)）

手 動 轉 換 (-{}-)--Leo_leo_768(Talk|Contributions) 2020年8月16日 (日) 09:11 (UTC)

{{Inventory slot}}我只记得，描述部分只会原样输出任何文字（-{}-也一样）。--  Lakejason0（论•功） 2020年8月16日 (日) 09:22 (UTC)

我觉得可以写个模板来插入需要转换的图片。-- 北狐 2020年8月14日 (五) 09:13 (UTC)

我在我的沙盒中写了一个这种模板，试验了一下，应该可以满足需求。--RedLightPOP·讨论 2020年8月15日 (六) 12:58 (UTC)

|1=是文件名，不含名字空间。--RedLightPOP·讨论 2020年8月15日 (六) 13:00 (UTC)

进一步补全？

有关进一步补全的态度和建议请在这里提出。--  Lakejason0（论•功） 2020年8月14日 (五) 03:54 (UTC)

如果文字与图片内容相关的话则需要考虑。文字没影响的话则不太必要。——Icyphantom 讨论I贡献 2020年8月14日 (五) 04:02 (UTC)

将建立规范和制作方法写入格式指导？

有关此提案写入格式指导等页面的意见和建议请在这里提出。--  Lakejason0（论•功） 2020年8月14日 (五) 03:54 (UTC)

Lakejason0的提案

在MCW:文件中加入以下内容：

内容含有大量需要繁简转换的内容的图像应当上传两份，文件描述内相互注明繁简和[[:Category:汉化图像]]。为方便起见及保持名称的一致性，这类文件的各材质版本命名格式为{{cd|<图像原名称> Simplified.png}}和{{cd|<图像原名称> Traditional.png}}，其中{{cd|Simplified}}代表内含简体的图像，{{cd|Traditional}}代表内含繁体的图像，并建立{{cd|<图像原名称>.png}}到{{cd|<图像原名称> Simplified.png}}的重定向。

不知道写的怎么样，请大家提出意见。--  Lakejason0（论•功） 2020年8月21日 (五) 03:09 (UTC)

 赞成 Odyssey08 [ ^T /_C ] 2020年8月21日 (五) 03:25 (UTC)

这里的<图像原名称>指的应是Smithing Table GUI.png之类的名称。需注意的是，其并非直接在最后加入SimplifiedTraditional字样，而是在文件主名的最后、.的前面加入的。可对指导稍加修改以消除歧义。--RedLightPOP_讨论 2020年8月26日 (三) 20:28 (UTC)

关于一个有歧义的句子

在页面Joe Liu，有这样一句话:曾经是Mojang的一名前客户支持代理.。总感觉这句话是病句(因为语义重复了)，感觉意思像是:他现在是一名客户支持代理。

所以各位，改成“是Mojang的一名前客户支持代理”还是“曾经是Mojang的一名客户支持代理”好？我个人感觉改成“曾经是Mojang的一名客户支持代理”好一点。

我想听听你们的看法--冰川橘子（讨论） 2020年8月20日 (四) 12:43 (UTC)

依据讨论页方针移除不合适评论。（原作者要求）

关于版本页面格式

MCW:SG中规定了版本页面标题的格式，但无论是Java版还是携带版/基岩版的版本页面具体内容，格式都不尽统一。

问题主要出现在较旧版本页面中：

• 携带版/基岩版页面的{{Version nav}}格式不统一。
  • |title=的格式是v0.14.1、v0.13.2 alpha还是Alpha 0.14.1、Alpha 0.13.2（默认生成）。
    • 如MCW:社区专页#携带版Alpha版本名称问题所述，携带版Alpha 0.14.0以前的版本号为v0.x.x alpha，携带版Alpha 0.14.0及之后的版本号为v0.x.x。
    • 如果修改|title=会导致|protocol manual=需要手动更改（见MCW:社区专页#携带版Alpha版本名称问题），但是改成v0.14.1、v0.13.2 alpha却是更合适的（游戏内主菜单右下角如此）。
  • |date=的格式完全是随心所欲。
• {{Version nav}}后的“主要描述的介绍”中格式不统一。
  • 部分Java版页面的“主要描述的介绍”未指明是Java版，如Java版1.13.1。这里是Minecraft Wiki，不是Minecraft Java版Wiki。
  • 大部分携带版/基岩版页面的“主要描述的介绍”格式完全不统一。

在这之外，版本页面具体内容问题“不是很多”。

毕竟漏洞都没人翻译，最后都规定不用翻译了——于是旧版本的漏洞就真的没人翻译了，{{Fixes}}甚至默认折叠内容。{{Fixes}}的格式也未规范完善，导致了一定的混乱。

这些问题的出现的原因都是未在MCW:格式指导/版本中详细阐明。由于MCW:格式指导/版本并未完全适应中文Wiki的情况，且与也未完全同步，使得页面最上方的那个{{Msgbox}}非常可笑。

解决问题只需要完善MCW:SG及其子页面即可。--SkyE | Talk · Contributions · Logs 2020年8月21日 (五) 02:05 (UTC)

目前格式指导已经移除了“漏洞不需要翻译”。--  Lakejason0（论•功） 2020年8月21日 (五) 03:21 (UTC)

如果大家有时间的话，建议和上面的问题放一起重整一下格式指导。--  Lakejason0（论•功） 2020年8月21日 (五) 03:27 (UTC)

模块似乎可以这样转换：

version = '携带版v0.4.0 alpha rev 2'
version = string.gsub(version, '携带版v(0%.%d+%.%d+) alpha (%d+)', '携带版Alpha %1 alpha %2')
version = string.gsub(version, '携带版v(0%.%d+%.%d+) alpha', '携带版Alpha %1')
version = string.gsub(version, '携带版Realms alpha', '携带版Alpha Realms')
version = string.gsub(version, '携带版v(0%.%d+%.%d+)', '携带版Alpha %1')
--version现在是“携带版Alpha 0.4.0 rev 2”

还有一定容错率。（未必是件好事。）--RedLightPOP_讨论 2020年8月28日 (五) 16:19 (UTC)

是否应该将网易版的“新玩法”加入wiki？

好吧，我是新手……但是网易版已经加入了本wiki，算不算与Java版和基岩版同级的版本？如果是的，那么要不要把网易版的“天启之境”，“伙伴系统”算为“网易版特性”呢？网易版与其他版本价钱不一样，版本不同步，版本号瞎编，算不算独立版本？--112.23.187.225 2020年8月23日 (日) 01:04 (UTC)

本人持 反对意见。这些特性本质上不属于Mincraft本家的内容，更像是mod。--Minesunset1030（讨论） 2020年8月24日 (一) 06:12 (UTC)

 反对。我认为只需在中国版页面中注明即可。--Ultim 0（讨论） 2020年8月24日 (一) 08:50 (UTC)

关于版本文件格式

关于某些特性的文件命名规则有了，一些有关版本、更新、开发阶段的文件命名仍然千奇百怪。

菜单界面（较好）

• Java版正式版名称多为类似于Java Edition <版本号>.png的名称，但仍有少部分使用Release <版本号>.png的格式。
  • Java版的Beta开发阶段以前版本大多无菜单界面截图。
• 基岩版（携带版）正式版的名称多为Pocket Edition <版本号>.pngBedrock <版本号>.png，Edition时有时无，有些无版本号末尾的.0。
  • Alpha阶段大部分直接Pocket Edition <版本号>.png没有Alpha。

游戏内截图（一塌糊涂）

• 游戏内截图多为基岩版（携带版），且一塌糊涂。
  • 文件主名有MCPE<版本号><版本号纯数字>peMcpe<版本号纯数字>等格式，也有很长一串的，扩展名pngjpgjpeg各种都有。上传者即兴发挥？
• Java版有游戏内截图的大多是远古版。
  • 格式大多是<开发阶段> <版本号>.png，Pre-classic也有直接使用<版本号>.png的。

更新（中等）

• 大多是官方发布的某一版本的海报、Logo和一些具有代表性的游戏内截图等。
  • 有<更新名称>.png<版本前缀> <版本号>.png（无更新名称的版本）等格式，有不加空格的，也有加thePEBEposterbannerlogo等字样的。

建议：“菜单界面”和“游戏内截图”使用<版本全名> [标识]，“更新”使用<更新名|版本全名> [标识]，且写入MCW:SG。

另：Category:Mojang图像内文件较多，不便于查找，可否进一步细致文件分类？--RedLightPOP_讨论 2020年8月27日 (四) 05:10 (UTC)

携带版Alpha部分的截图全部都是我自行截图并上传的，所以格式是统一的。其他截图建议直接去和en对线。-SkyE | Talk · Contributions · Logs 2020年8月28日 (五) 07:53 (UTC)

告知 InPageEdit 插件使用者

请更新你们的资源调用地址为以下地址：

mw.loader.load("https://cdn.jsdelivr.net/npm/mediawiki-inpageedit@latest/dist/InPageEdit.min.js");

详细信息参见：InPageEdit_14-0-0

带来不便，敬请谅解。机智的小鱼君⚡ (给我留言✨) 2020年8月30日 (日) 17:10 (UTC)

拆分末路之地

末路之地页面在英文维基已被拆分为en:The End和en:The End (biome)两个页面，一个讲维度，一个讲生物群系。可以参考一下他们的做法，维度和生物群系在同一页面也挺乱的。

但不保证内容足以支撑页面。--RedLightPOP_讨论 2020年9月8日 (二) 12:15 (UTC)

 同意 但是en:The End (biome)仍在挂着wip模板，还是先不要动为好。--135ty_{議(Talk)/勛(Contribs)} 2020年9月8日 (二) 13:05 (UTC)

 同意。-- 北狐 2020年9月12日 (六) 07:11 (UTC)

关于notch

wiki里明确写了他删除了推特账号，但是模板里还留着。要删掉模板里的吗？(我记得这是受保护的，我也来不及登录，所以在此发问)--122.96.40.87 2020年9月10日 (四) 20:22 (UTC)

没必要。--117.71.48.151 2020年9月11日 (五) 07:21 (UTC)

另有人也推测账号会恢复，但是看起来不太可能。--117.71.48.151 2020年9月11日 (五) 07:38 (UTC)