ArchWiki 讨论:请求

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

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

创建请求

最新评论： 2024 年 9 月 17 日14 条评论11 人参与讨论

在此处列出您认为应在 ArchWiki 上涵盖的主题的请求。如果不太明显，请解释为什么 ArchWiki 覆盖是合理的（而不是现有的 Wikipedia 文章或其他文档）。此外，请考虑自行研究和创建初始文章（请参阅 Help:Editing 以获取内容创建帮助）。

桌面环境的左手习惯调整

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

我认为单独的页面更好。 -- Fengchao (讨论) 11:58, 2013 年 8 月 12 日 (UTC)回复

iPXE

iPXE 是一个功能强大的网络引导程序，具有许多功能。目前，没有专门描述 iPXE 详细信息的 iPXE 页面。Wiki 中有一些页面提到了 iPXE，主要与网络引导有关，但没有关于如何让 iPXE 工作的进一步说明。所以我认为值得在 Wiki 中添加一个详细解释 iPXE 的页面。 Alive4ever (讨论) 10:08, 2016 年 7 月 21 日 (UTC)回复

我最近将 ipxe 添加到了 [community]，除了默认设置外，它还具有允许 iPXE 引导到 Arch Linux 特定端点所需的二进制文件。如果能有一个关于此的页面就太好了，我将尽快在 iPXE 上工作。 Davezerave (讨论) 09:54, 2021 年 6 月 17 日 (UTC)回复

缺失重定向

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

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

TOML 多年来发展迅速，因此创建一个页面来列出与 toml 兼容的软件包（如库），并简要解释 TOML 是什么（引用他们的文档），以及链接到他们的文档，这将是一个有用的页面。

祝您愉快，PolarianDev (讨论) 10:56, 2023 年 5 月 11 日 (UTC)回复

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

镜像故障排除

不幸的是，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)回复

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

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

查看 mw:Manual:Random page，看起来不可能，因为 ArchWiki 将所有翻译都放在主命名空间中。 -- nl6720 (讨论) 09:40, 2023年5月19日 (UTC)回复

可观测性

这篇文章可以从引用和链接到维基百科上关于同一主题的文章开始。我还有一个想法，在“通用建议”页面，甚至在应用程序列表中添加一个简短的介绍（在该部分的顶部显眼地链接到主要的可观测性文章）。

作为一名新兴的云工程师，我对 Web 应用程序/服务以及我自己的业余项目中的可观测性越来越感兴趣。我已经对此进行了一些研究，并且对一些不同的选项略有了解。我发现的大多数是开源的，我想从这个“可观测性”页面中链接到一些选项，并可能提供完整的 wiki 文章来描述各种选项。也有更多交钥匙式的商业产品，我们可以列出其中一些，并提供链接以获取更多信息。我实际上从其中一个开始使用，主要是为了了解哪些功能对我来说很重要，然后我再拼凑一些更手动的选项。

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

我甚至了解了 Pressure Stall Information，并编写了自己的脚本来监控和警报 CPU、I/O 或内存压力过高的情况。它在一个公共 Git 存储库中，但我想在任何地方分享它的链接之前，先完善一些文档。

像这样的 Arch Wiki 文章是否值得？我认为是值得的，但我不想在没有先讨论的情况下就开始编写它。Ectospasm (讨论) 18:00, 2023年12月17日 (UTC)回复

安装指南

感谢 Arch Linux 的滚动发布模式，我实际上只安装过几次 Arch。而 Wiki 在记录这个过程方面非常出色。我第一次安装 Arch 时，我没有另一台电脑可以访问 wiki，也没有想到使用我的手机。我只是在我使用的桌面系统上使用了单独的虚拟控制台，并在文本模式浏览器（elinks 或 lynx，我不记得是哪个）中加载了 wiki。我甚至可能启用了 GPM，以便我可以在 Linux 控制台中使用鼠标复制和粘贴（这部分我不太记得了）。

然而，每次我安装 Arch 时，我都想要一些特定的东西，这通常意味着搜索、遵循和回溯多个 Wiki 文章才能达到我的目的。现在我有一台新笔记本电脑，并且我计划很快在它上面安装 Arch，我已经为自己起草了一个“指南”来遵循。我被告知发布这样的“指南”违背了 Wiki 的精神，但我发现要浏览所有文章来拼凑我想要做的事情很费劲，尤其是在没有提前计划的情况下。我认为许多 Arch 用户可能会发现这样的“指南”很有用，即使只是为了获得他们自己系统的想法。

