Minecraft Wiki:社区专页/存档9

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

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

存档

继续“关于教程页的几个问题”议题

原议题见此处。

如题所示，本人提议将教程及{{Tutorials}}中的“原创教程”分类移除，并对已处于其他分类的中文原创教程进行下划线的标记。

若无人反对，我将在下个周末进行上述工作。--AblazeVase69188（讨论 | 贡献） 2021年12月18日 (六) 15:21 (UTC)

疑问所以为什么这么做？我觉得单开一个原创教程分类挺好的--Lxazl5770_zh.admin（论 ▪ 功） 2021年12月20日 (一) 01:01 (UTC)

原创教程分类中的教程均可以归入其他分类，而且目前已经出现了大部分原创教程重复出现在原创教程分类与其他分类中的情况
我认为在其他分类中对原创教程进行标记和单独开出原创教程一个分类的效果是差不多的

因此我提议进行上述工作。我认为您也可以进一步说明其他理由。--AblazeVase69188（讨论 | 贡献） 2021年12月24日 (五) 10:04 (UTC)

提议：在此基础上给所有原创教程在页面内添加原创教程分类，模板内不再列出。这样也可以平衡“移除后怎么一下子列出所有原创教程”等疑问。--

Lakejason0（论•功） 2021年12月24日 (五) 11:12 (UTC)

完成：已给处于“原创教程”标题下的所有教程添加[[Category:用户原创教程]]分类标签。--AblazeVase69188（讨论 | 贡献） 2021年12月24日 (五) 11:42 (UTC)

反对，不能因为enwiki没有就把zhwiki编写的叫做原创教程，来源不应该作为区分教程的标志；显而易见en没有把其他语言没有的教程分类为原创教程。--Snow dash（论 & 功） 2021年12月24日 (五) 15:21 (UTC)

无妨，改个名字就是，比如“中文独有教程”。--

Lakejason0（论•功） 2021年12月24日 (五) 15:25 (UTC)

确实，可以将[[Category:用户原创教程]]改为[[Category:中文独有教程]]，该操作可申请机器人完成。不过我想设立这个分类的原意是提升中文用户编写中文独有教程的积极性，以及向他们提供一定程度上的示范。因此仍然建议保留该分类，页面和模板内不再直接列出，而是以下划线标记。--AblazeVase69188（讨论 | 贡献） 2021年12月25日 (六) 02:01 (UTC)

下列工作 已完成：

将所有的[[Category:用户原创教程]]改为[[Category:中文独有教程]]
将教程及{{Tutorials}}中的“原创教程”分类移除，并在其他合适的分类中添加作了下划线标记的链接

若有谬误可以帮助修正。--AblazeVase69188（讨论 | 贡献） 2022年1月1日 (六) 14:59 (UTC)

将首页的“Minecraft简介”部分更改为和英文的“Minecraft video games”相对应的形式

据部分用户（Light beacon）的反馈，以及结合我自身的观感判断，目前首页的Minecraft简介一栏的观感相较于英文的“Minecraft video games”一格来说差了一些，英文此栏的格式更让人舒服。我在此提议将Minecraft简介一栏更改为和英文的“Minecraft video games”相对应的形式，其他部分暂不做更多变化。-- Lakejason0（论•功） 2022年1月1日 (六) 16:37 (UTC)

如果的确这么做，那么故事模式和mce还需要放进去吗？--

KaplanSteve（T•C） 2022年1月2日 (日) 00:10 (UTC)

看大家想法，我觉得可以放。--

Lakejason0（论•功） 2022年1月3日 (一) 15:16 (UTC)

所以是不打算改了吗？我感觉en那种观感确实好一些。等了近一个月没人提过这件事了。--KaplanSteve _T 2022年1月27日 (四) 06:46 (UTC)

其实我觉得改不改都无所谓吧，不过现在又有人提了，还是改了为好。--McplayerFS（讨论） 2022年1月27日 (四) 07:03 (UTC)

更改iOS图标

en上的iOS图标已经不再每个iOS版本一个图标，而是使用了“iOS”和“iPadOS”字样。而且每个iOS版本一个图标很有可能会造成图标过旧的问题，比如现在iOS 15已经发布了，而我们还在使用iOS 14的图标。

因此我建议将iOS图标更换为iOS字样。至于iPadOS我不知道该怎么处理，en上是分开来的，我感觉这样做也挺好，虽然也不是很有必要分开。-- KaplanSteve（T•C） 2022年1月2日 (日) 01:08 (UTC)

支持更改，少了很多更新的麻烦。分开也有道理反正，真要分开我也没意见。--

Lakejason0（论•功） 2022年1月3日 (一) 15:16 (UTC)

已完成更改。--Lxazl5770_zh.admin（论 ▪ 功） 2022年1月6日 (四) 04:06 (UTC)

移动页面

Java版中的距离现象与基岩版中的距离现象的页面命名不符合普遍用法习惯，现希望更正（移动）为距离现象/Java版与距离现象/基岩版，为此征求社区意见。--Snow dash（论 & 功） 2022年1月11日 (二) 06:44 (UTC)

支持，这种命名方式在维基百科尤为常见，因为他们不支持在条目名字空间设立子页面，但是Minecraft Wiki跟维基百科不一样，故支持移动页面。--ultim_0 ( USER | TALK | CONT ) 2022年1月11日 (二) 07:56 (UTC)

支持移动，更加有利于维护。--

KaplanSteve（T•C） 2022年1月11日 (二) 14:09 (UTC)

注意应该将页面移动为Java版距离现象和基岩版距离现象才对。--Lxazl5770_zh.admin（论 ▪ 功） 2022年1月11日 (二) 14:16 (UTC)

看到某些群里讨论的时候我就觉得不对劲，建议是不要把现有的页面标题规范当场笑话。函数和数据值就是例子，应当采取Lx的方案，将页面移动为Java版距离现象和基岩版距离现象。--

Lakejason0（论•功） 2022年1月11日 (二) 15:29 (UTC)

已完成移动。--Snow dash（论 & 功） 2022年1月15日 (六) 11:46 (UTC)

检修wiki的冷门页面

最近有在制作关效果状态的视频，之前也做过关于魔咒的视频。给我的感觉就是————为什么wiki上全是错误啊啊啊啊啊啊啊啊啊啊啊啊阿啊啊啊！！！这些老页面存在大量版本不分的问题以及未经测试的项目，因为过于冷门而无人问津，无人检修。过几天我会开始进行一些修补工作，但因为能力有限，工作效果想会很微薄。希望有能力的各位能帮助处理这些问题。哼，哼哼，啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊啊 –该未签名留言由Minecraftwater（讨论 • 贡献）在2022年1月15日 (六) 04:19 (UTC) 添加。请在您的回复后面加上 ~~~~

~~你这个话题一股味道啊~~ 首先呢，wiki一直以来都有人说“错漏百出”，但一没人说哪里错了，二没人来改。大家很欢迎对wiki内容的修正等改进，但并不是所有人都有时间（或者能力）。对于目前的状况来说，“不说哪里错了”=没有说。个人很期待相关改进，也许你可以稍微划个范围。
顺带一提，在编辑时，建议你写好编辑摘要。在移除/增加内容时，毕竟你也说了版本不分未经测试，那么就应当在编辑摘要中说明“是哪个版本”“在哪个版本测试”的，以便后来人查证和更新。期待你的编辑。--

Lakejason0（论•功） 2022年1月15日 (六) 04:26 (UTC)

第一，你签名没正确签上，最好使用~~~~重新签一下；第二，你可以说详细一点吗？比如哪里有错漏，又是哪里版本不分？KaplanSteve _T 2022年1月15日 (六) 04:50 (UTC)

意见：~~自己动手丰衣足食，勿问“为什么没有oo”。~~如果阁下真的有意为Minecraft Wiki添砖加瓦的话，请大胆地开拓吧！同时建议你先看看编辑帮助，可以省去许多不必要的麻烦。--ultim_0 ( USER | TALK | CONT ) 2022年1月15日 (六) 05:27 (UTC)（最后编辑于2022年1月15日 (六) 11:52 (UTC)）

不必过于苛刻，新编者很难得知实际的编辑情况。根据他的发言来看，他也没有太要求我们做什么，我们保持观望+适时的帮助即可。另，如果需要帮助的话，可以加入MCW:QQ。--

Lakejason0（论•功） 2022年1月15日 (六) 10:24 (UTC)

是否需要去除版本更改中的特殊信息

章节题目可能有些不明确，在下解释一下，以基岩版1.15.0.51为例，其中有一句：

被动型生物

现在只会生成于其应该生成的方块上。（MCPE-47596）

在下不明白，这些应当是修复章节的内容，为何在前面提及，是否考虑删除这类通过修复漏洞做出的更改？仅仅让它们存在于修复章节内。

Cu·铜（吐槽专栏·考古专栏） 2022年1月15日 (六) 12:43 (UTC)

意见：基岩版版本页面有其自己特殊的规范，部分内容直接翻译自feedback.minecraft.net上的对应更新日志。对于上述内容，更新日志的描述如下：

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

Parity

Fence Gates can now be placed without supporting blocks underneath
Damaged Bows can again be used to craft Dispensers (MCPE-55861)
...
Passive mobs now spawn on blocks they are supposed to (MCPE-47596)
...
Boats placed on top of Cactus blocks will now take damage and break

其见于Parity一段，而非Fixes段落，故应当视作特性同步而不是常规的漏洞修复，不应将其移动到修复章节。--ultim_0 ( USER | TALK | CONT ) 2022年1月15日 (六) 13:13 (UTC)（最后编辑于2022年1月15日 (六) 13:16 (UTC)）

但是，MCW的编辑是灵活的，或许没有必要完全照着官方博文的格式，大致相同即可？——Cu·铜（吐槽专栏·考古专栏） 2022年1月15日 (六) 13:17 (UTC)

并且，这两个章节中都出现了一次，是否重复呢？——Cu·铜（吐槽专栏·考古专栏） 2022年1月15日 (六) 13:18 (UTC)

那就删掉一个呗，还有关于狼的那个在两个章节中都出现了，那就把上面那个结尾的（MCPE-47596）去掉。-- McplayerFS（讨论） 2022年1月18日 (二) 02:25 (UTC)

