Minecraft Wiki:社区专页

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

请了解，Minecraft Wiki在共识系统上运作而不是投票决定，清楚地阐述自己的理由比简单地支持争论的一方更有效。

涉及管理员权限的相关事宜请发布于管理员告示板。涉及繁简字词转换等问题请到繁体中文问题报告中提出。

常用页面

Minecraft Wiki不是客户服务中心！游戏问题请移步Minecraft帮助中心或者玩家游戏社区。

所有在该页面上发表的无关话题都将被存档至无意义话题处。

请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。

语言

快捷方式: MCW:CP; MCW:PORTAL; MCW:社区

最新Wiki新闻

2023年8月31日 - 中文Minecraft Wiki确定将迁移至Weird Gloop（议题原文）。
2023年7月4日 - 英文Minecraft Wiki公开发布了关于Minecraft Wiki是否要从Fandom迁移至别的站点的讨论（链接）。
2023年6月1日 - 新的巡查员 Siiftun1857上任。
2023年5月4日 - 中文Minecraft Wiki使用的MediaWiki版本已升级至1.39。
2023年1月31日 - 新的管理员 Anterdc99上任。

存档

#	话题	发言条数	参与人数	发起者	最后发言者	最后发言时间（UTC）
1	关于首页大段空白的问题	28	9	North kun	Yzy32767	2022年7月16日 (六) 23:01
2	有关格式指导中图像介绍的说明文字的末尾句号用法之问题与相关提议	11	4	Lakejason0	Lakejason0	2022年7月16日 (六) 08:21
3	【重要】关于本wiki的封禁准则	36	6	Lxazl5770	Lxazl5770	2022年7月3日 (日) 15:03
4	使用模板的大小写与缩写要求、以及部分模板及其参数的使用规范问题	20	6	AblazeVase69188	McplayerFS	2022年7月16日 (六) 09:08
5	对parity一词翻译为趋同这一议题的疑问	14	8	Lakejason0	MysticNebula70	2022年7月9日 (六) 10:31
6	关于bilibili链接的规范	5	2	Ultim 0	Ultim 0	2022年7月17日 (日) 15:29
7	关于“物品修饰器”内对象的遗漏	2	2	Hastel04	Anterdc99	2022年7月12日 (二) 09:03
8	翻译重心	6	6	Leidaozan	Ultim 0	2022年7月15日 (五) 09:46
9	自定义世界生成页面内容的严重缺失，如何解决	4	2	QWERTY-5238	Lakejason0	2022年7月15日 (五) 08:59
10	允许添加“架设一个Mod服务器”一栏	5	5	Leidaozan	Ultim 0	2022年7月16日 (六) 10:55
11	无意义话题的范围拓展	2	2	Ultim 0	MysticNebula70	2022年7月28日 (四) 13:08
12	给Minecraft wiki出百科全书	3	3	雨后的晴天	Ultim 0	2022年7月18日 (一) 03:40
13	user warning模板拆分事宜	5	3	MysticNebula70	MysticNebula70	2022年7月29日 (五) 05:21
14	关于将本wiki迁移至灰机wiki的建议	16	6	114.103.49.42	Ff98sha	2022年7月25日 (一) 10:55
15	关于《Minecraft Bedrock Edition》可能存在的钓鱼特性	?	?	?	?	未知日期
16	关于在"中国版"的"游戏内容"的校正	?	?	?	?	未知日期
17	我的世界基岩版没有斗篷	?	?	?	?	未知日期
18	音樂	1	1	Cyron Choi	Cyron Choi	2022年8月1日 (一) 08:28

话题

关于首页大段空白的问题

本人的多个设备以及部分尝试了查看首页的群友在打开首页的时候均会在“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)

英文版本的版本信息是放在下面的，这样就无需考虑其高度问题。但同样的，就得考虑其他部分的内容宽度和高度问题。--

