Minecraft Wiki

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

了解更多

Minecraft Wiki
Advertisement
该页面是Minecraft Wiki:社区专页的存档页,请勿编辑该页面。

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

目录

关于“现在”两个字

“现在”两个字有股机翻的感觉。如果是暂时的,“现在”是不能说的。--218.205.55.108 2020年7月5日 (日) 22:39 (UTC)

连语境都没有,不太确定你要说什么。-- LakeJasonFace.png Lakejason0) 2020年7月6日 (一) 00:33 (UTC)
如果是漏洞,“现在”两个字感觉是机翻。 --58.33.125.27 2020年7月14日 (二) 06:46 (UTC)
依然,没啥语境。如果看到奇怪的表述的话直接改掉就好了。如果是漏洞的话,有一些漏洞的原文就很奇怪。-- LakeJasonFace.png Lakejason0) 2020年7月14日 (二) 07:04 (UTC)
“软件”本来就是舶来品,所以更新日志用语有些偏西化也不可避免。 Cuervo(t) 2020年7月14日 (二) 14:51 (UTC)

关于基岩版脚本文档内名词的翻译

英文版基岩版脚本文档内有不少名词没有标准翻译,例如Minecraft Script Engine、binding、identifier,不知道怎么处理比较恰当 --Foxuser123讨论) 2020年7月12日 (日) 09:52 (UTC)

这类名称按照通常认可的中文译名来翻译就可以了。 MysticNebula70 ( T / C ) 2020年7月12日 (日) 11:33 (UTC)
感谢 Foxuser123讨论) 2020年7月12日 (日) 11:37 (UTC)

关于沙盒一拖再拖的问题

沙盒里有好多未完成的内容或者未翻译的界面,请尽快编辑沙盒里的界面。–该未签名留言由61.140.26.139讨论)在2020年7月13日 10:18 (UTC) 添加。请在您的回复后面加上 ~~~~

Wiki是像你(希望是你)这样的人一起编辑的,我记得IP用户就可以编辑沙盒。如果有能力编辑的话,建议你自己加入Wiki的编辑工作。更不客气地说,就是do it yourself。-- LakeJasonFace.png Lakejason0) 2020年7月13日 (一) 10:22 (UTC)(最后编辑于2020年7月20日 (一) 11:58 (UTC))

关于部分模板的参数

如题,英文Wiki已经将{{Block}}{{Item}}等模板的{{{nameid}}}参数移除;将{{Entity}}{{{drops}}}等参数移除,理由是和下文内容重复。中文Wiki是否有必要跟进? MysticNebula70 ( T / C ) 2020年7月13日 (一) 11:57 (UTC)

我认为,若是为读者方便考虑,如果读者习惯从侧边栏找信息,那么不跟进,如果不是的话弃用也不错。-- LakeJasonFace.png Lakejason0) 2020年7月14日 (二) 03:15 (UTC)
实际我认为EN移除{{{nameid}}}的一个原因是ID事实上和英文本身没啥区别,所以放侧边栏也没关注度,而中文不是。故 支持移除{{{drops}}},对{{{nameid}}} 中立。-- LakeJasonFace.png Lakejason0) 2020年7月16日 (四) 03:04 (UTC)(最后编辑于2020年7月16日 (四) 03:04 (UTC))
{{{drops}}}应该去除了,因为实体掉落物多变且受魔咒影响,放在侧边栏信息可能不全;至于{{{nameid}}},只要不是传递了错误的信息(比如基岩版的id和Java版不同),应该是可以保留的。--Lxazl5770zh.admin) 2020年7月14日 (二) 03:53 (UTC)
 支持移除{{{drop}}}参数,理由同上。{{{nameid}}}参数暂时没有太大意见,去留随意。--HlDoramon(7AlK · C0И7Я18z) 2020年7月15日 (三) 10:27 (UTC)因歧义故删除一条。--HlDoramon(7AlK · C0И7Я18z) 2020年7月15日 (三) 14:46 (UTC)

