<本站文本内容除另有声明外,转载时均必须注明出处。(详情…中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!Minecraft中文Wiki微博正在更新!或许有兴趣去看看想与其他用户进行编辑上的沟通?社区专页正是为此创建的。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。需要管理员的协助?在管理员告示板留言也许可以帮到您。>

Minecraft Wiki:社区专页

来自Minecraft Wiki
跳转至: 导航搜索
社区
专页
社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
涉及管理员权限的相关事宜请发布于管理员告示板
请了解,Minecraft Wiki在共识系统上运作而不是投票决定,清楚地阐述自己的理由比简单地支持争论的一方更有效。
常用页面
Minecraft Wiki不是客户服务中心!游戏问题请移步Mojang客户服务中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至此
Minecraft Wiki是永远不会完成的,新的页面每时每刻都在被添加。如果你想要添加某个页面并需要帮助的话,请添加到列表
请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。 ​
最新Wiki新闻
话题

我怎么创建我的用户页?[编辑源代码]

我想创建可以自定义、个性化的用户页,然而不管是在地址栏里输入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 head.png 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))

 中立偏向 支持。的确增长速度太快,而且大部分话题都无太大作用。-- LakeJasonFace.png Lakejason0) 2020年8月5日 (三) 14:07 (UTC)
 支持。不过我认为管理员告示板和社区专页的垃圾话题可以存档在同一个页面,如有必要,标明存档自哪个页面即可。--葉月 § 2020年8月5日 (三) 14:13 (UTC)
 支持。这种情况下至少可以在存档页里把有用的弄出来,减少无关垃圾信息。——Icyphantom 讨论I贡献 2020年8月5日 (三) 14:18 (UTC)
 支持这样可以排除垃圾话题,还可以提高每次存档时间间隔。--SnowFoxFace.png 北狐 2020年8月6日 (四) 05:57 (UTC)
 支持——垃圾话题查证价值不大,混在有益话题里面我觉得很碍眼。--Lxazl5770zh.admin) 2020年8月6日 (四) 09:09 (UTC)

垃圾话题存档页[编辑源代码]

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