我想说的是，有些“修复漏洞”的确会给游戏带来实质上的更改，而通常更新日志反而不会把这些写进去。修复列表是个列表，但更改是总结出来的，之前的N个Java版快照都是把修漏洞造成的更改写进了更改里的。——IcyPhantom 讨论I贡献 2022年1月21日 (五) 08:56 (UTC)

采用模板化的版本页面

如题，MCW:沙盒/格式/版本，在下认为版本页面可以通过subst调用此模板进行编写，就模板而言，并没有多少限制。此模板与大多数版本页面格式吻合。——Cu·铜（吐槽专栏·考古专栏·MCR Wiki） 2022年1月19日 (三) 14:42 (UTC)

不现实，有一个一个找参数名挨个填的功夫页面早写完了。--葉月桐§ 2022年1月19日 (三) 15:18 (UTC)

不一定：为什么不能提供一个已经写好的模板，让编辑者直接自取？——Cu·铜（吐槽专栏·考古专栏·MCR Wiki） 2022年1月20日 (四) 06:51 (UTC)

我们创建版本页面的主要方法依然是从en复制源代码然后再翻译，页面格式的雏形一般从开始搬运页面就已经定好了，如果用你的模板，还得花额外的精力把源代码里的关键内容一点点挑到模板里，那样显然会降低效率，完全不如直接修改复制来的源代码方便快捷。而且好的模板只需要专一完成自己的任务，没必要把其他模板的工作全都揽过来，那样只会徒增麻烦。--葉月桐§ 2022年1月20日 (四) 07:11 (UTC)

意见：若实在麻烦，该模板应该可以当做一个大概的框架，以防有时格式相差甚远。不一定要完全套着模板来，也许是写完之后对照一下该模板，格式相差不大即可？重申一次，该模板被创建的初衷不是限制，而是参考。——Cu·铜（吐槽专栏·考古专栏·MCR Wiki） 2022年1月20日 (四) 07:16 (UTC)

那也不需要，我们有已经编写好的版本页面格式指导，格式以此为准即可，而且模板页面也从来没有当作参考对照的用法。--葉月桐§ 2022年1月20日 (四) 09:06 (UTC)

确定部分游戏内容的名称

命名空间ID——en那边已经确定为Resource Location（资源路径）并且已经移除未确认名称了。
生成结构——无论怎么想“生成结构（Generated Structure）”这名字都很奇怪。通常是直接称作“结构（Structure）”，以及数据包文件里它被叫做“已配置结构地物（Configured Structure Feature）”。无论叫什么都比叫成这个不明所以的“生成结构”合理。
黑曜石柱——这玩意叫“End Spike（终末之刺）”，对应地物文件的名称告诉我的。
还有些别的什么这里还没发现。

总之。——IcyPhantom 讨论I贡献 2022年1月21日 (五) 08:56 (UTC)

生成结构指的是相对于玩家建造的结构，可以改为“预置结构”Configured Structure。末地刺的名称可以直接放进页面里，原名已经比较常用。--RealCuervo（讨论） 2022年1月21日 (五) 09:05 (UTC)

注意，基岩版中没有资源路径这种称呼，且‘命名空间id’比‘资源路径’更易理解。第二个可以移动到“结构地物”，不会产生歧义。而“Configured”的确是“已配置的”、“配置过的”的意思，而且配置的对象是feature，而不是结构，不存在Configured Structure这种说法。--Chixvv（讨论） 2022年1月21日 (五) 09:29 (UTC)

其实命名空间ID这个词我之前提过有定中关系不明的问题（但是很常用啦所以没人在意），根据我再次查看EN给出的来源，以及基岩版社群的相关询问，我得出结论是“Mojang自己也不知道叫什么”。--

Lakejason0（论•功） 2022年1月21日 (五) 10:39 (UTC)

建议模块IdTools投入使用

近日在闲暇时写了模块Allconversion2，将会改名为IdTools。现在我建议将此模块投入使用。

模块用途：目前打算用在ID table模板（自动生成数字id、别名id、方块的物品形式、本地化键名），java版数据值和基岩版数据值页面（自动生成方块和物品列表）。

模块维护：我可能没有那么多的精力去持续维护，所以需要mcw管理团队的各位及时更新。需要维护的内容及方法见模块的文档页面。也不必更新太频繁，建议至少一个大版本更新一次。

英文wiki：如果在中文wiki应用效果不错，未来将会把此模块推到英文wiki。

其他：模块没有经过足够的测试，可能还有一些bug。另外对于英文名，基岩版的snow_layer、snow使用了java版的英文名，其他的都是尽量与游戏原文保持一致。

如有其他问题或建议请提出，十分感谢。--Chixvv（讨论） 2022年2月6日 (日) 12:47 (UTC)

关于移动页面的事宜

本人最近在编辑时看到教程/附魔机制页面被加上了“等待移动”的模版，并且下方的“教程”模版已被去除，另外有关机制的页面不应该属于教程，所以想征求一下大家的意见，是否移动此页面至“附魔机制”，反正我是同意的。

还有中国版的页面什么时候才能移动啊，我想移动，但是移动的权限仅限管理员。--McplayerFS（讨论） 2022年2月8日 (二) 03:00 (UTC)

不赞成：该页面的举例较多，不适宜移出教程子空间，参考原始JSON文本格式和教程/原始JSON文本。--ultim_0 ( USER | TALK | CONT ) 2022年2月8日 (二) 03:06 (UTC)

1. 不赞成：教程/附魔机制页面即使去除了教程模板，但整体行文仍属于教程，需要将格式修改后才能移动。

2. 而Minecraft：中国版的移动暂时未获得社区共识，建议在这里一并讨论。为了与其他页面统一名称，我支持对此页面进行移动。--

Anterdc99（论·功） 2022年2月8日 (二) 03:09 (UTC)（最后编辑于2022年2月23日 (三) 13:56 (UTC)）

我也同意中国版页面的移动。--McplayerFS（讨论） 2022年2月8日 (二) 03:15 (UTC)

1. 支持对中国版页面的移动。

2. 教程/附魔机制的标题应与铁砧机制的统一，然而页面上的举例过多，不适于移动出教程子页面。我认为，可以将附魔机制重定向到附魔，把教程/附魔机制移动到教程/附魔（不留重定向）。这样把附魔作为介绍机制的页面，把移动后的教程/附魔作为为附魔的实际应用举例的页面。--AblazeVase69188 (T/C) 2022年2月8日 (二) 03:57 (UTC)

关于Internal version模块的现况

先前讨论（根本没人讨论）请见MCW:社区专页/存档8#关于Internal version模块及版本拆分和MCW:社区专页/存档8#关于模板version nav中的internal参数。

经过长时间的努力以及其他方面的支持，现在模块:Sandbox/Internal version/Versions中的数据部分已经全部整理完毕，可以投入使用。

鉴于我根本不会用Lua写模块的功能部分，恳请哪位帮我写一个简单的模板实现。

模块中用注释写明了应该拆分的版本和目前存在的问题，也可参见先前的议题。

另，已经根据得出的数据修正了基岩版上的Android最低支持版本；而en那边还是错的，现在有了充分的论据，我先改为敬。--SkyE | Talk · Contributions · Logs 2022年2月11日 (五) 11:40 (UTC)

如果Infobox中需要展示修订版本的话需要如何呈现呢？2190303755(T|C) 2022年2月24日 (四) 08:49 (UTC)

规范用词

如题，我觉得本Wiki中需要规范一下用词。以下仅代表我的建议：“如果”一词完全可以改成“若”，后者更简短，在表格中表现更为明显；还有“概率”和“几率”两个词一直混用，查询某些页面时，总能发现这两个词混用。编辑者一会儿用“概率”，结果下文又用“几率”，我认为有必要统一一下。有其他需要规范的用词用语等大家也可以说一下帅哥之霸（讨论） 2022年2月15日 (二) 05:55 (UTC)

前者的改动我不发表意见；后者的改动我们已经讨论过了，改成概率。--KaplanSteve _T 2022年2月15日 (二) 14:13 (UTC)

对于第一条建议，我觉得对教程的文字没有必要如此认真地规范用词，只要使其通顺并能够准确地表达意思即可；然而对于其他主页面的规范用词，基于我对其他主页面编辑的高被撤回率，我不发表意见。--AblazeVase69188 (T/C) 2022年2月18日 (五) 10:53 (UTC)

在传达到意思的基础上，追求语言尽可能准确、简洁、每100字信息含量（信息熵）大、生动、有趣（重要性递减）。但是如果别人用了复杂的表达，或在非专有名词上不太规范，也不必直接算错。我觉得这样比较合理。——

1^stlezygDARK（闲聊/讨论/贡献） 2022年2月19日 (六) 07:11 (UTC)

若和如果只是语言偏好，应该按需使用，不宜强制规定。我们又不是文言wiki。-- Dianliang233 ^T•_C

2022年4月18日 (一) 02:13 (UTC)

中文MCWiki时间显示为UTF+8

~~如题，中文MCWiki的用户和编辑者大多数都在东八区，所以不知道能不能把MCW内的时间显示为UTF+8？每次看着都感觉很别扭。~~——1^stlezygDARK（闲聊/讨论/贡献） 2022年2月19日 (六) 07:17 (UTC)

请在参数设置-显示里自行调整时区。--Lxazl5770_zh.admin（论 ▪ 功） 2022年2月19日 (六) 07:23 (UTC)

！！我是*#%@。我的问题。——1^stlezygDARK（闲聊/讨论/贡献） 2022年2月19日 (六) 07:37 (UTC)

还有，是UTC不是UTF。--ultim_0 ( USER | TALK | CONT ) 2022年2月19日 (六) 09:01 (UTC)

兔子文章出现漏洞

该音效无法播放，已经在Windows 11与Android 设备确认。请修复一下链接：https://minecraft.fandom.com/zh/wiki/%E5%85%94%E5%AD%90 --Batele Jackson（讨论） 2022年3月31日 (四) 17:49 (UTC)

原因可能为音效时长过短，部分浏览器不支持播放，我们无法修复。另外，建议查阅编辑手册以了解如何使用源代码编辑，不要通过复制网址插入链接。--葉月桐§ 2022年3月31日 (四) 17:59 (UTC)