en考虑移除{{{nameid}}}(以及相关的{{{data}}}{{{multipledata}}})也有其他理由,毕竟还有部分页面的这一栏直接就填写了一个“见数据值”。另,删除这一参数可将{{Block}}Template:BlockTileEntity两个模板统一,有利于精简代码。 MysticNebula70 ( T / C ) 2020年7月14日 (二) 08:57 (UTC)

 支持移除,Infobox展示这些信息的效果有时并不理想。既然很多信息都已经单独成段且能够以更详细的形式展示,保留这些参数的意义不大。--葉月 § 2020年7月15日 (三) 10:24 (UTC)
 支持这些参数大多已过时,移除这些参数 比一大堆的“见xxx”简洁和有用得多。--HlDoramon(7AlK · C0И7Я18z) 2020年7月15日 (三) 10:27 (UTC)
 支持移除{{{drop}}}等参数。對於{{{nameid}}} 中立,因為其確實有助於讀者更快的找到ID--Impulse Command Block JE5 BE2.pngLeo_leo_768(Talk|Contributions) 2020年7月16日 (四) 02:59 (UTC)

是否需要翻译en:Minigames

我注意到中文Wiki目前没有关于小游戏的词条。现有的小游戏词条讲的是原主机版的小游戏,对应的是英文Wiki的en:Mini games(中间有空格)。 ——Lnn031537128(DGCK81LNN)资料页用户页讨论页贡献) 2020年7月19日 (日) 03:09 (UTC)

可以。考虑到关注度,建议将此页面搬运后将现有的“小游戏”条目重命名为“小游戏(原主机版)”。--葉月 § 2020年7月19日 (日) 08:30 (UTC)
 同意。ditto。-- LakeJasonFace.png Lakejason0) 2020年7月19日 (日) 08:44 (UTC)

工作台的中文译名要更改

中文Wiki为什么用维基百科

教程/恶意破坏的标题

该页面似乎更多在说如何防止恶意破坏,所以标题是否应该改为“教程/防止恶意破坏”?(原题目似乎意味着该页面在教玩家如何“恶意破坏”)120.244.142.56 2020年7月23日 (四) 11:40 (UTC)

确有不妥,且英文页面即为“griefing prevention”,故 已移动教程/防止恶意破坏 MysticNebula70 ( T / C ) 2020年7月23日 (四) 12:12 (UTC)

Java版1.9的快照页面中的格式问题

如题,Java1.9的很多快照页面中写的是“15w31c是1.9的第3个快照”而不是“15w31c是Java版1.9的第3个快照”(这里只是举了其中一个例子),这与其他版本不同,是否应该修改?Sigma166讨论) 2020年7月30日 (四) 05:50 (UTC)

 支持。--SnowFoxFace.png 北狐 2020年7月30日 (四) 06:39 (UTC)

历史遗留问题,请自行修改。--Lxazl5770zh.admin) 2020年7月30日 (四) 07:17 (UTC)

好的,我会找时间(可能明天?)完成这项任务。Sigma166讨论) 2020年7月30日 (四) 12:45 (UTC)

 已完成Sigma166讨论) 2020年7月31日 (五) 00:50 (UTC)

携带版Alpha版本名称问题

目前携带版Alpha版本在Wiki的命名方式有Alpha 0.x.xv0.x.x alpha等(包括但不限于页面标题、{{version nav}}模板的{{{title}}}参数等),除页面标题较统一外,其余名称极其不统一。游戏内,在0.13.0之前全部采用v0.x.x alpha的命名方式,0.14.0及之后全部采用v0.x.x的命名方式,0.13不详。可将页面内的版本名称作统一,统一为Alpha 0.x.xv0.x.x alphav0.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 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之类的名称。需注意的是,其并非直接在最后加入SimplifiedTraditional字样,而是在文件主名的最后、.的前面加入的。可对指导稍加修改以消除歧义。--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开发阶段以前版本大多无菜单界面截图。
  • 基岩版携带版)正式版的名称多为Bedrock <版本号>.pngPocket Edition <版本号>.pngEdition时有时无,有些无版本号末尾的.0
    • Alpha阶段大部分直接Pocket Edition <版本号>.png没有Alpha

游戏内截图(一塌糊涂)

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

更新(中等)

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

