Help:Style (简体中文)

相关文章

• /格式与标点
• /空白字符
• Help:讨论
• Help:Editing (简体中文)
• 帮助:阅读
• Help:模板

这些格式规范旨在鼓励整洁、有序且视觉一致的文章。在编辑 ArchWiki 时请尽可能严格遵守。

文章页面

标题

• 标题应使用首字母大写句式 (sentence case)，例如：“Title for new page”是正确的，而“Title for New Page”则不正确。注意，作为专有名词或大写缩写词一部分的常用词必须大写，例如：“Advanced Linux Sound Architecture”，而不是“Advanced Linux sound architecture”。
  名字空间不被视为标题的一部分，因此“ArchWiki:Example article”是正确的，而“ArchWiki:example article”则不正确。子页面名称应以大写字母开头，因此“My page/My subpage”是正确的，而“My page/my subpage”则不正确。
• 默认情况下，标题中的主题名称应使用单数形式；如果它代表一组或一类事物，并且是可数名词或被视为可数名词，则应使用复数形式。
• 除非文章的主题主要以其缩写为人所知，否则标题中应优先使用全称。标题中不要同时包含全称和缩写（例如在括号中），而应在缩写页面上使用重定向，指向以全称为标题的页面。
• 本地化页面的标题必须遵循 Help:i18n#页面标题。
• 有关更多信息，请参阅 Help:文章命名准则 文章。

布局

• 文章中的元素排序如下：

1. 魔术词（可选）
2. 分类
3. 跨语言链接（可选）
4. 文章状态模板（可选）
5. 相关文章栏（可选）
6. 前言或介绍
7. 目录（自动）
8. 文章具体章节。

魔术词

• 行为开关——以及广义上所有改变文章显示或行为方式但不直接添加内容的魔术词——都应该放在文章的最顶部。

这条规则尤其适用于 {{DISPLAYTITLE:title}} 和使用前者的 Template:Lowercase title。

分类

• 每篇文章必须至少归入一个现有的分类中。
• 一篇文章可以属于多个分类，前提是这些分类之间没有父子级（祖先）关系。
• 分类必须包含在每篇文章的顶部，就在任何魔术词的正下方。
  注意 这与其他一些将分类包含在底部的 MediaWiki 项目（如 Wikipedia）不同。
• 分类与第一行正文（或跨语言链接，如果存在）之间不应有空行，因为这会在文章顶部引入额外的空间。
• 有关更多信息，请参阅 Help:分类 文章。

跨语言链接

• 如果文章在本地或外部 Arch Linux wiki 中有翻译，跨语言链接必须包含在分类下方、第一行正文上方。
  注意，它们实际上会出现在页面左侧相应的列中。
• 跨语言链接与第一行正文之间不应有空行，因为这会在文章顶部引入额外的空间。
• 在添加或编辑跨语言链接时，应注意在所有现有的翻译中重复您的操作。
• 每篇文章中每种语言不要添加超过一个跨语言链接。
• 不要添加与文章自身语言相同的跨语言链接。
• 跨语言链接必须根据语言标签（而非本地名称）按字母顺序排序；例如 [[fi:Title]] 排在 [[fr:Title]] 之前，尽管 "Suomi" 排在 "Français" 之后。
• 有关更多信息，请参阅 Help:i18n 和 Wikipedia:Help:Interlanguage links 文章。

文章状态模板

• 涉及整篇文章的状态模板必须包含在分类（或跨语言链接，如果存在）下方，且在简介（或相关文章栏，如果存在）上方。
• 涉及文章特定部分的管理状态模板必须尽可能放置在该部分上方，同时注意避免破坏段落、代码块或其他预先存在的模板。
• 务必在专用字段中使用简短的词语解释添加文章状态模板的原因（各模板页面均有示例），甚至可以在讨论页开启讨论。

相关文章栏

• 提供一个简单的内部相关文章列表。
• 可选，放在分类（或跨语言链接，或文章状态模板，如果存在）正下方。
• 它只能由 Template:Related articles start、Template:Related 和 Template:Related articles end 组成。另请参阅这些页面中的指南。
• 非英语文章可以使用 Template:Related2 来翻译锚点文本。
• 对于包含链接描述、维基间链接或外部链接的更完整详细的列表，请使用 “另见”章节。

