Minecraft Wiki

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

了解更多

Minecraft Wiki
尚未注册？
注册
Advertisement
注册
Minecraft Wiki
Minecraft Wiki
6,591
个页面
分类: 存档
不转换

Minecraft Wiki:社区专页/存档7

< Minecraft Wiki:社区专页
登录以编辑
该页面是Minecraft Wiki:社区专页的存档页，请勿编辑该页面。

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

存档

重新整理模板{{Blocks}}的方块分类

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

讨论结果为 同意更新。

目前导航模板{{Blocks}}中已收录数百种方块，展开长度过长，且其目前的分类情况较为混乱，游戏每更改一次方块的生成方式，模板中的部分方块可能就要重新分类一次，如不注意维护很容易产生信息过期的情况，而且这也不利于玩家查找方块。建议重新整理此模板的方块分类。

为此，我已整理了一个新的导航模板（见此），相比原来的导航模板作出的修改如下：

  • 弃用原有的方块分类方式，以Java版的创造模式物品栏为基础分类，并按照玩家的思维稍加改动，避免分类属性交叉，查找方块更加方便。
  • 将整个导航拆分为默认折叠的四个部分，可以按照页面介绍的方块类型展开其中一部分，减少页面占用空间。

具体的分类细则及使用方法已写在文档页面当中，如对此模板的分类规则和使用方法等方面有建议可在此提出。--葉月 桐§ 2021年1月2日 (六) 04:21 (UTC)

 支持。--AblazeVase69188（讨论） 2021年1月2日 (六) 05:28 (UTC)
 建议：某些部分应按照种类（如冰、浮冰和蓝冰）排列在一起，而非按照英文首字母排列。--AblazeVase69188（讨论） 2021年1月2日 (六) 05:37 (UTC)
那就需要为这种特殊情况制定统一的排列规则，避免排列混乱。--葉月 桐§ 2021年1月2日 (六) 05:53 (UTC)
 建议：将每个分组下的方块优先按照加入游戏的时间排列，先加入者在前。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月2日 (六) 11:13 (UTC)
 反对：查阅方块加入历史的过程比较繁琐，更难维护，且存在方块在不同版本加入的时间差异等问题。--葉月 桐§ 2021年1月5日 (二) 14:15 (UTC)
 支持--Snow Dash（论 & 功） 2021年1月5日 (二) 18:01 (UTC)
 支持，此外“生物”改成“动植物”也许会好一点。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月6日 (三) 05:38 (UTC)
不用“动植物”是因为蘑菇等方块严格意义上属于真菌，而且还存在垂泪藤和缠怨藤这样的生物属性模糊的方块，这些特例不能很好地概括进去。--葉月 桐§ 2021年1月6日 (三) 06:34 (UTC)
 已完成，模板已更新，同时已使用机器人补充所有方块页面的模板参数。关于此模板的其他建议可在其讨论页上提出。--葉月 桐§ 2021年1月6日 (三) 09:05 (UTC)

跟进“中文MCW怎么变成了这个样子？”

在我自己的MediaWiki站点上，我最近添加了一些英文的系统信息。由于某些原因登出之后，发现也出现了相同的问题，即以Headeraccept-language: zh-CN,zh;q=0.9访问页面时，部分系统信息会变成英文，但<html>标签的lang属性依然是zh-Hans-CN。我的Wiki上只有有/en子页面的信息会变成英文。查看MediaWiki:Portal，发现也存在MediaWiki:Portal/en。个人认为这有可能是MediaWiki的漏洞。已知Headeraccept-language: zh-TW,zh;q=0.9没有问题。希望这些信息能够帮助给予一些该问题的Workaround。-- LakeJasonFace Lakejason0（论•功） 2021年1月2日 (六) 08:36 (UTC)（最后编辑于2021年1月2日 (六) 08:39 (UTC)）

已报告至Phabricator。-- LakeJasonFace Lakejason0（论•功） 2021年1月2日 (六) 09:13 (UTC)
经排查，问题来源为本Wiki自身页面错误。修复需要上报wiki主管或fandom helper。MysticNebula70 T  2021年1月2日 (六) 10:52 (UTC)

删除版本介绍页面中的“新内容一览表”

自Java版1.16快照更新起，有用户从英文Wiki的版本介绍页面当中搬运了“新内容一览表”，其形式为利用{{FakeImage}}和{{Inventory}}模板制作出的方块、物品展示列表。但此举并未经过讨论，当前的格式指导也并未写出任何有关此列表的编写规范。后来，英文Wiki移除了这些列表，相关讨论见此。

虽然中文Wiki保留了这些列表，但由于未加以规范，随着该列表被应用到越来越多的页面，其暴露出的问题也越来越多：

  • 部分方块（如细雪）没有物品形式，使用{{Inventory}}展示可能会误导玩家。
  • 部分生物（如幻术师）没有刷怪蛋，无法以刷怪蛋的形式展示。
    • 用刷怪蛋来表示生物也并不直观。
  • {{Inventory}}无法反映物品的材质变化。
  • 部分物品（如愚人节玩笑版本当中的物品）不适合收录到Autolink当中，这些物品通常也没有单独的页面介绍，放入列表会产生红链，难以维护。
  • 部分物品的不太重要的衍生形式（如装填了箭或烟花火箭的弩）有时也会加入到列表当中，似乎没有必要。
  • 部分加入很少新内容的版本（如20w14a）也使用了此列表，但空白较多，浪费页面空间。
  • 部分加入大量新内容的版本（如教育版1.0.27）使用此列表后显得极其凌乱。

综上所述，我认为这类列表不适合展示在版本介绍页面当中，加之很多用户在添加这些列表时往往会忽略一些细节问题（如不注意Java版和基岩版的特性差异、写错版本标题以及描述文字），常常出现错误，质量较差，因此我建议移除版本介绍页面当中的所有这类列表。相较而言，在指南和教程等页面上使用这类列表可能更加合适，可以考虑转移。--葉月 桐§ 2021年1月9日 (六) 12:43 (UTC)

 建议：
  • 在大型更新的页面（如下界更新、Java版1.16、基岩版1.16.0等）保留，而在开发版本（如20w06a、基岩版1.16.0.51等）移除。
  • 至于物品的衍生形式（如半满和全满的收纳袋之于空的收纳袋），可以考虑保留其基本形式（如空的收纳袋）。
  • 至于愚人节玩笑相关的物品，应待en的相关页面完善并在本wiki得到同步之后再考虑在相关页面加入{{Inventory}}。
  • 对于加入了大量内容的版本，私以为应当按照一定顺序排列（如物品的材料类型、在常规游戏中获得的先后顺序等）：
    • 一种物品的不同颜色、材料或变种形式（如各种颜色的染色玻璃、不同材料的工具以及锈蚀程度不同的铜块）应考虑以动画表示以减少其在列表中占用的网格，如。
以上。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月9日 (六) 13:11 (UTC)（最后编辑于2021年1月12日 (二) 14:25 (UTC)）
从我自己的角度来说，我真的看到有人会使用这种图来分享到底有什么新内容，因此我并不认为这个主意本身是坏的。但是的确，出现了一些维护问题，并且其实比你说的还多（尤其是繁简转换）。我偏向 保留，但是如果觉得真的不行，那我会坚持 转移。-- LakeJasonFace Lakejason0（论•功） 2021年1月10日 (日) 06:17 (UTC)
 支持移除，当然这种简介直观的形式确实也有它的存在必要。如果确实有需要，可以在Java版指南之类的地方放吧？--Snow Dash（论 & 功） 2021年1月10日 (日) 06:36 (UTC)
我也偏向 保留，但如果那些维护问题没法解决，那就最好 移除。--ChengBing（讨论） 2021年1月10日 (日) 08:24 (UTC)
个人倾向于将特性简介统一 转移至指南页面。MysticNebula70 T  2021年1月10日 (日) 09:22 (UTC)
 回应——我倒是不希望完全移除，因为其可以非常直观地让读者知道更新了些什么东西。最好是将其移动到别处或者保留一部分，而不是entirely removed。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月10日 (日) 10:45 (UTC)
 再次回应——如上述，我认为大型更新的版本记录（如Java版1.15）、更新主要内容页面（如嗡嗡蜂群）和版本指南等保留新内容一览表，其余页面包括愚人节版本全数移除。并写入格式指导。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月14日 (四) 05:22 (UTC)
根据以上讨论，即将移除所有开发版和非正式版页面上的列表，并将其转移到指南页面和更新主题页面当中。考虑到维护问题，正式版页面上的列表也将暂行移除，待格式指导将其规范化（如可能）后再恢复并完善。--葉月 桐§ 2021年1月14日 (四) 07:26 (UTC)

重新整理模板{{Items}}的物品分类

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

讨论结果为 同意更新。

受到Hatsuki kiri的启发，本人整理了一个新的导航模板（见此）。与新整理之后的{{Block}}同样，{{Items}}根据游戏内的创造模式物品栏重新归类，但有所改动：

  • 信息源和载具并入工具，装饰并入功能性，武器和盔甲合并为战斗
  • 杂项里新增矿物、动物子分类以减少原材料的物品数量
  • 烈焰粉、下界疣、龙息归为酿造；马鞍归为载具；药物归为功能性；金胡萝卜归为食物；酿造台和炼药锅（皆为物品形式）归为酿造
  • 移除了独立的仅创造、仅命令和即将归来子分类

最为重要的一点是，这样的分法避免了“其他”子类别（用于归类无法按常规归类的孤儿们）的出现。

对此模板的分类规则和使用方法等方面有建议可在下方提出，我需要各位的建议。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月12日 (二) 14:19 (UTC)

