社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解，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） |
|---|---|---|---|---|---|---|
| 1 | Java版中可替换相关定义 | 7 | 3 | 传入神经元 | siiftun1857 | 2023年11月4日 (六) 17:39 |
| 2 | 删除侮辱内容 | 1 | 1 | Gongxiang01 | Gongxiang01 | 2023年11月4日 (六) 08:16 |
| 3 | BUG Lua错误 在Module:Breaking_table的第443行：bad argument #1 to 'ipairs' (table expected, got string) | ? | ? | ? | ? | 未知日期 |
| 4 | wiki发生什么了 | 2 | 2 | Luobojuo | Outreach8982 | 2024年2月25日 (日) 14:13 |
| 5 | 关于Wiki教程的事宜 | 5 | 3 | Just Cookie and Cookie | Just Cookie and Cookie | 2024年7月10日 (三) 12:40 |
| 6 | 是否同步英文wiki的一些政策 | 4 | 3 | Spconversion | Just Cookie and Cookie | 2024年6月17日 (一) 02:29 |
Java版中可替换相关定义[]
目前在材料/Java版#可替换方块有一个可替换方块的概念，它有以下影响：
- 玩家放置方块、下落的方块落地时可以替换可替换方块；
- 受重力影响的方块在下方方块可替换时可以下落；
- 可替换方块带有
enchantment_power_transmitter标签，允许附魔台检测其后方的书架。
此外，游戏中有与之对应的replaceable标签，源代码中也有相应的检测。
然而，我们发现了以下特例：
- 幽匿脉络没有
replaceable和enchantment_power_transmitter标签，可被玩家放置的方块和落地的下落方块替换，上方受重力影响的方块不下落； - 青蛙卵没有
replaceable和enchantment_power_transmitter标签，玩家放置方块时不可替换，上方受重力影响的方块不下落，有下落的方块接近时破坏； - 多种方块在源代码中疑似有特判；
- 历史上的其他特例，如23w14a ~ 1.20-pre1的牡丹。
那么现在需要：
- 在合适的页面给出相关概念的定义；
- 向
{{Block}}加入相关参数； - 对现存的特例给出解释。
先前在QQ群讨论的效果不好，所以转移到这来。以下是我的观点。
首先事实是没有争议的，无论给了怎样的定义，都不用担心和源代码或实验有冲突。最重要的是考虑读者的需求，便于理解、应用，便于维护的话更好。
因为现存的特例不多，保留一个概念就可以。我强调一个被忽略了的事：有replaceable这么一个方块标签。这个标签通过调试屏幕和命令很容易鉴定，同时目前来看它和影响的后两条等价，而它们也好测试。对读者来说，给一个与游戏中看到的字面意思相同的标签一致的定义也容易理解。它还把幽匿脉络排除在外了。综合来看以该标签为可替换的判据应该可以让所有人满意。
下一个问题是定义放在哪。可替换曾经是材料决定的属性，但自从23w14a加入replaceable标签，可替换相关的属性已经不再和材料绑定，自然不该在材料下定义。那么最合适的地方大概是标签#blocks replaceable。如果未来建立了收集方块属性的页面，那也是一个选择。
最后，幽匿脉络显然要在其用途下解释。考虑到该判据与字面意思的可替换不符，可能引起误解，在{{Block}}内添加注释即可。青蛙卵被下落方块破坏的机制与可替换方块有明显区别，应按不可替换处理。
综上，我的观点是在标签下给定义，{{Block}}参考该标签，幽匿脉络在其用途下给解释并在{{Block}}内添加注释，青蛙卵按不可替换处理。看到一些编者持不同的观点，请在此复述以便讨论，谢谢。我手里没有代码，有相关信息的也请补充。传入神经元（权限/讨论/贡献/日志) 2023年11月3日 (五) 13:11 (UTC)
- 首先是关于定义本身：
- 要讨论“可替换性”的定义，首先得确定在
{{Block}}infobox里的各属性的定位是什么。如果没有明确的定位，那自然怎么定义都有道理。现在所用的定位就是直接反映源码中方块实际拥有的基础属性，然后各个页面引用这些基础属性去解释多种多样的行为。由于它的定位根本不是直接描述方块的行为，因此所列举的各种行为，不管存不存在特判，都和它无关。如果把定位改成“直接描述方块的某些行为”，那么我不太同意，replaceable作为一个属性本来很简单，把行为杂糅到这一个属性里只会导致后续编辑的困难和描述混乱。 - 至于去反映代码中的一个属性有什么用，首先是使条目描述逻辑和代码尽量接近（当然前提是要易懂），从而防止mj背刺。更重要的是，这些基础属性往往是技术性玩家常见得到的。对于replaceable属性，虽然不如红石导体那样知名，但在自定义世界生成中的方块谓词中可以直接检测方块的replaceable属性。也就是说即使完全不接触源码，该基本属性也是玩家可以直接接触得到并有查询需求的。
- 在原版中replaceable标签和代码中的replaceable基本属性的确完全一致，但我不建议在定义时使用该标签。因为该标签只影响引用它的enchantment_power_transmitter标签，向replaceable标签中加入或删除方块不会改变方块的replaceable属性。因此需要把标签和基本属性两者区分开来，避免读者误解该标签的功能。
- 因此，我认为，infobox里的replaceable应直接定义为源码中方块的replaceable属性。如果不这样定义，就不好解释那个方块谓词到底在检测什么东西（是检测方块本身的属性而不是方块的某种行为，也不是标签）。
- 关于写到哪里：
- 该属性的定义以及相关的各式各样的行为要统一写到哪里，可以进一步讨论，Nickid2018考虑在wiki搬迁后再重写材料拆分后的各种内容。存在特判的行为当然要写到方块的用途章节中，可以多花点笔墨，做到便于理解。
- 另，以上我的见解完全基于Java版，对于依旧在使用材料系统的基岩版如何处理，可以再进一步讨论。--Chixvv（留言） 2023年11月3日 (五) 14:43 (UTC)
- 既然标签与其他现象无关，按照标签定义确实不合适。至于按源码怎么样，不妨先交流下这些观念。
- 关于背刺的问题，咱们没法预测Mojang会改什么，代码大改也有可能，不如先不考虑，有变化之后再讨论。
- Block infobox是读者打开一个方块条目立刻就能看到的，而会用源码和谓词的技术性玩家应该是少数，而且对Block infobox的需求不大（MCPropertyEncyclopedia它不香嘛），这里不必优先考虑。读者最需要的依然是放置方块时能否替换。
- Infobox内的属性定位到源码中的属性也并不清晰。可再生显然不是从源码导出的，红石导体来自源码好理解，而“窒息生物”“可替代”如果从源码定义，它们的字面意思会误导读者。或许可以在infobox里注明。传入神经元（权限/讨论/贡献/日志) 2023年11月4日 (六) 05:16 (UTC)
- 首先，目前这个东西的名称的共识是“可替代”。
- 可替代有非常清晰的定义：方块的诸多属性中，其中一个是可替代，这个值是什么，就是什么。数据导出工具也会准确地导出他们。
- Block Infobox内的其他行，除了透明度仍有争议外（这是另一个话题的事情了），剩下的行也都有清晰的定义，并且几乎都是程序根据游戏自动生成的。
- 可替代是一个取值只能是“是”或“否”的数据，不存在“部分”或其他可能。测试也很简单，仅需将沙子放在方块上，沙子下落就是可替代，未下落就是不可替代，也只有这两种结果。
- 青蛙卵是被下落的方块直接砸碎的，会经历标准的方块破坏过程再执行下落的方块放置，因此在这个问题上并无特殊之处。
- 方块标签并非被忽略，没有提到是因为参考标签是不可取的，这个属性不受标签影响，且多数机制是由可替换属性而非标签控制。想看标签的也可以直接去标签条目或者ID table里看。
- 定义会放置在新的“方块属性”条目，与许多其他方块属性一起，无需担心这会对可替代的定义有影响。
- 你提出的将幽匿脉络的可替代属性填写为“是”是不可接受的。如果要做到“考虑读者的需求”，那么写正确的值才是做到这一点的方式。你需要了解一点，那就是这些属性值并非只有方块放置过程会读取，游戏中可能会有任意多个机制读取，每一个机制都有读者在乎，每个人都可以主张他们在乎的那个游戏机制。例如，红石导体可以阻止下方的箱子开启，即使两者的名字听上去是那么的毫无关联。
- 幽匿脉络是自己定义了可替换行为、从而在可替换属性为否的情况下可以直接放置方块替换掉的唯一实例。幽匿脉络本身有诸多反常现象，可以说是出现什么问题都不奇怪，先前讨论的结果是都得写行为里。
- 再次重申，幽匿脉络的可替换属性为“否”，不可为“是”，不可为“部分”，与该方块有关的行为应当写入行为段落中而非更改可替换属性。
- 不要脱离实际去想象机制，否则只会出现下一个教程/不透明度。--siiftun1857[T/C/E] 2023年11月3日 (五) 17:10 (UTC)
如果考虑多数玩家的话，其实第一次看到infobox一行里“可替代”三个字，普通读者根本理解不了什么是“可替代”，也不清楚哪些行为和“可替代”有关，必须点到链接里去看。（加<ref>不太合适，加tooltip的话也难以一句话解释清楚。）因此只要链到的内容能够把它和相关的行为都解释清楚就行了，不必太担忧对普通读者产生误导。
既然一行infobox描述不了和可替代相关的全部行为，我认为即使infobox里写了可替代，所有可替代方块的用途章节里也都需要再用文字描述一遍。比如在草的页面就要讲明白各种行为包括放置方块会覆盖草、草支撑不了沙子等等。可替代方块本身没几个，其行为特例又相对较多，值得花一些笔墨来把它讲清楚。有了足够的文字描述的话，infobox里的可替代定义如何可能也并不是很重要了。--Chixvv（留言） 2023年11月4日 (六) 17:39 (UTC)
- 这个可替代值就是为了这个属性而存在的。总得有一个东西传达这个属性，就算可替代这个名字被占用了也得写另一个名字（显然更加不合适和令人困惑）。因此，可替代的定义不存在问题。--siiftun1857[T/C/E] 2023年11月4日 (六) 17:39 (UTC)
删除侮辱内容[]
依据讨论页方针折叠不合适评论。（偏离主题或闲聊）BUG Lua错误 在Module:Breaking_table的第443行：bad argument #1 to 'ipairs' (table expected, got string)[]
https://minecraft.fandom.com/zh/wiki/%E6%BD%AE%E6%B6%8C%E6%A0%B8%E5%BF%83: Lua错误 在Module:Breaking_table的第443行：bad argument #1 to 'ipairs' (table expected, got string)
wiki发生什么了[]
好久没等录wiki了，感觉wiki是不是发生什么事情了？Luobojuo（留言） 2024年2月23日 (五) 15:14 (UTC)
- wiki迁移至Weird Gloop，可见置顶公告或微博公告。--Outreach8982（留言） 2024年2月25日 (日) 14:13 (UTC)
关于Wiki教程的事宜[]
下列有关页面移动的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。
讨论结果为 完成。
Wiki本只该搜罗客观可供查证的内容，然而，Wiki上的教程却允许记录难以划分界限的社区内容，无收录边际可言，内容也无可靠来源，仅凭编者的心情就能随意加入任何内容。且众所皆知，教程为目前Wiki质量最差的一部分，已严重影响玩家群体对本Wiki的观感，拉低整体可信度。再说任何人皆可加入自己的个人看法，甚至加入视频不用经过条目视频化审核，很容易成为宣传自己思想甚至商品的工具，这些巡查时都难以揪出。对不理解Wiki运作的外人来说，还可能认定其代表所谓“Wiki立场”，有心人还能自己写自己在站外引用称内容经Wiki背书。不过教程历史已久，删除肯定不可行，因此，我提议将教程都移至用户空间。如此不但能大量减缓前述问题，这些内容也很符合用户空间的精神。我将在进期执行此操作，欢迎各位留下自己的看法。--Just Cookie and Cookie（留言） 2024年5月27日 (一) 10:37 (UTC)
- 非常支持这一方案，目前各个视频平台上的视频教程也十分清晰易懂，玩家不再需要wiki上的质量较低的文字教程。请问阁下打算将教程移动到谁的用户页中呢？--Spconversion（留言） 2024年6月2日 (日) 11:04 (UTC)
- 这确实是一个问题，那还是Help命名空间好了，也正符合其名称。--Just Cookie and Cookie（留言） 2024年6月17日 (一) 02:32 (UTC)
- 本wiki已迁移至Weird Gloop，可见微博公告--Dream Star（留言） 2024年5月27日 (一) 12:09 (UTC)
- 已完成移动，剩下就是有部分红链该修改的修改该去除的去除--Just Cookie and Cookie（留言） 2024年7月10日 (三) 12:40 (UTC)
是否同步英文wiki的一些政策[]
根据en:Minecraft_Wiki_talk:Community_portal#Removing_Snapshot_Articles和en:Minecraft_Wiki_talk:Community_portal#Updating the Wiki's Policies，英文wiki行政员SLScool正在提倡删除所有快照页面和所有历史图片（包括生物、方块等的）。我认为这些内容确实没有什么用处，wiki应当追求收集一切最新的信息，包括现在所有页面和教程都只收录最新版本的内容，而快照版本在官网上都有介绍，且不说很多快照版本都是些琐碎的漏洞修复，而且很多中文社区也有优秀的翻译，wiki应该让编者们把精力集中在最新的内容上，这也是SLScool提出这些建议的原因之一。
对此，我个人对此表示支持，并提出以下建议：删除所有页面的“历史”段落；将所有快照页面重定向到其所属主板本，如23w05a重定向到Java版1.19.4，这是因为这些主版本页面包含其所属快照的全部更新内容。欢迎大家踊跃提出意见。--Spconversion（留言） 2024年6月2日 (日) 12:24 (UTC)
- 此话题已逾两周无人回复，如无反对意见，私欲于近日执行将快照页面改为重定向之操作。--Spconversion（留言） 2024年6月14日 (五) 14:20 (UTC)
- 支持，与英文wiki的步调保持一致有助于中文wiki获得与英文wiki相似的优势。--Giobowhosty（留言） 2024年6月15日 (六) 00:27 (UTC)
- 支持，这么多快照页面难以维护和即时更新。Just Cookie and Cookie（留言） 2024年6月17日 (一) 02:29 (UTC)