<本站文本内容除另有声明外,转载时均必须注明出处。(详情…中文Minecraft Wiki是完全公开的。请勇于扩充与修正内容!Minecraft中文Wiki微博正在更新!或许有兴趣去看看想与其他用户进行编辑上的沟通?社区专页正是为此创建的。翻译或创建页面之前,不妨看看译名标准化Wiki条例页面。需要管理员的协助?在管理员告示板留言也许可以帮到您。>

Join The Fan Lab, a private Fandom research community for users in the US and UK where you will be asked to share your opinions on all things gaming and entertainment! Click here to see if you qualify

Minecraft Wiki:格式指导

来自Minecraft Wiki
跳转至: 导航搜索
快捷方式
MCW:SG
MCW:STYLE

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

虽然维基百科已经提供了一份更通用的格式指导,但专用于Minecraft的特殊指导方针是有必要的。同理,只有专用于Minecraft Wiki的指导方针和其基本的格式规则才会被收录在这里。

关注度

快捷方式
MCW:关注度

只有符合以下准则的条目可以放在主名字空间。不符合准则的条目可能会在未通知的情况下被删除。

常规
  1. 条目必须包含足够的信息以支撑一个完整的条目。如果它们没有足够的内容,就会被合并到其他相应的条目。
  2. 条目必须在某种程度上直接涉及Minecraft。
  3. 关于人物的条目只允许此人物是Minecraft的开发者且/或有一部分或十分密切地与Mojang Studios相关。
  4. 目前还不存在于游戏中的特性只能放入对应版本的提及特性条目。
    1. 这不包括已被移除的特性或开发版本中的特性,它们应在受其影响的条目与相关版本的条目中提及。
  5. 关于Minecraft版本的条目,可以创建已发布的版本的,其中每个开发版本都应该创建单独的条目。
    1. 可以创建关于未发布版本的条目,前提是有证明未发布版本存在的显著信息来源。这些来源包括开发版本或是多项关于下一个更新的特性。未发布的开发版本的条目不可被创建。
    2. 原主机版的版本应放入原主机版版本记录,未发布的版本应加入到计划版本
    3. Minecraft的启动器各版本也应当创建单独的条目。如果同一个版本在不同平台上有不同的版本号,将不同的的数字用“x”替换。
社区内容
  1. 游戏内容相关的攻略,教程等应作为教程的子条目。
    1. 包含如何进行建筑等杂项的条目不会被视为教程。它们应放入用户空间。这包括用户创作的活动与挑战。
  2. 只允许加入Mojang AB表示已经玩过的小游戏。
  3. Mod内容正在被导出至FTB Wiki,所有关于Mod的文章都应该在那里创建。
  4. 关于定制服务器的条目只允许此服务器是对公众开放的。
Wiki条例
4. 忠于事实 - 不要在编辑条目时对内容进行恶搞/讽刺/扯淡/二次创作/夹带私货以免误导玩家。
5. 不允许创建为特定服务器或其他产品做广告的条目。
6. 禁止创建有关玩家论坛的条目,以免造成广告内容相关的纠纷。
7. 请不要从其他Minecraft相关的网站直接复制信息到本Wiki。

在“User”名字空间的条目是关注度指导的例外。这些条目可以在遵守相关Wiki条例的条件下作任意用途。

重定向

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

  1. 属于替代或缩写的名称,而此名称被广泛使用,例如“栓绳”之于“拴绳”。曾用于游戏中的名称也是允许的。
    1. 也包括其他中文书写系统中的名称。
    2. 也包括Mojang Studios员工的姓名或昵称,例如“Dinnerbone”、“Nathan”之于“Nathan Adams”。
    3. 错误拼写、笔误、非正规的格式和粗俗内容是被不允许的。
  2. 属于曾用的条目标题,包括被移动到其他Wiki的条目,例如“流髑”之于“流浪者”。
    1. 如果曾用标题未广泛使用则除外。
  3. 属于合并或杂项条目的一部分,例如一种药水、一种提及特性或同一启动器版本在不同平台上的版本号。
  4. 升为其他版本的预发布版的父版本,例如“1.7”之于“1.7.2”,因为“1.7-pre”是"1.7.2"的预发布版本。
  5. 特别地,允许基岩版译名的重定向,但是除了重定向页面以外,主空间不应出现基岩版译名。

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

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

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

条目标题

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

  • 关于游戏内方块,物品和实体等特性的条目应使用Java版游戏内译名。目前,这些译名由中文Minecraft Wiki管理团队管理。完整的译名列表可见此处
    • 基岩版的译名质量差,不值得使用。
    • 如果某特性无游戏内名称,就应遵照其他同类型条目的相同形式,例如,生物鸡骑士
    • 如果条目是关于游戏内多项事物的,标题应同等地代表所有名称。例如,关于木质与铁质门的条目应命名为
    • 如果某特性尚无确定的中文译名,则使用其英文名称作为占位,其相应条目的编辑应一律在公共沙盒中进行。待中文名称确定后,再将条目移动至相应的中文名称处(不留重定向)。
  • 关于人物的条目应该包含姓氏与名字,而不是他们的Minecraft或Twitter昵称。
  • Java版版本除快照外应一律加上前缀“Java版”。例如“Java版1.8”。
    • 目前英文Wiki在快照的版本号前也加入了“Java Edition”(Java版),但中文Wiki不需要。请在搬运时去除。
    • 预发布版的格式应为父版本与“pre”之间加一个单独的(英文的)破折号。如果预发布版的末尾有一个数字,那么“pre”与数字间不应有任何东西。例如:“Java版1.8-pre1”。
  • 携带版版本应加前缀“携带版”。例如,“Alpha 0.9.0”应被命名为“携带版Alpha 0.9.0”。
    • 携带版Alpha开发版本应先加上前缀“携带版”,然后加上小写的“build”字样。例如,“0.9.0”的“build 2”应被命名为“携带版Alpha 0.9.0 build 2”。
    • 携带版开发版本应先加上前缀“携带版”,然后加上小写的“alpha”字样。例如,“1.1.0.1”应被命名为“携带版alpha 1.1.0.1”。
  • 基岩版版本应加前缀“基岩版”。例如,“1.2.0”应该使用“基岩版1.2.0”这个标题。
    • 基岩版的预览版本应先加上前缀“基岩版”,然后加上版本号数字。例如,“1.5.0”的第一个预览版本应该使用“基岩版beta 1.5.0.0”这个标题。
  • 其他版本应加上相应的版本前缀。例如,教育版的“1.9.0”应该使用“教育版1.9.0”这个标题。
  • 消歧义条目在标题已被某条目使用时才应该包含“(消歧义)”。
  • 若是以英文命名的条目,且条目类型未在此列出,则应选用句子型大写(第一个单词首字母大写)的最确切的标题,而不应用标题型大写(各单词首字母大写),除非其为一个特定的名词。

编写

参见: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}}模板都应被移除。