Lakejason0（论•功） 2022年6月19日 (日) 13:13 (UTC)

我不认为这是需要处理的问题。目前没有插入新栏目的打算。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月20日 (一) 02:33 (UTC)

并不是“插入”的问题，而是重新整理，重新排版的问题。--

Lakejason0（论•功） 2022年6月20日 (一) 03:01 (UTC)

重新排版确实有必要，不过目前暂时没有比较好的设计。有的话可以提出来。MysticNebula70 _T 2022年6月20日 (一) 05:30 (UTC)

仿效en的排版其实也不错，把你知道吗换成每周页面如何呢？--

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

此段内容过长，请通过显示按钮阅读

/** Responsive main page layout **/
#main-page.main-page {
	display: -ms-grid;
	-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	-ms-grid-template-columns: 1fr;
	display: grid;
	grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
	#main-page.main-page {
		-ms-grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
		-ms-grid-template-columns: 1fr 1fr 1fr;
		grid-template-areas: "a a a" "b b c" "d d c" "e f g" "h i j";
		grid-template-columns: 1fr 1fr 1fr;
	}
}

/* ... */

#fp-1 {
	-ms-grid-area: a;
	grid-area: a;
}

#fp-2 {
	-ms-grid-area: b;
	grid-area: b;
}

/* #fp-3到#fp-9同理 */

#fp-10 {
	-ms-grid-area: j;
	grid-area: 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的提案制作的最终提案如下。

此段内容过长，请通过显示按钮阅读

对于首页的CSS：

/** Responsive main page layout **/
#main-page.main-page {
	display: -ms-grid;
	-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	-ms-grid-template-columns: 1fr;
	display: grid;
	grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
	#main-page.main-page {
		-ms-grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
		-ms-grid-template-columns: 1fr 1fr 1fr;
		grid-template-areas: "a a a" "b b b" "c c d" "e f g" "h i j";
		grid-template-columns: 1fr 1fr 1fr;
	}
}

对于每周页面的图片：

<onlyinclude>[[File:{{{img|}}}||{{{img-size|}}}|border|center|class=banner-image nomobile]]<div style="line-height:2em;display:table;min-width:25%;">{{{content|}}}

<p class="nomobile">
{{{img-desc|}}}</p></div></onlyinclude>

还有一些其他的方案。--

Lakejason0（论•功） 2022年6月22日 (三) 06:07 (UTC)（最后编辑于2022年6月22日 (三) 06:42 (UTC)）

由于测试过程中发现了一些新问题，在此说明一下问题以及一些新的提案。

问题1：首页的每周页面图片有浮动，会把文字挤到一边。这个在上方提案中修改为了居中来解决问题。

问题2：版本信息一栏方格下方的列表观感不好，词汇会断开，而且横向列表在列表项目不多时展示效果较差。

基于以上发现的两个问题，我又查看了其他语言站点的首页，相关情况如下：

英文：版本信息单独出一整个横栏，所有的购买链接和版本号放在一起。

西班牙语：重新设计了首页，将版本信息删除。

由于版本信息写全似乎冗余，在即时通信软件中部分用户对EN的目前方案给出的意见是负面的。西班牙语目前没有人评论。大概是这样。--

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（通过直接删除、转移到版本方格内的方式解决）。由于这样的更改会导致先前的版本号合并不再可行（链接显示会不完整），我暂时先放在那边。--

Lakejason0（论•功） 2022年6月22日 (三) 08:01 (UTC)

在处理横向列表的时候发现了EN的一个做法，就是把购买链接写在对应的页面，而不是直接写到首页。这样也更便于维护。--

Lakejason0（论•功） 2022年6月30日 (四) 07:24 (UTC)

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

首页CSS：

