Minecraft Wiki:社区专页

来自Minecraft Wiki
跳转至: 导航搜索
社区
专页

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

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

涉及管理员权限的相关事宜请发布于管理员告示板

常用页面

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

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

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

最新Wiki新闻
  • 2021年4月4日 - 中文Minecraft Wiki已啟用香港繁體(zh-Hant-HK/zh-hk轉換表沙盒
  • 2021年3月30日 - 中文Minecraft Wiki域名已迁移至https://minecraft.fandom.com/zh/。
  • 2021年2月13日 - Fandom对社区团队架构进行了更改,中文Minecraft Wiki新的Wiki Representative(原名Wiki经理)将由Winston Sung - zh出任。
  • 2021年2月11日 - 新的巡查员Snow dash上任。
  • 2020年10月5日 - Minecraft Wiki已迁移至统一社区平台(UCP)。详情见此
# 话题 发言条数 参与人数 发起者 最后发言者 最后发言时间(UTC)
1 制作了总讨论页的顶端目录 6 2 star00 star00 2021年4月6日 (二) 14:42
2 重新规划生物分类 7 5 siiftun1857 Endearing Cat 2021年4月15日 (四) 13:55
3 提议修改格式指导,以及再次更新Message box样式 18 7 MysticNebula70 MysticNebula70 2021年5月4日 (二) 13:28
4 是否应加入有关盔甲和工具的重定向 4 3 AblazeVase69188 AblazeVase69188 2021年4月30日 (五) 15:15
5 深层绿宝石(铜、煤)矿石的相关解释需要改吗? 2 2 Minesunset1030 Lxazl5770 2021年5月5日 (三) 15:56
6 重写LootChest模块 8 6 Star00 RealCuervo 2021年5月4日 (二) 16:36
7 修改Minecraft Wiki:管理制度 38 15 Dianliang233 SkyFuInMC 2021年5月27日 (四) 14:46
8 加入标签储存模块 3 2 Snow dash Snow dash 2021年5月16日 (日) 16:14
9 BE开发版归属问题 8 3 Jingji132 Jingji132 2021年6月7日 (一) 02:06
10 命令描述页面,把“示例”挪到“效果”与“输出”之前 10 7 Dahesor Dahesor 2021年6月8日 (二) 05:32
11 关于“你知道吗”段落的规范化 4 3 Lxazl5770 Lxazl5770 2021年6月11日 (五) 06:06
12 fandom INTERNAL_SERVER_ERROR, 500 2 2 207.180.203.231 145.239.77.243 2021年6月11日 (五) 00:54
13 广告 2 2 173.255.254.49 Endearing Cat 2021年7月13日 (二) 09:41
14 更新携带版/基岩版版本记录中引用的链接 1 1 MinecraftPig321 MinecraftPig321 2021年7月14日 (三) 04:40
15 沒辦法上傳圖片 3 3 Zica87 Dianliang233 2021年7月24日 (六) 13:19
16 【对于一系列服务器小游戏是否加入的讨论】 4 4 183.209.144.184 AblazeVase69188 2021年7月26日 (一) 02:34
17 关于基岩版开发内容留存及去向问题 3 3 SkyEye FAST Addonscommandresource 2021年7月28日 (三) 03:48
话题

制作了总讨论页的顶端目录[编辑源代码]

本人制作了用于总讨论页的顶端目录,可以方便的查看当前存在的论题及相关信息,具有多种的标记功能(功能一看就懂就不赘述了),效果如下。

如觉得不错可考虑应用于Minecraft Wiki:社区专页Minecraft Wiki:管理员告示板的header中。--Star Zero · 维基假期中 2021年4月3日 (六) 07:13 (UTC)

 问题:就目前来看此模块仍存在较多影响正常使用的问题,因此暂持保留意见。MysticNebula70 T  2021年4月3日 (六) 07:53 (UTC)
问题已全部解决。--Star Zero · 维基假期中 2021年4月4日 (日) 04:05 (UTC)
根据你的成果重写了模块,如测试无问题且无异议即可将其转正。MysticNebula70 T  2021年4月4日 (日) 13:36 (UTC)
感谢猫猫的协助。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)
另此模板还需要修改讨论通过论题后的颜色,原通过模板背景颜色与24小时内更新颜色不易区分。--Star Zero · 维基假期中 2021年4月6日 (二) 14:42 (UTC)

重新规划生物分类[编辑源代码]

由于生物分类异常混乱且缺乏规则,我一点时间整理了这些内容。然而,介于这是一个不小的变动,对先前分类方式的完全颠覆,我希望在大动干戈之前能够先取得社区共识。

草稿已经提交至沙盒,包含对生物条目和{{Entities/content}}的更改。

这个变更的主要内容是将生物分类由被动型/中立型/敌对型这三大类改为友好生物/敌对生物这两类,抛弃中立型类别并将其中的生物送入前两个大类的子分类。

如果达成共识,那么所有生物条目的infobox内的生物类型也会更新,并且在这一方向将不再与En看齐。--Magnussiiftun1857[T/C/E] 2021年4月5日 (一) 07:29 (UTC)(最后编辑于2021年4月5日 (一) 13:24 (UTC))

 支持对生物分类进行变更 较反对全部改变到新分类方式。先不论文章实际内容(因为反正总得有个标准),抛弃中立型合并到其他类别的变更会给读者造成直觉阻碍。虽然很多页面都要说“中立型和敌对型”,然后再去除中立型里面的动物,确实造成了表意赘余,但是除了这种赘余之外,是否还有更多需要改动的必要?
此外,两个分类方式是否有源代码层面的依据?目前的提案应该是来源自声音事件分类,但是这似乎不能说“就和源代码层面对Mob的处理”完全一致。如果有人能基于某一套反混淆(我建议yarn或者Mojmap)给出相应的依据,我觉得会更清晰一些。-- LakeJasonFace.png Lakejason0) 2021年4月5日 (一) 07:41 (UTC)
 问题:友好生物/敌对生物如何判定?这只能主观判定吧。-- Dianliang233 TC 16 2021年4月5日 (一) 08:33 (UTC)
