Minecraft Wiki

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

了解更多

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

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

关于首页大段空白的问题

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

讨论结果为 已应用新布局


本人的多个设备以及部分尝试了查看首页的群友在打开首页的时候均会在“Minecraft简介”和“本周页面”底部显示大量空白。这是否是一个需要处理的问题? North kun留言) 2022年6月18日 (六) 04:12 (UTC)

 支持:中文表达所需空间比英文要少,套用以前英文版的排版必然会存在空白。不过其实现代汉语的版本还算好,文言版的首页空白那才是惨不忍睹。--Yzy32767/ 2022年6月18日 (六) 04:30 (UTC)
之前也不是没讨论过,当时提出来的时候没人理。至于已经停止支持的游戏,我个人的意见是写上去并标注好。至于MCD和Legends,MCD由于在MCD Wiki首页中已经写了,但是在这里不写又不是很合适,所以我建议可以略写一下;Legends也是相同的道理。--KaplanSteve  T/C 2022年6月18日 (六) 07:10 (UTC)
似乎是为了和旁边的“开始游戏!”对齐。--McplayerFS讨论 | 贡献) 2022年6月18日 (六) 14:12 (UTC)
可以考虑缩减“开始游戏!”的高度,但是我还是弄不明白这些框的大小是在哪里指定的,希望不要动CSS。--Yzy32767/ 2022年6月19日 (日) 01:08 (UTC)
英文版本的版本信息是放在下面的,这样就无需考虑其高度问题。但同样的,就得考虑其他部分的内容宽度和高度问题。-- LakeJasonFace Lakejason0) 2022年6月19日 (日) 13:13 (UTC)
我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770zh.admin) 2022年6月20日 (一) 02:33 (UTC)
并不是“插入”的问题,而是重新整理,重新排版的问题。-- LakeJasonFace Lakejason0) 2022年6月20日 (一) 03:01 (UTC)
重新排版确实有必要,不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 T  2022年6月20日 (一) 05:30 (UTC)
仿效en的排版其实也不错,把你知道吗换成每周页面如何呢?-- LakeJasonFace Lakejason0) 2022年6月21日 (二) 04:04 (UTC)
 意见:en的“你知道吗”板块也有留白,然而如果把每周页面替换进去的话,有可能会空间不足。我建议是要么限制一下每周页面的字数,要么把“关于Minecraft”扩写一点。--KaplanSteve  T/C 2022年6月21日 (二) 14:38 (UTC)(最后编辑于2022年6月21日 (二) 14:39 (UTC))
en主页上的版本信息一栏内容所占空间显然比zh的多,如果仿照其把版本信息一栏的宽度扩展到整个页面的做法,其高度将明显减少。虽然我没有具体试过,但观感肯定不好。--AblazeVase69188讨论 | 贡献 2022年6月24日 (五) 12:57 (UTC)
 留言:浏览首页及相关页面(Minecraft Wiki/style)可知,首页的栏目布局的代码见于MediaWiki:Gadget-mainpage.css,其中与首页栏目布局相关的内容如下:
目前的布局 ultim_0建议的布局之一
a
b c
d
e f g
h i j
a
b
c d
e f g
h i j
其含义是:当页面宽度较宽(大于等于990px)时,将各栏目按右表1所示的方式进行排版。“Minecraft简介”(#fp-2)和“每周页面”(#fp-4)对应的就是b和d的位置。
综上所述,通过修改MediaWiki:Gadget-mainpage.css的相关内容(已在上文标出),即可在不改变首页源代码的情况下更改页面排版形式。
 关于重新排版:经本地测试,将布局改为右表2所示可明显避免出现过多空白。
但是根据群友(既然北鲲使用了这个称呼,那么用在这里应该也没问题)反映,这会导致“每周页面”在部分宽屏设备上出现排版异常的情形(在下的屏幕只有1366px宽,难以预览大屏幕下的情形),建议一并修改Minecraft Wiki/weekly/style。--ultim_0 ( USER | TALK | WORK ) 2022年6月21日 (二) 16:08 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
我根据Ultim的提案制作的最终提案如下。
还有一些其他的方案。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 06:07 (UTC)(最后编辑于2022年6月22日 (三) 06:42 (UTC))
由于测试过程中发现了一些新问题,在此说明一下问题以及一些新的提案。
问题1:首页的每周页面图片有浮动,会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。
问题2:版本信息一栏方格下方的列表观感不好,词汇会断开,而且横向列表在列表项目不多时展示效果较差。
基于以上发现的两个问题,我又查看了其他语言站点的首页,相关情况如下:
英文:版本信息单独出一整个横栏,所有的购买链接和版本号放在一起。
西班牙语:重新设计了首页,将版本信息删除。
由于版本信息写全似乎冗余,在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 06:48 (UTC)
韩国语wiki首页的布局 ultim_0建议的布局之二
a
b c
关于外来词
e f g
h i j
a
b c
d
e f g
h i j
注意到韩国语wiki相对于en也对首页排版进行了小幅度修改,如右表1所示,其中的“关于外来词”是其独有的栏目,对应zh的“每周页面”,除此之外的各个字母表示的内容与zh相同。根据其样式给出了方案二,如右表2所示,该方案可以避免方案一中“每周页面”栏目因为宽度过小而出现排版异常的情况,因此无需同时修改该栏目的样式。谨供参考。--ultim_0 ( USER | TALK | WORK ) 2022年6月22日 (三) 07:14 (UTC) (最后编辑于2022年6月25日 (六) 18:39 (UTC))
我在Editcopy中修改了一部分代码,将购买链接和试玩链接直接添加到了版本信息方格中。这样就可以解决问题2(通过直接删除、转移到版本方格内的方式解决)。由于这样的更改会导致先前的版本号合并不再可行(链接显示会不完整),我暂时先放在那边。-- LakeJasonFace Lakejason0) 2022年6月22日 (三) 08:01 (UTC)
在处理横向列表的时候发现了EN的一个做法,就是把购买链接写在对应的页面,而不是直接写到首页。这样也更便于维护。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 07:24 (UTC)

没有人讨论吗?那我再把方案二需要修改的地方指出来:

至于版本信息(“开始游戏!”)的处理,个人并无较好的提案,建议将购买和试玩的链接移动到对应页面的{{infobox}}中。

以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月6日 (三) 10:33 (UTC) (最后编辑于2022年7月6日 (三) 12:03 (UTC))

然而这个方案里的“Minecraft简介”留的空间太少,个人建议与旁边的“开始游戏”同宽。--Yzy32767/ 2022年7月6日 (三) 10:57 (UTC)
不太可能,那样解决不了Minecraft简介的空白过多吧?-- LakeJasonFace Lakejason0) 2022年7月6日 (三) 11:00 (UTC)
已经足够了,在宽度为1366px的屏幕上,该方案中的简介栏高度与版本信息相同。--ultim_0 ( USER | TALK | WORK ) 2022年7月6日 (三) 12:03 (UTC)
其实可以把Minecraft简介改成en的Minecraft video game样式,这样无需改动布局即可填充空白,我会在稍后将代码放至editcopy下。旁边的图片尚未上传,我会先注释掉。--Yzy32767/ 2022年7月15日 (五) 07:28 (UTC)
 同意Yzy32767的做法,少去了更新布局的麻烦,并且这样也可以避免较多的留白。只是这样的话需要保证每周页面的内容不多不少(本周的烈焰人就是个例子)才能避免留白过多或超出范围。--KaplanSteve  T/C 2022年7月15日 (五) 07:38 (UTC)
没事,周页差不多都是这个长度,这周的甚至还超出了一点,导致1003宽度下版本留白过多。--Yzy32767/ 2022年7月15日 (五) 09:08 (UTC)
将代码写入editcopy后遇到了以下问题:
  1. 版本信息处在2036px宽度后开始出现较严重的留白。
  2. 移动端窄视图下“Minecraft游戏”的右侧图标显示过小。--Yzy32767/ 2022年7月16日 (六) 05:13 (UTC)
或许可以借鉴一下德语和西班牙语的首页。有用户提出“重要的东西除了版本号以外都缩在一个角落里,换做谁也不想找。”“版本信息图标过大,和下面的小字相比就是失衡的。”而德语和西班牙语的首页完美解决了这个问题,将重要的页面如交易、酿造,包括MCD的内容都放在了首页,版本信息也使用了小图标。只是如果我们也这么做,可能会涉及到MCD的首页的改动问题(比如把内容合并到主首页或重新布局)。并且这么做的话等于现在为止做的全部都是白费。
总之,保留现在的设计也可以,但是要解决Yzy32767提出的问题;也可以推倒重来,做成像德语一样的的首页,只是不需要那么多东西,可以删减一些。如果采用德语的设计,个人建议把版本信息收窄,放到右边(德语的留白太多),然后把“你知道吗”板块改为“本周页面”,并放到5个游戏介绍(或者像西班牙语一样拆开来变成7个)下面。
以上是我的提议。--KaplanSteve  T/C 2022年7月16日 (六) 05:29 (UTC)
问题1已通过flex-shrink: 0;样式解决。为了让图标在移动端不占据过多空间,对其进行了一定程度的缩小。此举也使得整个“Minecraft游戏”的高度降低,问题2稍有改善。然而考虑到主页的版本区(“开始游戏!”)没有试玩和下载链接,留白较editcopy会更严重,故建议重新设计“开始游戏!”板块。--Yzy32767/ 2022年7月16日 (六) 23:01 (UTC)
版本板块预计更改内容如下:
  1. 取消田字布局,改为直接竖向排列。
  2. 取消每个版本的背景颜色,以分割线分割各版本。
  3. 文字居左(“更多”除外)。
  4. 将平台呈现方式从上图下字换为图文同行(需更改/platform,个人沙盒里已有实验性代码)。
  5. 移除下方hlist。
群内已有预览图。--Yzy32767/ 2022年8月4日 (四) 09:58 (UTC)
版本的更改已在editcopy中完成,还有其他的建议请提出。--Yzy32767/ 2022年8月7日 (日) 04:43 (UTC)
Apple Safari浏览器在窄屏移动端视图下,“Minecraft游戏”里面所有flex容器框都会异常拉伸,超出屏幕左右两边,原因未知。--Yzy32767/ 2022年8月13日 (六) 01:34 (UTC)
已解决。目前还需要处理深色模式的适配,以及整理代码。--Yzy32767/ 2022年8月26日 (五) 01:05 (UTC)
 已更新首页。如有问题请开新话题。MysticNebula70 T  2022年9月4日 (日) 03:52 (UTC)

有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议

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

讨论结果为 将相应表述写入格式指导


行政员Lxazl5770在处理用户Louis0921gee有关画廊中说明文字句号的编辑时,引起了该用户对格式指导相关用法的疑问。

经查询,此说明于第一个版本写入格式指导,因此其实算是历史悠久的。相关疑问在中文Minecraft Wiki用户集中的地方也出现过数次(据用户口述可能有四次之多),而根据后来各用户的讨论,发现由于这些疑问的讨论,各用户甚至管理员似乎存在一个错误的印象,即认为这个问题已经解决,且解决方案是按照中文维基百科目前的方案(也就是“存在于图表中的短语式说明文字,其中部内容可用逗号,但末尾不用句号。就算是有些时候说明文字内容比较长,在前面的语段中已出现句号,最后的结尾处仍不用句号。”)执行。但这不是事实,这没有写入格式指导,且事实是这些疑问都是不了了之,并没有得出结论。

由于执行标准不一,实施情况不同,根据维基百科标点符号用法(中华人民共和国国家标准GB/T 15834-2011)的相关说明,我在此提议更改格式指导有关图像介绍的说明文字的末尾句号用法的说明:

旧:图像介绍末尾不应有句号,除非语句是一个完整的句子。

新:图像介绍的说明文字末尾不用句号。就算是有些时候说明文字内容比较长,在前面的语段中已出现句号,最后的结尾处仍不用句号。

我的提议如上。希望各位用户参与讨论。-- LakeJasonFace Lakejason0) 2022年6月29日 (三) 10:38 (UTC)(最后编辑于2022年6月29日 (三) 10:55 (UTC))

 我的提议:一律不用句号,并且将原本的说明文字精简到一句话以内。以简化繁。--Lxazl5770zh.admin) 2022年6月29日 (三) 13:43 (UTC)
