|
Minecraft Wiki:社区专页
KaplanSteve在话题“新增DiscussionTools扩展”中的最新留言：2024年3月13日 (星期三)
| [隐藏] | |
|---|---|
| 社区 | |
| 管理 | |
- 快捷方式
- MCW:CP
- MCW:PORTAL
- MCW:社区
社区专页是为用户讨论编辑相关话题设立的。用户也可以在对应页面、用户的讨论页讨论。在发言后请记得添加~~~~签名。
请了解，Minecraft Wiki在共识系统上运作而不是投票决定，清楚地阐述自己的理由比简单地支持争论的一方更有效。
常用页面 |
Minecraft Wiki不是客户服务中心！游戏问题请移步Minecraft帮助中心或者玩家游戏社区。
所有在该页面上发表的无关话题都将被存档至无意义话题处。
请点击下面的“发起议题”按钮或页面上面的“添加话题”标签在页面底部发表新的议题。
存档
- 最新Wiki新闻
- 2025年3月17日 - 新的巡查员AblazeVase69188上任。
- 2025年3月10日 - 经社区讨论，“关注度”更名为“收录标准”。
- 2024年10月18日 - 新的巡查员TeaSummer上任。
- 2024年8月14日 - 新的巡查员海绵couna上任。
- 2024年7月1日 - 新的管理制度实施。
| # | 话题 | 发言条数 | 参与人数 | 发起者 | 最后发言者 | [隐藏]最后发言时间（UTC） |
|---|---|---|---|---|---|---|
| 1 | 修改Minecraft Wiki:管理制度（2） | 8 | 4 | Dianliang233 | Dianliang233 | 2024年2月5日 (一) 08:13 |
| 2 | 游戏档案文字格式 | 4 | 3 | Leo_leo_768 | AblazeVase69188 | 2024年2月11日 (日) 10:12 |
| 3 | 关于消歧义 | 6 | 3 | Wang31 | Wang31 | 2024年2月15日 (四) 15:40 |
| 4 | 建议将数据值中基岩版的名称使用基岩版译名 | 6 | 4 | Wilf233 | Wilf233 | 2024年2月17日 (六) 11:10 |
| 5 | 添加命令的格式指导 | 3 | 2 | Chixvv | Chixvv | 2024年2月28日 (三) 13:47 |
| 6 | 重命名原始JSON文本格式为文本组件格式 | 1 | 1 | Luoboju0 | Luoboju0 | 2024年3月2日 (六) 01:14 |
| 7 | 增修格式指导 | 6 | 3 | Leo_leo_768 | Leo_leo_768 | 2024年3月6日 (三) 10:19 |
| 8 | 关于“附魔”的定义以及有关附魔的一系列页面的问题 | 17 | 7 | MCluoluo | Leo_leo_768 | 2024年3月9日 (六) 12:55 |
| 9 | 关于物品生产类教程名称的问题 | 2 | 2 | Computerb | MysticNebula70 | 2024年3月13日 (三) 02:04 |
| 10 | 新增DiscussionTools扩展 | 2 | 2 | MysticNebula70 | KaplanSteve | 2024年3月13日 (三) 07:46 |
话题
修改Minecraft Wiki:管理制度（2）
为了在很长时间内实际对管理制度的执行方法修订成文的基础上，进一步夯实近期wiki民主化的成果，我再次提议修改Minecraft Wiki:管理制度。
- 原则
- 明确确定权限由共识产生。
- 保留一定的行政员的灵活决定权。
- 大致更改内容
- 微调了部分岗位的要求。
- 明确了每个用户组的授权共识形成过程。
- 为了反应这一更改，权限申请现在在社区专页进行。
- 明确了除权过程和弹劾过程。
- 为了更直观地体现条例内容，更改了标题。
- 草案
-- 
Dianliang233 T•C 2023年11月15日 (三) 10:00 (UTC)
- 我认为巡查豁免者门槛过低，建议参考User:Anterdc99/Archives/巡查豁免管理办法。巡查豁免者是否要修改成允许申请制可能仍需要讨论。--
Wilf233 2023年11月15日 (三) 10:23 (UTC)
- 巡查豁免者的权限时限分级是否太多？一天及七天的设计对于十分活跃的巡查豁免者是否有些过于麻烦？建议参考巡查员与管理员的任期制度适当削减任期分级数量？--Computer Li（留言）2023年11月15日 (三) 19:03(UTC)
- 巡查豁免者的权限时限分级是针对可能出现的短时间内做出大量编辑而言的。对于十分活跃的巡查豁免者，给予一个月或以上即可。--AblazeVase69188（讨论 | 贡献） 2023年11月18日 (六) 06:20 (UTC)
- 首先感谢你给予行政员更大的权利。关于巡查豁免的给予和剥夺，这个管理层内部也是有讨论过的，不过现在仍然没有定论。我的意见是巡查豁免并无封禁用户等高级权限，它本质上还是普通用户组的一个分支，一般不应该通过申请以获得。--Lxazl5770zh.admin（论 ▪ 功） 2023年11月19日 (日) 15:00 (UTC)
- 我认为持续时限为一个月及以上的巡查豁免权限不应当通过申请获得；但是持续时限较短的巡查豁免权限，如果申请者确有需要，可以开放申请。--AblazeVase69188（讨论 | 贡献） 2023年11月26日 (日) 10:07 (UTC)
- 现在对提案进行了修订，主要增加了界面管理员的任免过程，调整了申请巡查豁免员的条例（现在只有七天内的短期巡查豁免开放申请），请各位参阅。-- GIM Dianliang233 T C 2023年12月3日 (日) 09:26 (UTC)
- 1. 管理员、巡查豁免者等用户组的申请条件包括“××天内没有被拒绝的××申请（在先前申请讨论中行政员予以豁免的除外）”，但是巡查员的申请条件没有这一条，不知道是不是遗漏了。
- 2. 只有行政员拥有“赋予或撤销用户权限”的职责，但是巡查豁免权限的授予、续期和剥夺更多是由管理员进行，可能需要在管理员的职责一段加上“赋予或撤销巡查豁免权限”。
- 3. 机器人一段可能还需要补充一些内容，例如“机器人出现异常行为时可以立即封禁”。--AblazeVase69188（讨论 | 贡献） 2023年12月16日 (六) 11:15 (UTC)
- 除3以外基本同意，已修改草案。-- GIM Dianliang233 T C 2024年2月5日 (一) 08:13 (UTC)
- 除3以外基本同意，已修改草案。--
游戏档案文字格式
以下几点问题讨论：
- 文中提到文件名称时，应用“filename.abc”、“
filename.abc”、“filename.abc”、“filename.abc”中的哪一个？ - 文中提到文件路径时，应用“path/filename.abc”、“
path/filename.abc”、“path/filename.abc”、“path/filename.abc”中的哪一个？ - 介绍固定名称文件的条目标题，应用“filename.abc”、“filename.abc格式”、“<文件用途>格式”、“<文件用途>文件格式”中的哪一个？
- 承上，非固定或共处于同一文件夹内的文件呢？
目前wiki中极不统一，以上提到的都现有使用，希望在格式指导中作统一规范。--
Leo_leo_768（Talk｜Contributions） 2024年1月20日 (六) 09:44 (UTC)
- 我觉得用code标签比较美观和醒目 Geticer（留言） 2024年1月23日 (二) 07:56 (UTC)
- 我支持文中文件都用<samp>，文句中一大堆白色框框影响流畅阅读。固定文件标题我支持统一为单纯的文件名，非固定为“<文件用途>格式”--
Leo_leo_768（Talk｜Contributions） 2024年1月27日 (六) 09:33 (UTC) - 支持文件和文件夹名称使用</samp>，而文件路径使用</code>。这是因为文中通常不会列举一大堆文件路径，如果要列举的话用无序列表比一大堆白色方框堆在一起会更好；文件和文件夹就使用samp标签，避免列举时一大堆白色方框堆在一起。
- 我觉得介绍固定名称文件的条目标题用“filename.abc”更好，符合读者想要查找内容时直接输入文件名称的直觉，而且这些页面也不只是介绍格式，还要介绍其功能、历史等内容。--AblazeVase69188（讨论 | 贡献） 2024年2月11日 (日) 10:12 (UTC)
关于消歧义
最近关注到了有关消歧义的讨论，也发现了一些问题。
例如猪排，人们肯定不会将生猪排和熟猪排混淆，提到猪排更可能指的是宽泛的两者；再如下界合金，可能只是宽泛地指代这种“材质（或品质）”，而不是在这些物品中存在歧义。
问题在于，究竟应该如何改进。个人认为应该将许多消歧义页面改为同类索引和宽泛概念条目，尤其是前者。另外，一些消歧义页可以保留，如?；一些消歧义页需要删减内容，如Minecraft（消歧义）应删去#版本。
当前，消歧义的滥用问题似乎十分严重，而改进起来也是不小的事情，希望能有一种好的办法。
另外附上一些参考内容：维基百科:消歧义、维基百科:同类索引条目、维基百科:宽泛概念条目；还有过去的一些讨论：Minecraft_Wiki:社区专页/存档6#关于消歧义条目的编辑规范及同类索引条目的引入、Minecraft_Wiki:社区专页/存档7#关于同类索引条目的规范。
表述可能不太清楚，敬请谅解。--古怪的Wang31（讨论 | 贡献） 2024年2月14日 (三) 12:55 (UTC)
- 我个人认为消歧义页面（模板·分类）和同类索引页面（模板·分类）应为部分易混淆概念的列举，前者为名称类似，后者为用途类似，都不应在内容页面的正文中有链接指向它们。
- 对于正文中表示一类物品的链接，全部展开可能会占篇幅，所以可以在每个页面首次出现（或适合展开）的地方展开，下文不再展开，用链接链向本页面的章节。例如：
- 同时，可以在Template:For、Template:About及参见段落中提供指向消歧义页面或同类索引页面的链接。这样就可以在正文中避免出现此类链接。（抱歉可能有点啰嗦）--Hos_Soh<T> 2024年2月15日 (四) 02:55 (UTC)
- 这样似乎是最合理的，但显然也太繁琐、冗长。这或许也就是问题所在：究竟该以怎样的方式指代一类物品？或者，该设立一种怎样的页面，能够涵盖这样的一类物品，并且能够在条目中链入？--古怪的Wang31（讨论 | 贡献） 2024年2月15日 (四) 15:40 (UTC)
- 这类页面的一个用途是检测条目直接链接到下界合金的情况，因为游戏中实际上没有叫做这个名称的东西。编者就可以通过检查这个页面的链入来改正链入到正确的地方。--siiftun1857[T/C/E] 2024年2月15日 (四) 04:27 (UTC)
- 说得对，这些页面是消歧义页，也就意味着原则上不应有链入页面。那么问题就变成了，究竟该让这些页面变成非消歧义页而允许链入，还是创造一个“正确的地方”作为替代（据我观察目前似乎没有一个合适的位置）。--古怪的Wang31（讨论 | 贡献） 2024年2月15日 (四) 15:40 (UTC)
- 经过我的思考，我认为消歧义页和同类索引条目或许都不太合适，因为它们原则上并不应该有链入页面。或许如Hos_Soh所言，我们可以考虑设立一种“归类”页面，将有一定共性的内容（条目）列在其中，并且允许其他条目的链入（例如一个包含所有下界合金制工具的条目）。这个想法与同类索引条目和宽泛概念条目有些类似，但不完全相同，想听听各位的意见。（我的想法似乎特别混乱，见谅）--古怪的Wang31（讨论 | 贡献） 2024年2月15日 (四) 15:40 (UTC)
建议将数据值中基岩版的名称使用基岩版译名
如题，建议用displayname参数覆盖原有标准译名，使用基岩版译名，理由如下：
- 当一个Java版译名对应多个基岩版译名时，不至于混淆。
- 可解决Java版和基岩版对应的英文本身不同，造成的译名不同问题。
- 对其他正文内容并没有造成影响，并且更真实地反映了游戏内名称，达到了写数据值条目本身的目的，避免了跳转查询基岩版译名的过程。
- 示例1：
改动前：
| 实体 | 命名空间ID | 本地化键名 |
|---|---|---|
 掷出的末影珍珠 | ender_pearl | entity.ender_pearl.name |
