Minecraft Wiki:社区专页

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

请了解，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	重新规划生物分类	9	5	siiftun1857	Lakejason0	2021年7月31日 (六) 00:57
2	重写LootChest模块	8	6	Star00	RealCuervo	2021年5月4日 (二) 16:36
3	加入标签储存模块	3	2	Snow dash	Snow dash	2021年5月16日 (日) 16:14
4	BE开发版归属问题	8	3	Jingji132	Jingji132	2021年6月7日 (一) 02:06
5	广告	2	2	173.255.254.49	Endearing Cat	2021年7月13日 (二) 09:41
6	更新携带版/基岩版版本记录中引用的链接	2	2	MinecraftPig321	Ultim 0	2021年8月5日 (四) 15:05
7	沒辦法上傳圖片	3	3	Zica87	Dianliang233	2021年7月24日 (六) 13:19
8	【对于一系列服务器小游戏是否加入的讨论】	4	4	183.209.144.184	AblazeVase69188	2021年7月26日 (一) 02:34
9	关于基岩版开发内容留存及去向问题	4	4	[[User:SkyEye_FAST SkyE] \|SkyEye_FAST SkyE] ]]	Lakejason0	2021年7月29日 (四) 07:18
10	提议修改命令语法格式	5	2	MysticNebula70	Lakejason0	2021年8月2日 (一) 07:27
11	把“概念性”的armor一词的翻译改为“护甲”	2	2	Miemiemethod	Lakejason0	2021年8月2日 (一) 07:30
12	弃用原有Infobox，改用PortableInfobox	2	2	Dianliang233	Lakejason0	2021年8月3日 (二) 09:18
13	在《我的世界：中国版》中的编辑错误。	?	?	?	?	未知日期
14	新页面	3	3	ChiaLeeChuen	Ultim 0	2021年8月5日 (四) 15:12
15	请问Wiki点数的计算公式是什么	3	3	QWERTY-5238	Ultim 0	2021年8月9日 (一) 05:58
16	网易我的世界的"演示模式"	?	?	?	?	未知日期
17	关于教程页的几个问题	4	3	QWERTY-5238	QWERTY-5238	2021年8月12日 (四) 12:46

话题

重新规划生物分类

由于生物分类异常混乱且缺乏规则，我一点时间整理了这些内容。然而，介于这是一个不小的变动，对先前分类方式的完全颠覆，我希望在大动干戈之前能够先取得社区共识。

草稿已经提交至沙盒，包含对生物条目和{{Entities/content}}的更改。

这个变更的主要内容是将生物分类由被动型/中立型/敌对型这三大类改为友好生物/敌对生物这两类，抛弃中立型类别并将其中的生物送入前两个大类的子分类。

如果达成共识，那么所有生物条目的infobox内的生物类型也会更新，并且在这一方向将不再与En看齐。--Magnussiiftun1857[T/C/E] 2021年4月5日 (一) 07:29 (UTC)（最后编辑于2021年4月5日 (一) 13:24 (UTC)）

支持对生物分类进行变更， 较反对全部改变到新分类方式。先不论文章实际内容（因为反正总得有个标准），抛弃中立型合并到其他类别的变更会给读者造成直觉阻碍。虽然很多页面都要说“中立型和敌对型”，然后再去除中立型里面的动物，确实造成了表意赘余，但是除了这种赘余之外，是否还有更多需要改动的必要？
此外，两个分类方式是否有源代码层面的依据？目前的提案应该是来源自声音事件分类，但是这似乎不能说“就和源代码层面对Mob的处理”完全一致。如果有人能基于某一套反混淆（我建议yarn或者Mojmap）给出相应的依据，我觉得会更清晰一些。-- Lakejason0（论•功） 2021年4月5日 (一) 07:41 (UTC)

支持。和英文的一位编者讨论了这个问题，实际上目前沙盒内的方案（也就是先归入友好/敌对大类再归入行为小类的方法其实很好地消除了歧义（但是在文章内需要把两个分类都写上去不然歧义就变大了）。目前的一个问题是如何让读者适应这个变化。--