/** Responsive main page layout **/
#main-page.main-page {
	display: -ms-grid;
	-ms-grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	-ms-grid-template-columns: 1fr;
	display: grid;
	grid-template-areas: "a" "b" "c" "d" "e" "f" "g" "h" "i" "j";
	grid-template-columns: 1fr;
}
@media screen and (min-width:990px) {
	#main-page.main-page {
		-ms-grid-template-areas: "a a a" "b c c" "d d d" "e f g" "h i j";
		-ms-grid-template-columns: 1fr 1fr 1fr;
		grid-template-areas: "a a a" "b c c" "d d d" "e f g" "h i j";
		grid-template-columns: 1fr 1fr 1fr;
	}
}

至于版本信息（“开始游戏！”）的处理，个人并无较好的提案，建议将购买和试玩的链接移动到对应页面的{{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简介的空白过多吧？--

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后遇到了以下问题：

版本信息处在2036px宽度后开始出现较严重的留白。
移动端窄视图下“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)

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

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

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

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

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

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

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

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

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

我的提议：一律不用句号，并且将原本的说明文字精简到一句话以内。以简化繁。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月29日 (三) 13:43 (UTC)

这种要求不一定都能实现。建议将我的提案作为保底规则，然后将您的提议作为优先规则。--

Lakejason0（论•功） 2022年6月30日 (四) 07:11 (UTC)

由于管理员提出了新的意见，我的新提案如下：

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

新：图像介绍的说明文字应精简到一句话以内。当且仅当图像内容足够复杂，需要使用超过一句话才能说明清楚时，可以超过一句话，但最后的结尾处不用句号。即使说明文字在多句话的前面的语句中已出现句号，最后的结尾处仍不用句号。

以上是我的新提案。如有更好的表述也欢迎提出。--

Lakejason0（论•功） 2022年6月30日 (四) 10:43 (UTC)（最后编辑于2022年6月30日 (四) 10:44 (UTC)）

这应该是两条：

图像介绍应精简到一句话，图像内容足够复杂、说明清楚需要超过一句话的除外；
图像介绍末尾不应有句号，即使说明文字较长，前面的语段已出现句号。传入神经元（权限|讨论|贡献|日志) 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)

图像描述过长还会影响网页观感（尤其是移动端）。若图像内容足够复杂，我建议先写简要介绍，再用注释加上详细描述。

IBUCKEEET ·· 2022年7月2日 (六) 05:01 (UTC)

在本来就是说明文字的地方再加注释，我不是很能接受这种做法。--

Lakejason0（论•功） 2022年7月2日 (六) 06:07 (UTC)

由于此议题没有进一步推进，我再次提出提案，希望各位给出意见：

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

新：图像介绍应精简到一句话以内，图像内容足够复杂、说明清楚需要超过一句话的除外。即使图像介绍的说明文字较长，其中靠前的语句已出现句号，末尾也不应有句号。

希望提案采纳。--

Lakejason0（论•功） 2022年7月6日 (三) 10:52 (UTC)

支持。--AblazeVase69188（讨论 | 贡献） 2022年7月9日 (六) 13:48 (UTC)

由于没有更多反对意见，且先前的疑问基本已解决，相关提案 已应用。--

Lakejason0（论•功） 2022年7月16日 (六) 08:21 (UTC)

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

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

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

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

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

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

粗略查看了一下。目前该准则缺少对于先前使用较多的“提示性封禁”这一用法的说明。同时，我认为应当在该准则开头以较为亲切的口吻，使用Msgbox说明好，封禁是wiki维护与破坏防治中靠后的环节，管理团队不会对（绝对否定的说法可以自行修改为较为缓和的语气）轻微的不熟练操作采取封禁这一手段，等类似的内容。同样，应该在Wiki条例当中提及违反条例会按照封禁准则封禁。--

Lakejason0（论•功） 2022年6月30日 (四) 12:55 (UTC)

我已经根据你的说法进行了适当修改。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月30日 (四) 13:16 (UTC)