建议:“菜单界面”和“游戏内截图”使用<版本全名> [标识],“更新”使用<更新名|版本全名> [标识],且写入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)

目前模板和分类已按上述方案整改完毕。其中分类只针对Java版、基岩版和教育版进行了整改,其余版本的分类维持现状。如发现任何问题,请在此回复。--葉月 § 2020年9月28日 (一) 07:27 (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)
@Miemiemethod:可能是我没说清楚导致了误解,我认为的方案是按照屏幕上方的有关信息命名页面标题——这样beta前缀仍然会留在标题中。同理,alpha后缀也要全部留在标题中。--SkyE | Talk · Contributions · Logs 2020年10月23日 (五) 13:06 (UTC)

需要创建更多Texture atlas页面

terrain.png已经与英文统一了,还需要创建items.pngkz.png或更多Texture atlas。-- Xiaoyinface.png Duowan channel) 2020年9月28日 (一) 06:15 (UTC)

你以为我不想吗,但是页面内容都还没完善呢。还有,不要有事没事都来社区专页发帖,小心当水帖处理。--Lxazl5770zh.admin) 2020年9月28日 (一) 06:52 (UTC)

建议拆分Java版已移除特性

目前这个页面的内容已经过于杂乱以至于影响阅读体验了,并且现在也很不方便整理和维护。因此,我建议将所有的已移除特性全部拆分为单独的页面。--_Regera_ 2020年9月28日 (一) 11:35 (UTC)

#是否有必要将已移除特性拆分为独立的页面如上。--RedLightPOP讨论 2020年9月28日 (一) 11:38 (UTC)
拆分条目只是我能想到的整理页面的一种对策,现在这个页面的最大问题就在于格式太乱,这无论对阅读者还是编辑维护者都会带来一定的不便。所以我觉得需要另外想个对策来整理一下这个页面。--_Regera_ 2020年9月28日 (一) 11:58 (UTC)
5个东西在沙盒里。--61.152.208.142 2020年9月28日 (一) 13:58 (UTC)

关于Dungeons的译名问题

官方的中文译名已经发布了,但我个人认为这些翻译质量非常糟糕。我想听听各位的意见,是否要把新的官方译名作为Wiki的标准译名,还是沿用之前的民间翻译。--Lxazl5770zh.admin) 2020年9月29日 (二) 11:41 (UTC)

 反对 第一,翻译质量非常糟糕);第二,先前民间译名已经给了许多玩家初印象,保留也更容易让玩家接受,产生熟悉感。--Zyjking资料 / 讨论) 2020年9月29日 (二) 12:26 (UTC)
 反对 理由同上。--OasisAkari讨论·贡献) 2020年9月29日 (二) 13:16 (UTC)
 部分反对。繁体的部分我建议全部采纳游戏(放入转换表),简体则沿用,但是保留游戏内翻译的重定向。-- LakeJasonFace.png Lakejason0) 2020年9月29日 (二) 14:19 (UTC)
当然,所有的翻译采用以是否准确为最低底线,比如“Arch Haven”看成“Arch Heaven”这种问题就没必要采用而是直接在条目内指出即可。带命令块的《我的世界》并感-- LakeJasonFace.png Lakejason0) 2020年9月29日 (二) 14:33 (UTC)
回家再次嚼了一遍垃圾官译的大致情况,实际上比我想得好上一点。但是这些作为Wiki的译名标准化抑或是MCD页面的导语则甚至不能差强人意。仅针对游戏的翻译来说,没法满意,但是其实没那么糟糕;仅针对Wiki的使用来说,则完全不能胜任表意的要求。针对关注度问题导致的官方译名必须要存在于Wiki上的时候,我也依然倾向于只添加重定向。-- LakeJasonFace.png Lakejason0) 2020年9月30日 (三) 18:44 (UTC)
 反对 这个翻译太不走心了,除了极个别的翻译还不错可以借鉴之外,其余的翻译要么是照搬的民间汉化包,要么是直接带入了传统异能基翻引擎。这些翻译明显是找了不同的人分工翻译的,所以良莠不齐,建议民间汉化包借鉴一下优良部分,然后以民间汉化为标准译名。对于繁中,我的建议是除了他就是翻译的很奇怪或者错了,之外,一律按游戏内译名。繁中的翻译太走心了。并不是说繁中疯狂借鉴了民间汉化包就说他走心,而是借鉴之余可以明显看出又额外修改了很多用词错误,并且句子更加通顺了,虽然还有个别地方错误或怪,但已经可以称得上是一个非常好的翻译了。不像简中这边净会整些稀罕的。--方法放寒假 (Talk - Contributions) 2020年9月29日 (二) 14:24 (UTC)
 反对。只需建立重定向即可,像带有命令块的《我的世界》一样。--Ultim 0讨论) 2020年9月29日 (二) 15:17 (UTC)
 反对。这次翻译就是 局外人翻译 + 抄民间汉化包 + 基翻,除了部分翻译质量较好外整体糟糕,我甚至认为他们翻译都没有校对过,建议只建立重定向,不更改现有译名。--Light beacon (讨论 · 贡献) 2020年9月29日 (二) 15:54 (UTC)
