Help:Style

这些风格规范旨在鼓励编写整洁、有序且视觉一致的文章。在编辑 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:文章命名指南文章。

布局

按以下顺序排列文章中的元素

魔术词（可选）
分类
跨语言链接（可选）
文章状态模板（可选）
相关文章框（可选）
前言或简介
目录（自动生成）
文章特定章节。

魔术词

行为开关——以及一般来说，所有改变文章显示或行为方式但不自行添加内容的魔术词——都应该放在文章的最顶部。

这条规则特别适用于 {{DISPLAYTITLE:title}} 以及使用了前者的 Template:Lowercase title。

分类

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

跨语言链接

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

文章状态模板

涉及整篇文章的状态模板必须包含在分类（或跨语言链接，如果存在）正下方，以及简介（或相关文章框，如果存在）正上方。
涉及文章特定部分的状态模板必须尽可能紧贴该部分上方放置，同时应适当避免破坏段落、代码块或其他预先存在的模板。
务必在专用字段中为文章状态模板附上一些解释说明（各模板页面中均有示例），甚至可以在讨论页发起讨论。

前言或简介

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

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

描述文章的主题。

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

更多信息请参阅 Help:编写文章简介。

标准章节

“安装”章节

安装章节描述如何安装软件，参见 #软件包管理指令。
使用标准的标题 Installation（安装），并将其排在文章靠前的位置。

“已知问题”章节

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

“技巧与窍门”章节

技巧与窍门章节提供关于使用该软件的高级提示或示例。
使用标准的标题 Tips and tricks（技巧与窍门）。
各种技巧与窍门应组织在子章节中。

“故障排除”章节

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

“参见”章节

另请参阅章节包含指向参考资料和附加信息来源的链接列表。
这应该是一个列表，每个条目以 * 开头，这将创建一个 MediaWiki 项目符号列表。
使用标准的标题 See also（另请参阅），并将该章节放在文章最后。应避免使用其他类似标题，如 External links（外部链接）、More resources（更多资源）等。

章节标题

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

更多信息请参阅某篇相关文章。

出于同样的原因，还要避免使用任何形式的 HTML 或 wiki 标记代码，包括 #代码格式化模板。另请参阅 Help:风格/格式化与标点。

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

格式化

代码格式化

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

对于需要在专用框中显示的单行代码（命令行输入、输出代码或文件内容），只需以一个空格字符开头；另请参阅 Help:编辑#代码。示例：

$ 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 (not DEL 或 Delete)
- PrintScreen
- Up (不是 ↑ 或 Up Arrow) – 其他方向键同理
- PageUp
- PageDown
- Fn (不是 FN 或 fn) – 许多笔记本电脑上的功能键
- Home (不是 HOME 或 Beginning)
- End (不是 END)

注意、警告、提示

Note（注意）应用于在文章某处与用户自然预期有所出入的信息。这包括提供更深入知识的信息，否则这些知识可能被认为与文章有点不相关。另一个例子是需要指出临时公告，比如软件包名称的更改。

Note 也可以用来突出显示重要但容易被该领域新手忽视的信息。

Warning（警告）应用于所描述的过程可能产生严重后果的情况，例如撤销操作相当困难，或导致系统损坏。警告通常应说明最坏的情况，以及可能导致或避免此类最坏情况的条件。

一般情况下，不要滥用 Warning：如果你犹豫不决，很大可能你应该使用 Note。

Tip（提示）应指出某种可能有用并能带来益处的方法或步骤，尽管完成正在处理的操作并不需要它，因此可以安全忽略。
当两个或多个注意、警告或提示必须在文章同一位置连续出现时，优先将它们的文本分组到单个模板内的列表中，除非它们完全无关，否则应避免堆叠模板；例如：

提示

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

表格

语法请参阅 mw:Help:Tables。

表格通常应具有 wikitable 类。
对比表格还应具有 sortable 类。
在适当的时候使用表头和单元格模板。
表头应采用句首大写。
表格图例应使用定义列表，并放置在表格之前。
脚注或备注应使用 1、2 等，并在表格下方使用有序列表，而不是 Unicode 字符。

操作指南

文件编辑请求

