跳转至内容

帮助:风格

来自 ArchWiki

相关文章

这些风格规范鼓励保持文章整洁、有条理且视觉上一致。在编辑 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文章。

文章状态模板

  • 指代整篇文章的状态模板必须放在分类（或存在的跨语言链接）下方、引言（或存在的相关文章框）上方。
  • 指代文章特定部分的 are 状态模板必须尽可能放置在该部分上方，同时适当避免破坏段落、代码块或其他预先存在的模板。
  • 始终在专用字段中附带一些解释性文字来伴随文章状态模板（每个模板页面都提供了示例），甚至可以开启讨论页面进行讨论。

前言或介绍

  • 放在文章第一个章节的上方。
请勿明确创建== Introduction ==或== Preface ==章节：让它出现在第一个章节标题上方。当文章中有足够多的章节时，目录会在前言和第一个章节之间自动显示。
  • 描述文章的主题。
与其转述或写您自己（可能带有偏见）的软件描述，不如使用上游作者的描述，通常可以在项目的首页或关于页面上找到（如果存在）—一个例子是WireGuard。您也可以使用 Wikipedia 上的描述，例如 ImageMagick。

有关更多信息，请参阅Help:Writing article introductions。

标准章节

“安装”章节
  • Installation 章节描述了如何安装软件，请参阅#Package management instructions。
  • 使用标准标题Installation，并将其放在文章靠前的位置。
“已知问题”章节
  • Known issues 章节用于描述尚未解决的已知错误或使用问题（与“疑难解答”章节进行比较）。
  • 使用标准标题Known issues，并将其放在文章靠前的位置。
  • 如果已知问题存在 bug 报告，强烈建议您提供链接。如果不存在，您应该自己报告，从而增加 bug 被修复的机会。
  • 尽可能避免提及日期或版本号（例如，“Linux kernel 3.17 自 2014 年 10 月起仍不支持设备 XYZ”）。同样，优先链接 bug 报告等参考资料以获取后续信息。
“技巧与窍门”章节
  • Tips and tricks 章节提供关于使用该软件的高级技巧或示例。
  • 使用标准标题Tips and tricks。
  • 各种技巧和窍门应组织在子章节中。
“疑难解答”章节
  • Troubleshooting 章节用于回答关于软件的常见问题或提供常见问题的解决方案（与“已知问题”章节进行比较）。
  • 使用标准标题Troubleshooting。应避免的常见拼写错误包括 Trouble shooting、Trouble-shooting 和 TroubleShooting。
  • 您也可以报告已知 bug 的临时解决方法；在这种情况下，您必须提供 bug 报告的链接（或类似的适当来源，如包含解决方法的论坛帖子）。如果尚未报告，您应该自己报告，从而增加 bug 被正确修复的机会。
    尽可能避免提及日期或版本号。链接到 bug 报告等外部参考资料对读者和编辑都有很大好处。
    • 对读者而言，Wiki 不会成为终点：他们可以在接近来源的地方找到更多信息，而这些信息可能因他们的搜索工作而被忽略。
    • 对 Wiki 编辑者而言，通过减少研究某个报告的 bug 是否仍然存在的问题所需的工作，可以使清理工作更轻松；这甚至可能带来更大的自主性，如果读者找到新信息并回来编辑 Wiki。
“参见”章节
  • See also 章节包含指向参考资料和附加信息来源的链接列表。
  • 这应该是一个列表，其中每个条目都以*开头，这会创建一个 MediaWiki 项目符号列表。
  • 使用标准标题See also，并将其放在文章的最后。应避免其他类似的标题，如External links、More resources等。

章节标题

  • 标题应从级别 2（==）开始，因为级别 1 保留给文章标题。
  • 创建子章节时不要跳过级别，因此级别 2 的子章节需要级别 3 的标题，依此类推。
  • 标题使用句子大小写，而不是标题大小写：My new heading，而不是 My New Heading。
  • 避免在标题中使用链接，因为它们会破坏风格一致性且不够突出。通常，锚文本也出现在章节内容中，否则您可以使用一个简单的句子，例如：
有关更多信息，请参阅Some related article。
出于同样的原因，也应避免使用任何 HTML 或 wiki 标记代码，包括#Code formatting模板。另请参阅 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）

注释、警告、提示

  • 应使用Note来提供在文章的某个点上，信息在某种程度上与用户自然预期不符的内容。这包括提供关于某个在文章中可能被视为有点不必要的、更深入的知识的信息。另一个例子是当需要指出一个临时公告时，例如软件包名称的更改。