per myself,根据sounds.json内的声音事件类别。-- LakeJasonFace.png Lakejason0) 2021年4月5日 (一) 08:37 (UTC)
标准的选择其实相当多……不过我倾向于,将是否被进度“怪物猎人”和“资深怪物猎人”追踪,视为目前的决定性标准。
实际上,友好生物和敌对生物分类的内容来自先前的被动型和攻击型,区别只有多了原本归类于中立型的生物。--Magnussiiftun1857[T/C/E] 2021年4月8日 (四) 18:05 (UTC)
关于区分友好生物和敌对生物,游戏里本身也分不清楚(比如可以蜇人的蜜蜂属于友好生物,猪灵属于敌对生物,北极熊在Java版算友好生物在基岩版却算敌对生物),所以我个人还是赞成保留现有的区分方法。--Lxazl5770zh.admin) 2021年4月13日 (二) 02:51 (UTC)

 现有分类方式确需改进 不建议这样更改。很多读者可能已经习惯了现有的分类方式,这样更改会使一些人难以接受。我认为基于现有的分类方式上进行合理的更改会更好。--Endearing Cat讨论) 2021年4月15日 (四) 13:55 (UTC)

提议修改格式指导,以及再次更新Message box样式[编辑源代码]

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

讨论结果为 同意更新


目前中文wiki的msgbox是放在infobox之后的,这并不符合大多数wiki的主流布局。我建议按照多数wiki的做法来,先msgbox然后infobox,并修改格式指导。

然后,目前的msgbox样式不能适应以上的调整,需要相应修改。大致需要更改的内容有:

  1. 将所有非mini的msgbox统一宽度;
  2. 增加msgbox的外边框;
  3. 两个相邻的msgbox取消间隔;
  4. msgbox内的文本改为左对齐。

另外,msgbox可以使用预设的颜色(目前有7个:redorangeyellowgreenbluepurplemagenta),以不同的颜色表示不同类型的信息(如红色表示需要立即执行的操作,橙色表示页面有内容方面的问题,等等),同时仍然支持自定义颜色。

此处可以预览新样式。

现在此征询社区的意见。MysticNebula70 T  2021年4月16日 (五) 12:24 (UTC)

 支持。不过和英文的差别还是很大,和正经Ambox的差距倒是很小。-- LakeJasonFace.png Lakejason0) 2021年4月16日 (五) 14:07 (UTC)
大部分 支持。只不过那个灰色的border我不大喜欢。-- Dianliang233 TC 16 2021年4月16日 (五) 14:11 (UTC)
需要修改的还有消歧义模板。正常的顺序为消歧义-讯息框(msgbox)-信息框(infobox)。
对于预设颜色,我建议使用type(模式),每个模式对应一种颜色,然后选择模式。以及我个人建议不同名字空间设置不同样式。
对于文本左对齐,我认为现在mcw的讯息框宽度太小了,居左可能不太好看,如果要居左最好宽度拉长点,视具体情况而定。--Star Zero · 维基假期中 2021年4月16日 (五) 14:12 (UTC)
 支持,预览看着不错。不过调换很多页面的顺序确实是个很麻烦的工作。。--Snow dash & ) 2021年4月16日 (五) 14:14 (UTC)
 同意,新样式挺好看--Lxazl5770zh.admin) 2021年4月16日 (五) 15:35 (UTC)

目前有部分成员提出不添加灰色边框。对此条建议有其他看法的请在此回复。MysticNebula70 T  2021年4月17日 (六) 11:33 (UTC)

移除了灰边框,效果请自行对比。MysticNebula70 T  2021年4月20日 (二) 10:28 (UTC)

预设颜色的用途[编辑源代码]

各个预设颜色的使用场合是什么?有关想法请在此提出。对配色本身有意见也在此提出。MysticNebula70 T  2021年4月17日 (六) 02:26 (UTC)

忽然才意识到这些配色在我的显示器上很素,很暗。如果改的更亮一点呢?-- LakeJasonFace.png Lakejason0) 2021年4月17日 (六) 03:40 (UTC)

目前英文wiki选取的颜色用途:

  • red:disclaimer和提删;
  • purple:建议页面移动、拆分、合并;
  • orange:页面存在内容问题;
  • yellow:页面存在格式问题;
  • green:标记页面的其他状态(例如是stub、正在编写中);
  • blue:标记版本相关(例如版本独有、将在下个版本添加);
  • magenta:未使用/自定义。

以上内容可供参考。

另:若按照type来选取颜色,则仍然需要确定一些预设的type用来对应颜色。如果同意使用type,可在此提议type。MysticNebula70 T  2021年4月17日 (六) 11:43 (UTC)(最后编辑于2021年4月17日 (六) 12:31 (UTC))

 建议:新增颜色gray,用于表示丢失(如{{Lost version}}{{Lost pre-reupload}})、未发布(如{{Unreleased}})或者可能不存在(如{{Unproven}})的版本。--Ultim 0 ( VIEW | TALK | CONT ) 2021年4月17日 (六) 12:21 (UTC)(最后编辑于2021年4月17日 (六) 12:39 (UTC))
这样的type咋样:
  • red->important
  • purple->pageaction
  • orange->problem
  • yellow->notice
  • green->pagestatus
  • blue->version
-- LakeJasonFace.png Lakejason0) 2021年4月17日 (六) 12:44 (UTC)(最后编辑于2021年4月17日 (六) 12:45 (UTC))
 不认可:都不怎么样,行为和程度混杂,单词和双词混杂,而且和用途不搭,建议全部重定。--Star Zero · 维基假期中 2021年4月19日 (一) 01:40 (UTC)