好的–该未签名留言由Batele Jackson（讨论 • 贡献）在2022年3月31日 (四) 18:09 (UTC) 添加。请在您的回复后面加上 ~~~~

命令页的页面规范

介绍具体命令的页面用了一堆高端模板，而且大部分都是技术性内容。所以有必要写一个页面说明如何去编写这种页面。

如果要问怎么写，至少要说明各个章节的作用、各个章节应遵循说明格式、如何使用各个章节的涉及模板、如何获取必要的数据（指权限等级、输出值这类的东西）。

如果要讨论必要性，至少这种页面的格式要明确一下。 ——IcyPhantom 讨论I贡献 2022年4月3日 (日) 10:11 (UTC)

我记得以前似乎讨论过这样的事情。--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月12日 (二) 05:43 (UTC)

差不多一年前了，讨论的内容好像是该不该调换命令案例的位置。--ultim_0 ( USER | TALK | WORK ) 2022年4月12日 (二) 06:12 (UTC)

确实有必要，并且我也有写一写的打算。但目前事实上，能完全看懂这些命令页面的人自然知道应该怎么写，看不懂的人即使有了页面规范，也没办法去完善这些页面。

页面里的各项内容对命令玩家都是很有必要也很有用的，却实在难以编写。就像权限等级，最简单的获取方法只有反编译看源码。而对于结果与输出值，更是完全没有简易的获取渠道。对于java版，必须对源码一行一行进行分析，寻找任何可能抛出异常和影响输出值的地方。对于基岩版，由于反编译的源码难以分析，所以需要绞尽脑汁想到游戏中可能出现的各种情况，并在游戏中逐一测试。有时候我在编写页面时，也很难考虑到所有情况，所以还需要看b站各个命令大佬的视频和动态，再对它们所提出的需要注意的情况进行测试。

可悲的是，近几年基岩版加入的命令大多是直接调用底层逻辑，而完全没有进一步的封装，导致这些命令的未定义行为和副作用数不胜数。像ride、damage这一类的命令，如果真想搞清楚它们的结果与输出，除了在游戏中对所有实体种类逐一测试，真没有什么好的办法。即使是我，也不敢说对ride、playanimation、damage这一类的命令很了解。--Chixvv（讨论） 2022年4月19日 (二) 04:17 (UTC)

我无法上传图片

今天尝试上传图片时（使用了编辑页面的自助式上传），突然返回如下错误并拒绝上传：

“过滤器在您的编辑中自动检测到了一些不妥，您需要核实编辑后再提交。
与您此次编辑所匹配的过滤规则概述如下：上传文件时未选择授权协议。
如果您认为您的编辑没有问题，可再次点击“保存更改”按钮来提交编辑。”

以前都没见过这种情况，请问我该怎么办？--Minesunset1030（讨论） 2022年4月16日 (六) 04:59 (UTC)

请使用Special:上传文件链接上传文件并为其选择正确的授权协议，不要在编辑框中直接上传。--AblazeVase69188（讨论 | 贡献） 2022年4月16日 (六) 05:43 (UTC)

关于“末地”和“末路之地”的用法

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

讨论结果为 移动页面，并将“末地”作为正式名称使用。

目前，“末路之地”和“末地”在本wiki中分别用作“The End”一词翻译的全称和简称，而实际上“末路之地”这一全称并未使用在游戏当中，查阅Crowdin后可知游戏内统一将其译作“末地”。但“The End”对应的维度和生物群系页面的标题当前皆使用“末路之地”，与其他和游戏内部名称保持统一的页面标题不一致，且一定程度上造成了页面内容的混乱，如在末路之地（生物群系）这一页面当中，末地生物群系的信息框标题显示为“末路之地”，而其他变种生物群系的信息框标题则只带“末地”二字。为了保持页面标题以及名称使用的统一性，在此提出以下建议：

将末路之地、末路之地（生物群系）两个页面分别移动至末地、末地（生物群系）。
“末路之地”一词今后仅用作维度页面的导言（末路之地（The End），通称末地……），其余地方统一使用“末地”。

如对此有其他补充意见或更好的名称使用方案也欢迎提出。--葉月桐§ 2022年4月17日 (日) 10:55 (UTC)

支持，“末路之地”确实在本Wiki乃至整个玩家社区内都使用得比较少。--AblazeVase69188（讨论 | 贡献） 2022年4月17日 (日) 11:34 (UTC)

支持。--McplayerFS（讨论 | 贡献） 2022年4月17日 (日) 12:06 (UTC)

附议，不会真的有人把“end portal”“end city”叫做“末路之地传送门”“末路之地城市”吧？--ultim_0 ( USER | TALK | WORK ) 2022年4月17日 (日) 17:35 (UTC)

我更好奇的是为啥游戏内的“The End”叫“末地”。虽然更应该去Crowdin把那个译名改成“末路之地”，但我觉得这地方是非要把这名字改定了。这里只建议一点：如果非要移动的话，导言别写末路之地了，把这名字放别称里去。——IcyPhantom 讨论I贡献 2022年4月18日 (一) 15:05 (UTC)

“末路之地”名字太长，不适合作为前缀使用（e.g.末路之地石砖台阶）。--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月19日 (二) 02:30 (UTC)

关于成文的译名使用指导

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

讨论结果为 同意建立。

长久以来，本Wiki在如何使用译名，以及如何处理译名变动的问题上，是有一些习惯的。我认为，如果这种习惯能够以文本的形式固定下来，应该可以使译名管理更加规范化。

所以，这次我向社区提出将这些习惯性、不成文的做法，以格式指导补充条款（即“译名使用指导”）的形式，形成正式的指导性文本。

此次提交社区讨论的文本的大多数内容是对既有习惯性做法的描述，可以在Minecraft Wiki:沙盒/Minecraft Wiki:格式指导/译名使用指导处查阅。恳请各位对此文本提建议。

另外，还有一个问题需要提交社区讨论：内容页面历史段落中，译名不同步更改时应当如何处理？（之前的讨论见：Talk:末地水晶#关于末影水晶和末地水晶这两个译名）-- Anterdc99（论·功） 2022年4月20日 (三) 10:30 (UTC)

意见：视作其译名“从未更改过”，即段落内全部使用更改后的译名。--ultim_0 ( USER | TALK | WORK ) 2022年4月20日 (三) 11:08 (UTC)

建议在历史段落记录所有译名更改，让旧版本玩家把条目和游戏内特性对应上，也方便了解译名历史。传入神经元（权限|讨论|贡献|日志) 2022年4月22日 (五) 09:14 (UTC)

我没什么意见，只是方针要简洁易懂。--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月23日 (六) 03:17 (UTC)

建议添加BE相关的译名事项，如BE名称没有同步JE的情况下如何使用译名（JE的风袭丘陵和BE的峭壁）、什么情况不可使用基翻、什么情况只能使用基翻原文（如选项名称）。--XiaoXin666（T·C） 2022年4月23日 (六) 05:02 (UTC)

已增加相关内容，见此差异。--

Anterdc99（论·功） 2022年4月26日 (二) 14:52 (UTC)

因为暂时没有更多人参与，且当前参与者并没有对文本其他内容的意见，故暂时将译名更改规则第三条隐藏，留待后续讨论，其余内容转为正式文本。--

Anterdc99（论·功） 2022年5月6日 (五) 03:54 (UTC)

“漏洞”章节的必要

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

讨论结果为 同意删除。

如题，“漏洞”章节只有一句话和一个前往Mojira的链接，内容单薄，且没有什么用途。

据考古，这个章节最早在2013年3月出现。当时是一个用JS加载的列表。在2013年五月左右改为了目前的一个链接形式。据en:Template:Issue list，这是因为Jira的API出现了一些错误。在这之后，漏洞章节再也没有得到更改。

如今，漏洞章节是否还有存在的必要？-- Dianliang233 ^T•_C 2022年4月21日 (四) 01:03 (UTC)

建议删除，这个段落在各种页面中千篇一律，除了提示前往漏洞追踪器之外一无是处，大有凑数的嫌疑。--ultim_0 ( USER | TALK | WORK ) 2022年4月21日 (四) 01:24 (UTC)

同意，{{issue list}}模板导致分类:本地化模块需更新这个分类里的条目迟迟无法消除。--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月23日 (六) 03:16 (UTC)

同意删除，凑数段落，还给编辑添加麻烦。--KaplanSteve ^T/_C 2022年4月23日 (六) 03:19 (UTC)

意见，可以改为mojira的固定链接以消除本地化模块更新的问题。当然我也支持完全删除段落。--Snow dash（论 & 功） 2022年4月23日 (六) 03:22 (UTC)

同意删除只含有issue list的“漏洞”章节。--

Anterdc99（论·功） 2022年4月23日 (六) 04:35 (UTC)

除了部分因为不受支持的游戏要素需要标注Mojira不受理之外，其余的删除也可。--

Lakejason0（论•功） 2022年4月23日 (六) 04:46 (UTC)

同样支持。--McplayerFS（讨论 | 贡献） 2022年4月23日 (六) 15:32 (UTC)

但，它的作用就是弄出一个指向相关内容的漏洞列表的链接，以及说明与此内容相关的漏洞会被怎么处理。不受支持的内容会在这一栏里写明不接受漏洞报告，而调试棒等少数特例会有额外说明。如果要全部删除，则需要给“不接受漏洞报告”和“漏洞报告特例”之类的说明找个位置；如果只把这些东西的“漏洞”章节留下来，只能说一致性喂了狗了。而且en那边还留着，虽然en的意见在这里不适用，我建议各位去那边问一下他们是怎么看待的。（如果他们也觉得没必要那我没啥想说的）——IcyPhantom 讨论I贡献 2022年4月24日 (日) 14:21 (UTC)

虽然但是，Wiki好像没有义务告诉哪些特性不能在漏洞追踪器里报告（摊手）。--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月24日 (日) 14:38 (UTC)

支持移除只含有{{issue list}}模板的“漏洞”一段，其他有特别说明的建议保留，我也暂时想不到其他适合放置这些特别说明的段落。虽然有用户认为部分保留该段落可能会破坏页面一致性，但是我认为这与“你知道吗”一段的有无是一个道理，这类内容应该是有必要才加入到页面中去，没有就不加。--AblazeVase69188（讨论 | 贡献） 2022年4月29日 (五) 13:02 (UTC)（最后编辑于2022年5月1日 (日) 07:59 (UTC)）

