ArchWiki talk:Requests

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

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

创建请求

最新评论：本周日 11:4320 条评论14 人参与讨论

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

桌面环境的左手习惯调整

我在想，如果有一个针对每个桌面环境的配置选项列表，方便左撇子使用鼠标和触摸板，那会对他们很有帮助。我不确定这是否与 Arch 足够相关以包含在此 Wiki 中，但我一直没能为我自己的 DE (KDE) 找到多少信息，更不用说其他的了。我会开始记录信息，如果没有其他人认为应该为此设立专门的页面，我就把找到的信息添加到各个 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] 仓库中，除了默认设置外，它还包含了允许 iPXE 引导至 Arch Linux 特定端点所需的二进制文件。如果能有一个相关页面就太好了，我会在时间允许时尽快尝试编写 iPXE 页面。 Davezerave (讨论) 2021年6月17日 09:54 (UTC)回复

缺失的重定向

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

我想我可能会创建 TOML，但我会先检查有多少页面尝试链接到它，看看它的需求程度。

这些年来 TOML 的应用增长了很多，所以建立一个页面来列出兼容 TOML 的软件包（如库）、简要解释什么是 TOML（引用其文档）并链接到其官网，会非常有用。

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

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

镜像故障排除

遗憾的是，Mirrors#Troubleshooting 内容有点匮乏，增加更多信息肯定大有裨益，比如如何检测坏掉的镜像。镜像失效并非罕见，因此这一主题绝对应该涵盖，包括应该向谁报告坏镜像以便将其从镜像列表中移除。

这个话题影响的人很多，值得放在这里讨论。

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

坏镜像的情况现在已经涵盖了。是否应该再增加一个关于镜像返回 404 的章节，还是说 Pacman#Packages_cannot_be_retrieved_on_installation 中的信息已经足够了？ --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)回复

可观测性

这篇文章可以从引用并链接到维基百科上相同主题的文章开始。我还想在“常规建议”页面上添加一段简短的说明，甚至添加到应用程序列表中（在章节顶部显著位置放一个指向“可观测性”主文章的链接）。

作为一名初出茅庐的云工程师，我对 Web 应用程序/服务以及我自己的业余项目中的可观测性越来越感兴趣。我对此做了一些研究，并对几种不同的方案有所了解。我发现的大多数工具都是开源的，我想在这个“可观测性”页面中链接一些选项，并可能由专门的 Wiki 文章详细描述各种方案。还有更多开箱即用的商业产品，我们可以列出其中一些并提供链接以获取更多信息。实际上，我一开始选择了一个商业产品，主要是为了学习哪些功能对我来说比较重要，然后再去折腾那些需要手动配置的方案。

当我在寻找监控我个人 Web 项目的方法时，我偶然看到了 New Relic 的广告，它是众多商业服务之一。令我感兴趣的是，New Relic 的大部分工具都是开源的（采用 Apache 2.0 许可证，使用 Go 编写）。他们每月免费提供 100GB 的数据上传量，这对于在我的 VPS 上观察我的业余项目来说已经足够了。我已经为我使用过的一些工具起草（但尚未发布）了 PKGBUILD，主要基于它们预编译的 deb 包。AUR 中有一些 PKGBUILD（如 newrelic-cli^AUR 和 newrelic-infra^AUR），但我没看到有 Wiki 文章描述如何使用它们。遗憾的是，目前 New Relic 并不正式支持 Arch Linux，而且他们仅使用 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 需要一个单独的页面。在我看来，Domain name resolution#Privacy and security 是讨论该主题的一个足够好的地方。尤其是因为 DNS over TLS 只是选项之一。 -- nl6720 (讨论) 2025年11月25日 07:29 (UTC)回复

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

GPU 文章

我认为创建一个通用的“图形处理器 (GPU)”文章会很有用，它可以作为发现所有图形硬件相关文章的主要入口。例如，Xorg#Driver installation 中的 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 (讨论) 上周日 11:43 (UTC)回复

修改请求

最新评论：12月1日26 条评论12 人参与讨论

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

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

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

目前，尝试在内部、外部驱动器上安装带有/不带有 LUKS、LVM 的驱动器相当复杂。参考相关文章时，它们会建议不同的方法来达到目的。文章中建议了许多不同的驱动器命名约定，例如：

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

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