前言或介绍

• 包含在文章第一个章节的正上方。

不要显式地创建 == 简介 == 或 == 前言 == 章节：让它显示在第一个章节标题上方。当文章中有足够多的章节时，目录会自动显示在前言和第一个章节之间。

• 描述文章的主题。

与其转述或编写您自己（可能带有偏见）的软件描述，不如使用上游作者的描述，通常可以在项目的首页或关于页面中找到——例如 WireGuard。您也可以使用来自维基百科的描述，就像 ImageMagick 那样。

有关更多信息，请参阅 Help:编写文章介绍。

标准章节

“安装”章节

• 安装 (Installation) 章节描述如何安装软件，见 软件包管理指令。
• 使用标准标题 Installation 并将其置于文章靠前的位置。

“已知问题”章节

• 已知问题 (Known issues) 章节用于目前尚无解决方案的已知错误或使用问题（对比 “疑难解答”章节）。
• 使用标准标题 Known issues 并将其置于文章靠前的位置。
• 如果该已知问题存在错误报告，强烈建议提供其链接。如果不存在，您应该亲自报告，从而增加错误修复的机会。
• 尽可能避免提到日期或版本号（例如，“截至 2014 年 10 月，Linux kernel 3.17 尚不支持 XYZ 设备。”）。同样，应优先链接到错误报告等参考资料以获取后续信息。

“技巧与提示”章节

• 技巧与提示 (Tips and tricks) 章节提供软件的高级技巧或使用示例。
• 使用标准标题 Tips and tricks。
• 各项技巧与提示应在子章节中组织。

“疑难解答”章节

• 疑难解答 (Troubleshooting) 章节用于有关软件的常见问题解答或常见问题的解决方案（对比 “已知问题”章节）。
• 使用标准标题 Troubleshooting。应避免的常见拼写错误有 Trouble shooting、Trouble-shooting 和 TroubleShooting。
• 您也可以报告已知错误的临时变通方法；在这种情况下，必须提供错误报告的链接（或类似的适当来源，如包含变通方法的论坛帖子）。如果尚未报告，您应该亲自报告，从而增加错误得到妥善修复的机会。
  尽可能避免提到日期或版本号。链接到错误报告等外部参考资料对于读者和编辑者都有很大好处：
  • 对于读者，Wiki 不会成为终点：他们可以找到接近源头的更多信息，而这些信息原本可能在搜索中被漏掉。
  • 对于 Wiki 编辑者，通过减少研究报告的错误是否仍是问题的工作量，使清理工作更容易；如果读者找到新信息并回来编辑 wiki，甚至能带来更大的自主权。

“参见”章节

• 另见 (See also) 章节包含一系列指向参考资料和补充信息来源的链接。
• 这应该是一个列表，每个条目以 * 开头，这会创建一个 MediaWiki 项目符号列表。
• 使用标准标题 See also，并将该章节置于文章最后。应避免使用其他类似标题，如 External links、More resources 等。

章节标题

• 标题应从第 2 级 (==) 开始，因为第 1 级保留给文章标题。
• 创建子章节时不要跳级，因此第 2 级的子章节需要第 3 级标题，以此类推。
• 标题使用首字母大写句式 (sentence case)，而不是每个单词首字母大写 (title case)：My new heading，而不是 My New Heading。
• 避免在标题中使用链接，因为它们会破坏风格的一致性且不够醒目。通常锚点文本也可以在章节内容中找到，否则您可以使用一个简单的句子，例如：

参阅 某篇相关文章 以了解更多信息。

出于同样的原因，也要避免使用任何形式的 HTML 或维基语法代码，包括 代码格式 模板。另见 Help:格式 - 格式与标点。

• 有关更多信息，请参阅 Help:标题的有效使用。

格式化

代码格式化

• 对于简短的代码行、文件名和路径、配置参数、变量以及其他情况，使用 Template:ic 进行行内表示；例如：
  在控制台中运行 sh ./hello_world.sh。

• 对于需要在独立框中表示的单行代码（命令行输入或输出代码以及文件内容），只需以单个空格字符开头；另见 Help:Editing#代码。示例：

$ sh ./hello_world.sh

Hello World

