帮助:风格

来自 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文章。

文章状态模板

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

相关文章框

前言或导言

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

标准章节

“安装”章节
  • 安装章节描述如何安装软件，请参阅#软件包管理说明。
  • 使用标准标题安装，并将其放在文章的早期位置。
“已知问题”章节
  • 已知问题章节用于已知错误或尚无解决方案的使用问题（与#“故障排除”章节进行比较）。
  • 使用标准标题已知问题，并将其放在文章的早期位置。
  • 如果已知问题存在错误报告，则非常希望您提供指向它的链接。如果不存在，您应该自己报告，从而增加错误被修复的可能性。
  • 尽可能避免提及日期或版本号（例如，“截至 2014 年 10 月，Linux kernel 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 仓库获取。
如果软件包在AUR中以不同的名称提供
安装aurpkgAUR 软件包，也可从示例仓库以 builtpackage 的名称获取。
您可以灵活地调整措辞以适应您的特定文章。
  • 指向非官方用户仓库的链接是强制性的，并且应指向相关的仓库部分；例如 [[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:Mouse keys
我们有关于链接的样式规则 #超文本隐喻 章节有关于链接的样式规则
  • 在文章中编写特定步骤或描述特定内容之前，请务必检查是否已有一篇文章详细介绍了该部分；在这种情况下，请链接到该文章，而不是复制其内容。此外
    • 对于 ArchWiki 文章中未涵盖的技术术语，请链接到相关的维基百科页面。
    • 如果您的文章主题的上游文档编写良好且维护良好，则最好只编写特定于 Arch 的适配，并链接到官方文档以获取一般信息。
例如：“内核参数用于在启动时发出系统调用；有关完整列表，请参阅 Linux 内核文档。”
通常，保持与 Help:Reading#Organization 的一致性。
  • 除非在极少数情况下，否则您不应将文章留作死胡同页面（不链接到任何其他文章的文章）或孤立页面（未从任何其他文章链接到的文章）。
  • 不要使用跨 wiki 链接来链接到正在编辑的文章的相同语言的本地化页面，因为它们不会显示在 Special:WhatLinksHere 页面中；例如，在匈牙利语文章中使用 [[:hu:Main page]] 是错误的，而 [[Main page (Magyar)]] 是正确的。
    在不同语言之间使用此类链接是可以接受的，因为如果将来创建单独的 wiki，这将使文章更容易移动到单独的 wiki 中。
    最后，请注意这些链接类型与 #跨语言链接 的区别，后者在开头没有冒号。
  • 首选 “Wikipedia:” 跨 wiki 前缀，而不是更短的 “w:” 前缀。

Man 页面

支持的内核版本

  • 不要删除任何关于内核版本大于或等于当前 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#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: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 命名空间中的页面无法分类。
  • 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>；要开始新段落或换行，请在其下方放置一个空行。
    此规则的常见例外情况是当需要在列表项中换行并且您不能使用子项，或者在模板内部并且您不能使用列表时。
Retrieved from "https://wiki.archlinux.org.cn/index.php?title=Help:Style&oldid=822645"