帮助:风格

出自 ArchWiki
（重定向自 Style）

相关文章

这些风格约定旨在鼓励文章整洁、有条理且视觉上一致。在编辑 ArchWiki 时，请尽可能严格地遵守这些约定。

文章页面

标题

  • 标题应使用句子首字母大写，例如，“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#Page titles。
  • 有关更多信息，请参见Help:Article naming guidelines文章。

布局

  • 按以下顺序排列文章中的元素
  1. #魔法字（可选）
  2. #分类
  3. #跨语言链接（可选）
  4. #文章状态模板（可选）
  5. #相关文章框（可选）
  6. #前言或导言
  7. 目录（自动）
  8. 文章特定章节

魔法字

  • 行为开关——以及通常所有魔法字，它们更改文章的显示方式或行为，但不添加内容本身——都应放在文章的最顶部。
    此规则尤其适用于{{DISPLAYTITLE:title}}和Template:Lowercase title，后者使用了前者。

分类

  • 每篇文章都必须至少在一个现有类别下进行分类。
  • 一篇文章可以属于多个类别，前提是一个类别不是另一个类别的祖先。
  • 分类必须包含在每篇文章的顶部，紧接在任何魔法字下方。
    注意：这与其他一些 MediaWiki 项目（例如 Wikipedia）不同，后者将类别包含在底部。
  • 类别与文本的第一行（或跨语言链接，如果存在）之间不应有空行，因为这会在文章顶部引入额外的空间。
  • 有关更多信息，请参见Help:Category文章。

跨语言链接

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

文章状态模板

  • 引用整篇文章的文章状态模板必须包含在类别（或跨语言链接，如果存在）下方和导言（或相关文章框，如果存在）上方。
  • 引用文章特定部分的文章状态模板必须尽可能靠近该部分上方放置，同时适当避免破坏段落、代码块或其他预先存在的模板。
  • 始终在文章状态模板中添加一些解释性文字（示例在每个模板的页面中提供），甚至可以在讨论页中发起讨论。

相关文章框

前言或导言

  • 描述文章的主题。
    与其改述或撰写您自己（可能带有偏见）对某件软件的描述，不如使用上游作者的描述，这通常可以在项目的主页或关于页面上找到（如果存在）。WireGuard就是一个例子。您也可以使用 Wikipedia 的描述，例如ImageMagick的情况。
  • 包含在文章的第一个章节上方。
  • 不要显式创建== Introduction ==或== Preface ==章节：使其出现在第一个章节标题上方。当文章中有足够的章节时，目录会自动显示在前言和第一个章节之间。
  • 有关更多信息，请参见Help:Writing article introductions。

标准章节

“安装”章节
  • 安装章节描述了如何安装软件，请参见#软件包管理说明。
  • 使用安装的标准标题，并将其放置在文章的早期位置。
“已知问题”章节
  • 已知问题章节用于描述尚未解决的已知错误或使用问题（与#“故障排除”章节进行比较）。
  • 使用已知问题的标准标题，并将其放置在文章的早期位置。
  • 如果已知问题存在错误报告，则非常希望您提供指向该报告的链接。如果不存在，则应自行报告，从而增加错误被修复的机会。
  • 请尽可能避免提及日期或版本号（例如，“截至 2014 年 10 月，Linux 内核 3.17 尚不支持设备 XYZ。”）。同样，首选链接错误报告等参考资料以获取后续信息。
“技巧与窍门”章节
  • 技巧与窍门章节提供使用软件的高级技巧或示例。
  • 使用技巧与窍门的标准标题。
  • 各种技巧与窍门应组织在子章节中。