这是好的。（我在想为啥斧和镐锄隔了那么多桶，原来是按字母排的）--Ff98sha（讨论） 2021年1月12日 (二) 14:30 (UTC)
 回应现在的问题是如何重新定义“工具”（因为我觉得信息源和交通工具也算是工具一类），游戏里的工具给的定义非常狭小且不能进一步细分。其他的基本上无大碍。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月14日 (四) 05:16 (UTC)
如果没有人有异议的话过几天就会实施。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月23日 (六) 00:58 (UTC)
 已完成。后续讨论请新开话题。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月26日 (二) 06:29 (UTC)

关于同类索引条目的规范

虽然根据在社区专页达成的共识，中文Minecraft Wiki已经引入了同类索引页面，但是对于其规范尚有不明之处，故在此征询各位的意见：

  • 当与既有页面重名时，应如何命名同类索引页面？

在浏览中文维基百科时发现：对与其他条目重名的同类索引，中文维基百科一部分采用在页面名称后加注“索引”的方式（如wzh:试播集 (索引)），而另一部分仍沿用“消歧义”的后缀（如wzh:包青天 (消歧义)）。试问本wiki应采用哪种方式区分同类索引页面？

以上。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月12日 (二) 15:37 (UTC)

 回应现在看来似乎有很多消歧义要转为同类索引。我觉得同类索引不需要加上“索引”后缀，反而现在把所谓的“消歧义”转为同类索引才是首要工作。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月14日 (四) 05:12 (UTC)
以下是个人对“消歧义”与“索引”使用的看法。
  • 最好按照“消歧义”与“索引”的字面意思处理。
    • 说文解字，“消歧义”页面是为了对很可能产生歧义的页面进行区分的页面。而“索引”应该是将同类事物罗列在一起的页面。
  • 个人觉得，现在绝大部分的消歧义页面都改成索引，但对于非常容易产生歧义的，或由于译名更改而产生歧义的（eg:对于鱼来说，可能指生物鳕鱼，可能指物品鳕鱼，也有可能指其它的鱼，种子、金同理，但金只需要区分金粒、金锭或金块），即使对应页面做了区分（如鱼（生物））也需要建立消歧义。
  • 对于其他的（比如亡灵生物或灾厄村民）只需要改成索引即可。

--ChemistChang（Talk/Contributions） 2021年1月17日 (日) 15:44 (UTC) （最后编辑于2021年1月17日 (日) 15:44 (UTC)）

关于16种染料的独立页面

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

讨论结果为 同意合并。

16种染料不仅有综合页面（染料），同时还有各自独立的页面（白色染料、绿色染料、黑色染料等）。不同颜色染料之间仅有获取方式上的差异，用途基本完全一致。我认为保留各个颜色染料独立页面没有必要。可以全部整合进染料，而现状也基本是如此。是否可以将16色染料的页面合并到染料页面？ --Snow Dash（论 & 功） 2021年1月22日 (五) 15:03 (UTC)

 同意，其他有色物品（潜影盒、蜡烛、羊毛、玻璃等）都是写在一个页面中的，可以借鉴。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月22日 (五) 15:57 (UTC)
 支持。--XiaoXin666（T·C） 2021年1月22日 (五) 16:37 (UTC)
 支持如今青金石等的部分具有染色功能的物品已经被专门的染料取代了，我觉得是可以合并的。顺便合并之后我会去掉{{Items}}模板的染料子分类。--Lxazl5770zh.admin（论 ▪ 功） 2021年1月23日 (六) 00:46 (UTC)
 支持可以减少维护工作量。135ty（讨论） 2021年1月23日 (六) 03:05 (UTC)
重定向已完成，但有多个页面出现合成配方错误的问题。--葉月 桐§ 2021年1月23日 (六) 05:57 (UTC)
目前合成配方问题已解决。--葉月 桐§ 2021年1月23日 (六) 09:24 (UTC)

删除辅助程序与编辑器？

英文wiki已经建议把第三方程序的相关内容全部移动到ftb，其中包括辅助程序和编辑器（见此）。对于中文wiki，此举是否有必要？这些页面是否活跃，有人维护？有人阅读这些页面吗？--Dianliang233 2021年1月26日 (二) 02:17 (UTC)（最后编辑于2021年1月26日 (二) 02:22 (UTC)）

中文ftb无受众，转到ftb将更没人看。方法放寒假 (Talk - Contributions) 2021年1月26日 (二) 02:31 (UTC)
 反对，毕竟是辅助原版的辅助程序，我个人倾向于保留。应该还是有人会阅读，但维护确实很少。如果真的要移动的话最好保留一个软重定向。--Snow Dash（论 & 功） 2021年1月26日 (二) 03:23 (UTC)
 意见：辅助程序与编辑器与mod一样，不受Mojang等的支持，因此个人建议将这些内容全部移动至ftb，并保留软重定向。--Ultim 0 ( VIEW | TALK | CONT ) 2021年1月26日 (二) 03:30 (UTC)
那些辅助程序没记错的话一堆不见有人用的远古玩意，更别说维护了……这类玩意留这里也不见得有什么用，移过去也没什么影响。——IcyPhantom 讨论I贡献 2021年1月26日 (二) 03:35 (UTC)
 意见：建议保留。辅助程序与编辑器也不是没有人用，所以可能需要这些页面，但是要删去多数版本过旧的辅助程序与编辑器。--AblazeVase69188（讨论） 2021年1月26日 (二) 09:47 (UTC)

基岩版标签

基岩版beta1.16.100.56中加入的查询器query.any_tag和query.all_tag可查询方块或物品的标签
即：基岩版有方块和物品标签
但至今ID_table模板仍无基岩版标签参数
是否会考虑加入？
链接列出了一些Miemiemethod在源码找的方块标签
方块标签（这个页面是我水的
2190303755(T|C) 2021年1月28日 (四) 07:53 (UTC)

自己看着办吧--Lxazl5770zh.admin（论 ▪ 功） 2021年2月5日 (五) 14:39 (UTC)

对15w44b页面修改被撤回的异议

在末地烛的页面已经有提到在快照15w44b中加入了末地烛的合成配方，所以我认为在15w44b中加入这个应该没啥问题，这与后文并不算冲突，前半句话是阐述末地烛合成配方被加入的事实，后半句话是合成的结果，删去可能会失去在15w44b新加入的语义，望15w44b/更改/方块/末地烛 更改为“加入了末地烛的合成配方，每次合成产出4根。”–该未签名留言由Hanpi3626（讨论 • 贡献）在2021年2月5日 (五) 12:14 (UTC) 添加。请在您的回复后面加上 ~~~~

“现在可以由底部放置爆裂紫颂果，顶部放置烈焰棒来合成。”这句话就已经表示加入了新的合成配方，后面再补一句会显得信息重复，没必要。另外，这种只涉及小改动的话题请直接到对应的讨论页或相关用户的讨论页上发布。--葉月 桐§ 2021年2月5日 (五) 12:27 (UTC)

在页面的“现在可以由底部放置爆裂紫颂果，顶部放置烈焰棒来合成。”这一句话只是说明的是这个物品的性质，如果是要这么说的话那也可能说明这是在添加合成配方之前增加的性质，您说是不是这个理？而且，这也说明了末地烛拥有合成配方的时间。Hanpi3626（讨论） 2021年2月5日 (五) 14:08 (UTC)

我已经修改了原文以迎合你表达的意思。注意源代码里星号*表达的从属关系。按照逻辑应该是先叙述是否存在配方再叙述如何合成，两者本来是递推关系，如果先叙述合成配方再叙述是否有这么一个配方就显得混乱而且不符合直觉。此外，社区主页不应该用于汇报编辑问题，请到对应页面下的讨论页或者执行者的讨论页进行留言。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月5日 (五) 14:37 (UTC)
此外，你说的“现在可以由底部放置爆裂紫颂果，顶部放置烈焰棒来合成”这句话不是末地烛固有性质，这句话仅仅只是在叙述它的合成配方。性质应该随事物的出现而同时出现，或者消失时同时消失（简单点说性质是与生俱来的）。显然此处的合成配方是之后加上去的，这就谈不上什么性质了。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月5日 (五) 14:44 (UTC)

Java版数据值需要更新？

英文Wiki跟中文Wiki不统一，Java版数据值需要更新，Minecraft Wiki:沙盒/Java版数据值。211.140.201.9 2021年2月5日 (五) 15:39 (UTC)

等你学会了怎么签名再来说话。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月5日 (五) 13:20 (UTC)
自己动手丰衣足食，勿问“为什么没有oo？”。--Ultim 0 ( VIEW | TALK | CONT ) 2021年2月5日 (五) 14:53 (UTC)

编辑问题

能否在中文Wiki添加有可靠依据但没有英文Wiki上出现的修改？[Wiki小萌新]DSDlonDTX 2021年2月9日 (二) 09:36 (UTC)

可以。如有能力可以把信息也补充到英文Wiki上。--葉月 桐§ 2021年2月9日 (二) 08:12 (UTC)

关于版本页面问题

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

讨论结果为 按照Miemiemethod的方案进行更新。

如题，旧事重提。携带版/基岩版的历史版本页面格式较为混乱，一直没有得到妥善解决。

在和Miemiemethod进行讨论后，于MCW:SG和MCW:SG/V的基础上在此提出一些方案。讨论完后将会写入MCW:SG/V中。

此外，MCW:SG/V本身也不够完善，希望能够进一步改进。

