ArchWiki 讨论:请求

注意 有疑问的编辑应直接通过适当的 文章状态模板 在页面本身报告，或在相应的 讨论页 报告。

Wiki 是否缺少热门软件包的文档或重要话题的涵盖？或者现有内容是否需要更正、更新或扩充？请在下方写下您的请求并分享您的想法...

创建请求

在此列出您认为 ArchWiki 应该涵盖的主题请求。如果不明显，请解释为何 ArchWiki 的涵盖是有理由的（而非现有的维基百科文章或其他文档）。此外，请考虑自行研究并创建初始文章（参见 帮助:编辑 获取内容创建帮助）。

桌面环境的左手习惯调整

我在想，如果有一个针对各个桌面环境的配置选项列表，方便左撇子使用鼠标和触控板，那将会非常有帮助。我不确定这是否与 Arch 足够相关以包含在此 Wiki 中，但我一直没能为我自己的 DE (KDE) 找到多少信息，更不用说其他 DE 了。我将开始记录信息，如果没有其他人认为应该为此设立一个单独的页面，我就把找到的信息添加到每个单独的 DE 页面中。 —ajrl 2013-08-11T15:09−06:00

我认为单独开一个页面更好。 -- Fengchao（讨论） 2013年8月12日 11:58 (UTC)

iPXE

iPXE 是一个功能强大的网络启动程序，具有许多特性。目前，Wiki 中没有专门的 iPXE 页面来详细描述它。Wiki 中虽然有一些页面提到了 iPXE，大多与网络启动有关，但没有关于如何使 iPXE 工作的进一步说明。所以我认为值得在 Wiki 中添加一个带有详细 iPXE 说明的页面。 Alive4ever（讨论） 2016年7月21日 10:08 (UTC)

我最近将 ipxe 添加到了 [community]，除了默认设置外，它还包含允许向 Arch Linux 特定端点进行 iPXE 启动所需的二进制文件。如果能有一个关于此的页面就好了，我会尝试在时间允许的情况下编写 iPXE 页面。 Davezerave（讨论） 2021年6月17日 09:54 (UTC)

缺失的重定向

• Linux 命名空间 (namespaces)
• sysfs
• lspci 和 lsusb
• stty
• terminfo (termcap)
• LPD, LPR
• JSON, XML, CSV, JS, CSS
• Exif
• CGI
• SQL
• YAML, TOML
• Chromecast

--Larivact（讨论） 2018年10月21日 15:35 (UTC)

我想我可能会创建 TOML，不过我会先查看有多少页面尝试链接到它，以确定大家对它的需求程度。

这些年来 TOML 发展迅速，所以创建一个页面列出与之兼容的软件包（如库），并简要解释什么是 TOML（引用其文档），同时链接到其文档，将会非常有帮助。

祝好，PolarianDev（讨论） 2023年5月11日 10:56 (UTC)

这是唯一链接到 TOML 的页面，链接它可能是浪费时间……尤其是考虑到所有其他序列化和配置语言（json, yaml 等）也没有专门的页面。 PolarianDev（讨论） 2023年5月11日 10:57 (UTC)

镜像故障排除

遗憾的是，Mirrors#故障排除 有点欠缺，肯定能受益于更多信息，例如如何检测坏镜像。镜像出现故障并非极罕见，所以这个话题肯定应该被涵盖，包括应该告知谁关于坏镜像的信息，以便将其从镜像列表（mirrorlist）中移除。

这个话题影响的人足够多，值得放在这里。

-- NetSysFire（讨论） 2021年8月6日 00:07 (UTC)

关于坏镜像的情况我现在已经涵盖了。是否应该添加另一个关于镜像返回 404 的章节，还是 Pacman#安装时无法检索软件包 中的信息已经足够了？ --Mpan（讨论） 2021年8月6日 08:19 (UTC)

感谢您的贡献！您添加的内容看起来不错。仍然缺少一些帮助确定镜像是否有故障的信息。遗憾的是，您提到的章节并没有包含足够的相关信息，而且无论如何这些信息都应该是 Mirrors 文章特有的。如果有任何了解镜像内部机制的开发者或其他人看到此条信息，请分享您在调试镜像方面的知识。

-- NetSysFire（讨论） 2021年8月6日 17:19 (UTC)

随机页面 - 仅限特定语言？

