Minecraft Wiki:格式指导

快捷方式

MCW:SG

MCW:STYLE

此条目旨在提供一份为所有Minecraft Wiki条目遵守的综合的格式指导。在选择使用哪些格式规则上经常会有争议，而一部官方的格式指导有希望帮助解决这些争议，同时也能帮助大家达成共识。

虽然维基百科已经提供了一份更通用的格式指导，但专用于Minecraft的特殊指导方针是有必要的。同理，只有专用于Minecraft Wiki的指导方针和其基本的格式规则才会被收录在这里。如果有任何冲突，本页面的优先级永远高于本页面的子页面和维基百科的格式手册。

关注度

快捷方式

MCW:关注度

只有符合以下准则的条目可以放在主名字空间。不符合准则的条目可能会未经通知即被删除或重定向。

常规

1. 条目必须包含足够的信息以支撑一个完整的条目。如果它们没有足够的内容，就会被合并到其他相应的条目。
2. 条目必须在某种程度上直接涉及Minecraft。
3. 关于人物的条目只允许此人物是Minecraft的开发者或与Mojang Studios相关。
4. 目前还不存在于游戏中的特性只能放入对应版本的提及特性条目。
   1. 这不包括已被移除的特性或开发版本中的特性，它们应在受其影响的条目与相关版本的条目中提及。
5. 可以创建已发布的版本的条目；其中每个开发版本都应该创建单独的条目。
   1. 可以创建关于未发布版本的条目，前提是有证明未发布版本存在的显著信息来源。这些来源包括开发版本或是多项关于下一个更新的特性。未发布的开发版本的条目不可被创建。此外，这些版本应该作为一个子章节添加到计划版本。
   2. 原主机版的版本若不同平台的更新有类似的更新内容的，内容应位于同一条目。
   3. Minecraft的启动器各版本也应当创建单独的条目。如果同一个版本在不同平台上有不同的版本号，将不同的的数字用“x”替换。

社区内容

1. 游戏内容相关的攻略、教程等应作为教程的子条目。
   1. 包含如何进行建筑等杂项的条目不会被视为教程。它们应放入用户空间。这包括用户创作的活动与挑战。
2. 只允许加入Mojang Studios表示已经玩过的小游戏。
3. 不可创建关于客户端和服务端的Mod、第三方应用程序和地图编辑器等内容的条目。
   1. 这些内容应当在Feed the Beast Wiki上创建。
   2. 尽管本Wiki上仍然存在部分此类内容（主要是辅助程序与编辑器的子页面），但它们仅作留档之用。
4. 不可创建关于定制服务器的条目。
   1. 这些内容应当在Minecraft Servers Wiki上创建。

Wiki条例

1. 违反《Minecraft最终用户许可协议》《品牌和游戏资产使用指南》的行为一律禁止。

4. 请勿误导读者和编者，确保您的编辑有据可依。请勿加入臆测、恶搞、虚假内容。

5. 请勿加入广告内容或宣传玩家服务器和社区的页面。

6. 请勿从其他网站擅自转载内容到本站。

在“User”名字空间的条目是关注度指导的例外。这些条目可以在遵守相关Wiki条例的条件下作任意用途。不过，仍然十分建议保持它们尽可能整洁，以免出现在维护分类中，以及因用户不再活跃而被清空。

重定向

重定向条目有特别的关注度原则，且其必须重定向到一个符合关注度指导的条目。如果重定向到另一个Wiki，必须使用软重定向{{soft redirect}}。重定向条目在符合以下条件之一时可被创建：

1. 是目标条目的缩写、广泛使用的社区名称、曾用译名、其他中文书写系统中的名称，例如“流髑”之于“流浪者”、“豬布林”之于“猪灵”。
   1. 也包括Mojang Studios员工的姓名或昵称，例如“Dinnerbone”“Nathan”之于“Nathan Adams”。
   2. 但不允许创建错误拼写、错误的曾用译名。
   3. 也不允许创建粗俗名称、含有强烈主观色彩的名称。
   4. 如果曾用名未广泛使用，则也不能创建。