Lakejason0（论•功） 2021年7月31日 (六) 00:47 (UTC)

问题：友好生物/敌对生物如何判定？这只能主观判定吧。-- Dianliang233 ^T•_C

2021年4月5日 (一) 08:33 (UTC)

per myself，根据sounds.json内的声音事件类别。--

Lakejason0（论•功） 2021年4月5日 (一) 08:37 (UTC)

标准的选择其实相当多……不过我倾向于，将是否被进度“怪物猎人”和“资深怪物猎人”追踪，视为目前的决定性标准。
实际上，友好生物和敌对生物分类的内容来自先前的被动型和攻击型，区别只有多了原本归类于中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)

关于区分友好生物和敌对生物，游戏里本身也分不清楚（比如可以蜇人的蜜蜂属于友好生物，猪灵属于敌对生物，北极熊在Java版算友好生物在基岩版却算敌对生物），所以我个人还是赞成保留现有的区分方法。--Lxazl5770_zh.admin（论 ▪ 功） 2021年4月13日 (二) 02:51 (UTC)

现有分类方式确需改进 不建议这样更改。很多读者可能已经习惯了现有的分类方式，这样更改会使一些人难以接受。我认为基于现有的分类方式上进行合理的更改会更好。--Endearing Cat（讨论） 2021年4月15日 (四) 13:55 (UTC)

现有分类的问题就在于他的最外层本身具有ambiguity，因为单纯的“非完全敌对”不能完全概括生物行为。--

Lakejason0（论•功） 2021年7月31日 (六) 00:56 (UTC)（最后编辑于2021年7月31日 (六) 00:57 (UTC)）

重写LootChest模块

本人受中文McWiki管理员邀请，重写LootChest模块，原模块有以下问题：

代码杂乱，严重过长
数据结构复杂，维护困难
运行效率低

虽然原义只是修改后端代码而不动前端显示效果，但基于以下原因，我也一并进行了重构：

原模块生成的表格过长，对于大表较难对应左边和上面的标尺。
原模块生成表格将不同结构合并为一张大表，导致浪费空间多。
移动端显示效果差。

因此我预计进行以下更改：

将数据储存方式更改为原文件的格式（JSON）,其他运算全部在模块内进行，不需要人工进行编辑。
提高了模块运行效率，从而可以一次性生成全部结构的表格，不需要箱子战利品加载多个页面的形式。
对于前端输出显示效果，一个结构输出一个表格，通过flex布局的形式进行合并，从而优化查找数据方便程度和移动端显示效果。

当前重写后的模块存在以下问题：

由于拆分table的原因，虽然提高了查找效率，但表格不对齐对于观感有部分破坏。
由于重写为非人工编写的数据储存方式，可能有个别功能无法继承（大部分都可以继承）。

当前已发现的问题：

部分物品和全部结构名无法进行转换，将会添加转换表进行转换。
同一个大结构里的不同箱子结构无法归于同一个整体，这个可以人工分段解决。
java开发版和基岩版后续会添加支持。

当前的数据储存页面：

当前的进度：

结构输出：指定结构 ✓
结构输出：全部结构 ?
物品输出：单个物品 X
物品输出：全部物品 X

当前的示例页面：

源代码存放：模块:Sandbox/Star00/LootChest
指定结构输出：project:沙盒/LootChest
全部结构输出：Test wiki上的沙盒页

由于未知原因，相同的代码在mcwiki上无法实现效果，因此请先前往Test wiki进行查看。

请发表重构模块的建议，感激不尽。--Star Zero · 维基假期中 2021年5月1日 (六) 14:08 (UTC)

没有什么更好的建议了（在群里都交流过了，但是似乎不太明朗），就支持一下重构吧。EN那边感觉也找不到人解释。--

Lakejason0（论•功） 2021年5月1日 (六) 15:36 (UTC)

支持重构，希望还能加入的一点就是java版和be版相同时的合并表格。--Snow dash（论 & 功） 2021年5月1日 (六) 16:16 (UTC)

支持，见前面。Sigma166（^论/_功） 2021年5月2日 (日) 09:40 (UTC)