这种要求不一定都能实现。建议将我的提案作为保底规则,然后将您的提议作为优先规则。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 07:11 (UTC)
由于管理员提出了新的意见,我的新提案如下:
旧:图像介绍末尾不应有句号,除非语句是一个完整的句子。
新:图像介绍的说明文字应精简到一句话以内。当且仅当图像内容足够复杂,需要使用超过一句话才能说明清楚时,可以超过一句话,但最后的结尾处不用句号。即使说明文字在多句话的前面的语句中已出现句号,最后的结尾处仍不用句号。
以上是我的新提案。如有更好的表述也欢迎提出。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 10:43 (UTC)(最后编辑于2022年6月30日 (四) 10:44 (UTC))
这应该是两条:
  1. 图像介绍应精简到一句话,图像内容足够复杂、说明清楚需要超过一句话的除外;
  2. 图像介绍末尾不应有句号,即使说明文字较长,前面的语段已出现句号。传入神经元权限|讨论|贡献|日志) 2022年6月30日 (四) 17:09 (UTC)
应该要求编者尽力把图像介绍缩短至一句话。如果句末不加上句号,在前面的句子中又出现了句号,会显得有点奇怪。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 01:06 (UTC)
说不清楚的怎么办?这种用法是国标,不奇怪。传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 02:10 (UTC)
我所提到的“奇怪”指的是对某些读者来说不适应这种用法。当然如果一句话说不清楚,多加几句话也没问题。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 02:38 (UTC)
图像描述过长还会影响网页观感(尤其是移动端)。若图像内容足够复杂,我建议先写简要介绍,再用注释加上详细描述。IbuckeeetFaceIBUCKEEET ·· 2022年7月2日 (六) 05:01 (UTC)
在本来就是说明文字的地方再加注释,我不是很能接受这种做法。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 06:07 (UTC)
由于此议题没有进一步推进,我再次提出提案,希望各位给出意见:
旧:图像介绍末尾不应有句号,除非语句是一个完整的句子。
新:图像介绍应精简到一句话以内,图像内容足够复杂、说明清楚需要超过一句话的除外。即使图像介绍的说明文字较长,其中靠前的语句已出现句号,末尾也不应有句号。
希望提案采纳。-- LakeJasonFace Lakejason0) 2022年7月6日 (三) 10:52 (UTC)
 支持。--AblazeVase69188讨论 | 贡献 2022年7月9日 (六) 13:48 (UTC)
由于没有更多反对意见,且先前的疑问基本已解决,相关提案 已应用。-- LakeJasonFace Lakejason0) 2022年7月16日 (六) 08:21 (UTC)

【重要】关于本wiki的封禁准则

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

讨论结果为 已设立封禁准则


目前,尽管本wiki已经有了一则详细的条例,但在处理封禁方面仍无具体的准则。

为此,本人以行政员的身份拟定了一份封禁准则的草案希望能够听取各用户的意见并加以改进。

此事项相当重要。望各用户积极建言献策。祝各位编辑愉快。--Lxazl5770zh.admin) 2022年6月30日 (四) 12:50 (UTC)

粗略查看了一下。目前该准则缺少对于先前使用较多的“提示性封禁”这一用法的说明。同时,我认为应当在该准则开头以较为亲切的口吻,使用Msgbox说明好,封禁是wiki维护与破坏防治中靠后的环节,管理团队不会对(绝对否定的说法可以自行修改为较为缓和的语气)轻微的不熟练操作采取封禁这一手段,等类似的内容。同样,应该在Wiki条例当中提及违反条例会按照封禁准则封禁。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 12:55 (UTC)
我已经根据你的说法进行了适当修改。--Lxazl5770zh.admin) 2022年6月30日 (四) 13:16 (UTC)
  • “目标用户无视任意警告(例如撤销编辑或讨论页警告)”“管理人员在条件允许下应当在目标用户的讨论页里留下{{User warning}}以提醒该用户注意遵守Wiki条例”这些前戏应该统一,例如目标用户无视管理人员在目标用户讨论页留下的{{User warning}}。
  • “匿名用户不允许永久封禁”推不出“封禁时长应当不超过1年”,留后半句就够了。
  • 未尽事宜应该有个限制,例如不违反条例和applicable law的行为不应受到惩罚性封禁。
  • 为什么设置那些不保留讨论页申诉权的情况?申诉权就是被封禁用户的权利,滥用申诉权的才应该撤销。传入神经元权限|讨论|贡献|日志) 2022年6月30日 (四) 17:09 (UTC)
第二点把关联词移除掉就没问题了。其他的都算有道理。-- LakeJasonFace Lakejason0) 2022年6月30日 (四) 18:38 (UTC)
 留言:对于使用可视化编辑器破坏页面源代码的行为,是否应当在封禁摘要中说明?--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 02:28 (UTC)
我建议是先警告,若忽略警告再考虑封禁。--KaplanSteve  T/C 2022年7月1日 (五) 02:33 (UTC)
已经修改。特别地,部分违规情况属于极其恶劣的情况(例如发广告和利用傀儡破坏),不应当给予其申诉权。--Lxazl5770zh.admin) 2022年7月1日 (五) 03:01 (UTC)
只要违反格式指导就给予一天封禁太过严重。违反格式指导的理论上没有封禁的必要,只需要给予提醒即可。屡次不改本身就违反条例。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:08 (UTC)
以及,利用傀儡破坏本身并不绝对属于极其恶劣的情况(取决于做出的破坏行为本身),因此不保留申诉权利并不合理。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:15 (UTC)
我写了一下Msgbox的内容,希望加入页面开头。表述都可以适当调整。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 03:54 (UTC)(最后编辑于2022年7月1日 (五) 11:54 (UTC))
 特殊情形:对于仅涉及单个页面的破坏行为(如导致苦力怕(消歧义)被半保护的事件),应当灵活处理。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 09:40 (UTC)
注册用户“插入具有营利性质的广告”立即无限期封禁——这样做是不是太严了?我承认,广告机器人创建账户就是为了发广告,但是有些开服玩家可能也写wiki,他们会在用户页宣传自己的具有盈利性质的服务器,而没有注意到Wiki条例。TripleCamera留言) 2022年7月1日 (五) 11:48 (UTC)
可以在讨论页申诉吧?-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 11:59 (UTC)
无限期封禁也可以通过申诉缩短封禁时长吗?无限期封禁给人一种行为非常恶劣的感觉。TripleCamera留言) 2022年7月1日 (五) 12:07 (UTC)
这是未尽事项,所以我也不清楚。-- LakeJasonFace Lakejason0) 2022年7月1日 (五) 12:08 (UTC)
需要直接永久封禁的是最恶劣的违规行为。如果是因为多次违规而导致永久封禁的,由于三番屡次劝阻无效,一般不会出现减刑情况。--Lxazl5770zh.admin) 2022年7月1日 (五) 12:45 (UTC)
这些事应该写清楚。 建议:不得因被封禁用户申诉减刑至低于适用细则最低标准。传入神经元权限|讨论|贡献|日志) 2022年7月1日 (五) 13:22 (UTC)
已经补充一条。--Lxazl5770zh.admin) 2022年7月1日 (五) 14:05 (UTC)
意思跟我的想法是反的,不过按认错态度量刑也对。传入神经元权限|讨论|贡献|日志) 2022年7月1日 (五) 16:07 (UTC)
在用户页另说,但是在主名字空间创建此类页面是绝对不能接受的,见页面“梦想世界”的日志。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 12:09 (UTC)
有道理…我在这里只讨论了一种比较特殊的情况。TripleCamera留言) 2022年7月1日 (五) 13:47 (UTC)
插入商业性质广告是Fandom使用条款中的规定的禁止行为,是极其恶劣的破坏行为,因此必须直接永久封禁而不给予申诉权。--Lxazl5770zh.admin) 2022年7月1日 (五) 12:52 (UTC)
重罚更需要保留申诉权。传入神经元权限|讨论|贡献|日志) 2022年7月1日 (五) 13:24 (UTC)
Gamepedia是建立在Fandom的基础上的,在Fandom进行活动表明用户“已完全阅读并同意Fandom使用条款”。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 13:33 (UTC)
本wiki建立于Fandom提供的wiki农场之上。任何违反Fandom使用条款的行为均属于严重违规行为,不予申诉。--Lxazl5770zh.admin) 2022年7月1日 (五) 14:06 (UTC)
这不对吧,为啥严重违规不予申诉?申诉不是认错,就是被认为严重违规的才更需要申诉权,如果严重违规不给申诉那轻微违规更不用申诉了。传入神经元权限|讨论|贡献|日志) 2022年7月1日 (五) 16:07 (UTC)
这是原则性的问题,没有退让或者妥协的可能。--ultim_0 ( USER | TALK | WORK ) 2022年7月1日 (五) 16:14 (UTC)
同上,Fandom服务条款是必须遵守的法律性文本,不是可以退让和妥协的事情。任何违反Fandom使用条款的用户属于跨越红线级别的违规行为,是极其严重和恶劣的行为,严重情况下甚至会有触犯现实法律的行为。因此不予申诉权利。--Lxazl5770zh.admin) 2022年7月1日 (五) 17:02 (UTC)
Fandom服务条款是红线,违反Fandom使用条款极其严重,这都没有争议。问题是认定严重违规需要给申诉权,这也应该是原则性的。传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 02:10 (UTC)
我看了下,目前草案上规定的立即永久封禁的行为都是违反Fandom使用条款的行为,因此不予申诉权。--Lxazl5770zh.admin) 2022年7月2日 (六) 02:15 (UTC)

┌──────────────────────────┘
怎么回到草案了?现在问题就是违反Fandom使用条款这种严重违规应该保留申诉权。传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 02:31 (UTC)

 你难道是想要给某些在用户资料页里发“新xx娱乐”的人求情吗?在Fandom发布小广告的用户,无一例外都被永久封禁了,你却还想着给这种蠹虫网开一面,这无异于割地求和。对敌人仁慈就是对自己残忍,请深思。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 03:16 (UTC) (最后编辑于2022年7月2日 (六) 03:58 (UTC))
我说了这是极其严重的行为没有争议,没人想对这种人网开一面。这和现在的话题有啥关系?传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 04:09 (UTC)

如果你的意思是禁止编辑讨论页而要求被封禁用户在专门的渠道申诉,这没问题。传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 04:13 (UTC)

违犯使用条款的行为应当前往support.fandom.com进行申诉,不在本wiki的辖域内。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 04:19 (UTC)
刚才我查阅了使用条款:“您同意不会:发布任何商业性广告或潜在性的商业信息。”此事属实。TripleCamera留言) 2022年7月1日 (五) 13:47 (UTC)
 建议:IP地址可更换性强,对其的普通或轻微违规行为单次封禁时长不应超过一周,严重或屡教不改的违规行为不应超过一个月。此外,还可以加上有关注册用户和匿名用户封禁时长具有差异的原因说明,避免被误解。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 01:14 (UTC)
针对此前几次顽固的IP封禁,我觉得一个月很快就过去了,部分IP地址解封后仍然继续作案,因此我考虑加到1年。--Lxazl5770zh.admin) 2022年7月2日 (六) 01:55 (UTC)
对于此,我 建议在匿名用户首次违规时采用我上方提出的封禁时长上限,每多违规一次就把上限上调一级。对于屡教不改的可以一次将上限上调到六个月或一年。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 04:07 (UTC)
 建议:在Wiki条例中,加入“禁止违反Fandom服务条款”的要求,列举“插入盈利性广告”等行为,并放在第一位(Minecraft条款放在第二位)。在封禁准则中,把所有“永久封禁且不予申诉”的惩罚进行醒目标记。既然惩罚非常重,那么应事先警告用户。--TripleCamera留言) 2022年7月2日 (六) 01:49 (UTC)
关于违反Fandom使用条款这一点,本Wiki以及其他托管在Fandom的子网站都必须严格遵守Fandom使用条款。wiki条例只对本wiki进行特别的条例制定,不能完全替代Fandom使用条款,因此对于Fandom使用条款不再重复叙述。特别地,“插入盈利性广告”这个情况在本wiki发生比较频繁,因此为了使得部分不自觉查阅Fandom使用条款的用户得知此事,特意写在本wiki条例里。--Lxazl5770zh.admin) 2022年7月2日 (六) 02:01 (UTC)
那么,能不能给相关条例一个着重显示呢?如果真的要永久封禁+不予申诉的话(是不是要这么做目前仍在讨论中),应该提前告诉用户这种行为是“极其严重和恶劣的”,并警告他们后果有多么严重。--TripleCamera留言) 2022年7月2日 (六) 04:05 (UTC)
我想这个已经超出了本封禁准则的范畴。另一方面,“Wiki不治眼瞎”。--Lxazl5770zh.admin) 2022年7月2日 (六) 06:47 (UTC)