2. 属于合并或杂项条目的一部分，例如一种药水、一种提及特性或同一启动器版本在不同平台上的版本号。
3. 特别地，允许基岩版译名的重定向，但是除了重定向页面以外，主空间不应出现基岩版译名。

一个页面的重定向数量需在合理范围内。重定向条目的目标不能是不存在的条目或另一个重定向条目。

英文名称不应被创建重定向。

“User”命名空间下的条目可以重定向到任意位置，但仍需遵守上述原则。

条目标题

条目应遵从基于其类型的常规命名格式。

• 关于游戏内方块，物品和实体等特性的条目应使用Java版游戏内译名。目前，这些译名由中文Minecraft Wiki管理团队管理。完整的译名列表可见此处。
  • 基岩版的译名质量差，不应使用。
  • 如果某特性无游戏内名称，就应遵照其他同类型条目的相同形式，例如，生物鸡骑士。
  • 如果条目是关于游戏内多项事物的，标题应同等地代表所有名称。例如，关于木质与铁质门的条目应命名为门。
  • 如果某特性尚无确定的中文译名，则使用其英文名称作为占位，其相应条目的编辑应一律在公共沙盒中进行。待中文名称确定后，再将条目移动至相应的中文名称处（不留重定向）。如译名由于特殊原因在短期内无法确定，可酌情考虑将其移动至主命名空间，标题采用英文名称，直至其译名正式确定。
• 关于人物的条目应该包含姓氏与名字，而不是他们的Minecraft或Twitter昵称。
• 消歧义条目在标题已被某条目使用时才应该包含“（消歧义）”。
• 若是以英文命名的条目，且条目类型未在此列出，则应选用句子型大写（第一个单词首字母大写）的最确切的标题，而不应用标题型大写（各单词首字母大写），除非其为一个特定的名词。

关于游戏版本条目标题的命名格式，请见版本#标题。

编写

参见：Help:官方资源

由于本Wiki的目的是记录事实，您应该始终避免推测的与无来源的信息。一般来说，如果可以直接地在游戏或其他明显的地方被看到，这些信息就不需要来源。然而其他的信息，比如来自Mojang员工的引言和并不广为人知的信息，必须以适当的参考标明来源。{{citation needed}}模板应被放置在任何需要来源的信息之后。不要在条目中加入你无法找到来源的内容。

在主名字空间的条目应该保持第三人称的口吻且不使用对读者来说需要参考的术语，但教程页面除外。也尽量尝试不使用缩略语。举例来说，“你不该靠近苦力怕，因为他们会爆炸然后把你杀掉。”应该写成“玩家不应该与苦力怕靠的太近，因为它们会爆炸，并有杀死玩家的可能。”

强调重点时应该用粗体，而不能用斜体。

教程信息，包括对方块或纹理的延伸特性，应只写在教程条目。如果有重要关系，教程条目被主要条目链接。

Mod信息不应包含在与Mod无关的条目。Mod条目也不能从与Mod无关的条目链接。

保持条目的简明与更新

快捷方式

MCW:更新

简单来说，条目应该只包含最新的信息，即在最新的“完整”游戏版本所呈现的内容。任何的过期内容应该移动到条目的历史段落。当有更改时，应在历史段落中记录并移除条目其他段落中的过期信息。提及某一特定的特性在何时实现并不必要；这个特性也应当保留于条目的历史段落。例如这样的句子：“交易，实现于1.3.1，是一种允许玩家通过交换绿宝石（此前是红宝石）来获取其他物品的特性。”应当写成“交易是一种允许玩家通过交换绿宝石来获取其他物品的特性。”

这里有一个不好的条目编写的示范，使用的是原木条目之前的版本。这段是完整的介绍内容。用黄色高亮的是多余内容，而粉色的是历史内容。

