ArchWiki talk:Requests

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

创建请求

镜像故障排除

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

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

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

坏镜像的情况我现在已经涵盖了。是否应该增加另一个关于镜像返回 404 的章节，还是 Pacman#Packages_cannot_be_retrieved_on_installation 里的信息已经足够了？ --Mpan (讨论) 08:19, 2021年8月6日 (UTC)

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

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

已修复 --Matthewq337 (讨论) 01:35, 2026年1月25日 (UTC)

就我从 Matthewq337 的其他编辑来看，他放“fixed”挺随意的。所以，真的修复了吗？ — Andrei Korshikov (讨论) 18:16, 2026年1月28日 (UTC)

将 Flatpak 应用程序排障内容收纳至子页面

正如 Talk:Steam#Remove/move flatpak instructions 中建议的那样，我们应该创建一个 Flatpak/Application-specific troubleshooting，为那些使用 Arch 同时也选择非原生软件包的人提供一个中心场所。

--Erus Iluvatar (讨论) 11:23, 2026年2月2日 (UTC)

我不反对，但是……仅仅使用 Flatpak#Troubleshooting 怎么样？Flatpak 页面并不是很长，真的需要子页面吗？

当然，作为读者我喜欢子页面，但作为编辑我讨厌它们 :) 所以……这只是另一个澄清问题 :)

— Andrei Korshikov (讨论) 14:12, 2026年2月6日 (UTC)

在我看来，“排障（Troubleshooting）”章节是用于排查 Flatpak 本身或所有（或大部分）Flatpak 应用程序通用的问题，而建议的页面更像是我们已经拥有的 Steam/Game-specific troubleshooting、CUPS/Printer-specific problems 等……

不过我很好奇为什么你作为编辑会讨厌子页面？

-- Erus Iluvatar (讨论) 19:01, 2026年2月6日 (UTC)

啊哈，我明白了。那是另一种排障 :) 现在我理解并同意了。

不过我很好奇为什么你作为编辑会讨厌子页面？

哎呀……睡了一觉后，我同意我选词有点奇怪 :)

作为编辑，我唯一讨厌的情况是从主页面拆分出来的排障子页面，因为这种拆分会破坏历史记录。当然，某种维基溯源（wiki blame）会有所帮助，但那是另一回事了 :)

也就是说，明确一点，我通常当然喜欢子页面（因为我喜欢结构化的方法等等），但当我看到“/Troubleshooting”时……我确实感到忧郁 :) — Andrei Korshikov (讨论) 09:10, 2026年2月7日 (UTC)

啊是的，这让我想起我第一次想看新手指南（Beginners' guide）早期历史的时候 :D

-- Erus Iluvatar (讨论) 09:33, 2026年2月7日 (UTC)

修改请求

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

从其他发行版创建软件包

我们能否在 Arch 软件包指南中增加一个章节，讨论如何为二进制软件包（例如来自 .deb 文件）创建 PKGBUILD？

--Stickynotememo (讨论) 04:04, 2026年4月1日 (UTC)

(a) Arch 软件包指南肯定不合适：它是关于从源代码为 Arch 官方仓库打包的。

(b) @Stickynotememo，你漏掉了什么（即你有哪些未解决的问题）？用于 .deb 的 PKGBUILD 只是从归档中提取文件，仅此而已（参见我的例子，https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cvs-feature-bin）。

我想以“不是问题”为由关闭此主题。 — Andrei Korshikov (讨论) 18:29, 2026年4月13日 (UTC)

(a) 据我所见，APG 同时涵盖了 AUR 和官方软件包；两者都属于“Arch 软件包”旗帜下，因为它们都使用 PKGBUILD 和 makepkg。

(b) 我知道这些解释在互联网的其他地方也存在，但 Arch Wiki 上的许多页面大概也可以这么说。能有个解释还是挺好的。你可以放上去的内容包括：从哪里获取 debian 软件包、解压缩步骤等。不过，还是由你决定。 Stickynotememo (讨论) 11:03, 2026年4月20日 (UTC)

(a)

据我所见，APG 同时涵盖了 AUR 和官方软件包

你能解释一下吗？特别是“据我所见”——你在哪里见到的？

当然，AUR 软件包通常遵循官方软件包的指南，但这更多是一种礼仪上的事情，而不是强制性规则。

(b)

从哪里获取 debian 软件包、解压缩步骤等。

啊哈，我明白了。我们已经有了 Creating packages for other distributions，而你请求的是类似 Creating packages/From other distributions 的内容。我会重新开启并重命名这个主题。 — Andrei Korshikov (讨论) 17:07, 2026年4月20日 (UTC)

