Minecraft Wiki

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

了解更多

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

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

重新规划生物分类

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

草稿已经提交至沙盒,包含对生物条目和{{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)
 支持。和英文的一位编者讨论了这个问题,实际上目前沙盒内的方案(也就是先归入友好/敌对大类再归入行为小类的方法其实很好地消除了歧义(但是在文章内需要把两个分类都写上去不然歧义就变大了)。目前的一个问题是如何让读者适应这个变化。-- LakeJasonFace.png Lakejason0) 2021年7月31日 (六) 00:47 (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)
现有分类的问题就在于他的最外层本身具有ambiguity,因为单纯的“非完全敌对”不能完全概括生物行为。-- LakeJasonFace.png Lakejason0) 2021年7月31日 (六) 00:56 (UTC)(最后编辑于2021年7月31日 (六) 00:57 (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)

模块重构第二阶段

大家好,本模块的重构在今日已宣告基本完成,已经基本可用。新的模块具有以下优点:

  • 完全由结构化数据生成,避免失误或版本交替造成的错误,这在原模块已经发现几个了。
  • 极大优化了代码,让维护和添加功能变得轻松。
  • 使用了JSON表对数据的命名空间ID进行转换,有利于管理和更新最新的译名标准。
  • 极大的减少了本地化的难度,任何本地化需要修改的内容都在子页面进行。
  • 优化了运行效率,避免出现一个页面5个LoadPage的情况。
  • 优化了all模式的显示效果,增加了实用性。

但新模块刚出炉,不可避免的出现若干小问题,然而我因学业原因无法继续下一步的修补,因此需要:

  • 另一位擅长Lua的编者接手维护工作。
  • all模式的注释还未完全继承原模块,需要按文档进行补充。

以下是模块使用的全部页面:

我虽想完成后续的工作,但心有余而力不足,因此需要各位的帮助,感激不尽。
Star Zero · 维基假期中 2021年8月31日 (二) 14:45 (UTC)

辛苦辛苦,感谢重构--Lxazl5770zh.admin) 2021年8月31日 (二) 15:06 (UTC)

加入标签储存模块

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)

广告

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

这些广告不是我们Wiki能控制的,因为我们(包括管理员等在内)没有网站的实际控制权。您可以通过登录账号以及使用浏览器插件来减少广告的显示。--Endearing Cat讨论) 2021年7月13日 (二) 09:41 (UTC)
你也可以使用广告拦截插件(如Adblock Plus,AdGuard等)来去除广告。正如Endearing Cat所说,广告的投放是由Fandom进行的,Wiki的任何管理员、行政员(包括Wiki创建者在内)都无法控制广告。——JerryHan3讨论) 2021年9月27日 (一) 10:13 (UTC)

更新携带版/基岩版版本记录中引用的链接

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

 建议使用方案3。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:05 (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)
从维护程度上考虑,我们无力维护这些文档,如果内容质量也没法掌控,不如移交给更有能力的人去做。但是Minecraft Wiki的引流导向作用还是要仔细考虑发挥好,不能让基岩版开发者找不到(如果真的)移除后的去处。-- LakeJasonFace.png Lakejason0) 2021年7月29日 (四) 07:18 (UTC)

提议修改命令语法格式

根据我和Miemie method的讨论,以及游戏内的情况,提议修改命令语法格式,按照游戏内文本表示:

  1. 不再翻译原来的[]<>()内的内容,同时取消斜体;
  2. 按游戏内方式使用[]<>()。由于Java版和基岩版格式不同,因此需要分别表示。

以上两条同时写入格式指导内。

有其他想法欢迎提出。MysticNebula70 T  2021年7月29日 (四) 03:15 (UTC)(最后编辑于2021年7月29日 (四) 03:18 (UTC))