原木（Log）（旧称木头（Wood）），是一种首次出现于Minecraft创造模式0.0.14a的方块。它们的四个侧面有类似树皮的外表，顶面和底面则是横切面。在Beta 1.2与所有之前的版本中，只有普通橡树原木能在区块中生成，而松树与白桦将生成于更新一些的区块中。作为树的组成，原木在自然生成的地图中非常丰富。原木可以用手挖下，但使用斧会更快。原木也是可燃的。

在现有的原木中，白桦是最稀有的品种。原木、木头常用于组成植物，树和木屋。在生存测试中，原木挖掘后掉落3 - 5个木板。而在Indev、Infdev、Alpha和Beta挖掘原木会则掉落一个原木。这使得原木可以作为建筑材料，也能合成出木板。

原木唯一的合成用途是制作成4个木板。另外，原木可以在熔炉中烧制来制作煤炭的替代品木炭。

自2011年1月13日更新的Beta 1.2以来，总共有四种原木。一种是普通的原木（橡木），另一种像白桦，还有一种像普通原木，但更黑且出现在生长于寒冷生物群系的松/针叶树，第四种与橡木相似，但颜色稍有不同且斜向一边。这些原木方块依旧可以通过合成制作4个木板。不同种类的原木在物品栏里不会堆叠，但是木板可以。由不同种类的原木做成的木板完全相同。白桦的叶子比一般的叶子略微暗淡，松树有松针，丛林木树叶茂密且有水果样的花纹。

第四种原木加入于快照12w03a，只生长在丛林生物群系，组成它们专属类型的树。最高的树使用这种类型的原木，尺寸为2x2而不是通常的1x1。

这部分的问题是陈旧信息散布于新信息中。介绍应该陈述方块在最新发布版本的当前内容。历史信息是好的，但为清晰起见，这些信息应该按时间顺序写在单独的地方：条目的历史段落。

未来

快捷方式

MCW:未来

在未来更新中加入的内容应加入到条目的主内容中，被写入的特性要用{{upcoming}}标记且是在预览版本中出现过的。如果更新包含相关条目的巨大更改，那么这些内容应在主段落中作为一个子段落提及，或是放在一个名为“即将到来”的专有段落。即将到来的特性必须同时在“历史”段落，使用特定的“即将到来”的标头提及。

更新发布后，所有过期的内容都需要移动到历史段落或移除，且所有使用的{{upcoming}}模板都应被移除。

引用

所有引用的内容应当和原文完全一致。引文中需要额外添加的内容应当以方括号[]标出。如果原文存在错误，则引用时应当在出错处用{{sic}}标注。

段落等级

页面主段落应以二级标题开始（两个等号），每一子段落增加一级。永远不要使用一级标题（一个等号）。

段落之间应有一个空格，等号与段落名称也应有一个空格以方便编辑。如果使用了“主条目”链接或缩略图，将其直接放在段落标题之下，然后在开始段落内容之前，接着输入一个空格。

关于段落次序的信息，参见本格式指导的页面布局段落。

斜体

中文和英文的斜体使用方式有所差异。在本Wiki中，斜体的使用规范如下：

• 一般情况下，任何中文内容都不应使用斜体。
  • 强调内容时可以适当使用粗体；包含中文的书籍、电影等作品名称应使用书名号“《》”标记。
• 只包含英文的作品名可以使用斜体，如Minecraft: The Voyage。在英文句子中强调内容时，也可以使用斜体。
  • 正文中的Minecraft、Minecraft Earth和Minecraft Dungeons是仅有的三个例外，不应使用斜体。
  • 其他情况下，英文内容都不应使用斜体。
• 在计算公式等特殊内容中，可以适当使用斜体标记参数。

另外，有时为了防止机器人在批量替换文本时破坏模板参数，部分正文内容也会使用斜体标记。这类标记会在文本替换完成后由机器人自动去除。