Note 也可以用来强调重要但不易被新手忽略的信息。
  • 应使用Warning来描述可能带来严重后果的程序，例如难以撤销或导致系统损坏。警告通常应指明最坏情况，以及导致或避免这些最坏情况的条件。
总的来说，请勿滥用 Warnings：如果您犹豫不决，很可能应该使用 Note。
  • 应使用Tip来指示一个对某人有益的方法或程序，尽管完成所处理的操作并非必需，因此可以安全地忽略。
  • 当两个或多个注释、警告或提示必须在文章的同一点连续出现时，请优先将它们的文本分组在单个模板内的列表中，避免堆叠模板，除非它们完全不相关；例如：
提示
  • 提示示例 #1。
  • 提示示例 #2。

表格

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

  • 表格通常应具有wikitable类。
  • 比较表应另外具有sortable类。
  • 在适当的情况下，请使用表头和表格单元格模板。
  • 表头应使用句子大小写。
  • 表格说明应使用定义列表，并放在表格之前。
  • 脚注或备注应使用<sup>1</sup>、<sup>2</sup>等，并在表格下方使用有序列表，而不是Unicode字符。

操作指南

文件编辑请求

  • 在请求文本文件编辑时，除非必要，否则请不要假定使用特定的文本编辑器（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的链接。

软件包管理说明

  • 所有软件包管理说明都应使用简单的陈述句，而不是示例命令。
  • 推荐使用install重定向或其变体（例如[[install]]ed），至少在第一次出现安装请求时。
  • 涉及的软件包（或多个软件包、软件包组）必须被链接，最好是不带变体（通常用后缀表示，如-bin、-git或-nightly），除非它们提供有意义的区别。
  • 您可以根据具体文章调整措辞，有关更多示例，请参阅#Official packages部分。
官方软件包
  • 避免提供安装官方软件包的pacman命令示例：既是为了简洁起见（每个 Arch 用户都应该凭记忆知道pacman的文章），也是为了避免pacman -Sy package之类的错误，或关于在pacman -S package和pacman -Syu package之间选择的无休止的讨论。更不用说您不应建议使用pacman前端或包装器。
相反，只需使用简单的陈述句，例如：
安装 foobar 软件包。
或者，例如应用程序名称与软件包名称不同时：
MyApplication 可以通过 my-app-pkg 软件包进行安装。
一系列软件包的安装说明可以如下显示：
安装 foobar1、foobar2 和 foobar3 软件包。
如果指的是软件包组，可以使用：
安装 foobar 组。
引用软件包组时，请使用Template:Grp；例如，{{Grp|foobar}}。
  • 如果软件包托管在core或extra仓库中，请勿提及仓库：这会增加维护成本，因为软件包经常会被移动到不同的仓库。如果软件包托管在默认未启用的官方仓库中（multilib、core-testing等），则需要提及，使用如下措辞：
从官方multilib仓库安装 foobar 软件包。
AUR 软件包
  • 避免提供安装 AUR 软件包的示例，无论是使用官方方法还是提及 AUR 助手。所有安装非官方软件包的用户都应该阅读Arch User Repository文章，并了解其系统上所有可能的后果。