实际上,在讨论这个问题的时候,技术性内容方面,坐标的表示方法也有待统一。目前游戏内的表示方法(命令返回文本)里为x, y, z,但作为页面来说这么写分割感/可辨识度不强,我们初步提出了使用(x, y, z)的表示方法。此外,单独表示某一轴的坐标也有待统一,比如Y=255。由于Minecraft坐标系与数学上右手系的标注不太一致,在讨论时有人建议将XYZ强制大写。希望在此议题中能够一并解决这个问题。
有关此次命令参数语法表示的修改,我认为若游戏内的表示方法具有统一性(基岩版是调用游戏内部类的所以应该是统一的)且满足wiki的表意需要,直接采纳即可。问题在于,虽然根据游戏内部机制,不翻译是对的(没人会翻译类名),但“不翻译括号内内容”可能会造成读者看不懂参数,反而造成读者体验的下降。如果能用一种方式达到表意和游戏内实际的结合,那我认为会更好。-- LakeJasonFace.png Lakejason0) 2021年7月29日 (四) 07:28 (UTC)(最后编辑于2021年7月29日 (四) 07:28 (UTC))
为什么会看不懂参数把参数内容在下面解释清楚就行了,应该够了吧(MysticNebula70 T  2021年7月29日 (四) 11:30 (UTC)
若无更多意见,将按照目前的提议修改命令语法格式。MysticNebula70 T  2021年8月2日 (一) 03:16 (UTC)
 同意。-- LakeJasonFace.png Lakejason0) 2021年8月2日 (一) 07:27 (UTC)

把“概念性”的armor一词的翻译改为“护甲”

众所周知,armor在Minecraft英文语境下有两种主要用法,一是表示人实际着装的一种衣物,常用语xxxx armor(XX盔甲)的词组,二是做概念性用法,表示一种虚拟的技术性词汇,比如armor value(护甲值)、armor toughness(护甲韧性)。正如我例子中所述,我提议,前者的armor一律翻译成盔甲不变,后者的armor改译成护甲。除了用于作语义区别之外,还有理由如下:1. 以护甲值为例,护甲值非常正常,而盔甲值要么使人不明所以,要么使人听懂但是说起来拗口;2. 社区在这种语境下用护甲的明显要比盔甲多,这说明盔甲一词不足以完全胜任armor的翻译,需要与护甲配合才能表达armor的全部意思。方法放寒假 (Talk - Contributions) 2021年8月2日 (一) 07:15 (UTC)

 FYI相关游戏内字符串的键名:attribute.name.generic.armorattribute.name.generic.armor_toughness。-- LakeJasonFace.png Lakejason0) 2021年8月2日 (一) 07:30 (UTC)

弃用原有Infobox,改用PortableInfobox

原有的Infobox是基于Lua和<table>构建的。在UCP迁移后,我们又可以使用Fandom提供的PortableInfobox方案。

两种方案的优缺点:

原有方案

 优点

  • 可自定义程度强
  • 与en相同,方便搬运

 缺点

  • 编写复杂
  • 样式不现代,且有很大的历史包袱(参考FandomDesktop夜间模式)(en的样式已经变更)
  • 使用<table>
PI

 优点

  • 可根据社区样式自动适配,样式现代
  • SEO略好一些
  • 编写较简单,甚至有GUI工具

 缺点

  • 可自定义性较差
  • 与en方案不同,需要花精力转换
  • 会忽略页内转换规则(虽然在本wiki中页内转换使用不多,而且Infobox内貌似也没有此类用例)

现已有Lakejason0制作的实验性方案(使用了style,其实不需要)。

关于PI:

-- Dianliang233 TC 16 2021年8月3日 (二) 08:11 (UTC)

小声提醒一句,某个镜像并不支持PI,所以如果转向了PI,恐怕也还是要同时维护两个(虽然压力没听起来那么大)。-- LakeJasonFace.png Lakejason0) 2021年8月3日 (二) 09:18 (UTC)

新页面

其实我一直想帮中文Minecraft Wiki添加新页面,可是中文Minecraft Wiki就好像万事俱备,已经没有什么东西要加下去了。所以我有什么新页面可以加的吗?–该未签名留言由ChiaLeeChuen讨论贡献)在2021年8月5日06:35(UTC) 添加。请在您的回复后面加上 ~~~~

