Help:Procedures

本页收集了在对文章进行复杂更改或其他维护操作时需参考的检查列表。

章节

在同页面内移动章节

移动操作应通过单次编辑完成，且不更改任何其他内容

1. 剪切要移动的文本。此时不要保存页面，即不要分两次编辑完成移动（第一次移除章节，第二次粘贴）——否则在第二次编辑中，你会被视为该章节的作者，特别是在编辑摘要不清晰的情况下。
2. 将剪切的文本粘贴到新位置。
3. 如果需要，可以调整标题级别，但暂时不要对内容进行任何其他修改，否则这些修改在生成的编辑差异（diff）中将不明显。
4. 保存页面，并规范填写编辑摘要。

现在你可以根据需要正常编辑该章节的文本了。

将章节拆分至新子页面

当文章中的某个章节变得过长，需要将其移动到该文章的子页面时，此流程非常有用。

1. 复制整个章节的内容。
2. 在另一个编辑器（另一个浏览器标签页）中打开目标子页面。
3. 将复制的内容粘贴到目标编辑器中，不做任何修改。
4. 保存目标子页面，编辑摘要填写类似 content split from [[原始文章#章节]]。
   • 务必包含指向原始页面的链接，否则你将被视为该内容的作者。
5. 在原始编辑器中，将拆分的内容替换为指向目标子页面的链接。可以保留原章节标题，或在文章的相关文章栏添加链接。
6. 保存原始页面，编辑摘要填写类似 content moved to [[目标子页面]]。
7. 重新在编辑器中打开目标子页面。
8. 为目标子页面添加与原始文章相同的分类。
9. 调整新子页面的标题级别，使其从二级标题（level 2）开始。
   提示： 这一步可以使用 Wiki Monkey 的插件自动完成。
10. 保存目标子页面，并填写规范的编辑摘要。
11. 检查并修复原始页面、目标页面以及链接到原始页面的页面中所有失效的章节链接。
    提示： 这一步可以使用 Wiki Monkey 的插件自动完成。

修复失效的章节链接

由于章节被重命名、合并、移动或删除，页面偶尔会出现失效的章节链接。主命名空间中的所有页面都会定期由 Lahwaacz.bot 进行检查，该机器人会检查所有链接，并在章节链接失效时用 Template:Broken section link 标记。

要修复失效的章节链接，不要直接从 Wiki 中删除该引用，请先进行调查

• 查看章节所在页面的历史记录，该章节可能被重命名、合并、移动或删除了。
• 如果不确定，请使用适当的状态模板标记该章节，而不是直接删除引用。

所有包含失效章节链接的页面都列在 Category:Pages with broken section links 中。

重定向

页面重定向后的讨论页处理

如果页面 A 已重定向到页面 B（例如将 A 的内容合并到了 B），且 Talk:A 存在：

• 如果 Talk:B 不存在，请将整个 Talk:A 移动到 Talk:B，让 MediaWiki 自动将 Talk:A 重定向到 Talk:B。
• 如果 Talk:B 已经存在：
  1. 将 Talk:A 中仍有意义的讨论（如有）移动到 Talk:B。
  2. 确保留在 Talk:A 中的讨论（如有）已经关闭。
     • 如果 Talk:A 中的讨论关闭时间未满 Help:Discussion#Closing a discussion 指定的期限，请为 Talk:A 挂上 Template:Redirect 模板，以便在期限过后将该页重定向至 Talk:B。
     • 否则，请立即将 Talk:A 重定向到 Talk:B。

修复双重重定向

1. 阅读本章节以了解什么是重定向。
2. 查看 Special:DoubleRedirects 检查是否存在此类问题。
3. 例如，如果你看到 Pastebin Clients (编辑) →‎ Common Applications →‎ List of applications，这意味着 Pastebin Clients 重定向到 Common Applications，而后者又重定向到 List of applications。因此，Pastebin Clients 就是一个双重重定向。
4. 要修复它，编辑 Pastebin Clients，将 #REDIRECT [[Common Applications]] 改为 #REDIRECT [[List of applications]] 以跳过中间页面。
5. 输入编辑摘要（如 Fixed double redirect）并保存。

提示： 此任务可以通过 Wiki Monkey 插件自动完成。

在重定向页面上编辑

参见 mw:Help:Redirects#Viewing a redirect。

修复失效的软件包链接

ArchWiki 包含许多指向在官方仓库或 AUR 中均找不到的软件包的失效链接，这是由于软件包被合并、拆分或从仓库中移除导致的。主命名空间中的所有页面都会定期由机器人检查。机器人会检查 AUR、Grp 和 Pkg 模板的所有实例，尝试自动更新它们，并在无法自动更新时使用 Template:Broken package link 标记。

要修复失效的软件包链接，不要直接从 Wiki 中删除对该软件包的引用，请先进行调查

• 搜索软件包数据库 (pacman -Ss) 和 AUR，软件包可能已被合并或重命名。
  • 对于官方仓库中失效的软件包，你还可以搜索此处的提交记录：https://gitlab.archlinux.org/archlinux/packaging/state/-/commits。
  • 对于 AUR 中失效的软件包，你可以查看 aur-request 邮件列表存档。
• 如果是寻找特定文件（例如曾属于该包的二进制文件），使用 pkgfile 可能会有帮助。
• 如果不确定，请使用适当的状态模板标记页面或章节，而不是直接删除引用。

为了辅助手动更新，每个“失效软件包链接”模板都会提供提示

• “invalid number of template parameters”（模板参数数量无效）——所有 AUR、Grp 和 Pkg 模板都只接收一个参数，但 Wiki 文本中指定了多个（或零个）。大多数情况下，多余的参数应移动到周围文本中，或直接删除（如果已存在）。
• “replaced with [其他软件包]”（被替换为……）——该软件包已被重命名或合并到另一个包中，新包的 replaces 数组中指定了旧包名。大多数情况下，只需将旧包名替换为新名，并相应更新周围文本。
• “package not found”（未找到软件包）——以上情况均不适用时的默认提示。

所有包含失效软件包链接的页面都列在 Category:Pages with broken package links 中。此外还有一个自动生成的报告页面：User:Lahwaacz.bot/Reports/archpkgs。

注意： 机器人只更新软件包链接，不会更新周围的文本（周围文本过于依赖上下文）。例如，在 修订版本 308608 中，AUR 链接被改成了 Pkg，但周围文本仍然说该包在 AUR 中。这类情况可以通过直接删除周围关于包位置的描述来修复，从而一劳永逸；另请参阅 Help:Style#Package management instructions。目前我们还没有自动跟踪这类手段，欢迎提供建议。

维护应用列表

Wiki 中有许多应用列表类文章，主要位于 List of applications，但它也链接到包含列表的子页面，例如 PDF, PS and DjVu。由于条目数量巨大，这些列表需要持续维护，以处理条目失效、更改或移动位置等情况。

请参阅上文的 #修复失效的软件包链接，以及在较小程度上参考 #修复失效的章节链接。

条目需要维护的明显标志是死链或失效链接。通常的工作流程如下：

1. 条目是否仍然具有参考价值？
   1. 例如，软盘管理器或令牌环网络工具不再具有参考价值。
   2. 针对已停止服务的工具也是如此，例如 ICQ。
2. 是否仍在维护？
   1. 通常，已存档的仓库会明确提示其已不再维护或已废弃，但如果最后一次提交是在多年前，也可以视为相同情况。
   2. 虽然有些程序被认为已经“完工”且能在未来多年保持运行，但这通常是极少数情况，软件应当由上游积极维护。
   3. 还要考虑软件包的状态。它还能编译吗？是否很快就会失效？如果你发现上游已存档且已无用处（因为已经有了更好的替代方案），你可能还想在 AUR 中为该包提交删除请求。
3. 列表中是否有替代方案？
   1. 即使上游状况不佳但仍可用，你可能也想避免移除列表中（最后几个）仅有的条目。当然，这取决于列表本身的价值。如果列表中所有条目都已彻底失效，保留列表也就没有意义了。

页面移除

修复指向已存档页面的链接

当页面被存档时，ArchWiki:Archive#How to archive a page 中的准则规定，应在存档前移除指向该页面的所有链接。但在某些语境下（尤其是翻译页面，句子的语境不允许在不改变读者体验的情况下直接移除链接），存档时可能未完成此操作。

要修复指向已存档页面的链接，请先进行调查，不要直接从页面中删除链接：

• 通过将指向过时内容的引用替换为其替代内容来调整页面（例如 Special:Diff/704983）。
• 对于翻译页面，如果你能熟练地更新页面，请参考英文页面的处理方式。
• 如果不确定，请使用适当的状态模板标记该章节，而不是直接删除链接。

所有包含指向已存档页面链接的页面都列在 Category:Pages with links to archived pages 中。

移除整个页面

新建但不恰当的页面

• 如果是因为垃圾信息或其他明显的恶意内容（由管理员判定），则会立即删除；
• 在其他情况下（例如与 Arch 无关），该文章应：
  • 标记 Template:Merge（合并），或
  • 标记 Template:Redirect（重定向），或
  • 使用 Template:Move 标记为移动到作者的用户子页面（或直接移动）。

旧文章已过时

1. 按偏好顺序使用以下模板之一进行标记：
   • Template:Merge (合并)
   • Template:Redirect (重定向)
   • Template:Archive (存档).
2. 等待至少 7 天。
3. 如果没有反对意见，或者讨论结果支持移除，则执行建议的操作：
   • 重定向时，请考虑参考 #页面重定向后的讨论页处理 和 #修复双重重定向。
   • 存档时，请遵循 ArchWiki:Archive#How to archive a page 中的说明。

创建一个新页面及其翻译

参见 ArchWiki 翻译团队#创建新页面及其翻译。

将讨论移动到另一个讨论页

1. 将讨论文本复制到目标讨论页，确保在标题和粘贴的文本之间添加如下注释：
   ''[已从 [[原始讨论页#标题]] 移动。-- ~~~~]''
2. 在原始讨论页中划掉标题，并将内容替换为如下注释：
   ''[已移动至 [[目标讨论页#标题]]。-- ~~~~]''

重命名分类

1. 像移动普通页面一样移动分类页面，确保创建从旧标题到新标题的重定向。这只会重命名分类页面本身，分类中的成员不会被重新分类。
2. 将旧分类的所有成员重新分类到新分类中。
   提示： 这可以使用 wiki-scripts 的 recategorize-over-redirect.py 自动完成。它通过旧分类的重定向来检测新名称，因此不局限于大小写更改或类似的简单逻辑。
3. 更新所有跨语言链接。
   提示： 这可以使用 wiki-scripts 的 interlanguage.py 或 Wiki Monkey 的机器人插件自动完成。
4. 更新旧分类的所有反向链接，使其指向新分类。
   提示： 这可以通过在旧分类的 Special:WhatLinksHere 页面上运行 Wiki Monkey 的 RegExp substitution（正则替换）插件来自动完成，替换规则类似 (\[\[|\{\{Related2?\|):[ _]*[Cc]ategory[ _]*:[ _]*[Oo]ld[ _]name[ _]*(#|\||\]\]|\}\}) -> $1:Category:New name$2（假设旧分类名为 "Category:Old name"）。
5. 用 Template:Archive 标记旧分类，不要破坏重定向（旧分类可能仍被目录链接）。
   提示： 如果该分类没有重要的历史记录，管理员可以在确保已执行第 2-4 步后将其删除。

巡查

任何人都可以查看最近更改。但只有 维护团队 成员可以将编辑和页面标记为已巡查。本章节主要讨论任何人都能参与的工作。

请记住，巡查最近更改需要更持久的投入，而修复其他内容则更灵活，随时有空都可以做。

最近更改巡查

主要有两种巡查最近更改的方法：

• 定期访问 Special:RecentChanges，检查自上次访问以来的所有编辑。
• 订阅 Special:RecentChanges Atom feed，一有时间就检查编辑。

对于每一项编辑或对同一页面的多项编辑，你应该根据经验和知识评估其是否可疑，同时参考常见问题列表。

• 如果你认为该编辑需要可以立即完成的简单修复，那就动手去做。这尤其适用于细微的样式问题、错别字和语法修复。
• 如果编辑可疑但你无法修复，应查看是否已挂上适当的状态模板。
  • 如果没有，请在相应章节添加描述问题的模板。
  • 如果已经有了针对该编辑的讨论，看看你是否能为随附的注释或讨论提供有用的细节。

提示： 通过以下步骤使巡查更轻松：

• 在“参数设置 > 最近更改 > 高级选项”中启用“在最近更改和监视列表中按页面对更改分组”。
• 要使用 Feed 阅读器跟踪你监视的文章，请使用监视列表页面左栏中的 Atom 链接。

机器人编辑

默认情况下，MediaWiki 在最近更改中不显示机器人的编辑。检查机器人修改过的页面是有意义的，因为这可能意味着需要进一步的人工更改。机器人会标记失效的软件包链接、失效的章节链接和死链。

强烈建议在这些标记出现后尽快修复，以免它们淹没在大量的更改中。这同样适用于死链，通常是外部资源。

常见问题及解决方案

注意： 你随时可以寻求 维护团队 的帮助。

滥用

幸运的是，垃圾信息和其他违反行为准则的行为并不多见，但偶尔仍会发生。

最重要的任务在这里也适用。确保立即打击滥用行为：

1. 首先，撤销所有破坏。
2. 联系 维护团队。你也可以加入 ArchWiki IRC 频道 并呼叫管理员（通常是所有频道管理员）。

如果是大规模滥用，且撤销破坏耗时太长，请先报告。

内容相关

• 移除有用内容：撤销或联系作者。
• 无解释修改或移除内容：联系作者，若无反应则撤销。
• 在没有充分解释的情况下进行重大修改（通常是单次大批量编辑）：联系作者。

样式相关

• 文章中的签名、致谢、个人见解：撤销或移动到讨论页。
• 标题从一级（level 1）开始：将所有章节提升一级。
• 未分类的新文章：添加分类并修复页眉。
• 错误使用模板：根据 Help:Style 进行修复。
• 添加安装说明：撤销或使其符合 Help:Style。

MediaWiki 巡查功能

注意： 此功能仅供 维护团队 成员使用。

将更改标记为“已巡查”是避免重复劳动的非常有效的方法。鼓励每位维护团队成员利用此功能来节省他人的时间。

有时，尤其是对某个主题不熟悉时，不确定是否应将编辑标记为已巡查。不标记为已巡查意味着其他维护团队成员更有可能查看该更改。以下是一些帮助巡查更多更改的建议：

• 拼写、语法或语言错误通常很容易验证。尽可能先处理这些。
• 讨论页的新内容如果合情合理（符合主题，例如在 archiso 页面讨论游戏就不合适），可以标记为已巡查。
• 用户页面可以包含任何内容，只要不违反规则。遗憾的是，它们基本上不受大多数样式指南的约束。
• 任何开发者都可以在 DeveloperWiki 中进行任何操作。
• 如果不懂相应的语言，翻译很难检查。可以使用 DeepL 检查翻译是否大致正确。检查新用户的翻译有助于发现低质量编辑和破坏行为。
• 人非圣贤。如果用户意识到自己的错误并撤销了自己的编辑，可以将这两次编辑都标记为已巡查。
• 将已被维护团队成员回退的编辑标记为已巡查，因为回退者可能只是忘了标记。
• 新页面可能不完整或存在样式问题。如果内容适合 ArchWiki，请将其标记为已巡查。考虑监视该页面，并确保在它被弃置时进行处理。

所有这些点都以更改不违反行为准则或 ArchWiki:Contributing 中描述的规则为前提。

其他

还有其他需要注意的事项：

• 检查新创建的账号列表，看是否有账户已经开始编辑。新编辑者的修改应当总是被检查，因为他们可能还不熟悉所有指南。
• 确保在讨论页添加的内容都有签名。
  • 有时，用户不知道讨论页上有“添加话题”按钮。确保新讨论放在底部并有合适的章节名称。
  • 如果编辑摘要看起来像 →某些章节: 新章节，说明用户使用了“添加话题”按钮。
  • 如果某个用户一直手动添加新章节，可以提醒他们使用更方便的“添加话题”按钮。
• 内容清空（blanking）和差异巨大的编辑应始终进行调查。
• 新页面也值得关注，改进它们并修复样式问题可以树立良好榜样并帮助作者。
• 确保修改表格的编辑没有破坏表格，例如插入了多余的列。
• 没有规范编辑摘要的编辑需要特别注意。如果用户没有规范使用编辑摘要，可以使用 Template:Editsum 提醒。
• 撤销操作（Undo）很常见，但仍应检查。

处理请求

参见 ArchWiki talk:Requests。

• 如果你认为自己可以解决该请求，直接操作并移除相应的模板即可。另请参阅 #常见问题及解决方案。
• 或者，如果你觉得最好联系该可疑编辑的作者，请在他们的讨论页留言，或发送电子邮件以请求解释或进一步讨论。

提示

• 优先处理时间最久的请求。
• 优先修复内容相关问题，而非样式相关问题。
• 你可以考虑使用编辑器辅助工具（如 Wiki Monkey 的 Editor 配置）来自动解决一些常见的样式问题。