Minecraft Wiki:社区专页/存档10

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

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

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

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

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

行政员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)

对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)）

关于将本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)