“目标用户无视任意警告（例如撤销编辑或讨论页警告）”“管理人员在条件允许下应当在目标用户的讨论页里留下{{User warning}}以提醒该用户注意遵守Wiki条例”这些前戏应该统一，例如目标用户无视管理人员在目标用户讨论页留下的{{User warning}}。
“匿名用户不允许永久封禁”推不出“封禁时长应当不超过1年”，留后半句就够了。
未尽事宜应该有个限制，例如不违反条例和applicable law的行为不应受到惩罚性封禁。
为什么设置那些不保留讨论页申诉权的情况？申诉权就是被封禁用户的权利，滥用申诉权的才应该撤销。传入神经元（权限|讨论|贡献|日志) 2022年6月30日 (四) 17:09 (UTC)

第二点把关联词移除掉就没问题了。其他的都算有道理。--

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)

已经修改。特别地，部分违规情况属于极其恶劣的情况（例如发广告和利用傀儡破坏），不应当给予其申诉权。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月1日 (五) 03:01 (UTC)

只要违反格式指导就给予一天封禁太过严重。违反格式指导的理论上没有封禁的必要，只需要给予提醒即可。屡次不改本身就违反条例。--

Lakejason0（论•功） 2022年7月1日 (五) 03:08 (UTC)

以及，利用傀儡破坏本身并不绝对属于极其恶劣的情况（取决于做出的破坏行为本身），因此不保留申诉权利并不合理。--

Lakejason0（论•功） 2022年7月1日 (五) 03:15 (UTC)

我写了一下Msgbox的内容，希望加入页面开头。表述都可以适当调整。--

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)

可以在讨论页申诉吧？--

Lakejason0（论•功） 2022年7月1日 (五) 11:59 (UTC)

无限期封禁也可以通过申诉缩短封禁时长吗？无限期封禁给人一种行为非常恶劣的感觉。TripleCamera（留言） 2022年7月1日 (五) 12:07 (UTC)

这是未尽事项，所以我也不清楚。--

Lakejason0（论•功） 2022年7月1日 (五) 12:08 (UTC)

需要直接永久封禁的是最恶劣的违规行为。如果是因为多次违规而导致永久封禁的，由于三番屡次劝阻无效，一般不会出现减刑情况。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月1日 (五) 12:45 (UTC)

这些事应该写清楚。建议：不得因被封禁用户申诉减刑至低于适用细则最低标准。传入神经元（权限|讨论|贡献|日志) 2022年7月1日 (五) 13:22 (UTC)

已经补充一条。--Lxazl5770_zh.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使用条款中的规定的禁止行为，是极其恶劣的破坏行为，因此必须直接永久封禁而不给予申诉权。--Lxazl5770_zh.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使用条款的行为均属于严重违规行为，不予申诉。--Lxazl5770_zh.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使用条款的用户属于跨越红线级别的违规行为，是极其严重和恶劣的行为，严重情况下甚至会有触犯现实法律的行为。因此不予申诉权利。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月1日 (五) 17:02 (UTC)

Fandom服务条款是红线，违反Fandom使用条款极其严重，这都没有争议。问题是认定严重违规需要给申诉权，这也应该是原则性的。传入神经元（权限|讨论|贡献|日志) 2022年7月2日 (六) 02:10 (UTC)

我看了下，目前草案上规定的立即永久封禁的行为都是违反Fandom使用条款的行为，因此不予申诉权。--Lxazl5770_zh.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年。--Lxazl5770_zh.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条例里。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月2日 (六) 02:01 (UTC)

那么，能不能给相关条例一个着重显示呢？如果真的要永久封禁+不予申诉的话（是不是要这么做目前仍在讨论中），应该提前告诉用户这种行为是“极其严重和恶劣的”，并警告他们后果有多么严重。--TripleCamera（留言） 2022年7月2日 (六) 04:05 (UTC)