根据各位的意见,目前决定Wiki以民间汉化包作为简体中文翻译的标准,而官方翻译作重定向处理。MysticNebula70 T  2020年10月1日 (四) 10:46 (UTC)

关于Dungeons标准译名列表跟进的问题

Dungeons已更新简繁中文,要不要跟进一下?--61.140.27.98 2020年10月1日 (四) 10:00 (UTC)n

简体中文翻译的讨论见上,我们已决定不采用官方翻译。繁体中文仍然有待进一步讨论。MysticNebula70 T  2020年10月1日 (四) 10:46 (UTC)

我硬动了!--61.140.27.98 2020年10月2日 (五) 13:47 (UTC)n

然而被叶月改了。顺便,提前提醒,不要做出违反社区共识的行为。-- LakeJasonFace.png Lakejason0) 2020年10月2日 (五) 15:20 (UTC)

(^.^)--61.140.27.114 2020年10月3日 (六) 00:49 (UTC)n

尝试推进话题+Lakejason0的提案

条目真实名称沿用民间的简体,将基翻简体作为重定向。繁体除了建立重定向,还在转换表内添加对应的词条,即使用繁体变体显示时显示游戏内的繁体名称。

由于游戏内的语言文件都是.locres,可以导出成.csv,我认为用脚本生成一个转换表不算困难。

例外是翻译错误,比如Arch Haven,那么全部采用民间译名,但是在条目内写出错误。

不知道这样怎么样。-- LakeJasonFace.png Lakejason0) 2020年10月6日 (二) 15:25 (UTC)

请--Lxazl5770zh.admin) 2020年10月7日 (三) 09:30 (UTC)

未命名的话题

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

我认为Wiki应该换一种方式为新手玩家们展示某种事物或者方块、事件等的介绍

建议使用表格方式来为新手玩家们展示(就像“历史”也采用了表格方式来显示,这样可以使新手玩家更方便找到自己想要的内容)--58.16.150.79 2020年10月1日 (四) 03:54 (UTC)

我建议加入“扁平化”之前版本的命名空间ID,以方便在玩家需要的情况下使用。--58.16.150.79 2020年10月1日 (四) 03:56 (UTC)

关于原主机版版本的问题

原主机版版本的interwiki问题

最近en已经完成了原主机版版本补全的工作,但是en的每个版本是相互独立的,这导致在zh里添加en的interwiki十分困难,请问大家谁有好方案解决这个问题,请在此处提出。--ChemistChangTalk/Contributions) 2020年10月2日 (五) 12:46 (UTC)

如果两个Wiki的页面不能很好地对应,就不用加Interwiki了。把更新内容相同的原主机版更新合并到一个页面是之前本地讨论的结果(见此),如果认为确实有加Interwiki的必要,可以征求en的意见,看看那边愿不愿意也合并这些页面。--葉月 § 2020年10月2日 (五) 13:27 (UTC)

关于en在原主机版版本中使用的模板问题