英文内容

条目正文内除开头的关键词外，一般不应出现英文。关键词的英文应当遵循游戏内名称（如有）或常规的美式英语拼写。含有大段英文内容的条目应当移动至沙盒。

图像

快捷方式

MCW:图像

当往页面加入屏幕截图时，确保截图用的是原版纹理与UI。使用定制纹理包、UI模组与其他定制内容的屏幕截图是不被允许的，但关于模组的页面除外。

为清楚显示截图内容，除非目的是展示平视显示器（HUD）相关内容，否则需要隐藏HUD（可通过按F1切换隐藏）。

图像介绍末尾不应有句号，除非语句是一个完整的句子。

往页面中加入的图像应符合以下指导方针：

• 图像应展现页面主题的一种属性。
  • 图像不应出现无意的怪异或搞笑之类的行为，例如生物“坐在”楼梯上。
  • 图像不应只有展示漏洞的目的，而漏洞应到官方追踪器报告。
  • 图像应避免展示具体特性的装饰用途。
• 页面应只用一张图片展示页面内容的某一项独立属性。例如，一只僵尸穿着盔甲。
• 图像应展示包含描述内容的最新版本的Minecraft。
  • 图像如果过期则应被移除。

二次上传英文Wiki的图像时应当使用原图，而不是低分辨率的版本。

链接

快捷方式

MCW:链接

  关于完整的链接指导，请见“链接格式守则|wikipedia:zh:Wikipedia:格式手册/链接|链接格式守则”。

对链接的使用是在为读者提供使其能流畅阅读页面的足够实用链接与干扰到阅读流的多余连接之间的艰难平衡。

链接缺失会使读者困惑，因为可能会出现一些只能通过搜索选项或其他说明来源的关于页面内容的问题，这些问题会打断并干扰读者。

链接过多可能会干扰读者，因为链接常使用不同颜色来吸引眼球。此外，如果同一个词在同一个段落被多次使用链接，会使读者产生这些链接是否指向不同页面的疑问。

链接的指导方针如下：

• 单个页面用于链接的词不能超过10%。
• 除非对句子的词语组成或可读性产生不利影响，两个链接不能紧挨在一起，以致看起来像单个链接。
• 任何单一术语的链接不能在同一页面多余地重复创建。多余链接的定义是在某行或某自然段对同一术语创建多次，使其在读者屏幕上总会不必要地出现。记住，链接的目的是在读者需要更多信息，而要临时绕道时，引导他们到一个新的地方。
• 在页面中离上一次出现有一定距离的地方重复创建重要链接应是很合适的。如果一个重要术语在一个长页面中多次出现，但只在页面最开头的地方用了链接，就应当用下划线标明。确实，带着兴趣直接跳转到一个子段落的读者必须依然能找到一个链接。但对于这种问题要小心对待，重复链接的距离关乎编辑者的喜好，然而如果存疑那就在更远的地方重复。

链接到重定向页比用管道链接更好，除非是在模板和其他可能会被引用的页面。如果无法避免使用管道链接，就不应将其指向重定向页。例如，请用[[白桦原木]]而不是[[原木|白桦原木]]。

坐标

游戏内的单个坐标应当大写，并且不需要添加空格（即“Y=1”而不是“y=1”或“y = 1”）。体积标识应当按照X、Y、Z的顺序写出，中间使用乘号（“×”，×）隔开；例如，“4×3×2”表示一个沿X轴4格、Y轴（竖直方向）3格、Z轴2格的区域。更深入的坐标表示正在讨论中。

命令

命令格式应当严格遵循游戏内的提示。

Java版