本条例拟定于7月11日(一)生效。届时将正式成为条例文本并不作进一步更改。现在处于商议期,还请各位继续提议。--Lxazl5770zh.admin) 2022年7月3日 (日) 15:03 (UTC)

使用模板的大小写与缩写要求、以及部分模板及其参数的使用规范问题

我于数月前查看版本634496时,发现该编辑将{{only}}{{in}}等模板中的英文字母全部改为了小写,并将使用了{{editions}}模板参数的文字进行了缩写(如把java改为了je,bedrock改为了be)。此后,我也养成了在编辑页面时顺手对这些模板进行类似改动的习惯。不过到今天为止,我也不太清楚这么做究竟有什么意义,可能是为了统一格式。

首先,以{{in}}模板的使用为例:区分大小写,我见到过三种用法:{{in}}、{{In}}还有{{IN}},是否应该把它们全部统一为小写?例如,{{IN|BE}}统一为{{in|be}}。我的建议是将其全部统一为小写,模板中的文本不作大小写统一。

值得注意的是,在普通的页面编辑中,提供的模板自动补全功能(例如,可以在编辑页面时的编辑区内输入{{ab,等待数秒就会出现一个以该字符串为开头的模板列表(包含重定向),点击任意一个即可将其自动补全为完整的模板名称)会自动将模板的首字母大写;可视化编辑也有可能在使用模板时将模板首字母大写或全部大写。

其次,部分模板具有其缩写形式,如{{editions}}对应的{{el}}。那么,在使用模板时,应该使用其全拼写形式还是缩写形式?我的建议是全部统一为缩写,以减少编者的负担。同时也需要注意,上文提及的模板自动补全与可视化编辑都会输出完整的模板名称。

第三,上述为例的{{in}}和{{only}}模板均引用了{{editions}}参数,以这些参数中最常用的java和bedrock为例,它们对应的缩写分别为je和be。同上,在使用这些参数时,应该使用其全拼写形式还是缩写形式?我的建议也是全部统一为缩写。与此同时,可视化编辑也可能把这些参数强制转换成完整拼写,可参见版本661837对第244行文本的更改。

第四,{{only}}模板接受short参数,该参数启用时会将对应版本名称缩写,如将[仅基岩版]转换为[仅BE]。那么,此参数存在的意义是什么,应该在什么地方使用?我在这方面暂时没有什么想法,不过在en对于此模板的讨论上,有人提到这个参数(由于我个人所限,我只从里面提取到一句“把版本名称缩短是一个好主意”),其他有能力的用户可以去看看,能不能从那里得到什么有用的观点。

第五,{{Sprite}}相关模板包括{{BlockSprite}}等,其作用是在页面中添加一个特定的“精灵图”。那么,对于在这些精灵图前后的文本,是否应该以一个空格将图片和文本隔开?以{{BlockLink}}为例,使用dirt参数会输出泥土的精灵图、一个空格和泥土的链接,这就向我们展示了一般情况下,这类模板的使用需要在图片后加上一个空格与文本隔开。与之对应,图片的前面如果有文本,是否也应加上一个空格与之隔开?我的建议是,这类精灵图的前后如果有文本,就要加上一个空格与之隔开,如果其前后为标点符号则不需要。

我发起上述议题的原因,主要是看到Wiki上仍然有很多地方的模板使用情况不统一,而又不知道是否应该统一;并且有时候我也对寻找并更改页面中的大小写、缩写和{{editions}}参数感到厌烦,这些工作明明可以交给机器人来完成。但是,正如上文部分地方所提到的,官方提供的模板自动补全功能和可视化编辑的部分输出结果又与我上面所提出的部分建议矛盾,是否应该采用还有待讨论。

以上。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 09:28 (UTC)

首字母大小写个人认为没必要统一吧。不过真的要统一,还是小写好一点,毕竟这样编辑也方便。Sprite前面加个空格会美观一些,但是MCD的装备一类的sprite由于尺寸较大,甚至出现了空格过大的情况,这一点还是需要其他人考虑。至于其他问题我再考虑。—KaplanSteve  T/C 2022年7月2日 (六) 09:47 (UTC)
{{IN}}等模板有大小写的原因是英文中有大小写区分的必要,中文则没有。出于方便(搬运进来或者搬运出去)考虑,此类区分大小写的情况下,建议是“翻译成英文的时候需要大写的”大写,反之小写。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 09:48 (UTC)(最后编辑于2022年7月2日 (六) 09:51 (UTC))
那么在en那边区分这类大小写,有没有具体规则或格式指导?最好能把这些规则列入到本议案最终的解决方案中。--AblazeVase69188讨论 | 贡献 2022年7月3日 (日) 00:50 (UTC)
至于是否是要统一拼写,个人认为没必要,用得顺手就行,这不会带来太大的负担,反而是强行统一会失去模板别称的价值。至于Only模板,在Infobox里面我会觉得要缩写,还有一个用例是例如“某某某共有6[仅JE]/9[仅BE]个”,像这样的,其他地方写全也不会和英文一样长得太长,改不改都没什么必要。Sprite模板我记得本身也就不应该单独使用,我没有办法讨论这里的用例。强行前置空格会造成源代码观感差。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 09:55 (UTC)(最后编辑于2022年7月2日 (六) 10:06 (UTC))
我此处所说的“Sprite模板”是用来泛指包含BlockLink这一类模板的集合的。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 10:51 (UTC)
 留言
  1. 原则上首字母大小写以及空格与下划线的相互替换并不会影响被调用的模板、页面或者用户(例如user:ultim_0等效于User:Ultim 0),个人建议不做任何更改。
    • 而部分模板的参数同时接受大小写(甚至是混合输入),是因为这些模板在处理对应参数时使用了魔术字{{lc:}}来将输入的参数转化为全部小写(如{{lc:Be}}会显示为be),对于这些模板参数的大小写,个人建议也不做任何更改。
  2. 至于同义参数,个人建议依用户输入习惯而异,与对模板别名的态度一样,也不做任何更改。
  3. 至于{{only}}使用参数|short=的情形,个人认为应当在表格等内容拥挤的地方使用,以避免占用过多页面空间影响观感。
  4. Sprite模板相关:个人认为在文段中,应当在Sprite后以及Sprite之间添加空格,无论是否为了单纯列举Sprite。
以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月2日 (六) 09:59 (UTC) (最后编辑于2022年7月2日 (六) 10:18 (UTC))
所以目前大致的共识就是第一至四条没有采用的必要,而第五条仍需讨论。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 10:53 (UTC)
前三条没啥不良影响,没必要改。short的缩写不够标准,不如全称好理解,建议能不用就不用。Sprite的空格应该是这类模板的标志,模板外不用。传入神经元权限|讨论|贡献|日志) 2022年7月2日 (六) 12:43 (UTC)
的确部分读者可能对short参数输出的缩写不是很熟悉。不过在Minecraft Dungeons等较长的版本名称的使用上,显然MCD比Minecraft Dungeons更短,在这些情况下还是可以更多地考虑使用缩写。--AblazeVase69188讨论 | 贡献 2022年7月3日 (日) 00:50 (UTC)
 支持以上1、2、3的观点,事实上我也是这么做的。5的话我不建议加空格。--McplayerFS讨论 | 贡献) 2022年7月2日 (六) 12:53 (UTC)(最后编辑于2022年7月4日 (一) 04:27 (UTC))
请问您是否不慎在此处将“第四点”和“第五点”调换了?--AblazeVase69188讨论 | 贡献 2022年7月9日 (六) 13:56 (UTC)
目前貌似有部分编者不太理解我所说的第五点的内容,我在这里举个例子:
“村庄可以在平原生物群系生成。”与:
“村庄可以在 平原生物群系生成。”的区别。
{{BlockLink}}等模板中在精灵图和链接文本之间添加了一个空格,因此对应地,如果精灵图前面有文本,那也应该在它们之间加上一个空格。的确,{{BlockSprite}}等只包含精灵图的模板不经常使用,但在使用时仍建议遵循{{BlockLink}}等模板添加空格的做法。不过由于部分情况下精灵图前面没有文本,不需要加上空格,而添加新的参数可能会增加模板使用的复杂程度,因此目前可能只能采取有必要时在精灵图前面加一个空格以将文本与之隔开的做法。--AblazeVase69188讨论 | 贡献 2022年7月2日 (六) 15:13 (UTC)
这么做的问题仍然是源代码层面的一个不太好看(因为没有其他场合会需要一个额外的空格)。-- LakeJasonFace Lakejason0) 2022年7月2日 (六) 15:23 (UTC)
 提醒:一般来说并不建议在正文的文本段落内使用各种sprite链接模板,因为实际上观感并不会比普通文本更好。MysticNebula70 T  2022年7月2日 (六) 16:07 (UTC)
既然这样,如果格式指导里面暂未提到相关内容,那是否可以在格式指导中加上一句“不建议在正文的文本段落内使用各种sprite链接模板”,并对Wiki现存的在文本段落内使用的Sprite链接模板进行替换,这样就可以避免此处第五点所提到的情况?--AblazeVase69188讨论 | 贡献 2022年7月3日 (日) 00:50 (UTC)
 需要分情况讨论。如新手手册中有以下的叙述:

你可以获取的工具基于材料可以有不同的品质,这些工具包括,分别用于挖掘石质、木质和沙土类方块。第四类工具是,其略有不同——一般会到后面使用,作为耕种的一部分,不过锄可以用于更快地破坏轻的方块(如树叶)。类似于工具,同样可以有不同的品质,但是用于攻击动物和怪物而非破坏方块。六种品质分别是木头石头钻石下界合金,但是第一天你通常只能得到木头和石头,或许还有铁。更高品质的工具可以更快破坏方块,且耐久度更高,更高品质的剑可以造成更高的伤害。尤其对于镐,很多方块只有至少特定品质的工具才能收集,否则不会掉落任何掉落物:木镐可以收集石头煤矿石,但是铁矿石青金石矿石至少需要使用石镐,更高级的矿物(如金和钻石,第一天也不太可能遇到)至少需要铁镐才能挖掘。金是特例,尽量避免依赖于使用金质的工具、剑或者盔甲,因为金质工具的效率虽然很高,但耐久度却很低。如果你在某些结构中的箱子(如废弃传送门)里发现了金质物品,可以保存起来,以后再使用。如果刚进入游戏就发现了的金,可以仅做临时防御,有好装备(铁质及以上)了之后立刻更换。

该段落中使用了较多的sprite,因为新玩家不一定明白教程中提及的物品在游戏中的样貌,虽然可以通过点击文段中的链接进一步查看,但是较为不便,因此建议在教程页面适当保留。--ultim_0 ( USER | TALK | WORK ) 2022年7月4日 (一) 05:02 (UTC)
依上述讨论,现列出解决草案如下:
1. 第一点、第二点、第三点不采用,各编者可保留原有使用习惯,不必强制统一。
2. 第四点,对于全称过长的Minecraft Dungeons和Minecraft Dungeons Arcade,可以分别缩写为MCD和MCDA。其他的缩写尽量不使用;或只在表格等空间窄小的地方、较短的句子或词组中使用。
3. 第五点,可以在格式指导中加上一句“不建议在正文的文本段落内使用各种sprite链接模板”,以避免第五点所提到的问题出现。如果有特殊情况需要在文本段落内使用,在精灵图的前面不需要添加空格。
七日后将依新的讨论给出最终解决方案。(六日后我才能再次开始活跃。)--AblazeVase69188讨论 | 贡献 2022年7月3日 (日) 09:36 (UTC)
现根据最新讨论,给出最终解决方案如下:
1. 第一点至第四点的解决方案与草案相同,具体内容见上方。其中第四点的格式标准拟写入{{only}}模板的文档页面。
2. 第五点,在格式指导中加上一句“一般不在正文的文本段落内使用各种Sprite链接模板,教程页面除外。在Sprite的前面不需要添加空格”。
如有其他意见请在三日内提出。--AblazeVase69188讨论 | 贡献 2022年7月11日 (一) 01:51 (UTC)
 已完成添加上述说明的工作,不过我还有一个建议在此提出:
原本我是因为看到了模板中精灵图和文字中间的空格,才采用在Sprite前面添加空格的做法的。既然为了源代码层面的美观而不在Sprite的前面添加空格,那么为了统一是否应该将各种Sprite链接模板中精灵图和文字中间的空格移除?--AblazeVase69188讨论 | 贡献 2022年7月16日 (六) 01:33 (UTC)
这是模板的特性,不需要统一。传入神经元权限|讨论|贡献|日志) 2022年7月16日 (六) 07:05 (UTC)
 反对:如果去除空格会影响页面的美观性,如平原平原。--McplayerFS讨论 | 贡献) 2022年7月16日 (六) 09:08 (UTC)
 支持,后空前不空实在不太美观。如果过于紧凑也可以前后都空。--Yzy32767/ 2022年9月24日 (六) 02:16 (UTC)

对parity一词翻译为趋同这一议题的疑问

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

讨论结果为 维持当前译名


两个支持其他中立,这是不是一种共识呢?我觉得有待商榷。

自相关操作开始实施之后,我和其他的wiki用户将相关的意见发布到了各个地方(包括SPXX,这个是Mojira漏洞的一个第三方翻译服务)和MCBBS(我的世界中文论坛)的新闻群(这是会翻译到parity的地方)。

从我收集到的结果来说,没有参与过讨论的人对这一提议都表达的是不满意,不愿意服从。这对标准化是不利的,标准化的意义是在于,大家有一个共同适用的标准,而对于原版内容来说,这个共同是通过直接加入游戏来保证的,其他的科技术语会是通过各种渠道进行宣传。如果这个词语不能够达到目的,而且这个议题的结果其实远远不能称得上是一个“共识”,那么我在此提出异议,建议延缓这一议题的进行。如果这个议题的结果是无共识,请将相关词汇的情况冻结。

补充:这个话题的产生只是因为wiki目前的“准许”的得出似乎不能够代表wiki编者的意见,因此才提出的,而且提出的目的也只是希望暂缓这一操作,不是说对趋同一词的反对。有关这个词为什么要翻译成趋同,趋同的好处等等,这些请参考#请求敲定“parity”一词的标准译名为“趋同”,我不再赘述,总之理由是算充分的。

再补充:这个议题希望得到的是更为明确的同意或反对,或者是相关疑问的解决。

再再补充:本议题只是希望达成wiki编者之间的共识。其他地方不算在内。我对上述议题的疑问仅限于准许在较多中立或疑问的情况下被给出这一事实。

-- LakeJasonFace Lakejason0) 2022年7月3日 (日) 14:09 (UTC)(最后编辑于2022年7月5日 (二) 04:09 (UTC))

 中立,我反复阅读该讨论,我还是没看懂趋同的定义,是我英语不好还是因为我在台湾用语不同的关系ouo。总觉得英语搞那么模糊,我们真的需要准确翻译吗?--Impulse Command Block 乳液Louis 对话 •贡献 2022年7月4日 (一) 14:50 (UTC)
不从正确性的角度为前提讨论,自然会得出像你这样的结论。这也是MCBBS那边询问的结果。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 06:25 (UTC)
根据目前本人掌握的资料,看待这个问题的用户可以分为三个群体:基岩版开发者、Java版开发者、其他人。基岩版开发者不用多说,多数赞成使用这一翻译,但是Java版开发者不赞同,并且只是给出了“不是人话”这种无意义的理由,并且双方翻译者并不能很好地一起交流。其他人则是“好听就行”。
我不认为这个议题会得出什么共识。现在要解决的问题已经不是Parity怎么翻译的问题,而是两个版本的开发者之间的偏见存在的问题。然而这个问题不可能本wiki能够解决,偏见会一直存在。
实际上,“待同步特性”这个原本的翻译也不是通过所谓的共识决定的,这个翻译出自本人之手,只是我本人认为更老的翻译“等价议题”显得非常晦涩难懂,于是换成了相对更好的、更容易接受的。但是在Miemie发出上述敲定翻译的请求前,根本就没人去深究Parity的真正含义。--Lxazl5770zh.admin) 2022年7月4日 (一) 15:25 (UTC)
 留言:可否考虑从MCBBS等地引流,让更多的自然人参与讨论,从而达成真正的共识?--ultim_0 ( USER | TALK | WORK ) 2022年7月4日 (一) 15:35 (UTC)
意义不大,见lx的留言。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 04:01 (UTC)
换句话说,这个议题只是想要wiki编者之间真正达成共识,其他地方并不算在内。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 04:03 (UTC)
 疑问
  1. Java版编者(姑且认为等同于“Java版开发者”)反对的理由是什么?真的“只是给出了‘不是人话’这种无意义的理由”吗?(追加:是我的理解出现了问题)
  2. 为什么这次在社区专页讨论没能达成共识?是社区专页的问题还是人的问题?
  3. 这个问题已经上升到了“两个版本的开发者之间的偏见存在的问题”吗?真的无法解决吗?
--TripleCamera留言) 2022年7月5日 (二) 04:46 (UTC)(最后编辑于2022年7月5日 (二) 09:11 (UTC))
lx所说的无意义的理由主要是指MCBBS新闻版的那些人并不认同从正确性角度优先考虑译名,而是从是否顺口的角度考虑。既然讨论前提不同自然没有意义。
为什么我认为专页未能达成共识是因为除了管理员,支持人数少,中立和疑问的人数多。只要有人再来几个支持,或者行政员认为自己得出这是共识的过程没有问题,那么趋同的替换操作大可以继续进行。
不清楚,不晓得,这个议题仅限于wiki内的使用,不会也不能涉及其他地方。标准化是要让大部分人接受,但不接受也没有办法了。-- LakeJasonFace Lakejason0) 2022年7月5日 (二) 06:23 (UTC)
既然是这样,那就没有必要纠结了,毕竟texture的翻译从“材质”变成了“纹理”,快一年了不买账的玩家大有人在。--ultim_0 ( USER | TALK | WORK ) 2022年7月5日 (二) 08:30 (UTC)
听了你的分析,看来这个译名的正确性是站得住脚的。希望大家能早日达成共识。--TripleCamera留言) 2022年7月5日 (二) 09:11 (UTC)
只要译名合理,就可以推行下去。--58.248.208.154 2022年7月5日 (二) 09:03 (UTC)

本人同意趋同的翻译,确实是目前兼顾多方面较为合适的译名。社区共识方面,纹理也不出现在游戏中,wiki号召一个译名还是可以的,尽管似乎没有得到部分wiki译者的赞同。--Ff98sha留言) 2022年7月5日 (二) 11:45 (UTC)

由于目前无其他疑问和意见,目前维持现有译名。MysticNebula70 T  2022年7月9日 (六) 10:31 (UTC)

关于bilibili链接的规范

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

讨论结果为 建立相应的模板{{BilibiliVideoLink}}


如题,最近注意到Minecraft Wiki有许多地方引用了哔哩哔哩(B站)的内容(视频、专栏、动态等),但是其中一些链接存在不规范的地方:有的编者会选择直接复制粘贴哔哩哔哩手机客户端生成的短链接或者这种链接展开后的链接(从浏览器地址栏复制)。

综上所述,建议为站内的哔哩哔哩链接提供一个固定格式的模板。先前已在自己的用户页中设计了一个哔哩哔哩视频链接的模板(User:Ultim 0/Template/BV),对标{{YouTubeLink}},但是不确定其中的功能是否为此规范所需,如有需要,会根据{{YouTubeLink}}稍作修改。

以上。大家如有意见或建议,烦请提出。--ultim_0 ( USER | TALK | WORK ) 2022年7月9日 (六) 08:05 (UTC)(最后编辑于2022年7月9日 (六) 09:19 (UTC))

我认为还可以给该模板添加链接到指定的哔哩哔哩专栏和动态的功能。--AblazeVase69188讨论 | 贡献 2022年7月10日 (日) 01:52 (UTC)
专栏和动态的内容目前引用得较少,暂时不考虑添加。--ultim_0 ( USER | TALK | WORK ) 2022年7月10日 (日) 02:46 (UTC)

若无异议,则将在168小时之内择机将上述模板移动到Template:BilibiliVideoLink,并创建重定向Template:BvlTemplate:Bv。--ultim_0 ( USER | TALK | WORK ) 2022年7月11日 (一) 15:20 (UTC)

 已完成上述模板的创建,接下来将逐步替换站内原有的bilibili链接。注意到Fandom本身的搜索功能难以精确识别此类外链,建议使用中文MCW在bilibili的镜像进行辅助查询。--ultim_0 ( USER | TALK | WORK ) 2022年7月17日 (日) 15:29 (UTC)

关于“物品修饰器”内对象的遗漏

物品修饰器"set_count"函数中遗漏了"add"这一对象,是否需要补充 --Hastel04留言) 2022年7月12日 (二) 08:58 (UTC)

可以根据实际情况和en对应页面自行补充。-- Anterdc99Face Anterdc99· 2022年7月12日 (二) 09:03 (UTC)

翻译重心

我认为Wiki应该将翻译重心集中到经常会使用的节目,如新手教程,这些页面有些已经落后英文Wiki许多,且存在一些语法错误和本地化翻译的不足,这些内容又恰恰是新玩家最多看的;而最新版本介绍的翻译由于具有特殊的时效性,应先翻译重要内容,细节以后慢慢补足Leidaozan留言) 2022年7月15日 (五) 05:36 (UTC)

那就麻烦您贡献了!--Impulse Command Block 乳液Louis 对话 •贡献 2022年7月15日 (五) 06:17 (UTC)
自己动手,丰衣足食。--ChengBing留言) 2022年7月15日 (五) 06:28 (UTC)
  1. 自己动手,丰衣足食;
  2. 从往期我的了解来说,来wiki看哪怕是技术性教程的人(我还写了两篇)都很少,加之教程是本wiki的历史遗留大问题,也只有可能是有人会补充这些内容才会有这些内容的改进。
除了基岩版大版本之外,Java版的版本更新内容并没有你想的那么难翻译,说是先翻译重要内容,可是翻译完重要内容后,不重要的内容顺道早就翻译完了(尤其是先前没人翻译的漏洞,现在是有人提前抓取提前翻译好的)。作为wiki向来的薄弱处基岩版,我觉得反而才更应该受到关注吧。
此外,管理员是可以看到一些数据的。我想他们如果能够分享一些结果的话也不是不可以。在数据分析页面,可以得到以下数据:
  1. 所有页面访问次数;
  2. 被搜索关键词排行;
  3. 访客所在地;
  4. 访问最多的页面和文件;
  5. 访客使用的客户端情况(手机和桌面端比例,桌面端浏览器比例)
  6. 用户回访率;
  7. 日编辑量。
这些数据都仅限管理员使用,未得到许可所有信息不可与他人分享。我想得到许可后,分享一些数据自然可以明白哪些页面是重点。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 07:36 (UTC)
“被搜索关键词排行”和“访问最多的页面”和几年前情况大致相同,无非多了一些新内容,而这些页面的维护一向到位。顺便提一句,我在三五年前就与管理员们分享过类似数据,当时指出了一点:繁体中文的访客占到了30%以上(目前这个数字更高),因此有必要不断优化繁体访客的体验。tr模板的维护、词库更新,繁中界面管理员的招募,以及繁简转换表的沙盒,都是为此的举措。--Ff98sha留言) 2022年7月16日 (六) 02:17 (UTC)
 留言:en有许多低质量内容(比如纹理图集),建议不要贸然搬运。--ultim_0 ( USER | TALK | WORK ) 2022年7月15日 (五) 09:46 (UTC)

自定义世界生成页面内容的严重缺失,如何解决

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

讨论结果为 密度函数页面已被创建并完善


最近我正在制作一个Mod,发现自定义世界生成页面上缺失了density_function和placed_feature(均添加于Java版1.18.2-pre1)这两项重要的内容,同时对worldgen/noise(添加于21w42a)一项缺少解释。我检查了Minecraft源代码,用两天时间研究得出了这几项内容的结构,并得出了每一个参数的作用。

现在我的问题是:

  1. density_function应该放在一个独立的主页面上还是放在自定义世界生成页面上?
  2. 自定义世界生成的历史记录严重缺失,需要完全把每一个参数的加入都写进去,还是可以只写“加入了一系列参数”?(1.18的更改记录实在有点多,如果精确到每一个快照版本,添加历史将会是一个巨大的工程)
  3. 我只有1.18.2的源代码,但最新版本已经是1.19,我能否在页面上只写1.18.2的格式,然后注明“此内容仅限Java版1.18.2使用,并非最新内容”?
  4. density_function和placed_feature如何翻译?

--QWERTY-5238留言) 2022年7月15日 (五) 08:29 (UTC)