为社区做贡献不只有添加新页面这一种途径.--Snow dash & ) 2021年8月5日 (四) 07:58 (UTC)
找错别字、移除失效链接、同步历史段落信息、扩充已有教程……这些都可以去做,不必拘泥于创建新页面。--ultim_0 ( USER | TALK | CONT ) 2021年8月5日 (四) 15:12 (UTC)

请问Wiki点数的计算公式是什么

就是这个页面:Special:WikiPoints

Wiki上没找到相关规定,搜索也没有相关结果。--QWERTY-5238讨论) 2021年8月9日 (一) 05:47 (UTC)

It's a secret. 这里的用户都不知道。但可以告诉的是,相同条件下,首次编辑页面的分数会高一些。Plus,不要为了贡献点数去编辑。--Ff98sha讨论) 2021年8月9日 (一) 05:53 (UTC)
 意见:但行好事,莫问前程。--ultim_0 ( USER | TALK | CONT ) 2021年8月9日 (一) 05:58 (UTC)


关于教程页的几个问题

  1. 请问“原创教程”的定义是什么?如果有人转载了其他网站的一篇教程,然后其原作者也过来完善教程,那么这到底算“原创教程”还是不算?Wiki是可以供所有人编辑的,因此“原创”到底按照哪个人的视角来看?页面创建者吗?
  2. 如果一篇教程即是“原创教程”又是“建筑教程”(或者其他类型),是否需要将这个教程放两个链接到{{tutorials}}模板上?我看到很多”原创教程“都没有这样做,如教程/跑酷,然而教程/NBT与JSON又即是原创教程又是技术性教程,那么到底应不应该在{{tutorials}}上创建两个链接?

求解。--QWERTY-5238讨论) 2021年8月12日 (四) 12:23 (UTC)(最后编辑于2021年8月12日 (四) 12:44 (UTC))

原创教程指的是“不从英文Minecraft Wiki翻译而来的教程”,如果是转载其他中文网站的教程,其大部分情况下不符合协议,那个页面有可能会被删除。这是一个遗留问题,与早年中文Minecraft Wiki的编辑方针有关。至于模板中如何摆放的问题,之前在群里有争论,但是没有结论,个人感觉可以放两次,但是我自己的教程只放了一次(放在数据包里面)。-- LakeJasonFace.png Lakejason0) 2021年8月12日 (四) 12:30 (UTC)
 意见
  1. 从其他网站转载教程到中文Minecraft Wiki尚无成功案例。
  2. 中文Minecraft Wiki的原创教程是与从英文Minecraft Wiki翻译的教程相对而言的。
  3.  支持将原创教程在{{tutorials}}标记为用户原创教程的同时放在相应的类别。
    1.  具体描述:移除该模板中的“原创教程”分类,转而使用特殊的标记点出原创教程,并在模板开头说明。
    2. 现试举一例以供大家探讨,见个人沙盒
以上。--ultim_0 ( USER | TALK | CONT ) 2021年8月12日 (四) 12:34 (UTC)(最后编辑于2021年8月13日 (五) 08:01 (UTC))
 !这个对于“原创教程”的定义着实有点奇怪。我这里的转载指的是符合规定的转载(例如已经获得作者许可,或作者明确可以转载),那么这种转载能算“原创教程吗?按你这个定义倒是算,但是分明是转载变成原创也不太合适吧。