建议方案:
类型(颜色) \ 名字空间 条目名字空间 文件名字空间 讨论名字空间
delete(red) 请求删除
move(purple) 移动、拆分和合并 移动和重命名 合并,拆分和重命名
content(orange) 内容问题 严重警告和问题 大部分警告和提醒
style(yellow) 格式问题 较轻警告和问题 较小警告和提醒
protection(grey) 保护
version(blue) 版本 \ \
notice(default) 条目注意 注意 通知和消息
Star Zero · 维基假期中 2021年5月4日 (二) 10:43 (UTC)
建议补充green,用于标示正在进行的工作以及未完成的页面。--Ultim_0 ( USER | TALK | CONT ) 2021年5月4日 (二) 10:54 (UTC)
修改版本:
类型(颜色) \ 名字空间 条目名字空间 文件名字空间 讨论名字空间
warning(red) 警告消息和请求删除 请求删除
move(purple) 移动、拆分和合并 移动和重命名 合并、拆分和重命名
content(orange) 内容问题 严重警告和问题 大部分警告和提醒
style(yellow) 格式问题 较轻警告和问题 较小警告和提醒
protection(grey) 保护
version(blue) 版本 \ \
status(green) 状态 \ \
notice(default) 条目注意 注意 通知和消息
Star Zero · 维基假期中 2021年5月4日 (二) 11:33 (UTC) (最后编辑于2021年5月4日 (二) 11:35 (UTC))
模板已更新,各用到msgbox模板的模板需要单独更新。MysticNebula70 T  2021年5月4日 (二) 13:28 (UTC)

是否应加入有关盔甲工具的重定向[编辑源代码]

我最近在Wiki上进行某些条目的翻译工作时,想使用和en一样的重定向(比如说[[Diamond Armor]][[Iron Armor]],均会被重定向到[[Armor]]),但是发现中文Wiki除了皮革盔甲之外没有其他相关的重定向了。

如题,加入的理由有如下:

  1. 某些编辑者可能更倾向于输入[[钻石盔甲]]而非[[盔甲|钻石盔甲]]
  2. 一些初来乍到的编辑者对Wiki是否有这样的重定向不熟悉,可能会直接输入[[钻石盔甲]];发现Wiki上没有这样的重定向之后,为了方便此编辑者可能会输入钻石[[盔甲]],这样不符合部分读者的习惯——他们可能会在看不清楚的情况下点击“钻石”而非“盔甲”。

综上,我认为有一定的必要加入相关重定向,现在此提出意见,征求社区的共识。--AblazeVase69188讨论 | 贡献) 2021年4月23日 (五) 14:18 (UTC)(最后编辑于2021年5月1日 (六) 03:55 (UTC))

如果需要的话,您可以自行添加重定向。MysticNebula70 T  2021年4月23日 (五) 14:31 (UTC)
 支持 这种确实对新手会产生困扰,我以前也体会过hhhhh Yfohdit讨论) 2021年4月23日 (五) 17:46 (UTC)

相关重定向已全部创建,如有异议请在此提出。--AblazeVase69188讨论 | 贡献) 2021年4月30日 (五) 15:15 (UTC)

深层绿宝石(铜、煤)矿石的相关解释需要改吗?[编辑源代码]

如题,21w17a的数据包中已经可以生成这三种矿石的深层变种,但数据包的更新内容需要和正式更新内容一起写吗?--Minesunset1030讨论) 2021年4月30日 (五) 22:15 (UTC)

数据包的内容不大可能和常规内容共存,因为它已经不属于原始玩法。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:56 (UTC)

重写LootChest模块[编辑源代码]

本人受中文McWiki管理员邀请,重写LootChest模块,原模块有以下问题:

  1. 代码杂乱,严重过长
  2. 数据结构复杂,维护困难
  3. 运行效率低

虽然原义只是修改后端代码而不动前端显示效果,但基于以下原因,我也一并进行了重构:

  1. 原模块生成的表格过长,对于大表较难对应左边和上面的标尺。
  2. 原模块生成表格将不同结构合并为一张大表,导致浪费空间多。
  3. 移动端显示效果差。

因此我预计进行以下更改:

  1. 将数据储存方式更改为原文件的格式(JSON),其他运算全部在模块内进行,不需要人工进行编辑。
  2. 提高了模块运行效率,从而可以一次性生成全部结构的表格,不需要箱子战利品加载多个页面的形式。
  3. 对于前端输出显示效果,一个结构输出一个表格,通过flex布局的形式进行合并,从而优化查找数据方便程度和移动端显示效果。

当前重写后的模块存在以下问题:

  1. 由于拆分table的原因,虽然提高了查找效率,但表格不对齐对于观感有部分破坏。
  2. 由于重写为非人工编写的数据储存方式,可能有个别功能无法继承(大部分都可以继承)。

当前已发现的问题:

  1. 部分物品和全部结构名无法进行转换,将会添加转换表进行转换。
  2. 同一个大结构里的不同箱子结构无法归于同一个整体,这个可以人工分段解决。
  3. java开发版和基岩版后续会添加支持。

当前的数据储存页面:

当前的进度:

  • 结构输出:指定结构
  • 结构输出:全部结构 ?
  • 物品输出:单个物品 X
  • 物品输出:全部物品 X

当前的示例页面:

由于未知原因,相同的代码在mcwiki上无法实现效果,因此请先前往Test wiki进行查看。

请发表重构模块的建议,感激不尽。--Star Zero · 维基假期中 2021年5月1日 (六) 14:08 (UTC)

没有什么更好的建议了(在群里都交流过了,但是似乎不太明朗),就 支持一下重构吧。EN那边感觉也找不到人解释。-- LakeJasonFace.png Lakejason0) 2021年5月1日 (六) 15:36 (UTC)
 支持重构,希望还能加入的一点就是java版和be版相同时的合并表格。--Snow dash & ) 2021年5月1日 (六) 16:16 (UTC)
 支持,见前面Sigma166/ 2021年5月2日 (日) 09:40 (UTC)