我想这个已经超出了本封禁准则的范畴。另一方面，“Wiki不治眼瞎”。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月2日 (六) 06:47 (UTC)

本条例拟定于7月11日（一）生效。届时将正式成为条例文本并不作进一步更改。现在处于商议期，还请各位继续提议。--Lxazl5770_zh.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}}等模板有大小写的原因是英文中有大小写区分的必要，中文则没有。出于方便（搬运进来或者搬运出去）考虑，此类区分大小写的情况下，建议是“翻译成英文的时候需要大写的”大写，反之小写。--

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模板我记得本身也就不应该单独使用，我没有办法讨论这里的用例。强行前置空格会造成源代码观感差。--

Lakejason0（论•功） 2022年7月2日 (六) 09:55 (UTC)（最后编辑于2022年7月2日 (六) 10:06 (UTC)）

我此处所说的“Sprite模板”是用来泛指包含BlockLink这一类模板的集合的。--AblazeVase69188（讨论 | 贡献） 2022年7月2日 (六) 10:51 (UTC)

留言：

原则上首字母大小写以及空格与下划线的相互替换并不会影响被调用的模板、页面或者用户（例如user:ultim_0等效于User:Ultim 0），个人建议不做任何更改。
- 而部分模板的参数同时接受大小写（甚至是混合输入），是因为这些模板在处理对应参数时使用了魔术字{{lc:}}来将输入的参数转化为全部小写（如{{lc:Be}}会显示为be），对于这些模板参数的大小写，个人建议也不做任何更改。
至于同义参数，个人建议依用户输入习惯而异，与对模板别名的态度一样，也不做任何更改。
至于{{only}}使用参数|short=的情形，个人认为应当在表格等内容拥挤的地方使用，以避免占用过多页面空间影响观感。
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)

这么做的问题仍然是源代码层面的一个不太好看（因为没有其他场合会需要一个额外的空格）。--

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)

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

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

讨论结果为 维持当前译名。

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

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

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

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

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

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

-- Lakejason0（论•功） 2022年7月3日 (日) 14:09 (UTC)（最后编辑于2022年7月5日 (二) 04:09 (UTC)）

中立，我反覆閱讀該討論，我還是沒看懂趨同的定義，是我英語不好還是因為我在台灣用語不同的關係ouo。總覺得英語搞那麼模糊，我們真的需要準確翻譯嗎？－－

乳液Louis ^对话 •_贡献 2022年7月4日 (一) 14:50 (UTC)

不从正确性的角度为前提讨论，自然会得出像你这样的结论。这也是MCBBS那边询问的结果。--

Lakejason0（论•功） 2022年7月5日 (二) 06:25 (UTC)

根据目前本人掌握的资料，看待这个问题的用户可以分为三个群体：基岩版开发者、Java版开发者、其他人。基岩版开发者不用多说，多数赞成使用这一翻译，但是Java版开发者不赞同，并且只是给出了“不是人话”这种无意义的理由，并且双方翻译者并不能很好地一起交流。其他人则是“好听就行”。

我不认为这个议题会得出什么共识。现在要解决的问题已经不是Parity怎么翻译的问题，而是两个版本的开发者之间的偏见存在的问题。然而这个问题不可能本wiki能够解决，偏见会一直存在。

实际上，“待同步特性”这个原本的翻译也不是通过所谓的共识决定的，这个翻译出自本人之手，只是我本人认为更老的翻译“等价议题”显得非常晦涩难懂，于是换成了相对更好的、更容易接受的。但是在Miemie发出上述敲定翻译的请求前，根本就没人去深究Parity的真正含义。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月4日 (一) 15:25 (UTC)

留言：可否考虑从MCBBS等地引流，让更多的自然人参与讨论，从而达成真正的共识？--ultim_0 ( USER | TALK | WORK ) 2022年7月4日 (一) 15:35 (UTC)

意义不大，见lx的留言。--

Lakejason0（论•功） 2022年7月5日 (二) 04:01 (UTC)