注意到此话题被搁置了。大家都支持删除的只含有{{issue list}}模板的“漏洞”段落，如果开始删的话，应该如何删除呢？--KaplanSteve ^T/_C 2022年5月1日 (日) 07:43 (UTC)

大概是把所有仅有{{issue list}}模板的“漏洞”一段移除，余下有特别说明的就不移除。这类操作应该是需要机器人的。--AblazeVase69188（讨论 | 贡献） 2022年5月1日 (日) 07:59 (UTC)

完全去除也无妨，Wiki没有义务告诉玩家哪些内容不能报告给漏洞追踪器（更不用说现在官方已经不承认这个是official wiki了）。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月9日 (一) 02:09 (UTC)

赞成，虽然漏洞追踪器上的用户有时候也会提及Minecraft Wiki，但是一般是接入en的页面链接，这已经与我们关系不大，甚至可以考虑把{{issue list}}这个模板给扬了。--ultim_0 ( USER | TALK | WORK ) 2022年5月9日 (一) 02:22 (UTC)

Sound table

Template:Sound table→User:烨凌/Sandbox/Sound table+模块:Sound table--烨凌（讨论） 2022年4月22日 (五) 18:51 (UTC)

请具体说明此次更改的内容及益处，不要通过抽象的方程式让别人理解您的意图，否则此话题将被存档至MCW:BT。另外，请及时按照讨论页方针整改您的签名。--葉月桐§ 2022年4月22日 (五) 20:19 (UTC)

本来的音效模板又不是不能用--Lxazl5770_zh.admin（论 ▪ 功） 2022年4月23日 (六) 03:07 (UTC)

同意Lxazl5770的说法，可以仅对现模板进行小修改即可。不需要改成模块。--

Anterdc99（论·功） 2022年4月23日 (六) 04:33 (UTC)

屎山，影响我维护。--烨凌（讨论） 2022年4月23日 (六) 04:40 (UTC)

支持重构，这个模板的代码实在辣眼睛，但请多沟通需求与设计，社区达成共识后再正式应用。--Snow dash（论 & 功） 2022年4月23日 (六) 04:46 (UTC)

重构是有必要的，但请先遵守社区规则，取得大家的一致意见后操作。--

Lakejason0（论•功） 2022年4月23日 (六) 04:47 (UTC)

“Slot”译名标准化

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

如题，现在Minecraft Wiki中对于“Slot”的译名有两种，即“栏位”与“槽位”，各条目使用混乱，需要统一修改。

另外，“栏位”的使用频率比译名标准化中的“槽位”更高。（搜索“栏位”大约得到900项结果，“槽位”则是400项）--Yzy32767（讨论） 2022年5月1日 (日) 02:18 (UTC)

译名标准化列表和游戏内都写的是“槽位”。——IcyPhantom 讨论I贡献 2022年5月1日 (日) 03:26 (UTC)

记得之前讨论过，应该使用槽位。而fandom搜索功能比较垃圾，因为“栏”字和“位”字使用的比较多，自然搜索结果比较多。使用b站镜像精确搜索，使用槽位的页面约有300个，而使用栏位的页面不足一百个。-2022年5月1日 (日) 03:59 (UTC)–该未签名留言由Chixvv（讨论 • 贡献）在2022年5月1日 (日) 03:59 (UTC) 添加。请在您的回复后面加上 ~~~~

提示：5个~是只生成日期的。--ultim_0 ( USER | TALK | WORK ) 2022年5月1日 (日) 04:19 (UTC)

这个可以使用机器人处理，请移步MCW:BOTR。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月1日 (日) 10:32 (UTC)

未命名话题

额...我感觉主页放大过的"Minecraft Wiki" 的logo不清晰请问可不可以给我合适的像素比（比如长x宽）。这样我可以很快就清晰化完毕。谢谢低分辨率的logo Batele Jackson（讨论） 2022年5月6日 (五) 22:05 (UTC)

了解一下什么是svg。--

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

“X制物品”与“X质物品”之统一

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

讨论结果为将相关表述统一为“X质”。

目前wiki上X制/质物品和工具的表述较为不统一，交流群内的多次讨论结果仍有分歧，因此有必要在社区专页进行进一步的讨论。

个人倾向于选择X制，在搜索引擎上搜索木制和木质，木制的搜索结果多为木头做成的物品，木质的搜索结果多形容木头本身的特性；石制和石质的结果类似。且搜索“木质品”或重定向到“木制品”。

当然，X制/质也可能需要根据具体搭配做出区分。--Ff98sha（讨论） 2022年5月7日 (六) 05:00 (UTC)

留言：使用“o工具/装备”（如木工具、皮革装备）可好？--ultim_0 ( USER | TALK | WORK ) 2022年5月7日 (六) 06:22 (UTC)

其实这种表述也很不错，不过对品质和盔甲材料页面中×质的表述应如何处理呢？特别是其中的表格只有“×质”的文字，我觉得改为诸如只有“皮革”“铁”的文字貌似不太恰当。--AblazeVase69188（讨论 | 贡献） 2022年5月7日 (六) 09:32 (UTC)

盔甲材料#材料中表格第一列内容多是“某某质”，唯独锁链和海龟壳没有“质”，~~搞特殊是吧~~。而且，第一列表头是“材料名”，并不存在一种材料叫“铁质”，删去质很合理。而对于品质，即使不改Tiers的翻译，由于品质里说“品质（Tiers）指的是工具和武器不同的等级和’’’材料’’’”，且材料与“品质”是一一对应关系，品质#概述中的描述删去质也没有任何问题，即“目前游戏里有6种品质：木、石、铁、钻石、金和下界合金”。其他多数涉及质的页面，比如方块的挖掘时间表，都可以采取同样手段规避。当然这是退而求其次的办法，规避了“制”“质”争议，我 更倾向于采取清秋的建议（见下引文）。--Mamaruo（讨论） 2022年5月10日 (二) 05:18 (UTC)

品质和盔甲材料中均使用了×质的表述，我个人 更倾向于使用×质的表述。我认为×制表示是用什么材料合成的，不过我实际上不太清楚Wiki现使用的×质的意思。--AblazeVase69188（讨论 | 贡献） 2022年5月7日 (六) 09:27 (UTC)

建议：盔甲讲材料，用“制”；工具讲品质，用“质”。传入神经元（权限|讨论|贡献|日志) 2022年5月7日 (六) 10:05 (UTC)

我个人同样 更倾向于使用×质的表述。--McplayerFS（讨论 | 贡献） 2022年5月8日 (日) 05:35 (UTC)

留言：我查阅了说文解字。不了解维基规则，就不放书的链接了。制：裁也。从刀、从未。未，物成，有滋味，可裁断。一曰止也。𠝁，古文制如此。质：以物相赘。从贝，从斦。阙。由此得知，质没有制造的意思，材质的意思是现代引申的，而制本意的制造是合适的。相关讨论CFPAOrg/Minecraft-Mod-Language-Package#1961。--Zhang anzhi（讨论） 2022年5月8日 (日) 12:02 (UTC)

留言：基于一致性原则，应当统一使用×质这种说法，原因：

描述不同对象用语的一致性：应统一使用“×制”或“×质”的说法，不宜将此处用词按类别分开讨论。
词性一致性：除“制”或“质”字外，其余部分均为名词形式。在《现代汉语词典》中，此处涉及的“制作”“制造”等词，“制”均作动词使用。此处涉及的“质地”一词中，“质”作名词使用。

另外，如使用“×制”这种说法，由于其动词性质，加上词组本身不包含主语的情况，有产生歧义的可能性。--

Anterdc99（论·功） 2022年5月8日 (日) 12:19 (UTC)（最后编辑于2022年5月8日 (日) 12:27 (UTC)）

盔甲和工具的分类本身就不一致，盔甲讲材料，工具讲品质，是不是要统一成品质？
“木制”整体作形容词，没问题。传入神经元（权限|讨论|贡献|日志) 2022年5月8日 (日) 12:39 (UTC)

难道盔甲就不可以讲品质？由某种材料制作出来的物品自然地具有相应的质地，而且也不止“质地”一个表达相似意思的词。例如“具有铁质感的盔甲”。--

Anterdc99（论·功） 2022年5月8日 (日) 12:54 (UTC)

可以，就把盔甲材料合并到品质呗。传入神经元（权限|讨论|贡献|日志) 2022年5月8日 (日) 13:13 (UTC)

“

目前游戏里有7种盔甲材料品质

”

——盔甲材料

这就是你说的页面里面的说法，建议把这个改掉再以此为论据，否则盔甲也可以谈“质”。合并页面的事，既然你这么说，那我赞成，当然合并也应当谁提出谁合并。--

Anterdc99（论·功） 2022年5月8日 (日) 14:16 (UTC)

盔甲当然可以谈“质”，这不影响“盔甲材料”这个说法与工具不一致。传入神经元（权限|讨论|贡献|日志) 2022年5月8日 (日) 14:26 (UTC)

注意，两者在代码层面上是不同的概念，合并会使概念混淆。比起讨论这玩意我觉得应该先规范下那个页面的用语：为什么“盔甲材料”的定义是“材质”？“盔甲材料品质”是什么意思？盔甲材料就是盔甲材料，不是品质也不是材质。顺带一提品质之所以叫品质是因为Mojang在混淆映射表里那么写了，有些非官方映射表写的是“工具材料”。——IcyPhantom 讨论I贡献 2022年5月8日 (日) 15:02 (UTC)（最后编辑于2022年5月8日 (日) 15:14 (UTC)）

木质物品同理。--

Anterdc99（论·功） 2022年5月8日 (日) 12:55 (UTC)

这里描述的应该不是质地。方块的质地就是材料，但物品没有质地的概念，说不定下界合金头盔有铁的质地。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 08:48 (UTC)

CFPA那边的规定是使用制或不写，我这边对用哪个字没有意见，但最好统一起来。——IcyPhantom 讨论I贡献 2022年5月8日 (日) 15:02 (UTC)