如果这些话题基本上都是一些错置话题(且趋向一致),那么合并也无不可。-- LakeJasonFace.png Lakejason0) 2020年8月6日 (四) 09:06 (UTC)
另建存档就行了,比如无益话题存档123……虽然看起来像公 开 处 刑--Lxazl5770zh.admin) 2020年8月6日 (四) 09:11 (UTC)
这话怎么这么熟悉呢。-- LakeJasonFace.png Lakejason0) 2020年8月6日 (四) 09:39 (UTC)
取名的话可以稍微中性一点,比如折叠话题存档页之类的(这个名字很烂不要用)。-- LakeJasonFace.png Lakejason0) 2020年8月6日 (四) 09:39 (UTC)
管理员告示板上的折叠内容和社区专页的大方向似乎并不完全一致,而且管理员告示板上的部分折叠话题其实应该在社区专页提出。 MysticNebula70 ( T / C ) 2020年8月6日 (四) 14:38 (UTC)
同样是无意义话题,同样不具备参考价值,两者没有什么不同的地方,我觉得还是合并好一点。--Lxazl5770zh.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实际。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 03:58 (UTC)
也许每个页面给一个{{needs update}}足矣。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 04:02 (UTC)
怎么说呢,我的意思是,如果一个页面需要一个像wiki条例一样详细的注意事项,就不能用{{needs update}}117.181.15.209 2020年8月8日 (六) 05:53 (UTC)
你所说的情况 应该并不存在,如果有那么复杂的页面的话,那种页面也只会逐步拆分掉。为了维护方便,应该也不会允许如此复杂的页面存在吧。也许你想的东西不是你说的,但是就你所说的内容而言,我认为 不符合Wiki的维护需要。我非常 理解对页面维护没有什么太多规范感到的不安,但是我们毕竟有格式指导。如果你指的是教程的话,那么很遗憾Wiki目前没有人有能力巡查教程。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:13 (UTC)
以及,个人认为维护一个如此长的页面的更新注意事项,这本身和更新这个页面本身一样麻烦,因此我依然认为{{needs update}}(这个模版可以写入需要更新的原因)足以胜任目前的编辑提示/贡献指导的作用。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:13 (UTC)(最后编辑于2020年8月8日 (六) 06:19 (UTC))
也许你可以举一些例子来更好的描述你的想法。以及,如果可以的话,可以尝试注册账号。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:15 (UTC)
不不不,我所说的“和Wiki一样详细的注意事项”只是举个例子。而且,我并不理解“Wiki目前没有人有能力巡查教程”,当然,这不是重点。已经有事实证明格式指导并不像想象中的管用,一个较长的页面的几个项目之间难免有些内容上的重复,但因此就把它放到另一个项目去,又不太合适。而将页面拆分也有弊端。如果有一个专门为指定页面编写的贡献提纲,就能杜绝或减少这样的现象的发生。如果你们认为我指教程页面,其实就算“Wiki目前没有人有能力巡查教程”也没太大关系(当然是指非恶意编辑的情况),个人认为写出贡献提纲后,至少能给积极的IP编辑者一个奋斗的方向,迟早能把页面规范化。117.181.15.209 2020年8月8日 (六) 06:31 (UTC)
教程无人巡查主要指的是大部分教程都“过时”了。一些教程甚至是在Beta时期写的,又由于教程实在太繁杂,所以“没有人有能力定期(像主页面一样的细致)巡查”和像主页面一样维护。至于“有一个专门为指定页面编写的贡献提纲,就能杜绝或减少这样的现象的发生”,我认为这并不一定。虽然存在这么一个东西是好的,但是这个东西维护起来如果非常麻烦,那就是得不偿失。至于重复内容等格式问题,如果你发现了,可以当场修复并且写明编辑摘要。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:42 (UTC)
教程可不只是过时,标点和格式等乱七八糟的东西也令人头疼(我深有体会)。Sigma166讨论) 2020年8月8日 (六) 06:46 (UTC)
以及,如果给用户奋斗方向,你依然可以挂{{stub}}或者{{needs update}}并在模板参数里写明原因。如果需要很多行,也可以<br>。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:42 (UTC)
也许你也可能指的是在更新条目计划内搞一个类似于条目问题之类的子页面吧,我不知道实际维护难度怎么样(毕竟还没试过),但是我不持肯定态度。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 06:42 (UTC)
这玩意没人写,而且更新维护比原页面更麻烦,故此 强烈反对。-- DLFace.png Dianliang233 TC 2020年8月8日 (六) 06:36 (UTC)
如果有些页面的确比较混乱,或者不符合实际情况什么的,那就像Lakejason0说过的一样——“Do it yourself”。Sigma166讨论) 2020年8月8日 (六) 06:41 (UTC)
Wiki更需要的是解决问题而非仅仅去发现问题。如果发现问题立马就能解决掉,那就解决,不能解决就挂模板。行动可能更重要一些。-- LakeJasonFace.png 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)
还是希望你举出来哪一些页面存在这种问题。一部分人依然认为不存在。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 07:51 (UTC)
比如教程/不该做的事117.181.15.209 2020年8月8日 (六) 08:21 (UTC)
讲个笑话,教程/另类玩法。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 08:23 (UTC)
emmm,那好吧,希望你能够写点东西出来(毕竟看上去没几个人想动这种东西)。教程是个大坑,你要真有个办法也行。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 08:26 (UTC)
也许各位管理员对贡献提纲持怀疑态度。不过我认为可以为一个常有用户编辑的、格式谈不上规范的大型页面以子页面形式试验性地编写一个贡献提纲,看看效果如何,到时再做决定。117.181.15.209 2020年8月8日 (六) 07:30 (UTC)
沙盒,请。-- LakeJasonFace.png Lakejason0) 2020年8月8日 (六) 07:42 (UTC)
恕我们并没有这么多精力去写,不过你可以在沙盒里写一个出来。-- LakeJasonFace.png 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:沙盒/教程/不该做的事/贡献提纲。你们认为这份提纲是否有起到“让页面整洁美观”的作用?如果内容有用,是否有更好的办法让这个子页面的关注度提升?大部分人的论点是“没人会看”(类似于没人会看许可协议一样),因此如果这个提纲还行,关于此类贡献提纲关注度又该如何做呢?-- LakeJasonFace.png Lakejason0) 2020年8月9日 (日) 01:11 (UTC)(最后编辑于2020年8月9日 (日) 01:11 (UTC))

 中立,本人感觉有没有差不多。--ChemistChangTalk/Contributions) 2020年8月9日 (日) 01:16 (UTC)