分为共有，java版，基岩版三个部分如何。--Star Zero · 维基假期中 2021年5月2日 (日) 09:57 (UTC)

支持。--Minesunset1030（讨论） 2021年5月2日 (日) 10:16 (UTC)

支持。也许可以用{{only|je}}和{{only|be}}？Sigma166（^论/_功） 2021年5月2日 (日) 10:41 (UTC)

可否考虑i18n？方便维护也方便迁移到其他wiki。--RealCuervo（讨论） 2021年5月4日 (二) 16:36 (UTC)

加入标签储存模块

在21w19a中Mojang加入工具加速破坏的方块相关标签后，{{ID table}}中包含标签的方块大幅度增加；且快照更改标签相关内容的频率有所提高。我希望将游戏data文件夹中标签相关的内容经过脚本整理后，储存到Wiki模块。Template:Sandbox/GameTag/doc是一个样板。用途有两点：

类似于模块:SpecialConversion，在{{ID table}}的|blocktags=参数中返回涉及到的相关标签。这样便于维护，更改时只需要更新数据模块，且更新标签从无到有或从有到无的相关方块物品页面即可。
在标签的表格中使用。输出标签包含内容，引用的其他标签也能自动生成链接以方便页面内点击跳转，便于维护。

现就这些问题发布于社区专页：

是否需要更改{{ID table}}以支持自动生成标签或提供报错分类。以提示过时的手动参数、空标签或自动合并相同标签。但技术难度很大，现有的rowspan都是手动指定的。
现有的输入都是手动输入，更改需要不小的编辑量，在此申请社区共识认同。

谢谢。--Snow dash（论 & 功） 2021年5月16日 (日) 02:54 (UTC)

如果改的话，顺便把基岩版的标签也弄一下？不过基岩版目前标签有亿点点乱--2190303755(T|C) 2021年5月16日 (日) 03:49 (UTC)

对，忘说了，模块是Java版的标签，基岩版没有json定义，需要其他人来搞。。--Snow dash（论 & 功） 2021年5月16日 (日) 16:14 (UTC)

BE开发版归属问题

既然允许存在这种1.16.200+的开发版包含1.17的特性，那要不要把目前1.4.0的前四个开发版（1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12）还给1.2.13，更何况1.2.13正式版也加入了对应的实验性玩法。与此同时我认为既然这样的过渡版本开发版内容已经不再属于当前的主版本号的更新主题，应该考虑为其划分出独立的定位，而不是直接放到一起。可以参考

-Jingji132（讨论） 2021年6月4日 (五) 08:00 (UTC)

不建议：自1.16.200发布以来，1.16.200+正式版从未出现过“Caves and Cliffs”这个实验性玩法选项，即这些正式版不包含洞穴与山崖特性，而不像1.2.13那样，可以通过实验性玩法启用水域更新的部分特性；况且这些开发版也不全都测试洞穴与山崖特性，也有其他内容（如1.16.200.53加入光追），且会发布到正式版中，并非过渡更新；直白地说，这些开发版如同一个实验工具，用完了该放哪放哪。至于1.2.13的问题，参见：en:User talk:Ff98sha#1.3 builds don't exist (yet)。--XiaoXin666（T·C） 2021年6月4日 (五) 15:46 (UTC)

我的主要目的还是回过头讨论1.2.13开发版的归属问题，我认为目前的规则与1.2.13时所讨论出的规则并不相符，1.2.13那时认为的包含新内容的后续开发版都属于1.4，但它们本质上是1.2.13的开发版，甚至1.2.13正式版都加入了对应的实验性功能；而现在1.16.200+的规则认为开发版加入了新内容，即使正式版不包含对应的实验性功能，也保持从属关系。我认为这两个规则是近乎完全相反，按理应该选择其一，个人倾向于1.16这种更合乎常理。在这一前提下，我再建议考虑为那些添加新内容的开发版划分出独立区域，而非像现在这样让人以为1.16.200+是为了下界更新搞了一堆开发版，具体的形式肯定不是能直接确定下来的，我只是提供参考，为的是说明目前确实存在一定弊端。-Jingji132（讨论） 2021年6月5日 (六) 03:53 (UTC)