分为共有,java版,基岩版三个部分如何。--Star Zero · 维基假期中 2021年5月2日 (日) 09:57 (UTC)
 支持。--Minesunset1030讨论) 2021年5月2日 (日) 10:16 (UTC)
 支持。也许可以用{{only|je}}{{only|be}}Sigma166/ 2021年5月2日 (日) 10:41 (UTC)
可否考虑i18n?方便维护也方便迁移到其他wiki。--RealCuervo讨论) 2021年5月4日 (二) 16:36 (UTC)

修改Minecraft Wiki:管理制度[编辑源代码]

背景

中文Minecraft Wiki现行与过去的管理员选举机制存在明显漏洞和缺陷,为某些图谋不轨的管理员施行专政封闭的管理提供了可乘之机。几年前发生过的反pow团队割裂现象,推进了管理制度的制定。但是,它反而成了管理员滥权的工具。因此,有必要重定管理员选举制度,主要是管理员与巡查员的产生办法。

原因
  • Minecraft Wiki:管理制度中所规定的“行政员保留无理由撤销管理层职务的权利””在职务到期时由行政员根据其表现决定是否刷新和延长时限”“不多于n名在职管理员对其就职提出反对”“3⁄4以上的在职管理员认可其对Wiki的贡献。”使管理员可以“钦定”管理员、巡查员的就职和任免,严重违反了wiki社区共识高于一切的基本法。
  • 现今中文wiki社区环境已经成熟,共识系统可以确立,“人少”“效率低”已不是借口。
修改办法

Minecraft Wiki:沙盒/Minecraft Wiki:管理制度。请善用比较功能查看差异。修改内容主要有:

  • 全面摈除专制选举的陋制
  • 加入管理员投票选举制度和巡查员符合要求即授予制度
  • 提高了巡查员和管理员的要求
总结

这是社区从选举层面坚持和完善社区共识制度体系、确保wiki长治久安的必要之举,充分体现了正当性和进步性。相信通过选举制度的完善,Minecraft Wiki一定能够走出长期存在的“专制泥沼”,集中精力完善内容、添砖加瓦,再创发展奇迹。仅代表个人,不代表Fandom意见。希望得到各位的支持。-- Dianliang233 TC 16 2021年5月5日 (三) 03:14 (UTC)


应当事人要求就此折叠上述讨论。--Lxazl5770zh.admin) 2021年5月10日 (一) 14:27 (UTC)


利益不相关:作为非本维基管理组,通过我在WP的认知和我在某维基担任主要管理者的经验来谈谈维基中的民主体制。
声明:本人不清楚本维基管理层情况,请根据实际情况实行。
引子
目前来说,对于社群民主实践最深的维基网站来说,毫无疑问是维基百科,在维基百科中有着这样的描述:

(是否是管理员)不应该有什么大不了的。

——吉米·威尔士

管理员没有任何高于其他用户的特权,唯能实现社群讨论所得的共识。

但是这并非所有维基都要遵循这样的理念,因为每个维基的现状不同,维基百科有着独特的实践条件(后文会提及),重新引用上面的引用语:

wiki不是可口可乐,不是全世界的wiki都有一样的制度

——某位用户
上面的讨论,我认为过多的使用了其他维基的条文来讨论“制度应该是怎么样的”,我认为不必过多的参考其他维基,而是从实际情况出发,我简要的谈谈实际情况中我的认知。
维基百科具有以下的条件:
  • 维基百科编者众多
  • 编者具有社群选举的参与度
  • 编者有相关的选举观念
而到了本维基,我们就不得不思考以下几个问题:
管理组的人数是否需要控制?
毫无疑问是需要的,基于一个社群中管理员适宜的占比以及上文提到的“拉帮结派”原因,管理员应该被控制在一个数量。
上文电量量有说到社区会自己控制管理员的数量,但是:
我们的编者是否对于管理员选举有认知?
本维基没有维基百科长期的民主政治历史,因此本维基的编者真的有充分对于“一个人是否应该成为管理员”的认知吗?相反,由于社群较小,社群中的编者大都互相认识,由于关系亲近,对于相熟的人自然会带有自己的偏移,给予更放松的通过条件(比如说大家对于界管权限的认知)。
以当前Mcwiki的社群讨论环境,很有可能会发生上面的情况,且大部分社群成员对于管理员上任的重要性可能没有概念,不参与或盲目投支持票,而不考虑社群是否需要更多管理员,管理员和社群考虑的方向是有区别的,再者:
我们编者的人数真的足够进行通过民主投票,表现社区真正公正的共识吗?
实际上,维基百科由于其编辑者的众多,进行投票的人数非常广泛,而我们维基进行投票会有多少满足条件的编者参与社群投票?
电量量说“社群条件已成熟”,而我从我这段时间的观察来说可能未必,况且是满足条件的编者,比如,现在发投票,能有20个人参与吗?
如果参与投票的人数没有达到一定规模,那么投票的结果就无法反映社群意见,而可能会发生上文提到的“倾向性投票”。依据现状,很有可能没有足够的人参与到社群讨论投票中,导致投票结束无限拉长。
我们真的需要完全民主吗?
综上所述,Mcwiki完全改制可能还为时过早。让我们思考以下,当前的寡头制管理组织形式真的很不堪吗?当然不是,寡头制管理有效率高等优点,社群也有足够的空间进行民主讨论,但最大的问题是寡头制过于依靠几位管理者的道德品质与个人能力,可能会导致滥权的发生,因此要考量的是:管理组现在真的有存在滥权专制的现象吗?这就要看本维基具体情况了。
最后
其实我个人是比较欣赏社群民主体制和电量量的改革精神,我自己在管理的维基也进行过多次这方面的改革,但是这可能不太符合实际情况。
我本人对本提案不持有立场,内容仅供引发思考,也望电量量放下立场,思考这些内容是否合理。
我个人认为现阶段不必操之过急,不必直接使用投票制度而是逐渐添加管理者的限制,减少可能使管理人专制的条件,将权利逐渐分散到社群中。
另:如果巡查员要改为即授予制,可能要选择降低一下巡查员的权限,目前权限确实有点超过用户组应有的权限。
Star Zero · 维基假期中 2021年5月8日 (六) 09:56 (UTC)
 同意Star Zero的观点。之前我考虑不周,盲目地表达自己观点。中文Minecraft Wiki的社区环境确实不够成熟,而且目前管理层滥权的可能性也不大,个人认为现阶段的任务应该是努力发展Wiki与其社区成员。由于我个人对本Wiki的深层和历史情况也不是非常熟悉,所以持 中立态度。