“故障排除”章节
  • 故障排除章节用于描述有关软件的常见问题或常见问题的解决方案（与#“已知问题”章节进行比较）。
  • 使用故障排除的标准标题。应避免的常见拼写错误是Trouble shooting、Trouble-shooting和TroubleShooting。
  • 您还可以报告已知错误的临时解决方法；在这种情况下，必须提供指向错误报告（或类似的适当来源，例如包含解决方法的论坛帖子）的链接。如果尚未报告，则应自行报告，从而增加错误被正确修复的机会。
    请尽可能避免提及日期或版本号。链接到外部参考资料（例如错误报告）对于读者和编辑者都有很大的好处
    • 对于读者而言，Wiki 不会成为终点：他们可以找到更接近来源的更多信息，而这些信息可能在其搜索工作中被遗漏。
    • 对于 Wiki 编辑者而言，通过减少研究报告的错误是否仍然是问题的工作量，可以使清理工作更容易；如果读者找到新信息并返回编辑 Wiki，这甚至可以带来更大的自主权。
“参见”章节
  • 参见章节包含指向参考资料和其他信息来源的链接列表。
  • 这应该是一个列表，其中每个条目都以*开头，这将创建一个 MediaWiki 项目符号列表。
  • 使用参见的标准标题，并将该章节放在文章的最后。应避免使用其他类似的标题，例如外部链接、更多资源等。

章节标题

  • 标题应从级别 2 (==) 开始，因为级别 1 保留用于文章标题。
  • 制作子章节时，不要跳过级别，因此级别 2 的子章节需要级别 3 标题，依此类推。
  • 标题使用句子首字母大写，而不是标题首字母大写：My new heading，而不是 My New Heading。
  • 避免在标题中使用链接，因为它们会破坏风格一致性并且不够突出。通常，锚文本也会在章节内容中找到，否则您可以使用简单的句子，例如
有关更多信息，请参见一些相关文章。
出于同样的原因，还要避免使用任何类型的 HTML 或 wiki 标记代码，包括#代码格式化模板。另请参见Help:Style/Formatting and punctuation。

格式化

代码格式化

  • 对于简短的代码行、文件名和路径、配置参数、变量以及要以内联方式表示的其他情况，请使用Template:ic；例如
    在控制台中运行 sh ./hello_world.sh。
  • 对于要以适当框架表示的单行代码（命令行输入或输出代码以及文件内容），只需以单个空格字符开头即可；另请参见Help:Editing#Code。示例
$ 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文章。

命令行文本

  • 使用内联代码（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）

注释、警告、提示

  • 注释应用于表示在文章的某个点上与用户自然期望有所不同的信息。这包括提供有关某些事物的更深入知识的信息，否则这些信息将被视为与文章有些无关。另一个例子是当需要指出临时公告时，例如软件包名称的更改。
注释也可以用于突出显示重要但容易被主题领域的新手忽略的信息。
  • 警告应用于描述的过程可能带来严重后果的情况，例如难以撤消或导致系统损坏。警告通常应指示最坏的情况，以及可能导致或避免此类最坏情况的条件。
通常，不要滥用警告：如果您不确定，则很可能应该使用注释。
  • 提示应指示一种方法或过程，该方法或过程可能有用并为某人带来好处，即使并非完成正在处理的操作所必需，因此可以安全地忽略。
  • 当两个或多个注释、警告或提示必须在文章的同一点连续出现时，首选将它们的文本组合在一个模板内的列表中，避免堆叠模板，除非它们完全不相关；例如
提示
  • 提示示例 #1。
  • 提示示例 #2。

表格

有关语法，请参见mw:Help:Tables。

  • 表格通常应具有wikitable类。
  • 比较表还应具有sortable类。
  • 在适当的时候使用表头和表格单元格模板。
  • 表头应使用句子首字母大写。
  • 表格图例应使用定义列表，并放置在表格之前。

说明

文件编辑请求

  • 除非必要，否则在请求编辑文本文件时，请勿假定特定的文本编辑器（nano、vim、emacs 等）。
  • 通常，请勿使用命令来隐式请求编辑文本文件；例如，$ echo -e "clear\nreset" >> ~/.bash_logout应为
将以下行追加到~/.bash_logout
clear
reset
一个常见的例外是涉及生成复杂的、特定于系统的输出的命令；例如，genfstab -U /mnt >> /mnt/etc/fstab。
在可能有所帮助的情况下，可以添加指向Help:Reading#Append, add, create, edit的链接。

软件包管理说明