换句话说，这个议题只是想要wiki编者之间真正达成共识，其他地方并不算在内。--

Lakejason0（论•功） 2022年7月5日 (二) 04:03 (UTC)

疑问：

Java版编者（姑且认为等同于“Java版开发者”）反对的理由是什么？~~真的“只是给出了‘不是人话’这种无意义的理由”吗？~~（追加：是我的理解出现了问题）
为什么这次在社区专页讨论没能达成共识？是社区专页的问题还是人的问题？
这个问题已经上升到了“两个版本的开发者之间的偏见存在的问题”吗？真的无法解决吗？

--TripleCamera（留言） 2022年7月5日 (二) 04:46 (UTC)（最后编辑于2022年7月5日 (二) 09:11 (UTC)）

lx所说的无意义的理由主要是指MCBBS新闻版的那些人并不认同从正确性角度优先考虑译名，而是从是否顺口的角度考虑。既然讨论前提不同自然没有意义。

为什么我认为专页未能达成共识是因为除了管理员，支持人数少，中立和疑问的人数多。只要有人再来几个支持，或者行政员认为自己得出这是共识的过程没有问题，那么趋同的替换操作大可以继续进行。

不清楚，不晓得，这个议题仅限于wiki内的使用，不会也不能涉及其他地方。标准化是要让大部分人接受，但不接受也没有办法了。--

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站）的内容（视频、专栏、动态等），但是其中一些链接存在不规范的地方：有的编者会选择直接复制粘贴哔哩哔哩手机客户端生成的短链接或者这种链接展开后的链接（从浏览器地址栏复制）。

以b23.tv开头的短链接（如 https://b23.tv/KmKbAw ，见于传输电路）不够直观，必须在点击链接之后才能获悉其中的内容是视频、专栏还是动态；一个视频、专栏和动态可能会对应多个不同的短链接，对于查重会产生一定的不便。
短链接展开后形成的链接往往会包含一些无用的参数（如上述链接展开后的内容为 https://t.bilibili.com/489477365230381234?share_medium=android&share_plat=android&share_source=COPY&share_tag=s_i&timestamp=1621431868&unique_k=KmKbAw ，其中问号后面的参数含义为分享途径、平台、时间戳等），这些参数对于Minecraft Wiki并无实际作用，反而会增加页面的长度，影响观感。这种情形目前在Minecraft Wiki尚未出现，但应当避免。
- 本例中的时间戳是用户生成分享链接的时间，并非视频中的时间锚点。

综上所述，建议为站内的哔哩哔哩链接提供一个固定格式的模板。先前已在自己的用户页中设计了一个哔哩哔哩视频链接的模板（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:Bvl和Template: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对应页面自行补充。--

Anterdc99（论·功） 2022年7月12日 (二) 09:03 (UTC)

翻译重心

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

那就麻煩您貢獻了！--

乳液Louis ^对话 •_贡献 2022年7月15日 (五) 06:17 (UTC)

自己动手，丰衣足食。--ChengBing（留言） 2022年7月15日 (五) 06:28 (UTC)

自己动手，丰衣足食；
从往期我的了解来说，来wiki看哪怕是技术性教程的人（我还写了两篇）都很少，加之教程是本wiki的历史遗留大问题，也只有可能是有人会补充这些内容才会有这些内容的改进。

除了基岩版大版本之外，Java版的版本更新内容并没有你想的那么难翻译，说是先翻译重要内容，可是翻译完重要内容后，不重要的内容顺道早就翻译完了（尤其是先前没人翻译的漏洞，现在是有人提前抓取提前翻译好的）。作为wiki向来的薄弱处基岩版，我觉得反而才更应该受到关注吧。

此外，管理员是可以看到一些数据的。我想他们如果能够分享一些结果的话也不是不可以。在数据分析页面，可以得到以下数据：