改动后：
| 实体 | 命名空间ID | 本地化键名 |
|---|---|---|
| 末影珍珠 | ender_pearl | entity.ender_pearl.name |
| Java版译名 | 掷出的末影珍珠 |
| Java版英文游戏名 | Thrown Ender Pearl |
| Java版命名空间ID | ender_pearl |
| 基岩版译名 | 末影珍珠 |
| 基岩版英文游戏名 | Ender Pearl |
| 基岩版命名空间ID | ender_pearl |
- 示例2：
改动前：
| 名称 | 命名空间ID | 本地化键名 |
|---|---|---|
 僵尸村民（旧版） | zombie_villager | entity.zombie_villager.name |
| 僵尸村民 | zombie_villager_v2 | entity.zombie_villager_v2.name |
改动后：
| 名称 | 命名空间ID | 本地化键名 |
|---|---|---|
| 怪人村民（旧版） | zombie_villager | entity.zombie_villager.name |
| 怪人村民 | zombie_villager_v2 | entity.zombie_villager_v2.name |
--
Wilf233zhMCW（论·功） 2024年2月15日 (四) 12:41 (UTC)
- 支持．--
Ilya_Yezerovsky（论•功） 2024年2月16日 (五) 10:47 (UTC) - 我个人比较 反对在这里使用基翻译名。
- 并在此提出几个有必要先去回答的问题：
- 1.难道目前Java版的ID table使用的displayname都是游戏内名称吗？显然很多都不是，不少是编者随意起的名称，有的也是根据需求写的。比如水和流动水，再比如墙上的旗帜在游戏内的名称其实都没有“墙上的”三字，再比如各种音乐唱片、旗帜图案在游戏内的显示名称都一样。这些是否有必要统一改成游戏内名称？我认为必须先解决此问题才能讨论基岩版ID table是否使用游戏内名称。
- 2.游戏内根本没有显示名称的怎么办？比如BE中所有的木门方块（木门物品才有显示名称）。
- 3.如果游戏内的名称明显存在错误的怎么办？如BE的双层诡异木台阶和双层绯红木台阶的名称缺失了“双层”二字，其他双层台阶（如双层樱花木台阶）则有“双层”二字。
- 4.依靠方块状态决定名称的方块怎么办？如stone_block_slab2、red_flower、colored_torch_bp，它们本身不存在任何名称，它们的各个方块状态才拥有名称。
- 5.忘了。--Chixvv（留言） 2024年2月16日 (五) 12:58 (UTC)
- 这样观感有点差，如果读者浏览页面时突然出现"基翻"，可能会使读者疑惑。--1400kl（留言） 2024年2月16日 (五) 13:21 (UTC)
- 支持但应注明是基岩版译名．-- Ilya_Yezerovsky（论•功） 2024年2月17日 (六) 10:09 (UTC)
小结：根据本章节讨论和群内的意见，多数人 反对全部使用基岩版译名。因此，我建议下列一种情况使用基岩版译名：
- 英文与Java版不同，基岩版译名是与其英文对应的、合适的中文，但标准译名与英文并不对应，可能造成混淆的情况。例如：掷出的末影珍珠、掷出的鸡蛋等。
同时，我尽量不对现有数据值做出太多改变，除非上述情况提及。请在下方发表建议。--Wilf233zhMCW（论·功） 2024年2月17日 (六) 11:10 (UTC)
添加命令的格式指导
目前Wiki内命令条目的编写较为混乱，需要有一个明确的格式指导用于指导编写。
目前在沙盒内有一份关于命令的格式指导草案，如果没有问题希望可以添加到格式指导中。
--Chixvv（留言） 2024年2月21日 (三) 17:21 (UTC)
- 意见：把命令的效果放在“用法”章节可能会让读者困惑。在en:Commands/return页面中，“Usage”章节的大部分内容在描述命令的具体效果，似乎已经脱离了“用法”的含义。个人认为，需要的时候再开一个“效果”章节会合适一些。--Yzy32767-T/C- 2024年2月22日 (四) 01:04 (UTC)
- 个人认为en:Commands/return的usage章节依旧是在描述就是命令可以在什么场合使用、可以用来干什么，也就是“用法”。效果和用法往往很难区分，并且大多数情况下内容不多，没必要两个章节。若能提出区分用法和效果的标准，则可以考虑增加一个“效果”章节。-Chixvv（留言） 2024年2月28日 (三) 13:47 (UTC)
重命名原始JSON文本格式为文本组件格式
原始JSON文本格式的标题所达之意过于宽泛，其实际页面内容主要是介绍Text Component的格式。关于到底是Chat Component还是Text Component，从官方日志来看，1.13之后的日志写为Chat Component，之前为Text Component。从游戏内翻译来看，为"聊天组件"。但聊天组件这个翻译对其实际应用存在混淆和概括不全，故理应称为"文本组件"。--Luoboju0（留言） 2024年3月2日 (六) 01:14 (UTC)
增修格式指导
为避免造成读者困惑，并确保所有玩家都能轻易的在wiki上找到目标资讯，兹提议格式指导增修如下 :
- 条目标题
此外，条目的标题必须能直接链接至该条目。
- 为达成此目的，对任二相异条目，所有变体之显示标题均不可重复。
- 条目所有的显示标题若非条目之原始标题，且不能由系统自动重定向至该条目，则必须手动创建重定向页。
需尽量避免不同条目的标题撞名，若在所不免的发生标题冲突，一般应依循下列办法解决：
- 若皆为消歧义，应予以合并。
- 若二者之一为消歧义，由消歧义让出标题。若可行，应直接在另一个条目顶注附上消歧义内容，否则消歧义应改名加上“（消歧义）”，并于另一个条目注明消歧义链接。
- 否则，为各冲突之标题分别加上括号附注，并在各条目顶注加入其余条目或消岐义之链接。再于原条目名处建立消岐义。
- 倘若其中存在关注度显着较高者，得不另建消岐义，改为直接重定向至该条目。但不同语言变体之间无从比较关注度。
- 游戏特性名至集合页面的重定向若发生冲突，比照标题办理，惟无须再建立具括号之重定向。
若未发生以上情况，标题不必加括号。
以上提案，是否有当？敬请公决。-- Leo_leo_768（Talk｜Contributions） 2024年3月5日 (二) 14:27 (UTC)（最后编辑于2024年3月6日 (三) 08:09 (UTC)）
- 更新：再次调整表述方法，改了几个错字--
Leo_leo_768（Talk｜Contributions） 2024年3月6日 (三) 04:15 (UTC)（最后编辑于2024年3月6日 (三) 08:09 (UTC)） - 关于因为太过于公文化导致我看不懂想表达什么的这件事--Lxazl5770zh.admin（论 ▪ 功） 2024年3月6日 (三) 08:03 (UTC)
- 建议修改表述以符合现代汉语习惯。--Wilf233zhMCW（论·功） 2024年3月6日 (三) 08:07 (UTC)
- 已修改表述基本符合现代汉语习惯，但并不代表本人支持或反对该意见，意见会在下方提出。
- 条目标题
此外，条目的标题必须能直接链接至该条目。
- 也就是说，对于两个不同的条目，所有中文变体的显示标题不得重复。
- 条目所有的显示标题如果不是条目的原始标题，且不能由系统自动重定向至该条目，则必须手动创建重定向页。
因而需尽量避免不同条目的标题撞名。如果冲突避无所避，一般应遵循下列方法来解决：
- 若皆是消歧义页，应予以合并。
- 若二者之一是消歧义页，则由消歧义页让出标题。若可行，应直接在另一个条目的顶注附上消歧义内容，否则消歧义应改名于末尾加上“（消歧义）”，并在另一个条目中注明消歧义链接。
- 否则，为各冲突的标题分别加上括号附注，并在各条目的顶注加入其余条目或消岐义的链接。再于原条目名处建立消岐义。
- 如果其中存在关注度显著较高者，可不另建消岐义，直接重定向至该条目。但不同语言变体之间无从比较关注度。
- 游戏特性名至集合页面的重定向若发生冲突，比照标题办理，但无需再建立带有括号的重定向。
若未发生以上情况，则标题不必添加括号。
--Wilf233zhMCW（论·功） 2024年3月6日 (三) 09:11 (UTC)
- 恕我直接修改阁下的文字以符合提案原意，更改内容参见此编辑-- Leo_leo_768（Talk｜Contributions） 2024年3月6日 (三) 10:19 (UTC)（最后编辑于2024年3月6日 (三) 12:32 (UTC)）
关于“附魔”的定义以及有关附魔的一系列页面的问题
“附魔”应当如何定义，Wiki上的附魔页面应该怎么办？
关于附魔的定义有以下观点：
- 附魔是向物品添加魔咒的行为
- 附魔是“附魔台+战利品+生物天然装备”使用的名为“附魔”的系统
- 附魔是包含添加魔咒、魔咒生效在内所有与“附魔”有关的统称
- 将物品从没有魔咒转化为有魔咒的过程
附魔页面的处理方式有以下观点：
欢迎补充 ——MCluoluo（留言） 2024年3月6日 (三) 10:33 (UTC)
- 关于有关附魔的页面存在以下争议：玩家社区似乎普遍把“魔咒”称作附魔，是否应该按照玩家社区的习惯将魔咒移动到附魔 ——MCluoluo（留言） 2024年3月6日 (三) 10:36 (UTC)
- 我认为wiki中enchantment被称为“魔咒”而不是“附魔”，是译名标准化的问题，曾已达成共识的，与本次争议无关。--Chixvv（留言） 2024年3月6日 (三) 11:13 (UTC)
- 先说一下我的观点，附魔台、战利品表等确实共用了一个随机选择魔咒的机制，对应代码中的selectEnchantment（JE)和selectEnchantments (BE)。此机制在给物品添加魔咒前调用。我认为此机制不管叫什么也不能叫做“附魔”，它只是在给物品添加魔咒之前的一个机制。我提出“随机选择魔咒”甚至“随机附魔”可以作为该机制的名称。没有任何证据表明这个随机选择的机制应该叫两个字“附魔”，也没有任何理由将其命名为“附魔”。
- 至于“附魔”一词如何定义，我认为该词只能按照汉语本身的表意，将其解释为“附有魔咒”或“附上魔咒”。我相信几乎任何一个中文母语者，都不会区分或者同意区分“附魔”与“(让物品)附上魔咒”或“附有魔咒(的物品)”。几乎任何一个英语母语者，都不会区分或者同意区分“enchanting”与“adding enchantments (on an item)”或“enchanted (items)”。因此我认为，对“附魔”一词进行任何强行的狭义定义都是不可行的，是违反语言规律的，即使花大量篇幅去进行狭义的定义，也是不能为玩家所理解的。
- 至于“附魔”页面如何处理，只要selectEnchantment机制不独占“附魔”页面，我都能接受。但必须先考虑上方的#增修格式指导话题，合理处理语言变体的问题。--Chixvv（留言） 2024年3月6日 (三) 11:13 (UTC)
- 恕我重新整理讨论议题：
- 对目前位于附魔机制的页面所描述之游戏机制“一种为不具有附魔的物品随机生成附魔的方式，由附魔台、生物天然装备、战利品表所使用”，名称当是如何？
- “附魔”一词的定义为何？用于称呼该机制是否适当？
- 是否有其他词汇可用于称呼该机制？用其他词汇是否妥当？
- 条目应写/放在哪个页面？
- 对目前位于附魔机制中附魔台机制一节的内容是否属于1.提到的机制？
- 是否需拆分出去独立条目？
- 是否影响1.的名称？
- 是否也把其他内容拆走？或部分归到魔咒页？
- 附魔一词与标题“附魔”日后在本wiki的处置？
- 标题给重定向魔咒？消歧义？还是重定向给1.、作1.的条目名？
- 简繁转换造成的影响？反之？
- 其他条目中是否还能提到“附魔”，连结到“附魔”？
- 对目前位于附魔机制的页面所描述之游戏机制“一种为不具有附魔的物品随机生成附魔的方式，由附魔台、生物天然装备、战利品表所使用”，名称当是如何？
- -- Leo_leo_768（Talk｜Contributions） 2024年3月6日 (三) 11:22 (UTC)（最后编辑于2024年3月6日 (三) 12:14 (UTC)）
- 回应一下2。附魔台调用selectEchantment机制，仅仅是生成了3个选项以供玩家选择，还没有把魔咒添加到物品上。而这三个选项有什么规律和效果（摆书架、三个等级公式、添加了魔咒并消耗了青金石和经验等等一堆内容）显然是附魔台独有的另外的机制，而绝非和战利品表共用的selectEchantment机制。目前“附魔机制”页面开头说是共用的机制，但摆书架和三个选项公式却占了很大篇幅，显然这些根本不是和战利品表通用的机制，不是条目开头所概括的内容。我认为不能强行把附魔台独有的机制描述概括为selectEchantment机制的一部分，selectEchantment机制和附魔台机制应该拆为两个页面。--Chixvv（留言） 2024年3月6日 (三) 12:20 (UTC)（最后编辑于2024年3月6日 (三) 12:30 (UTC)）
- 有关附魔和附魔机制的现状，当前最需要解决的核心问题有且只要一个：“附魔”一词的定义是否为当前“附魔机制”所述内容？这决定了是否要将附魔机制移动到附魔。这是一个选项仅有“是”和“否”的问题。在该问题得到解决前，任何其他问题都没有意义：
- 因此可以认为，将该话题从““附魔”一词的定义是否为当前“附魔机制”所述内容？”这一核心问题引开到其他问题上的表述都是非常不负责任的虚构现实的行为。唯有这一核心问题得到解决，其他假定核心问题的结果而提出的问题才有意义。--siiftun1857[T/C/E] 2024年3月6日 (三) 14:27 (UTC)
- 另外需要注意，当前附魔页面的链入状况：
- 可见，若附魔机制的内容不在附魔页面中，那么任何页面的任何内容都无法合理地链入到附魔，导致该页面的链入被清空。若“附魔”的作为这种魔咒生成方式的定义被确定不可接受，这将会是中文MCW中“附魔”一词的使用的终结。--siiftun1857[T/C/E] 2024年3月6日 (三) 14:41 (UTC)
- 这一条留言中的“附魔”均指当前“附魔机制”页面所述内容，即“附魔台+战利品+生物天然装备”的“附魔”：
- 附魔有明确的定义，专指一种有明确流程和行为的游戏内容：
- 附魔操作的输入是一个没有魔咒且有附魔能力的物品，和一个指定的附魔等级。
- 魔咒的基本属性“修正附魔等级”和“稀有度”专门用于参与附魔过程。
- 附魔会随机选择魔咒，最后输出一份魔咒及其等级的列表——这一列表是否在附魔计算完成时就已经应用到物品上并不是附魔的定义的一部分。
- 附魔的实现是一个客观的程序方法，该方法名即是“附魔”，因此将附魔定义为这一方法本身合情合理，这一简单的定义也给予了附魔非常清晰的良好定义。
- 基于这一定义，任何其他使用“附魔”的场景均是对附魔的误用和挪用，并且都有他们对应的合适表述，并不是一定要使用“附魔”一词：
- “物品上有附魔”应该为“物品上有魔咒”。
- “铁砧为物品附魔”应该为“铁砧为物品添加魔咒”。
- “enchant命令为物品附魔”应该为“enchant命令为物品添加魔咒”。
- 附魔有明确的定义，专指一种有明确流程和行为的游戏内容：
- 因此可以认为，提出当前“附魔机制”内容为“附魔”是正当且合理的，同时也不会导致任何其他挪用了“附魔”一词的表述在不使用“附魔”后无法表述。
另一方面，中文MCW当前的所有“附魔”一词的使用，除了表达“魔咒”“铁砧操作”甚至“经验”的挪用外，剩下的“附魔”均是在表达当前“附魔机制”页面所述的“附魔”，因此将其置于“附魔”页面中，在这方面并无任何不妥。--siiftun1857[T/C/E] 2024年3月6日 (三) 15:12 (UTC) - 以下内容是对Chixvv的反驳：
- Chixvv的全文的多数观点都可以被这些论点本身换一个词就击破自己：
- 我相信几乎任何一个oo母语者，都不会区分或者同意区分oo：这句话我也可以说“我相信几乎任何一个中文母语者，都不会无法区分附魔和添加魔咒”，并且这种“我相信几乎任何一个oo都不会oo”表述是非常傲慢的，直接将异见者排除在“oo母语者”的群体之外，这是在要挟谁的意见？
- 因此我认为，对“附魔”一词进行任何强行的狭义定义都是不可行的，是违反语言规律的，即使花大量篇幅去进行狭义的定义，也是不能为玩家所理解的。：直接指定当前附魔定义是“强行”的和“狭义”的，那这句话自己何尝不是一种对“附魔”强行和狭义定义，甚至还是模糊的不良好定义？我也可以说“因此我认为，对“附魔”一词进行任何强行的不良好定义都是不可行的，是违反客观规律的，即使花大量篇幅去进行强行的定义，也是不能为玩家所理解的。”
- 至于“附魔”一词如何定义，我认为该词只能按照汉语本身的表意，将其解释为“附有魔咒”或“附上魔咒”。：我是否可以说该词语应当按照其“客观实现的本意”，将“附魔”解释为当前“附魔机制”的内容？我也按照汉语的表意理解，但并没有解读出你所说的狭隘含义。
- 至于“附魔”页面如何处理，只要selectEnchantment机制不独占“附魔”页面，我都能接受。：这一句就仅仅只是“什么能接受”的表述，那么我的回应也可以是“只要selectEnchantment机制不独占“附魔”页面，我就不能接受。”
- 以及在即时通讯群聊中，还有以下的言论：
- 这是你自己妄想出来的争议，我们两个都在从不同角度反对叫“附魔”，你是一句话也没听：我认为大可不必如此攻击。因为我没有认同你的说法，就应当被叫做“你自己妄想出来的争议”和“一句话都没听”吗？并且有不止一人表示了为何“附魔机制”的内容是“附魔”，说明了为何你的观点会被反对，以及附魔不是附魔对wiki内容有什么后果，而你也没有表现出任何有接受，那么你的这句“你是一句话也没听”是不是也可以用在你自己身上？
- 关于附魔的定义的论述问题：
- 我认为此机制不管叫什么也不能叫做“附魔”，它只是在给物品添加魔咒之前的一个机制。我提出“随机选择魔咒”甚至“随机附魔”可以作为该机制的名称。没有任何证据表明这个随机选择的机制应该叫两个字“附魔”，也没有任何理由将其命名为“附魔”。：随机选择完了之后就是可以添加魔咒的状态，这并没有任何问题。并非“没有任何证据表明这个随机选择的机制应该叫两个字“附魔””——游戏实现已经揭示了这个机制叫做“附魔”，并且“附魔台”也叫做“附魔台”，交互界面标题也叫做“附魔”。同时也并非“也没有任何理由将其命名为“附魔””，是你在有意忽略已经提出的诸多理由，如当前中文MCW所有的“附魔”一词，除了指“魔咒”“铁砧操作”和“经验”的挪用情况，剩下的所有“附魔”几乎全都是指这个“附魔”。
- 附魔台调用selectEchantment机制，仅仅是生成了3个选项以供玩家选择，还没有把魔咒添加到物品上。附魔方法的主要部分就是生成魔咒，从而允许接收到魔咒列表的方法处理他们。将其理解为仅是“把魔咒添加到物品上”是狭隘的。
- 而这三个选项有什么规律和效果（摆书架、三个等级公式、添加了魔咒并消耗了青金石和经验等等一堆内容）显然是附魔台独有的另外的机制，而绝非和战利品表共用的selectEchantment机制。，目前“附魔机制”页面开头说是共用的机制，但摆书架和三个选项公式却占了很大篇幅，显然这些根本不是和战利品表通用的机制，不是条目开头所概括的内容。：直接告诉你答案，他们就是共用的，调用的是完全相同的方法。附魔台有且只有一个功能：进行附魔。附魔内容中的附魔台段落表述的是附魔台如何生成附魔等级，以及每个选项的条件和使用附魔选项的花费，点完就执行附魔，这些都和附魔有强关联性，并且读者会预期在同一个条目看到附魔台的行为和附魔台进行的附魔是如何运作的。
- 我认为不能强行把附魔台独有的机制描述概括为selectEchantment机制的一部分，selectEchantment机制和附魔台机制应该拆为两个页面。：请不要强行将一个内容说成是强行的。上一条解释了附魔台的行为为什么放在这里，读者预期附魔台的内容会在附魔内容中，将其移出附魔内容是违背关注度的，并且导致读者要在两个不同的页面来查找附魔台附魔的内容。这并不合理。
- 另外还有一点补充:
- 但必须先考虑上方的#增修格式指导话题，合理处理语言变体的问题。：如何“合理处理语言变体的问题”与这个话题毫无关系，这是没有内容归属争议的条目才需要做的事情，并且通常可以直接简易程序完成，实在是没有看出来这为何是“但必须先考虑”。
- Chixvv的全文的多数观点都可以被这些论点本身换一个词就击破自己：
- 因此可以认为这些论述都是没有道理的无效论述，并不能支持将“附魔机制”内容认定为不是“附魔”的做法。--siiftun1857[T/C/E] 2024年3月6日 (三) 16:05 (UTC)
- 我已说过，你所说的这个游戏机制在代码中的方法名在JE和BE中分别是“selectEnchantment”和“selectEnchantments”，而绝非你所谓的“附魔”。恰恰相反，代码中名为“enchant”的方法或名中带有“enchant”的方法有多个，都是将魔咒应用到物品上的过程，如/enchant命令直接调用ItemStack::enchant方法。您所谓的“该方法名即是‘附魔’”从何而来？你给出的这个定义是没有任何事实依据的，因此任何基于这个定义的推论都站不住脚。我相信mojang起名再怎么灾难，也不会把“选择魔咒，最后输出一份魔咒及其等级的列表”的方法命名为enchant。--Chixvv（留言） 2024年3月6日 (三) 15:31 (UTC)
- 即使按照你的定义来说，你最后的观点“除了表达魔咒铁砧操作甚至经验的挪用外，剩附魔均是在表达当前附魔机制页面”也显然并非如此。“附魔”一词在本wiki中应用广泛，如“附魔工具”、“附了魔的物品”等，均是在表达“附有魔咒/附上魔咒”的含义。我认为只要不将这个机制强行称为附魔，“附魔”页面在清除链入后，“附魔”一词完全可以沿用“附上/附有魔咒”的含义，不会有任何歧义。“附魔”页面的终结是理所应当的，而绝非什么严重的问题。
- 你认为“是否拆分附魔机制的问题假定了当前附魔机制页面所述内容已经被认定为并非附魔”，我并不这么认为，我认为不管该机制名称如何，都应该拆分，因为附魔台独有的那些机制显然不是“附魔台+战利品+生物天然装备”共有机制的一部分。--Chixvv（留言） 2024年3月6日 (三) 15:49 (UTC)（最后编辑于2024年3月6日 (三) 15:54 (UTC)）
- 我存在态度的极端化与情绪过激的问题，在此向你道歉。所以还是回到争议的核心问题。我认为该机制不能名为“附魔”。你对此唯一的论据是代码中的方法。然而事实确是代码中的生成魔咒的方法名为selectEnchantment(s)而非“附魔”。而“附魔台”叫做“附魔台”、交互界面标题叫做“附魔”，无法支撑你把生成魔咒的机制称为附魔的观点，它们之所以叫附魔，是因为能够使物品附有魔咒，而非使用了selectEnchantment机制。对于其他的我不认同的观点，我不再想逐句反对。--Chixvv（留言） 2024年3月6日 (三) 16:16 (UTC)（最后编辑于2024年3月6日 (三) 16:22 (UTC)）
- 我认为附魔的歧义来自于附这个字。它作为动词时指代将一个物品加上魔咒，包括使用铁砧和附魔台，比如“给钻石剑附魔”这句话中就是一个动词。而作为名词时，它指的实际是一个物品附属的魔咒，比如“那把钻石剑的附魔很好”。除此之外，它还可以是形容词，代表一个物品拥有魔咒，比如“附魔书、附魔的钻石剑”。而这些刚好是消歧义界面的内容所要消的歧义，因此我认为保留目前的原状即可。Creependerman（留言） 2024年3月9日 (六) 04:49 (UTC)
- 我认为“enchant”应当翻译为“附魔”（动词），“enchantment”应当翻译为“魔咒”（名词）。-- Ilya_Yezerovsky（论•功） 2024年3月9日 (六) 09:21 (UTC)
- 说一下我自己的拙见。我认为，附魔只可以做动词。“enchantment”就是魔咒，把它称作为附魔纯属是和岩浆、材质包一样的错译，这些错译的影响，想必大家都知道。而附魔的机制，我认为应该区分铁砧机制和附魔台机制。附魔机制应是这两种机制的统称。现在主要需要讨论的是，附魔（没有任何前缀）到底指的是狭义附魔（只指使用附魔台附魔）还是广义附魔（一切可以给予物品魔咒的方式）？Computerb（留言） 2024年3月9日 (六) 09:56 (UTC)
- 系争机制：采Special:diff/873550所述“附魔有明确的定义，专指一种有明确流程和行为的游戏内容：”之定义，输入物品与等级，输出乃魔咒清单。
- 系争页面：专指下笔时目前暂时名为“附魔机制”的条目页面。
- 附魔、enchant：用于指该词本身，不自然带任何定义。
“
因此可以认为，将该话题从““附魔”一词的定义是否为当前“附魔机制”所述内容？”这一核心……（恕删）……假定核心问题的结果而提出的问题才有意义。
“是否拆分附魔机制”的问题假定了目前“附魔机制”页面所述内容已经被认定为并非“附魔”，但这一点目前并没有结论。
“日后如何处理附魔页面”的问题假定了“附魔机制”目前已被认定为不移动到“附魔”，但这一点目前同样没有结论。
”
——Siiftun1857
首先在下 不同意此说法，敝人提出的问题二在于厘清阁下这句所谓“‘附魔机制’所述内容”是什么？连取名的目标都理不清，如何继续讨论？根据目前现况，系争页面包含“系争机制”与“有提到附魔台如何使用系争机制的附魔台机制”，此又与阁下所述不同。更明确地说，若从编写条目的角度认为目前系争页面里内容组合方式并不妥当，应并入或分出部分内容，影响条目整体性质，则系争页面移动问题的根基将大为改变，故同时并列。 再者，把系争机制命名为附魔不当然等于把系争页面移到附魔，此为相关但相异的两个问题，而在下对这两个问题的态度也有所不同。阁下声称我“假定不该把系争页面移动至附魔”，但事实恰恰相反，同时考虑我提出的三个讨论问题才能共同决定“如何处置系争页面”，是你假定了“系争机制命名为附魔可以直接推得系争页面应移动到附魔”，但这一点目前并没有共识。另外恕我直言，全然不管不顾前提或后果就作决定，才是真正“不负责任的行为”。
“
任何其他使用“附魔”的场景均是对附魔的误用和挪用
”
——Siiftun1857
此句可能隐含了一个谬误，对于用附魔指代给物品加上魔咒的操作或指具有魔咒之物品，不是其他页面错误的挪用了附魔一词，而是阁下今天打算修改附魔的定义。若修改了，将导致其他页面必须更改原本正确但将来错误的表述，并非其他页面长期以来的误用。
“
中文MCW目前的所有“附魔”一词的使用，除了……均是在表达目前“附魔机制”页面所述的“附魔”
”
——Siiftun1857
此句具有严重的事实错误，wiki对附魔的使用除可直接代换为魔咒者外，有大量皆是指“附有魔咒”或“附上魔咒”，而这并非也不能换成系争机制，详细会再论述。反而，指系争机制的不能说没有，但是极少数。此外需注意依阁下提出之定义，“在附魔台上附魔了的剑”也是“错误挪用”，详细在下文一并说明。
以下先就我提出的三个讨论问题的第一题作意见发表。
我 反对将系争机制命名为附魔，或将附魔定义为系争机制。
- 悖于官方：根据Mojang官网博文、更新日志等，显而易见官方的“Enchant(ing)”是指广泛的给物品加上魔咒，而非系争机制。阁下不断提到想让内容贴近游戏源代码，如此做能有什么理由？可解释得通之理由无非“避免Mojang背刺”。那不照Mojang自己对外的官方定义，反而试图取Mojang常常乱取名且一键就可能改变的程式码中名称，不是反而与原始目的背道而驰，更容易发生意外吗？官方若再加入一个机制说它也是“Enchant(ing)”，还不是要再改名？若欲反驳说无需理会官方定义，wiki自有wiki规，那就别拿程式码中名称这种由官方写而可以随便改的，改了也不影响一丁点游戏表现的事物当论据。
- 悖于社区：请问倘若依阁下将附魔定义为系争机制，那“使用附魔台附魔将消耗一至三级经验”此句是否正确？按编辑纪录，容我擅自认定阁下的回答应为正确。然而，仔细检视系争机制，其定义并不包含消耗经验，消耗经验是附魔台机制的事，是附魔台机制会使用到系争机制。根据阁下的说法，附魔台机制仅仅是因为与系争机制高度相关，因关注度才将其放于系争页面。且若严格遵照系争机制，当物品放上附魔台时，其就已发生了系争机制，我想连阁下自己的直觉都会本能的抗拒“物品放上附魔台就发生附魔”这一陈述，但这是将附魔定义为系争机制推导出的必然结果。同样地，我发觉阁下在编辑修改掉至附魔的连结时，亦常“错误”地在附魔指“使用附魔台将魔咒添加到物品上”时当其指的是系争机制，或通过附魔一词将系争机制的输出误作具有魔咒之物品。倘若连阁下作为社区的一分子，自己的直觉都会使自身难以正确使用自己对附魔的新定义，何以期待其他人能正确使用，乃至接受、承认呢？
- 悖于中文：依siiftun1857君的叙述，系争机制仅仅是个为物品生成随机魔咒清单的机制，给物品加上魔咒并不是系争机制的一部分，亦与其无直接关连。但“附魔”二字由字面理解就是“附上魔咒”或“附有魔咒”，也是现行的普遍定义。想去稍微缩小或扩大定义并非全然不可，实务上也不是没有先例，但我不认同Chixvv君说阁下是“强行限缩附魔定义”，因为若严格照siiftun1857君陈述的系争机制来定义附魔，那这甚至不是限缩，而是造一个与“附魔”字面意义、原始定义全无交集的新定义。既然此新定义已与“附魔”的原意几乎毫无关联，那又何必占用与改义呢？用个新词岂不更准确、更佳？是故，若欲认定“Enchant”就是系争机制的正确英文名称，那将Enchant翻作附魔，以阁下的句式就是所谓“长期以来的错译”，当重新讨论译名。而非使用翻译时全无考虑系争机制，而是认定Enchant(ing/ed)为“附上（有）魔咒”才决出的附魔“错误”译名。综上，不论系争机制是否为Enchant，中文都不应也没有理由命名为附魔。
- 悖于英语：2024年，连/enchant都不是enchant了，连be enchanted都非be enchanted了，disenchant移除魔咒enchant却不加入魔咒，还有什么能信的？英语中搞这种区分，不合理，不现实，不可能。再说若将enchant限定为系争机制，请问阁下如何处理、如何翻译这些词汇？难不成阁下要指摘游戏中Enchanted Items泛指所有具魔咒之物品是错误用法？指摘游戏中/enchant是错误名称？还有以后翻译官方更新日志时，都还要注明一下官方用的wiki认为错误的表述？我也知道，很多人支持移动系争页面是出于译名标准化的缘故，想让众人不再将“魔咒”误称为“附魔”。但先不论定义不受世人所承认，降低wiki威信，更不利译名标准化。原文enchant就难以专指系争机制，附魔从翻译角度上附魔也不会是系争机制的良好翻译。
- 悖于历史：知道一个比游戏里源代码更底层的东西是什么吗？是游戏设计。附魔不是不透明度，不是先有一个机制在游戏中，我们将它称作附魔，然后看到另外一个就是觉得他跟附魔很像就跟他一起叫做附魔。是Mojang先觉得游戏中有需要为物品附上魔咒的机制，并叫它附魔。所以为此才创造了附魔台实现、才创造了附魔书与铁砧实现、所以才创造了系争机制实现，再为他们编写了源代码。仔细去看那些史料，这些游戏内容都是为了实现Mojang认为的“附魔”这一概念所创造的，怎么今天有其中一个东西，阁下自行认定它的名字占用了“附魔”二字，同样为“附魔”而建立的其他东西就全部必须退让整个概念给它？附魔一词的概念是先于系争机制，没有反向退让之理。
- 悖于现状：阁下在论述时，还常常提到所谓良好定义或不良好定义，俨然一副要把附魔当不透明度处理一般，可能阁下是修不透明度修到累瘫了才发出这种言论，但我认为如此大错特错。阁下声称将附魔定义为“给物品添加魔咒”是个会造成问题的不良定义，但却认为将现有使用的附魔一词替换为“给物品添加魔咒”是正确的作法，请问怎么前者不良后者良了？唯一可能的差别就是词法上的表达差异，但阁下都把系争机制定义为附魔了，词意字面上不是错更多吗？再来这都能所谓不良定义，但我们是不是也该清光“矿石”，因为源代码中找不到矿石的“良好定义”，我们也该清光“红石电路”，因为源代码中找不到红石电路的“良好定义”。若所有词汇都需要严格对应源代码的一个区段，那wiki上要改的可多了去的，我们要不改成源代码注释百科算了？这种严格对应不但难以执行，还极可能出错。
- 悖于游戏：恕我直说，请问源代码中的命名会影响但凡一咪咪游戏表现吗？请问今天不给混淆映射表会改变那怕一丁点原版游戏体验吗？我们Minecraft Wiki是在写程式码注释吗？玩家使用与源代码不同的名称称呼会对游玩造成任何改变吗？或者说做个思想实验，若我把混淆映射表中的enchant一词都改成所谓“他们对应的其他合适表述”，阁下会发现吗？会影响阁下对系争机制名称的坚持吗？那源代码中名称的重要性不及官方表述、语文逻辑、社区惯用、游戏文字任何之一的半根汗毛。我唯一看到阁下以游戏文字做论据，是声称“附魔台”的“附魔”支持了阁下的论点，然查其进度描述“用附魔台附魔一样物品”，结合游戏表现，无不揭示了附魔是按下按钮后魔咒附至物品上，而非附魔台执行系争机制为物品准备魔咒时就算“附魔”。游戏文字亦也表现铁砧为附魔，甚至/enchant指令本身的名字，及附魔可指“附有魔咒”等，怎么就选择无视了？
- 悖于源码：若是我上面如此强调源代码名称根本不重要，还要继续扯源代码中命名，那我只好用魔法打败魔法了。经查Java版官方混淆映射表，“系争机制在源代码中的实现就叫做附魔”与事实不符，Chixvv君也提到了，系争机制以阁下定义严格对应selectEnchantment。源代码唯一真正叫做“附魔（enchant）”的方法是ItemStack:enchant()，功能就是给物品加入魔咒，其输入魔咒不必然是系争机制的输出，该方法体现出Enchant“附上魔咒”之原定义，而非阁下的新定义。实际上，包含/enchant、一些生物生成时的额外固定附魔、创造模式物品栏的附魔书等亦有使用该方法。故我于前文用词为“试图照源代码中名称”，因为若事实上也照源代码名称与源代码逻辑，那也不应提出定义修改。综上，阁下表示添加魔咒至物品并非系争机制之一部分，此为正确，的确是由系争机制输出魔咒后再额外呼叫ItemStack:enchant()方法将魔咒添加至物品，但enchant之名属于后者，而非阁下声称的前者，切莫移花接木，捏造事实。严格遵照源码，系争机制依然不是附魔。
以上任何一点单独拿出，皆足以完全驳倒将系争机制命名为附魔，或将附魔定义为系争机制。
第二题我 赞成拆分系争页面，或将其主客颠倒。第三题我 不同意将附魔重新导向至系争页面， 支持重新导向至魔咒，论述皆之后再论。-- Leo_leo_768（Talk｜Contributions） 2024年3月9日 (六) 12:55 (UTC)
关于物品生产类教程名称的问题
以教程:铁轨复制机为例。 可以使用的名称如下 1、动宾短语（铁轨复制） 2、主谓短语（刷铁轨） 3、名词+机器名（铁轨农场） 4、主谓短语+机器名（刷铁轨机） 5、动宾短语+机器名（铁轨复制机）（即现在使用的）
究竟该使用哪一个？--Computerb（留言） 2024年3月12日 (二) 09:06 (UTC)
- 教程标题没有严格限制必须使用哪种，需要作区分的是合理使用游戏机制（刷xx、xx农场）和利用漏洞（xx复制）。MysticNebula70 T 2024年3月13日 (三) 02:04 (UTC)
新增DiscussionTools扩展
DiscussionTools是一个用于改进讨论页的扩展，提供了订阅讨论、自动添加签名、显示讨论串的发言人数和最新回复时间等功能，可以有效维护讨论的良好环境，同时避免一些低级错误。在此征集其他人关于是否添加此扩展的意见。另外，可参阅英文Wiki的讨论。MysticNebula70 T 2024年3月13日 (三) 07:40 (UTC)
- 同意，安装此扩展后能有效提高讨论页观感体验，并能阻止一些留言未签名的低级错误。--KaplanSteve T/C 2024年3月13日 (三) 07:46 (UTC)