“

You'll see more 1.16 versions before seeing 1.17. Increasing the second octet is still a little ways off, even though we're still testing Caves and Cliffs features. At the end of the day, it's just a version number.

你将会在1.17发布之前见到更多的1.16版本。进一步加入新特性还要走很多路，即使我们现在仍在测试洞穴与山崖特性。最后，它只是个版本号。

”

——mattgartzke

由上可见，官方也把1.16.200+当作了版本号，从未将它们视为洞穴与山崖的版本（开发版也如此）。而且若照此划分，许多版本的归属将会变得很奇怪，1.16.201、1.16.221，以及那些没有加入洞穴与山崖特性而加入其他特性的开发版，如RTX beta、1.16.200.53、1.16.210.50等，也和洞穴与山崖有从属关系？这一弄不就更让人不解了吗？不论如何，它们本质上就属于1.16（下界更新）的次版本或开发版，即使与下界更新关联不大，只不过它们被借去当作了测试洞穴与山崖特性的工具，没必要给它们单独搞个工具箱，用完了还是要回到1.16，不然Mojang不会在正式版移除这些特性。所以我还是认为 维持现状即可。补充说明一下，我关心的是1.16.200+版本的问题，1.2.13的问题我不作讨论。--XiaoXin666（T·C） 2021年6月5日 (六) 05:19 (UTC)（最后编辑于2021年6月5日 (六) 07:13 (UTC)）

你自始至终都没有讨论到人家的频道上去啊，Jingji132也明确指出他赞同目前1.16的版本分类现状，你“当做对方反对你的观点然后额外赘述一堆这些话”是没有必要的。他对于1.16的的观点与你是一样的，维持现状。如果不讨论1.2.13的问题，请不要发表不必要的言论。方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 15:58 (UTC)

本人只是就“添加新内容的开发版划分出独立区域”的建议而讨论，反对拆分独立区域而已（~~一开始我写的是反对拆分~~），不过没有想到什么好建议，只好维持现状。--XiaoXin666（T·C） 2021年6月6日 (日) 16:23 (UTC)

赞同，无论是从发布时间来看，还是从“都是1.2.13.x”来看，还是从特性的继承性来看，1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12都属于1.2.13的测试版，而非1.4的，纵使有1.4的特性加入，但是1.2.13正式版将这些新特性重新放回实验性玩法也不足以支持“这四个版本不是1.2.13”的开发版。首先，将新特性放入实验性玩法只是改动一行代码的事情，1.2.13正式版是基于1.2.13.12而发布的；其次，将新特性放入实验性玩法其实是正确的事，正式版是正式发布的，新内容可能尚有bug，没有充分的测试自然不能当做正式特性加入游戏，不管是这些特性放入beta，还是这些特性放入实验性玩法，他们的目的都是一样的，“测试新特性”，这是合乎常理的需求，跟“1.2.13正式版的测试版到底有谁”丝毫没有关联。目前把1.2.13的四个测试版归为1.4正式版的内容据我所知有页面分类和infobox、{{Development versions}}。希望速速更正。——方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 16:00 (UTC)

就是这个意思，至于我后面为的是提出“模板中无法突出洞穴与山崖这类更新从何版本进入开发阶段”这一问题，给出方案仅对该问题提供参考而非推荐。（而且其实1.2.13的测试版也是通过实验性玩法添加的水域特性，正式版是直接继承）-Jingji132（讨论） 2021年6月7日 (一) 02:06 (UTC)

更新携带版/基岩版版本记录中引用的链接

许多携带版版本页面中（例如携带版0.4.0）底部引用的修复漏洞列表由于mojang.com迁移的原因均已失效。三种修改方案：1.使用web.archive.org，访问该页面的存档。缺点是国内无法访问 2.使用bug.mojang.com的筛选器功能，筛选出在某个版本被修复的bug。 3.从英文站上直接复制。 MinecraftPig321（讨论） 2021年7月14日 (三) 04:40 (UTC)