对于经历了“中文Minecraft Wiki是英文的子语言项目”到“中文Minecraft Wiki已经不只是子语言项目”的过渡的编辑者来说,只能说很正常,如果要更改的话我觉得也不是不行,但是原来是“翻译”的文章我认为还是要有一定的标注。-- LakeJasonFace.png Lakejason0) 2021年8月12日 (四) 14:37 (UTC)
 意见关于那个放两次还是放一次的问题,感觉Wiki现在很乱(两种均可?)该整改一下了。我个人的建议是放两次。--QWERTY-5238讨论) 2021年8月12日 (四) 12:46 (UTC)
 意见
  1. 我个人认为,原创教程是指中文用户自己编写的教程。既然是原创,那么这个过程中应该几乎不依靠从英文Wiki的教程翻译、或是从其他地方转载等方式进行编写。
  2. 目前来看,我 支持将原创教程在{{tutorials}}模板上标记为用户原创教程的同时放在相应的类别中。但是我个人倾向于把原创教程这个类别从{{tutorials}}模板中删除。--AblazeVase69188· 2021年8月13日 (五) 05:41 (UTC)
 支持User:Ultim 0将原创教程进行特殊标记的方法,但认为可能需要使用另外的标记,如下划线。--AblazeVase69188· 2021年8月13日 (五) 09:06 (UTC)
 意见怎么没人回应了?
将原创教程进行标记是一个不错的决定。建议移除原创教程分类,并用红点和下划线突出原创教程。
如果没有人反对的话,明天就可以正式实施了。--QWERTY-5238讨论) 2021年8月24日 (二) 09:51 (UTC)

“历史”页面命名问题

在英文Wiki中,某些篇幅较长的历史条目统一被命名为“XX(的)历史”(History of XX,如History of textures);而当前中文Wiki沙盒中的命名则是“XX§历史”,把分节符放到页面名称中显然极不合理。所以恳请各位讨论决定一下页面命名规范:究竟是直接按照英文wiki的方式命名页面,还是将“历史”放到子页面,或是有更好的方案可供另行采取?

(另外,“纹理历史”相关页面需要大量上传/移动图片,最好使用机器人完成这些任务)

--Thgabs讨论) 2021年8月20日 (五) 03:54 (UTC)

我认为放在子页面更合适一些。--Endearing Cat讨论) 2021年8月20日 (五) 04:14 (UTC)
子页面可能有SEO问题(来源请求),不过无论是子页面还是直接叫“XX历史”我都能接受。-- LakeJasonFace.png Lakejason0) 2021年8月20日 (五) 04:47 (UTC)
 意见放在哪里其实并不重要。统一使用“页面名称/History”的格式,如“Java版已移除特性/History”。--ultim_0 ( USER | TALK | CONT ) 2021年8月20日 (五) 08:05 (UTC)(最后编辑于2021年8月20日 (五) 08:48 (UTC))
审题,“篇幅较长的历史条目”已经表明可以支撑页面。-- LakeJasonFace.png Lakejason0) 2021年8月20日 (五) 08:31 (UTC)
 中立 反对,总感觉“XX的历史”有点别扭……--ChemistChangTalk/Contributions) 2021年8月20日 (五) 09:05 (UTC)
这似乎是维基百科的编辑习惯,因为维基百科的条目名字空间并不支持建立子页面。--ultim_0 ( USER | TALK | CONT ) 2021年8月20日 (五) 09:11 (UTC)
还有,如果要改的话,那就别管篇幅长短,最好都统一。--ChemistChangTalk/Contributions) 2021年8月20日 (五) 09:16 (UTC)

重改Food模板

如题。

根据游戏内代码重写了一个{{food}}模板,可在沙盒内找到。

但目前有个问题是:甜浆果发光浆果可作为食物也可作为方块放置。这两个东西需要一个方法处理。

以上。

--SorairoMafura讨论) 2021年8月20日 (五) 07:05 (UTC)

首先,不需要刻意去区分肉类;其次,我不知道“总是可食用”什么意思(可能是金苹果这类的)。然后就是状态效果,由于版本差异这会导致infobox看起来很臃肿,不建议加上。甜浆果直接在后面补充一个{{food}}模板即可。--Lxazl5770zh.admin) 2021年8月20日 (五) 08:56 (UTC)
某些补充:肉类(meat)、总是可食用(alwaysEat)、状态效果(effect)都是在代码里注册食物时便已经定义的属性。--SorairoMafura讨论) 2021年8月20日 (五) 09:14 (UTC)