• 对于需要在独立框中表示的多行代码（命令行输入或输出代码以及文件内容），使用 Template:bc；例如：

#!/bin/sh

# Demo
echo "Hello World"

• 当需要同时表示命令行输入和输出时，使用 Template:hc；例如：

$ sh ./hello_world.sh

Hello World

• 当需要表示文件内容，并且觉得读者可能难以理解该代码指的是哪个文件时，也可以使用 Template:hc 在标题中显示文件名；例如：

~/hello_world.sh

#!/bin/sh

# Demo
echo "Hello World"

• 对于像配置文件这样的代码块，考虑让读者关注相关行，并省略 (...) 任何周围不相关的内容。

• 有关更多信息以及解决 = 或 | 等破坏模板字符的问题，请参阅 Help:模板 文章。

命令行文本

• 使用行内代码 (Template:ic) 时，不需要表示提示符符号；任何关于权限的说明必须显式地添加到周围文本中。
• 使用代码块 (Template:bc 或以空格开头的行) 时，使用 $ 作为普通用户命令的提示符；使用 # 作为 root 命令的提示符。
  注意 因为 # 也用于表示文本文件中的注释，所以您应该始终确保避免歧义，通常是通过明确写明运行命令或编辑文本文件。
  • 引入命令块的句子通常应以 : 结尾。
  • 除非确实有必要，否则优先使用：

    # command

    而不是写：

    $ sudo command

  • 不要同时使用 root 提示符和 sudo 命令，例如：

    # sudo command

  • 为了展示以另一个用户身份运行命令，在提示符前添加方括号括起来的用户名：

    [archie]$ command

  • 不要在命令的同一个方框内添加注释；例如：

    # pacman -S foo  #Install package foo

  • 避免编写过长的代码行：尽可能使用换行技术。
• 不要假设用户使用 sudo 或其他权限提升工具（如 gksu, kdesu）。

键盘按键

• 文章中表示键盘按键的标准方式是使用 Template:ic 的实例。
• 字母按键应以小写形式表示：a。要表示大写字母，使用 Shift+a 而不是 Shift+A 或 A。
• 表示键位组合的正确方式是在单个模板实例中，使用 + 符号连接各按键，周围不加空格：Ctrl+c。
  Ctrl + c, Ctrl+c, Ctrl-c 是不合规的形式，应予以避免。
• 表示键位序列的正确方式可以是详细说明，例如“按下 g 紧接着按 Shift+t”，或者是简洁说明，在不同的模板实例中用单个空格分隔各按键：g Shift+t。
• 以下是表示一些特殊按键的标准方式：
  • Shift (不是 SHIFT)
  • Ctrl (不是 CTRL 或 Control)
  • Alt (不是 ALT)
  • Super (不是 Windows 或 Mod)
  • Enter (不是 ENTER 或 Return)
  • Esc (不是 ESC 或 Escape)
  • Space (不是 SPACE)
  • Backspace
  • Tab
  • Ins (不是 INS 或 Insert)
  • Del (不是 DEL 或 Delete)
  • PrintScreen
  • Up (不是 ↑ 或 Up Arrow) —— 其他方向键同理
  • PageUp
  • PageDown
  • Fn (不是 FN 或 fn) —— 许多笔记本电脑上的功能键
  • Home (不是 HOME 或 Beginning)
  • End (不是 END)

注意、警告、提示

• 注意 (Note) 应由于那些在文章某些点上可能与用户自然预期有所出入的信息。这包括提供针对某事物的更深入知识的信息，而这些内容原本可能被认为与文章有点无关。另一个例子是需要指出临时公告时，比如软件包名称的变更。

“注意”也可用于突出那些很重要但对于该领域新手来说容易忽略的信息。

• 警告 (Warning) 应由于所述程序可能带来严重后果的情况，例如合理预期下难以撤销的操作，或者会导致系统损坏。警告通常应指明最坏的情况，以及可能导致或避免这些最坏情况的条件。

通常不要滥用“警告”：如果您犹豫不决，很大可能您应该使用“注意”。

• 提示 (Tip) 应指示可能对某人有用并带来好处的方法或程序，尽管完成正在处理的操作并非必须，因此可以安全忽略。