这些页面共同的问题有：

  • 大多数版本页面的“修复”段落没有具体内容（或未被翻译，不显示），也没有使用{{Fixes}}模板（Java版等其他版本也存在这种情况）。
  • “介绍”段落的第一句话，如“Beta 1.16.210.58是基岩版1.16.210的第8个开发版……”等前的“Beta”和“Alpha”首字母是否要大写
    • 有些页面没有大写。而由于英语的语言习惯，en全部都大写了。
  • 仍然需要补全菜单界面的截图。

关于标题等内容的格式：

  • Miemiemethod的思路是，“版本号是为了区分的”，建议对区分无用的部分全部都删掉，并且建议直接按照AndroidManifest.xml中的内容进行命名。
  • 我的思路则是尽量参照游戏内显示的版本号原文进行命名，毕竟Mojang写在没人看的地方（例如Microsoft Store等）的格式真的是千奇百怪。
  • zh的现行方案，既没有完全按照游戏内原格式，也没有完全抛开游戏内原格式，而是对游戏内原文进行一定变形，显然不够恰当。
  • en的现行方案完全参照游戏内原文。

携带版Alpha

年久失修。

标题可使用如下几种格式：

  1. 携带版vx.x.x[.x] alpha[x][build x]（游戏中如此，en使用方案，zh经过我填海的页面行文也使用此方案）
  2. 携带版Alpha x.x.x[.x][（x）][build x]（zh现行方案，括号建议改为半角）
  3. 携带版x.x.x[.x][build x][(【内部版本号】)]或携带版x.x.x'[.x][build x][_Rev]（Miemiemethod的方案）

相关文件的标题也可整理为这种格式，如en就将菜单界面的截图标题全部更改为File:Pocket Edition vx.x.x[.x] alpha[x]的格式。

相应地，{{Version nav}}的|title=参数也需要进行更改，|protocol_manual=也受其影响。

页面内当时使用旧版材质的物品、方块和实体等前可加入渲染图，参见Java版历史版本页面的格式。

携带版正式版

目前没有发现显著的问题存在。

现行格式为游戏内原格式携带版alpha x.x.x.x和携带版x.x.x。

en把形如“携带版x.x.x”的页面中{{Version nav}}的|title=参数前全部都加上了v，这也是游戏内原文导致的。

Miemiemethod的方案是去掉alpha和v等。

基岩版

同上，Miemiemethod的方案是建议去掉beta等。

鉴于时间仓促和个人能力有限，可能有特殊情况和其他问题没有列出。--SkyE | Talk · Contributions · Logs 2021年2月9日 (二) 16:03 (UTC)

 附议，我建议只保留“xx版”及其版本号，示例“基岩版1.16.210.58”及“携带版0.2.1_Rev”、“携带版0.10.0.b9”；同理，就算携带版Alpha_0.2.0要拆分，也可以拆成“携带版0.2.0”、“携带版0.2.0_Rev”、“携带版0.2.0_j”和“携带版0.2.0_Lite”。“Alpha”、“Beta”及不必要的括号、空格都可以去掉。方法放寒假 (Talk - Contributions) 2021年2月9日 (二) 16:36 (UTC)
方案给的实在太多了……这样看下来我也只能给 中立了。-- LakeJasonFace Lakejason0（论•功） 2021年2月9日 (二) 16:39 (UTC)
 支持MysticNebula70所描述的方案。-- LakeJasonFace Lakejason0（论•功） 2021年2月12日 (五) 09:05 (UTC)
个人 反对支持删除前缀alpha和beta，因为这些前缀可以明确地表示该版本是开发版，并不是多余的便于查找和输入；其余方案保持 中立。--XiaoXin666（T·C） 2021年2月10日 (三) 05:18 (UTC)（最后编辑于2021年2月11日 (四) 09:41 (UTC)）
前缀alpha和beta并非开发版的代表，但是我不想就这个观点进行争论。就算二者是开发版的代表，加与不加不会造成任何混淆，因为没有两个版本拥有相同的版本号但是一个带beta一个不带；并且，开发版与否可以直接看Infobox内以及第一段段首第一句话，标题带着beta不仅累赘（不便于查找和输入），而且和页面内信息重复，而且没有起到任何和其余版本区分的作用（因为加与不加两个版本都能区分开，就算某个正式版与某个测试版区分，他们最大的不同也是版本号不同而非有没有beta）。因此 反驳你的观点。方法放寒假 (Talk - Contributions) 2021年2月10日 (三) 12:21 (UTC)
 确实，前缀alpha和beta没必要保留，是我思虑不周，感谢你的反驳。--XiaoXin666（T·C） 2021年2月11日 (四) 09:41 (UTC)
 支持--RealCuervo（讨论） 2021年2月10日 (三) 12:45 (UTC)
我个人 同意Miemiemethod的方案。希望能够就此方案进一步完善。 --SkyE | Talk · Contributions · Logs 2021年2月10日 (三) 14:49 (UTC)

总结一下上述方案：

  • 携带版版本应加前缀“携带版”。例如，“0.9.0”应被命名为“携带版0.9.0”。
    • 携带版开发版本应先加上前缀“携带版”，然后加上相关说明字样。例如，“0.9.0”的第二个开发版应被命名为“携带版0.9.0.b2”。
  • 基岩版版本应加前缀“基岩版”。例如，“1.2.0”应该使用“基岩版1.2.0”这个标题。
    • 基岩版开发版本应先加上前缀“基岩版”，然后加上版本号数字。例如，“1.5.0”的第一个开发版本应被命名为“基岩版1.5.0.0”。

为方便查找，现行命名作为重定向处理。如有其他意见请提出。MysticNebula70 T  2021年2月11日 (四) 02:48 (UTC)

 意见：
  1. Alpha和Beta等建议首字母大写，毕竟是称呼开发版本版本号的特有用语，不是一般英文单词。
  2. 对于基岩版各版本的标题， 同意直接参照游戏内格式进行命名，要不然太乱了。
  3. 对于基岩版开发版本标题的命名， 支持去掉Alpha和Beta等英文，便于输入与查找。
对于其余方案则保持 中立。--AblazeVase69188（讨论） 2021年2月11日 (四) 08:57 (UTC)

Dianliang233的提议

我个人强烈 反对上述所有方案（除“携带版”“基岩版”前缀）。

我提议：按照en的命名方案，严格跟随游戏内命名。

游戏内命名可以消除绝大多数歧义：这样的命名方案不但不会消除潜在的错误认知，而且使玩家的资料查询变得无比便捷。游戏内写什么，他们就搜什么，这种方案最为直观，符合人类的认知习惯。玩家也不需要在根据“wiki的命名”和“Mojang的命名”之间做毫无必要的犹豫。

若您认为我的这些观点毫无逻辑，那么请问一个版本的标题不是版本在游戏内的命名有何意义！？

以上。-- Dianliang233 T•C 2021年2月12日 (五) 11:58 (UTC)

首先要明确游戏内版本到底是哪一个版本，如果按照游戏内右下角，所有的beta和alpha都将被去掉。如此图，游戏内版本应该是v1.16.210.59。en目前所有的携带版版本页面标题都带着“v”前缀，但是基岩版都没带，但是所有的版本v前缀都是存在的。
Bedrock 1.16.210

如果你认为顶部显示的是游戏内版本，首先第一点就是正式版并没有那个东西；第二点是，beta虽然搁那儿了，虽然和版本号挨着，但是它是不是“版本”的一部分都有待争议，因为alpha也曾经在这个位置，当时没有进入beta阶段，那么alpha是否属于版本的一部分也有待争议。如果认为beta是测试的意思，那alpha应该也是测试的意思，但是按照en的命名方法，所有的携带版前缀都有alpha，但是基岩版只有测试版有beta前缀，这是不是一种矛盾？如果认为alpha是开发周期，那么在某个时刻Mojang用beta字样取代了同位置（在顶部的那个）alpha，那么beta是否也是开发周期？大多数人不苟同，那么又出现了矛盾。

好，就算我们不考虑矛盾，返回“游戏内版本”的问题，以顶部字样作为游戏内版本只能对测试版适用，但是测试版和正式版右下角都有版本号，所以以右下角版本作为游戏内版本号倒是可以对所有版本适用，那就算所有的版本条目的标题都改成“基岩版/携带版v1.xx.xx”，beta和alpha字样也是不应该出现在标题内的。但是很明显v是version的缩写，本身肯定不是版本号的一部分，因为version 1.xx.xx就是“版本1.xx.xx”的意思，你应该不觉得“版本1.xx.xx”中的“版本”是“版本号”的一部分吧。那么标题是不是应该为“基岩版/携带版1.xx.xx”其中最后那个1.xx.xx是游戏内右下角v后面的东西

好，再退一步，就算不考虑游戏内版本，你所说的“按照en的命名方案，严格跟随游戏内命名。”，可以明确的是en根本就没有严格按照游戏内命名，上面的文字已经说了好几个en命名的矛盾之处，这也是本次讨论为什么会展开的原因。那么单从版本号分析的角度来看，以“有没有出现在标题中的意义”为角度切入，也是所有的alpha、beta和v以及括号、空格都不应该存在在版本号中，虽然存在也有一定意义，但是意义不大，没有大到缩短标题能带来的受益程度大。目前标题长而冗杂，按照你说的确实能在一定程度上帮助人们找到标题，但是大部分时候是找不到标题的。我个人是习惯直接用地址找页面而非搜索功能的，深知少一个空格，打错一个字母，多一个空格，或者想找“基岩版beta 1.16.210.59”结果输入了“基岩版v1.16.210.59”或者“基岩版1.16.210.59”萌新发现找不到页面时多么无措。你说用搜索功能不就好了？那么就算标题换成“基岩版1.16.210.59”，搜索功能不依旧有用？甚至没有了各种前缀后缀，搜索效率不更高吗？