不过我觉得适当提高对进入管理层的用户的要求也是合理的,但我认为沙盒中的管理制度上更改的要求未免有点高了,例如对巡查员的要求“在中文Minecraft Wiki的编辑记录达600条以上”以及对管理员的要求“在中文Minecraft Wiki的Template(模板)名字空间编辑记录达100条以上”。--AblazeVase69188· 2021年5月8日 (六) 13:06 (UTC)
我不知道我应该做出什么评价。
少打一点感叹号,少打一点问号,少打一点粗体。能正常说话就不要写那么多反问句。不要让越来越强烈的语气演变成咄咄逼人的攻击性。
这个话题崩溃的一塌糊涂,上头了的话就应该先去洗把脸清醒一下。--Magnussiiftun1857[T/C/E] 2021年5月8日 (六) 11:18 (UTC)(最后编辑于2021年5月8日 (六) 11:20 (UTC))
 支持EPIC! MC中文wiki的毒菜问题也不是一天两天了,不彻底根治的话只会持续发酵下去,没个好的,加速编者流失。不过毒菜问题真的能靠自下而上的提案让毒菜结束吗?--Kaniol233讨论) 2021年5月8日 (六) 14:35 (UTC)
 意见

肉食者谋之,又何间焉?

——《左传》
私之栖于Minecraft Wiki,尚不足期年,个中条例,犹有不通,故 不予置评。--Ultim_0 ( USER | TALK | CONT ) 2021年5月8日 (六) 15:34 (UTC)

以下部分段落文字,移动自管理员告示板

对“修改Minecraft Wiki:管理制度”话题的回应:

首先,恳请大家先了解一点:不是所有事物都是非黑即白(binary)的。
众决没错,但是要依情景而论
对于众决好不好,对效率有何影响,政治科学、管理学、组织行为学等都有涉及,知乎之类也有很多高论,我才疏学浅不敢高谈阔论。但是我想简单引用弗雷德·菲德勒权变理论来解释我上述的这个论点。简要地说,工作结构的不同,需要采取不同的职务权力才能达成合适的效果,而没有完全众决一定是最好的简单的非黑即白的说法,否则上述几个学界的研究者恐怕也没有存在的必要了。当然在Wiki里行政员和管理员也都应该是普通的编辑者,不过我想在一定程度上进行仲裁对于日常运作还是有必要的。
中文Minecraft Wiki已经非常开放
就拿英语Minecraft Wiki来说,据我所知没有任何管理员推举公示的制度,而英语Wiki的规模少说有中文Wiki的10倍。本Wiki上全保护页面也已经尽量减少,就连首页也有部分片段可以开放给所有注册用户编辑,这一点上就算不是绝无仅有也是非常少的。之前的Wiki条例修订,也经过了公示咨询,绝对不存在哪个行政员、管理员一手遮天的情况
所有编辑者都是善意的,包括管理员
提出修改管理制度也是为了Wiki的良好发展才做出的,这一点我愿意相信。但是可否请大家也相信管理员有自己的坚持也是为了Wiki的良好发展?在这里我想稍微辩护几句,对Wiki最恶意的人最该做的就是不来编辑(请不要把这句话反过来理解,编不编辑是个人的自由),而不是参与在其中“浪费”自己的时间,能参与讨论的,已经都是非常关心Wiki的同好了。如果大家都能有这个前提的话,我相信交流当中也会少一些矛盾。
之后的安排
我们会讨论修改管理制度,同时行政员、管理员的组成也会再加考虑,请各位耐心等待。
--一名编辑者RealCuervo讨论) 2021年5月9日 (日) 08:47 (UTC)
我想说的话大体上已经在编辑者QQ群里说完了,我在这里顺便补充一些需要了解的东西:WP:DEMWP:POLLWP:BATTLEGROUNDWP:FAITH。--Lxazl5770zh.admin) 2021年5月9日 (日) 09:32 (UTC)
补充一张《反驳金字塔》图,作为镇楼用途。
格雷厄姆的反驳金字塔
--Lxazl5770zh.admin) 2021年5月9日 (日) 14:07 (UTC)
感谢管理的真诚回应。其他的就不多说了,决裂过的人也没必要再挽回了。-- LakeJasonFace.png Lakejason0) 2021年5月9日 (日) 10:23 (UTC)
这里指的不是电量。我甚至都不认为哪一个(只有一个例外)决裂的人是因为wiki事务才决裂的。-- LakeJasonFace.png Lakejason0) 2021年5月9日 (日) 10:24 (UTC)(最后编辑于2021年5月9日 (日) 10:38 (UTC))
讨论及决定的不是管理组,是社群本身,即本讨论。--Star Zero · 维基假期中 2021年5月10日 (一) 14:18 (UTC)
对于Cuervo/a2的发言我就不用说太多了;因为已经很久没有在这里编辑过了,又因为每一次出现都能被说是旧病复发,我知道我没有多少发言权。关于管理员(此处尤其指某位行政员)是否能够一手遮天的问题,我想有过遭遇的自然会知道答案。如果中文 Minecraft Wiki 真的能够做到长久以来虚无的“皿煮”的话,那我就在幕后为你们的成功庆祝吧。另外,好像看到有一名马迷成功上任了管理员,这个也一定要祝贺一下,这是坠吼的!
Minecraft Wiki Anti-* Safe House. --SkyFuInMC (DI/CO) 2021年5月27日 (四) 14:46 (UTC) from Onion Network