不，这个问题基本上是将 .deb 文件重新打包为 Arch Linux 软件包，而不是在其他发行版上制作 Arch 软件包。

关于 Arch 软件包指南：该页面旨在涵盖所有 Arch 软件包的规则，尤其是官方软件包。不涉及官方软件包的特定案例和场景不在讨论范围内。此外，可行的事情并不一定等同于应该做的事情。大家达成了强烈的共识，即 Arch 软件包应该从源代码构建，虽然 AUR 并不禁止二进制软件包，但我们认为没必要为此类情况制定正式指南。

Lahwaacz (讨论) 13:13, 2026年4月21日 (UTC)

这个问题基本上是将 .deb 文件重新打包为 Arch Linux 软件包

我试着说，通常情况下，这个问题是关于将 .deb / .rpm / 其他任何格式 重新打包为 Arch Linux 软件包。我发现“Creating packages/From other distributions”看起来有误导性。Repackaging 或 Creating packages/Repackaging 应该是更好的名称 :)

— Andrei Korshikov (讨论) 06:59, 2026年4月23日 (UTC)

将驱动器命名/访问方式更改为 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 (讨论) 11:22, 2015年3月30日 (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 (讨论) 17:47, 2015年3月30日 (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 (讨论) 13:24, 2015年3月31日 (UTC)

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

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

(2) 我喜欢你使用 "/dev/disks/by-uuid/[YOURUUID] /mnt" 格式的想法（我们称这类实例为“伪变量”）。尽管如此，如果你在文章上下文中使用它，例如加密的 LVM，你仍然需要更详尽地描述哪一个 dev/blockdevice/vg/lv UUID 是要挂载到 /mnt 上的。我还是没法想象这在总体上是如何让读写变得更简单的。

正如我上面写的，我同意我们可能需要更多地指明持久化命名的优点，但我们已经在做一些工作了（例如，从一开始就有：Beginners' guide#Generate an fstab）。简而言之，我认为维持现状会更好（不设硬性规定，只要贡献符合所贡献的文章，所有编辑都可以选择最适合语境的方式）。我的看法就是这些。期待阅读反馈和其他意见。 --Indigo (讨论) 20:46, 2015年3月31日 (UTC)

在我看来，手册页的示例有时会落后于“新标准”。这是自然的，这不应阻止我们前进。在 Arch 中，我们有 UUID —— 让我们使用它们吧 :)

如果用户不了解 UUID，我们可以引导他们查看一份简短的转换表/文章，了解如何切换到 UUID。实际上，这比通常认为的要容易理解得多。

• 只需输入 lsblk -f，就可以在任何上下文（RAID、LUKS、LVM……）中清楚地看到哪个 UUID 指向哪个驱动器。如这个 获取 UUID 的示例 所示，只需复制相应的 UUID 并将其用于所有 UUID Wiki 示例。我认为这相当简单。

我明白你的出发点，但我确信读者会很快学会 UUID 的用法。新用户甚至不会知道以前有哪些其他选项。此外，由于读者已经熟悉了 UUID，他们以后在移动驱动器位置时就不会遇到问题。经验丰富的用户只需阅读转换表/文章即可。

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

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

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

嗨，T.ask，感谢讨论此事，但我不太确定这是否纯属理论，或者你是否已有具体的实施方案，因为在读完所有的讨论后，我还没太明白这个想法会如何改变我们的文章。在这个阶段，你必须选择我们其中一篇重要文章（例如 LVM），并详细向我们解释文章会如何改变，这样我们才能就更具体的东西进行讨论。 — Kynikos (讨论) 14:37, 2015年4月2日 (UTC)

嗨，Kynikos。是的，如果事情看起来很复杂，有一个好的实际案例总是更好。我现在很忙。等我有时间了，我会像我之前提到的那样，开始（缓慢地）修改维基。LVM 是一个很好的例子，但我希望从那些更容易调整且更常用的章节开始。特别是如果我需要事先增加一个新的子章节（如何使用 UUID）。 --T.ask (讨论) 10:44, 2015年4月21日 (UTC)

正如我所说的，如果你在真正开始“修改维基”之前，能在这里或你的用户页给我们展示一个例子，那就太好了。当然，慢慢来 :) — Kynikos (讨论) 02:30, 2015年4月22日 (UTC)

php-fpm

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

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

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

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

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

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

听起来可行。

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

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

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

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

虽然我不知道 MediaWiki 如何处理 Accept-Languages，但至少这对于像我这样在参数设置中设置界面语言的人来说是有用的。--Lakejason0 (讨论) 04:59, 2023年2月5日 (UTC)

