帮助:程序
一系列清单,用于在对文章进行复杂更改或执行其他维护操作时使用。
章节
在同一页面内移动章节
移动应在一次编辑中完成,并且不更改其他任何内容。
- 剪切要移动的文本。现在不要保存页面,也就是说,不要分两次编辑来执行移动——第一次删除章节,第二次粘贴——否则在第二次编辑时,您将看起来像是该章节的作者,特别是当编辑摘要不清晰时。
- 将剪切的文本粘贴到新的位置。
- 如有需要,调整标题级别,但暂时不要对内容进行任何其他调整,否则修改将不会在生成的编辑差异中显示。
- 保存页面,并正确撰写编辑摘要。
现在您可以根据需要正常编辑章节文本了。
将章节拆分到新子页面
当一篇文章过长,需要将其某个章节移动到一个子页面时,此过程非常有用。
- 复制整个章节内容。
- 在另一个编辑器(另一个浏览器标签页)中打开目标子页面。
- 将复制的内容粘贴到目标编辑器中,不做任何修改。
- 使用类似
content split from [[Origin article#Section]]的编辑摘要保存目标子页面。- 请确保包含指向原始页面的链接,否则会看起来像是您是内容的作者。
- 在原始编辑器中,将拆分的内容替换为指向目标子页面的链接,可以保留章节标题,也可以添加一个指向文章相关文章框的链接。
- 使用类似
content moved to [[Destination subpage]]的编辑摘要保存原始页面。 - 在编辑器中重新打开目标子页面。
- 像原始文章一样为目标子页面添加分类。
- 调整新子页面的标题级别,使其从二级开始。提示 此步骤可以使用 Wiki Monkey 的插件自动完成。
- 使用合适的编辑摘要保存目标子页面。
- 检查并修复原始页面和目标页面中,以及链接到原始页面的页面中所有损坏的章节链接。提示 此步骤可以使用 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 存在。
- 将 Talk:A 中仍然相关的讨论(如果有)移动到 Talk:B。
- 确保 Talk:A 中留下的讨论(如果有)被关闭。
- 如果 Talk:A 托管了已关闭少于 Help:Discussion#Closing a discussion 中指定的时期的讨论,则用 Template:Redirect 标记 Talk:A,以便在关闭期结束后,该页面将被重定向到 Talk:B。
- 否则,立即将 Talk:A 重定向到 Talk:B。
修复双重重定向
- 阅读本节以了解重定向是什么。
- 查看 Special:DoubleRedirects 以查看是否存在任何双重重定向。
- 例如,如果您看到
Pastebin Clients (Edit) → Common Applications → List of applications,这意味着 Pastebin Clients 重定向到 Common Applications,而 Common Applications 重定向到 List of applications。因此,Pastebin Clients 是一个双重重定向。 - 要修复它,请编辑 Pastebin Clients 并将
#REDIRECT [[Common Applications]]更改为#REDIRECT [[List of applications]]以跳过中间环节。 - 输入一个类似
Fixed double redirect的编辑摘要并保存。
编辑重定向页面
参见 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 可能会派上用场。
- 如果不确定,请使用合适的状态模板标记页面或章节,而不是完全删除对软件包的引用。
为了帮助手动更新,每个“损坏的软件包链接”模板都提供了一个提示。
- "无效的模板参数数量" — 所有 AUR、Grp 和 Pkg 模板都接受一个参数,但 wiki 文本指定了更多(或无)参数。在大多数情况下,多余的参数应移至周围的文本,或在已存在的情况下删除。
- "替换为 [其他软件包]" — 该软件包已被重命名或合并到另一个软件包中,该软件包在 replaces 数组中指定了旧软件包名称。在大多数情况下,旧软件包应简单地替换为新软件包,并相应地更新周围文本。
- "未找到软件包" — 当以上情况都不适用时的默认提示。
所有带有损坏软件包链接的页面都跟踪在Category:Pages with broken package links 中。还有一个自动报告页面在 User:Lahwaacz.bot/Reports/archpkgs。
应用程序列表的维护
有一些应用程序列表文章,主要在 List of applications,但也链接到包含列表的子页面,例如 PDF, PS and DjVu。由于数量庞大,列表需要持续维护,因为条目会变得不相关、损坏、更改或移动到其他位置。
参见#Fix broken package links,以及在较小程度上#Fix broken section links。
需要维护的条目的明显迹象是死链接或损坏的链接。常见的流程如下:
- 条目是否仍然相关?
- 例如,软盘管理器或令牌环网络工具已不再相关。
- 服务已停止运行的工具也一样,例如 ICQ。
- 它是否仍在维护?
- 通常,存档的存储库也包含明确的提示,表明它已停止维护并已被弃用,但如果最后一次提交是在多年前,则被视为相同情况。
- 虽然有些程序被认为是完成的,并且将在未来几年内保持工作状态,但这通常是特殊情况,软件应由上游积极维护。
- 同时考虑软件包的状态。它是否可以构建?它是否很快会损坏?如果您发现上游已被存档且不再有用,因为有更好的替代品,您也可以在 AUR 中提交删除请求。
- 是否有替代品列表?
- 即使上游状况不佳但仍可用,您可能也不想删除列表中的(最后)一个条目。当然,这取决于列表本身的关联性。如果所有条目都已完全停止工作,则保留列表没有意义。
页面移除
修复已存档页面的链接
当页面被存档时,ArchWiki:Archive#How to archive a page 中的指南规定,在存档之前应删除所有指向该页面的链接。在某些情况下(特别是对于翻译),当存档页面时,上下文不允许在不影响读者体验的情况下简单删除链接。
修复已存档页面的链接时,不要简单地从页面中删除链接而不先进行一些研究。
- 调整页面,用其替换项替换过时内容的引用(例如 Special:Diff/704983)。
- 对于您足够流利可以更新页面的翻译,请匹配对英文页面的操作。
- 如果不确定,请使用合适的状态模板标记该章节,而不是完全删除链接。
所有带有已存档页面链接的页面都跟踪在Category:Pages with links to archived pages 中。
移除整个页面
新创建但内容不当的页面
- 如果因垃圾信息或其他明显恶意内容而不当(由管理员评估),则会立即删除;
- 在其他情况下,例如与 Arch 无关,文章应
- 使用 Template:Merge 标记,或
- 使用 Template:Redirect 标记,或
- 使用 Template:Move 标记并移至其作者用户页的子页面(或立即移动)。
旧文章过时
- 标记以下列顺序为优先
- 等待至少 7 天。
- 在没有反对意见的讨论,或这些讨论最终倾向于删除的情况下,执行提议的操作。
- 重定向时,请考虑遵循 #Deal with talk pages after redirecting a page to another 和 #Fix double redirects。
- 存档时,请遵循 ArchWiki:Archive#How to archive a page 中的说明。
创建一个新页面及其翻译
参见 ArchWiki Translation Team#Create a new page and its translation。
将讨论移动到另一个讨论页
- 将讨论文本复制到目标讨论页,确保在新标题和粘贴文本之间添加类似以下的说明:
''[从 [[Origin talk page#Heading]] 移动。 -- ~~~~]'' - 在原始讨论页中划掉标题,并将内容替换为类似以下的说明:
''[已移动到 [[Destination talk page#Heading]]。 -- ~~~~]''
重命名分类
- 以与移动普通页面相同的方式移动分类页面,确保从旧标题创建到新标题的重定向。这只会重命名分类页面本身,分类的成员不会被重新分类。
- 将旧分类的所有成员重新分类到使用新分类。提示 这可以使用 wiki-scripts 的 recategorize-over-redirect.py 脚本自动完成,它依赖于旧分类的重定向来检测新名称,因此不限于大写或其他类似启发式方法。
- 更新所有跨语言链接。
- 更新旧分类的所有反向链接,使其指向新分类。提示 这可以通过在旧分类的 Special:WhatLinksHere 页面上运行 Wiki Monkey 的正则表达式替换插件来自动完成,替换方式为
(\[\[|\{\{Related2?\|):[ _]*[Cc]ategory[ _]*:[ _]*[Oo]ld[ _]name[ _]*(#|\||\]\]|\}\})->$1:Category:New name$2(假设旧分类名称为“Category:Old name”)。 - 使用 Template:Archive 标记旧分类,但不要破坏重定向(旧分类可能仍从 目录链接)。提示 如果该分类没有相关的历史记录,管理员可以在确保步骤 2-4 已实际执行后将其删除。
巡查
每个人都可以检查最近更改。然而,维护团队成员还可以将编辑和页面标记为已巡查。本节主要介绍每个人都可以做的事情。
请记住,巡查最近更改显然需要更持续的投入,而修复其他事情则更具灵活性,可以随时进行。
最近更改巡查
您可以通过以下两种主要方式巡查最近更改:
- 定期访问 Special:RecentChanges,检查自上次访问以来所做的所有编辑。
- 订阅 Special:RecentChanges Atom feed,并在有时间时尽快检查编辑。
对于每一次编辑,或对同一页面进行的编辑组,您应根据您的经验和知识评估它是否可疑,同时也要考虑到最常见问题列表。
- 如果您认为该编辑需要立即快速修复,请直接进行。这尤其适用于小的样式问题、拼写错误和语法修正。
- 如果该编辑可疑但您无法修复,您应该查看它是否已用合适的状态模板标记。
- 如果没有,请向适当的章节添加合适的模板,描述问题。
- 如果已有该编辑的讨论,请查看是否可以为附带的说明或讨论添加有用信息。
- 在偏好设置 > 最近更改 > 高级选项下启用在最近更改和监视列表中按页面分组更改设置。
- 要通过 feed 阅读器关注您监视的文章,请使用您监视列表页面左侧栏中的 Atom 链接。
机器人编辑
MediaWiki 默认不在最近更改中显示机器人的编辑。检查机器人何时修改了页面可能很重要,因为它可能表明需要进行更改。机器人会标记损坏的软件包链接、损坏的章节链接和死链。
强烈建议在标记的内容出现后尽快修复,以免被大量更改淹没。这同样适用于死链,通常是外部资源。
常见问题及解决方案
滥用
幸运的是,垃圾信息和其他违反行为准则的内容相当罕见,但偶尔还是会发生。
最重要的任务在这里也适用。请务必立即制止滥用。
- 首先,撤销所有损害。
- 联系维护团队。您也可以通过加入ArchWiki IRC 频道并提及管理员来联系他们,他们通常都是频道管理员。
如果出现一波滥用,而撤销损害需要太长时间,请先举报。
内容相关
- 删除有用内容:撤销或联系作者。
- 无解释的修改或删除内容:联系作者,若无回应则撤销。
- 重大修改(通常一次性大改)但解释不足:联系作者。
样式相关
- 签名、署名、个人观察在文章中:撤销或移至讨论页。
- 从级别 1 开始的标题:将所有章节向上移动 1 个级别。
- 未分类的新文章:添加分类并修复标题。
- 不当使用模板:根据 Help:Style 进行修复。
- 添加安装说明:撤销或遵守 Help:Style。
MediaWiki 巡查功能
将更改标记为已巡查是避免不必要地重复工作的非常有用的方法。鼓励维护团队的每个成员都使用此功能,以节省他人的时间。
有时,尤其是在某人对某个主题没有经验时,不确定是应该将编辑标记为已巡查还是不。不将编辑标记为已巡查意味着维护团队的其他成员更有可能查看该更改。以下是一些可能有助于巡查更多更改的技巧:
- 拼写错误、语法或语言修复通常很容易验证。如果可能,请优先处理它们。
- 讨论页的添加可以标记为已巡查,前提是它们有意义(适合主题,例如在关于 archiso 的页面讨论游戏是不合适的)。
- 用户页面可以包含任何内容,只要不违反任何规则。它们不幸地基本上不受大多数样式指南的约束。
- 任何开发者都可以在DeveloperWiki 中进行任何操作。
- 如果不懂相关语言,翻译很难检查。可以使用 DeepL 来检查翻译是否大致正确。检查非常新用户的翻译有助于发现低质量编辑和破坏行为。
- 错误是难免的。如果用户注意到自己的错误并撤销了自己的编辑,将两者都标记为已巡查是可以的。
- 将由维护团队成员撤销的编辑标记为已巡查,因为撤销该编辑的人很可能忘记了。
- 新页面可能不完整和/或有样式问题。如果它符合 ArchWiki,则将其标记为已巡查。考虑监视此页面,并确保在它被放弃时加以照顾。
以上所有观点都意味着更改不得违反行为准则或 ArchWiki:Contributing 中描述的规则。
其他
还有其他需要注意的事项:
- 检查新创建帐户的列表,看看是否有任何帐户已经编辑过。非常新编辑者的编辑应始终进行检查,因为编辑者可能不熟悉所有指南。
- 确保对讨论页的所有添加都已签名。
- 有时,用户不知道讨论页上的添加主题按钮。确保新讨论放置在底部并具有适当的章节名称。
- 如果编辑摘要看起来像 →Some section: new section,则用户使用了添加主题按钮。
- 如果用户持续手动添加新章节,请随时提醒他们有一个更方便的添加主题按钮。
- 空白和差异非常大的编辑应始终进行调查。
- 新页面也值得一看,改进它们并修复样式问题可以树立一个好榜样,并帮助作者。
- 确保修改表格的编辑不会通过插入额外的列等方式破坏它们。
- 没有合适编辑摘要的编辑需要特别注意。如果用户没有正确使用编辑摘要,还有一个 Template:Editsum。
- 撤销是常见现象,但仍应进行检查。
请求处理
- 如果您认为自己可以解决请求,请直接执行并删除相应的模板。另请参见 #Common problems and solutions。
- 如果否则您认为最好联系可疑编辑的作者,请在他们的讨论页上给他们留言,或通过电子邮件联系他们以请求解释或进一步讨论。
- 优先尝试处理最旧的请求。
- 优先处理内容相关问题而非样式相关问题。
- 您可以考虑使用编辑器助手(例如 Wiki Monkey 的编辑器配置)来自动解决一些常见的样式问题。