据本人观察,en那边发明了一个模板,只需要将版本相关参数(如时间)输入,即可显示版本更新内容,zh是否需要同步?--ChemistChangTalk/Contributions) 2020年10月2日 (五) 13:59 (UTC)

哪个模板?--Odyssey08Face.png Odyssey08 [ T /C ] 2020年10月2日 (五) 14:15 (UTC)
{{Console version}},如输入{{Console version|2016-10-28}}就会显示Xbox 360版TU45的内容。--ChemistChangTalk/Contributions) 2020年10月2日 (五) 14:27 (UTC)
 支持。不过不同平台的版本有些在同一日期发布。--SnowFoxFace.png 北狐 2020年10月3日 (六) 03:15 (UTC)
我记得这个模板好像有参数能解决平台问题。--ChemistChangTalk/Contributions) 2020年10月3日 (六) 14:03 (UTC)
要不我先搬过来?--ChemistChangTalk/Contributions) 2020年10月3日 (六) 14:05 (UTC)
此模板含有大量子页面,建议在搬运之前先讨论完是否确实需要使用、如何使用此模板(或者先只搬一两个子页面测试),否则可能会做很多无用功。--葉月 § 2020年10月3日 (六) 14:24 (UTC)

桌面版MC中文Wiki左边社区专页哪去了?

可能是迁移有关。--Duowan channel讨论) 2020年10月7日 (三) 09:07 (UTC)

已经反馈到Gamepedia。RealCuervo讨论) 2020年10月7日 (三) 09:09 (UTC)
UCP暂时不能读取MediaWiki信息,导致Sidebar、Sitenotice、转换表和页面标题等无法正确显示。这是已知问题,已向Gamepedia/Fandom汇报。请耐心等待修复。-- LakeJasonFace.png Lakejason0) 2020年10月7日 (三) 09:10 (UTC)

关于消歧义条目的编辑规范及同类索引条目的引入

受英文Wiki及其他一些因素的影响,本Wiki存在一定的滥用消歧义条目的问题。根据维基百科的编辑指引,消歧义是指消除“一词多义”带来的歧义。但一部分消歧义条目并没有体现其应有的功能,其中一些罗列了大量存在某些共性,而名称却完全不会带来歧义的事物(如动物),还有一部分条目则硬是给一些很难发生混淆的词汇进行了消歧义,有些甚至还会把一些几乎不会被关注的概念加进去,滥竽充数(如苦力怕(消歧义),还收录了“苦力怕视角”这么一个不知从哪个犄角旮旯挖出来的概念)。

为应对消歧义条目的滥用现象,建议为消歧义条目编写制定规范并写入格式指导,以供编辑者参考。另外,那些罗列了大量具有一定共性的事物的页面与维基百科的“同类索引”的功能较为相似,将这类页面改为同类索引页面可能也对此有所帮助。但如果选择引入同类索引条目,则也需要为这类页面制定一定的编辑规范,以防低价值页面泛滥。

总结一下需要讨论的问题:

  1. 是否应当为消歧义页面的编辑制定规范?具体需要哪些规范?
  2. 是否需要引入同类索引条目?同类索引条目的编辑具体需要哪些规范?

--葉月 § 2020年10月23日 (五) 12:32 (UTC)

首先一个像动物这类有着一类共性的页面应该创建索引,而不是“消歧义”。引入同类索引我觉得是很有意义的,将拥有共性但却在游戏中这类共性没有一定体现的创建同类索引。其次如果页面的关注度远远大于其它消歧义项,应在该条目内使用{{About}},而不是创建消歧义页面,并且这种情况下关联性不大或过于冷门页面的义项不应加入在{{About}}中。消歧义应当是为名称相同或极度相似的条目服务,不易弄混的概念不应创建消歧义条目。如果几个概念需要消歧义且不属于上两种情况,应该将消歧义页面作为该条目名称的页面,其消歧义项应移动到“条目名称(类型)”。--Light beacon (讨论 · 贡献) 2020年10月23日 (五) 13:36 (UTC)
现在的消歧义页基本上包括:
  1. 消歧义页;
  2. 定义一个概念,然后列出所有相关内容;
  3. 列出与某事物有关系的所有东西。
