manual.md

基本编写规范

!> 此规范仅适用于一般的 Wiki 编辑。对于某些特定页面的编写规范，还需要查看特别的规定。

?> ✔ 最后修订版本：2020-4-4-1

众所周知，在此编写规范尚未颁布之前，Wiki 的编写格式和风格一直没有统一。虽然我们不能就这样称之为「杂乱无章」，但是这样也会让新人的阅读体验产生撕裂。因此，我们编写了「基本编写规范」供各位 Wiki 编写者参考。

!> 无需完全遵照，可以适当发挥，但请遵循原则！

语言

Wiki 是向公众开放的资料查阅平台，因此，要保证平台的权威和可信度，我们必须规范语言。对于语言，我们一般作如下要求

不要包含个人观点或风格

任何与个人有关的事情或观点不应该在 Wiki 上出现，具体视情况而定。一般来说，我们应当避免出现以下三种

• 使用含「某」不定代词指人。 例如「某些人」、「某些玩家」等；
• 使用口语语气论述。 例如「这样做是不对的！」、「嘻嘻」；
• 使用自己的理解叙述。 当你不了解一样东西时，应当去查阅有关资料和咨询群友，而不是将自己的对它的主观理解摆放到 Wiki 上。

取而代之，我们应当使用书面语言去表达这些内容，让内容更加清晰易懂。范例：

• 这些玩家最近反馈的问题，我们正在逐一解决。
• 一些玩家并不了解服务器的情况，因此会犯下过错。
• SoTap 不建议玩家进行这种行为。
• 这种行为在当前是不允许的。
• 我们支持玩家进行这种行为。

标点符号恰当

!> 请使用全角中文标点符号

为了让 Wiki 守序中立，我们不能让语言过于活泼。语言的活泼程度部分是由标点符号决定的，因此我们在编写的过程中应当遵循标点符号的使用规则。

目前我们推荐使用的标点符号是最基本的「五大符号」：逗号（，）、句号（。）、顿号（、）、冒号（：），引号会在后文提到。对于问号、感叹号等很容易就带有感情色彩的符号，我们应当尽量避免使用。

• 问号应当只用于设问句，加强论述语气。但是一般情况下我们并不会在 Wiki 中用到设问句，一切都是平铺直叙。
• 感叹号应当只用于简短标语。但从实际出发，其能够用到的情况少之又少。

引号

对于引号，我们目前流行两种组合。第一种是普通引号组合：“、‘、’、”，另一种是直角引号组合 「、『、』、」。直角引号并不是汉语规范用法，虽然也在知乎等平台流行过。Wiki 支持两种引号同时使用。

!> 直角引号一说来自日语，还有另一种说法来自清末王煜初（炳耀）所著的《拼音字谱》

详略得当，语言清晰

其一，Wiki 的内容必须简洁和通俗易懂，因为 Wiki 是为没有任何基础的新手所设立的。我们在使用较为性冷淡的语言的同时也应当使用新人能够理解的词汇。

不要为了让内容显得「高级」而刻意复杂化句子：

?> ❌ 错误示例
本 Wiki 的用户页面禁止所有非本人或本人授权的 Wiki 编写者进行的任何更改。

?> ✅ 正确示例
Wiki 的用户页面不接受非本人，或者没有经过本人授权的人进行编辑。

其二，我们应当把握文章的篇幅。对于一篇文章，我们要想办法删去它的冗余。使文章详略得当是一个逐级进步的过程，并不需要第一次编写就做到，而是随着一遍又一遍的阅读逐渐发现，然后再进行改进。

格式

格式包括文字排版、结构、分段把握和分页设计等内容。一个好的文章结构能够促进读者对内容的理解，因为很多层次都已经被标题分好，很容易便能找到每一段、每一条目、每一主题都在写什么。

文字基本格式

文字基本格式是文字层面所要遵循的格式基础。

空格概念

空格（Blank space）是一个很重要的元素，它能够使文章的内容更易读，对于长篇目文件效果尤为显著。简单来说，就是在中文与英文、中文与阿拉伯数字之间加上空格。

?> 示例 Minecraft 是一款由 MOJANG 出品的沙盒游戏，诞生于 2009 年。

实际上，对于中西文混排的情况，我们往往习惯加上间距，而不是我们一般所说的空格。但是由于间距（指大多数设计软件例如 InDesign 或者单纯的文字排版软件 Word）的大小几乎等于空格，我们便直接简写为空格了。

参考刘昕对中英混排的使用规则概括：

中文正文及标题中出现的英文及数字应该使用半角方式输入，并且在左右各留一个半角空格。如果这些这些半角英文及数字的左边或者右边紧接着任何的中文全角括号或者其他标点符号的话，则不需要加入半角空格。

这段文字写于 2006 年，现在可以在这里找到存档。

善用列表

人类对于分条罗列的信息似乎更具有洞察力，更能够从中理出一份较为完整的理解——也是列表形式的。一般能够使用列表来概括的，我们不应当使用正文。正如刘昕所说，

在 Web 上的文字，是被人们用眼睛来扫描的，绝大部分都不会被人仔细阅读。

如果我们将一系列有一定逻辑关联的文字，使用列表来概括，总比写「长段大论」要好读得多。

?> ❌ 错误示例
在进行操作之前，我们必须遵循一些规定。首先，我们不应随意去按照自己的想法编写，因为一些个人主观的内容如果出现在上面，有可能误导他人，最终导致我们的公信力下降；其次，对于整个内容，我们应当善于整理，条理清晰，脉络清楚是我们需要做的，只有这样，读者才能看懂我们在写什么；最后，整篇内容编写完成后，我们要不时去查看、修改，使文章内容质量能够随着时间提高。