我认为这些“指南”的格式需要讨论，因为我不确定哪种方式最好。我们绝对不希望复制或重复 wiki 中的部分内容。这是我提出的格式，但我不确定这是最好的方法。首先，从指南的硬件先决条件开始。文件服务器或网络附加服务器 (NAS) 的指南与笔记本电脑或 x86_64 掌上电脑或移动设备的指南不同，虚拟专用服务器 (VPS) 或其他虚拟机的指南也不同。该指南可以继续描述分区布局、文件系统、引导加载程序、网络拓扑和相应的网络管理器等。每个决策背后的理由可以用作者想要的任何细节来解释。然后，它可以提供一个链接到一个（伪）脚本来执行它，可能会在用户需要做出决策的地方暂停。我不熟悉 Archinstall，但如果它们运行良好，也许它们可以成为 Archinstall 脚本的可选组件（但这可能有点超前了）。

处理这种文档并保持 wiki 精神的正确方法是什么？或者这真的是一个坏主意吗？如果这是一个坏主意，为什么会这样呢？我的意思是，Wiki 中的这样一个部分可以有一个免责声明，声明读者必须理解安装过程，而不是盲目地遵循所列出的内容。当然，链接回描述如何执行每项任务的 Wiki 文章应该遍布这些“指南”，我不认为这些是理解安装指南的替代品。也许 wiki 不是放置这个的最佳场所；wiki 可以收集来自不同用户的指南链接，而指南本身可以托管在 Arch Linux GitLab 实例上。Ectospasm (讨论) 22:14, 2023年12月17日 (UTC)回复

关于如何优化隐私的文章

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

尤其是在许多页面上，例如NetworkManager/隐私或Firefox/隐私，我们已经有关于特定应用程序隐私相关配置的页面。如果您在 Arch 之外搜索，尤其是在 Linux 系统配置方面，您必须查看许多网站，有时还需要更改一些内容才能使其在 Arch 上工作。

SolarpunkJulian (讨论) 2024年9月17日 (星期二) 18:00 (UTC)回复

修改请求

最新评论： 2023年11月25日37 条评论16 人参与讨论

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

作为一个滚动发布版本，Arch 不断接收更新和改进。因此，Arch Wiki 必须快速更新以反映这些更改。

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

目前，安装带/不带 Luks、LVM 的内部和外部驱动器非常复杂。相关的文章提出了实现目标的不同方法。建议使用许多不同的驱动器命名约定，例如：

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

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

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

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

好的，我知道这是一个很大的建议。我想在这里提出它，因为我的印象是，遵循一条主要路径将对所有相关人员有很大帮助。这不需要一天完成。虽然我认为有一个建议的指导方针将是一个好的开始。然后考虑到这一点，我们在编写/编辑 Wiki 条目时，更容易更改这些部分。

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