群内是讨论过的，我的观点依然是“无正确解”，两个用法都存在，而且似乎没人纠错。完全从现代汉语去解释（用文言语料解释现代汉语我觉得参考价值有待讨论），那我们有“木制品”这个短语（怎么断我不知道，制品似乎也是个词），但同样的名词也可以修饰名词，所以木制工具还是木质工具似乎都没有语法上的问题。群内讨论还有一个有意思的现象，就是一些人觉得“木制工具”“铁制工具”，但又“下界合金质工具”。我依然认为这是由于存在木制品这样的固有短语导致的，而这个现象的结果就是，不是固有短语用“制”不符合部分人的语感。我真的没有什么特别好的意见，统一就行，既然上面已经给出了一个mod项目的决定，那么仿照先人决定也未尝不可。另外，如要使用“制”这个字，请确认转换表是否可以工作（表制作用“製”）。--

Lakejason0（论•功） 2022年5月8日 (日) 15:16 (UTC)

改表时注意两个变体部分材料的译名不统一，需要分别写规则。--

Lakejason0（论•功） 2022年5月8日 (日) 15:19 (UTC)（最后编辑于2022年5月8日 (日) 15:20 (UTC)）

意见：我赞成“制”。我前几天发的一个“论证”和ff98sha出奇一致，不过我用的铁。铁质叶酸片、维基百科:铁质的存在似乎更能说明问题。

另外，原版语言文件中存在两处使用x质的地方，分别是字幕“铁质盔甲：铿锵”^[1]，进度描述“用金质物品吸引猪灵”^[2]，应当一并更改。

铁质 - 百度搜索丨铁质 - Google 搜索

铁制 - 百度搜索丨铁制 - Google 搜索

↑ 语言文件 Iron armor clanks,
↑ 语言文件 Distract Piglins with gold

一些观点：

“

我昨晚考虑了很长时间，也查了一下原版wiki使用x质的地方，x质基本可以说有以下三种用途：

形容工具的材料，统共来说有抽象和具体两种语境用法，抽象指的是根据某些工具的用料统一而将它们归摄于x质之下：木头做的就是木质，石头做的就是石质；而具体指的是1.12的木质压力板这种，然而这两者其实只是在语境上有区分，语义上都是第一种，即用料都是x。
用于形容某类方块，比如木质方块、石质方块等，这个基本能够和第一点统一：x质工具是用x质方块制作而成的。
品质也用到了x质，先不谈tiers翻译为品质这个是有多牛马，某某工具的品质是x质，这是在说它的品质是x品质吗？可是x质好歹还能让人望文生义为制作用料是x，怎么可能会有人理解为x品质？若tiers翻译成品级/品阶，后续顺势翻译为木级/阶，甚至为了简洁只保留“木”一个字，那不是更好让人理解？凡是wood通通翻译为木质，语境不分情况，这压根不是翻译，那是抄字典。

考虑到根本没有x质这一说法，1、2两点至少应更改为x制/x类，3的意见以上已给出。
我不知道MC百科那边内部是有什么意见，但是对于我们这边，我个人的观点是：

1.12.2 除了木质/石质压力板外，其他的x质均需改为x或是x制；而在方块类别上采用x类。
1.12.2版本以上，不得保留x质。
品质/挖掘等级只能保留x级/x，不得使用x质。

”

——清秋，前CFPA管理员，2022年1月10日，评论于把木制压力板（批量替换导致）回退为木质压力板的更改

Mamaruo（讨论） 2022年5月8日 (日) 17:29 (UTC)

质形容的是材料的性能，不应理解成用料，但“x质”表示的是材料本身的特性，也确实不该用来表达品质。支持您后三条观点。传入神经元（权限|讨论|贡献|日志) 2022年5月9日 (一) 01:30 (UTC)

插一句，关于tier的翻译，它实际上就是“等级”，“品级”和“品阶”在汉语语境下都有特殊的含义，不能单纯地表达为“等级”，现在翻译成品质是暂时最好的结果；如果要考虑改成X制，还有顺带考虑下tier的翻译问题。至于游戏里的tier，它不仅仅表示工具等级，还表示了村民的交易等级，换句话说它还是“等级”，只是不是我们通常认为的经验等级。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月9日 (一) 02:02 (UTC)

对上面给出的清秋的说法，我表达一下观点：

x质的三种用途：其中前两种没有什么问题，描述也基本符合事实。而第三点，抛开品质页面中的用词不谈（虽然此页面本身问题也比较大），以读者视角（或者说不熟悉wiki或不熟悉游戏的读者）来看，正常的理解路径应当是看到此处用字之后，再去扩展此字所代表的含义。由于不同读者对此会有不同理解，“质”也不一定是指“品质”。事实上，包含“质”字并可合理用于此处的词语还有很多，例如“质感”“质地”等，因此，局限于“品质”这一种解释而否定在短语中使用“质”字的可能性是不合理的。
“根本没有x质这一说法”：在此引述中并没有其他内容来印证这句话。关于为什么没有“x质”的说法，需要给出明确的证据证明，不然这可被认为是主观臆断的结果。
最终用词的三点做法：很明显，这里引用的三点做法是针对语言文件中的用词而作出的。经查阅，目前原版简中语言文件中，此类型的表述中使用的均是“质”，而“制”完全没有出现。需要明确的是，根据话题提出者的描述，此话题涉及的是wiki内容页面上的表达问题，并不涉及语言文件。而语言文件中的相关内容又以单独表示某个具体物品为主，故这三点做法不适用于原始议题。

另外，关于是否为了避免争议而去除这个字，我认为，在表格以及专门描述此类内容的页面上，去除这个字是合理的，也是可操作的。但对散布于各页面的相关表述而言，此字不能省略。很明显，“木工具”或“木制/质工具”出现在某一句话当中，明显是“木制/质工具”要更顺口。

对于“制”“质”这两个字本身的区别，两个字都体现了由原材料制作为成品的过程。“制”代表制作，表示了物品由什么原材料制成，是强调过程；而“质”代表质地，表示了成品具有怎样的属性，是强调结果。因此，在短语前后内容均为名词的情况下，“质”这个表示结果的字，就能与短语中前后内容拥有相同的词性，这也正是我之前所提出的。

以上。--

Anterdc99（论·功） 2022年5月10日 (二) 07:38 (UTC)（最后编辑于2022年5月10日 (二) 07:49 (UTC)）

语言文件的做法不一定不适用于wiki，还得讨论。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 08:48 (UTC)

回应：Wiki的作用是描述游戏，用语理应和游戏中一样——尽管现在游戏内的X质已经非常少了。--Mamaruo（讨论） 2022年5月10日 (二) 09:53 (UTC)

回复：正如我在上面提到的，如果真要按照游戏文本，那就只可能用“质”，因为“质”还有几处使用，而“制”则没有被使用。--

Anterdc99（论·功） 2022年5月10日 (二) 10:03 (UTC)

回应：怪我没说清楚，我观点见上方发言“另外，原版语言文件……应当一并更改。”--Mamaruo（讨论） 2022年5月10日 (二) 10:11 (UTC)

回复：

既然在原版语言文件里已经统一用了“质”，说明之前翻译相关内容的译者是有意识统一这方面的用词的。也就是说，可能之前在这方面已有共识或者标准，只是我们不清楚确切的内容。
与出版物或学术刊物相比，搜索引擎得出的结果会相对不可靠。也就是说，如果有相应的出版物或学术刊物，那么这些来源中的内容应当优先考虑，而不是仅凭搜索结果推定。
“制”与“质”之争本质上是用语习惯问题，没有对错之分（见上方Lakejason0的留言），只是谁能给出更合适的理由来论证某种用法更好的问题。明显地，除了从搜索结果出发论证“制”更好外，“制”支持者并没有从更高优先度来源的角度论证这个问题（除上面用《说文解字》论证的，但《说文解字》不适用于使用现代汉语的本wiki）。-- Anterdc99（论·功） 2022年5月10日 (二) 10:48 (UTC)（最后编辑于2022年5月10日 (二) 10:51 (UTC)）

┌──────────────────────────┘
现代汉语词典中“质”一个义项是“物质：流～|铁～的器具”，看来有这个说法，而且没有不好的理由。所以 别统一了，随便用吧。传入神经元（权限|讨论|贡献|日志) 2022年5月10日 (二) 12:51 (UTC)

留言：查阅了更多的词典，摘录如下：

《新华字典》第12版 ①本体，本性：物~|流~|铁~|实~。
《新华词典》第4版 ③质料，构成事物的材料。铁~|流~。
《现代汉语学习词典》③物质；质地：杂~|流~|食物木~的家具。
《新时代汉英大词典》3 matter;substance;material丨a kettle made of aluminium;analuminium kettle 铝~壶丨iron utensils 铁~器皿→流~；木~；杂~ --Mamaruo（讨论） 2022年5月10日 (二) 17:05 (UTC)

回复：我的意见是，使用《说文解字》找到两个字的定义，支持“质”的话，需要找到变迁出来“质”的支持者想要的“质”的意思的有关论证，也就是为什么不适用于现代汉语的Wiki，这两者之间一定是有可查证的历史变迁记录，否则凭借“个人经验”的意思理解都是废话。--Zhang anzhi（讨论） 2022年5月10日 (二) 16:01 (UTC)

根据上述意见，拟将“X制”和“X质”统一为“X质”。如仍有疑问，请在一天内提出。--Ff98sha（讨论） 2022年5月12日 (四) 08:36 (UTC)

已使用机器人将相关表述统一替换为“X质”。--葉月桐§ 2022年5月13日 (五) 11:06 (UTC)

粒子问题

发现很多提及某个粒子的文章都没有写粒子名称，请大家注意修改。20.205.111.253 2022年5月7日 (六) 05:05 (UTC)

你是说幽匿尖啸体吗？没必要，大家并不一定想要知道那些粒子在代码之中的名称。--ultim_0 ( USER | TALK | WORK ) 2022年5月7日 (六) 06:22 (UTC)

剩余漏洞章节的处理

下列有关剩余漏洞章节处理方法的讨论已经结束，请不要再编辑此段。任何想要进一步探讨的编辑者应该新建一个话题。

讨论结果为 移除段落，特殊页面参照下方意见处理，附加信息为：“PC Gamer演示版”——更名为“已知问题”；“语言”——与“你知道吗”合并；其他——移除段落。