读者可以通过一条清晰的主线完成系统设置
排除“未找到驱动器”故障将变得直接了当
即使不阅读全文，许多章节也会变得更易读
文章更容易编写和维护
初学者阅读更轻松，能更好地理解如何访问驱动器
访问内部/外部加密驱动器变得容易

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

我知道这是一个宏大的建议。我想在这里提出来，是因为我觉得遵循一条主要路径对所有参与者都有很大帮助。这不需要在一天内完成，但我认为建立一个建议指南会是一个好的开始。有了这个共识，我们在编写/编辑 Wiki 条目时修改这些章节就会更容易。

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

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

我认为你说的没错，在某些可能必须使用 UUID 的文章中，我们可能缺少指向 Persistent block device naming 的交叉链接。也许我们还需要一个示例章节来阐述 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/[~~YOUR~~UUID] /mnt" 格式的想法（我们称这类实例为“伪变量”）。尽管如此，如果你在文章上下文中使用它，例如加密的 LVM，你仍然需要更详尽地描述哪一个 dev/blockdevice/vg/lv UUID 是要挂载到 /mnt 上的。我还是没法想象这在总体上是如何让读写变得更简单的。

如我上面所写，我同意我们可能需要更多地指出持久化命名的优点，但我们已经做了一些（例如从一开始就在做的：Beginners' guide#Generate an 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 (讨论) 02:30, 22 April 2015 (UTC)回复

php-fpm

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

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

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

-- Cvlc (讨论) 12:39, 23 January 2023 (UTC)回复

在 Help talk:Style#"as of version X.XX..." 有一个关于此主题的旧的、已停滞的讨论。 --Erus Iluvatar (讨论) 13:30, 23 January 2023 (UTC)回复