建议使用方案3。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:05 (UTC)

沒辦法上傳圖片

設定完檔名及描述之後按上傳，會跳出一個視窗寫「過濾器在您的編輯自動檢測到了一項問題，您將暫時無法作出該操作。與您此次編輯所匹配的過濾規則概述如下：上传文件时未选择授权协议。」用這個網頁才能正常上傳：上傳檔案 --Zica87（讨论） 2021年7月23日 (五) 10:26 (UTC)

您上传文件时未选定授权协议，并且使用了中文文件名，因此被过滤器检测到，拒绝上传。请您检查您上传文件时的授权协议和文件名。MysticNebula70 _T 2021年7月23日 (五) 10:48 (UTC)

这其实是VE/2017SCE导致的问题，因为它们不支持选择协议。-- Dianliang233 ^T•_C

2021年7月24日 (六) 13:19 (UTC)

【对于一系列服务器小游戏是否加入的讨论】

我发现【掘一死战】是一个wiki页，为什么不将【起床战争】，【空岛战争】，【饥饿游戏】等加入Wiki？顺便添加一些技巧。

wiki不应该只加入客观内容，如【在服务器里PVP】等属于主观内容是应该保留的！

183.209.144.184 2021年7月24日 (六) 12:39 (UTC)热爱minecraft的某人

根据现行格式指导，“只允许加入Mojang Studios表示已经玩过的小游戏”，否则这类页面不具有足够的关注度，因而不应创建。掘一死战等页面的存在实属英文Wiki搬运时期的历史遗留问题，而且值得注意的是英文Wiki已有用户发起提议删除这类页面并将其转移至Minecraft服务器Wiki的讨论（见此），并获得相当数量的支持。所以非常 不建议继续创建这类页面。--葉月桐§ 2021年7月24日 (六) 12:56 (UTC)

我认为这些内容 不应该加入到主页面命名空间，但是可以加入到教程页面。--222.216.84.54 2021年7月26日 (一) 01:15 (UTC)

我认为此类内容正如上面所说，不应该加入到本Wiki当中，而不只是主页面命名空间。此前本Wiki也有过关于Mods的内容，但是也快被移动或删除完了，因为它们不具有足够的关注度，而且违反现行格式指导。--AblazeVase69188（论·功） 2021年7月26日 (一) 02:34 (UTC)

关于基岩版开发内容留存及去向问题

如题，中英文Minecraft Wiki上的基岩版开发内容（文档及教程）已经过时，严重程度不一。目前由于更新不及时（Mojang不更新en）以及基岩版开发Wiki的建立，这些内容的留存价值已经越来越小。

对于此问题，经初步讨论，现存有以下方案：

保持现状不加改变，发挥其仍有的价值。包括参考翻译等。
- 或使用{{Community Tutorial}}等信息框来标明现况提醒。
一刀切，全部从Minecraft Wiki移除，并软重定向至开发Wiki。
使用Tabber等方式使多版本并存。
欢迎踊跃提议。

--SkyE | Talk · Contributions · Logs 2021年7月27日 (二) 15:47 (UTC)

我个人是倾向于全部重定向到基岩版开发Wiki的，因为这里还没有专门的人去维护这些技术性内容页面，而且容易过时导致参考价值变低。--Lxazl5770_zh.admin（论 ▪ 功） 2021年7月28日 (三) 02:01 (UTC)

个人认为先提出一个较好的替代方案，再对旧的文档进行处理是一种比较好的方法。但如果仅仅只是把旧的文档一刀切，而对新的文档又没有任何翻译或其他措施去处理，倒还不如在开发wiki直接引条链接去en的原页。 ACR研究小組編輯（讨论） 2021年7月28日 (三) 03:48 (UTC)

从维护程度上考虑，我们无力维护这些文档，如果内容质量也没法掌控，不如移交给更有能力的人去做。但是Minecraft Wiki的引流导向作用还是要仔细考虑发挥好，不能让基岩版开发者找不到（如果真的）移除后的去处。--

Lakejason0（论•功） 2021年7月29日 (四) 07:18 (UTC)

提议修改命令语法格式