虽然目前机器人已批量删除只含有{{issue list}}模板的“漏洞”章节，后期也手动移除了一些只含有漏洞报告提示的“漏洞”章节。但此段落在一些页面中仍有遗存，由于在原话题讨论时尚不掌握其具体内容，故对这些页面的处理方式的讨论被暂时搁置。

现已将这些页面列出以供讨论。这些页面可分为以下两类：

Java版远古版本页面：描述了这些版本中会出现的漏洞。
其他（PC Gamer演示版和语言）

目前已经将这些页面中的漏洞章节全部抄录到一起，以供参考。由于文本过长，故不直接放置在此处，可进入User:Anterdc99/Archives/漏洞查看。

经过在交流群中与Lxazl5770的初步讨论，对Java版远古版本页面，Lxazl5770提出了2种处理方法：

直接移除段落，不保留任何信息。
将这些段落合并至统一位置。

“PC Gamer演示版”和“语言”由于其漏洞章节内容的特殊性，需要另外讨论。

我认为，Java版远古版本页面基本上描述的都是一些过时漏洞，且无利用价值，应该可以直接移除。“PC Gamer演示版”描述的内容更像是这个版本中的独有特性，应该可以将此章节更改为其他名称。而“语言”描述了一些现今仍存在，且影响范围较大的漏洞，这些内容有一定的保存价值，只是具体怎么保存还需要讨论。-- Anterdc99（论·功） 2022年5月11日 (三) 11:50 (UTC)（最后编辑于2022年5月11日 (三) 12:07 (UTC)）

意见：

1. 把Java版远古版本页面上列出的漏洞删除，理由同上；且其他Java版版本页面都没有对该版本中所出现的漏洞进行详尽描述，为了格式统一也应该删除。

2. “PC Gamer演示版”和“语言”的漏洞一段，将前者的段落名称改为“已知漏洞”，后者移动至“你知道吗”一段下作为单独的子段落，保留“漏洞”的段落名称。--AblazeVase69188（讨论 | 贡献） 2022年5月13日 (五) 11:06 (UTC)

由于目前没有更多人参与此话题，为避免无限期搁置，现拟参考AblazeVase69188的意见以结束此话题。如有其他不同意见，请于1日内提出。-- Anterdc99（论·功） 2022年5月26日 (四) 05:33 (UTC)

已完成。--

Anterdc99（论·功） 2022年6月8日 (三) 14:29 (UTC)（最后编辑于2022年6月8日 (三) 14:30 (UTC)）

关于部分页面将漏洞情况加入非“修复”段落的问题

各位好，如题目所示，我认为不能将漏洞的情况添加至非“修复”段落中，否则内容将会非常杂糅，且不统一，我的观点是删除所有不在“修复”段落的漏洞修复信息。 ——Thaumic Copper（吐槽·考古） 2022年5月13日 (五) 09:58 (UTC)

例子？-- Dianliang233 ^T•_C

2022年5月13日 (五) 10:00 (UTC)（最后编辑于2022年5月13日 (五) 10:01 (UTC)）

耕地#历史——

Thaumic Copper（吐槽·考古） 2022年5月13日 (五) 10:01 (UTC)

见MCW:SG/F#历史中所述的例外情况。--

Anterdc99（论·功） 2022年5月13日 (五) 10:05 (UTC)

反对：有些漏洞修复实际上也是特性更改，尤其是基岩版，如果全部放到修复反而不好。（一般很多人读更新日志都会跳过大段修复章节）像现在这样挺好的，只要规范一下就可以了。Tzql1104048（讨论） 2022年5月21日 (六) 03:51 (UTC)

Screen相关译文待更新

部分页面（如调试界面、菜单界面）应将其中对应“Screen”的“界面”更换为“屏幕”使其与Crowdin译文保持一致。 -Jingji132（讨论） 2022年5月18日 (三) 10:24 (UTC)

似乎已经完成。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月9日 (四) 16:09 (UTC)

关于教程中有关旧版本的内容

如题，许多教程包含“某特性从某版本开始可用或在某版本之后不可用”之类的描述，我认为应当对这些内容进行一定程度的删减，因为Minecraft Wiki的教程是随着新版本发布而一同更新的，不可能兼顾所有版本的玩家，因此建议做出如下更改：

在教程中列出当前最新版本可用的内容或特性，将“某特性从某版本开始可用”的描述移除。
将过时的内容或特性归档到相应页面的结尾，并用{{Outdated feature}}标明失效的版本及原因。

大家如有不同的看法，烦请在下面陈述。--ultim_0 ( USER | TALK | WORK ) 2022年5月18日 (三) 15:33 (UTC)

意见：过时的内容或特性可以放置在/××之前子页面，并以{{loadPage}}或{{main}}模板链接至对应的教程页面。--AblazeVase69188（讨论 | 贡献） 2022年5月20日 (五) 10:10 (UTC)

长的可以，很多一句话的事不该再起一页。传入神经元（权限|讨论|贡献|日志) 2022年5月20日 (五) 12:45 (UTC)

支持。--McplayerFS（讨论 | 贡献） 2022年5月28日 (六) 02:27 (UTC)

关于中国版缺乏介绍的问题

发现关于中国版的介绍只有中国版这一个页面，关于家园系统，网易自己制作的游戏地图等缺乏介绍。–该未签名留言由59.149.163.248（讨论）在2022年5月23日 (一) 05:00 (UTC) 添加。请在您的回复后面加上 ~~~~

由于潜在的法律风险，中国版独有内容在Minecraft Wiki不受支持，感谢您的理解。另请参阅讨论页存档。--ultim_0 ( USER | TALK | WORK ) 2022年5月23日 (一) 05:49 (UTC)

w:Special:CreateNewWiki-- Dianliang233 ^T•_C

2022年5月23日 (一) 05:54 (UTC)

本Wiki不收录更多关于中国版的内容。请寻求国内的Wiki农场的协助或者在Fandom申请新的Wiki（上方链接）试着自己编写。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月23日 (一) 07:14 (UTC)

签名请用半角波浪线。传入神经元（权限|讨论|贡献|日志) 2022年5月23日 (一) 07:44 (UTC)

关于“萤火虫”的内容收录问题

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

讨论结果为 建立独立的萤火虫页面。

目前，关于萤火虫的为数不多的信息被安放在Java版提及特性里。然而，萤火虫并不是Java版独有特性，它甚至在基岩版里有了源代码（但在最新的测试版里被移除）。换句话说，可以通过一些方法来在即将发布的基岩版1.19.0或者在它的测试版本里将其调用出来，这对于基岩版开发者而言是非常简单的事情（已经有开发者做到了）。

这里就不再展开详细介绍。现在的问题是，萤火虫作为非版本独有特性，该将更多的内容放置在哪？在Java版提及特性页面里插入基岩版内容是不明智的做法，而在基岩版提及特性里插入更多内容也会导致重复叙述；萤火虫本身就不属于版本独有的内容，如果将其强行放置在区分版本的特性页面里是非常不明智的做法。

或许可以考虑单开一个页面来放置萤火虫的相关信息，但是本wiki并没有为单独一个提及特性建立一个页面的先例；如果将会萤火虫视作“已移除的特性”，实际上也仅仅加入了代码，无法在游戏里使用正常命令生成，还不构成视作“已移除特性”的惯例。

我个人是不希望因为上述问题阻碍了对单个特性的更多内容的收录，更不用说“萤火虫”是最近讨论热烈的话题。我希望能够获得各位的看法。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月26日 (四) 04:58 (UTC)

意见：天域~~（重定向至Java版提及特性/天域）~~就是一个先例，完全可以参照这个特性，为萤火虫建立一个单独的页面~~（如基岩版提及特性/萤火虫）~~。--ultim_0 ( USER | TALK | WORK ) 2022年5月26日 (四) 05:02 (UTC)（最后编辑于2022年5月26日 (四) 05:12 (UTC)）

我觉得 没什么问题，毕竟萤火虫在基岩版属于已经进行了一定程度的开发并且虽然被隐藏了但是还是加入了基岩版并且通过一定手段可以调出来的内容。方法放寒假 (Talk - Contributions) 2022年5月26日 (四) 06:25 (UTC)

支持单开页面。--KaplanSteve ^T/_C 2022年5月26日 (四) 07:14 (UTC)

根据MCW:关注度，目前还不存在于基岩版的特性应放入基岩版提及特性。传入神经元（权限|讨论|贡献|日志) 2022年5月26日 (四) 09:05 (UTC)

但是萤火虫已经存在于源代码之中了，就像1.18.30之前的旁观模式一样，只是不能通过实验性玩法之类的方法调用。--ultim_0 ( USER | TALK | WORK ) 2022年5月26日 (四) 10:08 (UTC)

这些信息可以附在后面，像那些已经部分加入的特性那样。传入神经元（权限|讨论|贡献|日志) 2022年5月26日 (四) 11:55 (UTC)

关于萤火虫的更多信息我放在我的沙盒里了，请各位查看一下。我想这些内容已经足够支撑一个页面（有趣的是，萤火虫还有实体Sprite，并没有移除）。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月26日 (四) 12:59 (UTC)

根据您在上面和您沙盒中历史部分的描述，萤火虫并未加入游戏，何来移除？传入神经元（权限|讨论|贡献|日志) 2022年5月26日 (四) 15:55 (UTC)

代码加入也是加入，而且能够调用出来，和当时的相机和天域是一个道理。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月27日 (五) 00:57 (UTC)

您之前说无法使用正常命令生成，这就不算加入游戏。如果能在基岩版游戏中正常调用，那就是基岩版独有特性，或者现在不能调用了就是已移除特性。相机可以在游戏中正常获取，天域归到提及特性了。传入神经元（权限|讨论|贡献|日志) 2022年5月27日 (五) 01:47 (UTC)

相机这个属于不能在游戏里正常获取（命令也不能）但它还没移除。萤火虫属于在当前的正式版1.18.31可以利用附加包生成（但不算是正常获取），在1.19.10里被彻底移除了，所以我才放上“已移除”信息框。另外，我不希望因为上述问题阻碍了对单个特性的更多内容的收录，因为目前收集的信息量已经足够支撑起一个页面。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月27日 (五) 10:25 (UTC)