定义概念的玩意最好是变成一个普通页面(如果能解释清楚那玩意的话),然后另开一个列表列出相关内容。列出与某事物有关系的所有东西的话只能是同类索引。一部分消歧义页实际上只有一个定义,只是版本不同以及用途不同导致的拆分,这种我个人感觉更应该合并那些页面。顺带,最好能少点后面带括号的(不仅局限于“(消歧义)”,还包括提案通过后可能会添加的“(列表)”啥的),能不备注就不加括号,别到时候又是满山的括号。
现在的消歧义页,小部分是消歧义,一部分是概念内容,一部分就是强行Category。——IcyPhantom 讨论I贡献 2020年10月23日 (五) 13:59 (UTC)
 同意引入同类索引。目前Wiki的消歧义页面涵盖范围过广,确实需要进一步区分。我已制作模板{{Set index}}MysticNebula70 T  2020年10月23日 (五) 14:13 (UTC)
 意见:这些所谓的“消歧义”页面大多数已失其本心,与消歧义的目的背道而驰,甚至还会误导新人,使其误认为消歧义的本义即是同类索引,故:
 建议将这些“消歧义”页面以另一种方式表示。--Ultim 0讨论) 2020年10月23日 (五) 14:32 (UTC)
没必要,大家并不会因为你的一次过失就使劲记住这件事情。-- LakeJasonFace.png Lakejason0) 2020年10月24日 (六) 01:12 (UTC)
 同意引入同类索引,per above。-- LakeJasonFace.png Lakejason0) 2020年10月24日 (六) 01:12 (UTC)
 同意引入同类索引。消歧义页面最好有社区共识或关注度,本身是否容易混淆。当然顺便也能讨论两个义项的消歧义是否需要消歧义。某个同类索引是否需要的确定也类似前面说的,社区共识和关注度。比如游戏内概念、源代码中的概念或社区普遍使用的。Snow dash讨论) 2020年10月24日 (六) 03:43 (UTC)

关于铜制楼梯是否从楼梯页面中拆分出来

楼梯页面本身已经很庞大繁杂了,再加入新增的那些铜楼梯及其变种。或许会影响页面体验。是否可以按照材质,例如金属楼梯和其他楼梯,将铜楼梯区分出来单独介绍。--Snow dash讨论) 2020年11月5日 (四) 08:28 (UTC)

 反对。玩家在查阅这些方块的信息时很可能并不会给这些方块分类,所以拆分可能反而会给查阅带来麻烦。楼梯页面过长的很大一部分原因在于表格,其余信息并不至于繁琐到影响阅读的程度。将这些表格改为默认折叠可能对此有所帮助。--葉月 § 2020年11月5日 (四) 08:52 (UTC)

Grar VR和Windows 10 Mobile已停止MC更新了

从2020年10月31日开始Samsung Gear VR和Windows 10 Mobile已经停止Minecraft了,是否要更改?-- Xiaoyinface.png Duowan channel) 2020年11月9日 (一) 21:17 (UTC)

自己去改--Lxazl5770zh.admin) 2020年11月10日 (二) 02:29 (UTC)

是否需要取消Block模板和Item模板中的nameid参数

{{Block}}{{Item}}中的nameid参数的唯一目的就是显示命名空间id,但存在很多情况还无法清晰说明数据值,需要链接到数据值段落。而数据值段落和{{ID table}}模板都已经很完善。

我认为取消这个参数能简化信息框,并且也不会有太大使用上的影响。是否需要取消这个参数?Snow dash讨论) 2020年11月21日 (六) 06:47 (UTC)

 支持,信息框应该只作导航和基础信息介绍用。--RealCuervo讨论) 2020年11月26日 (四) 08:48 (UTC)

是否需要在小麦种子页面中加入时运对掉落物的影响

其他类似方块页面都有描述时运的影响,我写了个我的改动想法。是否可以在小麦种子#获取#种植一段中加入这些内容以详细且简介地描述时运的影响。--Snow Dash & ) 2020年11月28日 (六) 07:54 (UTC)

建议添加教程/菜鸟手册中的“控制”