先参考en怎么做的(没做就算了)。Density function直译密度函数,我在该页面上方放置的Misode的链接已经翻译过了相关内容。Placed Feature目前我翻译为已放置的地物。奇怪的话我也没办法。补肯定都要补,因为官方有反混淆表,不可能只写1.18的内容。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 08:32 (UTC)
“已放置的地物”这名字实在有点容易误会,和configured_feature难以区分。
en在历史一节的详细程度甚至不如中文wiki,也没有density_function一节(不然我也不会去花两天时间翻源代码了)。
能否暂时只写1.18.2的内容,可以放在一个子页面里(1.19的差别有点大,我没搞清楚,写不了)?--QWERTY-5238留言) 2022年7月15日 (五) 08:39 (UTC)
要不先更上,然后needs update里面说1.19的内容少?至于难以区分这一点,原文也一样的。-- LakeJasonFace Lakejason0) 2022年7月15日 (五) 08:59 (UTC)

允许添加“架设一个Mod服务器”一栏

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

我提议允许添加“架设一个Mod服务器”一栏,理由如下

  1. 插件服务器如Spigot在中文Wiki存在,而插件对游戏的做出的改变比Mod要大,为什么架设插件服务器的教程可以存在而架设Mod服务器会因为“Mod相关游戏特性、非官方游戏版本、游戏服务器等内容由于不受Mojang官方支持,且存在信息杂乱、维护困难等问题,故在本Wiki中一律视为垃圾信息处理,因此请勿添加此类信息或为其创建页面”而受阻拦?
  2. 在插件服务器的中文Wiki的第一段有一句话“你可以尝试使用Spigot。此教程将向你展示如何轻松架设服务器并让你的朋友加入,以及服务器上使用的插件与Mods列表。”示意了插件和Mod在服务器的作用基本相同,那么为什么插件服务器的架设教程可以在中文和英文Wiki同时存在而中文Wiki不能发布mod服务器的架设教程?
  3. 在英文Wiki的Technical一栏,有一项是 Installing Forge mods,翻译过来就是“安装forge mod”,可见安装mod的教程是可以存在的,只是没有各个mod功能的详细百科而已。
  4. 在英文Wiki的Servers一栏,有一项是 Setting up a Minecraft Forge server,翻译过来就是“架设一个forge服务器”,那么请问为什么在英文Wiki存在的教程在中文Wiki就不能存在?如果是为特意为了造成差异化,那我认为中文Wiki就没啥意义了。
  5. mod服务器的架设区别于mod,架设仅仅限于架设而不会扩展到mod,所以我认为架设的教程是可以存在的。

Leidaozan留言) 2022年7月16日 (六) 08:52 (UTC)

没人说不可以,不过Mod内容(教程除外)确实在本站体系下的各个Minecraft Wiki都不怎么被允许了,因为都搬到FTB去了。不过我知悉,您的部分编辑内容似乎涉及到了一个国外知名服务器,因而被过滤器拦截。虽然我不反对写一个架设Mod服务器的教程,但内容还是要注意的。-- LakeJasonFace Lakejason0) 2022年7月16日 (六) 09:00 (UTC)
正如我在相关页面的讨论页回复的,只要内容不涉及具体的mod或其他任何的具体的东西,都可以允许存在,但如果此教程与其他教程较为相似,则有可能被删除。-- Anterdc99Face Anterdc99· 2022年7月16日 (六) 09:02 (UTC)
教程的页面建立标准相对其他主页面来说相对宽松,只要不涉及特定的Mod、插件或服务器等,就可以保留这篇教程。您在此前提出了翻译英文Wiki的教程来补充中文Wiki对应内容的建议,这没有问题,不过请注意,目前英文Wiki的内容质量正日益下滑,并在一些内容的收录与否的问题上与中文Wiki相去甚远,因此建议您先筛选或者与其他Wiki编者讨论,再搬运英文Wiki的内容。--AblazeVase69188讨论 | 贡献 2022年7月16日 (六) 10:34 (UTC)
 留言
  1. mod类内容在Minecraft Wiki受到限制是有历史原因的:早些时候Minecraft Wiki上存在一些非官方的mod,这些内容使用{{disclaimer}}标记;后来在Minecraft Wiki的自我整顿中,这些内容被删除,但一些其他语言的Minecraft Wiki(如ru)仍然允许此类内容存在。
  2. 只要不在教程中对具体的mod进行过度描述,教程是可以接受的。
以上。--ultim_0 ( USER | TALK | WORK ) 2022年7月16日 (六) 10:55 (UTC)

无意义话题的范围拓展

最近,用户雨后的晴天MCW:免责声明等3个页面的讨论页提出了不适宜的话题,其中两个讨论页已删除,剩下的一个讨论串被存档到无意义话题。但是注意到无意义话题页面开头有说明“这个页面的子页面用于存档社区专页管理员告示板上的各类无意义话题”,而目前无意义话题的出现范围似乎有扩大的趋势,已不限于前述页面,是否需要修改对应描述以及相关模板?--ultim_0 ( USER | TALK | WORK ) 2022年7月17日 (日) 16:05 (UTC)

 已修正MysticNebula70 T  2022年7月28日 (四) 13:08 (UTC)

给Minecraft wiki出百科全书

根据wiki上某成员的建议,我决定在社区专页讨论页上说这个请求: 首先,盈利方面我不盈利,而且,如果先抛开盈利问题的话可不可以?雨后的晴天留言) 2022年7月18日 (一) 00:26 (UTC)

首先,建议先好好了解一下什么是CC BY-NC-SA 3.0。版权方面的问题我不太懂,但是如果要让内容更换授权协议发布,那么得联系所有的贡献者,这是不可能的。这也就是为什么大家一开始看到就会思考盈利问题,因为要盈利就要更改内容的授权协议,这是不可能的。
其次,作为一个网站,他的内容是不断变化的,而且没有人能够保证内容的准确性(虽然有人巡查)。因此,即使你立即下载一份全站快照出版,也很有可能立即过期。参考官方在国内出版的一些书籍,由于译名标准化的更改已经变成了“不符合标准”的书籍了。这样一个离线版Minecraft Wiki的书籍存在本身意义不大。
最后,如果你执意要遵守当前协议,请仔细思考如何做到正确的“署名”(BY),“非商业性使用”(NC),“相同方式分享”(SA)。在美国确实有书籍以该协议发布,但不清楚其如何做到协议的兼容。-- LakeJasonFace Lakejason0) 2022年7月18日 (一) 03:10 (UTC)(最后编辑于2022年7月18日 (一) 03:11 (UTC))
 留言:维基百科有出过纸质书籍,但是效果不佳,所以 不看好将Minecraft Wiki导出为纸质书籍的行为。--ultim_0 ( USER | TALK | WORK ) 2022年7月18日 (一) 03:27 (UTC) (最后编辑于2022年7月18日 (一) 03:40 (UTC))

user warning模板拆分事宜

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

讨论结果为 已完成拆分


目前的user warning模板是整合了数个警告类模板而成的一个大模板。如此编辑模板并不利于后期维护,也使得单个模板的长度过长。因此在此考虑拆分模板,仿照中文维基百科的做法,按严重等级和具体警告事宜制作一系列模板。目前需要考虑的问题有:

  1. 是否照搬中文维基百科的5个严重等级;
  2. 讨论适合本wiki的具体警告事宜。

欢迎各位提出意见和建议。MysticNebula70 T  2022年7月18日 (一) 14:06 (UTC)

 支持将uw下的警告信息拆分成多个模板。关于严重等级,我认为过于细分的等级在本wiki上并不实用,建议分成轻微情节警告和严重情节警告两级即可。关于具体警告内容,我认为实用性较大的有破坏、可视化编辑、机器翻译、页面格式、上传文件、乱改乱用译名。--葉月 § 2022年7月20日 (三) 20:13 (UTC)
议题没人回复,主要是没法下手。等级的话不清楚该怎么办,也许可以分个三级(提醒、轻微警告、严重警告?)。至于具体的内容,现有都拆开似乎也没问题,毕竟这些内容的添加是因为wiki史上存在过对应的案例。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:55 (UTC)
命名的话,继承EN应该没问题。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:56 (UTC)
考虑了一下,本wiki分成三档等级(提醒、警告、严重警告)应该足够使用了。关于警告事宜,参照Hatsuki kiri和现有的也暂时够用了。MysticNebula70 T  2022年7月29日 (五) 05:21 (UTC)
目前的拆分工作暂时完成,如有后续需求将会相应添加新模板。MysticNebula70 T  2022年8月26日 (五) 14:36 (UTC)

关于将本wiki迁移至灰机wiki的建议

由于Fandom不是国内创办的wiki农场,故其时常被墙(即使没被墙时也非常卡,如本人从2015年起开始尝试注册Fandom账号,最近才勉强成功),鉴于近年微软与本站合作到期,故提出上述建议。114.103.49.42 2022年7月21日 (四) 10:22 (UTC)

历史上灰机站长与本站的部分人员产生过矛盾,个人认为这是不可能发生的。
原因主要是BWIKI[原文如此]的镜像。灰机方面认为BWIKI对本站的镜像行为非法,态度为“深恶痛绝”。但自相关疑问产生后,BWIKI方面去除了顶栏的商业要素(NC),将历史按钮全部导向本站点(BY),注明了协议(SA),是符合CC BY-NC-SA 3.0的合法搬运。因此这边建议,如果产生网络问题,去BWIKI那边的镜像查看相关内容。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:31 (UTC)(最后编辑于2022年7月21日 (四) 10:37 (UTC))
我不仅是想要查阅本wiki的内容,而且还想要作出编辑贡献,使用BWIKI显然不大现实。114.103.49.42 2022年7月21日 (四) 11:21 (UTC)
很遗憾,出于上述和下述各种各样的理由,我们不可能为了某一个人而把整个站点迁走。也许你会说这样会妨碍更多的贡献者,但很遗憾这里并不是只有中国大陆用户,既然繁体访客的比例更高,我觉得还是不迁移带来的好处更多。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 05:35 (UTC)
网站迁移本身也是个问题。参考灰机的案例来说,当年从Fandom迁到灰机的站点,很多是Fandom也死了,灰机的也死了。究其本质是,流量本身迁移不走。Fandom也特别注重SEO优化,由于各种规定的限制,不太好做站点搬迁导向,因此贸然搬迁只会导致更多问题。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 10:42 (UTC)
您应该还需要知道一点,就是本站的繁体访客数量比例是不断增加的。出于这样的原因,继续改进繁简字词自动转换应该比搬迁站点要更加对用户友好。-- LakeJasonFace Lakejason0) 2022年7月21日 (四) 11:02 (UTC)
不建议这么做,理由同上。当时灰机站长对中文MCW在BWIKI建立镜像站的行为进行了猛烈抨击,现在想要迁移过去恐怕也不是那么好说的。据我所知,Fandom下的网站都没有被墙过,有时候访问速度缓慢、图片无法加载都属于正常现象(有其他Wiki用户认为这纯粹是自己的网络问题)。所以,如果要做出贡献的话,您可以通过改善自己的网络环境来提高网站的访问速度。--AblazeVase69188讨论 | 贡献 2022年7月21日 (四) 11:36 (UTC)
你的建议很好,但是我 拒绝,因为这里是中文Minecraft Wiki,不是中国大陆Minecraft Wiki,非常抱歉。--Lxazl5770zh.admin) 2022年7月22日 (五) 05:34 (UTC)
 疑问您指的是港澳台地区的用户访问本站更方便吗?还是迁移之后没有繁简转换?Watermelontail留言) 2022年7月22日 (五) 07:05 (UTC)