我在原版附加包没找到萤火虫，您指的是自定义附加包吗？它只能用自定义附加包启用的话就是提及特性。需要收录的内容包括移除的信息都可以写在基岩版提及特性，如果确实需要为提及特性单开页面可以改格式指导。传入神经元（权限|讨论|贡献|日志) 2022年5月27日 (五) 15:26 (UTC)

咩咩王说这个萤火虫可以通过开发者版本的基岩版来调用，但在常规版本里只能通过附加包加载。我还不清楚“原版附加包”和自定义的有什么区别。关于格式指导，我认为随着时间的推移，会变得越发不准确，但另一方面又不想为了单独的东西来改动现行的格式指导。如果只是把萤火虫丢到提及特性里，我觉得这非常可惜。请用平辈称呼，谢谢。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月27日 (五) 16:33 (UTC)

我已经收集到了充分的信息。在开发者版本的基岩版里，萤火虫不仅有刷怪蛋，而且能够使用命令生成。Mojang在编译零售版的时候把萤火虫的相关代码去除了，但是仍然有目标选择器的残留。开发者版和零售版是并行的，同样属于原版。显然，在开发者版里，萤火虫是属于原版附加包的内容的，只是如果想要在普通用户玩到的版本中实现萤火虫，确实需要加载外部的附加包来实现。综上所述，萤火虫不算是提及特性，它属于即将被移除的特性。因此既不需要改动格式指导，也允许单独一个页面介绍。如果没有更多人持反对意见，我会完善后移动到主命名空间里。祝各位编辑愉快。--Lxazl5770_zh.admin（论 ▪ 功） 2022年5月27日 (五) 17:31 (UTC)

同意。“原版附加包”大概是我理解错了，附加包应该都是外部的。传入神经元（权限|讨论|贡献|日志) 2022年5月27日 (五) 23:20 (UTC)

关于“最近更新”

我们关于“最近更新”版块，我们可以在最近更新版面里添加快照版本的更新。这样就可以让玩家们跟进何时发布的快照更新。 Batele Jackson（讨论） 2022年5月27日 (五) 17:38 (UTC)

反对，已经有类似的内容了，见于“开始游戏！”的“开发/测试版本”。另，涉及首页内容相关的话题应当在首页的讨论页进行讨论。--ultim_0 ( USER | TALK | WORK ) 2022年5月27日 (五) 17:51 (UTC)

关于“画廊”章节的文字说明

我发现每个页面的“画廊”章节图片下的文字说明部分存在一个问题，就是句末要不要加句号的问题。虽然无伤大雅，格式指导里也没有，但是我认为这种细节问题还是统一一下比较好，统一了观感上也有提升。--KaplanSteve ^T/_C 2022年5月28日 (六) 08:42 (UTC)

相关格式说明见于MCW:图像：“图像介绍末尾不应有句号，除非语句是一个完整的句子”。--葉月桐§ 2022年5月28日 (六) 08:47 (UTC)

修改四个~签名

本主题或以下段落文字由ultim_0 ( USER | TALK | WORK )移动自Minecraft Wiki:管理员告示板。

可不可以在使用四个~签名时自动在前面加上“--”？
原版：
用户名日期
修改：
--用户名日期（相当于--~ ~ ~ ~）

--Java.lang.NullPointerException（讨论） 2022年6月3日 (五) 06:15 (UTC)

请在您的参数设置中手动修改签名内容，记得勾选“将签名视为维基文本”。--ultim_0 ( USER | TALK | WORK ) 2022年6月3日 (五) 06:42 (UTC)

弃用“数据标签”一词

建议弃用“数据标签”一词，全面更改为“NBT标签”或“NBT”。

社区几乎不使用，实在没见过有哪个玩家在交流时会带上“数据标签”一词。
游戏内已不使用该词。“数据标签”对应的原文是“Data Tag”，这个词组只存在于较早期的Minecraft中，当前版本直接使用“NBT”一词，中文也全部照写“NBT”。
“数据”一词概念过于广泛，方块状态也可以属于数据，而“NBT”能更好的指明它是什么。--Yzy32767（讨论） 2022年6月4日 (六) 00:02 (UTC)

可以请求机器人进行全局替换。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月9日 (四) 16:07 (UTC)

请求敲定“parity”一词的标准译名为“趋同”

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

讨论结果为准许。

请求敲定parity一词的标准译名为趋同，理由分述如下：

现状: 当前parity一词本身无单独翻译，Parity Issue词组被MCW翻译为待同步特性，Vanilla Parity被MCBBS相关更新日志页面翻译为特性同步。

敲定该词的标准译名的必要性

在部分官方文章中parity一词单独出现，或与其他更多单词一起组成词组出现，导致不便或无法翻译，例如parity request、feature parity等。参考页面为：https://feedback.minecraft.net/hc/en-us/articles/360015877192 ；Minecraft Feedback网站亦有名为Parity的分类。
parity无标准译名会导致玩家或开发者（尤其是开发者）无法对这个词语产生既视感，亦不便于玩家或开发者在Minecraft Feedback或Mojira上进行相关反馈或在其他涉及到的地方使用。

parity一词的解释: 词根-par-来自于拉丁语par、paris，意为相同、类似。率先被数学界确立为术语，parity表示数学中一种类似但对称/对等变化的事物：奇偶性。随后被经济学确定为不同国家货币单位的一种对称/对等变化：平价，被物理学确定为“宇”（即空间）的一种对称/对等变化性质：宇称。随后被计算机界确立为一种校验两个程序是否具备相同功能的过程，通过比较1的数量（是奇还是为偶）是否一致来确定程序功能是否一致，被称为：奇偶校验（来自于微软术语库），而作为该过程的结果，即两个对称/对等变化的程序功能的一致程度，称为功能的奇偶一致性（来自于微软术语库）。Mojang选取了这一概念，并作出了改编和进一步解释：在官方文章Parity Requests and You: A Guide中，给出解释“Parity is a word that we use a lot here. We use it to mean "ways we can make Minecraft be the same experience as much as possible, regardless of what 'engine' you are using to play". Starting with Update Aquatic, our team renewed its commitment to developing the same features for all versions being updated in Minecraft at the same time.”。注意，这是一种自我免责的说法，“we can make Minecraft be the same experience as much as possible”，这里所说的是提供相同的体验，而非相同的功能，这是一种具备很大最总解释权的说法；而后一句话，也仅是在说从海洋更新开始，我们（才）承诺同时提供相同的功能，事实上这句话并不是在说parity问题了。同时更新相同的功能属于更新问题而非我们所谓的“将一方的特性（feature，其实应该翻译为功能）移植到另一方上的问题”（当然也正是因为这个原因本来在BE开发者版中基本上都做好的萤火虫和白桦树（可能）因为JE产能不足给删了，当然这就是另一个指的探讨的问题了，和本问题无关）。可以看出，Mojang的parity显然来自于微软对于parity奇偶校验的词义，但是，该词只选取了使功能（或者说体验）尽可能相同的说法，而没有进行所谓的真正的“奇偶校验”。微软的“奇偶校验”翻译不可取。

当前翻译的错误性: 接上一段，我们可以看出，parity并非同步。Mojang选取parity一词作为特性移植的代名词，而不是uniform、consistency、port、synchronize等，很可能是由于parity词义模糊，可以充分解释，进行自我免责。同时，Minecraft Feedback网站上也有很多提出的parity申请被表示不会在可视时间内移植（类似于Mojira的not fix）。parity并非承诺同步，亦非承诺一致、同化、等价……。这是当前的同步不可取的原因。而特性一词更是无中生有，如果必须保留这种翻译，那么parity request、单独的parity等翻译也就必须“曲线救国”，绕圈调整至类似的翻译的样子。不可长久，亦不可取。

给parity一词下个定义: 经过上述分析，Mojang给出的parity意为对JE和BE之间的功能对称调整，使其体验趋于相同的过程。解释：调整tweak的是功能feature，tweak意味着微调而非一致化的保证，该词亦是官方更新日志选取的词汇；趋同的是体验experience，与官方的解释相一致。

社区讨论过程: 由我先提出等称的翻译，改编自物理学翻译宇称。由于晦涩难懂，在贡献者群试讨论被全盘否定，移至基岩版开发术语讨论群投票，被否定。在基岩版开发术语讨论群中讨论并征集译名，在分析parity的发展与含义后陆续否定所有绝对性词汇，同时否定的原因也有不符合一词一译的原则（例如一致应为uniform或consistency，同步应为synchronize等，会产生术语冲突，提高翻译成本），最终得出趋同一词作为术语，在场人员全部持赞同或中立赞同立场，发起投票，尚无反对票产生。

“趋同”的优势

符合定义，趋同即JE与BE游戏体验的趋同，虽然“调整功能”这一含义没有体现，但是也暗含其中。
群众接受成本低，趋同为“顺口词汇”，不像等称等翻译让人无法接受。
不会产生术语冲突，趋同一词为中文纯文学性词汇，对应的英文只有文学性的converge/convergence。而converge/convergence作为非文学性/专业词汇时应翻译为收敛，因此不会产生术语冲突，便于行文翻译。

总结: 在几乎所有能够想出的词汇都被以充分的理由否决之后，趋同一词以其独有的优势看似成为了该术语的译名敲定最优解。因此，请求敲定parity一词的标准译名为趋同。

相关翻译: parity 趋同; feature parity 功能趋同; vanilla parity 原版趋同; parity issue 趋同问题; parity request 趋同请求

方法放寒假 (Talk - Contributions) 2022年6月8日 (三) 16:52 (UTC)

支持。趋同一词是目前社区提出的相对符合parity在MC中含义且顺口的词汇了--QianShanyao（留言） 2022年6月8日 (三) 17:12 (UTC)

这就是太长不看效应吗？唔，作为参与了讨论初期的人，我表示parity issue翻译成趋同问题会有理解成“趋同是一种问题”的嫌疑。--

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

附议：可以将parity issue翻译为趋同事项。--AblazeVase69188（讨论 | 贡献） 2022年6月9日 (四) 01:41 (UTC)

唔......作为parity翻译的提案，在此处我个人关注的更多还是parity，而有关parity issue的翻译，这应该是issue在此处翻译的问题，而非parity吧（且我也是全程参与了在术语群的讨论的qwq） ——QianShanyao（留言） 2022年6月9日 (四) 09:34 (UTC)