官方软件包
  • 请避免使用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}}。
  • 以上示例还使用了指向install的链接（例如，[[install]]）：建议至少在第一次出现安装请求时使用它，尤其是在更可能被 Arch 新手访问的文章中。
  • 如果软件包托管在core或extra软件仓库中，请勿引用软件仓库：这会增加维护工作量，因为软件包移动到不同的软件仓库并不少见。如果软件包托管在默认情况下未启用的官方软件仓库中（multilib、core-testing 等），则需要提及它，使用类似以下的措辞
安装来自官方 multilib 软件仓库的 foobar 软件包。
AUR 软件包
  • 请避免使用如何安装 AUR 软件包的示例，既不要使用官方方法，也不要提及 AUR 助手。每个安装非官方软件包的用户都应该阅读过Arch User Repository文章，并意识到对其系统的所有可能后果。
相反，只需使用一个简单的语句，例如
安装 foobarAUR 软件包。
您可以灵活地调整措辞以适应您的特定文章。有关更多示例，请参见#官方软件包部分。
  • 指向引用的软件包的链接是强制性的，应使用Template:AUR（例如，{{AUR|foobar}}）创建。
非官方软件仓库
  • 当建议使用非官方软件仓库来安装预构建的软件包时，请勿提供启用软件仓库的说明，而是将软件仓库添加到Unofficial user repositories并在那里链接到它。与官方软件包一样，不要添加pacman命令的示例；例如