加入标签储存模块[编辑源代码]

21w19a中Mojang加入工具加速破坏的方块相关标签后,{{ID table}}中包含标签的方块大幅度增加;且快照更改标签相关内容的频率有所提高。我希望将游戏data文件夹中标签相关的内容经过脚本整理后,储存到Wiki模块。Template:Sandbox/GameTag/doc是一个样板。用途有两点:

  1. 类似于模块:SpecialConversion,在{{ID table}}{{{blocktags}}}参数中返回涉及到的相关标签。这样便于维护,更改时只需要更新数据模块,且更新标签从无到有或从有到无的相关方块物品页面即可。
  2. 标签的表格中使用。输出标签包含内容,引用的其他标签也能自动生成链接以方便页面内点击跳转,便于维护。

现就这些问题发布于社区专页:

  1. 是否需要更改{{ID table}}以支持自动生成标签或提供报错分类。以提示过时的手动参数、空标签或自动合并相同标签。但技术难度很大,现有的rowspan都是手动指定的。
  2. 现有的输入都是手动输入,更改需要不小的编辑量,在此申请社区共识认同。

谢谢。--Snow dash & ) 2021年5月16日 (日) 02:54 (UTC)

如果改的话,顺便把基岩版的标签也弄一下?不过基岩版目前标签有亿点点乱--2190303755(T|C) 2021年5月16日 (日) 03:49 (UTC)

对,忘说了,模块是Java版的标签,基岩版没有json定义,需要其他人来搞。。--Snow dash & ) 2021年5月16日 (日) 16:14 (UTC)

BE开发版归属问题[编辑源代码]

既然允许存在这种1.16.200+的开发版包含1.17的特性,那要不要把目前1.4.0的前四个开发版(1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12)还给1.2.13,更何况1.2.13正式版也加入了对应的实验性玩法。与此同时我认为既然这样的过渡版本开发版内容已经不再属于当前的主版本号的更新主题,应该考虑为其划分出独立的定位,而不是直接放到一起。可以参考

-Jingji132讨论) 2021年6月4日 (五) 08:00 (UTC)

 不建议:自1.16.200发布以来,1.16.200+正式版从未出现过“Caves and Cliffs”这个实验性玩法选项,即这些正式版不包含洞穴与山崖特性,而不像1.2.13那样,可以通过实验性玩法启用水域更新的部分特性;况且这些开发版也不全都测试洞穴与山崖特性,也有其他内容(如1.16.200.53加入光追),且会发布到正式版中,并非过渡更新;直白地说,这些开发版如同一个实验工具,用完了该放哪放哪。至于1.2.13的问题,参见:en:User talk:Ff98sha#1.3 builds don't exist (yet)。--XiaoXin666T·C 2021年6月4日 (五) 15:46 (UTC)
我的主要目的还是回过头讨论1.2.13开发版的归属问题,我认为目前的规则与1.2.13时所讨论出的规则并不相符,1.2.13那时认为的包含新内容的后续开发版都属于1.4,但它们本质上是1.2.13的开发版,甚至1.2.13正式版都加入了对应的实验性功能;而现在1.16.200+的规则认为开发版加入了新内容,即使正式版不包含对应的实验性功能,也保持从属关系。我认为这两个规则是近乎完全相反,按理应该选择其一,个人倾向于1.16这种更合乎常理。在这一前提下,我再建议考虑为那些添加新内容的开发版划分出独立区域,而非像现在这样让人以为1.16.200+是为了下界更新搞了一堆开发版,具体的形式肯定不是能直接确定下来的,我只是提供参考,为的是说明目前确实存在一定弊端。-Jingji132讨论) 2021年6月5日 (六) 03:53 (UTC)

You'll see more 1.16 versions before seeing 1.17. Increasing the second octet is still a little ways off, even though we're still testing Caves and Cliffs features. At the end of the day, it's just a version number.

你将会在1.17发布之前见到更多的1.16版本。进一步加入新特性还要走很多路,即使我们现在仍在测试洞穴与山崖特性。最后,它只是个版本号。

——mattgartzke
由上可见,官方也把1.16.200+当作了版本号,从未将它们视为洞穴与山崖的版本(开发版也如此)。而且若照此划分,许多版本的归属将会变得很奇怪,1.16.2011.16.221,以及那些没有加入洞穴与山崖特性而加入其他特性的开发版,如RTX beta、1.16.200.53、1.16.210.50等,也和洞穴与山崖有从属关系?这一弄不就更让人不解了吗?不论如何,它们本质上就属于1.16(下界更新)的次版本或开发版,即使与下界更新关联不大,只不过它们被借去当作了测试洞穴与山崖特性的工具,没必要给它们单独搞个工具箱,用完了还是要回到1.16,不然Mojang不会在正式版移除这些特性。所以我还是认为 维持现状即可。补充说明一下,我关心的是1.16.200+版本的问题,1.2.13的问题我不作讨论。--XiaoXin666T·C 2021年6月5日 (六) 05:19 (UTC)(最后编辑于2021年6月5日 (六) 07:13 (UTC))
你自始至终都没有讨论到人家的频道上去啊,Jingji132也明确指出他赞同目前1.16的版本分类现状,你“当做对方反对你的观点然后额外赘述一堆这些话”是没有必要的。他对于1.16的的观点与你是一样的,维持现状。如果不讨论1.2.13的问题,请不要发表不必要的言论。方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 15:58 (UTC)
本人只是就“添加新内容的开发版划分出独立区域”的建议而讨论,反对拆分独立区域而已(一开始我写的是反对拆分),不过没有想到什么好建议,只好维持现状。--XiaoXin666T·C 2021年6月6日 (日) 16:23 (UTC)
 赞同,无论是从发布时间来看,还是从“都是1.2.13.x”来看,还是从特性的继承性来看,1.2.13.8·1.2.13.10·1.2.13.11·1.2.13.12都属于1.2.13的测试版,而非1.4的,纵使有1.4的特性加入,但是1.2.13正式版将这些新特性重新放回实验性玩法也不足以支持“这四个版本不是1.2.13”的开发版。首先,将新特性放入实验性玩法只是改动一行代码的事情,1.2.13正式版是基于1.2.13.12而发布的;其次,将新特性放入实验性玩法其实是正确的事,正式版是正式发布的,新内容可能尚有bug,没有充分的测试自然不能当做正式特性加入游戏,不管是这些特性放入beta,还是这些特性放入实验性玩法,他们的目的都是一样的,“测试新特性”,这是合乎常理的需求,跟“1.2.13正式版的测试版到底有谁”丝毫没有关联。目前把1.2.13的四个测试版归为1.4正式版的内容据我所知有页面分类和infobox、{{Development versions}}。希望速速更正。——方法放寒假 (Talk - Contributions) 2021年6月6日 (日) 16:00 (UTC)