相反，只需使用简单的陈述句，例如：
安装 foobarAUR 软件包。
非官方仓库
  • 当建议使用非官方仓库安装预构建软件包时，请勿提供启用该仓库的说明，而是将该仓库添加到Unofficial user repositories并链接到相关仓库部分；例如[[Unofficial user repositories#example|example]]。
  • 与官方软件包一样，不要添加pacman命令的示例；例如：
从 example 仓库安装 foobar 软件包。
如果软件包也可用在AUR中：
安装 foobarAUR 软件包，该软件包也可用在 example 仓库中。
如果软件包在AUR中有不同的名称：
安装 aurpkgAUR 软件包，也可从 example 仓库以builtpackage形式安装。

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（例如 Bash），除非确实需要；在撰写或编辑文章时，尽量保持 shell 的中立性。

超文本隐喻

有关内部链接、站内链接和外部链接语法的详情，请参阅 Help:Editing#Links。

  • 尝试将您的文章与尽可能多的其他文章进行互链，方法是使用文本中的词语。
  • 仅链接到现有文章。如果您遇到死链接，请尝试修复。外观上像死链接的外部链接应使用 Template:Dead link 标记。
  • 尽可能避免隐式链接，优先使用“有关更多信息，请参阅 systemd 文章”之类的说明，而不是“有关更多信息，请参阅 此处”。

链接的用法有两种：

  • 作为主题引用，其中链接是一个词语，是正文的一部分，并遵循常规语法规则；如有需要，请使用链接标签。内部/站内链接应指向重定向页（如果可用）。
  • 作为页面/章节引用，请勿使用链接标签，并根据 Template:Lowercase_title 中的规定拼写标题；特别是，在同一页面内的章节链接中，请勿隐藏 # 符号，例如 [[#Hypertext metaphor|Hypertext metaphor]]。

请参阅这些示例：

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

手册页

支持的内核版本

  • 请勿删除与内核版本大于或等于 core 仓库中当前 linux-lts 包和最新 安装媒体上的内核之间的最小版本相关的任何注释或调整。

不相关内容

  • 请勿签署文章，也不要署名文章作者：ArchWiki 是社区的劳动成果，每篇文章的历史记录足以表彰其贡献者。
    请注意，报告用于撰写文章的来源是良好的做法：您可以为此目的使用“另请参阅”部分。
  • 普通用户无法上传文件，文章中也不允许包含图片。作为替代，您可以包含指向外部图片或图库的链接，如果您需要绘制简单的图表，可以使用类似 Asciiflow 和 Template:Text art 这样的 ASCII 编辑器；理由如下：
    • 维护：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#Configuration parameters, variables, options, properties...。
  • 项目、应用程序、可执行文件等的名称，尤其是大小写，应主要根据其官方文档的风格来拼写。这包括官方文档将名称视为普通名词的情况，即句子开头时首字母大写，其他情况小写。如果官方文档没有采用一致的风格，请遵循 ArchWiki 中已有的风格。如果名称未出现在 ArchWiki 中，或拼写仍不一致，请选择一种风格并在文章中保持一致，同时可能更新提及该名称的其他页面。以 Git 为例，您可以选择在一般性地谈论项目/软件时将名称首字母大写（“Git”），而在提及编译后的程序时使用全小写并斜体（“git”）。当名称的大小写可能引起争议时，请在文章的讨论页中明确定义风格。另请参阅 Help:Style/Formatting and punctuation#Executable/application names。
  • ArchWiki 倾向于不偏向任何特定国家的英语变体，遵循 Wikipedia:Wikipedia:Manual of Style#National varieties of English 中概述的相同指南；如果与其他 ArchWiki 明确定义的指南发生冲突，ArchWiki 的指南优先。在现有文章中撰写新内容时，建议保持其中已普遍存在的拼写约定；如果文章没有明确的普遍拼写，请按照所编辑部分的变体进行书写。对编辑内容周围的拼写进行协调是可以接受的；请避免进行主要目的是更改或协调文章或一系列文章的拼写标准的操作。

语言风格

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

分类页面

  • 分类名称必须使用句子大小写。
  • 每个分类都必须至少被一个父分类正确分类，根分类除外，它们是：
  • 一个分类可以被归类到多个分类下，前提是其中一个不是另一个的祖先。
  • 避免循环关系：两个分类不能互相成为祖先。
  • 请勿将一个分类归类到自身（自归类分类）。
  • 分类必须包含在分类页面的顶部。
  • 分类不应重定向，除非是在重命名期间暂时进行的。
  • 默认情况下，分类名称应为单数形式（“主题”分类，例如 Category:Simulation）；如果单数形式可用于描述其成员的一个（“集合”分类，例如 Category:Boot loaders），则应使用复数形式。

重定向页面

  • 鼓励为现有文章标题的缩写或语法变体，或更泛泛的文章子主题创建重定向页面；例如 ALSA、daemon 或 AIGLX。重定向可以简化源文本，通过替换带标签的链接，比较前面的示例与 [[Advanced Linux Sound Architecture|ALSA]]、[[daemons|daemon]] 或 [[Xorg#Composite|AIGLX]]。
  • 重定向页面只应包含重定向代码，不应包含其他任何内容；唯一的例外是：
  • 仅重定向到内部文章；请勿使用站间重定向。
根据 Help:i18n，允许使用跨语言链接进行重定向，但这需要 ArchWiki:Maintenance Team 的授权。

用户页面

  • 位于 User 命名空间下的页面不能被分类。
  • 位于 User 命名空间下的页面只能从 User 或 talk 命名空间下的其他页面链接，除非获得管理员的授权。
  • 位于 User 命名空间下的页面不能被其他命名空间下的 重定向指向。

通用规则

编辑摘要

请参阅 ArchWiki:Contributing#The 3 fundamental rules。

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=848523"