目前还不能下结论,建议在28天后或84个百字节以上的编辑后再下结论.117.181.15.209 2020年8月9日 (日) 03:28 (UTC)

放在讨论页[编辑源代码]

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

 反对放在讨论页,但本人认为放在个人用户页是可行的。--ChemistChangTalk/Contributions) 2020年8月9日 (日) 01:16 (UTC)
个人用户页的关注度更低,个人认为并不符合话题提出者的意图。-- LakeJasonFace.png 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,告诉编辑者在编辑之前先认真阅读此页面的贡献提纲。--ChemistChangTalk/Contributions) 2020年8月9日 (日) 01:38 (UTC)(最后编辑于2020年8月9日 (日) 01:41 (UTC))

有关此方案的评价请在此子话题下提出。-- LakeJasonFace.png 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 head.png 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}}的方式我认为 可以。-- LakeJasonFace.png Lakejason0) 2020年9月6日 (日) 02:16 (UTC)

关于记分板与标签、队伍[编辑源代码]

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

希望删除,因为相关内容和记分板已经没有联系。--Skyicecn1讨论) 2020年8月9日 (日) 06:45 (UTC)
 支持。--SnowFoxFace.png 北狐 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,也许你想找的是那个。-- LakeJasonFace.png Lakejason0) 2020年8月10日 (一) 08:00 (UTC)
这里是Minecraft Wiki,不是Minecraft Server Wiki 。-- DLFace.png Dianliang233 TC 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)

如何回退文件?[编辑源代码]

我是个萌新,但我不知道回退图片文件。-- Xiaoyinface.png Duowan channel)2020年8月12日 (三) 04:39 (UTC)

图片-- DrLee lihr head.png 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)
 中立偏向 支持保留,如果现在拆分出来的内容有更多的信息量,我认为可以合并回原来的页面。-- LakeJasonFace.png Lakejason0) 2020年8月13日 (四) 01:44 (UTC)(最后编辑于2020年8月13日 (四) 01:45 (UTC))
 意见:个人认为拆分的标准在于单独页面的信息量是否足够。如果是都不够,那么我认为合并就可以了。如果一部分单独页面比目前合并页面的信息量更大,我认为可以拆分,并在合并页面的原段落加一个{{main}}。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 03:33 (UTC)
 中立偏向 反对保留,per below。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 10:13 (UTC)
 支持保留,看了一下,信息量根本不大,很多是一些滥竽充数的段落。个人认为存在信息量虚高的问题,应该合并回原来的段落。-- LakeJasonFace.png 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)
 意见:可以拆分一些内容较多的特性,较少的保留。--SnowFoxFace.png 北狐 2020年8月13日 (四) 13:48 (UTC)
 中立,但 偏向反对。一方面,主词条的确存在内容过多的问题,但另一方面,拆分又有可能会导致内容过于破碎,似乎更不易维护…?--Minesunset1030讨论) 2020年8月14日 (五) 01:52 (UTC)
 反对保留来源en。-- Xiaoyinface.png 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)
这边的预定假设是保留,所以大家都对保留提出意见。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 03:58 (UTC)
 反对保留,很多已移除特性在主词条的介绍太少,需要单独拆分出页面来。--ChemistChangTalk/Contributions) 2020年8月14日 (五) 10:03 (UTC)
