Minecraft Wiki

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

了解更多

Minecraft Wiki
Advertisement

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

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

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

常用页面

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

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

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


语言

最新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 重构SPConversion与Module:SPConversion 6 4 Lakejason0 Snow dash 2021年3月3日 (三) 12:13
2 InPageEdit使用满意度小调查 1 1 机智的小鱼君 机智的小鱼君 2021年2月20日 (六) 05:25
3 箱子战利品 5 4 Sigma166 Lxazl5770 2021年2月26日 (五) 01:20
4 各个版本“修复”部分中的链接 8 4 Sigma166 Sigma166 2021年2月28日 (日) 10:22
5 关于引用进度的标准 2 2 IcyPhantom Lxazl5770 2021年3月25日 (四) 08:52
6 新增关于字词转换的帮助页 4 2 Lakejason0 Lakejason0 2021年4月23日 (五) 18:41
7 愚人节 3 2 119.237.10.81 119.237.10.81 2021年3月31日 (三) 11:34
8 制作了总讨论页的顶端目录 6 2 star00 star00 2021年4月6日 (二) 14:42
9 重新规划生物分类 7 5 siiftun1857 Endearing Cat 2021年4月15日 (四) 13:55
10 提议修改格式指导,以及再次更新Message box样式 18 7 MysticNebula70 MysticNebula70 2021年5月4日 (二) 13:28
11 是否应加入有关盔甲和工具的重定向 4 3 AblazeVase69188 AblazeVase69188 2021年4月30日 (五) 15:15
12 深层绿宝石(铜、煤)矿石的相关解释需要改吗? 2 2 Minesunset1030 Lxazl5770 2021年5月5日 (三) 15:56
13 重写LootChest模块 8 6 Star00 RealCuervo 2021年5月4日 (二) 16:36
14 修改Minecraft Wiki:管理制度 8 6 Dianliang233 Powup333 2021年5月5日 (三) 19:41
话题

重构{{SPConversion}}Module:SPConversion

原标题为:重构{{SPConversion}}Module:SPConversion
由于简繁的地区翻译差异,我们有转换表,用于自动地将文章内的词汇更换为简体/繁体用户所熟悉的词汇,以提升阅读体验。但是,部分词汇转换的使用量低,或者词汇太长影响转换效率,因此Leo leo 768制作了模块Module:SPConversion(模板同名)。但目前,这个模板的默认输入是简体文本,由于游戏文本可能产生变化,这种输入方案可能会导致大量不必要的更改来修复。并且据反馈,该模块目前的代码品质不够高。考虑到目前此模块主要用于来源为游戏内文本的转换,提出以下提案:

  • 将模板当前的匿名参数输入改为游戏内的本地化键名。使用ID有利于维护语言中立,即所有编者都可以较为方便地使用转换,而不需要刻意的都去使用简体文本,且本地化键名较为固定,可以减少因游戏内文本变化而导致的大量改动。
  • 仍然保留|type=的同等功能参数。由于这个模块实际上也用于故事模式的转换,而故事模式的文本实际上并不存在游戏内id,也不可能把这些页面内的文本全部替换成输入id的形式(源代码层面很影响观感),所以仍然有必要保留。此外,部分教程页面不存在嵌入的需求,而在页面内反复使用模板又很累赘,所以仍有必要保留。

此讨论由Snow dashMysticNebula70和我个人在私下提出,现放在社区专页征求共识。-- LakeJasonFace Lakejason0) 2021年2月17日 (三) 04:00 (UTC)(最后编辑于2021年2月17日 (三) 04:09 (UTC))