英语语法

Wiki上的条目应使用美式英语,除非游戏中名称是英式英语。例如,“colour”应为“color”,而“centre”应为“center”。

英文使用

中文Wiki仅在一个条目的核心词第一次出现时在括号给出其英文名称。如果某特性更改了其英文名称,而中文名称不变,则在相应的历史段落内说明。

段落等级

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

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

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

斜体

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

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

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

图像

快捷方式
MCW:图像

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

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

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

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

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

链接

快捷方式
MCW:链接

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

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

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

链接的指导方针如下:

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

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

红石结构

红石电路与机械的写作应遵循Wiki的单一惯例。

文件

快捷方式
MCW:文件

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

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

Infobox内的图像名称必须和游戏内英文名称一致,且应当是等轴视图。为方便起见及保持名称的一致性,这类文件的各材质版本命名格式为<特性名称> JEm BEn.png,其中“m”和“n”是此材质在对应Java版或基岩版中更新的次数(从1开始),随材质的更新而递增。<特性名称>.png作为重定向指向最新的修订版本。例如,File:Grass Block.png是一个重定向,指向最新的File:Grass Block JEm BEn.png

页面布局

出于一致性的目的,特定类型的所有页面都应遵循此常规布局。

  • 在最顶部,可使用横幅与模板,比如给一个版本用{{Version nav}},给方块类页面用{{Block}},等等。
  • 介绍,使用综合性的描述。
  • 页面正文,从第一个段落开始。

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

删除页面

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