没有的内容照样可以合并回原来的段落。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 11:22 (UTC)
 支持保留。不符合关注度原则,然后就是页面内容少得可怜,不足以支撑起一个页面,何况还是过时很久的信息。不是说变成独立页面就一定是好事。--Lxazl5770zh.admin) 2020年8月14日 (五) 14:20 (UTC)

猪灵条目需要猪人信息[编辑源代码]

我看过en:Piglin里的历史了,有猪人详细内容。-- Xiaoyinface.png Duowan channel) 2020年8月14日 (五) 03:17 (UTC)

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

MC地下城Wiki微标需要优化[编辑源代码]

en比较流畅,zh比较粗糙。MC地下城Wiki微标需要优化并同步en。-- Xiaoyinface.png Duowan channel) 2020年8月14日 (五) 03:23 (UTC)

 已同步。另,中文Wiki的共识运作不应完全受到EN的干扰。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 03:31 (UTC)

关于内含文字的图片的繁简转换[编辑源代码]

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

目前有的繁简转换,其格式也大多为:

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

目前存在的例子,比如File:DifficultyButton.gifFile:ArmorDamageFormula.svgFile:Smithing Table GUI.pngFile:AdvancementsInterface.pngFile:Subtitles.png等。

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

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

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

插入方式?[编辑源代码]

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

直接tr算是最粗暴的方法——在有更佳替代方案的情况下通常不会直接用的。可能的话可以弄一个模板来实现,但要保证这个模板和插入文件的语法差不多。——Icyphantom 讨论I贡献 2020年8月14日 (五) 04:02 (UTC)
目前的问题在于,一部分标签内部并不支持简繁转换语法,比如<gallery>,以及原英文名的重定向没有使用。-- LakeJasonFace.png Lakejason0) 2020年8月14日 (五) 04:04 (UTC)
這樣應該可以--Impulse Command Block JE5 BE2.pngLeo_leo_768(Talk|Contributions) 2020年8月16日 (日) 06:10 (UTC)
这样写的话,直接写文字描述不会被转换。-- LakeJasonFace.png Lakejason0) 2020年8月16日 (日) 08:30 (UTC)
不过文字描述用{{tr}}似乎可以。但是{{Inventory slot}}的话……用{{tr}}写文字描述就不行。-- LakeJasonFace.png Lakejason0) 2020年8月16日 (日) 08:34 (UTC)(最后编辑于2020年8月16日 (日) 08:35 (UTC))
手 動 轉 換 (-{}-)--Impulse Command Block JE5 BE2.pngLeo_leo_768(Talk|Contributions) 2020年8月16日 (日) 09:11 (UTC)
{{Inventory slot}}我只记得,描述部分只会原样输出任何文字(-{}-也一样)。-- LakeJasonFace.png Lakejason0) 2020年8月16日 (日) 09:22 (UTC)
我觉得可以写个模板来插入需要转换的图片。--SnowFoxFace.png 北狐 2020年8月14日 (五) 09:13 (UTC)
我在我的沙盒中写了一个这种模板,试验了一下,应该可以满足需求。--RedLightPOP·讨论 2020年8月15日 (六) 12:58 (UTC)
{{{1}}}是文件名,不含名字空间。--RedLightPOP·讨论 2020年8月15日 (六) 13:00 (UTC)

进一步补全?[编辑源代码]

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

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

将建立规范和制作方法写入格式指导?[编辑源代码]

有关此提案写入格式指导等页面的意见和建议请在这里提出。-- LakeJasonFace.png 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}}的重定向。

不知道写的怎么样,请大家提出意见。-- LakeJasonFace.png Lakejason0) 2020年8月21日 (五) 03:09 (UTC)

 赞成Odyssey08Face.png Odyssey08 [ T /C ] 2020年8月21日 (五) 03:25 (UTC)
这里的<图像原名称>指的应是Smithing Table GUI.png之类的名称。需注意的是,其并非直接在最后加入Simplified Traditional字样,而是在文件主名的最后、.的前面加入的。可对指导稍加修改以消除歧义。--RedLightPOP讨论 2020年8月26日 (三) 20:28 (UTC)

关于一个有歧义的句子[编辑源代码]

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

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

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