我们希望将模板改为通过{{sc|本地化键名}}的方式调用,输出繁简转换。包含字幕与统计相关字符串,因此主要用在音效段落等相关位置。现有的调用使用机器人批量转换为上述调用。
顺便也会改一下模块名字,我个人认为SpecialConversion可能会更好--Snow dash & ) 2021年2月17日 (三) 04:58 (UTC)
引用本地化键名可能 不直观,在语义上也不通畅,能做到英语输入中文变种输出是不是更方便,也可以和当前的autolink一同更新。--RealCuervo讨论) 2021年2月18日 (四) 14:08 (UTC)
考虑到{{sc}}的使用场合,个人认为引用本地化键名并不存在太多语义上的问题。例如用量最多的音效段落,其使用方式为模板{{sound table}}的一个参数,使用本地化键名并无不妥。不存在键名的场合也不需要随用随调的情形,而是采取类似于-{H|...}-的方式将需要转换的文本全部包含进来,也无需输入英文名称。而且使用英文名称反而存在更新不够及时以及维护更麻烦的问题。MysticNebula70 T  2021年2月19日 (五) 16:37 (UTC)(最后编辑于2021年2月19日 (五) 16:40 (UTC))
进度:沙盒中的Module:Sandbox/SpecialConversion基本完工,支持Java版1.16.5所有游戏内字符串,快照数据模块分开维护,有报错分类,输入本地化键名使用。但暂时还没有页面内全局转换。--Snow dash & ) 2021年3月1日 (一) 09:17 (UTC)
进度2:模块已基本成型,页面内全局转换也加入,没有高消耗的反查。--Snow dash & ) 2021年3月3日 (三) 12:13 (UTC)

InPageEdit使用满意度小调查

大家好,我是小工具inPageEdit的开发者,当初自用的小插件如今被这么多人使用这么多次,承蒙大家厚爱了!

为了更直观地获取InPageEdit使用方面的反馈,方便后期开发维护,特此邀请ipe的使用者,耽误大家大约3分钟的时间,来填写一个问卷,问卷采取匿名形式,内容绝对不会用作商业用途。

https://www.wjx.cn/vm/mtTpOXX.aspx

再次感谢大家,鞠躬。 机智的小鱼君⚡ (给我留言✨) 2021年2月20日 (六) 05:25 (UTC)

箱子战利品

对于箱子战利品来说,Java版基岩版有完全一样的部分(比如下界要塞),但是战利品部分中仍然将Java版和基岩版分开说,是否应该合并以去除重复?(但这玩意好像涉及到模板,因此我需要帮助。)Sigma166/ 2021年2月23日 (二) 07:48 (UTC)

 同意我个人认为,同样的模版确实影响观感,如果要修改模版的话,建议可以翻阅编辑手册--Cobalt sayori=钴子 2021年2月23日 (二) 07:55 (UTC)
 反对,技术问题,加判断、修bug带来的人力消耗换来的只是合并表格,非常不划算。--Snow dash & ) 2021年2月23日 (二) 08:46 (UTC)
额人力消耗嘛……我倒是可以找时间搞(可是我不会啊啊啊——)那就等我会了再说吧Sigma166/ 2021年2月23日 (二) 14:13 (UTC)
 拒绝——根据现有{{LootChestItem}}模块代码,不能实现Java版和基岩版分开。重构是一件非常麻烦的事情。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:20 (UTC)

各个版本“修复”部分中的链接

在本wiki的各个版本介绍页面中,有小部分页面在“修复”部分添加了链接(比如18w43a12w06a),而大部分页面并没有。本人现有如下想法,并征求大家的意见:

  1. 所有版本介绍页面中的“修复”部分添上链接(艰巨的任务)
  2. 所有版本介绍页面中的“修复”部分删去链接(为保持一致并减少工作量)
  3. 不做改动,保持原状(省事是省事,就是看着别扭)

个人 支持1,在“修复”部分添加链接有利于读者更便利地了解该版本修复的内容。

带着兴趣直接跳转到一个子段落的读者必须依然能找到一个链接。

Sigma166/ 2021年2月26日 (五) 00:52 (UTC)