综上， 驳回。方法放寒假 (Talk - Contributions) 2021年2月12日 (五) 12:25 (UTC)

我 同意Miemiemethod的论述。

首先，这里是Minecraft Wiki，不是Minecraft Java版 Wiki；既然Wiki上Java版的快照页面标题能够删去“Java版”这一多余元素，携带版/基岩版/教育版版本页面的标题命名虽然无法删去“携带版/基岩版/教育版”，但是多余的其他任何元素都可以删去。繁则同繁，简则同简；如果携带版/基岩版/教育版的版本页面名称不能得到有效简化，请把Java版的快照前加上“Java版”——为什么Java版的快照不命名成“Java版Minecraft 21w06a/snapshot”？

而Dianliang233提出的论点“玩家也不需要在根据‘Wiki的命名’和‘Mojang的命名’之间做毫无必要的犹豫”，试问平日里玩家沟通的时候有谁会带着“Alpha”和“Beta”吗？简而言之，玩家不会去在意Mojang到底是怎么命名的，没有普通玩家会一字不落地记下Mojang的命名规则。这和译名标准化有一定意义上的不同。

根据我之前提出的方案列表，我认为目前只有两条路可走：

  1. 依照游戏内显示的名称，帮en改正错误的命名并且应用到zh。
  2. 采用Miemiemethod的方案。

--SkyE | Talk · Contributions · Logs 2021年2月12日 (五) 12:57 (UTC)

相关内容已经写到en的社区专页。--SkyE | Talk · Contributions · Logs 2021年2月14日 (日) 08:07 (UTC)
我 同意Miemiemethod的方案。另外插一句，现在Java版Alpha（客户端）里面也有前导的"v"（现行的Alpha（客户端）与其他的都不一样），是不是也可以考虑去掉一下。 Anterdc99Face Anterdc99（论·功） 2021年2月14日 (日) 08:25 (UTC)
 同意Miemiemethod的方案。玩家们平时交流也就只说1.16.100.56，没有谁会@他说他没加beta。上wiki搜要自觉加个基岩版也就算了，问题是这样子还是搜不到（要做基岩版后面加beta_）。版本号是拿来区分版本的，不是拿来为难玩家的。删除beta_不但不会影响玩家的认知，而且使玩家的资料查询变得无比便捷。Miemiemethod的方案最为直观，玩家也不需要在标题格式上做毫无必要的犹豫。--2190303755(T|C) 2021年2月15日 (一) 15:29 (UTC)
 同意Miemiemethod的方案。但对于0.15.0和0.16.0的开发版本，游戏右下角显示的版本号是没有build之类的单词的，只显示数字、.和v，如携带版Alpha 0.16.0 build 2显示为“v0.15.90.1”，我认为它应该被命名为“携带版0.15.90.1”，其余类似。--RedLightPOP讨论 2021年2月17日 (三) 10:39 (UTC)

手机版页面

手机版的页面跟之前不一样了 发生了个什，有懒人包吗？101.12.85.96 2021年2月12日 (五) 08:28 (UTC)

请指出具体页面。- Olvcpr423 Oak Sign JE2 BE2 / Book and Quill JE2 BE2 2021年2月12日 (五) 13:15 (UTC)
如果你是指“手机版视图”，请见此页面。该功能尚在测试中，所以会有一些问题。- Olvcpr423 Oak Sign JE2 BE2 / Book and Quill JE2 BE2 2021年2月12日 (五) 13:24 (UTC)
Gamepedia职员目前已经导入FandomMobile的CSS。部分CSS可能已经修复。-- LakeJasonFace Lakejason0（论•功） 2021年2月13日 (六) 04:08 (UTC)
什么懒人包啊--Lxazl5770zh.admin（论 ▪ 功） 2021年2月14日 (日) 23:30 (UTC)
就......懒人包ㄚ.w.--61.224.171.83 2021年2月16日 (二) 17:38 (UTC)

关于编辑的问题

请问基岩版开发版本中洞穴与山崖的更新内容属于1.17.0还是1.16.210？编辑时应该写[新增：BE 1.16.210]还是[新增：BE 1.17.0]?

目前wiki上大部分都是1.17.0，少部分是1.16.210（例如矿石、熟羊肉）。Wangruiheng（讨论） 2021年2月18日 (四) 12:29 (UTC)

鉴于1.16.200的开发版中加入的洞穴与山崖特性在1.16.200正式版中不可用，结合Mojang官方人员的推文（见此），可以推测1.16.210很可能也不会实装这些特性。所以1.16.210中加入的洞穴与山崖特性应用[新增：BE 1.17.0]标记，其他特性用[新增：BE 1.16.210]标记。--葉月 桐§ 2021年2月18日 (四) 12:55 (UTC)

用户页不见了

如题，今天在wiki瞎逛游时发现只能看到自己的用户页，而他人的用户页则显示“此用户还没有填写个人资料页”，并且登出后发现自己的用户页也没了。

所以想问一下是出了啥问题（不会是大家都把用户页删了吧）。

Sigma166（讨论） 2021年2月19日 (五) 07:41 (UTC)