✅ 正确示例
在进行操作之前，我们必须遵循一些规定，大概有如下三条

• 不应随意去按照自己的想法编写。 主观内容有可能误导他人，导致我们的公信力下降。
• 应当善于整理。 只有条理清晰，脉络清楚，读者才能看懂我们在写什么。
• 应不时查看和修改。 这可以使文章内容质量能够随着时间提高。

排版与结构

警告栏和提示栏

Wiki 使用的程序是 Docsify，其本身给 Markdown 添加了一些拓展语法，这也使得我们可以使用警告栏和提示栏来表达特定类型的文字。

!> 这是警告栏，用来编写用于警示、告诫或强调的文字

?> 这是提示栏，用来编写一些小提示

它们在 Markdown 中的语法为：

!> 这是警告栏，用来编写用于警示、告诫或强调的文字

?> 这是提示栏，用来编写一些小提示或举例

使用这两种格式，可以便于我们进行叙述。但是在使用过程中，我们应当遵循一些规则：

• 内容不得过长，举例除外。 内容过长会给人阅读疲劳的感觉，与其将一段话单独以栏目的方式显示，不如直接成为正文。
• 内容不得全段加粗。 警告栏本身就含有一定的强调含义，我们不能再次进行加粗表示「强强调」，而是使用下文中列出的区域标题法。

同时我们也应当避免将这两个栏目与「引用块」相混淆。引用块只能用来引用内容，不能和警告栏、提示栏换用。

如果想要定义这个栏目的性质，则可以选用「区域标题法」，在栏目的第一行写上对此栏目所要论述内容的概括。例如

?> 示例
这是一个例子。

!> 严重警告
这是严重警告。

写法是，使用粗体表示标题，再加上强制换行 <br> 后编写内容：

?> **示例**<br>
这是一个例子。

!> **严重警告**<br>
这是严重警告。

分段原则

如何分配段落？以旧的 FAQ 页面的文字来举例

SoTap 的规则和其他服务器不同的就是要求玩家自己来判断这样做会不会违规。在做一件事之前要三思，最重要的是站在对方的角度去思考。设想一下，如果你的机器被别人乱动了，你内心会开心吗？你破坏了别人的东西，这是道德所允许的吗？你拿了别人箱子里的东西，这是合情合理的吗？在做任何事情之前 ，先思考一番再做不是坏事情，不要用突破道德和贬低教养的标准来做一些事情，当一个人试图降低道德标准来做某件事情的时候，其实他自己已经知道自己违规了。

!> 此段文字中不符合编写规范的内容已用下划线指出，请勿模仿

这段文字对于我们阅读来说略冗长，因此我们需要给它分段。分段时，我们一般按照标准：

• 如果第一句话带有概括性，则独立成段；
• 如果含有「设想一下」、「举个例子」等词语，可以根据对句意的理解，将此句和前后句划分为一段；
• 如果最后一句话带有总结性，则独立成段。

因此上面那段文字的整理结果是

SoTap 的规则和其他服务器不同的就是要求玩家自己来判断这样做会不会违规。

在做一件事之前要三思，最重要的是站在对方的角度去思考。设想一下，如果你的机器被别人乱动了，你内心会开心吗？你破坏了别人的东西，这是道德所允许的吗？你拿了别人箱子里的东西，这是合情合理的吗？

在做任何事情之前 ，先思考一番再做不是坏事情，不要用突破道德和贬低教养的标准来做一些事情，当一个人试图降低道德标准来做某件事情的时候，其实他自己已经知道自己违规了。

分段规则数不胜数，我们无法在此给出一个明确的概括。这需要依赖我们的语感和对文章的整体构思进行。不过，有一点可以明确：

?> 分段是围绕「使一个段落的内容不多不少，刚刚好」为目的进行的。

不要滥用语法

Markdown 语法自然有趣，但并不能滥用，否则会导致阅读上的问题，以及损害整体阅读体验和全文排版的协调性。参考了先前 Wiki 中出现的问题，归纳出如下几点

• 代码块 不是用来表示强调的，而是用于标记某一个在编程含义上的值、Minecraft 指令或者某个具有特定含义的「块」。
  • 例如音标 /'wɪkɪ/、指令 /mute Remind_Z、编程值 "1"。

?> ❌ 错误用法
1 我是强调内容，我应该被强调显示，因为我很重要。
2 SoTap 开放周 是一个所有非白名单玩家都能进入 SoTap 的周。

?> ✅ 正确用法
1 我是强调内容，我应该被强调显示，因为我很重要。
2 SoTap 开放周是一个所有非白名单玩家都能进入 SoTap 的周。

• 删除线在使用时，如果要表达「玩笑效果」，请尽量不要补充额外的词汇，例如「（不是）」、「（bushi」、「（不）」。如果删除线后的内容不是对删除线中的内容的更改和纠正，则删除线中的内容应当与前后文存在逻辑联系。
  • 例如「曾经 Sapherise 也和不知道来自哪里不可名状的某个组织有过联系」。

?> ❌ 错误用法
1 其实一直有个事情想告诉大家：我喜欢女装（不是）我讨厌女装
2 其实我们的服务器也是很有内涵♂的特色的。

?> ✅ 正确用法
1 其实一直有个事情想告诉大家：我喜欢女装我讨厌女装
2 其实我们服务器也是很有特色（内涵♂）的。

关于

此规范用于引导 Wiki 新手进行规范化的编写与贡献，如果您有任何好的意见或建议，欢迎联系我们。