你说的链接是指访问官方漏洞追踪器的链接吗?但是我点进去18w43a的链接只会显示“No issues were found to match your search”,毫无用处。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:17 (UTC)
不不不,就是最普通的内链([[xxxx]]的形式)。Sigma166/ 2021年2月26日 (五) 01:21 (UTC)
这个任务可能相当的艰巨,因为需要补充的链接太多,而补充链接的过程也相当麻烦,个人 支持2--Cobalt sayori=钴子 2021年2月26日 (五) 01:25 (UTC)
快照少的也有两三个漏洞,多的可能有二三十个--Cobalt sayori=钴子 2021年2月26日 (五) 01:26 (UTC)
可加可不加,要好好利用页面顶部的搜索栏。但是要记住插入过多内链是不允许的(斑驳的颜色导致阅读问题)。--Lxazl5770zh.admin) 2021年2月26日 (五) 01:28 (UTC)

因为最近我一直在做漏洞列表相关工作,所以我来说明一下具体情况:

  • 一般来讲,最近依据漏洞补全计划补全的(我编辑的)并且使用了fixes模板的漏洞列表,列表全文一般没有链接,有链接的属于少数情况。
  • 较老的列表(1.4以前)的,一般都有。当然这是从英文wiki带过来的情况,所以我在翻译的时候也保留了这些链接。
  • 还有一些以前其他贡献者翻译的内容,其实存在大量这样有链接和无链接混合的情况,还有模板使用不正确的问题(就比如Lxazl577018w43a遇到的情况一样,是fixes模板使用不当导致的)。

至于你提出的选项,我个人 支持2或者是3。因为如果要全部加上的话,少说几百个版本页面中的内容都要修改。
且大多数版本中修复的漏洞大约有30-40个,甚至多的会有70+,另外还要算上主要更新版本(例如:Java版1.8),这些版本的漏洞修复列表往往非常巨大,这是由于这样的页面需要合并所有开发版本中的内容导致的。
所以在做添加链接的工作前,建议先考虑好这样是否合算。 Anterdc99Face Anterdc99· 2021年2月26日 (五) 02:04 (UTC)(最后编辑于:2021年2月26日 (五) 02:05 (UTC))

经过本人思考,认为1的确过于艰巨,2更现实一些。但若采用2的话是否应在格式指导中说明?(另外我因为开学难以继续编辑,这事还需大家帮助,谢谢!)Sigma166/ 2021年2月28日 (日) 10:22 (UTC)

关于引用进度的标准

昨天有人在说这个事。因为进度本身的判定有着比较具体的目标,所以昨天写了个引用标准的草稿:https://pastebin.com/k3Bpah0m

所以就是:

  • 是否有必要对进度引用提供一个标准;
  • 这个草稿内有无可能需要改进的地方。

以上。——IcyPhantom 讨论I贡献 2021年3月18日 (四) 14:18 (UTC)

个人认为按照共识去进行整理即可,并不需要刻意去编写标准(因为这个只是页面内容的一小部分罢了)。--Lxazl5770zh.admin) 2021年3月25日 (四) 08:52 (UTC)

新增关于字词转换的帮助页

写了一个关于字词转换的帮助页,见此(修订版本链接)

设立这个页面的主要目的是为了让想帮忙参与转换表/字词转换建设,或者只是一般读者的繁体用户能够更明确地明白本wiki的字词转换方针。另外,也可以以这个页面为基础,完善现有页面(尤其是标准化相关的)对繁体的说明。目前标准化页面没有明确提及“本wiki页面源代码内的名称以简体中文的实际核定情况为准”的相关明确语句,可能还是会导致繁体人士编辑时的迷惑。此外,目前wiki上没有从简繁体的核定速度等情况出发作“为什么wiki优先套用简体翻译”这类问题的简单说明,虽然我知道wiki尽可能保持语言中立,可能出于这个原因没有明说,但是个人认为明说更有利于和繁体读者沟通,提升更多人的阅读体验。