根据我和Miemie method的讨论，以及游戏内的情况，提议修改命令语法格式，按照游戏内文本表示：

不再翻译原来的[]<>()内的内容，同时取消斜体；
按游戏内方式使用[]<>()。由于Java版和基岩版格式不同，因此需要分别表示。

以上两条同时写入格式指导内。

有其他想法欢迎提出。MysticNebula70 _T 2021年7月29日 (四) 03:15 (UTC)（最后编辑于2021年7月29日 (四) 03:18 (UTC)）

实际上，在讨论这个问题的时候，技术性内容方面，坐标的表示方法也有待统一。目前游戏内的表示方法（命令返回文本）里为x, y, z，但作为页面来说这么写分割感/可辨识度不强，我们初步提出了使用(x, y, z)的表示方法。此外，单独表示某一轴的坐标也有待统一，比如Y=255。由于Minecraft坐标系与数学上右手系的标注不太一致，在讨论时有人建议将XYZ强制大写。希望在此议题中能够一并解决这个问题。
有关此次命令参数语法表示的修改，我认为若游戏内的表示方法具有统一性（基岩版是调用游戏内部类的所以应该是统一的）且满足wiki的表意需要，直接采纳即可。问题在于，虽然根据游戏内部机制，不翻译是对的（没人会翻译类名），但“不翻译括号内内容”可能会造成读者看不懂参数，反而造成读者体验的下降。如果能用一种方式达到表意和游戏内实际的结合，那我认为会更好。--

Lakejason0（论•功） 2021年7月29日 (四) 07:28 (UTC)（最后编辑于2021年7月29日 (四) 07:28 (UTC)）

~~为什么会看不懂参数~~把参数内容在下面解释清楚就行了，应该够了吧（MysticNebula70 _T 2021年7月29日 (四) 11:30 (UTC)

若无更多意见，将按照目前的提议修改命令语法格式。MysticNebula70 _T 2021年8月2日 (一) 03:16 (UTC)

同意。--

Lakejason0（论•功） 2021年8月2日 (一) 07:27 (UTC)

把“概念性”的armor一词的翻译改为“护甲”

众所周知，armor在Minecraft英文语境下有两种主要用法，一是表示人实际着装的一种衣物，常用语xxxx armor（XX盔甲）的词组，二是做概念性用法，表示一种虚拟的技术性词汇，比如armor value（护甲值）、armor toughness（护甲韧性）。正如我例子中所述，我提议，前者的armor一律翻译成盔甲不变，后者的armor改译成护甲。除了用于作语义区别之外，还有理由如下：1. 以护甲值为例，护甲值非常正常，而盔甲值要么使人不明所以，要么使人听懂但是说起来拗口；2. 社区在这种语境下用护甲的明显要比盔甲多，这说明盔甲一词不足以完全胜任armor的翻译，需要与护甲配合才能表达armor的全部意思。方法放寒假 (Talk - Contributions) 2021年8月2日 (一) 07:15 (UTC)

FYI相关游戏内字符串的键名：attribute.name.generic.armorattribute.name.generic.armor_toughness。--

Lakejason0（论•功） 2021年8月2日 (一) 07:30 (UTC)

弃用原有Infobox，改用PortableInfobox

原有的Infobox是基于Lua和<table>构建的。在UCP迁移后，我们又可以使用Fandom提供的PortableInfobox方案。

两种方案的优缺点：

原有方案

优点：

可自定义程度强
与en相同，方便搬运

缺点：

编写复杂
样式不现代，且有很大的历史包袱（参考FandomDesktop夜间模式）（en的样式已经变更）
使用<table>

PI

优点：

可根据社区样式自动适配，样式现代
SEO略好一些
编写较简单，甚至有GUI工具

缺点：

可自定义性较差
与en方案不同，需要花精力转换
会忽略页内转换规则（虽然在本wiki中页内转换使用不多，而且Infobox内貌似也没有此类用例）

现已有Lakejason0制作的实验性方案（使用了style，其实不需要）。

关于PI：

-- Dianliang233 ^T•_C 2021年8月3日 (二) 08:11 (UTC)