在菜鸟手册中“控制”表格里,个人认为缺少了Q键(将主手持有物品以掉落物形式投掷出去)和F键(切换主副手物品),不知道要不要添加呢?shift键在骑行时按下会从所骑的生物身上下来;按住shift键右键点击功能性方块不会打开GUI,这一点也可能修改。还有,本人是个wiki新人,不太会修改呢,希望哪位大佬可以帮帮忙,修改一下 QWQ –该未签名留言由刘昊讨论贡献)在2020年11月28日 (六) 13:28 (UTC) 添加。请在您的回复后面加上 ~~~~(最后编辑于2020年11月28日 (六) 13:34 (UTC))

我们鼓励新手勇于编辑各种页面,无需过多担忧和向Wiki管理人员汇报。如果您不熟悉Wiki编辑方法,推荐您先阅读Help:帮助目录Help:编辑手册Help:编辑帮助等帮助页面。MysticNebula70 T  2020年11月28日 (六) 13:42 (UTC)
 已完成:追加关于F键的说明。另外记得用~~~~来签名。--Ultim 0讨论) 2020年11月28日 (六) 13:48 (UTC)

建议修改计划页面

建议在计划页面中增加“长期持续的计划”之类,来处理继续翻译或者启动器版本补全这类计划,因为它们都会与时俱进,随时都可能出现新的任务。 另外,在Launcher versions列表中,最后的“2.1.327”应为“2.2.327”,还缺少2.2.5xx与2.2.6xx两个页面。 ——139.227.244.122 2020年12月1日 (二) 11:32 (UTC)

计划页面并不是放置一直需要处理的事情的地方。本Wiki上需要持续关注的内容很多,计划页面不一而足。--RealCuervo讨论) 2020年12月1日 (二) 13:44 (UTC)

中文MCW怎么变成这个样子?

有很多地方都变成了英文,比如上方的栏目。--61.140.26.166 2020年12月11日 (五) 09:37 (UTC)

登录后可以手动切换显示语言为中文来解决,可能是迁移UCP后所致--OasisAkari讨论) 2020年12月11日 (五) 10:20 (UTC)
无法复现,可能与您的个人参数设定有关。--Ultim 0讨论) 2020年12月11日 (五) 10:30 (UTC)
该情况仅出现在未登录时,所以建议您登录或者注册。--211.64.159.23 2020年12月11日 (五) 10:35 (UTC)
我用的是手机桌面视图。--61.140.26.166 2020年12月11日 (五) 13:14 (UTC)
这似乎与视图无关,无论是桌面版还是移动版,均会出现类似的问题。--211.64.159.83 2020年12月11日 (五) 13:32 (UTC)
不就是难看亿点吗,我都背下来了!--183.40.227.136 2020年12月12日 (六) 01:38 (UTC)
请发送一下你的浏览器的HTTP请求头。如果你不知道怎么看,可以用这里的HTTP Headers段落Accept-Language栏目。--RealCuervo讨论) 2020年12月12日 (六) 08:18 (UTC)
Reproduced with header accept-language: zh-CN,zh;q=0.9 --Ff98sha讨论) 2020年12月14日 (一) 08:55 (UTC)
我在微机课上以IP登录时也是这个header,也就是我未登录时的留言(下面那个),<html>标签的lang属性是zh-Hans-CN,但界面语言是英文。-- LakeJasonFace.png Lakejason0) 2020年12月18日 (五) 11:12 (UTC)
未登录时,这边显示的<html>标签的lang属性依然是zh-Hans-CN,但界面语言依然是英文。一般来说正常的MediaWiki软件一般是对应的才对。--117.71.48.166 2020年12月14日 (一) 03:57 (UTC)
总结一下吧:虚无世界wiki中文有问题,而此wiki日文没有问题。是不是中文的事?--61.140.27.69 2020年12月18日 (五) 12:58 (UTC)

社区专页签名按钮缺失

请尽快修复这个漏洞。--183.40.227.136 2020年12月12日 (六) 01:40 (UTC)