虽然话题已经结束了,但是我稍作解释:我们的访客中,繁体用户占了不少于40%的比例,如果因为“国内访问速度不好”而迁移至国内农场,这对繁体用户而言非常不公平。何况迁移之后繁简转换系统如果出现问题,我们wiki的声誉将会大打折扣。--Lxazl5770zh.admin) 2022年7月25日 (一) 08:15 (UTC)
这些不是重点,至少从上方来说,迁移了的好处比不迁移的好处少。如果从迁移的原因上来说也不合适(也就是并不是本站的大多数用户都在遇到网络问题)的话,行政员自然从原因上反驳,以此作结,其他原因肯定也不考虑。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 07:23 (UTC)
我个人不是没想过和灰机wiki合作,只是还没开口就被对面喷死了。--Ff98sha留言) 2022年7月22日 (五) 07:46 (UTC)
具体情况是怎样的?Watermelontail留言) 2022年7月22日 (五) 07:55 (UTC)
你可以搜一搜知乎。不过问题中很多回答有过期,包括所谓职员的回复这里实际上也是有双方误解的成分在里面。如果有需求的话我可以联系Fandom联络人,兴许可以让他们查查看是个什么情况。从我还记得的结果来说,其实Fandom或者先前的Gamepedia肯定没有权利阻止其他人复制站点内容,只要遵守协议要求(我在上方说了争议开始后镜像方做了调整以符合协议),镜像行为是没问题的。退一步,从当时疑似侵权的角度来说,灰机站长认为这个镜像行为是有人恰烂钱,从中攫取了利益,因此开始破口大骂,然后深恶痛绝,但事实是并没有人拿到任何物质利益。总之争议行为本身应该算是消失了,但是就风评和敌对态度来说,我觉得灰机方面肯定不会再考虑让本站再搬到他们那边去。-- LakeJasonFace Lakejason0) 2022年7月22日 (五) 08:51 (UTC)(最后编辑于2022年7月22日 (五) 09:06 (UTC))
已阅,了解本站与灰机wiki之间的矛盾。但既然矛盾已几乎消除,再与其处于敌对状态是不利于发展的,也没必要再记仇什么的了(插一嘴,网易的广告是真多)Watermelontail留言) 2022年7月22日 (五) 09:27 (UTC)
同样的,mcwzh方面也肯定不会再考虑让本站再搬到灰机那边去。--Ff98sha留言) 2022年7月25日 (一) 10:55 (UTC)

音乐

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

讨论结果为 已完成


现在,音乐的分类上很有问题,我根据游戏内建重新分类了所有音乐,如此:Special:Diff/672700。希望各位参与讨论,谢谢。Choi Chin Long 2022年8月1日 (一) 08:28 (UTC)

感觉部分分类过于分散,例如“绯红森林音乐”“下界荒地音乐”等应该归于“下界音乐”。我 建议将“创造模式音乐”和“菜单屏幕音乐”分类出来,新分类包括“主世界音乐”“下界音乐”“末地音乐”“水下音乐”“创造模式音乐”和“菜单屏幕音乐”。将水下音乐和创造模式音乐分类出来的原因是若条件满足,这些音乐在多个维度中都能播放。--AblazeVase69188讨论 | 贡献 2022年8月1日 (一) 09:32 (UTC)
资源包上的音乐资料夹是这样的:[1] Choi Chin Long 2022年8月1日 (一) 10:30 (UTC)
C:\Program Files\WindowsApps\Microsoft.MinecraftUWP_1.19.1101.0_x64__8wekyb3d8bbwe\data\resource_packs\vanilla_music\sounds\music目录下找到的基岩版1.19.11的音乐文件目录如下:
--AblazeVase69188讨论 | 贡献 2022年8月1日 (一) 11:31 (UTC)
基于Java版1.19.1,我制作了一份详细的音乐列表,由于内容过长不便在此展示,可前往User:Anterdc99/Archives/Java版1.19.1音乐树查看。
根据上面AblazeVase69188的说法,并根据实际情况,可得出Special:Diff/672700中的分类法有以下问题:
  • 机械地以目录为分类依据,不考虑各音乐间的关系。
  • 部分分类内容过少,更适合将其按一定规则与其他内容合并。
实际来说,就是“沼泽音乐”以及仅播放于下界特定生物群系的音乐是否有必要拆分的问题。
  1. 对于“沼泽音乐”,其并不需要单独列出。根据其对应的声音事件ID,除了包含music.menu(播放于菜单屏幕)外,其余ID与其他主世界音乐对应的ID并无用法上的区别。即便是music.menu,根据前例(参见22w16a之更改),在1.20开发过程中也有可能移除。沼泽音乐之所以在目录中单独列出,可能即是根据此(在菜单屏幕外仅在沼泽播放的音乐)而作。因此,这几个音乐只需在第二栏标注播放位置即可,不需要单独列出。
  2. 对于下界各音乐,其也不需要单独列出。一般的下界音乐nether1.ogg、​nether2.ogg、​nether3.oggnether4.ogg也可以在绯红森林、下界荒地和灵魂沙峡谷中播放,因此也可以仅在第二栏标注播放位置以示区分,不需要单独列出。
基于以上论断,故 支持AblazeVase69188所提出的分类法。
当然,如果要将credits.ogg也列入末地音乐中,则对应段落中的描述需要做相应修改,否则会与实际不符。-- Anterdc99Face Anterdc99· 2022年8月3日 (三) 05:09 (UTC)
 留言
  1. 不宜按照生物群系细分,会产生许多包含较少内容以及内容产生交叉的分组。
    • 以“沼泽音乐”概括“只会在森林、丛林、繁茂洞穴、沼泽播放的音乐”欠妥当,因为这些生物群系的共性是“繁茂”而非“沼泽”。
    • 按照不同维度、游戏模式和菜单中的不同位置划分就已经很合适了。
  2. “水下音乐”一般情况只会在主世界中的特定生物群系且头部处于水中时播放,可以考虑作为“主世界音乐”的子类。
以上。--182.90.218.225 2022年8月8日 (一) 14:57 (UTC)(ultim_0)
所以页面可以改动了吗?这个议题已经放在这里一个月了。--AblazeVase69188讨论 | 贡献 2022年9月3日 (六) 09:45 (UTC)
已于版本682922中重新分类音乐,分类后有“主世界音乐”“下界音乐”“末地音乐”“创造模式音乐”和“菜单屏幕音乐”五个分类,其中“水下音乐”已归为“主世界音乐”的子类。--AblazeVase69188讨论 | 贡献 2022年9月3日 (六) 14:05 (UTC)

新手手册编写问题

新手手册内的内容有些都是重复的,但有些写的详细,有些写的不精确,一眼就能看出是多个人写的,极不统一。新手手册是最重要的页面,就打算这样编写?–该未签名留言由20.239.51.29讨论)在2022年8月5日 (五) 07:37 (UTC) 添加。请在您的回复后面加上 ~~~~

 留言:Minecraft Wiki是由诸多像您这样的用户构建的,如果您觉得某些页面存在质量较低的问题,可以自行补正。--182.90.218.225 2022年8月8日 (一) 14:57 (UTC)(ultim_0)

自定义世界生成页面的严重问题

Minecraft Wiki的自定义世界生成页面的“历史”一节非常不完整,甚至有“为结构噪声设置添加标签字段。”这种相当于没说的话,1.18和1.19的更新内容几乎没有。

但是,1.18和1.19的更改实在太多(Misode整理的就有上百条),Minecraft Wiki短时间内很难(甚至几乎不可能)把所有的更改都写出来,并跟上一周一次的快照更新速度。

为了能更好地为数据包作者提供参考,我在此提出建议:

  1. 删除噪声设置的“默认设置”一节,其本身版本未知,落后许多个版本,容易误导读者。
  2. 重新编写/开始编写每一节默认设置(可参考slicedlime的原版地生数据包),取消表格(表格难以描述复杂的密度函数了),改为列出JSON内容,并标注最后版本
  3. 在每个JSON格式前写上最后更新版本。
  4. 旧版本内容不要删除,而是保留每一个大版本的内容(1.16.5,1.17.1,1.18.2)移动到子页面,在每一节的最前方添加旧版本链接。
    1. 这是因为历史章节内容必将十分冗长,如果只保留最新版本内容,就会让旧版的数据包作者只能对比每一条历史更改来确定自己版本的格式,花费不必要的时间。
  5. 参考Misode,完善历史章节。

--QWERTY-5238留言) 2022年8月10日 (三) 03:23 (UTC)

补充:写个世界生成示例,避免过于抽象。--QWERTY-5238留言) 2022年8月10日 (三) 04:09 (UTC)
 支持,不过还是要尽量保留信息的,默认的具体设置可以不写,但是相关参数的实际意义还是要说明清楚。-- LakeJasonFace Lakejason0) 2022年8月10日 (三) 14:55 (UTC)
每一节加上还是太多了,整个页面本身份版本,在开头写旧版本链接比较好。-- LakeJasonFace Lakejason0) 2022年8月10日 (三) 14:58 (UTC)

关于pvp相关部分的大幅动

当前pvp页面之中,存在大量因为版本更替出现的过时内容,导致格式以及内容冗杂而难以保证简洁。个人建议新设一个“pvp/java1.9之前”的条目,并将原条目中的过时内容予以删除。竹琴之留言) 2022年8月10日 (三) 04:36 (UTC)

 支持,这个页面太长导致难以维护。--McplayerFS讨论 | 贡献) 2022年8月10日 (三) 06:58 (UTC)
 支持,pvp页面的确存在您说的内容,分开管理比较好。Zhangzixuan2010留言) 2022年8月10日 (三) 07:58 (UTC)

关于世界界限与世界边界两个页面的过时现象

在世界界限与世界边界两个页面中存在严重过时与不符合游戏的现象,关于这些现象的具体表述请见 世界界限 的讨论页--Wodemc留言) 2022年8月25日 (四) 11:31 (UTC)

申请中文玩家社区添加新链接

本主题或以下段落文字移动自Talk:Minecraft Wiki

申请添加苦力怕论坛 目前苦力怕论坛已成为国内基岩版论坛中下游,并在先前转型为基岩版社区,并未直接与mcbbs为同类论坛 谢谢

172.105.234.90 2022年9月9日 (五) 12:21 (UTC)苦力怕纸

苦力怕论坛提供了安卓平台的盗版游戏安装包,因此我猜测此请求会被拒绝。(我不是管理层人员,无权处理此类请求)--AblazeVase69188讨论 | 贡献 2022年9月9日 (五) 12:47 (UTC)(最后编辑于2022年9月9日 (五) 13:35 (UTC))
先前申请在本站添加友链的Minebbs论坛也提供了安卓平台的盗版游戏安装包,所以这不是一个很好的拒绝理由。请无视我先前的发言。--AblazeVase69188讨论 | 贡献 2022年9月9日 (五) 13:35 (UTC)
提交友链申请请勿以匿名用户身份。建议由苦力怕论坛的管理人员来申请。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 12:58 (UTC)
不好意思,我们不接受来自匿名用户的外交请求。如果你是苦力怕论坛的管理员,请创建账户并提供相应的证据来表明你的身份。--Lxazl5770zh.admin) 2022年9月9日 (五) 13:00 (UTC)

申请中文玩家社区添加新链接(2)

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

讨论结果为 准许


我是苦力怕论坛管理员苦力怕纸,邮箱klpbbs@qq.com或admin@klpbbs.com,再次申请添加苦力怕论坛,链接:https://klpbbs.com 辛苦了,谢谢 回复一下前面那个回复,现在站内已将mc破解版分离,转为了其他网站,并且我们也在积极引导玩家入正。图片链接 McKlpbbs留言) 2022年9月9日 (五) 13:54 (UTC)苦力怕纸(最后编辑于2022年9月9日 (五) 13:57 (UTC))

回复前面留言的时候,您无需新开一个另外的话题,直接在原话题下留言即可。此外,在添加~~~~的字符串之后,保存编辑时系统会自动输入您的签名,您无需在其后再重复一次您的签名。--AblazeVase69188讨论 | 贡献 2022年9月9日 (五) 13:56 (UTC)
好的,感谢提醒McKlpbbs留言) 2022年9月9日 (五) 14:22 (UTC)苦力怕纸
上传文件请通过Special:上传文件,请勿使用编辑器内提供的上传文件。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 13:59 (UTC)
其次,这样的截图无法作为证明。由于所提供的论坛,其QQ群无法访问,其提供的管理员QQ无人回信,因此这边不好验证。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 14:01 (UTC)
(给站内没有入QQ群的人的告知)申请友联的相关人员已进入QQ群说明情况。-- LakeJasonFace Lakejason0) 2022年9月9日 (五) 14:12 (UTC)
 同意请求。--Lxazl5770zh.admin) 2022年9月10日 (六) 08:54 (UTC)

Breaking row模板颜色含义问题

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

讨论结果为 已修改


{{breaking row}}颜色表示的含义目前存在一些模糊之处,例如只有使用精准采集才掉落物品,在目前没有统一的表示颜色。是否应当为这种情况设立专门的颜色?MysticNebula70 T  2022年9月11日 (日) 11:08 (UTC)