小声提醒一句，某个镜像并不支持PI，所以如果转向了PI，恐怕也还是要同时维护两个（虽然压力没听起来那么大）。--

Lakejason0（论•功） 2021年8月3日 (二) 09:18 (UTC)

在《我的世界：中国版》中的编辑错误。

本主题全部或部分段落文字已移动至Talk:Minecraft：中国版。

新页面

其实我一直想帮中文Minecraft Wiki添加新页面，可是中文Minecraft Wiki就好像万事俱备，已经没有什么东西要加下去了。所以我有什么新页面可以加的吗？–该未签名留言由ChiaLeeChuen（讨论 • 贡献）在2021年8月5日06:35(UTC) 添加。请在您的回复后面加上 ~~~~

为社区做贡献不只有添加新页面这一种途径.--Snow dash（论 & 功） 2021年8月5日 (四) 07:58 (UTC)

找错别字、移除失效链接、同步历史段落信息、扩充已有教程……这些都可以去做，不必拘泥于创建新页面。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:12 (UTC)

请问Wiki点数的计算公式是什么

就是这个页面：Special:WikiPoints

Wiki上没找到相关规定，搜索也没有相关结果。--QWERTY-5238（讨论） 2021年8月9日 (一) 05:47 (UTC)

It's a secret. 这里的用户都不知道。但可以告诉的是，相同条件下，首次编辑页面的分数会高一些。Plus，不要为了贡献点数去编辑。--Ff98sha（讨论） 2021年8月9日 (一) 05:53 (UTC)

意见：但行好事，莫问前程。--ultim_0 ( USER | TALK | CONT ) 2021年8月9日 (一) 05:58 (UTC)

网易我的世界的"演示模式"

本主题全部或部分段落文字已移动至Talk:Minecraft：中国版。

关于教程页的几个问题

请问“原创教程”的定义是什么？如果有人转载了其他网站的一篇教程，然后其原作者也过来完善教程，那么这到底算“原创教程”还是不算？Wiki是可以供所有人编辑的，因此“原创”到底按照哪个人的视角来看？页面创建者吗？
如果一篇教程即是“原创教程”又是“建筑教程”（或者其他类型），是否需要将这个教程放两个链接到{{tutorials}}模板上？我看到很多”原创教程“都没有这样做，如教程/跑酷，然而教程/NBT与JSON又即是原创教程又是技术性教程，那么到底应不应该在{{tutorials}}上创建两个链接？

求解。--QWERTY-5238（讨论） 2021年8月12日 (四) 12:23 (UTC)（最后编辑于2021年8月12日 (四) 12:44 (UTC)）

原创教程指的是“不从英文Minecraft Wiki翻译而来的教程”，如果是转载其他中文网站的教程，其大部分情况下不符合协议，那个页面有可能会被删除。这是一个遗留问题，与早年中文Minecraft Wiki的编辑方针有关。至于模板中如何摆放的问题，之前在群里有争论，但是没有结论，个人感觉可以放两次，但是我自己的教程只放了一次（放在数据包里面）。--

Lakejason0（论•功） 2021年8月12日 (四) 12:30 (UTC)

意见：

从其他网站转载教程到中文Minecraft Wiki尚无成功案例。
中文Minecraft Wiki的原创教程是与从英文Minecraft Wiki翻译的教程相对而言的。
支持将原创教程在{{tutorials}}标记为用户原创教程的同时放在相应的类别。

以上。--ultim_0 ( USER | TALK | CONT ) 2021年8月12日 (四) 12:34 (UTC)

!这个对于“原创教程”的定义着实有点奇怪。我这里的转载指的是符合规定的转载（例如已经获得作者许可，或作者明确可以转载），那么这种转载能算“原创教程吗？按你这个定义倒是算，但是分明是转载变成原创也不太合适吧。

意见关于那个放两次还是放一次的问题，感觉Wiki现在很乱（两种均可？）该整改一下了。我个人的建议是放两次。--QWERTY-5238（讨论） 2021年8月12日 (四) 12:46 (UTC)

Minecraft Wiki