属于MediaWiki新特性,无法修复。输入四个波浪号不是什么难事。--Lxazl5770zh.admin) 2020年12月12日 (六) 11:13 (UTC)
那么,请删除关于文档。--14.30.144.166 2020年12月13日 (日) 00:46 (UTC)
不知道你想表达什么。--Lxazl5770zh.admin) 2020年12月13日 (日) 01:28 (UTC)
可能与MediaWiki的一项关于签名的命名空间的LocalSettings.php设置有关,由于是后台设置,管理员可能无权修改。--117.71.48.166 2020年12月14日 (一) 03:42 (UTC)
目前只有社区专页和管理员告示板才会出现签名按钮缺失的问题(因为没有被识别为讨论页),修复办法待查。另外,确实,我们无权修改上述的后台设置,因为我们不是整个网站的所有者,我们只是负责管理本wiki志愿者团队。--Lxazl5770zh.admin) 2020年12月14日 (一) 04:37 (UTC)
如果的确需要这个功能的话可能需要编写一点Gadget(自定义JS的部分),但是我不会写,目前需求不大也没人会特别写一个。-- LakeJasonFace.png Lakejason0) 2020年12月19日 (六) 07:42 (UTC)
 已修复 测试→ --RealCuervo讨论) 2020年12月25日 (五) 07:28 (UTC)
注:这段代码放到了Common.js里面,而非上述所说的Gadget。--117.71.48.166 2020年12月25日 (五) 07:33 (UTC)

在内容空间加入音效段落的条件是否成熟?

所有Java版音效已经全部整理完毕,可以在我的音效表查看所有方块、实体与物品的音效事件(除了音符盒和鹦鹉模仿事件),全文无红链。HLD的音效表还有其他环境、唱片和粒子音效。

没有明确在我的音效表中说明的方块基本可能是使用预设的,也可以去英文wiki对应页面查看用法。

File move to do list:这里是之前移动文件的记录,绝大部分和音效整理相关的文件移动都记录在此。其他有疑问可以咨询我。

{{Sound table}}的预设模板也已经全部设置好,大部分方块都需要使用预设。

还有一点需要注意:鹦鹉模仿以及发射器、投掷器发射成功失败、压力板、按钮、红石比较器等方块的“咔哒”声是有后期处理的,声音文件只有一个Click.ogg,而很明显发射成功和失败有细微差别,因此这类处理需要另外生成新的文件,游戏文件无法直接使用。我无法处理这个情况。(刚刚查看英文发射器页面,发现en也没有处理发射成功与失败的区别。)

并且基岩版和MCD的音效也还未处理。

综上,虽然问题还有一些,并且工作量很大,但我觉得在内容页面加入Java版音效表格的条件已经成熟。是否可以开始在内容空间加入音效段落和音效表格?--Snow Dash & ) 2020年12月25日 (五) 04:30 (UTC)

 同意,可以到计划页面创建一个新的项目。--Lxazl5770zh.admin) 2020年12月25日 (五) 05:40 (UTC)
 支持。(From Lakejason0,未登录)--117.71.48.166 2020年12月25日 (五) 06:57 (UTC)

还有一点:1.17的新音效完全还没处理,上传文件时请按照方块/实体id首字母大写+动作的格式,例如File:Budding_Amethyst_step1.ogg,采用游戏文件的命名。上传后可以补充到音效表中。--Snow Dash & ) 2020年12月25日 (五) 07:41 (UTC)

通知显示的页面更改不完整

在“通知”一栏显示的其他用户对您监视页面的更改显示不完整。

例如,有其他用户在您所监视的某个页面进行了多次修改(在Special:最近更改中会被折叠),但是“通知”一栏只会显示该页面所做的第一次更改,随后的更改在“通知”一栏不会显示。这可能会使用户直接在第一次修改处作更改,稍不小心就会将后来的所有编辑覆盖掉。

希望能够尽快修复。另外,这是MCW的问题,还是Gamepedia的问题?--AblazeVase69188讨论) 2020年12月31日 (四) 13:35 (UTC)

改不了,这是gp故意而为的。另外,如果编辑的是旧版本,编辑界面顶部会有黄色警告文本。--Lxazl5770zh.admin) 2020年12月31日 (四) 14:29 (UTC)
Advertisement