我认为“多久”是关键。如果（大致上）没有人再使用之前的版本，那么它们就可以被移除。我们可以使用 Pkgstats 来观察使用情况。 İsmail Arılık (讨论) 07:31, 25 November 2025 (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

（MediaWiki:Statistics 已存在，归功于 Special:Statistics。）

谢谢！ --Lakejason0 (讨论) 13:52, 4 February 2023 (UTC)回复

听起来可行。

虽然有针对 "Table of Contents"（目录）的 MediaWiki:vector-toc-menu-tooltip，但那个没有使用句首大写（sentence case），而且看它的名称，过度依赖它可能不是个好主意。

-- nl6720 (讨论) 15:48, 4 February 2023 (UTC)回复

也许问题在于没人提供翻译。我想说如果他们愿意添加翻译，只需添加一个 MediaWiki talk: 即可。无论如何，对于两种中文：

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

虽然我不清楚 MediaWiki 如何处理 Accept-Languages，但至少对于（像我这样）在 Special:Preferences 中设置界面语言的人来说是有用的。--Lakejason0 (讨论) 04:59, 5 February 2023 (UTC)回复

这方面有进展吗？ --Lakejason0 (讨论) 08:50, 22 February 2023 (UTC)回复

更新 Intel 域名的链接

Intel 更改了他们的域名，以下所有链接都指向一些通用的着陆页

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

— Lahwaacz (讨论) 09:18, 30 July 2023 (UTC)回复

Bug 迁移

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

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

Klausenbusk (讨论) 20:42, 25 November 2023 (UTC)回复

已由 Matthewq337 (讨论) 修复

重新开启，因为 wiki 上仍有许多过时的链接。你检查并尝试更新上述列表中的所有页面了吗？ Lahwaacz (讨论) 17:13, 1 December 2025 (UTC)回复

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

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

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

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

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

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

Comic-paralyze-image (讨论) 18:51, 1 March 2025 (UTC)回复

Dovecot 2.4

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

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

已修复 Matthewq337 (讨论)

提到的页面仍未更新，甚至没有标记为过时。 Lahwaacz (讨论) 17:11, 1 December 2025 (UTC)回复

将 `# dmesg` 替换为 `$ journalctl -k`

……因为这会产生更好的格式化输出（日期），并且可以在没有 root 权限的情况下使用？ --Cvlc (讨论) 10:49, 25 July 2025 (UTC)回复

👍 支持将 dmesg 替换为 journalctl，但你不能使用 $。参见 systemd/Journal#Journal access as user -- nl6720 (讨论) 10:55, 25 July 2025 (UTC)回复

是的，抱歉，那正是我要表达的意思。据我所知，你不能仅仅通过将自己加入 wheel 组来获得 dmesg 的访问权限。 Cvlc (讨论) 12:50, 25 July 2025 (UTC)回复

我正考虑促成此事，但我注意到仅仅将 dmesg 替换为 journalctl -k 是不够的；输出内容也应该更新。我想获取每次使用的真实输出是不可行的。那么，仅仅将 dmesg 输出的第一部分替换为一些格式化为 journalctl -k 输出的随机日期是否足够？或者因为我们会改变真实输出而显得不现实？你们怎么看？ İsmail Arılık (讨论) 08:16, 25 November 2025 (UTC)回复

我认为最好从我们可以获得真实输出的地方开始。至于伪造输出，在我看来，在这些地方我们可以省略时间戳。 -- nl6720 (讨论) 08:27, 25 November 2025 (UTC)回复

机器人请求

最近评论：6 月 12 日14 条评论5 人参与讨论

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

自动添加/更新外部维基托管语言的语言链接

一些语言托管在外部维基上，我希望机器人能够自动添加/更新托管在外部维基上的语言链接，以便用户无需手动添加。 -- Blackteahamburger (讨论) 15:27, 20 May 2020 (UTC)回复

外部维基使用的标题可能与 “英文标题 (语言)” 不同，由于机器人不具备人类语言理解能力，它无法确定应该在哪些页面上添加哪些链接。 -- Lahwaacz (讨论) 08:34, 21 May 2020 (UTC)回复

可以通过外部维基上的跨语言链接来判断吗？ -- Blackteahamburger (讨论) 09:13, 21 May 2020 (UTC)回复

可以，但机器人必须连接到多个地方。这也许可行，但也可能最后比我们现在的还要乱……当我没别的事做的时候，也许会尝试一下。 -- Lahwaacz (讨论) 15:32, 13 August 2020 (UTC)回复

有没有可能检测被链接的页面是否存在？我今天偶然发现了两个笔记本电脑页面，链接了日语翻译但该页面并不存在。 --Erus Iluvatar (讨论) 13:55, 20 October 2022 (UTC)回复

关于 Template:Broken package link 的提示

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

如果你手动翻译了提示，机器人稍后会将其覆盖为英文。翻译必须添加到 wiki-scripts 中，我不确定最好的做法是什么。 -- Lahwaacz (讨论) 11:38, 26 May 2020 (UTC)回复

我认为你可以将翻译添加到 wiki-scripts 中，这很不错。 -- Blackteahamburger (讨论) 11:53, 26 May 2020 (UTC)回复

失效的跨维基链接

我们已经对外部链接、官方仓库及 AUR 中的失效软件包进行了标记：能否对跨维基 (interwiki) 链接也做同样的处理？我最近看到一些被手动修复的情况，尤其是在翻译页面上。 --Erus Iluvatar (讨论) 19:41, 2 March 2022 (UTC)回复

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

移除失效翻译

如你在 Special:Diff/835558 中所见，失效的翻译链接无法被自动检测和移除。让机器人扫描这些应该不难。如果上面的 #失效的跨维基链接也能检测托管在其他维基（例如德语 ArchWiki）上的失效翻译，那就更好了。 -- NetSysFire (讨论) 09:19, 12 June 2025 (UTC)回复

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

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

至少有一个翻译团队在页面上不使用此模板，而且至少有一个页面本身就不是翻译 — andreymal (讨论) 10:36, 12 June 2025 (UTC)回复

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

-- Erus Iluvatar (讨论) 10:54, 12 June 2025 (UTC)回复

删除请求

最近评论：12 月 1 日4 条评论2 人参与讨论

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

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

DeveloperWiki:HOWTO Be A Packager

删除 DeveloperWiki:HOWTO Be A Packager ——它太酷了以至于不该存在。我是说，我们已经有了 DeveloperWiki:How to be a packager，原始名称没用。 — Andrei Korshikov (讨论) 14:02, 3 September 2025 (UTC)回复