我很喜欢“随机页面”功能，https://wiki.archlinux.org.cn/title/Special:Random ，但它经常给我提供非英语的文章，例如今天随机到了葡萄牙语的 fstab，这超出了我的语言能力 :-) 是否可以在调用随机页面 URL 时添加一个额外选项，以便例如只获取英语的 Wiki 文章？谢谢。 Ua4000（讨论） 2023年5月19日 09:34 (UTC)

查看 mw:Manual:Random page，这似乎是不可能的，因为 ArchWiki 将所有翻译都放在主命名空间中。 -- nl6720（讨论） 2023年5月19日 09:40 (UTC)

可观测性 (Observability)

这篇文章可以从引用并链接到维基百科上相同主题的文章开始。我还想在“通用建议 (General Recommendations)”页面添加一小段文字，甚至添加到应用程序列表中（并在该章节顶部显著位置添加指向“可观测性”主文章的链接）。

作为一名初级云工程师，我对 Web 应用程序/服务以及我自己的业余项目中的可观测性越来越感兴趣。我对它做了一些研究，并对几种不同的方案有所了解。我发现的大多数方案都是开源的，我想在这个“可观测性”页面中链接一些选项，并可能编写完整的 Wiki 文章来描述各种方案。也有更多的交钥匙型商业产品，我们可以列出其中的一些并附上链接以获取更多信息。实际上，我一开始选择了一款商业产品，主要是为了在摸索更具手动性的选项之前，先了解哪些功能对我来说比较重要。

当我在寻找监控个人 Web 项目的方法时，偶然看到了 New Relic 的广告，它是众多商业服务之一。令我感兴趣的是，New Relic 的大部分工具都是开源的（采用 Apache 2.0 许可，使用 Go 编写）。他们每月提供 100GB 的免费数据上传额度，这对于观察我在 VPS 上的业余项目来说绰绰有余。我已经为我使用过的一些工具起草了 PKGBUILD（但尚未发布），主要基于他们预编译的 deb 包。AUR 中已经有 PKGBUILD 了（例如 newrelic-cli^AUR 和 newrelic-infra^AUR），但我没看到描述如何使用它们的 Wiki 文章。遗憾的是，Arch Linux 目前尚未得到 New Relic 的正式支持，他们仅通过 newrelic 命令（newrelic-cli^AUR 的一部分）进行自举的方法对我不起作用，所以我不得不遵循他们零散的手动指令。我遇到了一些问题，于是去他们的论坛寻求帮助。他们有提供一线支持的社区成员，针对我的至少一个问题，他们实际上已经为此创建了一个 New Relic 支持案例。

我甚至学习了压力停顿信息 (Pressure Stall Information)，并编写了自己的脚本来在 CPU、I/O 或内存压力过高时进行监控和报警。它存放在一个公开的 Git 仓库中，但在我分享链接之前，我想先完善一下文档。

这样的一篇 Arch Wiki 文章值得写吗？我认为是值得的，但在讨论之前我不想贸然开始编写。 Ectospasm（讨论） 2023年12月17日 18:00 (UTC)

关于如何优化隐私的文章

我知道 Arch 不想像其他某些发行版那样遵循某种意识形态，而是想给每个人提供任何选择。但既然我们已经有了关于如何针对其他目标（如 安全 或 提高性能）改进系统的文章，我认为写一篇至少包含各种改善系统隐私的方法链接的文章会是一个好主意。

特别是由于在许多页面（如 NetworkManager/Privacy 或 Firefox/Privacy）上，我们已经有了关于特定应用程序隐私相关配置的页面。如果你在 Arch 之外搜索，特别是涉及到 Linux 系统配置时，你必须浏览一堆网站，有时还得做些修改才能让它们在 Arch 上工作。

SolarpunkJulian（讨论） 2024年9月17日 18:00 (UTC)

我赞同这一点。特别是 DNS over TLS 和 DNSSEC 可以作为独立页面，并提供关于保持 DNS 查询私密性的详细信息。 İsmail Arılık（讨论） 2025年11月25日 07:24 (UTC)

我不认为 DNS over TLS 需要一个单独的页面。在我看来，域名解析#隐私与安全 是讨论该话题的一个足够好的地方。尤其是因为 DNS over TLS 只是选项之一。 -- nl6720（讨论） 2025年11月25日 07:29 (UTC)