嗨，关于您自己的上述示例：对于 /dev/mapper/* 设备声明，通常不需要使用 UUID（设备的唯一性在映射时确定）。我认为您高估了实际需要设置真正重要示例（例如，外部驱动器）的用户数量。我不明白的是，为什么您认为使用 UUID 更容易阅读/描述。首先，可怕的长 UUID 在许多情况下会破坏格式，例如，使代码块内联变得不可能。UUID 本身不提供上下文提示，而设备名称则提供。如果您查看持久块设备命名#引导管理器中的三个示例，您真的觉得 UUID 的那个最容易理解吗？

我认为您肯定是对的，我们可能在某些文章中缺少对持久块设备命名的交叉链接，而在这些文章中使用 UUID 可能很重要。也许我们还需要一个示例部分来说明持久块设备命名中的单个重要点，并且可能存在一些单独的文章/章节，其内容确实应该直接使用某种形式的持久命名。

建议：如何使用Talk:持久块设备命名来汇编一份特定文章章节的列表，其中应更突出地显示持久命名？这样我们也可以弄清楚是否以及哪些示例可能对添加有用。 --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 (talk) 20:46, 2015年3月31日 (UTC)Reply

我认为手册页的例子有时有点落后于“新标准”。这是很自然的，但这不应该阻止我们向前迈进一点。在 Arch 中，我们有 UUID - 让我们使用它们吧 :)

如果用户不知道 UUID，我们将引导他/她阅读一个关于如何切换到 UUID 的简短转换表/文章。实际上，它比通常认为的更容易掌握。

只需输入 lsblk -f，就可以清楚地看到哪个 UUID 指向哪个驱动器，在任何上下文中（raid, luks, lvm, ...）。正如这个获取 UUID 示例所展示的，只需复制相应的 UUID 并将其用于所有 UUID Wiki 示例。恕我直言，这非常容易。

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

你看，我非常有信心用户会轻松掌握 UUID。此外，这将防止他/她将来遇到问题。我们只需要迈出第一步的勇气。这不是我们需要在一天内完成的事情。我们有足够的时间慢慢朝着一个方向前进。

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

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

嗨，Kynikos，感谢你参与讨论，但是我不确定这是否只是理论上的探讨，或者你是否有一个关于如何将其付诸实践的明确想法，因为在阅读了所有讨论之后，我还没有完全理解这个想法将如何改变我们的文章。在这个阶段，你必须选择我们的一篇重要文章，例如 LVM，并详细向我们解释这篇文章将如何改变，这样我们就可以讨论更具体的东西。 — Kynikos (talk) 14:37, 2015年4月2日 (UTC)Reply

嗨，Kynikos。是的，如果事情看起来很复杂，有一个好的实际例子总是更好。我现在很忙。当我找到时间时，我会像我之前提到的那样开始（缓慢地）更改 Wiki。 LVM 是一个很好的例子，我想从那些更容易调整和更常用的部分开始。特别是如果我需要事先添加一个新的小节（如何使用 UUID）。 --T.ask (talk) 10:44, 2015年4月21日 (UTC)Reply

正如我所说，如果你在实际开始“更改 Wiki”之前，在这里或在你的用户页上向我们展示一个例子，那就更好了。当然，慢慢来 :) — Kynikos (talk) 02:30, 2015年4月22日 (UTC)Reply

放弃 i686 支持

根据 [1]，我暂时做了这些编辑

还有很多其他文章需要更新，而且上面的编辑在 2017 年 11 月之后也需要修改。我认为最好在这里决定我们是立即删除所有 i686 内容，还是保留到最终弃用时再进行清理。

— Kynikos (talk) 08:57, 2017年1月26日 (UTC)Reply

嗨，我认为对于某些内容，这将取决于开发人员在时间线上的进一步决定，例如，arch= 选项是否会有更改。我们应该稍等片刻，看看迁移计划是什么样的。恕我直言，一旦主题明确，即在截止日期之前，开始更新是有用的。另一个不确定因素是，社区是否会努力保持 i686 的某种程度的存续；任何这样的努力都会对如何更改产生影响。

总的来说，我认为相关内容的变化将非常广泛，以至于我们应该创建一个 Archwiki:Requests/Drop of i686 support（或一个顶级链接，如 Archwiki:Drop of i686 support - 更容易交叉链接）从这里链接过去。最好保持概览。

--Indigo (talk) 09:32, 2017年1月27日 (UTC)Reply

我认为保留在架构之间迁移是好的，它也至少从 FAQ 链接过来。

— Kynikos (talk) 08:57, 2017年1月26日 (UTC)Reply

关于 Makepkg#在 64 位系统上构建 32 位软件包和在 64 位系统中安装捆绑的 32 位系统，我不确定，也许它们在过渡期间对某些人有用？

— Kynikos (talk) 08:57, 2017年1月26日 (UTC)Reply

schroot 重定向到在 64 位系统中安装捆绑的 32 位系统。我认为我们应该继续保留一个页面，展示设置 schroot 的示例。有时在 schroot 中运行 Fedora、Ubuntu 等是很有用的。我想这篇文章应该被修改（并重新命名），以使用 32 位 Arch 以外的其他东西作为示例。Bobpaul (talk) 17:46, 2017年7月17日 (UTC)Reply

看起来 Install bundled 32-bit system in 64-bit system 已经被存档，但是仍然有一些外部链接。还有 Building 32-bit packages on a 64-bit system，但是我不确定那个页面过时多久了。Lonaowna（讨论）14:34, 2017年12月14日 (UTC)回复

最后，由于没有 i686 依赖的官方仓库可以用来构建，所以在 Archlinux 中已经没有任何方法可以原生构建 32 位软件包了（唯一的方法是使用 Archlinux32 的仓库创建一个构建 chroot 环境）。无论如何，这可能用途不大，因此，我已经存档了相关的页面。quequotion（讨论）14:53, 2019年6月5日 (UTC)回复

对于某些支持 x86_64 的硬件，存在 32 位 UEFI 限制。示例章节：Unified Extensible Firmware Interface#UEFI Firmware bitness。需要检查在 i686 被放弃后，是否会继续构建 i386.efi 引导程序文件（FS#52772）。根据结果，尽早将 Category:Boot loaders 内容重新基于 x86_64 可能会有用？

--Indigo（讨论）08:45, 2017年1月30日 (UTC)回复

结果证明我之前的研究有误，32 位 efi 文件无论如何都没有被打包。因此，需要这些文件的用户需要自行生成，详情请参阅 FS#52772。当在 Category:Boot loaders 文章中消除对 i686 的引用时，将此信息融入其中仍然是有用的。--Indigo（讨论）09:24, 2017年2月2日 (UTC)回复

我现在已经做了一些关于这方面的清理工作，但可能还有一些残留。--Erus Iluvatar（讨论）19:12, 2022年1月30日 (UTC)回复

php-fpm

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

需要修改的模板和页面

我正在修改模板以弃用 Template:META Box Red、Template:META Box Blue 和 Template:META Box Green，但我无法修改阿拉伯语模板（可能是因为阿拉伯语是从右向左排列的）。这些模板需要被修改

一些阿拉伯语页面也需要修改，请参阅 Special:WhatLinksHere/Template:META_Box_Blue、Special:WhatLinksHere/Template:META_Box_Red 和 Special:WhatLinksHere/Template:META_Box_Green。

-- Blackteahamburger（讨论）16:53, 2020年6月11日 (UTC) (编辑: 11:20, 2020年7月31日 (UTC))回复

我已经完成了 Warning、Note 和 Tip，但是剩下的确实更棘手... -- Kynikos（讨论）11:40, 2020年6月13日 (UTC)回复

似乎这只能由阿拉伯语用户修改... -- Blackteahamburger（讨论）11:59, 2020年6月13日 (UTC)回复

另请参阅 [2]。 -- Kynikos（讨论）04:05, 2020年6月14日 (UTC)回复

如果红色、蓝色和绿色被弃用，可能 Template:META Box Yellow 也应该跟进，或者重命名为更具意义的名称。 -- Kynikos（讨论）04:22, 2020年6月14日 (UTC)回复

我认为我已经修复了 Template:TranslationStatus (العربية)，修复了最后使用 Template:META Box Red 的内容页面，Template:META Box Blue 的最后一个内容页面是 Talk:Pacman，所以我没有动它，修复了最后使用 Template:META Box Green 的内容页面，并且 Template:META Box Yellow 看起来也不错！ --Erus Iluvatar (讨论) 19:50, 2022年1月30日 (UTC)回复

我正在查看标记为存档的最旧页面，它们是这四个 META Box。

Template:META Box Yellow 仅在 Template:Committed identity 中使用，但在 MediaWiki:Common.css 中没有替代类。
Template:META Box Red 仍然在受保护的 MediaWiki:Spamprotectiontext 中使用，但也提出了和之前相同的问题。
Template:META Box Green 仅在两个用户页面中使用：在存档之前应该对这些页面做些什么吗？
Template:META Box Blue 也仅在两个用户页面中使用，所以同样的问题适用。

--Erus Iluvatar (讨论) 19:22, 2022年3月2日 (UTC)回复

更新 WirePlumber 新的配置格式

WirePlumber 的配置格式正在更改。至少配置文件路径正在更改，但很可能需要进行实际的内容相关更改。我写了 WirePlumber#配置文件布局和 WirePlumber#修改配置，但我现在不想处理这些更新。

受影响的文章（不全面，欢迎修改）

谢谢，CodingKoopa (讨论) 03:36, 2022年10月28日 (UTC)回复

php-legacy

PHP 8.2 更新和引入 legacy 分支.

PHP 页面应该添加 php-legacy
提及 PHP7 的页面应该更新软件包和配置。

--Fengchao (讨论) 01:23, 2023年1月15日 (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)回复

本地化侧边栏文本

我不知道是否应该在这里发布，但这就是。

由于许多语言的 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、根）。

因此，为了本地化侧边栏，我们将创建一些 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)回复

听起来可行。

有 MediaWiki:Vector-toc-menu-tooltip 用于 “Table of Contents”（目录），但是那个没有使用句子首字母大写，并且看它的名字，依赖它可能不是最好的主意。

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

也许问题是没有人提供翻译。我想说如果他们想添加翻译，那么只需添加一个 MediaWiki talk: 即可。无论如何，对于中文

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

虽然，我不知道 MediaWiki 如何处理 Accept-Languages，但至少这对在Special:Preferences中设置界面语言的人（像我一样）会很有用。--Lakejason0（讨论） 04:59, 2023年2月5日 (UTC)回复

这方面有什么进展吗？ --Lakejason0（讨论） 08:50, 2023年2月22日 (UTC)回复

移除 Qt4 内容

Qt4 主要版本的 Qt GUI 工具包自 2015 年起已不再由 Qt 公司支持。自 2019 年 5 月起，它也不再是 Arch 仓库的一部分（仅在 AUR 中）。我认为在 ArchWiki 中记录 AUR 中的软件（!= 为 AUR 软件包提供官方支持）是符合范围的；我现在只能想到 dwm，但我确信还有更多。然而，维护旧的 Qt 内容意味着将其保留在 Qt 页面和相关页面中 (!)。随着 Qt6 的采用率不断提高，我认为我们应该考虑从主 wiki 中移除 Qt4 内容。我还没有搜索过这些内容出现的地方，但我至少自愿将它们汇总到 User:CodingKoopa/Removed content。 -- CodingKoopa（讨论） 16:12, 2023年6月25日 (UTC)回复

更新英特尔域名的链接

英特尔已更改其域名，以下所有链接都指向一些通用落地页

实际上，所有英特尔链接都应该由人工检查，因为机器人使用的脚本对大多数英特尔链接都获取状态 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)回复

机器人请求

最新评论：2022年10月20日15 条评论5 人参与讨论

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

软件包链接到 wiki 链接

如果机器人可以遍历并更改指向具有 wiki 条目的软件包的链接，将其更改为指向 wiki 条目的链接（例如，将 git 更改为 git），那将很好，可能也适用于 aur 软件包（例如，将 dropbox^AUR 更改为 dropbox）。 Jabranham（讨论） 19:42, 2018年7月31日 (UTC)回复

这并没有那么简单，因为像 git#Installation、应用程序列表以及可能许多其他地方的软件包链接不应该被替换。 -- Lahwaacz（讨论） 19:35, 2018年8月11日 (UTC)回复

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

有些语言托管在外部 wiki 上，我希望机器人自动为外部 wiki 托管的语言添加/更新语言链接，以便用户无需手动添加。 -- Blackteahamburger（讨论） 15:27, 2020年5月20日 (UTC)回复

外部 wiki 可以使用与“英文标题 (语言)”不同的标题，而且由于机器人不会说人类语言，因此它无法弄清楚应该在哪些页面上添加哪些链接。 -- Lahwaacz（讨论） 08:34, 2020年5月21日 (UTC)回复

可以根据外部 wiki 上的跨语言链接来判断吗？ -- Blackteahamburger（讨论） 09:13, 2020年5月21日 (UTC)回复

可以，但是机器人将不得不连接到多个地方。这可能行得通，但也可能最终比我们现在拥有的更混乱……当我没有什么更好的事情做时，我可能会尝试一下。 -- Lahwaacz（讨论） 15:32, 2020年8月13日 (UTC)回复

是否可以检测链接的页面是否存在？我今天偶然发现了两个笔记本电脑页面，其中链接了日文翻译，但该页面不存在。 --Erus Iluvatar（讨论） 13:55, 2022年10月20日 (UTC)回复

Template:Broken package link 的提示

标记在本地化页面上的Template:Broken package link模板的提示信息可以使用本地化版本吗？这可以让不理解英语的用户理解软件包的状态。 -- Blackteahamburger (talk) 11:34, 2020年5月26日 (UTC)Reply

如果您手动翻译提示信息，机器人稍后会将其覆盖为英文。翻译需要添加到 wiki-scripts 中，我不确定如何最好地做到这一点。 -- Lahwaacz (talk) 11:38, 2020年5月26日 (UTC)Reply

我认为您可以将翻译添加到 wiki-scripts 中，我认为这很好。 -- Blackteahamburger (talk) 11:53, 2020年5月26日 (UTC)Reply

Arch 的 git URL

git.archlinux.org 迟早会停止存在。目前尚不清楚何时（或是否）会有重定向，并且在项目迁移到 gitlab.archlinux.org 之后，git.archlinux.org 中的仓库可能不再更新。让我们准备更新 wiki 页面中的链接。

-- nl6720 (talk) 08:47, 2020年7月22日 (UTC)Reply

GitHub 上的项目也将迁移到 gitlab.archlinux.org。 -- nl6720 (talk) 14:04, 2021年6月14日 (UTC)Reply

我忘记了 git:// URL。已添加到列表中。 -- nl6720 (talk) 06:45, 2021年6月26日 (UTC)Reply

失效的跨wiki链接

我们已经标记了外部链接、仓库和 AUR 中损坏的软件包：我们可以对跨wiki链接做同样的事情吗？我最近看到一些手动修复的跨wiki链接，特别是在翻译中。 --Erus Iluvatar (talk) 19:41, 2022年3月2日 (UTC)Reply

这是个好主意，我们只需要找到人来委托实施... — Lahwaacz (talk) 15:18, 2022年3月13日 (UTC)Reply