跳转至内容

帮助:程序

来自 ArchWiki

这是一系列在对文章进行复杂修改或其他维护操作时应遵循的检查清单。

章节

在同一页面内移动章节

移动操作应在单次编辑中完成，且不得包含任何其他修改。

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

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

将章节拆分至新子页面

当文章的某个章节变得过长，需要移至该文章的子页面时，此程序非常有用。

  1. 复制整个章节的内容。
  2. 在另一个编辑器（浏览器标签页）中打开目标子页面。
  3. 将复制的内容粘贴到目标编辑器中，不要进行任何修改。
  4. 保存目标子页面，使用类似 从 [[原文章#章节]] 拆分内容 的编辑摘要。
    • 确保包含指向原页面的链接，否则你会被视为内容的作者。
  5. 在原编辑器中，用指向目标子页面的链接替换已拆分的内容，可以选择保留原章节标题，或者在文章的相关文章框中添加链接。
  6. 保存原页面，使用类似 内容已移动至 [[目标子页面]] 的编辑摘要。
  7. 在编辑器中重新打开目标子页面。
  8. 像原文章一样为目标子页面添加分类。
  9. 调整新子页面的标题级别，使其从二级标题开始。
    提示 此步骤可以通过 Wiki Monkey 插件自动完成。
  10. 使用规范的编辑摘要保存目标子页面。
  11. 检查并修复原页面和目标页面中任何损坏的章节链接，以及链接到原页面的其他页面中的链接。
    提示 此步骤可以通过 Wiki Monkey 插件自动完成。

页面中偶尔会出现损坏的章节链接，这是由于章节被重命名、合并、移动或从页面中删除导致的。主命名空间中的所有页面都会由 Lahwaacz.bot 定期检查，该机器人会检查所有链接，并在发现章节链接损坏时为其添加 Template:Broken section link 模板。

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

  • 查看章节所在页面的历史记录，该章节可能已被重命名、合并、移动或删除。如果改动不明显，请参阅 #将修订历史视为 git 仓库。
  • 如果不确定，请为该章节添加适当的 状态模板，而不是直接删除对该章节的引用。

所有包含损坏章节链接的页面都会在 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 中留下的讨论（如有）已经关闭。

修复双重重定向

  1. 阅读 本章节 以了解什么是重定向。
  2. 查看 Special:DoubleRedirects 以查看是否存在双重重定向。
  3. 例如，如果你看到 Pastebin Clients (Edit) →‎ Common Applications →‎ List of applications，这意味着 Pastebin Clients 重定向到 Common Applications，而 Common Applications 又重定向到 List of applications。因此，Pastebin Clients 是一个双重重定向。
  4. 修复方法是编辑 Pastebin Clients，并将 #REDIRECT [[Common Applications]] 修改为 #REDIRECT [[List of applications]] 以绕过中间层。
  5. 输入类似 修复双重重定向 的编辑摘要并保存。
提示 此任务可以通过 Wiki Monkey 插件自动完成。

在重定向页面上进行编辑

请参阅 mw:Help:Redirects#Viewing a redirect。

将修订历史视为 git 仓库

本文或本节需要在语言、wiki 语法或风格方面进行改进。请参阅 Help:Style 获取参考。

原因：该章节不适合出现在此页面（它不是一个操作程序）。（在 Help talk:Procedures#Revision history as a git repository 中讨论）

你可以将 页面修订 保存为 git(1) 提交记录 (commits)，然后使用传统的 Git 工具——例如 git-bisect(1)、git-blame(1)、git-log(1) 等——进行历史调查。例如，参阅 Gitify MediaWiki。

参见

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

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

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

  • "invalid number of template parameters" — 所有 AUR、Grp 和 Pkg 模板都需要且仅需要一个参数，但 Wikitext 中指定了更多（或没有）参数。在大多数情况下，多余的参数应移动到周围文本中，或者如果已存在则直接删除。
  • "replaced with [other package]" — 软件包已被重命名或合并到另一个软件包中，后者在 replaces 数组中指定了旧的包名。在大多数情况下，旧的包应直接替换为新的，并相应更新周围的文本。
  • "package not found" — 当上述情况均不适用时的默认提示。

所有包含损坏软件包链接的页面都会在 Category:Pages with broken package links 中追踪。还有一个自动报告页面：User:Lahwaacz.bot/Reports/archpkgs。

注意 机器人仅更新软件包链接，不会更新其周围的文本，因为这涉及上下文敏感。例如，在 修订版 308608 中，AUR 链接更改为了 Pkg，但周围文本仍然写着该软件包在 AUR 中。可以通过简单地删除描述软件包来源的周围文字来修复并“面向未来地”解决这些情况；另请参阅 Help:Style#Package management instructions。目前我们还没有自动跟踪此类问题的办法，欢迎提出建议。

应用程序列表的维护

有很多关于应用程序列表的文章，主要位于 List of applications，但它也链接到包含具体列表的子页面，例如 PDF, PS and DjVu。由于条目数量巨大，这些列表需要持续维护，以解决条目变得无关、失效、更改或移动到其他地方的问题。

请参阅上方的 #修复损坏的软件包链接，在较小程度上也请参阅 #修复损坏的章节链接。

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

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

页面移除

当页面归档时，ArchWiki:Archive#How to archive a page 中的指南规定，所有指向该页面的链接在归档前应被移除。在某些情况下（特别是对于翻译，如果句子上下文不允许在不改变读者阅读体验的情况下简单移除链接），归档时可能不会这样做。

要修复指向已归档页面的链接，不要在未经调查的情况下简单地从页面移除链接。

  • 通过将对过时内容的引用替换为其替代内容来调整页面（例如 Special:Diff/704983）。
  • 对于你足够精通并可以更新页面的翻译（或者对于没有语法错误风险的简单替换），请遵循英文页面的做法。
  • 如果不确定，请为该章节添加适当的 状态模板，而不是直接删除链接。

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

移除整个页面

新建但不合适的页面

  • 如果因垃圾邮件或其他明显的恶意内容而不合适（由管理员评估），则立即删除；
  • 在其他情况下，例如与 Arch 无关，文章应：

旧文章变得过时

  1. 按优先顺序标记为以下之一：
  2. 至少等待 7 天。
  3. 在没有反对讨论的情况下，或者当这些讨论最终达成移除共识时，执行建议的操作。

创建一个新页面及其翻译

请参阅 ArchWiki Translation Team#Create a new page and its translation。

将讨论移动到其他讨论页

  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 后，可以由管理员删除。

巡查

任何人都可以检查 最近更改。不过，维护团队成员还可以将编辑和页面标记为 已巡查。本节主要介绍每个人都能做的事情。

请记住，巡查最近更改显然需要更持续的投入，而修复其他问题则更灵活，随时都可以进行。

最近更改巡查

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

对于每一项编辑（或对同一页面的一组编辑），你应根据自己的经验和知识，并考虑到最常见的问题列表，评估其是否有问题。

  • 如果你认为该编辑需要一个你可以立即执行的快速修复，那就直接做吧。这尤其适用于细微的格式问题、错别字和语法修正。
  • 如果编辑存在问题但你无法修复，请查看它是否已经被标记为适当的 状态模板。
    • 如果没有，请在该章节添加描述该问题的适当模板。
    • 如果有关于该编辑的现有讨论，看看能否在随附的说明或讨论中补充有用的细节。
提示 通过执行以下步骤，可以使巡查更轻松：
  • 在 参数设置 > 最近更改 > 高级选项 中启用 在最近更改和监视列表中按页面分组显示更改 设置。
  • 要使用订阅源阅读器关注你的监视列表，请使用 监视列表 页面左侧栏中的 Atom 链接。

机器人编辑

MediaWiki 默认不在最近更改中显示由 机器人 所做的编辑。有时检查机器人何时修改了页面是有必要的，因为它可能表明需要进一步的改动。机器人会标记 损坏的软件包链接、损坏的章节链接 和死链接。

强烈建议在这些标记的内容被大量改动淹没之前，尽快对其进行修复。这也适用于通常属于外部资源的死链接。

常见问题与解决方案

注意 你可以随时向 维护团队 请求帮助。

滥用

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

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

  1. 首先也是最重要的，撤销所有破坏行为。
  2. 联系 维护团队。你也可以通过加入 ArchWiki IRC 频道 并提及管理员（他们通常都是频道管理员）来联系。

如果存在大规模滥用，且撤销破坏会给滥用者更多的时间采取行动，请先报告。

内容相关

  • 移除有用内容：撤销或联系作者。
  • 无法解释的修改或内容移除：联系作者，若无回应则撤销。
  • 重大修改（通常是在单次大批量编辑中）且没有充分说明：联系作者。
  • 文章中的签名、致谢、个人观察：撤销或移至讨论页。
  • 标题从 1 级开始：将所有章节上提 1 级。
  • 未分类的新文章：添加分类并修复标题。
  • 模板使用不当：根据 Help:Style 进行修复。
  • 添加安装说明：撤销或使其符合 Help:Style。

MediaWiki 巡查功能

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

将更改标记为已巡查是一种避免在不必要时重复工作的非常有用的方法。鼓励每位维护团队成员使用此功能，以节省他人的时间。

有时，特别是当某人对某个话题没有经验时，不清楚是否应该将编辑标记为已巡查。不标记为已巡查意味着其他维护团队成员更有可能查看该更改。以下是一些有助于巡查更多更改的提示：

  • 错别字、语法或语言修正通常非常容易验证。如果可能，请优先处理它们。
  • 如果讨论页的添加内容是有意义的（与主题相关，例如在关于 archiso 的页面上讨论游戏是不合适的），则可以将其标记为已巡查。
  • 用户页面可以包含任何内容，只要不违反任何规则。不幸的是，它们基本上不受大多数格式指南的约束。
  • 任何 开发者 都可以做任何事情在 DeveloperWiki 中。
  • 如果不知道相关语言，翻译很难检查。可以使用 DeepL 来检查翻译是否大致正确。检查非常新的用户的翻译有助于发现低质量的编辑和破坏行为。
  • 错误在所难免。如果用户注意到了自己的错误并撤销了自己的编辑，将这两者都标记为已巡查是可以的。
  • 将由维护团队成员撤销的编辑标记为已巡查，因为撤销该编辑的人很可能只是忘了标记。
  • 新页面可能不完整和/或有格式问题。如果它符合 ArchWiki，就将其标记为已巡查。考虑监视该页面，并确保在它被遗弃时进行照顾。

所有这些观点都意味着该更改不得违反行为准则或 ArchWiki:Contributing 中描述的规则。

其他

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

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

请求处理

请参阅 ArchWiki talk:Requests。

  • 如果你认为你可以修复请求，那就直接做并移除适当的模板。另请参阅 #常见问题与解决方案。
  • 否则，如果你觉得联系有问题的编辑作者更好，请在他们的讨论页写一条信息，或给他们发送电子邮件，以请求解释或进一步讨论。
提示
  • 优先尝试解决最旧的请求。
  • 优先修复内容相关问题，而非格式相关问题。
  • 你可以考虑使用编辑器助手（例如 Wiki Monkey 的 Editor 配置）来自动解决一些常见的格式问题。
取自 "https://wiki.archlinux.org.cn/index.php?title=Help:Procedures&oldid=864425"

© . This site is unofficial and not affiliated with Arch Linux.

Content is available under GNU Free Documentation License 1.3 or later unless otherwise noted.