谢谢；有道理！我只是指它们可以写得更详细些。 İsmail Arılık（讨论） 2025年11月25日 07:47 (UTC)

GPU 文章

我认为创建一个通用的“图形处理器 (Graphics processing unit)”文章会很有用，它可以作为发现所有图形硬件相关文章的主要入口。例如，Xorg#驱动安装 中的 DRM、OpenGL 和 Vulkan 信息并不仅限于 Xorg。对于 Wayland 用户来说，那里的表格并不容易发现。

--nl6720（讨论） 2025年7月25日 10:07 (UTC)

我记得在 IRC 上同意过这一点，我在这里重申，为这些信息提供一个中心化的场所似乎是个好主意。

-- Erus Iluvatar（讨论） 2025年10月2日 09:30 (UTC)

我几年前在 User:CodingKoopa/Direct Rendering Infrastructure 开始写一篇 GPU 文章，但我不知道什么时候会再次动笔。它包含的实现细节也比一般文章应有的要多。

-- CodingKoopa（讨论） 2025年11月16日 00:14 (UTC)

昨天我对 Xorg 页面表格的修改给了我将内容放到合适页面的动力，我鼓励大家复核一下，确保我没有犯错 :) 已结案。

--Erus Iluvatar（讨论） 2025年12月21日（周日） 11:43 (UTC)

修改请求

在此列出对现有文章进行更正或其他修改的请求。只有影响多篇文章的系统性修改才应包含在此处。如果特定页面需要修改，请改用该页面的讨论 (Discussion) 或 Talk 页面，并使用 文章状态模板 之一。

作为滚动更新版，Arch 不断收到更新和改进。因此，Arch Wiki 必须快速更新以反映这些变化。

将驱动器命名/访问更改为 UUID？

目前在内部、外部驱动器上尝试安装带有/不带 Luks、LVM 的驱动器相当复杂。遵循相关文章会建议不同的实现方式。建议了许多不同的驱动器命名约定，例如：

• /dev/sda2
• /dev/md0
• /dev/mapper/md/0
• /dev/mapper/vgroup-lvm-root
• /dev/vgroup-luks/root
• ...

其中一些不适用于便携式外部驱动器。这使在不同情况下设置加密驱动器变得过度复杂。我的建议是，将所有与驱动器相关的文章更改为一种特定的通用寻址驱动器的方案。目前我认为使用 UUID 驱动器命名是可行的方法。这将在各种情况下简化驱动器命名的过程。

• 读者将沿着一条红线引导完成系统设置
• 排除“未找到驱动器”故障将变得直截了当
• 即使不阅读整篇文章，许多章节读起来也会更清晰
• 文章更容易编写和维护
• 初学者更容易阅读，并能更好地理解如何访问驱动器
• 访问内部/外部加密驱动器变得容易

LMV 或其他虚拟文件系统更容易描述和设置

好吧，我知道这是一个重大的建议。我之所以在这里提出来，是因为我感觉遵循一条主线会给所有相关人员带来很大帮助。这不需要在一天内完成。我认为先有一个建议的准则会是一个好的开始。有了这个想法，我们在编写/编辑 Wiki 条目时，修改这些章节都会更容易。

T.ask（讨论） 2015年3月30日 11:22 (UTC)