从 example 软件仓库安装 foobar 软件包。
如果该软件包在 AUR 中也可用
安装 foobarAUR 软件包，该软件包在 example 软件仓库中也以 builtpackage 提供。
如果该软件包在 AUR 中以不同的名称提供
安装 aurpkgAUR 软件包，该软件包在 example 软件仓库中也以 builtpackage 提供。
您可以灵活地调整措辞以适应您的特定文章。
  • 指向Unofficial user repositories的链接是强制性的，并且应指向相关的软件仓库部分；例如 [[Unofficial user repositories#example|example]]。

systemd 单元操作

  • 不要提供有关如何在 systemd 单元上使用 systemctl 启用、启动或执行任何其他基本操作的示例；而是使用一个简单的句子列出涉及的单元，可能会评论与其他单元的依赖关系或冲突，以及要执行的操作的描述；例如
要在启动时启动 GDM，启用 gdm.service。
或者，例如，如果单元是需要实例化的模板
要在无线接口上启用 netctl 配置文件自动切换，启用 netctl-auto@.service 的实例，并带有接口名称；例如 netctl-auto@wlan0.service。
您可以灵活地调整措辞以适应您的特定文章。

编码风格

  • 在添加命令或脚本时，请在整篇文章中使用一致的编码风格，并可能参考其他文章，尤其是如果存在任何相关文章。如果可用，请遵守该语言的官方或最常见的编码风格指南。
  • 避免使用您正在使用的编程/脚本语言的已弃用功能；例如，对于 shell 命令替换，请使用 $() 语法，而不是反引号/重音符 (``) 语法。
  • 脚本的编写应仅执行以最清晰的方式执行所需任务的最小必要操作。它们不应设计为具有灵活性或可扩展性，首选使用伪变量而不是实际变量。不要添加不相关的功能，例如参数解析或输出格式化。
  • 脚本的添加主要用于教育目的，当文章文本中的详细解释无法充分清晰简洁时。例如，它们对于展示复杂命令的预期用法，或相关或相互依赖的命令的预期工作方式非常有用。
  • 如果脚本被认为可以为文章增加价值，但不符合上述标准，则可以将其外部链接，并可能将其作为 gist 发布。
  • 当表示目录的名称或路径时，请以斜杠结尾或显式添加诸如“目录”或“文件夹”之类的同位语；例如
  • “检查是否已创建 /sys/firmware/efi 目录”，而不是“检查是否已创建 /sys/firmware/efi”。
  • “将 .conf 文件放在 /etc/modules-load.d/ 中”，而不是“将 .conf 文件放在 /etc/modules-load.d 中”。
  • 包含空格的参数应用双引号引起来，例如 cd "foo bar" 而不是 cd foo\ bar。

Shell

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

超文本隐喻

有关内部、跨 Wiki 和外部链接的语法，请参见Help:Editing#Links。

  • 尝试将您的文章与尽可能多的其他文章互连，使用文本中的词语。
  • 仅链接到现有文章。如果遇到死链接，请尝试修复它。似乎已死的外部链接应使用Template:Dead link标记。
  • 尽可能避免隐式链接，首选诸如“有关更多信息，请参见systemd文章”之类的说明，而不是“有关更多信息，请参见此处”。

链接可以通过两种方式使用

  • 作为主题参考，其中链接是一个术语，是运行文本的一部分，并受常规语法规则的约束；如果需要，请使用链接标签。如果可用，内部/跨 Wiki 链接应指向重定向。
  • 作为页面/章节参考，请勿使用链接标签，并根据使用的Template:Lowercase title拼写标题；特别是，不要隐藏同页章节链接中的 # 符号，例如 [[#Hypertext metaphor|Hypertext metaphor]]。

请参见以下示例

主题参考 页面/章节参考
使用 SSH 代理来加速身份验证 按照 SSH keys#SSH agents 来加速身份验证
亚像素渲染受到大多数显示器的支持 按照 Font configuration#Subpixel rendering 中所述启用亚像素渲染
在 initramfs 中包含 密钥文件 说明可以在 dm-crypt/Device encryption#Keyfiles 中找到
请注意，鼠标键默认是禁用的 详情请参阅 Wikipedia:鼠标键
我们有针对链接的样式规则 #超文本隐喻章节有针对链接的样式规则
  • 在文章中编写特定步骤或描述特定内容之前，请务必检查是否已有文章详细介绍了该部分；如果有，请链接到该文章，而不是重复其内容。此外
    • 对于 ArchWiki 文章中未涵盖的技术术语，请链接到相关的维基百科页面。
    • 如果您的文章主题的上游文档编写良好且维护完善，请优先仅编写特定于 Arch 的适配内容，并链接到官方文档以获取一般信息。
例如：“内核参数用于在启动时发出 系统调用；完整列表请参阅 Linux 内核文档。”
总的来说，请与 Help:Reading#组织 保持一致性。
  • 除非在极少数情况下，否则您不应将文章留作死胡同页面（不链接到任何其他文章的文章）或孤立页面（未从任何其他文章链接的文章）。
  • 不要对与被编辑文章语言相同的本地化页面使用跨 wiki 链接，因为它们不会显示在 Special:WhatLinksHere 页面中；例如，在匈牙利语文章中使用 [[:hu:Main page]] 是错误的，而 [[Main page (Magyar)]] 是正确的。
    在不同语言之间使用此类链接是可以接受的，因为如果将来创建单独的 wiki，这将使文章更容易移动到单独的 wiki。
    最后，请注意这些类型的链接与 #跨语言链接 的区别，后者在开头没有冒号。
  • 优先使用 “Wikipedia:” 跨 wiki 前缀，而不是较短的 “w:” 前缀。

手册页

支持的内核版本

  • 不要删除任何关于内核版本的注释或适配，这些内核版本大于或等于当前 core 仓库中 linux-lts 软件包和最新 安装介质 上的内核之间的最低版本。

不相关的内容

  • 请不要在文章中署名，也不要注明文章作者：ArchWiki 是社区的工作成果，每篇文章的历史记录足以说明其贡献者。
    请注意，报告用于编写文章的来源是良好的做法：您可以使用“参见”部分来实现此目的。
  • 普通用户无法上传文件，也不允许在文章中包含图像。作为替代方案，您可以包含外部图像或图库的链接，如果您需要绘制简单的图表，可以使用 ASCII 编辑器，例如 Asciiflow 和 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:Style/Formatting and punctuation#配置参数、变量、选项、属性...。
  • 项目、应用程序、可执行文件等的名称应根据其官方文档风格拼写，尤其是在大小写方面。这包括文档将名称视为普通名词的情况，即在句首出现时首字母大写，否则为小写。如果官方文档未应用一致的风格，请遵循 ArchWiki 中已使用的风格。如果名称未出现在 ArchWiki 中，或者拼写仍然不一致，请选择一种风格并在整篇文章中保持一致，并尽可能更新提及该名称的其他页面。以 Git 为例，在谈论项目/软件时，您可以选择将名称的首字母大写 (“Git”)，而在引用编译后的程序时，则使用全部小写并用斜体 (“git”)。当名称大小写可能引起争议时，请在文章的讨论页中明确定义一种风格。另请参阅 Help:Style/Formatting and punctuation#可执行文件/应用程序名称
  • ArchWiki 优先不使用任何国家/地区的英语变体，而是采用 Wikipedia:Wikipedia:Manual of Style#国家/地区的英语变体 中概述的相同指南；如果与 ArchWiki 的任何其他明确定义的指南发生冲突，则以 ArchWiki 的指南为准。在现有文章中编写新内容时，建议保持文章中已有的 拼写约定；如果文章没有明确的流行拼写，请根据编辑部分中使用的变体进行编写。统一编辑内容周围的拼写是可以接受的；请勿进行主要目的是更改或统一文章或系列文章的拼写标准的编辑。

语言风格

  • 文章应使用正式、专业和简洁的语言编写。应注意通过编辑预览和校对来消除语法和拼写错误。
  • 记住不仅要回答如何，还要回答为什么。解释性信息总是比单纯的指导更能传授知识。
  • 不要省略对于赋予句子确切、明确含义所必需的术语；例如，在提及仓库名称时，请始终添加 “repository” 一词。
  • 不要使用不确定的时间参考，例如 “currently”、“at the time of writing” 或 “soon”；请用明确的表达方式代替，例如 “as of May 2015” 等。
  • 客观地写作：不要在文章中包含个人评论；请使用讨论页来实现此目的。总的来说，不要以第一人称写作。
  • 编辑内容时，请与文章其余部分使用的风格保持一致；例如，如果始终使用第二人称称呼读者，则添加的内容应采用这种风格；如果第三人称或被动语态在整篇文章中明显占主导地位，情况也是如此。
  • 当在不同选项（软件、执行某些操作的方法等）之间提供选择时，请不要明确推荐其中一个选项，而是客观地描述每个选项的优点和缺点，从而帮助读者为他们的个人情况做出最佳决定。
  • 在指代读者或一般人时，优先使用中性代词，例如 they/them。

分类页面

  • 每个分类都必须在至少一个父类别下进行适当的分类，根类别除外，根类别是 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]] 进行比较。
  • 重定向页面应仅包含重定向代码，不包含其他任何内容；唯一的例外是
  • 仅重定向到内部文章；不要使用跨 wiki 重定向。