• 当两项或多项注意、警告或提示必须在文章同一点紧接着出现时，优先将它们的文本分组到一个模板内的列表中，避免堆叠模板，除非它们完全不相关；例如：

提示

• 提示示例 #1。
• 提示示例 #2。

表格

语法见 mw:Help:Tables。

• 表格通常应具有 wikitable 类。
• 比较表格还应具有 sortable 类。
• 适当时使用表头和单元格模板。
• 表头应使用首字母大写句式 (sentence case)。
• 表格图例应使用定义列表并置于表格之前。
• 脚注或备注应使用 <sup>1</sup>, <sup>2</sup> 等，并在表格下方使用有序列表，而不是使用 Unicode 字符。

操作指南

文件编辑请求

• 在可能有帮助的地方，可以添加指向 Help:阅读#追加、添加、创建、编辑 的链接。
• 在请求文本文件编辑时，除非必要，否则不要假定特定的文本编辑器——nano, Vim, Emacs 等。
• 通常情况下，不要使用命令来暗示请求文本文件编辑，例如：

echo -e "clear\nreset" >> ~/.bash_logout 应该是：

将以下行追加到 ~/.bash_logout

clear
reset

一个常见的例外是涉及生成复杂的、系统特定的输出的命令——例如 genfstab -U /mnt >> /mnt/etc/fstab。

软件包管理指令

• 所有软件包管理指令都应使用简单的陈述语句，而不是示例命令。
• 推荐在至少第一次出现安装请求时使用 install 重定向或其变体（例如 [[install]]ed）。
• 涉及的软件包（或多个包、包组）必须建立链接，最好不带变体（通常由 -bin, -git 或 -nightly 等后缀表示），除非它们提供了显著的区别。
• 不要为非原生包管理器提供具体指令（例如 Flatpak, make install）；尽管指向具有显著差异的包装的 提示 (Tip) 是可以接受的，例如当上游支持仅限于它们时。
• 您可以灵活调整措辞以适应您的具体文章，更多示例请参阅 官方软件包 部分。

官方软件包

• 避免使用 pacman 命令来安装官方软件包：一是为了简明起见（每个 Arch 用户都应该背下 pacman 的文章），二是为了避免 pacman -Sy package 这样的错误，或者是关于选择 pacman -S package 还是 pacman -Syu package 的永无止境的争论。同理，您更不应建议使用 pacman 前端或封装工具。

相反，只需使用一个简单的陈述，如：

安装 foobar 软件包。

或者，例如当应用程序名称与软件包名称不同时：

MyApplication 可以通过 my-app-pkg 软件包 安装。

安装一组软件包的指令可能显示为：

安装 foobar1, foobar2 和 foobar3 软件包。

如果是指包组，您可以使用：

安装 foobar 包组。

• 使用 Template:Pkg；例如 {{Pkg|foobar}}。

当指代包组时，改用 Template:Grp；例如 {{Grp|foobar}}。

• 如果软件包托管在 core 或 extra 仓库中，不要提到仓库名：这会增加维护成本，因为软件包被移动到不同仓库并不罕见。如果软件包托管在默认未启用的官方仓库（multilib, core-testing 等）中，则必须提及，措辞如下：

从官方 multilib 仓库 安装 foobar 软件包。

AUR 软件包

• 避免使用如何安装 AUR 软件包的示例，无论是官方方法还是提到 AUR 助手。每个安装非官方软件包的用户都应该阅读过 Arch User Repository 文章并知晓对其系统可能产生的所有后果。

相反，只需使用一个简单的陈述，如：

安装 foobar^AUR 软件包。

• 使用 Template:AUR (例如 {{AUR|foobar}})。

非官方仓库