Snow dash关心的问题还是被提出来了啊……我简单地提议一下(前提都是使用了正确的工具):
颜色 含义
绿色 挖掘后,无论如何都会掉落自身
黄色 只有使用精准采集才会掉落自身,否则不会掉落或掉落其他东西
红色 挖掘后总是不会掉落自身,而是有可能不会掉落或掉落其他东西
鉴于精准采集的常用性,我认为我的提议算是比较清晰的。例如刷怪笼蛋糕归类为红色,冰和草方块归类为黄色,其他不一一列举。--Lxazl5770zh.admin) 2022年9月11日 (日) 11:22 (UTC)
二编:如果单纯使用三种颜色来表达目前所有方块的可获取性是完全不够用的,需要用注释来加以辅助。而且,如果使用红黄绿三种颜色以外的颜色,普通读者很难理解其中的意思。因此,在表格下插入注释文本是非常有必要的。--Lxazl5770zh.admin) 2022年9月18日 (日) 08:50 (UTC)
思考了一段时间,确实主要内容需要靠文本说明,颜色过多并不利于理解。MysticNebula70 T  2022年9月19日 (一) 14:14 (UTC)
已按照Lxazl5770的提议修改。MysticNebula70 T  2022年9月20日 (二) 13:49 (UTC)

关于拆分和优化Java版已移除特性

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

讨论结果为 已完成拆分


那个板块也过于长了吧,为什么到现在还没拆分--栗色粗布留言) 2022年9月12日 (一) 05:32 (UTC)

很简单——没有人讨论这个话题。且慢,等我把那个页面的用词全部改通顺再拆。--AblazeVase69188讨论 | 贡献 2022年9月12日 (一) 05:38 (UTC)
自己动手,丰衣足食。--Lxazl5770zh.admin) 2022年9月12日 (一) 06:40 (UTC)
这不是自己不敢拆吗--栗色粗布留言) 2022年9月12日 (一) 06:50 (UTC)
您可以先提出具体的方案并征求社区的意见。或者您可以准备采用en的拆分方式,让社区讨论。--AblazeVase69188讨论 | 贡献 2022年9月12日 (一) 06:57 (UTC)
如果需要更加及时的讨论方式,见您的讨论页。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 07:27 (UTC)
我已经对页面用词不通顺的地方完成修改,初步认为需要先将方块分离到子页面,它实在是太长了。--AblazeVase69188讨论 | 贡献 2022年9月12日 (一) 07:35 (UTC)
请注意,拆分后的页面也需要好好写导言(也就是首段)和跨wiki链接。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 08:13 (UTC)
很抱歉,我仅是将源代码复制过去了,这几个页面确实需要完善,不过我今天先暂时编到这里,下次有空再来或是等别人来优化吧。--栗色粗布留言) 2022年9月12日 (一) 08:18 (UTC)
未完成页面已被移动到沙盒。另外,强烈建议您加入QQ群以便沟通。-- LakeJasonFace Lakejason0) 2022年9月12日 (一) 08:20 (UTC)
建议拆分到Java版已移除特性/方块等子页面,方便查找与维护。--AblazeVase69188讨论 | 贡献 2022年9月12日 (一) 08:32 (UTC)
这样的话,我建议一并拆分基岩版已移除特性。--Yzy32767/ 2022年9月12日 (一) 09:54 (UTC)
好主意--栗色粗布留言) 2022年9月12日 (一) 09:57 (UTC)
Java版已移除特性已拆分并优化完成,能不能从沙盒中移出来。(之前此消息错发到管理员告示板中了,深感抱歉)--栗色粗布留言) 2022年9月12日 (一) 10:43 (UTC)

Minecraft Dungeons生物类型描述问题

目前地下城生物页面使用了类似“被动型”、“中立型”等名词描述生物种类,原版生物似乎已不再使用此类描述,主要区分友好生物、敌对生物,并在友好生物下分出无攻击能力、条件敌对等子类。

是否应统一Minecraft Dungeons与原版的相关术语?Minecraforever留言) 2022年9月12日 (一) 15:23 (UTC)

原版修改的原因是原本的分类系统理论上需要把大量生物都归入中立,且此分类系统与游戏机制无关。Minecraft Dungeons中如果本身有游戏机制可以区分的话则可以按此提案。如果没有遇到相关问题则不必。-- LakeJasonFace Lakejason0) 2022年9月13日 (二) 04:02 (UTC)
地下城游戏关卡中出现的动物生物几乎不具有主动攻击玩家的能力,中立及被动两种表述界限不是很清晰,个人认为统一为友好生物之后与敌对生物区分更明确,也更能体现动物大类之间的共性。Minecraforever留言) 2022年9月13日 (二) 14:46 (UTC)
看了一下,可以改。-- LakeJasonFace Lakejason0) 2022年9月13日 (二) 15:05 (UTC)
好的,随后会进行更改。Minecraforever留言) 2022年9月13日 (二) 15:50 (UTC)

关于译名标准化的子页面格式不统一的问题与提议

下列有关译名标准化子页面格式的讨论已经结束,请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已应用提案2


MCW:译名标准化/translation页面的括号有过多的意思——可能是替代翻译,可能是语境,可能是可省略不译出,可能是取代某一个字。

我个人提议是再加一列备注表示语境,用<br>分割多个翻译,用括号表示省略。若有多个翻译,且存在首选的翻译,使用粗体表示首选翻译。不翻译的,译名打横杠,注释内标明不翻译。

更新:参见提案2提案1

有更多意见在下方讨论。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 07:24 (UTC)(最后编辑于2022年9月17日 (六) 08:39 (UTC))

我认为用半角中括号[]来表示省略会更紧凑,易于理解,用括号()来表示意思相同或相近的译名,用换行来表示不同义项,加一列或用注释来表示语境--栗色粗布留言) 2022年9月17日 (六) 07:28 (UTC)
紧凑并不表示美观,且一般而言方括号也不表示省略。注释如果用ref标签,那么最终是堆在一起,其实也不便于查阅。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 07:30 (UTC)
术语在线里就是用[]来表省略,我认为效果很好,第一眼就能知道这方括号是什么意思,而括号(尤其是全角)并不能做到相同效果,有较大歧义--栗色粗布留言) 2022年9月17日 (六) 07:33 (UTC)
我查阅了《GB/T 15834-2011 标点符号用法》,意见是用[]来表示省略,用()来标示注释内容、补充说明(即语境),用分号;来表示分项列举的并列词语(即意思相同或相近的译名),用换行br来表示意思不同的义项。示例:sprite 拼合图;精灵图(通常不翻译) argument [实际]参数 Parity 趋同(用于Vanilla Parity等)br 奇偶[性](用于...)--栗色粗布留言) 2022年9月17日 (六) 07:52 (UTC)
美观性请参考沙盒中译标提案1和译标提案2界面自行评判–该未签名留言由栗色粗布讨论贡献)在2022年9月17日 (六) 08:26 (UTC) 添加。请在您的回复后面加上 ~~~~

意见

这里是给提案们的意见。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 09:20 (UTC)

投票

在下方投票。对某个提案的意见请在这个子标题上方加子标题。请只选择一个。有新提案时,原本选择旧提案的但要选择新提案的及时划票。-- LakeJasonFace Lakejason0) 2022年9月17日 (六) 08:50 (UTC)(最后编辑于2022年9月17日 (六) 09:20 (UTC))

 支持提案2。我个人认为如果用中括号括起来的话,难以理解为省略的意思。--AblazeVase69188讨论 | 贡献 2022年9月17日 (六) 12:25 (UTC)
 支持提案2,但是有一点,如果用全角括号的话,个人感觉有点丑。但这样最直观。--KaplanSteve  T/C 2022年9月23日 (五) 09:19 (UTC)
 支持提案2 --Lxazl5770zh.admin) 2022年10月28日 (五) 13:05 (UTC)
 已应用提案2。-- LakeJasonFace Lakejason0) 2022年10月28日 (五) 13:37 (UTC)

关于地物和结构模板使用的问题

下列有关地物和结构模板使用的问题的讨论已经结束,请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已完成重新分类并删除{{Generated structures}}模板


目前,{{Generated structures}}{{Environment}}{{Structures}}三个模板内容存在较大重复,意思混乱,内容杂糅。

因此,个人认为应将三个模板进行拆分,分为“地形特征”、“结构”两个模板,完成后将{{Environment}}模板进行精简(主要是考虑到某些内容不会包括在前两个模板里)。包括生成结构页面也可以移动至“结构”。

我的提议可能有点简单,不过我大概提出了一个思路。以上。--KaplanSteve  T/C 2022年9月17日 (六) 08:17 (UTC)

建议先考虑同步en的en:Template:Generated structuresen:Template:Environment再考虑是否进行拆分。以及意思混乱、内容杂糅的其实不只是模板,模板里的页面的内容和分类也都存在混乱的问题。--Chixvv留言) 2022年9月17日 (六) 08:39 (UTC)
{{Generated structures}}之前已经同步过一次。另外此模板一直处于未使用状态,所以如果问题较大的话,可以考虑删除(主要是en有一些zh没有的内容)。-- Anterdc99Face Anterdc99· 2022年9月17日 (六) 09:42 (UTC)
我认为可以将Generated structures合并至Structures,并将Environment中结构页面的链接(如独石柱、下界反应器)移动至Structures中。--AblazeVase69188讨论 | 贡献 2022年9月17日 (六) 12:10 (UTC)
我已在个人沙盒中将Environment中结构页面的链接(如独石柱、下界反应器)移动至Structures(已同步至模板页面),并移除了Generated structures中不存在的页面链接。其中Generated structures以生成器种类为分类方式,Structures以生成结构和地形特征为分类方式,二者内容几乎完全一样,我认为前者的分类方式更好,故计划将Structures合并至Generated structures。不过这样貌似不如将这两个模板分为“地形特征”、“结构”两个模板的做法好,如果要采取这种做法,则需要将“结构生成”和“装饰器生成”的部分内容放入“结构”,其他的放入“地形特征”。具体怎么做还有待各位讨论。顺带一提,en似乎对Generated structures的分类做了调整,个人沙盒中的模板暂时不打算进行同步。--AblazeVase69188讨论 | 贡献 2022年12月6日 (二) 14:20 (UTC)
2023年1月20日,结构页面被拆分为生成结构地物两个页面,并补充了大量内容,随后由Nickid2018整理了{{Structures}}模板。我认为目前这个模板已经能够代替{{Generated Structures}},可以直接删除后者;{{Environment}}模板保留现状即可。--AblazeVase69188讨论 | 贡献 2023年2月10日 (五) 12:38 (UTC)
鉴于结构和地物相关内容已完成补充和整理,{{Environment}}{{Structures}}模板内容页已区分开来,{{Generated structures}}模板内容已被{{Structures}}收录。因此{{Generated structures}}模板可被删除,此话题将被关闭。如有关于地物和结构模板以及各页面的内容分类问题,可另外讨论。-- Anterdc99Face Anterdc99· 2023年2月11日 (六) 08:05 (UTC)

搜索栏中翻译不正当

搜索栏中热度榜中显示“指令”而非“命令”,望修改。Emplovety留言) 2022年9月17日 (六) 09:55 (UTC)

那里显示的是用户搜索量最高的前几个词,不是可以更改的东西。--Lxazl5770zh.admin) 2022年9月17日 (六) 11:44 (UTC)
那东西真是用户搜索的?怪不得源码找不着这些字 Emplovety留言) 2022年9月18日 (日) 07:23 (UTC)
我们的热搜榜是客观公正的,哪像某些三流网站就是喜欢篡改热搜数据呢~ --Lxazl5770zh.admin) 2022年9月18日 (日) 08:45 (UTC)
但是怎么提取关键字的呢,既然提取了关键字何不将指令提取为命令,虽然涉及这个方面应该很难改动。Emplovety留言) 2022年9月23日 (五) 13:40 (UTC)
具体问题请恰fandom。-- Anterdc99Face Anterdc99· 2022年9月23日 (五) 13:42 (UTC)
“洽”,不是“恰”。-- LakeJasonFace Lakejason0) 2022年9月24日 (六) 05:02 (UTC)(最后编辑于2022年9月24日 (六) 05:03 (UTC))

关于消歧义页面的标点使用问题

下列有关消歧义页面的标点使用问题的讨论已经结束,请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 已完成更改。


今天在整理并扩充消歧义页面时,发现条目标题与后面的解释内容中间的标点符号使用不统一,有短划线、破折号、逗号等,并且解释内容后面有的有句号,有的没句号。

