;
×
创建新页面
在此填写您的页面标题:
我们当前在Undertale社区维基上拥有211个页面。请在上方输入您的页面名称或点击以下任意标题来开始编写页面!



Undertale社区维基

Undertale社区维基:条目格式

(重定向自UW:AF
欢迎来到Undertale社区维基(*`∀´*)ノ亻,如果想要参与条目创建或编辑,请先登录
Gear.png

政策性文件条目

本条目是一个政策性文件条目

条目格式是定义一般条目编辑风格的政策。细则见:AU条目·人物条目·音乐条目

制定一个统一的准则,目的是使得Undertale社区维基的内容更易于阅读和使用,并让编辑变得更加方便。

页顶模板

模板规范#页顶模板

首句

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

一个条目的首句,应为这个条目所描述事物的的定义句。

一般来说,条目的第一句的第一个词应是条目名称,如无法做到,那么条目名称在第一句中的位置越靠前越好。

条目名称在条目中首次出现时,将其粗体显示

如: Drop0ff,美国加利福尼亚州帕姆代尔人,真名Brandon Demitri Vaughn(布兰登·迪米特里·韦恩),曾用圈名DropLikeAnECake、Dropbits、BDV等,SoundCloud和YouTube著名音乐人、游戏实况主。

章节标题

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。
  • 章节标题应由最简单的名词构成。
  • 不应在章节标题中重复条目标题或其主题。
  • 不要使用一级标题= 标题 =,直接从二级标题== 标题 ==开始。
  • ==旁的空格无论存在与否都不会影响显示效果,可以选择性地添加它们。
  • 不应在标题处添加wikitext标记或html标记。
  • 不要使用粗体大文字充当标题。
  • 规范化标题参见附录,使用规范标题时,不应作出修改。

时间

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。
  • 默认时区为UTC+08:00。
  • 阿拉伯数字应使用半角数字,而非全角。
  • 中英文及阿拉伯数字混用以表示延续范围,应使用中文的连接号,即全角的“-"(U+FF0D)来连接,不是破折号“—”。波浪号“~”和“~”亦不适用。例如:2015年-2022年。
  • 表示时、分、秒应该使用阿拉伯数字,分隔符为半角冒号“:”。如果时、分、秒为个位数时,十位上加“0”;如果表示的是“0”的话,个位和十位都要用“0”,默认为24小时制。格式为HH:MM:SS/HH:MM
  • 表示一个完整的年月日时刻应该使用阿拉伯数字,不需要补齐十位的“0”,可在YYYY-MM-DD/YYYY/MM/DD两格式任选其一。[a]
  • 避免使用模糊的时间词,如“近期”、“一年前”。

附录

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

每个条目应包含的模板:

{{Ref}}:创建注释参考栏目,而不需要自行创建注释参考章节标题。

{{评论区}}:创建一个评论区。
可以选择一些附录可以依附在条目最后,使用以下表达:

外部链接:一些与条目主题相关的链接,不包括已经在条目的其他出现的链接。

相关条目:一些内部链接以及必要的说明。

声明

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。
  • 一般而言,不应在条目内作出无意义的声明,例如:“欢迎来到XX的utcwiki页面。”、“本AU的分类标准来自AU”。
  • 部分与Undertale社区维基本身重复的声明不应再在条目内再次声明,例如:“本页面不能保证信息的正确性”。

大小

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。
  • 可读部分大小:条目主要部分的可读文本,不包括脚注和参考文献部分(“参见”、“外部链接”等)、图表和图像、表格和列表、链接和外部URL以及格式化和标记等材料。应控制在100汉字——30000汉字以内。
  • 总字节大小:全页面编辑窗口中的字节(通常情况下,1个汉字等于三字节,一个字母等于一字节。)量,页面信息中的“页面长度(字节)”。应控制在1kib——120kib以内。
  • 总加载大小:由网页浏览器加载的页面总大小。最大限制为2048kib。

客观

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

原则上,编辑者不应对所编辑的条目做出主观上的个人评价和褒贬,而应该以客观的视角,以引用的形式表达读者、观众、媒体等对于角色、作品等的评价。

人称

现行
该规则是正在生效的规则,请至政策反馈讨论版反馈意见,一般而言现行政策不会发生大幅度的修改。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

编辑者应以第三人称视角编写条目,使用“我”作为主体视角是不应该的。

原始资料

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要添加更多的例子,需要确定哪些内容可以被直接引用。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

一般而言,应避免在条目中完整地列出原始资料(完整人物对话等等),可以在概括该内容的基础上,给出指向原文的链接。但篇幅较小的可以全文引用。

描述事实

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要更多的子规则。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

应尽量描述事实,勿用以下类型的词汇、句式或叙事结构:

1.空泛的形容词

如:最著名的、不可忽视的、值得一提的

请不要接管读者对条目所述对象的重要性判断,使用这些空泛的形容词,可能会反而导致条目变得缺乏说服力。

两个例子说明:

CZTV-28,国人著名曲师之一,从开始作曲至今在短短的两年间就拥有了不小的粉丝数和影响力。

CZTV-28,本名栾佳旺,山东省青岛市西海岸新区人,音乐创作者,代表作Eternal Time V1-V3 上述两例中,相比第一例直述CZTV是一名国人 著名曲师,更推荐像第二例一样描述CZTV的社 区活动与作品,让读者自行判断他的地位。


2.主观意见的形容词

如:可爱的、受人喜爱的、无望的、历史性的

参见#客观


3.存在谬误的归因

归因,指从他人的行为推论出行为原因、因果关系。

在归因过程中,一些常见的谬误如假性因果,即两者之间存在的因果关系是虚假的,只不过是时间上先后发生。这种谬误常见于归因时带有偏见,例如房子里充满了尘埃与户主的死亡不一定有关系,不要为这两件事构建因果关系。也就是说,不要把一个事实(房子里有尘埃)当作另一个事实(户主死亡)的原因或结果,而忽视了其他可能的解释或影响因素。

为了尽量避免这样的谬误发生,应在使用归因词语(如:因为、导致、造成)时,要注意区分相关性和因果性,不要混淆两者的概念和含义。

一致性

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要社群反映,需要更多例子。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

内容应与它对应的标题保持一致。

  • 一致性准则:
    • 与条目标题:条目的内容应与标题所述对象一致。比如Undertale条目不应过多包括Deltarune的内容。
    • 与条目章节/栏目标题:各章节/栏目标题内的内容应与章节/栏目标题一致。比如“简介”标题下不应过多包括经历。

相关性

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要社群反映,需要更多例子。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

内容应与Undertale社区维基的基调相关。

  • 相关性准则:
    • Undertale/Deltarune社区[b]:条目所述内容应与社区相关。例如在编写人物条目时不应将该人物在社区以外的活动或事务写入条目中,除非这些活动能够间接或直接引出其在社区的贡献,在此情况下也应将这部分内容控制在一个尽量小的篇幅。
  • 示例:
他已经因为喜欢日常整狠活在术圈小有名气。
(如果不是为了引出加入社区的内容,那么相关性不足)
他开始制作植物大战僵尸改版通关视频。
(如果不是为了引出加入社区的内容,相关性不足)
他在SoundCloud发布了开放有偿约稿及打赏的声明。
(如果作为社区作曲家生涯的阶段性内容,那么相关性满足)
他还创作过《毁灭战士》《雷神之锤》及《英雄萨姆》等作品的同人音乐和其他原创曲目。
(如果已经说明过他在社区内的贡献,且此段篇幅相较不长,属附属内容,那么相关性满足)

聚焦度

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要社群反映,需要更多例子。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

聚焦度是一个由关注度和关键性组成的评判标准,内容应是被人所关注且关键的。

  • 关注度准则:
    • 条目所述对象本身:条目所述对象应在社区拥有一定关注度,即不应为一个刚成为社区成员的新人攥写人物条目
    • 条目内容:条目内容应在此标题下拥有一定关注度。例如在编写人物条目时“经历”标题下不应写这个人做的不会有人在意的事
  • 关键性准则:
    • 条目所述对象本身:条目所述对象应在社区应有一定关键性,即不应为一个以臭名而昭著且没有任何社区贡献的人攥写人物条目
    • 条目内容:条目内容对条目所述对象本身应有一定关键性,即不应写入与人物的发展/发迹无关的事
  • 示例:
他于2023年7月4日发布了第一个Undertale社区相关视频。
(如果他是一名新人,那么关注度不足)
他早上吃了一碗面,中午开始制作他的自设Megalo。
(如果他不是作为任何后续事件的铺垫,那么前半句的关注度不足)
他在加入社区后觉醒魔证和抽象天赋。
(关键性不足)
他的社区活动期间十分喜欢数学,特别是三角函数。
(关键性不足)
他表明自己“不再会经常制作与UT相关的曲目”。
(如果他是一名著名社区创作者,那么关注度和关键性满足)
他们合作创作了国内最长的Omniilovania曲目。
(如果这件事被很多人重视,那么关注度和关键性满足)

体裁

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要例子,需要更多可以指定格式的栏目。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

建议条目的编写体裁与原始资料的体裁相同,若后者不为文字体裁则使用散文体裁。
可以自行尝试哪种格式更易读。
指定格式的栏目:

  • 表格:各集合
  • 列表:琐事

资料模型

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要例子,需要社群反映。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

对于一个条目上的结论,它基本上由以下环节而来:
原始资料 → 译后资料 → 零散的结论 → 以合适的格式放到条目上

首先,我们找到有原始资料,这些资料是最初的来源,指未经整理的原文,包括剧情原文,完整人物对话等等。

然后,我们把它们翻译成译后资料,当然还可能会有注解等其他本地化的方式,这确保了跨语言的资料传递。

接着,我们来到了零散的结论这一环节。这时候,我们从原始资料或译后资料中提取出各种结论、观点、事实或关键信息,这些结论通常以零散的形式存在,它们或适合或不适合被编排在一起。

最后,我们将这些零散的结论整理起来,以合适的格式放入条目中。这个过程包括将内容组织成段落、章节或列表,并确保它们符合政策。
  • 从保持内容可读的角度来看,原始资料、译后资料与零散的结论都不应直接出现在条目中。以下情况除外:
  • 原始资料即结论(来源本身就以结论的方式来写,但仍需按照直述)
  • 结论本来就适合以零散的格式来写的情况(可以用无序列表来编排这些结论)
  • 内容是背景故事(不需要遵循直叙规则)

直叙

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要例子,需要社群反映。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

叙述时应使用不加修饰、朴实的表达方式,且能用应尽用陈述句。不应以作中人的口吻叙事、包含口癖等。

原文如此

如果一个需要添加到Undertale社区维基的原始资料本身有悖于直叙规则,请直接改写成直叙的方式,背景故事除外。如果这是一句明显用于体现或暗示某些东西的内容,请在正文处写下这个结论。对于这个内容的本身,通过标注来记录而不用再在正文提及其。

合并与拆分

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要更多适用于拆分/合并的情况,需要例子,需要社群反映。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

这些规则也适用于当要为一/多个对象建立条目时,应建立一个还是多个条目。
一般而言,当几个条目满足以下条件的任一时,应考虑合并:

  • 某个条目所描述的对象实际上是另一个条目所描述对象的某版本/新旧版。

一般而言,当一个条目满足以下条件的任一时,应考虑拆分:

  • 超过大小限制时。
  • 某一个栏目或子栏目是除它以外最大(按可读部分计算)栏目的三倍以上时。
  • 某一个栏目或子栏目是除它以外最长(按移动端或桌面端计算)栏目的三倍以上时。

其他情况

注意,当:

  • 对象的相应官方宣称此版本/新旧版对象独立于原对象
  • 对象被转让

此时也不应立即拆分条目,应从以下角度考虑:

  • 两/多个对象是否有足够的实际差异(于AU而言即为新旧设定)。
  • 若将这个条目拆分,两/多个条目是否能够言之有物。

“坑”

试行
该规则正在试行阶段,请至政策反馈讨论版反馈意见,它会在得到回应后的一个星期天得到相应变更(如果有的话)。
它的主要改进方向有:
需要例子,需要社群反映。
强制
该规则是强制性的规则,这意味着如果有内容或行为与它冲突则会被处理。

它们的最大区别在于“占坑”是强功利性的,而“挖坑”在一般情况下是旨在为日后的内容补充提供一个结构化基础。

“占坑”

“占坑”是指在建立新条目时,只填写一个内容有限的框架,或者干脆什么都不填写,只留下一句“来日再补”,这样的行为被认为是在“抢先占有”一个条目名称。请确保在建立条目时就填写完应填的信息。

“挖坑”

“挖坑”是指为一个知名对象创建一个带有基本框架的条目。这种做法是允许的。

注释

  1. 使用{{日期}}会被强制转换为YYYY-MM-DD(不补齐十位的“0”)的格式
  2. 下文以“社区”简称