根据 Help:i18n，并经 ArchWiki:维护团队 授权，异常允许使用跨语言链接进行重定向。

用户页面

  • 用户 命名空间中的页面无法分类。
  • 用户 命名空间中的页面只能从 User 或 talk 命名空间中的其他页面链接，除非管理员授权允许其他链接。
  • 用户 命名空间中的页面不能作为来自其他命名空间的 重定向 的目标。

通用规则

编辑摘要

请参阅 ArchWiki:Contributing#3 项基本规则。

HTML 标签

  • 通常不鼓励使用 HTML 标签；在可能的情况下，始终优先使用 wiki 标记或模板（请参阅 Help:Editing 及相关内容）。
  • 当想要使用 <pre>code</pre> 时，请始终使用 {{bc|code}}。当想要使用 <tt>text</tt> 或 <code>text</code> 时，请始终使用 {{ic|text}}。
  • 尤其要避免使用 HTML 注释 (<!-- comment -->)：添加到 HTML 注释中的注释很可能可以在文章的讨论页中明确显示。
    您可以添加适当的 文章状态模板 来代替注释。
  • 仅在必要时使用 <br>；要开始一个新段落或换行，请在其下方放置一个空行。
    此规则的常见例外情况是，当需要在列表项中换行且无法使用子项时，或者在模板内部且无法使用列表时。
检索自“https://wiki.archlinux.org.cn/index.php?title=Help:Style&oldid=822645”