希望有人给个提案,如果可以的话建议开机器人进行更换。--KaplanSteve  T/C 2022年9月18日 (日) 02:33 (UTC)

 建议:条目标题与后面的解释内容中间使用空格+短划线+空格隔开(例如:钻石 − 一种……)。如果有解释内容,解释的后面全部加上句号;如果没有解释内容就不加句号。此提案引入自钻石(消歧义)页面。--AblazeVase69188讨论 | 贡献 2022年9月18日 (日) 02:59 (UTC)
我也是这么写的,感觉这种的美观性最强。--KaplanSteve  T/C 2022年9月19日 (一) 02:59 (UTC)
请将本话题转移至机器人请求页。--Lxazl5770zh.admin) 2022年9月18日 (日) 08:48 (UTC)
似乎还没有一个共识结果,先讨论一下。--KaplanSteve  T/C 2022年9月19日 (一) 02:59 (UTC)

教程译名更改意见

下列有关教程译名的讨论已经结束,请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 拒绝更改


wiki中的一个教程翻译有误(教程/机械)(当然也包括其他红石教程中相同用词),机械(machinery)是机器(machine)和机构(mechanism)的总称,而原文是mechanism,因此我认为改为机构会更好。大家可以在下方踊跃讨论。--栗色粗布留言) 2022年9月23日 (五) 12:28 (UTC)

这个教程的内容更像机器,不如改成机器。传入神经元权限|讨论|贡献|日志) 2022年9月23日 (五) 12:53 (UTC)
还是遵从原文比较恰当吧--栗色粗布留言) 2022年9月23日 (五) 12:56 (UTC)
中文Wiki的页面内容没有必要按照英文Wiki的内容生搬硬套,可以作适当的修改。--AblazeVase69188讨论 | 贡献 2022年9月23日 (五) 13:14 (UTC)
根据术语在线,机构表示“由两个或两个以上构件通过活动联接形成的构件系统”,机器表示“由零件组成的执行机械运动的装置”,机械则是机构和机器的总称。我认为它们之间的区分较为模糊,直接使用“机械”一词即可。正如上面所说的,没有必要拘泥于英文Wiki的原文。--AblazeVase69188讨论 | 贡献 2022年9月23日 (五) 13:21 (UTC)
“机构”单独作为页面标题时,由于缺乏上下文或修饰文字且其自身具有多重含义,故极不适合作为单独的页面标题,且现有标题并不影响表意,故 反对改动。-- Anterdc99Face Anterdc99· 2022年9月23日 (五) 13:28 (UTC)
应从页面内容上命名,而没必要考虑英语原文。
既然机械是统称,那么不管页面里的内容更像机构还是更像机器,以“机械”为标题总没有太大问题。
机构在机械领域是专业术语,但日常中文里机构一般指工作单位,而非机械构件。
题外话,虽然在中文机械专业领域机械确实是机器和机构的总称,但英文“machinery”并不是machine和mechanism的总称。--Chixvv留言) 2022年9月23日 (五) 13:35 (UTC)
路过,“机构”一词一般会和社会科学上的“组织”(Organization)划上等号,用来形容机械是不恰当的。--Lxazl5770zh.admin) 2022年10月28日 (五) 13:04 (UTC)

关于Subchunk的译名讨论

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

讨论结果为维持“子区块”这一翻译,并 已完成加入译名标准化。


最近发现wiki上对于subchunk的译名不统一,主要原因还是没有单独的界面,这个词主要存在于村庄刷新有关的内容,如村庄、僵尸围城、袭击等条目都有提及,不同的编者可能就按自己的意见翻了。因此我希望这个词在wiki中能以标准译名的形式得到统一,在这之前我想在这里讨论一下。先说一下这个词(subchunk)的含义,大致是指F3+G打开的区块显示中每个由蓝色线条框选的部分,单词本身也很简单,就是词缀sub-加chunk。有不少优秀的译名,比如“亚区块”、“次区块”、“子区块”、“分区块”等,当然我最喜欢的是“子块”,因为它言简意赅,个人认为这是个最(较)佳的选择。我希望大家能在这里踊跃的讨论,发表自己的意见。最后,由于匿名用户的局限性,希望讨论结束后能有人帮忙去译名标准化界面写入此词条,谢谢。--172.105.202.11 2022年10月4日 (二) 14:32 (UTC)(最后编辑于2022年10月4日 (二) 14:53 (UTC))

先前我们在一个闲聊群讨论过,结论是,子区块和区段这两个词对应的原词一个在JE,一个在BE。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:33 (UTC)
稍微具体一点:Java版的反混淆是“LevelChunkSection”,可以翻译为区段(但wiki内较新的内容也翻译为子区块),但根据其他描述,代码内也有叫子区块的。BE则由相关人员予以确认是子区块。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:35 (UTC)(最后编辑于2022年10月4日 (二) 14:56 (UTC))
再看了一下,好像讨论的东西不太一样。具体我会再问问会反混淆的用户。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:39 (UTC)(最后编辑于2022年10月4日 (二) 14:59 (UTC))
稍微问了一下。subchunk,或section,均分整个区块,是区块的组成部分,范围是16×16×16(单位是方块)。因此叫子区块毫无问题,不需要改为子块(块单用一般对应某block)。但是我没有在本wiki遇到subchunk译名不统一的问题,全部都翻译为子区块。不知道您所说的不统一是在哪些地方,包括是否有适用范围的区别。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 14:48 (UTC)(最后编辑于2022年10月4日 (二) 14:54 (UTC))
之前确实有看到,不过好像早就被修正了(好打脸),巡查员确实给力--172.105.202.11 2022年10月4日 (二) 15:15 (UTC)
已加入标准化列表。-- LakeJasonFace Lakejason0) 2022年10月4日 (二) 15:19 (UTC)

申请:wiki中能否加入有关敌对生物出现误伤,而导致互相攻击的特性。

根据个人测试,敌对生物(如主世界的骷髅)特别是在扎堆或挤在狭小空间时若对玩家进行攻击,容易对同类或异类敌对生物产生误伤(甚至产生仇恨导致相互攻击)。 备注:1.或许误伤也是获取通过骷髅用弓箭击杀苦力怕掉落唱片的方式;2.当玩家掉落剑或部分装备(除护甲外)时,骷髅有概率捡起并替换手里的弓箭。 详情请见:https://www.bilibili.com/video/BV1ey4y1x7qS?spm_id_from=333.999.0.0(第一次写议题,望采纳,谢谢) 小王666留言) 2022年10月20日 (四) 08:36 (UTC)小王666

敌对生物只说了“一些情况”,这块应该写详细点。相关的技巧可以往教程/战斗写。传入神经元权限|讨论|贡献|日志) 2022年10月20日 (四) 11:14 (UTC)

目前测试结果为主世界的僵尸,骷髅,蜘蛛,女巫容易在受到误伤后互相伤害(远程和范围攻击时概率更高),其余生物还再测试当中。令:谢谢回复与帮助。小王666留言) 2022年10月20日 (四) 13:09 (UTC)小王666

关于en的Experimental feature模板

该模板用于标注某一条目或段落的内容包含Java版的实验性特性。官方自22w42a开始通过内置数据包测试一些实验性内容,类似于基岩版的实验性玩法,而zh目前还没有类似的模板,建议引入。

个人认为该模板应与{{Experimental}}合并,在个人沙盒中有该方案的实验性代码。也可以照en的做法,把模板独立出来。各位意见如何?--Yzy32767-T/C- 2022年10月23日 (日) 02:34 (UTC)

目前Java版的实验性内容功能还处于胚胎阶段,很难说这就是和基岩版相同的运作方式。如果确实要合并的话,要考虑一下两个版本之间的Experimental feature能不能划上等号——Java也会和基岩版那样子开启永久性的测试吗?如果不会,那就没法进行合并操作。此外,我认为页面顶部的信息框不要挂太多,因为这一堆信息框只会给读者造成困惑,毕竟大部分人都是来看页面内容的,不是来看注意事项的。--Lxazl5770zh.admin) 2022年10月28日 (五) 12:55 (UTC)
补充一点,在{{Experimental}}加一个控制版本的参数应该就没啥问题了,用来控制只显示其中一个版本,或者都显示。--Lxazl5770zh.admin) 2022年10月28日 (五) 13:02 (UTC)

isSolid()的翻译

本主题或以下段落文字移动自User talk:Snow dash

很多固体不属于Solid材料。这个Solid是不是应该理解成致密?传入神经元权限|讨论|贡献|日志) 2022年11月3日 (四) 08:11 (UTC)

方块属性页面么?。。。好久以前搞的了,那个是代码层面的东西,搞不清楚mj咋想的。没法提供建议。。--Snow dash & ) 2022年11月3日 (四) 11:07 (UTC)
那我改成致密吧。传入神经元权限|讨论|贡献|日志) 2022年11月3日 (四) 11:56 (UTC)

以上段落移动自用户讨论页。由于此次更改在wiki编者所在的群内产生了一些分歧,故决定在此讨论。-- LakeJasonFace Lakejason0) 2022年11月3日 (四) 12:59 (UTC)

整理格式指导

随着MCW:格式指导逐渐扩充,目前已含有许多与格式无关的内容,使得其不再符合标题。因此,考虑将格式指导重新整理,将其中不属于格式的要求移动至其他页面内。另外,也可将其他相关指导(如MCW:书面汉语指导)一并整理。此提议需要社区成员参与并认同,因此发布到社区专页上。对提议本身有想法或者对整理方案有想法都可提出。MysticNebula70 T  2022年11月10日 (四) 14:13 (UTC)

缺少MCD相关内容(尤其是文件名,已经是烂摊子了);关注度应当拆除,只保留重定向链接。另有问题过一会在说。--KaplanSteve  T/C 2022年11月10日 (四) 15:22 (UTC)
建议新建几个独立页面将里面的内容拆分,个人认为拆分成独立页面没有什么坏处,只需要有一个页底导航收集起来即可。--Lxazl5770zh.admin) 2022年11月11日 (五) 14:27 (UTC)

能否将启动器的版本记录和Dungeons启动器的版本记录合为一页?

在英文Minecraft Wiki中,启动器界面包含了Minecraft启动器和曾经的MCD启动器,中文版要不要将其合并?Vjfjng留言) 2022年11月21日 (一) 09:22 (UTC)(最后编辑于2022年11月21日 (一) 10:02 (UTC))

 不需要,会丢失很多信息,另外头图也不一样,更新内容也有区别。--KaplanSteve  T/C 2022年11月25日 (五) 04:26 (UTC)

是否使用bool而不是byte表示NBT标签的布尔值

目前在Wiki中,NBT格式中的布尔值都以byte表示。这主要是因为NBT中不包含布尔值标签,而是使用TAG_Byte进行写入,用0代表false,用1代表true。但是目前看来,使用byte进行表示可能不是最好的选择,原因如下:

  1. 虽然NBT中没有代表布尔值的标签,但是SNBT却可以使用true/false,玩家对于NBT接触更多的其实是SNBT,所以将标签使用bool代替不会造成玩家困惑。
  2. 根据代码来看(Mojang Mapping),写入布尔值的方法被称为putBoolean,读取布尔值的方法被称为getBoolean。之所以使用TAG_Byte写入布尔值,是因为这会让写入文件更方便。
  3. 目前Wiki对于这些布尔值的描述是这样的: xxx:1或0(true/false)- xxxx。每一个布尔值都有这些文字重复。如果使用bool代替,描述会变成: xxx:xxxx。变得更加简洁而且可以让玩家更好的理解这些标签的作用。

目前我想出的做法是:

  1. 将Wiki内所有使用byte表示的布尔值全都替换为bool,并更改相应的描述。
  2. 修改NBT格式页面,并说明SNBT中的布尔值和NBT中TAG_Byte的关系等。

--Nickid2018留言) 2022年11月30日 (三) 03:39 (UTC)

如果你有精力去全部改掉的话,我 支持你的看法。--Lxazl5770zh.admin) 2022年11月30日 (三) 09:30 (UTC)

The Word of Notch已失效

关于游戏创始人Markus Persson的网站notch.com已失效,是否需要更改或删掉–该未签名留言由39.154.160.9讨论)在2022年12月14日 (三) 07:24 (UTC) 添加。请在您的回复后面加上 ~~~~(最后编辑于2022年12月14日 (三) 07:28 (UTC))

属于已知问题,此前已有计划更改。具体来说,可以改为使用Internet Archive。-- Anterdc99Face Anterdc99· 2022年12月14日 (三) 07:44 (UTC)
Advertisement