Information.svg 依据讨论页方针移除不合适评论。(原作者要求)

关于版本页面格式[编辑源代码]

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

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

  • 携带版/基岩版页面的{{Version nav}}格式不统一。
  • {{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)

目前格式指导已经移除了“漏洞不需要翻译”。-- LakeJasonFace.png Lakejason0) 2020年8月21日 (五) 03:21 (UTC)
如果大家有时间的话,建议和上面的问题放一起重整一下格式指导。-- LakeJasonFace.png 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 <版本号>.png Bedrock <版本号>.pngEdition时有时无,有些无版本号末尾的.0
    • Alpha阶段大部分直接Pocket Edition <版本号>.png没有Alpha

游戏内截图(一塌糊涂)

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

更新(中等)

  • 大多是官方发布的某一版本的海报、Logo和一些具有代表性的游戏内截图等。
    • <更新名称>.png <版本前缀> <版本号>.png(无更新名称的版本)等格式,有不加空格的,也有加the PE BE poster banner logo等字样的。

建议:“菜单界面”和“游戏内截图”使用<版本全名> [标识],“更新”使用<更新名|版本全名> [标识],且写入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 Enden:The End (biome)两个页面,一个讲维度,一个讲生物群系。可以参考一下他们的做法,维度和生物群系在同一页面也挺乱的。

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

 同意 但是en:The End (biome)仍在挂着wip模板,还是先不要动为好。--135ty議(Talk)/勛(Contribs) 2020年9月8日 (二) 13:05 (UTC)
 同意。--SnowFoxFace.png 北狐 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)

版本独有信息分类及其相关模板的整改方案[编辑源代码]

目前,本Wiki的版本独有信息分类情况较为混乱,一些页面对其相关模板的使用也未能形成统一的规范。为更好地维护这些分类,现提出以下整改计划。

分类

当前版本独有信息分类主要有两类,一类直接以“版本名称”为命名,另一类以“版本名称+独有信息”为命名,这两类分类内的页面基本都是通过使用模板归类的。此处以Category:Java版Category:Java版独有信息为例,前者包含使用了导航模板{{Java Edition}}与设置了java参数的通知模板{{Exclusive}}的页面,而后者包含使用了设置java等参数的模板{{Only}}{{In}}

问题主要出在Category:Java版上。该分类包含的页面可大致分为三种:

  • 第一种:介绍的内容是Java版的具体独有特性,且这些特性能够按游戏内容类型进一步分类,并纳入一些特性导航模板(如{{Blocks}}{{Environment}})当中。
  • 第二种:介绍的内容较难再按游戏内容类型进行分类,从而被纳入导航模板{{Java Edition}}当中。
  • 第三种:页面同样被纳入导航模板{{Java Edition}}当中,但其介绍的内容则并不能算是具体的游戏特性,只称得上与Java版有关(如Brigadier和其他各类开发资源页面)。

这三种页面需分别按照不同的原则添加模板以进一步分类:

考虑到页面信息的整理维护问题,被{{Exclusive}}标记的信息不宜直接归类到Category:Java版独有信息当中,否则可能会对修改与整理被{{Only}}标记的信息的工作带来麻烦。因此,建议新建分类Category:Java版独有特性(可讨论是否采用其他名称),将被{{Exclusive}}标记的信息归入其中。对于其他版本的相关页面,也采用相同的处理方式。如果有版本存在特殊情况,可以单独讨论是否为其建立这些分类。

调整后,独有信息分类将会增至三类,其定位及页面归类方式如下:

  • 以“版本名称”为命名的分类(一类分类):收集所有介绍的特性难以按游戏内容类型分类、且属于该版本的的页面,以及介绍内容与该版本有关但不属于特性的页面。此分类下的页面介绍的内容未必为该版本独有。
  • 以“版本名称+独有特性”为命名的分类(二类分类):收集所有用全篇去介绍该版本具体独有特性的页面。
  • 以“版本名称+独有信息”为命名的分类(三类分类):收集所有并未用全篇去介绍该版本的具体独有特性,但包含介绍这些信息的句子或段落的页面。
    • 通过使用{{Only}}{{In}}以及填写了{{{section}}}参数的{{Exclusive}}模板归类。