已知问题，fandom正在修复中。--Snow dash（论 & 功） 2021年2月19日 (五) 08:15 (UTC)
啊好像修好了(((Sigma166（论/功） 2021年2月23日 (二) 14:08 (UTC)

关于rd-131655（Cave Game Tech Test）之前的“版本”

rt，我认为rd-131655之前的“版本”只是一些小改动，它们根本就没有发布给任何人，也没有明确的证据证明它们是独立的版本，Notch也仅仅在IRC上简单提及了它们的改动内容，所以，我认为这些所谓“版本”根本不能算是版本。这些内容应当合并到rd-131655中，并在一个子标题中描述这些改动。顺便说一下，在英文Wiki中，这些“版本”的“更新”内容都已经被合并到了rd-131655的页面中。--KisinSagume286（Talk!/Contribs...） 2021年2月19日 (五) 14:50 (UTC)

 赞成。前面的“版本”介绍中只有“性能提升”，一不足以支撑页面内容，二更像Notch在调试程序。Sigma166（讨论） 2021年2月20日 (六) 00:41 (UTC)
 可以：将多个较短的页面合并成一个页面有利于维护。--Ultim 0 ( VIEW | TALK | CONT ) 2021年2月20日 (六) 00:46 (UTC)
 赞成，前面几个版本页面太短了，合并更有利于阅读。Wangruiheng（讨论） 2021年2月20日 (六) 02:00 (UTC)

好的。目前已经完成对rd-131655之前“版本”内容的合并。--KisinSagume286（Talk!/Contribs...） 2021年2月20日 (六) 03:02 (UTC)

Java版alpha版本“v1.2万圣节更新”界面“历史”条目不全

似乎这些原始版本的“历史”条目存在这个问题，建议应完善这些内容，引入专门的模版，谢谢。(awa)--Cobalt sayori（讨论） 2021年2月20日 (六) 07:57 (UTC)

上传文件前先阅读注意事项！--Lxazl5770zh.admin（论 ▪ 功） 2021年2月20日 (六) 10:57 (UTC)

关于本人编制的“教程/征服堡垒遗迹”能否发表到教程中

这一教程已经编制完毕，本人认为值得发表，但具体能否达到发表要求还有待商榷，也烦请大家帮忙看一下，好吗？--Cobalt sayori（讨论） 2021年2月22日 (一) 04:08 (UTC)

你写好就可以移动，实际上不需要别人的意见。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月22日 (一) 04:13 (UTC)
谢谢提醒，但是移动完成之后我没有权限删除原先界面，因此可能还需要一些调整，谢谢--Cobalt sayori（讨论） 2021年2月22日 (一) 05:42 (UTC)
不需要的移动残留重定向可以加上{{delete}}，会有人处理。--Snow dash（论 & 功） 2021年2月22日 (一) 07:00 (UTC)

本人愿意承担“教程/陷阱“篇目的修改工作

有关“教程/陷阱”篇目，存在大量的不妥当因素，需要进行一系列修改。 具体原因在于：

  1. 本教程是针对于多人联机中其他玩家的陷阱，但篇目中存在很多针对于生物的内容，这些内容对于玩家基本上没有用处。
  2. 对于掉落物的收集，仍需要完善。
  3. 建议通过陷阱的作用进行重新排版。

谢谢大家的帮助！--Cobalt sayori（讨论） 2021年2月22日 (一) 06:51 (UTC)

除大量更改以外，合理的编辑不需要在社区主页请求共识，直接编辑即可。--Snow dash（论 & 功） 2021年2月22日 (一) 06:57 (UTC)

关于21w07a中对矿物的材质更改

21w07a更改了主世界中铁矿石、金矿石、煤炭和红石的材质，是否有必要将这些修改后的材质添加到wiki条目中，或者仅仅添加相关的截图？--Cobalt sayori=钴子 2021年2月23日 (二) 13:58 (UTC)

添加到历史段落。请不要在社区专页滥发小问题（这样会被禁言，你已经连续水了五个帖了！），请到Wiki QQ群向群友咨询。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月23日 (二) 14:05 (UTC)
抱歉，但我好像已经不在wiki的qq群了，稍后我会甩一个申请到群里，谢谢，另外，以后这些小问题我也不会再往这里发了，谢谢。--Cobalt sayori=钴子 2021年2月23日 (二) 14:08 (UTC)

“进度”页面的列举部分更改为列表

如题，论理由的话：en如此。tooltip只能在鼠标悬浮时显示，查看起来很不方便，也不易于复制、点击里面的内容。更改成列表可以方便玩家查看，同时可以查阅其中的内容。

若同意此方案的话，存在的问题是：

  • 如何插入这个列表；
  • 现在的模板在放入列表时会因“字数已达上限”出错，需要在哪些地方优化这个模板。

以上。——IcyPhantom 讨论I贡献 2021年2月24日 (三) 16:25 (UTC)

 支持，列表可以以表格或html列表的形式配合{{ItemLink}}和{{BlockLink}}来显示；达到上限只能考虑拆分成子页面，但请注意和{{load advancements}}的兼容性，避免无法识别。这两问题应该都能参考en吧？顺便，严肃场合个人建议不要用删除线--Snow dash（论 & 功） 2021年2月24日 (三) 16:31 (UTC)

重构{{SPConversion}}与Module:SPConversion

由于简繁的地区翻译差异，我们有转换表，用于自动地将文章内的词汇更换为简体/繁体用户所熟悉的词汇，以提升阅读体验。但是，部分词汇转换的使用量低，或者词汇太长影响转换效率，因此Leo leo 768制作了模块Module:SPConversion（模板同名）。但目前，这个模板的默认输入是简体文本，由于游戏文本可能产生变化，这种输入方案可能会导致大量不必要的更改来修复。并且据反馈，该模块目前的代码品质不够高。考虑到目前此模块主要用于来源为游戏内文本的转换，提出以下提案：

  • 将模板当前的匿名参数输入改为游戏内的本地化键名。使用ID有利于维护语言中立，即所有编者都可以较为方便地使用转换，而不需要刻意的都去使用简体文本，且本地化键名较为固定，可以减少因游戏内文本变化而导致的大量改动。
  • 仍然保留|type=的同等功能参数。由于这个模块实际上也用于故事模式的转换，而故事模式的文本实际上并不存在游戏内id，也不可能把这些页面内的文本全部替换成输入id的形式（源代码层面很影响观感），所以仍然有必要保留。此外，部分教程页面不存在嵌入的需求，而在页面内反复使用模板又很累赘，所以仍有必要保留。

此讨论由Snow dash、MysticNebula70和我个人在私下提出，现放在社区专页征求共识。-- LakeJasonFace Lakejason0（论•功） 2021年2月17日 (三) 04:00 (UTC)（最后编辑于2021年2月17日 (三) 04:09 (UTC)）

我们希望将模板改为通过{{sc|本地化键名}}的方式调用，输出繁简转换。包含字幕与统计相关字符串，因此主要用在音效段落等相关位置。现有的调用使用机器人批量转换为上述调用。
顺便也会改一下模块名字，我个人认为SpecialConversion可能会更好--Snow dash（论 & 功） 2021年2月17日 (三) 04:58 (UTC)
引用本地化键名可能 不直观，在语义上也不通畅，能做到英语输入中文变种输出是不是更方便，也可以和当前的autolink一同更新。--RealCuervo（讨论） 2021年2月18日 (四) 14:08 (UTC)
考虑到{{sc}}的使用场合，个人认为引用本地化键名并不存在太多语义上的问题。例如用量最多的音效段落，其使用方式为模板{{sound table}}的一个参数，使用本地化键名并无不妥。不存在键名的场合也不需要随用随调的情形，而是采取类似于-{H|...}-的方式将需要转换的文本全部包含进来，也无需输入英文名称。而且使用英文名称反而存在更新不够及时以及维护更麻烦的问题。MysticNebula70 T  2021年2月19日 (五) 16:37 (UTC)（最后编辑于2021年2月19日 (五) 16:40 (UTC)）
进度：沙盒中的Module:Sandbox/SpecialConversion基本完工，支持Java版1.16.5所有游戏内字符串，快照数据模块分开维护，有报错分类，输入本地化键名使用。但暂时还没有页面内全局转换。--Snow dash（论 & 功） 2021年3月1日 (一) 09:17 (UTC)
进度2：模块已基本成型，页面内全局转换也加入，没有高消耗的反查。--Snow dash（论 & 功） 2021年3月3日 (三) 12:13 (UTC)

InPageEdit使用满意度小调查

大家好，我是小工具inPageEdit的开发者，当初自用的小插件如今被这么多人使用这么多次，承蒙大家厚爱了！

为了更直观地获取InPageEdit使用方面的反馈，方便后期开发维护，特此邀请ipe的使用者，耽误大家大约3分钟的时间，来填写一个问卷，问卷采取匿名形式，内容绝对不会用作商业用途。

→ https://www.wjx.cn/vm/mtTpOXX.aspx ←

再次感谢大家，鞠躬。 机智的小鱼君⚡ (给我留言✨) 2021年2月20日 (六) 05:25 (UTC)

箱子战利品

对于箱子战利品来说，Java版和基岩版有完全一样的部分（比如下界要塞），但是战利品部分中仍然将Java版和基岩版分开说，是否应该合并以去除重复？（但这玩意好像涉及到模板，因此我需要帮助。）Sigma166（论/功） 2021年2月23日 (二) 07:48 (UTC)

 同意我个人认为，同样的模版确实影响观感，如果要修改模版的话，建议可以翻阅编辑手册--Cobalt sayori=钴子 2021年2月23日 (二) 07:55 (UTC)
 反对，技术问题，加判断、修bug带来的人力消耗换来的只是合并表格，非常不划算。--Snow dash（论 & 功） 2021年2月23日 (二) 08:46 (UTC)
额人力消耗嘛……我倒是可以找时间搞（可是我不会啊啊啊——）那就等我会了再说吧。Sigma166（论/功） 2021年2月23日 (二) 14:13 (UTC)
 拒绝——根据现有{{LootChestItem}}模块代码，不能实现Java版和基岩版分开。重构是一件非常麻烦的事情。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月26日 (五) 01:20 (UTC)

各个版本“修复”部分中的链接

在本wiki的各个版本介绍页面中，有小部分页面在“修复”部分添加了链接（比如18w43a、12w06a），而大部分页面并没有。本人现有如下想法，并征求大家的意见：

  1. 将所有版本介绍页面中的“修复”部分添上链接（艰巨的任务）
  2. 将所有版本介绍页面中的“修复”部分删去链接（为保持一致并减少工作量）
  3. 不做改动，保持原状（省事是省事，就是看着别扭）

个人 支持1，在“修复”部分添加链接有利于读者更便利地了解该版本修复的内容。

“

带着兴趣直接跳转到一个子段落的读者必须依然能找到一个链接。

”
——格式指导

Sigma166（论/功） 2021年2月26日 (五) 00:52 (UTC)

你说的链接是指访问官方漏洞追踪器的链接吗？但是我点进去18w43a的链接只会显示“No issues were found to match your search”，毫无用处。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月26日 (五) 01:17 (UTC)
不不不，就是最普通的内链（[[xxxx]]的形式）。Sigma166（论/功） 2021年2月26日 (五) 01:21 (UTC)
这个任务可能相当的艰巨，因为需要补充的链接太多，而补充链接的过程也相当麻烦，个人 支持2--Cobalt sayori=钴子 2021年2月26日 (五) 01:25 (UTC)
快照少的也有两三个漏洞，多的可能有二三十个--Cobalt sayori=钴子 2021年2月26日 (五) 01:26 (UTC)
可加可不加，要好好利用页面顶部的搜索栏。但是要记住插入过多内链是不允许的（斑驳的颜色导致阅读问题）。--Lxazl5770zh.admin（论 ▪ 功） 2021年2月26日 (五) 01:28 (UTC)

因为最近我一直在做漏洞列表相关工作，所以我来说明一下具体情况：

  • 一般来讲，最近依据漏洞补全计划补全的（我编辑的）并且使用了fixes模板的漏洞列表，列表全文一般没有链接，有链接的属于少数情况。
  • 较老的列表（1.4以前）的，一般都有。当然这是从英文wiki带过来的情况，所以我在翻译的时候也保留了这些链接。
  • 还有一些以前其他贡献者翻译的内容，其实存在大量这样有链接和无链接混合的情况，还有模板使用不正确的问题（就比如Lxazl5770在18w43a遇到的情况一样，是fixes模板使用不当导致的）。

至于你提出的选项，我个人 支持2或者是3。因为如果要全部加上的话，少说几百个版本页面中的内容都要修改。
且大多数版本中修复的漏洞大约有30-40个，甚至多的会有70+，另外还要算上主要更新版本（例如：Java版1.8），这些版本的漏洞修复列表往往非常巨大，这是由于这样的页面需要合并所有开发版本中的内容导致的。
所以在做添加链接的工作前，建议先考虑好这样是否合算。 Anterdc99Face Anterdc99（论·功） 2021年2月26日 (五) 02:04 (UTC)（最后编辑于：2021年2月26日 (五) 02:05 (UTC)）

经过本人思考，认为1的确过于艰巨，2更现实一些。但若采用2的话是否应在格式指导中说明？（另外我因为开学难以继续编辑，这事还需大家帮助，谢谢！）Sigma166（论/功） 2021年2月28日 (日) 10:22 (UTC)

关于引用进度的标准

昨天有人在说这个事。因为进度本身的判定有着比较具体的目标，所以昨天写了个引用标准的草稿：https://pastebin.com/k3Bpah0m

所以就是：

  • 是否有必要对进度引用提供一个标准；
  • 这个草稿内有无可能需要改进的地方。

以上。——IcyPhantom 讨论I贡献 2021年3月18日 (四) 14:18 (UTC)

个人认为按照共识去进行整理即可，并不需要刻意去编写标准（因为这个只是页面内容的一小部分罢了）。--Lxazl5770zh.admin（论 ▪ 功） 2021年3月25日 (四) 08:52 (UTC)

新增关于字词转换的帮助页

写了一个关于字词转换的帮助页，见此（修订版本链接）。

设立这个页面的主要目的是为了让想帮忙参与转换表/字词转换建设，或者只是一般读者的繁体用户能够更明确地明白本wiki的字词转换方针。另外，也可以以这个页面为基础，完善现有页面（尤其是标准化相关的）对繁体的说明。目前标准化页面没有明确提及“本wiki页面源代码内的名称以简体中文的实际核定情况为准”的相关明确语句，可能还是会导致繁体人士编辑时的迷惑。此外，目前wiki上没有从简繁体的核定速度等情况出发作“为什么wiki优先套用简体翻译”这类问题的简单说明，虽然我知道wiki尽可能保持语言中立，可能出于这个原因没有明说，但是个人认为明说更有利于和繁体读者沟通，提升更多人的阅读体验。

此外，这个帮助页的关注度可能需要手动提升，不仅需要放在繁体中文问题报告和相关Navbox里面，可以的话我希望在Sitenotice里面在“请以游戏内为准”那一行也加上到这个帮助页的链接。

这个页面的内容我已经提前提交给一部分本地人看了看，收集了一部分修改意见，现放在社区专页以获得进一步的共识与建议。-- LakeJasonFace Lakejason0（论•功） 2021年3月20日 (六) 17:09 (UTC)（最后编辑于2021年3月25日 (四) 08:28 (UTC)）

 支持可以放到sitenotice。--Lxazl5770zh.admin（论 ▪ 功） 2021年3月25日 (四) 08:57 (UTC)

页面已建立，见Help:字词转换。 LakeJasonFace Lakejason0（论•功） 2021年3月25日 (四) 15:24 (UTC)

推进。希望管理员能写一下Sitenotice。-- LakeJasonFace Lakejason0（论•功） 2021年4月23日 (五) 18:41 (UTC)

愚人节

不如4月1日的时候开启一次非官方文章，并于4月2日无封禁提删--119.237.10.81 2021年3月31日 (三) 06:41 (UTC)

 拒绝可能你不知道Java版2.0这个玩笑在n年前就开过了。--Lxazl5770zh.admin（论 ▪ 功） 2021年3月31日 (三) 10:49 (UTC)
好吧--119.237.10.81 2021年3月31日 (三) 11:34 (UTC)

制作了总讨论页的顶端目录

本人制作了用于总讨论页的顶端目录，可以方便的查看当前存在的论题及相关信息，具有多种的标记功能（功能一看就懂就不赘述了），效果如下。

如觉得不错可考虑应用于Minecraft Wiki:社区专页和Minecraft Wiki:管理员告示板的header中。--Star Zero · 维基假期中 2021年4月3日 (六) 07:13 (UTC)

 问题：就目前来看此模块仍存在较多影响正常使用的问题，因此暂持保留意见。MysticNebula70 T  2021年4月3日 (六) 07:53 (UTC)
问题已全部解决。--Star Zero · 维基假期中 2021年4月4日 (日) 04:05 (UTC)
根据你的成果重写了模块，如测试无问题且无异议即可将其转正。MysticNebula70 T  2021年4月4日 (日) 13:36 (UTC)
感谢猫猫的协助。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)
另此模板还需要修改讨论通过论题后的颜色，原通过模板背景颜色与24小时内更新颜色不易区分。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)

提议修改格式指导，以及再次更新Message box样式

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

讨论结果为 同意更新。

目前中文wiki的msgbox是放在infobox之后的，这并不符合大多数wiki的主流布局。我建议按照多数wiki的做法来，先msgbox然后infobox，并修改格式指导。

然后，目前的msgbox样式不能适应以上的调整，需要相应修改。大致需要更改的内容有：

  1. 将所有非mini的msgbox统一宽度；
  2. 增加msgbox的外边框；
  3. 两个相邻的msgbox取消间隔；
  4. msgbox内的文本改为左对齐。

另外，msgbox可以使用预设的颜色（目前有7个：red、​orange、​yellow、​green、​blue、​purple和magenta），以不同的颜色表示不同类型的信息（如红色表示需要立即执行的操作，橙色表示页面有内容方面的问题，等等），同时仍然支持自定义颜色。

此处可以预览新样式。

现在此征询社区的意见。MysticNebula70 T  2021年4月16日 (五) 12:24 (UTC)

 支持。不过和英文的差别还是很大，和正经Ambox的差距倒是很小。-- LakeJasonFace Lakejason0（论•功） 2021年4月16日 (五) 14:07 (UTC)
大部分 支持。只不过那个灰色的border我不大喜欢。-- Dianliang233 T•C 16 2021年4月16日 (五) 14:11 (UTC)
需要修改的还有消歧义模板。正常的顺序为消歧义-讯息框(msgbox)-信息框(infobox)。
对于预设颜色，我建议使用type（模式），每个模式对应一种颜色，然后选择模式。以及我个人建议不同命名空间设置不同样式。
对于文本左对齐，我认为现在mcw的讯息框宽度太小了，居左可能不太好看，如果要居左最好宽度拉长点，视具体情况而定。--Star Zero · 维基假期中 2021年4月16日 (五) 14:12 (UTC)
 支持，预览看着不错。不过调换很多页面的顺序确实是个很麻烦的工作。。--Snow dash（论 & 功） 2021年4月16日 (五) 14:14 (UTC)
 同意，新样式挺好看--Lxazl5770zh.admin（论 ▪ 功） 2021年4月16日 (五) 15:35 (UTC)

目前有部分成员提出不添加灰色边框。对此条建议有其他看法的请在此回复。MysticNebula70 T  2021年4月17日 (六) 11:33 (UTC)

移除了灰边框，效果请自行对比。MysticNebula70 T  2021年4月20日 (二) 10:28 (UTC)

预设颜色的用途

各个预设颜色的使用场合是什么？有关想法请在此提出。对配色本身有意见也在此提出。MysticNebula70 T  2021年4月17日 (六) 02:26 (UTC)

忽然才意识到这些配色在我的显示器上很素，很暗。如果改的更亮一点呢？-- LakeJasonFace Lakejason0（论•功） 2021年4月17日 (六) 03:40 (UTC)

目前英文wiki选取的颜色用途：

  • red：disclaimer和提删；
  • purple：建议页面移动、拆分、合并；
  • orange：页面存在内容问题；
  • yellow：页面存在格式问题；
  • green：标记页面的其他状态（例如是stub、正在编写中）；
  • blue：标记版本相关（例如版本独有、将在下个版本添加）；
  • magenta：未使用/自定义。

以上内容可供参考。

另：若按照type来选取颜色，则仍然需要确定一些预设的type用来对应颜色。如果同意使用type，可在此提议type。MysticNebula70 T  2021年4月17日 (六) 11:43 (UTC)（最后编辑于2021年4月17日 (六) 12:31 (UTC)）

 建议：新增颜色gray，用于表示丢失（如{{Lost version}}、{{Lost pre-reupload}}）、未发布（如{{Unreleased}}）或者可能不存在（如{{Unproven}}）的版本。--Ultim 0 ( VIEW | TALK | CONT ) 2021年4月17日 (六) 12:21 (UTC)（最后编辑于2021年4月17日 (六) 12:39 (UTC)）
这样的type咋样：
  • red->important
  • purple->pageaction
  • orange->problem
  • yellow->notice
  • green->pagestatus
  • blue->version
-- LakeJasonFace Lakejason0（论•功） 2021年4月17日 (六) 12:44 (UTC)（最后编辑于2021年4月17日 (六) 12:45 (UTC)）
 不认可:都不怎么样，行为和程度混杂，单词和双词混杂，而且和用途不搭，建议全部重定。--Star Zero · 维基假期中 2021年4月19日 (一) 01:40 (UTC)
建议方案：
类型(颜色) \ 命名空间 条目命名空间 文件命名空间 讨论命名空间
delete(red) 请求删除
move(purple) 移动、拆分和合并 移动和重命名 合并，拆分和重命名
content(orange) 内容问题 严重警告和问题 大部分警告和提醒
style(yellow) 格式问题 较轻警告和问题 较小警告和提醒
protection(grey) 保护
version(blue) 版本 \ \
notice(default) 条目注意 注意 通知和消息
Star Zero · 维基假期中 2021年5月4日 (二) 10:43 (UTC)
建议补充green，用于标示正在进行的工作以及未完成的页面。--Ultim_0 ( USER | TALK | CONT ) 2021年5月4日 (二) 10:54 (UTC)
修改版本：
类型(颜色) \ 命名空间 条目命名空间 文件命名空间 讨论命名空间
warning(red) 警告消息和请求删除 请求删除
move(purple) 移动、拆分和合并 移动和重命名 合并、拆分和重命名
content(orange) 内容问题 严重警告和问题 大部分警告和提醒
style(yellow) 格式问题 较轻警告和问题 较小警告和提醒
protection(grey) 保护
version(blue) 版本 \ \
status(green) 状态 \ \
notice(default) 条目注意 注意 通知和消息
Star Zero · 维基假期中 2021年5月4日 (二) 11:33 (UTC) （最后编辑于2021年5月4日 (二) 11:35 (UTC)）
模板已更新，各用到msgbox模板的模板需要单独更新。MysticNebula70 T  2021年5月4日 (二) 13:28 (UTC)

是否应加入有关盔甲和工具的重定向

我最近在Wiki上进行某些条目的翻译工作时，想使用和en一样的重定向（比如说[[Diamond Armor]]和[[Iron Armor]]，均会被重定向到[[Armor]]），但是发现中文Wiki除了皮革盔甲之外没有其他相关的重定向了。

如题，加入的理由有如下：

  1. 某些编辑者可能更倾向于输入[[钻石盔甲]]而非[[盔甲|钻石盔甲]]；
  2. 一些初来乍到的编辑者对Wiki是否有这样的重定向不熟悉，可能会直接输入[[钻石盔甲]]；发现Wiki上没有这样的重定向之后，为了方便此编辑者可能会输入钻石[[盔甲]]，这样不符合部分读者的习惯——他们可能会在看不清楚的情况下点击“钻石”而非“盔甲”。

综上，我认为有一定的必要加入相关重定向，现在此提出意见，征求社区的共识。--AblazeVase69188（讨论 | 贡献） 2021年4月23日 (五) 14:18 (UTC)（最后编辑于2021年5月1日 (六) 03:55 (UTC)）

如果需要的话，您可以自行添加重定向。MysticNebula70 T  2021年4月23日 (五) 14:31 (UTC)
 支持 这种确实对新手会产生困扰，我以前也体会过hhhhh Yfohdit（讨论） 2021年4月23日 (五) 17:46 (UTC)

相关重定向已全部创建，如有异议请在此提出。--AblazeVase69188（讨论 | 贡献） 2021年4月30日 (五) 15:15 (UTC)

深层绿宝石（铜、煤）矿石的相关解释需要改吗？

如题，21w17a的数据包中已经可以生成这三种矿石的深层变种，但数据包的更新内容需要和正式更新内容一起写吗？--Minesunset1030（讨论） 2021年4月30日 (五) 22:15 (UTC)

数据包的内容不大可能和常规内容共存，因为它已经不属于原始玩法。--Lxazl5770zh.admin（论 ▪ 功） 2021年5月5日 (三) 15:56 (UTC)

修改Minecraft Wiki:管理制度

背景

中文Minecraft Wiki现行与过去的管理员选举机制存在明显漏洞和缺陷，为某些图谋不轨的管理员施行专政封闭的管理提供了可乘之机。几年前发生过的反pow团队割裂现象，推进了管理制度的制定。但是，它反而成了管理员滥权的工具。因此，有必要重定管理员选举制度，主要是管理员与巡查员的产生办法。

原因
  • Minecraft Wiki:管理制度中所规定的“行政员保留无理由撤销管理层职务的权利””在职务到期时由行政员根据其表现决定是否刷新和延长时限”“不多于n名在职管理员对其就职提出反对”“3⁄4以上的在职管理员认可其对Wiki的贡献。”使管理员可以“钦定”管理员、巡查员的就职和任免，严重违反了wiki社区共识高于一切的基本法。
  • 现今中文wiki社区环境已经成熟，共识系统可以确立，“人少”“效率低”已不是借口。
修改办法

见Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。请善用比较功能查看差异。修改内容主要有：

  • 全面摈除专制选举的陋制
  • 加入管理员投票选举制度和巡查员符合要求即授予制度
  • 提高了巡查员和管理员的要求
总结

这是社区从选举层面坚持和完善社区共识制度体系、确保wiki长治久安的必要之举，充分体现了正当性和进步性。相信通过选举制度的完善，Minecraft Wiki一定能够走出长期存在的“专制泥沼”，集中精力完善内容、添砖加瓦，再创发展奇迹。仅代表个人，不代表Fandom意见。希望得到各位的支持。-- Dianliang233 T•C 16 2021年5月5日 (三) 03:14 (UTC)

应当事人要求就此折叠上述讨论。--Lxazl5770zh.admin（论 ▪ 功） 2021年5月10日 (一) 14:27 (UTC)

利益不相关：作为非本维基管理组，通过我在WP的认知和我在某维基担任主要管理者的经验来谈谈维基中的民主体制。
声明：本人不清楚本维基管理层情况，请根据实际情况实行。
引子
目前来说，对于社群民主实践最深的维基网站来说，毫无疑问是维基百科，在维基百科中有着这样的描述：
“

（是否是管理员）不应该有什么大不了的。

”
——吉米·威尔士
“

管理员没有任何高于其他用户的特权，唯能实现社群讨论所得的共识。

”
但是这并非所有维基都要遵循这样的理念，因为每个维基的现状不同，维基百科有着独特的实践条件（后文会提及），重新引用上面的引用语：
“

wiki不是可口可乐，不是全世界的wiki都有一样的制度

”
——某位用户
上面的讨论，我认为过多的使用了其他维基的条文来讨论“制度应该是怎么样的”，我认为不必过多的参考其他维基，而是从实际情况出发，我简要的谈谈实际情况中我的认知。
维基百科具有以下的条件：
  • 维基百科编者众多
  • 编者具有社群选举的参与度
  • 编者有相关的选举观念
而到了本维基，我们就不得不思考以下几个问题：
管理组的人数是否需要控制？
毫无疑问是需要的，基于一个社群中管理员适宜的占比以及上文提到的“拉帮结派”原因，管理员应该被控制在一个数量。
上文电量量有说到社区会自己控制管理员的数量，但是：
我们的编者是否对于管理员选举有认知？
本维基没有维基百科长期的民主政治历史，因此本维基的编者真的有充分对于“一个人是否应该成为管理员”的认知吗？相反，由于社群较小，社群中的编者大都互相认识，由于关系亲近，对于相熟的人自然会带有自己的偏移，给予更放松的通过条件（比如说大家对于界管权限的认知）。
以当前Mcwiki的社群讨论环境，很有可能会发生上面的情况，且大部分社群成员对于管理员上任的重要性可能没有概念，不参与或盲目投支持票，而不考虑社群是否需要更多管理员，管理员和社群考虑的方向是有区别的，再者：
我们编者的人数真的足够进行通过民主投票，表现社区真正公正的共识吗？
实际上，维基百科由于其编辑者的众多，进行投票的人数非常广泛，而我们维基进行投票会有多少满足条件的编者参与社群投票？
电量量说“社群条件已成熟”，而我从我这段时间的观察来说可能未必，况且是满足条件的编者，比如，现在发投票，能有20个人参与吗？
如果参与投票的人数没有达到一定规模，那么投票的结果就无法反映社群意见，而可能会发生上文提到的“倾向性投票”。依据现状，很有可能没有足够的人参与到社群讨论投票中，导致投票结束无限拉长。
我们真的需要完全民主吗？
综上所述，Mcwiki完全改制可能还为时过早。让我们思考以下，当前的寡头制管理组织形式真的很不堪吗？当然不是，寡头制管理有效率高等优点，社群也有足够的空间进行民主讨论，但最大的问题是寡头制过于依靠几位管理者的道德品质与个人能力，可能会导致滥权的发生，因此要考量的是：管理组现在真的有存在滥权专制的现象吗？这就要看本维基具体情况了。
最后
其实我个人是比较欣赏社群民主体制和电量量的改革精神，我自己在管理的维基也进行过多次这方面的改革，但是这可能不太符合实际情况。
我本人对本提案不持有立场，内容仅供引发思考，也望电量量放下立场，思考这些内容是否合理。
我个人认为现阶段不必操之过急，不必直接使用投票制度而是逐渐添加管理者的限制，减少可能使管理人专制的条件，将权利逐渐分散到社群中。
另：如果巡查员要改为即授予制，可能要选择降低一下巡查员的权限，目前权限确实有点超过用户组应有的权限。
Star Zero · 维基假期中 2021年5月8日 (六) 09:56 (UTC)
 同意Star Zero的观点。之前我考虑不周，盲目地表达自己观点。中文Minecraft Wiki的社区环境确实不够成熟，而且目前管理层滥权的可能性也不大，个人认为现阶段的任务应该是努力发展Wiki与其社区成员。由于我个人对本Wiki的深层和历史情况也不是非常熟悉，所以持 中立态度。
不过我觉得适当提高对进入管理层的用户的要求也是合理的，但我认为沙盒中的管理制度上更改的要求未免有点高了，例如对巡查员的要求“在中文Minecraft Wiki的编辑记录达600条以上”以及对管理员的要求“在中文Minecraft Wiki的Template（模板）命名空间编辑记录达100条以上”。--AblazeVase69188（论·功） 2021年5月8日 (六) 13:06 (UTC)
我不知道我应该做出什么评价。
少打一点感叹号，少打一点问号，少打一点粗体。能正常说话就不要写那么多反问句。不要让越来越强烈的语气演变成咄咄逼人的攻击性。
这个话题崩溃的一塌糊涂，上头了的话就应该先去洗把脸清醒一下。--Magnussiiftun1857[T/C/E] 2021年5月8日 (六) 11:18 (UTC)（最后编辑于2021年5月8日 (六) 11:20 (UTC)）
 支持。EPIC! MC中文wiki的毒菜问题也不是一天两天了，不彻底根治的话只会持续发酵下去，没个好的，加速编者流失。不过毒菜问题真的能靠自下而上的提案让毒菜结束吗？--Kaniol233（讨论） 2021年5月8日 (六) 14:35 (UTC)
 意见：
“

肉食者谋之，又何间焉？

”
——《左传》
私之栖于Minecraft Wiki，尚不足期年，个中条例，犹有不通，故 不予置评。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 15:34 (UTC)

以下部分段落文字，移动自管理员告示板。

对“修改Minecraft Wiki:管理制度”话题的回应：

首先，恳请大家先了解一点：不是所有事物都是非黑即白（binary）的。
众决没错，但是要依情景而论
对于众决好不好，对效率有何影响，政治科学、管理学、组织行为学等都有涉及，知乎之类也有很多高论，我才疏学浅不敢高谈阔论。但是我想简单引用弗雷德·菲德勒的权变理论来解释我上述的这个论点。简要地说，工作结构的不同，需要采取不同的职务权力才能达成合适的效果，而没有完全众决一定是最好的简单的非黑即白的说法，否则上述几个学界的研究者恐怕也没有存在的必要了。当然在Wiki里行政员和管理员也都应该是普通的编辑者，不过我想在一定程度上进行仲裁对于日常运作还是有必要的。
中文Minecraft Wiki已经非常开放
就拿英语Minecraft Wiki来说，据我所知没有任何管理员推举公示的制度，而英语Wiki的规模少说有中文Wiki的10倍。本Wiki上全保护页面也已经尽量减少，就连首页也有部分片段可以开放给所有注册用户编辑，这一点上就算不是绝无仅有也是非常少的。之前的Wiki条例修订，也经过了公示咨询，绝对不存在哪个行政员、管理员一手遮天的情况。
所有编辑者都是善意的，包括管理员
提出修改管理制度也是为了Wiki的良好发展才做出的，这一点我愿意相信。但是可否请大家也相信管理员有自己的坚持也是为了Wiki的良好发展？在这里我想稍微辩护几句，对Wiki最恶意的人最该做的就是不来编辑（请不要把这句话反过来理解，编不编辑是个人的自由），而不是参与在其中“浪费”自己的时间，能参与讨论的，已经都是非常关心Wiki的同好了。如果大家都能有这个前提的话，我相信交流当中也会少一些矛盾。
之后的安排
我们会讨论修改管理制度，同时行政员、管理员的组成也会再加考虑，请各位耐心等待。
--一名编辑者RealCuervo（讨论） 2021年5月9日 (日) 08:47 (UTC)
我想说的话大体上已经在编辑者QQ群里说完了，我在这里顺便补充一些需要了解的东西：WP:DEM、WP:POLL、WP:BATTLEGROUND和WP:FAITH。--Lxazl5770zh.admin（论 ▪ 功） 2021年5月9日 (日) 09:32 (UTC)
补充一张《反驳金字塔》图，作为镇楼用途。
Graham's Hierarchy of Disagreement

格雷厄姆的反驳金字塔

--Lxazl5770zh.admin（论 ▪ 功） 2021年5月9日 (日) 14:07 (UTC)
感谢管理的真诚回应。其他的就不多说了，决裂过的人也没必要再挽回了。-- LakeJasonFace Lakejason0（论•功） 2021年5月9日 (日) 10:23 (UTC)
这里指的不是电量。我甚至都不认为哪一个（只有一个例外）决裂的人是因为wiki事务才决裂的。-- LakeJasonFace Lakejason0（论•功） 2021年5月9日 (日) 10:24 (UTC)（最后编辑于2021年5月9日 (日) 10:38 (UTC)）
讨论及决定的不是管理组，是社群本身，即本讨论。--Star Zero · 维基假期中 2021年5月10日 (一) 14:18 (UTC)
对于Cuervo/a2的发言我就不用说太多了；因为已经很久没有在这里编辑过了，又因为每一次出现都能被说是旧病复发，我知道我没有多少发言权。关于管理员（此处尤其指某位行政员）是否能够一手遮天的问题，我想有过遭遇的自然会知道答案。如果中文 Minecraft Wiki 真的能够做到长久以来虚无的“皿煮”的话，那我就在幕后为你们的成功庆祝吧。另外，好像看到有一名马迷成功上任了管理员，这个也一定要祝贺一下，这是坠吼的！
Minecraft Wiki Anti-* Safe House. --SkyFuInMC (DI/CO) 2021年5月27日 (四) 14:46 (UTC) from Onion Network

命令描述页面，把“示例”挪到“效果”与“输出”之前

本主题或以下段落文字移动自MCW:管理员告示板。

如题。

当前命令介绍页面的格式大致是：语法，参数，效果，输出，示例，历史。

对于一条命令，想要查找资料的初学者，示例显然比输出更重要。把示例往上放到参数下面应该更好，这样也便于阅读者对比示例中的例子用到了上面的什么参数。

如：/clear

请自行用预览功能尝试

在读示例的时候会轻松很多，去对比参数与语法。

en版是把示例示例放最后了？算了跟我们无关……我是觉得改一下更好--Dahesor（讨论） 2021年6月7日 (一) 20:21 (UTC)

“应由大众讨论的事项请布告于Minecraft Wiki:社区专页。”--Snow dash（论 & 功） 2021年6月8日 (二) 00:16 (UTC)
 赞同：明晰而立竿见影的案例比晦涩且难以理解的说教更具动力。
 收回前言：案例固然重要，但不是命令子页面的必需。--Ultim_0 ( USER | TALK | CONT ) 2021年6月8日 (二) 03:59 (UTC)（最后编辑于2021年6月8日 (二) 05:13 (UTC)）
 反对。本来就是给命令提供参考的页面，对于初学者来讲是上面那么回事，其他人呢？针对不太依赖示例的人来讲，确认命令的输出更实际点。而且我也没见事情本身的特性没解释完就写例子的玩意，真那么写的多半都给人一种莫名其妙编排混乱的感觉。至于对比，我觉得开MC手写命令去对比更实际点，而且实践一直都是学习的方法之一。顺带提一句，命令介绍页本身就不是放教程的地方。——IcyPhantom 讨论I贡献 2021年6月8日 (二) 04:35 (UTC)
 信息依我薄见，还是示例更重要。这不是教程不教程的关系。随意点进该页面的读者在看完参数后显然更需要示例，而不是深入才会涉及到的，详细的效果表，或是只有用execute store才会涉及到的输出。对于有兴趣者当然会自己下滑，特地要查找资料的读者也自然会寻找。还有我不认为这会造成编排错乱。Wiki是必经给人看的资料，没必要一定照标准。综上，我 +坚持己见，将示例挪到参数之后，或至少，将示例挪到效果之后，输出之前。--Dahesor（讨论） 2021年6月8日 (二) 05:21 (UTC)
 反对。首先明确“命令”下面的子页面是手册页性质的，而不是教程性质的。而无论什么手册页，示例都是放在最后，或者干脆不放示例。
就比如，在runoob上描述函数的顺序就是“描述”（对应“导言”），“声明”（对应“语法”），“参数”，“返回值”（对应“效果”和“输出”）和“实例”（对应“示例”）。
在man7（甚至没有示例）或者其他地方的类似内容基本也是同样的顺序。
另外，我 同意IcyPhantom的意见。-- Anterdc99Face Anterdc99（论·功） 2021年6月8日 (二) 04:51 (UTC)（最后编辑于2021年6月8日 (二) 04:58 (UTC)）
 这是坏的，因为抄示例不会让新手变的更强……虽然大部分新手很可能没有耐心看完语法。嘛，也算是一种矛盾，本来之前准备写如何阅读命令相关页面的教程的，但是不太好写就咕了，嗯。以及个人意见，新手要用好命令页面，绝不应该一上来就往示例里面看。-- LakeJasonFace Lakejason0（论•功） 2021年6月8日 (二) 05:23 (UTC)
顺便我们有一个东西叫做目录，如果新手想看的话完全可以直接点目录就是。虽然我们都知道就算目录摆在那里我们也一次都不会点（真是矛盾）。-- LakeJasonFace Lakejason0（论•功） 2021年6月8日 (二) 05:28 (UTC)
 反对。不管是技术类教科书还是指导书还是其余的手册/教程性质的文本，都只有两种排版方式：1. 根据示例来讲效果；2 列举效果最后放个例子。MCW的命令子页面很明显不适合第一种（第一种的页面应该归到教程的子页面）。对于初学者不想看“效果”与“输出”的话可以直接跳到最后看示例，但是根据内容完整度或连贯度来看，示例不应该提前。（我甚至想把示例直接删掉）。——方法放寒假 (Talk - Contributions) 2021年6月8日 (二) 05:24 (UTC)
 留言。好吧，那既然大家都反对，我就放弃辩论啦--Dahesor（讨论） 2021年6月8日 (二) 05:32 (UTC)

关于“你知道吗”段落的规范化

目前“你知道吗”段落内容泛滥，是时候要加以规范了。这是en搬运来的格式指导，不知各位的意见如何。--Lxazl5770zh.admin（论 ▪ 功） 2021年6月8日 (二) 15:48 (UTC)

 支持，这个指导内容很详细明确。--Snow dash（论 & 功） 2021年6月8日 (二) 15:50 (UTC)
 提醒：这些格式指导的内容与MCW:SG/F#你知道吗大致相同，只是未见规范效果。--葉月 桐§ 2021年6月8日 (二) 15:56 (UTC)
已经有了？？？？那没事了--Lxazl5770zh.admin（论 ▪ 功） 2021年6月11日 (五) 06:06 (UTC)

fandom INTERNAL_SERVER_ERROR, 500

我之前在试用wiki的新皮肤fandomDesktop，发现参数设置里还有第三个皮肤，是mobile开头的。 选上这个皮肤然后保存设置之后，就再也打不开Minecraft wiki了，任何页面都是500错误，只好通过清除cookie解除登录状态才能打开wiki。现在我重新登录后依旧是提示500。fandom什么时候能修复这个bug？有没有什么临时的解决方案（除了退出登录以外）？--207.180.203.231 2021年6月10日 (四) 17:10 (UTC)

终于找到解决办法了，在网址后面加上 ?mobileaction=toggle_view_mobile 之后就能进去了。fandomsb --（和上面是同一个人的）145.239.77.243 2021年6月11日 (五) 00:54 (UTC)
社区内容除另有注明外，均在CC BY-NC-SA许可协议下提供。
Advertisement