在请求编辑文本文件时，除非必要，不要假定特定的文本编辑器（nano、vim、emacs 等）。
通常不要使用命令来暗示请求编辑文本文件；例如，echo -e "clear\nreset" >> ~/.bash_logout 应改为：

将以下几行追加到 ~/.bash_logout：

clear
reset

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

在可能有帮助的地方，可以添加一个指向 Help:阅读#追加、添加、创建、编辑的链接。

软件包管理指令

所有软件包管理指令应使用简单的陈述句，而不是示例命令。
建议至少在第一次出现安装请求时使用 install（安装）重定向或其变体（如 [[install]]ed）。
涉及的软件包（或软件包组）必须链接，且优先使用无变体的形式（通常以 -bin、-git 或 -nightly 等后缀表示），除非变体版本提供了显著差异。
你可以根据具体文章灵活调整措辞，更多示例请参见 #官方软件包章节。

官方软件包

避免提供安装官方软件包的 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（Arch 用户软件库）文章，并了解对其系统可能产生的所有后果。

相反，只需使用简单的陈述句，例如：

安装 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 单元进行 enable、start 或任何其他 systemctl 基本操作的示例；相反，使用一个简单的句子列出涉及的单元，必要时说明与其他单元的依赖关系或冲突，并描述要执行的操作；例如：

若要在引导时启动 GDM，请启用 (enable) gdm.service。

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

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

你可以根据具体文章灵活调整措辞。

确保通过专用重定向链接到 Help:阅读#控制 systemd 单元，例如使用 [[start]]、[[enable]] 或 [[stop]]。

代码风格

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

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

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

Shell

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

超文本隐喻

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

尝试使用正文中的词汇将你的文章与其他尽可能多的文章互联。
只链接到已有的文章。如果遇到死链，尝试修复它。看起来已失效的外部链接应标记为 Template:Dead link。
尽可能避免隐性链接，优先使用如 “更多信息请参阅 systemd 文章” 之类的指令，而不是 “更多信息请参阅这里”。

链接可以用两种方式使用：

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

参见以下示例：

主题引用	页面/章节引用
使用 SSH agent 来加速身份验证。	遵循 SSH keys#SSH agents 来加速身份验证。
大多数显示器都支持次像素渲染。	按照 Font configuration#Subpixel rendering 中的描述启用次像素渲染。
在 initramfs 中包含一个密钥文件 (keyfile)。	说明可以在 dm-crypt/Device encryption#Keyfiles 中找到。
请注意，鼠标键 (mouse keys) 默认是禁用的。	详情请参阅 Wikipedia:Mouse keys。
我们有关于链接的风格规则。	#超文本隐喻章节有关于链接的风格规则。

在文章中编写特定步骤或描述特定事物之前，始终检查是否已有文章详细介绍了该部分；如果是这样，请链接该文章而不是重复其内容。此外：
- 对于 ArchWiki 文章未涵盖的技术术语，链接到相关的维基百科页面。
- 如果该主题的上游文档编写良好且维护及时，应优先只编写针对 Arch 的适配说明，并链接到官方文档以获取通用信息。

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

通常，应与 Help:阅读#组织结构保持一致。

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

Man 手册页

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

支持的内核版本

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

非相关内容

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

拼写

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

语言语域

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

分类页面

分类名称必须使用句首大写。
每个分类必须被适当地归入至少一个父级分类，根分类除外，它们是：
一个分类可以归入多个分类，前提是其中一个不是其他分类的父级。
避免循环关系：两个分类不能互为父级。
不要将一个分类归入其自身（自归类分类）。
分类必须包含在分类页面的顶部。
分类不应重定向，但在重命名期间的临时情况除外。
默认情况下，分类名称应为单数形式（“主题”类分类，例如 Category:Simulation）；如果单数形式可以用来描述其成员之一，则应使用复数形式（“集合”类分类，例如 Category:Boot loaders）。

重定向页面

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

根据 Help:i18n 的规定，并在获得 ArchWiki 维护团队授权的情况下，允许使用跨语言链接的重定向。

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

用户页面

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

通用规则

编辑摘要

参阅 ArchWiki:贡献#三大基本原则。

HTML 标签

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

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