模板

为了适应分类的调整,需要对相关模板的功能及用法作出以下修改:

  • {{Exclusive}}
    • 使用该模板的页面将不再被归入一类分类,而将被归入二类分类。
      • 当该模板用于段落时,需填写{{{section}}}参数,同时将页面归入三类分类。
    • 所有应当被归入一类分类,但介绍内容并非游戏特性的页面都不应使用该模板,因为该模板本应用于标记特性。
  • {{Bedrock Edition}}
    • 需移除“独有特性”和“已移除”栏目下所有已包含在其他特性导航模板(如{{Blocks}}{{Environment}})中的页面,只保留不适合放入其他导航模板的页面(如角色创建器种子选取器等)。
      • 被从该模板当中移除的页面都不应使用该模板,应以其他对应的导航模板取而代之。
可能需要讨论的问题
  • {{Exclusive}}标记的用全篇介绍独有特性的页面是否应当按“版本名称+独有特性”命名?其他分类的命名是否需要改动?
  • Minecraft Earth和原主机版等相关页面较少的版本是否也有必要按此方法分类?

以上就是整改方案的全部内容。因涉及的页面较多,模板和分类的使用规范也长期未能形成,所以整改研究难度较大,方案可能存在漏洞,如有发现,请及时指出。也请各位思考与讨论最后的两个问题,或尝试提出其他可行的方案。--葉月 § 2020年9月16日 (三) 09:31 (UTC)

 信息Category:Java版之前被称为Category:Java版独有MysticNebula70 T  2020年9月16日 (三) 09:38 (UTC)

手机端MC地下城wiki微标需要优化[编辑源代码]

我试图优化了一下,但依然是旧的。所以需要优化并同步en一下。-- Xiaoyinface.png Duowan channel) 2020年9月16日 (三) 15:02 (UTC)

Can you DO IT YOURSELF? --Lxazl5770zh.admin) 2020年9月16日 (三) 15:58 (UTC)

需要创建中国版独有特性[编辑源代码]

中国版独有特性页面。-- Xiaoyinface.png Duowan channel) 2020年9月19日 (六) 06:53 (UTC)

首先,最基本的游戏机制上,中国版特性肯定和主游戏是没区别的。如果你是指Mod实体/Mod物品等等,这并不符合关注度原则(因为本质上是Addon)。如果你指的是其他的特性,由于关注度原则基本上也不会收录。目前,中国版相关内容仅应写在中国版页面。-- LakeJasonFace.png Lakejason0) 2020年9月19日 (六) 07:09 (UTC)
 反对。第一,中国版大部分独有特性像是mod(如天启之境);第二,中国版独有特性的数量不足以支撑页面;第三,中国版部分独有特性已在中国版列出 。--XiaoXin666T·C 2020年9月19日 (六) 07:24 (UTC)
 反对——首先,创建了谁来维护,谁来同步到en?其次,本wiki不再收录不属于原版游戏的mod内容,中国版那堆更新算原版内容吗?再者,关注度原则满足吗?--Lxazl5770zh.admin) 2020年9月19日 (六) 07:34 (UTC)
 反对。中国版的独有特性少且零碎,不建议单独写在一个页面。--Ultim 0讨论) 2020年9月19日 (六) 09:13 (UTC)
 反对。中国版的游戏内容基本上和对应版本国际版没有区别,如果您坚持您的观点,请说明理由。(chemistchangIP编辑)--111.41.250.111 2020年9月19日 (六) 09:37 (UTC)
 反对。目前大部分中国版的特性已经写在中国版页面了。关于天启:无限幻境之类的独特玩法,都是通过Add-on的方式实现的,不属于原版范畴。--Odyssey08Face.png Odyssey08 [ T /C ] 2020年9月19日 (六) 10:29 (UTC)

地下城“游戏内容”需要更新图标[编辑源代码]