wiki和其他地方用的Parity Issue是最多的。既然都翻译成趋同了，要不把这个翻译成“特性趋同”呢？--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月14日 (二) 03:50 (UTC)

Feature和特性的关系本身就值得玩味，不建议从争议词汇出发。--

Lakejason0（论•功） 2022年6月14日 (二) 03:54 (UTC)

同意，改用“趋同”加强了翻译间的统一性，且贴近原文而直观。

另外，关于“parity issue”，“趋同问题”或者“趋同议题”这样的直译就行。--Yzy32767（留言） 2022年6月15日 (三) 12:38 (UTC)

主要是，issue翻译成“问题”，性质就变了。“趋同”不是问题，“不趋同”才是问题。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月17日 (五) 14:59 (UTC)

意见：可否考虑把parity issue翻译成“趋同事项”？--ultim_0 ( USER | TALK | WORK ) 2022年6月17日 (五) 15:31 (UTC)

中立：这样似乎去除了其中“问题”“错误”之类的含义，不过暂时是最优解。--Yzy32767_{【论/功】} 2022年6月18日 (六) 00:13 (UTC)

意见：总觉得“趋同事项”“趋同问题”这些翻译虽然准确，但是挺怪的……Tolly9180（留言） 2022年6月18日 (六) 10:15 (UTC)

最后采纳的提议如下：

原文	翻译
parity	趋同
feature parity	特性趋同
vanilla parity	原版趋同
parity issue	趋同事项
parity request	趋同请求

若无异议，3日后确立为讨论结果并予以采纳。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月29日 (三) 13:46 (UTC)

时日已到。--Yzy32767_{【论/功】} 2022年7月2日 (六) 13:24 (UTC)

远古之城页面缺少结构图片

1.19都更新了，远古之城页面结构图片还没有吗？请大家赶紧上传。 —-146.19.174.201 2022年6月9日 (四) 04:49 (UTC)

1.“Ancient City”的正式翻译为远古城市；

2.请问您是指游戏中所生成的结构的逐层构造吗？本Wiki的这些逐层构造并非由图片构成，而是由{{layered blueprint}}模板输出；

3.若您有能力，您可以注册一个账户，并至Minecraft_Wiki:计划/结构蓝图开始完善远古城市相关结构。--AblazeVase69188（讨论 | 贡献） 2022年6月9日 (四) 10:08 (UTC)

远古城市的结构较为复杂，无论是单个结构的等轴渲染图还是蓝图的制作都难以一蹴而就，还请您理解。--ultim_0 ( USER | TALK | WORK ) 2022年6月9日 (四) 10:15 (UTC)

Minecraft Wiki自动下载文件

几乎每次访问时均会自动下载f.txt与cm。我认为可能有攻击者修改了源代码。以下是我找到的可能与自动下载有关的源代码(在head区内)：

<script src="https://securepubads.g.doubleclick.net/gpt/pubads_impl_2022061501.js?cb=31068115" async=""></script>

希望管理员可以修复，谢谢！

183.193.129.221 2022年6月22日 (三) 08:10 (UTC)柚子柚子

我想这个应该是谷歌的广告。作为Fandom托管站的志愿者团队，很抱歉我们没有移除广告的权限。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月22日 (三) 09:41 (UTC)

或许你可以尝试注册账号，并活跃做出有意义的贡献，这样可能就没广告了。--

乳液Louis ^对话 •_贡献 2022年6月26日 (日) 05:39 (UTC)

现在获得Gamepedia PRO已经没有办法阻止Fandom向用户投放广告了。--AblazeVase69188（讨论 | 贡献） 2022年6月26日 (日) 08:44 (UTC)

喔真的吗？看来我太久没回来了。－－

乳液Louis ^对话 •_贡献 2022年6月26日 (日) 09:10 (UTC)

请删除MinecraftLegendsLogo.jpg

由于我无法将.png文件上传为原.jpg文件的新版本，我刚刚将MinecraftLegendsLogo.png作为一个新文件上传并修改了引用MinecraftLegendsLogo.jpg的页面介于该文件已无任何页面引用且被新文件的作用所覆盖，能否将MinecraftLegendsLogo.jpg删除?-WindMC（留言） 2022年6月22日 (三) 14:36 (UTC)

已完成，提请删除直接在页面挂{{delete}}模板即可，不需要在此处或管理员告示板发布请求。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月22日 (三) 14:44 (UTC)

关于重新划分版本导航模板的事项

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

讨论结果为准许。

注意到Anterdc99最近在自己的用户页中筹划重新划分{{Java Edition versions}}中的正式版和{{Bedrock Edition versions}}中的基岩版部分，并准备将其应用到模板中，但一些用户似乎不赞同其行为，故特地在社区专页发起讨论：

应将这些区域划分为哪几个部分？理由又是什么？
进行划分之后的部分是否应设置一个[显示/隐藏]按钮统一控制这些部分的显示/隐藏？

以上。--ultim_0 ( USER | TALK | WORK ) 2022年6月25日 (六) 18:19 (UTC) （最后编辑于2022年6月25日 (六) 18:24 (UTC)）

我觉得上面的分法就很好，将正式版拆分的原因是为了方便检索，因为正式版的更新叠起来实在是太长了，在页面里占据的篇幅太长，而且密密麻麻的版本号非常不便于检索。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月26日 (日) 03:37 (UTC)

赞成--

乳液Louis ^对话 •_贡献 2022年6月26日 (日) 05:54 (UTC)

本来是想开单独的话题讨论这个事，鉴于已开此话题，故在此话题下介绍相关情况。具体的显示效果可以在User:Anterdc99/Archives/Edition versions Preview看到。

背景

英文Wiki已于2个月前将{{Java Edition versions}}和{{Bedrock Edition versions}}两个模板中正式版的内容进行了分段处理，并更新了各版本页面中的引用；
目前的版本导航模板中正式版部分内容过长，不方便查找相关内容。（英文Wiki作出变更以及此处提议作出变更的根本出发点，也是众所周知的原因）

英文Wiki采用的方案

仅将Java版和基岩版的正式版进行分段处理；
将各正式版按1.x和1.1x的方式进行简单的划分。（即1.20开始开发后，也会新增相应的分段）

既然英文Wiki已经有现成的方案，为什么不直接使用？

英文Wiki目前的分段方式仅是将长度部分缩短，而对于达成改善检索条件，目前的效果还可以有提升空间，目前的分段后的长度仍然过长；
英文Wiki的方案需要对大量修改各版本页面，改动面过大。

因此，在本人设计新模板样式时，确定了以下要点（优先级递减）：

被展示部分的长度应当小于一屏，但可以略大于一屏；
被展示部分不应当太短（即避免将每个大版本划为一段的方式），但与其他部分较难相容时例外；
分出的段落应当长度一致或接近。

因此，在提交讨论的设计方案中，以下内容与英文Wiki的不同：

在|1=中填入的参数为1.0（即原先的“正式版”总类）时，模板会根据版本页面的名称和归属版本确定要被展示的部分，可以减少相应的修改量；
|1=参数支持直接填入下面列出的值，可在无法自动检测时正确显示相应内容；
Java版正式版分为：1.0 - 1.7（1.0）；1.8 - 1.12（1.8）；1.13 - 1.16（1.13）；1.17+（1.17）；
- 以版本使用率为依据（或者说代码变更幅度）进行分类，即以1.7.10，1.12.2以及1.16.5这三个版本作为结尾；
- 1.8 - 1.12和1.13 - 1.16两个中间段落在长度上大致相等。
携带版正式版/基岩版分为：1.0 - 1.1（1.0）；1.2 - 1.9（1.2）；1.10 - 1.16（1.10）；1.17+（1.17）；
- 1.0 - 1.1为携带版，其与后续版本的标题不同，故单独成段；
- 1.2 - 1.9和1.10 - 1.16没有明确的分段依据，而是依据长度原则进行划分，这两段的长度大致相等。

另外，除{{Java Edition versions}}和{{Bedrock Edition versions}}外，其他的类似模板由于使用率较低，故不在此次更改的范围内。

回应

分类依据：见上；
统一控制按钮：保持与英文Wiki保持一致，并降低代码复杂度，不会加入此功能。-- Anterdc99（论·功） 2022年6月26日 (日) 07:52 (UTC)

赞成，不过如果能够把1.0以前的版本合并为“测试版”就更完美了（因为分栏会一直增多，或者把Pre-Classic到Infdev合并，Alpha到Beta合并也行）。--Lxazl5770_zh.admin（论 ▪ 功） 2022年6月26日 (日) 11:44 (UTC)

建议用一个[显示/隐藏]统一控制正式版之前内容的显示和隐藏，因为这些内容太少了，加起来就只有两屏。--ultim_0 ( USER | TALK | WORK ) 2022年6月26日 (日) 12:06 (UTC)

同时注意到Java版beta部分有许多空白，建议也对这些内容进行整理。--ultim_0 ( USER | TALK | WORK ) 2022年6月26日 (日) 12:11 (UTC)

UPDATE：根据上方建议，做了以下更改：

将Java版的pre-Classic到Infdev，以及Alpha与Beta分别合并到一起，原先的各阶段标识改到段落内作为分隔行；
1. 由于调整后仍不能在一屏内显示，故正式版前所有内容并未合并在一起；
2. 合并后，|1=的pre-Classic、Classic、Indev和Infdev选项改为统一指向“pre-Classic - Infdev”段落；Alpha和Beta选项改为统一指向“Alpha - Beta”段落。
调整了Alpha和Beta的左栏样式以降低高度。

而关于测试版的统一控制，相似地，为了避免增加代码的复杂度，不会加入相应的控制按钮。-- Anterdc99（论·功） 2022年6月27日 (一) 14:27 (UTC)

由于此话题自27日起再无任何新评论，且根据以上发言，可认为是总体支持，故拟定于明日（即7月4日）晚23点（CST）更新相关内容。如有其他意见或建议，可于最终执行前提出，谢谢。-- Anterdc99（论·功） 2022年7月3日 (日) 15:10 (UTC)

[1] 语言文件 Iron armor clanks,

[2] 语言文件 Distract Piglins with gold

[1]

[2]