• 当建议使用非官方仓库安装预构建的软件包时，不要提供启用该仓库的指令，而是将该仓库添加到 非官方用户仓库 并链接到相关的仓库章节；例如 [[Unofficial user repositories#example|example]]。
• 就像官方软件包一样，不要添加 pacman 命令示例；例如：

从 example 仓库安装 foobar 软件包。

如果软件包在 AUR 中也可用：

安装 foobar^AUR 软件包，该包在 example 仓库中也可用。

如果软件包在 AUR 中以不同名称可用：

安装 aurpkg^AUR 软件包，在 example 仓库中也作为 builtpackage 提供。

systemd 单元操作

• 不要给出关于如何对 systemd 单元进行启用、启动或任何其他基本 systemctl 操作的示例；相反，使用简单的句子列出涉及的单元，必要时指出与其他单元的依赖关系或冲突，并描述要执行的操作；例如：

要在引导时启动 GDM，启用 gdm.service。

或者，例如当单元是需要实例化的模板时：

要在无线接口上启用 netctl 配置文件的自动切换，请带上接口名称 启用 netctl-auto@.service 的实例；例如 netctl-auto@wlan0.service。

您可以灵活调整措辞以适应具体文章。

• 确保通过专用重定向链接到 Help:阅读#控制 systemd 单元，例如 [[start]], [[restart]], [[enable]] 或 [[stop]]。使用 [[enable/start]] 重定向指示读者使用 enable --now 操作。

编码风格

• 添加命令或脚本时，全篇应使用一致的编码风格，也可以参考其他文章，特别是存在相关文章时。如果可行，请尊重该语言官方或最通用的编码风格指南。
• 避免使用您所用编程/脚本语言的过时特性；例如，对于 shell 命令替换，使用 $() 语法而不是反引号 (``) 语法。
• 脚本的编写应以最清晰的方式仅完成执行任务所需的最小操作。它们不应被设计用于灵活性或扩展性，优先使用 伪变量 而不是实际变量。不要添加无关的功能，如参数解析或输出格式化。
• 添加脚本的主要目的应是教育性质，即当文章正文中的详述无法做得足够清晰简洁时。例如，它们可以用于展示复杂命令的预期用途，或者相关联、互相关的命令如何协同工作。
• 如果认为脚本能为文章增色但不符合上述标准，可以进行外部链接，比如发布为 gist。
• 在表示目录的名称或路径时，以斜杠结尾，或者明确添加“目录”或“文件夹”等同位语；例如：

• “检查 /sys/firmware/efi 目录是否已创建”，而不是“检查 /sys/firmware/efi 是否已创建”。
• “在 /etc/modules-load.d/ 中放置一个 .conf 文件”，而不是“在 /etc/modules-load.d 中放置一个 .conf 文件”。

• 包含空格的参数应使用双引号括起来，例如 cd "foo bar" 而不是 cd foo\ bar。

Shell

• 除非确实需要，否则不要假设特定 shell 为用户的默认 shell（如 Bash）；在撰写或编辑文章时，尽量保持 shell 中立。

超文本隐喻

关于内部链接、维基间链接和外部链接的语法，请参阅 Help:编辑#链接。

• 尝试使用文中的词语将您的文章与尽可能多的其他文章相互链接。
• 仅链接到现有文章。如果您遇到死链，请尝试修复它。看似已失效的外部链接应标记为 Template:Dead link。
• 尽可能避免含糊的链接，优先使用“参阅 systemd 文章以了解更多信息”这样的指令，而不是“参阅此处了解更多信息”。

链接可以有两种用法：

• 作为主题引用，其中链接是一个术语，是正文的一部分，并受常规语法规则约束；如果需要可以使用链接标签。内部/维基间链接如果有重定向则应指向它。
• 作为页面/章节引用，不要使用链接标签，并根据 Template:Lowercase title（如有使用）拼写标题；特别地，在同页面章节链接中不要隐藏 # 符号，例如 [[#Hypertext metaphor|Hypertext metaphor]] 是错误的。

参见以下示例：

主题引用	页面/章节引用
使用 SSH 代理 来加速身份验证。	遵循 SSH keys#SSH agents 来加速身份验证。
大多数显示器都支持 次像素渲染。	按照 Font configuration#Subpixel rendering 中所述启用次像素渲染。
在 initramfs 中包含一个 密钥文件。	指令可以在 dm-crypt/Device encryption#Keyfiles 中找到。
注意，鼠标按键默认是禁用的。	详情见 Wikipedia:Mouse keys。
我们对链接有格式规则。	#Hypertext metaphor 章节中有关于链接的格式规则。

• 在文章中编写具体程序或描述特定内容之前，务必检查是否已有文章详细介绍了该部分；若是，请链接该文章而不是重复其内容。此外：
  • 对于 ArchWiki 文章未涵盖的技术术语，请链接到相关的维基百科页面。
  • 如果文章主题的上游文档编写良好且维护及时，优先仅编写 Arch 特定的适配内容，并链接到官方文档以获取通用信息。

例如：“内核参数用于在启动时发出系统调用；完整列表请参阅 Linux 内核文档。”

通常情况下，应与 Help:阅读#组织 保持一致。

• 除少数情况外，不应让文章成为死端页面（不链接到任何其他文章）或孤立页面（没有任何其他文章链接到它）。
• 不要对与所编辑文章语言相同的本地化页面使用维基间链接，因为它们不会显示在 Special:链入页面 中；例如，在匈牙利语文章中使用 [[:hu:Main page]] 是错误的，而 [[Main page (Magyar)]] 是正确的。
  在不同语言之间使用此类链接是可以接受的，因为如果将来创建了独立的维基，这将使文章迁移更加容易。
  最后，注意这类链接与跨语言链接的区别，后者开头没有冒号。
• 优先使用 “Wikipedia:” 维基间前缀，而不是更短的 “w:” 前缀。

Man 手册页

• Man 手册页应使用 Template:man 引用。

支持的内核版本

• 不要删除任何关于内核版本的说明或适配，只要其版本号大于或等于以下两者中的最小值：core 仓库中当前的 linux-lts 软件包版本，以及最新 安装介质 上的内核版本。

非相关内容

• 请不要在文章中签名，也不要署名文章作者：ArchWiki 是社区的作品，每篇文章的历史记录足以表彰其贡献者。
  注意，报告撰写文章所用的来源是良好实践：您可以为此目的使用“另见”章节。
• 普通用户禁止上传文件，且文章中不允许包含图像。作为替代，您可以包含指向外部图像或画廊的链接；如果您需要绘制简单的图表，可以使用 ASCII 编辑器（如 Asciiflow）和 Template:Text art；理由如下：
  • 维护性：Arch 是滚动更新的，图像会使更新文章变得更加困难。
  • 必要性：Arch 并不开发或维护任何类型的 GUI 应用程序，因此我们不需要展示任何截图。
  • 管理：自由的图像上传需要花费时间来删除尺寸过大或不合适的图像。
  • 可访问性：我们支持低速连接、纯文本浏览器、屏幕阅读器等用户。
  • 效率：图像会浪费服务器带宽和存储空间。
  • 简洁：纯文本文章看起来更简单整洁。

拼写

• 避免缩写 (contractions)：例如，“don't”, “isn't”, “you've” 等应分别为 “do not”, “is not” 和 “you have”。
• 避免对单词进行不必要的简称：例如，优先使用 “repository”, “distribution” 和 “configuration”，而不是 “repo”, “distro” 和 “config”。
  以同样的方式，优先使用不常用命令选项的长格式，而不是其单字符对应项。另见 Help:格式 - 格式与标点#配置参数、变量、选项、属性...。
• 项目、应用程序、可执行文件等的名称应主要根据其官方文档风格拼写，特别是关于大小写。这包括文档将名称视为普通名词的情况，即出现在句首时首字母大写，否则小写。如果官方文档未应用一致的风格，请遵循 ArchWiki 中已使用的风格。如果该名称未出现在 ArchWiki 中，或者拼写仍然不一致，请选择一种风格并在整篇文章中保持一致，同时也可能需要更新提及该名称的其他页面。以 Git 为例，在一般谈论项目/软件时，您可以选择首字母大写 (“Git”)，在指代编译后的程序时，使用全小写和斜体 (“git”)。当名称的大小写可能产生争议时，请在文章讨论页中明确定义一种风格。另见 Help:格式 - 格式与标点#可执行文件/应用程序名称。
• ArchWiki 不偏向任何特定地区的英语变体，采用与 Wikipedia:Wikipedia:Manual of Style#National varieties of English 相同的准则；如果与 ArchWiki 任何其他明确定义的准则发生冲突，以 ArchWiki 为准。在现有文章中编写新内容时，建议维持其已盛行的 拼写规范；如果文章没有明显的盛行拼写，则根据所编辑章节中使用的变体进行编写。协调所编辑内容周围的拼写是可以接受的；请勿进行旨在改变或统一文章或系列文章拼写标准的编辑。

语言语气

• 文章应使用正式、专业且简洁的语言编写。应通过编辑预览和校对，细心消除语法和拼写错误。
• 记住不仅要回答 如何做，还要回答 为什么。解释性信息在传递知识方面总是比单纯的指令更有效。
• 不要省略那些能为句子赋予准确、无歧义含义的术语；例如，在提到仓库名称时，务必加上“仓库”一词。
• 不要使用不确定的时间指代词，如 “currently” (目前)、 “at the time of writing” (在撰写本文时) 或 “soon” (很快)；请用确切的表达替换它们，如 “as of May 2015” (截至 2015 年 5 月) 等。
• 客观写作：不要在文章中包含个人评论；请使用讨论页。通常不要以第一人称写作。
• 在编辑内容时，应与文章其余部分使用的风格保持一致；例如，如果读者始终是以第二人称被称呼的，则新增内容也应采用这种风格；如果第三人称或被动语态在整篇文章中显然占主导地位，情况亦然。
• 在提供不同选项（软件、操作方法等）之间的选择时，不要明确推荐其中一个，而是客观地描述各选项的优缺点，从而帮助读者根据其个人情况做出最佳决策。
• 在提及读者或一般人群时，优先使用 they/them 等中性代词。

分类页面

• 分类名称必须使用 首字母大写句式 (sentence case)。
• 每个分类必须被适当地归入至少一个父分类中，除了以下根分类：
  • Category:Archive (存档),
  • Category:DeveloperWiki (开发者维基),
  • Category:Languages (语言),
  • Category:Maintenance (维护)，以及
  • Category:Sandbox (沙盒).
• 一个分类可以被归入多个分类，前提是它们之间没有父子级（祖先）关系。
• 避免循环关系：两个分类不能互为祖先。
• 不要将一个分类归入其自身（自归类）。
• 分类必须包含在分类页面的顶部。
• 分类不应重定向，除非在重命名过程中的临时重定向。
• 默认情况下，分类名称应为单数形式（“主题”分类，例如 Category:Simulation）；如果单数形式可以用来描述其其中一个成员，则应使用复数形式（“集合”分类，例如 Category:Boot loaders）。

重定向页面

• 鼓励为现有文章标题的缩写或语法变体创建重定向页面，或者为通用文章中子章节讨论的术语或主题创建重定向；例如 ALSA, daemon 或 AIGLX。重定向可以通过替换带标签的链接来简化源文本，请对比之前的示例与 [[Advanced Linux Sound Architecture|ALSA]], [[daemons|daemon]] 或 [[Xorg#Composite|AIGLX]]。
• 重定向页面应仅包含重定向代码，别无他物；唯一的例外是：
  • 存档 (Archived) 页面，其本质上是重定向；必须归类在 Category:Archive 下。
  • 已重命名的分类可以包含 Template:Archive 标记。
• 仅重定向到内部文章；不要使用维基间重定向。

符合 Help:i18n 并经 ArchWiki 维护团队授权的跨语言重定向除外。

• 有关更多信息，请参阅 Help:编辑#重定向。

用户页面

• 用户 (User) 名字空间中的页面不能进行归类。
• 用户 名字空间中的页面只能从 User 或 talk 名字空间的其他页面进行链接，除非获得管理员许可。
• 用户 名字空间中的页面不能作为来自其他名字空间重定向的目标。

通用规则

编辑摘要

见 ArchWiki:贡献#三大基本准则。

HTML 标签

• 通常不鼓励使用 HTML 标签；尽可能优先使用维基语法或模板（参见 Help:编辑 及相关页面）。
• 当想使用 <pre>code</pre> 时，务必改用 {{bc|code}}。当想使用 <tt>text</tt> 或 <code>text</code> 时，务必改用 {{ic|text}}。
• 尤其要避免 HTML 注释 (<!-- comment -->)：在 HTML 注释中添加的说明很可能可以在文章的讨论页中显式地显示。您可以添加一个合适的状态模板来替代注释。
• 仅在必要时使用 <br>；要开始一个新段落或换行，请在下方留一行空行。

提示 该规则常见的例外是：当需要在列表项中换行且无法使用子项目时，或者在模板内部且无法使用列表时。