地下城“游戏内容”的图表都是Minecraft的。急需更新新的关于地下城的图标。–该未签名留言由61.140.27.111讨论)在2020年9月20日 07:04 (UTC) 添加。请在您的回复后面加上 ~~~~

很遗憾我们并不明白你的意思。能尝试换一种表述吗?-- LakeJasonFace.png Lakejason0) 2020年9月20日 (日) 07:28 (UTC)
另,请使用~~~~签名。-- LakeJasonFace.png Lakejason0) 2020年9月20日 (日) 07:28 (UTC)
懂了,你指的是MCD:首页的图标吗?-- LakeJasonFace.png Lakejason0) 2020年9月20日 (日) 07:34 (UTC)
一个比较尴尬的一点是MCD中的图标有很大一部分都是纯白色的,不适合放在链接前。当然也有合适的,比如将角色皮肤改为Valorie,将生物改为钥匙傀儡,魔咒改为附魔点数?这些。-- LakeJasonFace.png Lakejason0) 2020年9月20日 (日) 07:41 (UTC)

关于携带版版本页面标题格式[编辑源代码]

如题,en现在把标题形如“Pocket Edition Alpha x.x.x”的页面全部移动到了“Pocket Edition vx.x.x alpha”,结合以前社区专页的相关讨论,我认为这样更加更符合携带版游戏版本本身的命名方式,原因详见之前的讨论段落,这里不再赘述。唯一有争议的地方是0.14.0-0.16.0的部分,游戏内标题界面并没有出现“alpha”的字样,此处是否应该认为Mojang是将其略去了?--SkyE | Talk · Contributions · Logs 2020年9月20日 (日) 14:07 (UTC)

0.14.0-0.16.0部分算是意外略去了吧,我觉得变成“携带版vx.x.x alpha”也是可以的。--Lxazl5770zh.admin) 2020年9月20日 (日) 14:10 (UTC)
个人觉得最好遵照游戏内标题界面,不添加alpha。--ChemistChangTalk/Contributions) 2020年9月20日 (日) 14:20 (UTC)
携带版Alpha0.1.0至0.13.0的游戏内标题界面都有alpha,但0.14.0至0.16.0的标题界面却没有。所以要遵循游戏内标题界面的话按理说是有alpha的,但0.14.0至0.16.0是例外。--Odyssey08Face.png Odyssey08 [ T /C ] 2020年9月20日 (日) 14:51 (UTC)
0.14-0.16的开发版的屏幕上方有关信息中依旧有alpha字样,因此是否可以认为是Mojang在标题界面右下角将其省略不写了而已?--SkyE | Talk · Contributions · Logs 2020年9月20日 (日) 14:57 (UTC)
按理说0.14.0-1.16.0游戏内虽然没写是Alpha版本,但是它本质上还是Alpha。再说了Java版1.0.0 Alpha在游戏内写的版本号还是inf-20100630-2。真的要统一还是加上Alpha吧,如果不加看上去反而还更乱。--_Regera_ 2020年9月20日 (日) 15:07 (UTC)
还有一个问题,携带版都按照游戏内右下角版本号写的话,基岩版的beta前缀就出现了去留问题。因为基岩版的右下角就没出现过beta前缀,包括开发版。--方法放寒假 (Talk - Contributions) 2020年9月20日 (日) 15:28 (UTC)
这里只讨论携带版版本页面的标题格式,有关基岩版的日后再谈。此外,也许右下角的版本号全部都是略写——见开发版屏幕上方的几行内容,其中是有beta前缀的。--SkyE | Talk · Contributions · Logs 2020年9月20日 (日) 15:36 (UTC)
携带版和基岩版不是同一个版本不同阶段的名字么。同一个东西应该一起讨论吧。还有,事实上目前基岩版所属于的大版本其实是beta,就像1.0之前大版本属于alpha一样,这个beta不是测试版的意思,和JAVA版的beta一个意思。你在开发版顶部看到的beta是这个beta不是测试的意思。正如0.xx.x的版本开发版顶部显示的是alpha一样,之后顶部显示的都是beta。--方法放寒假 (Talk - Contributions) 2020年9月21日 (一) 02:45 (UTC)