所有页面访问次数；
被搜索关键词排行；
访客所在地；
访问最多的页面和文件；
访客使用的客户端情况（手机和桌面端比例，桌面端浏览器比例）
用户回访率；
日编辑量。

这些数据都仅限管理员使用，未得到许可所有信息不可与他人分享。我想得到许可后，分享一些数据自然可以明白哪些页面是重点。--

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源代码，用两天时间研究得出了这几项内容的结构，并得出了每一个参数的作用。

现在我的问题是：

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

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

先参考en怎么做的（没做就算了）。Density function直译密度函数，我在该页面上方放置的Misode的链接已经翻译过了相关内容。Placed Feature目前我翻译为已放置的地物。奇怪的话我也没办法。补肯定都要补，因为官方有反混淆表，不可能只写1.18的内容。--

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的内容少？至于难以区分这一点，原文也一样的。--

Lakejason0（论•功） 2022年7月15日 (五) 08:59 (UTC)

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

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

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

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

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

没人说不可以，不过Mod内容（教程除外）确实在本站体系下的各个Minecraft Wiki都不怎么被允许了，因为都搬到FTB去了。不过我知悉，您的部分编辑内容似乎涉及到了一个国外知名服务器，因而被过滤器拦截。虽然我不反对写一个架设Mod服务器的教程，但内容还是要注意的。--

Lakejason0（论•功） 2022年7月16日 (六) 09:00 (UTC)

正如我在相关页面的讨论页回复的，只要内容不涉及具体的mod或其他任何的具体的东西，都可以允许存在，但如果此教程与其他教程较为相似，则有可能被删除。--

Anterdc99（论·功） 2022年7月16日 (六) 09:02 (UTC)

教程的页面建立标准相对其他主页面来说相对宽松，只要不涉及特定的Mod、插件或服务器等，就可以保留这篇教程。您在此前提出了翻译英文Wiki的教程来补充中文Wiki对应内容的建议，这没有问题，不过请注意，目前英文Wiki的内容质量正日益下滑，并在一些内容的收录与否的问题上与中文Wiki相去甚远，因此建议您先筛选或者与其他Wiki编者讨论，再搬运英文Wiki的内容。--AblazeVase69188（讨论 | 贡献） 2022年7月16日 (六) 10:34 (UTC)

留言：

mod类内容在Minecraft Wiki受到限制是有历史原因的：早些时候Minecraft Wiki上存在一些非官方的mod，这些内容使用{{disclaimer}}标记；后来在Minecraft Wiki的自我整顿中，这些内容被删除，但一些其他语言的Minecraft Wiki（如ru）仍然允许此类内容存在。
只要不在教程中对具体的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）。在美国确实有书籍以该协议发布，但不清楚其如何做到协议的兼容。--

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

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

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

支持将uw下的警告信息拆分成多个模板。关于严重等级，我认为过于细分的等级在本wiki上并不实用，建议分成轻微情节警告和严重情节警告两级即可。关于具体警告内容，我认为实用性较大的有破坏、可视化编辑、机器翻译、页面格式、上传文件、乱改乱用译名。--葉月桐§ 2022年7月20日 (三) 20:13 (UTC)

议题没人回复，主要是没法下手。等级的话不清楚该怎么办，也许可以分个三级（提醒、轻微警告、严重警告？）。至于具体的内容，现有都拆开似乎也没问题，毕竟这些内容的添加是因为wiki史上存在过对应的案例。--

Lakejason0（论•功） 2022年7月21日 (四) 10:55 (UTC)

命名的话，继承EN应该没问题。--

Lakejason0（论•功） 2022年7月21日 (四) 10:56 (UTC)

考虑了一下，本wiki分成三档等级（提醒、警告、严重警告）应该足够使用了。关于警告事宜，参照Hatsuki kiri和现有的也暂时够用了。MysticNebula70 _T 2022年7月29日 (五) 05:21 (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那边的镜像查看相关内容。--

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)