关于宝藏型魔咒的疑惑:既然它们无法从附魔台上获取,为何拥有魔咒权重?

是否应该移除相关内容?–该未签名留言由Minecraftwater讨论贡献)在2021年8月21日 (六) 11:41 (UTC) 添加。请在您的回复后面加上 ~~~~

 不建议:事实上,权重是由游戏源代码决定的,尽管它们从不在附魔台出现,但是仍然有权重存在。Cnmilkcnmilk讨论) 2021年8月21日 (六) 12:07 (UTC)

关于模板version nav中的internal参数

先前有关讨论请见en:MCT:Community portal/Archive 32#Pocket/Bedrock Edition version pages

{{version nav}}的文档没有提到参数{{{internal}}}的用法。目前其中所填写的内容不应称为“内部版本号”(Internal version no.),而应为“完整版本号”(Full version no.)。

内部版本号”实际上指的是一长串数字;在Android上其储存于文件AndroidManifest.xml中,在其他平台上亦然,储存在某个文件里。同时,完整版本号也可以在其中找到。举个例子,携带版1.1.3的内部版本号为871010352,完整版本号则为1.1.3.52

由现在所找到的携带版/基岩版APK文件来看,同一版本会对应多个安装包,虽然完整版本号相同,但内部版本号不同。在携带版0.6.1之前,每个版本应有且仅有一个内部版本号;这些版本的版本页面有必要按照内部版本号进行拆分(目前按照完整版本号写在同一页面内,有一个段落单独列出内部版本号)。目前,Google Play上的同一版本会有4个不同的内部版本号,分别对应ARM和x86架构的32、64位设备。当然,不只是Android上存在内部版本号,其他平台的版本号仍然需要考证。同时,PlayStation 4上的“完整版本号”较为特殊,和其他平台不一致。鉴于版本号错综复杂的情况,需要各位进行讨论。

综上,有必要进一步完善{{version nav}}。关于参数{{{internal}}}的显示,实现方式可能类似于{{{protocol_manual}}},新建一个模块以存储数据。剩余事项欢迎各位踊跃提议。--SkyE | Talk · Contributions · Logs 2021年8月22日 (日) 13:09 (UTC)

冰与18w15a信息不正确

在18w15a后怪物可以在冰面上生成,这一点在历史一栏中有写到,可是在生物部分中却说“北极熊以外的生物无法生成在冰上。” 我同样去查阅了英文版wiki,发现生物这部分已经被移除

而在18w15a中,中文wiki没有提到冰面上现在可以生成怪物,而英文版里确实有这么一段话 Mobs>Spawning "Mobs can now spawn on top of ice."

两个错误我试着修改,但被维护人员退回了,希望管理员修改这些误导性很严重的错误

喂龙讨论) 2021年8月27日 (五) 15:46 (UTC)Fed_Dragon 2021/8/27

 已完成。顺带一提,回退你的编辑的理由是你没有在编辑摘要中给出证据,以及使用了可视化编辑导致页面代码结构被破坏。--Lxazl5770zh.admin) 2021年8月28日 (六) 03:49 (UTC)

为什么顶部导航栏的文字变成了繁体?

如题。顶部导航栏原来是简体文字,但是现在变成了繁体,同时MediaWiki:Wiki-navigation页面内却仍是简体!这是怎么回事?——JerryHan3讨论) 2021年9月27日 (一) 10:26 (UTC)

简单来说是Gamepedia wiki特有的系统消息缓存问题。目前Fandom仍在修复,可以尝试刷新几次,可能会恢复正常。-- LakeJasonFace.png Lakejason0) 2021年9月27日 (一) 16:27 (UTC)(最后编辑于2021年9月27日 (一) 16:28 (UTC))
现在已经恢复了,谢谢!——JerryHan3讨论) 2021年9月28日 (二) 09:02 (UTC)
Advertisement