就是这个意思,至于我后面为的是提出“模板中无法突出洞穴与山崖这类更新从何版本进入开发阶段”这一问题,给出方案仅对该问题提供参考而非推荐。(而且其实1.2.13的测试版也是通过实验性玩法添加的水域特性,正式版是直接继承)-Jingji132讨论) 2021年6月7日 (一) 02:06 (UTC)

命令描述页面,把“示例”挪到“效果”与“输出”之前[编辑源代码]

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

如题。

当前命令介绍页面的格式大致是:语法,参数,效果,输出,示例,历史。

对于一条命令,想要查找资料的初学者,示例显然比输出更重要。把示例往上放到参数下面应该更好,这样也便于阅读者对比示例中的例子用到了上面的什么参数。

如:/clear

请自行用预览功能尝试

在读示例的时候会轻松很多,去对比参数与语法。

en版是把示例示例放最后了?算了跟我们无关……我是觉得改一下更好--Dahesor讨论) 2021年6月7日 (一) 20:21 (UTC)

“应由大众讨论的事项请布告于Minecraft Wiki:社区专页。”--Snow dash & ) 2021年6月8日 (二) 00:16 (UTC)
 赞同:明晰而立竿见影的案例比晦涩且难以理解的说教更具动力。
 收回前言:案例固然重要,但不是命令子页面的必需。--Ultim_0 ( USER | TALK | CONT ) 2021年6月8日 (二) 03:59 (UTC)(最后编辑于2021年6月8日 (二) 05:13 (UTC))
 反对。本来就是给命令提供参考的页面,对于初学者来讲是上面那么回事,其他人呢?针对不太依赖示例的人来讲,确认命令的输出更实际点。而且我也没见事情本身的特性没解释完就写例子的玩意,真那么写的多半都给人一种莫名其妙编排混乱的感觉。至于对比,我觉得开MC手写命令去对比更实际点,而且实践一直都是学习的方法之一。顺带提一句,命令介绍页本身就不是放教程的地方。——IcyPhantom 讨论I贡献 2021年6月8日 (二) 04:35 (UTC)
 信息依我薄见,还是示例更重要。这不是教程不教程的关系。随意点进该页面的读者在看完参数后显然更需要示例,而不是深入才会涉及到的,详细的效果表,或是只有用execute store才会涉及到的输出。对于有兴趣者当然会自己下滑,特地要查找资料的读者也自然会寻找。还有我不认为这会造成编排错乱。Wiki是必经给人看的资料,没必要一定照标准。综上,我 +坚持己见,将示例挪到参数之后,或至少,将示例挪到效果之后,输出之前。--Dahesor讨论) 2021年6月8日 (二) 05:21 (UTC)
 反对。首先明确“命令”下面的子页面是手册页性质的,而不是教程性质的。而无论什么手册页,示例都是放在最后,或者干脆不放示例。
就比如,在runoob上描述函数的顺序就是“描述”(对应“导言”),“声明”(对应“语法”),“参数”,“返回值”(对应“效果”和“输出”)和“实例”(对应“示例”)。
在man7(甚至没有示例)或者其他地方的类似内容基本也是同样的顺序。
另外,我 同意IcyPhantom的意见。-- Anterdc99Face.png Anterdc99· 2021年6月8日 (二) 04:51 (UTC)(最后编辑于2021年6月8日 (二) 04:58 (UTC))
 这是坏的,因为抄示例不会让新手变的更强……虽然大部分新手很可能没有耐心看完语法。嘛,也算是一种矛盾,本来之前准备写如何阅读命令相关页面的教程的,但是不太好写就咕了,嗯。以及个人意见,新手要用好命令页面,绝不应该一上来就往示例里面看。-- LakeJasonFace.png Lakejason0) 2021年6月8日 (二) 05:23 (UTC)
顺便我们有一个东西叫做目录,如果新手想看的话完全可以直接点目录就是。虽然我们都知道就算目录摆在那里我们也一次都不会点(真是矛盾)。-- LakeJasonFace.png Lakejason0) 2021年6月8日 (二) 05:28 (UTC)
 反对。不管是技术类教科书还是指导书还是其余的手册/教程性质的文本,都只有两种排版方式:1. 根据示例来讲效果;2 列举效果最后放个例子。MCW的命令子页面很明显不适合第一种(第一种的页面应该归到教程的子页面)。对于初学者不想看“效果”与“输出”的话可以直接跳到最后看示例,但是根据内容完整度或连贯度来看,示例不应该提前。(我甚至想把示例直接删掉)。——方法放寒假 (Talk - Contributions) 2021年6月8日 (二) 05:24 (UTC)
 留言。好吧,那既然大家都反对,我就放弃辩论啦--Dahesor讨论) 2021年6月8日 (二) 05:32 (UTC)

关于“你知道吗”段落的规范化[编辑源代码]