这方面有进展吗？ --Lakejason0 (讨论) 08:50, 2023年2月22日 (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 (讨论) 09:18, 2023年7月30日 (UTC)

Bug 迁移

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

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

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

已由 Matthewq337 (讨论) 修复

重新开启，因为维基上仍散布着许多过时的链接。你检查并尝试更新了上述列表中的所有页面了吗？ Lahwaacz (讨论) 17:13, 2025年12月1日 (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, 2025年3月1日 (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, 2025年12月1日 (UTC)

将 # dmesg 替换为 $ journalctl -k

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

👍 支持用 journalctl 替换 dmesg，但你不能用 $。参见 systemd/Journal#Journal access as user -- nl6720 (讨论) 10:55, 2025年7月25日 (UTC)

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

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

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

修复 ubuntuforums.org 链接

我今天发现 https://ubuntuforums.org/ 会静默重定向到 https://discourse.ubuntu.com/，这导致大约 70 个页面链接失效了

• Special:LinkSearch/https://ubuntuforums.org/

--Erus Iluvatar (讨论) 19:45, 2026年2月21日 (UTC)

其中一些有存档页面，例如 https://web.archive.org/web/20210801003830/https://ubuntuforums.org/showthread.php?t=1458300 我们可以使用存档机器人来帮我们做这件事 https://meta.wikimedia.org/wiki/InternetArchiveBot Matthewq337 (讨论) 21:25, 2026年2月24日 (UTC)

我们办不到，机器人不在这个 Wiki 上运行。而且将失效链接替换为 archive.org 的链接并不总是最佳解决方案。 — Lahwaacz (讨论) 10:43, 1 March 2026 (UTC)

机器人请求

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

有些语言托管在外部 Wiki 上，我希望机器人能自动为这些语言添加/更新语言链接，这样用户就不需要手动添加了。 -- Blackteahamburger (讨论) 15:27, 20 May 2020 (UTC)

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

能否通过外部 Wiki 上的跨语言链接来判断？ -- 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 中的失效软件包：我们能对跨 Wiki (interwiki) 链接做同样的处理吗？我最近看到一些手动修复的例子，特别是在翻译页面上。 --Erus Iluvatar (讨论) 19:41, 2 March 2022 (UTC)

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

移除失效翻译

正如你在 Special:Diff/835558 中看到的，失效的翻译不会被自动检测和移除。让机器人扫描这些应该不难。如果上面的 #失效跨 Wiki 链接 也能检测托管在其他 Wiki（例如德国 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)

重定向移除请求

Screen

我同意 @Alad 的观点，"screen" 应该是关于 "GNU screen" 及其同类（尤其是 tmux）。我想删除 screen 消歧义页面，并将 GNU Screen 重命名为 screen。如何正确地执行此操作？

— Andrei Korshikov (讨论) 20:13, 6 September 2025 (UTC)

Matthewq337 (讨论) 已修复

这仍然没有完成。 Lahwaacz (讨论) 17:08, 1 December 2025 (UTC)

Lean

能否请你

(a) 移除 Lean 重定向，

(b) 将 Lean Theorem Prover 移动到 Lean 且“不保留重定向”——参见 Talk:Lean Theorem Prover#重命名此页面为 Lean。

— Andrei Korshikov (讨论) 17:46, 9 March 2026 (UTC)

已完成 Matthewq337 (讨论) 19:15, 9 March 2026 (UTC)

不对，你又做错了。 — andreymal (讨论) 21:19, 9 March 2026 (UTC)

我已经重命名了它，但保留了重定向，因为还有页面链接到它。 — Lahwaacz (讨论) 18:10, 10 March 2026 (UTC)

我在创建此请求之前已经替换了所有链接。此外，Special:链入页面/Lean Theorem Prover 显示只有 ArchWiki talk:Requests（即本次讨论）链接到了那里。我漏掉了什么吗？

我希望移除此重定向，原因是：

(a) 它（几乎）毫无用处——参见 Talk:Lean#重命名此页面为 Lean 了解原因，

(b) 无论如何它都违反了“句首字母大写 (Sentence case)”规则 :)

— Andrei Korshikov (讨论) 09:10, 12 March 2026 (UTC)

顺便提一下，如果页面是关于一个上游要求大写的软件，那么“句首字母大写”规则是可以有例外的，例如我们有 Advanced Linux Sound Architecture。不过，既然在这种情况下它是一个未使用的重定向，那就关闭请求吧 :） --Erus Iluvatar (讨论) 17:19, 28 May 2026 (UTC)