此外,这个帮助页的关注度可能需要手动提升,不仅需要放在繁体中文问题报告和相关Navbox里面,可以的话我希望在Sitenotice里面在“请以游戏内为准”那一行也加上到这个帮助页的链接。

这个页面的内容我已经提前提交给一部分本地人看了看,收集了一部分修改意见,现放在社区专页以获得进一步的共识与建议。-- LakeJasonFace Lakejason0) 2021年3月20日 (六) 17:09 (UTC)(最后编辑于2021年3月25日 (四) 08:28 (UTC))

 支持可以放到sitenotice。--Lxazl5770zh.admin) 2021年3月25日 (四) 08:57 (UTC)

页面已建立,见Help:字词转换。 LakeJasonFace Lakejason0) 2021年3月25日 (四) 15:24 (UTC)

推进。希望管理员能写一下Sitenotice。-- LakeJasonFace Lakejason0) 2021年4月23日 (五) 18:41 (UTC)

愚人节

不如4月1日的时候开启一次非官方文章,并于4月2日无封禁提删--119.237.10.81 2021年3月31日 (三) 06:41 (UTC)

 拒绝可能你不知道Java版2.0这个玩笑在n年前就开过了。--Lxazl5770zh.admin) 2021年3月31日 (三) 10:49 (UTC)
好吧--119.237.10.81 2021年3月31日 (三) 11:34 (UTC)

制作了总讨论页的顶端目录

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

如觉得不错可考虑应用于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 Lakejason0) 2021年4月5日 (一) 07:41 (UTC)
 问题:友好生物/敌对生物如何判定?这只能主观判定吧。-- Dianliang233 TC 16 2021年4月5日 (一) 08:33 (UTC)
per myself,根据sounds.json内的声音事件类别。-- LakeJasonFace 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个:red、​orange、​yellow、​green、​blue、​purplemagenta),以不同的颜色表示不同类型的信息(如红色表示需要立即执行的操作,橙色表示页面有内容方面的问题,等等),同时仍然支持自定义颜色。

此处可以预览新样式。

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

 支持。不过和英文的差别还是很大,和正经Ambox的差距倒是很小。-- LakeJasonFace 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 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 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)

如果需要的话,您可以自行添加重定向。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

当前的示例页面:

  • 源代码存放:模块:Sandbox/Star00/LootChest
  • 指定结构输出:project:沙盒/LootChest
  • 全部结构输出:Test wiki上的沙盒页

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

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

没有什么更好的建议了(在群里都交流过了,但是似乎不太明朗),就 支持一下重构吧。EN那边感觉也找不到人解释。-- LakeJasonFace 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)

 支持。我认为新的管理制度很好,提高了对管理人员申请的要求,也能有效防止“专制”的负面影响,等等。只有实行了更完善的管理制度才能让我们的Wiki变得更好。--Endearing Cat讨论) 2021年5月5日 (三) 04:15 (UTC)(最后编辑于2021年5月5日 (三) 04:19 (UTC))
一个我比较担心的一点是管理员并没有CheckUser的权限——每一次都要申请职员去排除分身账号是不现实的,加上Fandom注册分身账号极其容易,因此这种理论上较好的制度可能会因为这种原因而反应不出社区共识。-- LakeJasonFace Lakejason0) 2021年5月5日 (三) 04:23 (UTC)
同上,本人不认为只要是“自动确认用户”就享有表决权,享有表决权应该设立以下限制:
  1. 必须是一名自动确认用户
  2. 注册时间须大于3个月,且总编辑数不少于50次
  3. 无重大封禁记录(违反Wiki条例且拒绝改正者须永久剥夺表决权)
满足以上所有条件的用户才能享有表决权。
以及,满足以下任一条件的表决应被视为无效投票:
  1. 投票本身已经违反“一人一票”原则(例如重复投票和使用傀儡账号投票)
  2. 没有说明支持或反对原因
  3. 说明原因时离题或者使用不雅语言
  4. 投票后干扰别人的选择,例如怂恿其改变想法等