目前“你知道吗”段落内容泛滥,是时候要加以规范了。这是en搬运来的格式指导,不知各位的意见如何。--Lxazl5770zh.admin) 2021年6月8日 (二) 15:48 (UTC)

 支持,这个指导内容很详细明确。--Snow dash & ) 2021年6月8日 (二) 15:50 (UTC)
 提醒:这些格式指导的内容与MCW:SG/F#你知道吗大致相同,只是未见规范效果。--葉月 § 2021年6月8日 (二) 15:56 (UTC)
已经有了????那没事了--Lxazl5770zh.admin) 2021年6月11日 (五) 06:06 (UTC)

fandom INTERNAL_SERVER_ERROR, 500[编辑源代码]

我之前在试用wiki的新皮肤fandomDesktop,发现参数设置里还有第三个皮肤,是mobile开头的。 选上这个皮肤然后保存设置之后,就再也打不开Minecraft wiki了,任何页面都是500错误,只好通过清除cookie解除登录状态才能打开wiki。现在我重新登录后依旧是提示500。fandom什么时候能修复这个bug?有没有什么临时的解决方案(除了退出登录以外)?--207.180.203.231 2021年6月10日 (四) 17:10 (UTC)

终于找到解决办法了,在网址后面加上 ?mobileaction=toggle_view_mobile 之后就能进去了。fandomsb --(和上面是同一个人的)145.239.77.243 2021年6月11日 (五) 00:54 (UTC)

广告[编辑源代码]

广告太多!有wiki的,还有google的。 173.255.254.49 2021年7月13日 (二) 09:33 (UTC)

这些广告不是我们Wiki能控制的,因为我们(包括管理员等在内)没有网站的实际控制权。您可以通过登录账号以及使用浏览器插件来减少广告的显示。--Endearing Cat讨论) 2021年7月13日 (二) 09:41 (UTC)

更新携带版/基岩版版本记录中引用的链接[编辑源代码]

许多携带版版本页面中(例如携带版0.4.0)底部引用的修复漏洞列表由于mojang.com迁移的原因均已失效。 三种修改方案:1.使用web.archive.org,访问该页面的存档。缺点是国内无法访问 2.使用bug.mojang.com的筛选器功能,筛选出在某个版本被修复的bug。 3.从英文站上直接复制。 MinecraftPig321讨论) 2021年7月14日 (三) 04:40 (UTC)

沒辦法上傳圖片[编辑源代码]

設定完檔名及描述之後按上傳,會跳出一個視窗寫「過濾器在您的編輯自動檢測到了一項問題,您將暫時無法作出該操作。 與您此次編輯所匹配的過濾規則概述如下:上传文件时未选择授权协议。」 用這個網頁才能正常上傳:上傳檔案 --Zica87讨论) 2021年7月23日 (五) 10:26 (UTC)

您上传文件时未选定授权协议,并且使用了中文文件名,因此被过滤器检测到,拒绝上传。请您检查您上传文件时的授权协议和文件名。MysticNebula70 T  2021年7月23日 (五) 10:48 (UTC)
这其实是VE/2017SCE导致的问题,因为它们不支持选择协议。-- Dianliang233 TC 16 2021年7月24日 (六) 13:19 (UTC)

【对于一系列服务器小游戏是否加入的讨论】[编辑源代码]

我发现【掘一死战】是一个wiki页,为什么不将【起床战争】,【空岛战争】,【饥饿游戏】等加入Wiki?顺便添加一些技巧。

wiki不应该只加入客观内容,如【在服务器里PVP】等属于主观内容是应该保留的!

183.209.144.184 2021年7月24日 (六) 12:39 (UTC)热爱minecraft的某人

根据现行格式指导,“只允许加入Mojang Studios表示已经玩过的小游戏”,否则这类页面不具有足够的关注度,因而不应创建。掘一死战等页面的存在实属英文Wiki搬运时期的历史遗留问题,而且值得注意的是英文Wiki已有用户发起提议删除这类页面并将其转移至Minecraft服务器Wiki的讨论(见此),并获得相当数量的支持。所以非常 不建议继续创建这类页面。--葉月 § 2021年7月24日 (六) 12:56 (UTC)
我认为这些内容 不应该加入到主页面命名空间,但是可以加入到教程页面。--222.216.84.54 2021年7月26日 (一) 01:15 (UTC)
我认为此类内容正如上面所说,不应该加入到本Wiki当中,而不只是主页面命名空间。此前本Wiki也有过关于Mods的内容,但是也快被移动或删除完了,因为它们不具有足够的关注度,而且违反现行格式指导。--AblazeVase69188· 2021年7月26日 (一) 02:34 (UTC)

关于基岩版开发内容留存及去向问题[编辑源代码]

如题,中英文Minecraft Wiki上的基岩版开发内容(文档及教程)已经过时,严重程度不一。目前由于更新不及时(Mojang不更新en)以及基岩版开发Wiki的建立,这些内容的留存价值已经越来越小。

对于此问题,经初步讨论,现存有以下方案:

  • 保持现状不加改变,发挥其仍有的价值。包括参考翻译等。
  • 一刀切,全部从Minecraft Wiki移除,并软重定向至开发Wiki。
  • 使用Tabber等方式使多版本并存。
  • 欢迎踊跃提议。

--SkyE | Talk · Contributions · Logs 2021年7月27日 (二) 15:47 (UTC)

我个人是倾向于全部重定向到基岩版开发Wiki的,因为这里还没有专门的人去维护这些技术性内容页面,而且容易过时导致参考价值变低。--Lxazl5770zh.admin) 2021年7月28日 (三) 02:01 (UTC)

个人认为先提出一个较好的替代方案,再对旧的文档进行处理是一种比较好的方法。但如果仅仅只是把旧的文档一刀切,而对新的文档又没有任何翻译或其他措施去处理,倒还不如在开发wiki直接引条链接去en的原页。 ACR研究小組編輯讨论) 2021年7月28日 (三) 03:48 (UTC)