嗨，关于你上面的例子：对于 /dev/mapper/* 设备声明使用 UUID 通常是不必要的（设备的唯一性在映射时就已经确定了）。我认为你高估了实际需要设置那些确实很关键的示例（例如外部驱动器）的用户数量。我不明白的是，为什么你认为使用 UUID 会更容易阅读/描述。首先，极其冗长的 UUID 在许多情况下会破坏排版，例如导致无法使用行内代码块。UUID 本身不提供上下文提示，而设备名称可以。如果你看 持久块设备命名#引导管理器 中的三个例子，你真的觉得 UUID 那个是最简单的吗？

我认为你说的对，我们可能在一些使用 UUID 比较重要的文章中缺乏指向 持久块设备命名 (Persistent_block_device_naming) 的交叉引用。也许我们还需要一个示例章节来阐述 持久块设备命名 中的个别要点，也许某些特定的文章/章节确实应该直接使用某种形式的持久命名。

建议：在 Talk:Persistent block device naming 中整理一份 *特定* 文章章节的列表，列出那些应该更突出显示持久命名的内容，如何？这样我们也可以弄清楚是否以及哪些示例适合添加。 --Indigo（讨论） 2015年3月30日 17:47 (UTC)

嗨，我发起这个话题是因为“按照设计”，Linux 有如此多分配驱动器的方式，而 Wiki 使用它们的方式有点“随意”。我的意图是为 Wiki 寻找 *最佳驱动器命名方法*。通过让读者能够理解一种访问驱动器的方式并将所有其他方式收集在某处，从而助其一臂之力。

我建议使用 UUID，因为它们既可用于本地情况也可用于移动情况。它们易于使用。UUID 格式是通用的，并且独立于位置（本地/移动）或使用它们的环境（LVM、Raid、Luks……）。

我提出这个建议的原因是，Wiki 目前似乎没有标准化的驱动器路径声明形式。如果我们能找到一种实用的方法，文章的编写、编辑和维护将变得更容易。每个参与的人都会知道哪种方法是推荐的。

因此，我想开启一段公开对话，寻找改善现状的想法。我猜 UUID 也是一个不错的选择，因为它们很容易用伪代码替换，例如：

• "mount /dev/disks/by-uuid/e9ea05ce-0ccb-87a1-c71e-90fab8be1944 /mnt"

可以写成

• "/dev/disks/by-uuid/[UUID] /mnt"

而不是在以下选项中进行选择

• "mount /dev/sda3 或
• /dev/mapper/vgroup--lvm-root 或
• /dev/md/0 或
• /dev/md0 或
• ... /mnt"

读者立刻就知道

• “我只需要更改 [UUID]”

没有必要去了解所有利用 Wiki 示例的可能替代方法。因为用户已经学习过（初学者指南）如何确定 UUID，所以这些示例非常易于采用。

减少了读者以前会遇到的不确定性：

• 在我这种情况下，我也可以使用那个例子的本地路径吗？
• 我的情况到底是什么？它与提供的有什么不同？
• 我的驱动器是 IDE、SATA 还是……什么？
• 我的驱动器/分区的路径的正确格式在哪里，又是怎样的？
• 我需要一个随处都能引导我的 USB 驱动器的例子。提供的那个例子对我不起作用。我需要了解的文章在哪里？
• 我浏览了许多文章，目前还没有成功。肯定有一篇，但在哪呢？
• 我这里的情况是 Luks、Raid、LVM（或混合）。当前文章只使用了 /dev/sdi3。该怎么办？
• 我需要先读哪篇文章？我不能使用当前的例子。有什么替代方案吗？

读者的问题在于，“/dev/sdb3”之类的驱动器路径如果不了解它们的使用背景和时间，就没有那么强的描述性。它们对于特定的情况很好，但在其他用例中可能立刻失去意义？！

如果我们能选出一种 Wiki 使用的驱动器命名方法，那么我们就能消除许多上述的内心独白，并且……

• 我们为编写者、读者和维护者获得了一个良好的文章结构。
• 提供的方法在任何情况下都有效（本地/移动/……）。
• 所有替代方法都可以列在一个转换文章/表格中。

读者可以快速继续阅读文章

• 太好了，我已经知道如何确定 UUID 了。我直接改掉它就行。.

正如您所提到的，交叉引用随后会指向一个子页面，在那里会解释如何转换到其他替代方法。

别误会我的意思，我并不是想暗示 Wiki 目前的做法有什么不对。这只是事物成长的自然过程。一点标准化可能会有所帮助。

目前我赞成使用 UUID，因为它们很容易更换，并且在 Wiki 中可以写成 [UUID]。

天哪，我写了一大堆字。很抱歉。作为一名非母语使用者，要把我想说的话写下来并不容易，而且非常耗时。我希望现在更容易理解我的意图了。我有点不确定自己是否找准了措辞。 --T.ask（讨论） 2015年3月31日 13:24 (UTC)

感谢你详细阐述提议的背景。完全不需要为花时间提供改进 Wiki 的意见而道歉！我只想对此再补充两点想法：

(1) 描述性的设备声明 (/dev/sda/...) 易于理解的一个原因是大家习惯了它们。从你打开任何分区工具开始——你就是为 /dev 树中的设备启动它的。试着在 cfdisk/cgdisk/parted 的手册页中寻找“UUID”这个词（fdisk 有，其他的没提到过）。我并不是说你想尽早引导用户使用持久化命名的意图是错的，只是使用描述性命名很常见，因此对读者来说很亲切。

(2) 我喜欢你使用“/dev/disks/by-uuid/[YOURUUID] /mnt”格式的想法（我们称这类实例为“伪变量”）。尽管如此，如果你在文章上下文中使用它，比如加密的 LVM，你仍然需要更详尽地描述哪一个 dev/块设备/vg/lv 的 UUID 是要挂载到 /mnt 上的。我还是无法想象为什么这样写和读会普遍变得更容易。

正如我上面写的，我同意我们可能需要更多地指明持久命名的优点，但我们已经做了一些（例如从头开始：初学者指南#生成 fstab）。简而言之，我认为维持现状会更好（不设死规定，只要贡献符合所贡献的文章，所有编辑都可以选择上下文中最合适的方案）。我就说这些。期待看到反馈和其他意见。 --Indigo（讨论） 2015年3月31日 20:46 (UTC)

在我看来，手册页的例子有时比“新标准”落后一点。这很自然，但这不应该阻止我们迈出更大的一步。在 Arch 中，我们有了 UUID —— 让我们使用它们吧 :)

万一用户不知道 UUID，我们会引导他/她看一个关于如何切换到 UUID 的简短转换表/文章。实际上，它比通常想象的要容易理解得多。

• 只需输入 lsblk -f，就可以很明显地看到在任何上下文（raid、luks、lvm……）中哪个 UUID 指向哪个驱动器。正如这个 获取 UUID 的示例 所示，只需复制相应的 UUID 并将其用于所有 UUID Wiki 示例即可。我认为这相当容易。

我明白你的意思，同时我有信心读者能很快学会 UUID 是如何工作的。新用户甚至不会知道以前有哪些其他选项。此外，由于读者已经熟悉了 UUID，他/她将来移动驱动器时就不会遇到问题。经验丰富的用户只需阅读转换表/文章即可。

你看，我很确信用户能轻松掌握 UUID。此外，这还能防止他/她将来遇到问题。我们只需要有勇气迈出第一步。这不需要在一天内完成。我们有充足的时间慢慢向一个方向移动。

这就是为什么我也希望在这里听听关于这个话题的其他意见。

T.ask（讨论） 2015年4月1日 12:45 (UTC)

嗨，T.ask，感谢讨论此事。不过我不确定这是否还停留在理论层面，或者你已经有了如何付诸实践的精确想法，因为在读完所有讨论后，我还没能很好地理解这个想法会如何改变我们的文章。在现阶段，你必须选择我们的一篇 *重要* 文章（例如 LVM），并向我们详细解释这篇文章将如何改变，这样我们才能在更切实际的基础上进行讨论。 — Kynikos（讨论） 2015年4月2日 14:37 (UTC)

嗨，Kynikos。是的，如果事情看起来很复杂，最好能有一个好的实际例子。我现在挺忙的。当我抽出时间时，我会开始（慢慢）修改 Wiki，正如我之前提到的。LVM 是个不错的例子，但我还是想从那些更容易改编且更常用的章节开始。特别是我需要事先添加一个新子章节（如何操作 UUID）。 --T.ask（讨论） 2015年4月21日 10:44 (UTC)

正如我所说，最好在真正开始“修改 Wiki”*之前*，在这里或你的用户页面向我们展示一个例子。当然，请慢慢来 :) — Kynikos（讨论） 2015年4月22日 02:30 (UTC)

php-fpm

为了准备让所有 (php) Web 应用程序使用专用用户，我扩展了关于 PostfixAdmin 的信息，并意识到关于 php-fpm 的信息散布在 nginx 和 apache 的文章中（可能也散布在其他一些 Web 服务器 页面中）。我认为，如果将这些信息移到专用页面或 PHP 的子页面，所有 Web 服务器 页面和 PHP Web 应用程序页面的引用/链接情况将大大改善，因为它是非常特定于 PHP 的（不像 uwsgi 那样通用）。 Davezerave（讨论） 2019年5月26日 00:55 (UTC)

关于旧版本内核/程序的的信息

关于内核和程序版本的信息应该保留多久，是否有指导意见？例如“btrfs 从 linux 5.0 开始支持此功能”或“fdisk 自……起支持 GPT”。当这些是最近的变化时，它们还有点意思，但 Wiki 上出现的许多情况都涉及到已经从仓库中移除多年的版本……我认为在大多数情况下，这增加了不必要的干扰，有什么想法吗？

-- Cvlc（讨论） 2023年1月23日 12:39 (UTC)

在 帮助讨论:样式#“自 X.XX 版本起……” 有一个关于此主题的旧的、停滞的讨论。 --Erus Iluvatar（讨论） 2023年1月23日 13:30 (UTC)

我认为“多长时间”是关键。如果（大致上）没有人再使用之前的版本，那么就可以移除它们。我们可以使用 Pkgstats 来观察使用情况。İsmail Arılık (讨论) 2025年11月25日 07:31 (UTC)

本地化侧边栏文本

我不知道是否应该发在这里，但总之先发了。

由于许多语言的 ArchWiki 直接寄宿在英文 ArchWiki 上，侧边栏只有一半翻译会显得有点奇怪。

所以在 MediaWiki:Sidebar 上，每个二级项目代表一个链接（| 左侧的文本是目标，右侧是“名称”。下面我会将这些“名称”称为“消息”，稍后你就知道原因了），而某些一级项目代表标题。在显示侧边栏时，MediaWiki 会尝试从 MediaWiki: 命名空间（该命名空间中的每个页面都称为 *系统消息*）获取名称。例如在当前的 MediaWiki:Sidebar 中：

MediaWiki:Sidebar

...
* Interaction
** :Category:Help|help
** {{ns:Project}}:Contributing|Contributing
...

以 Interaction（互动）为例。MediaWiki 首先会读取消息 MediaWiki:Interaction/用户的显示语言（假设是简体中文，那么就是 MediaWiki:Interaction/zh-hans，并假设其内容为 互动）。如果页面存在，页面内容 互动 将替换 "Interaction"。如果不存在，则使用根页面，如果还不存则保持原样。整个机制可能有所不同，因为实际机制会经过一长串的语言回退（仍以 zh-hans 为例，它可能会经过 /zh-hans、/zh-hant、/en、root）。

因此，为了本地化侧边栏，我们将创建一些 MediaWiki: 页面（即系统消息）及其子页面，子页面的标题为相应的 跨语言链接前缀。有些消息已经由 MediaWiki 核心翻译了，我会列出目前还没有的消息。不过我建议也将这些页面重命名为短横线命名法（kebab-case），然后在 MediaWiki:Sidebar 中进行相应更改。

MediaWiki:Table of contents
MediaWiki:Interaction
MediaWiki:Contributing
MediaWiki:Recent talks
MediaWiki:Requests

（由于 Special:Statistics 的存在，MediaWiki:Statistics 已经存在了。）

谢谢！ --Lakejason0 (讨论) 2023年2月4日 13:52 (UTC)

听起来可行。

“目录”有一个 MediaWiki:vector-toc-menu-tooltip，但那个没有使用句首大写，而且从它的名字来看，过度依赖它可能不是个好主意。

-- nl6720 (讨论) 2023年2月4日 15:48 (UTC)

也许问题在于没人提供翻译。我想如果他们想添加翻译，直接发个 MediaWiki talk: 就可以了。总之，对于两种中文：

en	zh-hans	zh-hant	注意
目录	目录	目錄
交互	参与	參與	“Interaction”在中文里是一个比较正式的词（至少在简体中是），翻译为“参与（Getting involved）”。
贡献	贡献	貢獻
最近讨论	最近讨论	近期討論	由“最近更改”延伸而来，因此也需要一个内容为 最近討論 的 /zh-hk。
请求	请求	請求

虽然不知道 MediaWiki 如何处理 Accept-Languages，但至少对那些在 参数设置 中设置了界面语言的人（比如我）很有用。--Lakejason0 (讨论) 2023年2月5日 04:59 (UTC)

这事有进展吗？ --Lakejason0 (讨论) 2023年2月22日 08:50 (UTC)

更新 Intel 域名的链接

Intel 更改了他们的域名，以下所有链接现在都指向一些通用的登录页面

• https://wiki.archlinux.org.cn/title/Special:LinkSearch?target=https%3A%2F%2F01.org
• https://wiki.archlinux.org.cn/title/Special:LinkSearch?target=http%3A%2F%2Fintellinuxgraphics.org
• https://wiki.archlinux.org.cn/title/Special:LinkSearch?target=https%3A%2F%2Fcommunities.intel.com%2Fmessage

实际上所有的 Intel 链接都应该由人工检查，因为机器人使用的脚本对大多数 Intel 链接都返回 404 状态，即使是那些工作正常的链接...

— Lahwaacz (讨论) 2023年7月30日 09:18 (UTC)

Bug 迁移

正如 邮件列表上公告 的那样，所有 bug 都已迁移到 GitLab，GitLab 成为新的 bug 追踪器。引用 bugs.archlinux.org 的页面（例如 Bug 报告指南）必须更新以指向我们的 GitLab。

• Special:LinkSearch/https://bugs.archlinux.org

Klausenbusk (讨论) 2023年11月25日 20:42 (UTC)

已解决 Matthewq337 (讨论)

重新开启，因为 Wiki 上仍散布着许多过时的链接。你是否检查并尝试更新了上述列表中的所有页面？ Lahwaacz (讨论) 2025年12月1日 17:13 (UTC)

意见征求 (RFC)：针对特定厂商和型号的讨论

目前关于特定厂商甚至特定型号的实现细节散布在多个页面中。这带来了两个问题：

• 作为没有该硬件的用户：通用页面充斥着仅对一小部分用户相关的讨论。
• 作为正在寻找特定硬件帮助的用户：我必须访问多个不同的页面才能找到相关信息。

例如，如果我有一台华硕（ASUS）笔记本电脑，我会在 Laptop/ASUS 页面上找到很多我需要了解的内容。但出于某种原因，关于风扇控制的信息却在 Fan_speed_control#ASUS_laptops，关于额外按键的注释在 Extra_keyboard_keys 等等。

我想建议将所有这些特定硬件的部分移至其相关的文章中。这包括针对特定软件的故障排除部分，前提是该信息无法被改写为具有通用性。

这*不包括*关于特定主题的独立文章，如 ASUS_Linux、Asusctl 等已经有自己页面的文章。这也不包括示例页面，例如 GRUB/EFI_examples#ASUS，它们只是将硬件作为示例。

Comic-paralyze-image (讨论) 2025年3月1日 18:51 (UTC)

Dovecot 2.4

Dovecot 的 2.4 更新显著改变了配置语法，之前的配置已不再有效。他们的非详尽变更列表可以在这里找到。

因此，大量的 Wiki 页面现在已经过时。这至少影响了以下 Wiki 页面：Dovecot、Virtual_user_mail_system_with_Postfix,_Dovecot_and_Roundcube、SOGo、Exim。

已解决 Matthewq337 (讨论)

提到的页面仍未更新，甚至没有被标记为过时。 Lahwaacz (讨论) 2025年12月1日 17:11 (UTC)

将 # dmesg 替换为 $ journalctl -k

...因为这能产生格式更好的输出（日期），且无需 root 即可使用？ --Cvlc (讨论) 2025年7月25日 10:49 (UTC)

👍 赞成将 dmesg 替换为 journalctl，但不能使用 $。参见 systemd/Journal#以用户身份访问日志 -- nl6720 (讨论) 2025年7月25日 10:55 (UTC)

是的抱歉，我就是那个意思。据我所知，你不能仅仅通过把自己加入 wheel 组来获得 dmesg 的访问权限。 Cvlc (讨论) 2025年7月25日 12:50 (UTC)

我正考虑着手做这件事，但我注意到仅仅把 dmesg 替换为 journalctl -k 是不够的；输出内容也应该更新。我想为每个用法都获取真实的输出可能不可行。那么，仅仅将 dmesg 输出的第一部分替换为格式化为 journalctl -k 输出的一些随机日期是否足够？或者这样做不现实，因为我们会改变真实的输出？你们怎么看？ İsmail Arılık (讨论) 2025年11月25日 08:16 (UTC)

我认为最好从我们能获取真实输出的地方开始。至于伪造的部分，我认为在这些地方可以省略时间戳。 -- nl6720 (讨论) 2025年11月25日 08:27 (UTC)

机器人请求

在这里列出对一系列现有文章进行重复性、系统性修改的请求，这些修改将由 Wiki 机器人 执行。

自动为外部 Wiki 承载的语言添加/更新语言链接

一些语言托管在外部 Wiki 上，我希望机器人能自动为这些外部 Wiki 托管的语言添加/更新语言链接，这样用户就无需手动添加它们。 -- Blackteahamburger (讨论) 2020年5月20日 15:27 (UTC)

外部 Wiki 可能使用与 "英文标题 (语言)" 不同的标题，而且由于机器人不懂人类语言，它无法弄清楚哪些链接应该添加到哪些页面。 -- Lahwaacz (讨论) 2020年5月21日 08:34 (UTC)

能否通过外部 Wiki 上的跨语言链接来判断？ -- Blackteahamburger (讨论) 2020年5月21日 09:13 (UTC)

可以，但机器人必须连接到不止一个地方。这可能行得通，但结果可能会比我们现在的状况更乱……等我有空的时候可能会试一下。 -- Lahwaacz (讨论) 2020年8月13日 15:32 (UTC)

是否可以检测链接的页面是否存在？我今天碰到了两个笔记本页面，上面链接了日语翻译，但那个翻译页面并不存在。 --Erus Iluvatar (讨论) 2022年10月20日 13:55 (UTC)

Template:Broken package link 的提示

本地化页面上标记的 Template:Broken package link 提示能否使用本地化版本？这能让不懂英语的用户也明白软件包的状态。 -- Blackteahamburger (讨论) 2020年5月26日 11:34 (UTC)

如果你手动翻译了提示，机器人稍后会将其覆盖回英文。翻译必须添加到 wiki-scripts 中，我不确定该怎么做最好。 -- Lahwaacz (讨论) 2020年5月26日 11:38 (UTC)

我认为你可以把翻译加到 wiki-scripts 里，我觉得这样挺好。 -- Blackteahamburger (讨论) 2020年5月26日 11:53 (UTC)

死掉的跨 Wiki 链接

我们已经对外部链接、仓库中损坏的包和 AUR 进行了标记：我们能否对跨 Wiki 链接也做同样的操作？我最近看到一些链接是人工修复的，特别是在翻译页面上。 --Erus Iluvatar (讨论) 2022年3月2日 19:41 (UTC)

这是个好主意，我们只需要找个人来负责实现…… — Lahwaacz (讨论) 2022年3月13日 15:18 (UTC)

移除死掉的翻译

正如你在 Special:Diff/835558 中看到的，死链接（页面已不存在）的翻译不会被自动检测和移除。让机器人扫描这一点应该不难。如果上面的 #死掉的跨 Wiki 链接 也能检测到托管在其他 Wiki（例如德国 ArchWiki）上的失效翻译，那就更好了。 -- NetSysFire (讨论) 2025年6月12日 09:19 (UTC)

标记缺少翻译状态模板的翻译页面

并非所有翻译页面都有 Template:TranslationStatus。如果机器人能自动标记此类页面就太理想了。 -- NetSysFire (讨论) 2025年6月12日 09:19 (UTC)

至少有一个翻译团队在页面上不使用此模板，并且至少有一个页面并不是翻译 — andreymal (讨论) 2025年6月12日 10:36 (UTC)

那也许我们可以直接在 User:Lahwaacz.bot/Reports/problems 中列出它们？

-- Erus Iluvatar (讨论) 2025年6月12日 10:54 (UTC)

删除请求

在此列出价值模糊且**除更改重定向目标外没有历史记录**的重定向。此类重定向可能是在移动最初标题不规范的页面时创建的，或者是早于 MediaWiki 搜索功能提供建议之前创建的。

我们不会删除有历史记录（即有内容）的页面——请在该页面中使用 Template:Archive 模板。

DeveloperWiki:HOWTO Be A Packager

移除 DeveloperWiki:HOWTO Be A Packager —— 它太“酷”了以至于不该存在。我的意思是，我们已经有了 DeveloperWiki:How to be a packager，原始名称没用了。 — Andrei Korshikov (讨论) 2025年9月3日 14:02 (UTC)

已解决 Matthewq337 (讨论)

重定向页面仍未被删除。 Lahwaacz (讨论) 2025年12月1日 17:07 (UTC)

Screen

我同意 @Alad 的看法，“screen”指的就是 “GNU screen” 及其同类工具（尤其是 tmux）。我想删除 screen 消歧义页面，并将 GNU Screen 重命名为 screen。该如何正确操作？

— Andrei Korshikov (讨论) 2025年9月6日 20:13 (UTC)

Matthewq337 (讨论) 已解决

这事儿还没办完。 Lahwaacz (讨论) 2025年12月1日 17:08 (UTC)