为了保证本Wiki的表决不受外界干扰,设立以上门槛是非常有必要的。--Lxazl5770zh.admin) 2021年5月5日 (三) 05:18 (UTC)
@Lakejason0Lxazl5770:意见刚刚已由本人加入到草稿。不过作为一个“投票”而不是“讨论”,理由等还是免了吧。-- Dianliang233 TC 16 2021年5月5日 (三) 06:13 (UTC)
 支持修改管理制度。
但是本人也认为修改中的管理制度有上述的缺点,对表决权的拥有者的要求确实应该更高,以保证投票结果真实可信。能合理地选举出巡查员、管理员和行政员的用户应该在Wiki上活跃一段时间,对Wiki的内容和其他活跃社区成员有一定的了解,而且个人的品行也:不能让其他社区成员感到反感。
由此提出下列关于对享有表决权的用户的要求的建议:
  1. 是一名自动确认用户
  2. 注册时间超过三个月、总编辑数不少于70次
  3. 曾经在Wiki上活跃过至少一周时间
  4. 一个月内在Wiki上活跃过至少两天
  5. 30天内无被封禁记录,一年内无被重大封禁记录(防编辑冲突等特殊原因除外)
此外,修改中的管理制度疑似没有明确能够正式成为巡查员的条件(如管理员的“在14日内,若至少70%的参与者支持,且没有更多的真实争议,则管理员申请通过”),在此提出疑问。--AblazeVase69188· 2021年5月5日 (三) 06:31 (UTC)
粗略地阅读了一下新的管理制度,如果我没猜错的话,实际上是把行政员的权力架空了。--Lxazl5770zh.admin) 2021年5月5日 (三) 15:46 (UTC)
  • 先从机制说起吧。明明在行政员的职责上写着“赋予或撤销用户权限”,可是在流程上的任何地方都没显示和行政员有任何联系。按照你的流程,完全可以用一件插件来替代,而且更高效便捷,提交者和投票者的资质审查完全可以交给机器处理且不会出错。你的提案将行政员从“人”用规则束缚成了“机器”,这是对行政员的正当权利的直接损害,不可接受。
  • 谈完机制谈缘由。在帮助wiki对分配权限流程是这么描述的:“如果你拥有许多管理员,你可能开始需要记录过程管理他们的行为,例如,什么时候应该保护一个页面,还是不保护它好? 你甚至可能会达到一种情况——你需要一个文件化程序来决定谁将成为一个管理员,以及应该撤销谁的管理员权利,为了应付这种情况,你不妨提拔几个用户进入“行政员”用户组(少数你最信任的用户)来管理分散提拔/撤销管理员的工作量。在一些大型wiki上,用户在被授予额外权限之前应由其他用户投票决定,而管理组则通过指控委员会调查不当行为来撤销其权利,除了最大的维基社区外,这些流程不太可能是必需的。”这其中明确指出行政员(按程序)有权限进行提拔和撤销,而投票流程也可能不是必需的。这其中也没有规定该程序需要“经过社区共识审批”,“严重违反了wiki基本法”的说法完全就是对它自身的歪曲解读。
  • 在整篇提案中,你咄咄逼人地说“(现有制度)成了管理员滥权的工具”,“(wiki需要)走出长期存在的“专制泥沼”(来继续发展)”,但完全没有提供任何支撑,完全是纸上谈兵。希望你能提供实例(不是“可能性”,而是已经发生的事实和数据)来证明现有制度被滥用,为什么它与所谓的社区共识相左,它如何限制了发展(及发展的定义是什么),和为什么你的改革能确实地进行所谓的发展。

-- Powup333讨论) 2021年5月5日 (三) 19:41 (UTC)

Advertisement