需要按原样输入的内容（字面量）没有其他任何修饰（如/data merge）。需要以合适的值替换输入的内容（变量）使用尖括号标注（如<target>）。可选的内容以方括号标注，但方括号不能取代其他标注（例如，[<size>]是可选的变量，而[size]是可选的字面量）。必须从一组字面量中选择一个输入的内容用圆括号标注，以管道符分隔（如(eyes|feet)）。可选的从一组字面量中选择一个输入的内容用方括号标注，以管道符分隔（如[destroy|replace|keep]）。

以/advancement (grant|revoke) <targets> only <advancement> [<criterion>]为例，/advancement和only是需要原样输入的字面量，(grant|revoke)是需要从grant和revoke中选择一个输入的字面量，<targets>和<advancement>是必需的以合适值替换的变量，[<criterion>]是可选的以合适值替换的变量。

文件

快捷方式

MCW:文件

文件的名称应当简洁，且能表明文件的内容。需要注意：

• 不应该只用日期来给文件命名（这经常发生在截图上，请修改文件名）。
• 文件名不应该包含中文字符。
  • 全角符号也被视为中文字符，请在上传时改为半角。
• 文件名不能是无意义的字母、数字和符号的组合。
• 文件名也不应该包含“px”之类的尺寸说明。
• 除了一些特殊文件另有用途外，请勿上传Grid开头的图标，这些图像统一收集在“小精灵”图像中。
• 确保文件名中没有多余的空格。
• 文件后缀名一律小写。

Infobox内的图像名称必须和游戏内英文名称一致，且应当是等轴视图。随着游戏的更新，这类图像往往会产生多个修订版本，为方便起见及保持名称的一致性，这类文件的各纹理版本命名格式及使用要求如下：

• 以<特性名称> JEm BEn.png为格式统一命名。
  • “m”和“n”是此纹理在对应Java版或基岩版中更新的次数（从1开始），随纹理的更新而递增。
• 将<特性名称>.png作为重定向指向游戏最新正式版中使用的修订版本，并应用在Infobox中。
  • 例如，File:Grass Block.png是一个重定向，指向最新正式版中使用的纹理File:Grass Block JEm BEn.png。
  • 若游戏开发版本使用了原有游戏内容的新纹理，应待其所属的正式版本发布后再将该重定向指向新纹理。
  • 对于游戏开发版本加入的新内容，该重定向应指向最新开发版本当中使用的纹理。
• 需要额外注明其他特征的，文件名应当遵循<特性名称> (<特征>) JEm BEn.png的形式。
  • 其中<特征>部分一般应小写，例如Oak Door (item) JEm BEn.png。

如图像含有大量需要繁简转换的内容，应当单独上传适用于各自地区的版本，文件描述内相互注明其他地区和Category:汉化图像。为方便起见及保持名称的一致性，这类文件的各地区版本命名格式为<图像原名称> Simplified.png、<图像原名称> Traditional.png和<图像原名称> Traditional HK.png，其中Simplified代表内含大陆简体的图像、Traditional代表内含台灣正體的图像、Traditional HK代表内含香港繁體的图像，并建立<图像原名称>.png到<图像原名称> Simplified.png的重定向。

页面布局

出于一致性的目的，特定类型的所有页面都应遵循此常规布局。一般条目从上往下分别是：

1. Hatnote（顶注）；
2. Message box（消息框）；
3. Infobox（信息框）；
4. 关于条目的简要介绍；
5. 条目主体部分；
6. 另见/另请参阅；
7. 注释和参考；
8. 合适的底部导航；
9. 分类；
10. 跨语言链接。

条目顶部内不应有过多的消息框。必要的时候，请将消息框移动至与其最相关的段落顶部。

特定类型的布局

如果页面目前尚未拥有布局，可以在讨论页中提出；否则，就尝试使用与已存在的布局格式相近的布局。目前页面的布局包括：

• 特性类
• 红石类
• 版本类

删除页面

为了防止出现孤立页面，请勿直接清空一个页面，而应当在页面顶部使用{{delete}}模板提示管理员或巡查员删除此页面。使用了此模板的页面会加入到Category:等待删除分类中。