很遗憾，出于上述和下述各种各样的理由，我们不可能为了某一个人而把整个站点迁走。也许你会说这样会妨碍更多的贡献者，但很遗憾这里并不是只有中国大陆用户，既然繁体访客的比例更高，我觉得还是不迁移带来的好处更多。--

Lakejason0（论•功） 2022年7月22日 (五) 05:35 (UTC)

网站迁移本身也是个问题。参考灰机的案例来说，当年从Fandom迁到灰机的站点，很多是Fandom也死了，灰机的也死了。究其本质是，流量本身迁移不走。Fandom也特别注重SEO优化，由于各种规定的限制，不太好做站点搬迁导向，因此贸然搬迁只会导致更多问题。--

Lakejason0（论•功） 2022年7月21日 (四) 10:42 (UTC)

您应该还需要知道一点，就是本站的繁体访客数量比例是不断增加的。出于这样的原因，继续改进繁简字词自动转换应该比搬迁站点要更加对用户友好。--

Lakejason0（论•功） 2022年7月21日 (四) 11:02 (UTC)

不建议这么做，理由同上。当时灰机站长对中文MCW在BWIKI建立镜像站的行为进行了猛烈抨击，现在想要迁移过去恐怕也不是那么好说的。据我所知，Fandom下的网站都没有被墙过，有时候访问速度缓慢、图片无法加载都属于正常现象（有其他Wiki用户认为这纯粹是自己的网络问题）。所以，如果要做出贡献的话，您可以通过改善自己的网络环境来提高网站的访问速度。--AblazeVase69188（讨论 | 贡献） 2022年7月21日 (四) 11:36 (UTC)

你的建议很好，但是我拒绝，因为这里是中文Minecraft Wiki，不是中国大陆Minecraft Wiki，非常抱歉。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月22日 (五) 05:34 (UTC)

疑问您指的是港澳台地区的用户访问本站更方便吗？还是迁移之后没有繁简转换？Watermelontail（留言） 2022年7月22日 (五) 07:05 (UTC)

虽然话题已经结束了，但是我稍作解释：我们的访客中，繁体用户占了不少于40%的比例，如果因为“国内访问速度不好”而迁移至国内农场，这对繁体用户而言非常不公平。何况迁移之后繁简转换系统如果出现问题，我们wiki的声誉将会大打折扣。--Lxazl5770_zh.admin（论 ▪ 功） 2022年7月25日 (一) 08:15 (UTC)

这些不是重点，至少从上方来说，迁移了的好处比不迁移的好处少。如果从迁移的原因上来说也不合适（也就是并不是本站的大多数用户都在遇到网络问题）的话，行政员自然从原因上反驳，以此作结，其他原因肯定也不考虑。--

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肯定没有权利阻止其他人复制站点内容，只要遵守协议要求（我在上方说了争议开始后镜像方做了调整以符合协议），镜像行为是没问题的。退一步，从当时疑似侵权的角度来说，灰机站长认为这个镜像行为是有人恰烂钱，从中攫取了利益，因此开始破口大骂，然后深恶痛绝，但事实是并没有人拿到任何物质利益。总之争议行为本身应该算是消失了，但是就风评和敌对态度来说，我觉得灰机方面肯定不会再考虑让本站再搬到他们那边去。--

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)

关于《Minecraft Bedrock Edition》可能存在的钓鱼特性

本主题全部或部分段落文字已移动至Talk:钓鱼。

关于在"中国版"的"游戏内容"的校正

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

我的世界基岩版没有斗篷

本主题全部或部分段落文字已移动至MCW:无意义话题。

音樂

現在，音樂的分類上很有問題，我根據遊戲內建重新分類了所有音樂，如此：Special:Diff/672700。希望各位參與討論，謝謝。Choi Chin Long 2022年8月1日 (一) 08:28 (UTC)