ArchWiki 讨论:请求

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

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

创建请求

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

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

桌面环境的左手习惯调整

我一直在想，如果为每个桌面环境列出配置选项，以方便左手用户使用鼠标和触摸板，这对左撇子会很有帮助。我不确定这是否与 Arch 足够相关，可以包含在 Wiki 中，但我自己在查找我的 DE (KDE) 的信息时运气不佳，更不用说其他的了。我将开始记录信息，如果其他人不认为应该为此单独设立一个页面，我只会将我找到的信息添加到每个单独的 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#故障排除有点缺乏，绝对可以从更多信息中受益，例如如何检测坏镜像。镜像出现故障并非极其罕见，因此绝对应该涵盖此主题，包括告知谁关于坏镜像，以便可以将其从镜像列表中删除等。

这个主题影响了足够多的人，值得将其放在这里。

-- 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)回复

可观测性

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

作为一名新兴的云工程师，我对 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 的方法对我不起作用，所以我不得不遵循他们分散的手动说明。我遇到了一些问题，所以我去他们的论坛寻求帮助。他们有社区成员提供第一线支持，并且至少针对我的一个问题，他们实际上为此创建了一个 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 (讨论) 18:00, 2024年9月17日 (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 驱动器命名是一种可行的方法。这将简化各种情况下的驱动器命名过程

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

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

好的，我知道这是一个很大的建议。我想在这里提出来，因为我的印象是，遵循一条主要路径将对每个人都有很大的帮助。这不需要在一天内完成。但我认为有一个建议的指导方针将是一个好的开始。然后，有了这个想法，我们在编写/编辑 Wiki 条目时，都可以更容易地更改这些部分。

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

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

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

建议：不妨使用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/[~~YOUR~~UUID] /mnt”格式的想法（我们将此类实例称为“伪变量”）。但是，如果你在文章上下文中使用它，例如加密的 LVM，你仍然需要更详细地描述哪个 dev/blockdevice/vg/lv UUID 旨在挂载到 /mnt。我仍然无法真正想象在一般情况下编写和阅读它会更容易。

正如我上面所写，我同意我们可能需要更多地指出持久命名的优势，但我们已经做了一些（例如，从一开始就：初学者指南#生成 fstab）。简而言之，我相信我们目前的做法更好（对此没有规定，只要贡献符合所贡献的文章，所有编辑都可以选择上下文中最佳的方式）。这就是我想说的。期待阅读反馈和其他意见。 --Indigo (讨论) 20:46, 2015年3月31日 (UTC)回复

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

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

只需输入 lsblk -f，就可以清楚地了解哪个 UUID 指向哪个驱动器，无论在什么上下文中（raid、luks、lvm 等）。正如这个获取 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。是的，如果事情看起来很复杂，那么有一个好的实际例子总是更好。我现在很忙。当我有时间的时候，我会开始按照我之前提到的那样（慢慢地）更改 Wiki。LVM 是一个不错的例子，但我希望从那些更容易适应且更常用的部分开始。特别是如果我需要事先添加一个新的子节（你如何使用 UUID）。 --T.ask (讨论) 10:44, 2015年4月21日 (UTC)回复

正如我所说，如果你在实际“更改 Wiki”之前，在这里或你的用户页面上向我们展示一个示例会更好。当然，慢慢来 :) — Kynikos (讨论) 02:30, 2015年4月22日 (UTC)回复

放弃 i686 支持

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

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

— Kynikos (讨论) 08:57, 2017年1月26日 (UTC)回复

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

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

--Indigo (讨论) 09:32, 2017年1月27日 (UTC)回复

我认为保留 Migrating between architectures 页面是好的，它至少也从 FAQ 页面链接过来了。

— Kynikos (讨论) 08:57，2017年1月26日 (UTC)回复

关于 Makepkg#在64位系统上构建32位软件包和 Install bundled 32-bit system in 64-bit system，我不确定，也许它们在过渡期间对某些人有用？

— Kynikos (讨论) 08:57，2017年1月26日 (UTC)回复

schroot 重定向到 Install bundled 32-bit system in 64-bit system。我认为我们应该继续保留一个页面，展示设置 schroot 的示例。在 schroot 中运行 Fedora、Ubuntu 等有时很有用。我认为应该修改（并重新命名）这篇文章，使用 32 位 Arch 以外的其他东西作为示例。Bobpaul (讨论) 17:46，2017年7月17日 (UTC)回复

看起来 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 固件位数。需要检查在放弃 i686 后，是否会继续构建 i386.efi 引导加载程序文件 (FS#52772)。根据结果，尽早将 Category:引导加载程序内容重新调整为 x86_64 可能会很有用？

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

事实证明我之前的研究是错误的，32 位 efi 文件无论如何都没有打包。因此，需要这些文件的用户需要生成它们，详情请参阅 FS#52772。当 Category:引导加载程序文章中消除对 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 的文章中（可能也分散在其他 web server 页面中）。我认为，如果将此信息移动到一个专用页面，或者 PHP 的子页面，那么所有 web server 页面和 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)回复

如果 Red、Blue 和 Green 已被弃用，那么可能 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#“截至 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，但是那个没有使用句子首字母大写，而且看它的名字，过度依赖它可能不是最好的主意。

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

也许问题是没有人提供翻译。我想说，如果他们想添加翻译，那么就添加一个 MediaWiki 讨论页。无论如何，对于中文来说

en	zh-hans	zh-hant	note
目录	目录	目錄
互动	参与	參與	“Interaction” 在中文中是一个相当正式的词（至少对于简体来说），翻译成 “Getting involved”（参与）。
贡献	贡献	貢獻
最近讨论	最近讨论	近期討論	从 “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-05 以来，它也不再是 Arch 仓库的一部分（仅在 AUR 中）。我认为在 ArchWiki 中记录 AUR 中的软件（!= 为 AUR 软件包提供官方支持）是在 ArchWiki 的范围之内的；我现在只能想到 dwm，但我确信还有更多。但是，维护旧的 Qt 内容意味着将其保留在 Qt 页面和相关页面中（！）。随着 Qt6 的普及，我认为我们应该考虑从主 wiki 中删除 Qt4 内容。我还没有搜索过出现的次数，但我至少自愿将它们汇总到 User:CodingKoopa/Removed content 中。 -- CodingKoopa (讨论) 16:12, 2023年6月25日 (UTC)回复

更新到 Intel 域名的链接

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

实际上，所有 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)回复

机器人请求

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

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

软件包链接到 wiki 链接

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

这没那么简单，因为诸如 git#Installation、List of applications 以及可能许多其他地方的软件包链接不应该被替换。 -- 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 的提示

localization 页面上标记的 Template:Broken package link 的提示可以使用本地化版本吗？这允许不理解英语的用户了解软件包的状态。 -- Blackteahamburger (讨论) 11:34, 2020年5月26日 (UTC)回复

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

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

Arch 的 git URL

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

-- nl6720 (讨论) 08:47, 2020年7月22日 (UTC)回复

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

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

失效的跨 wiki 链接

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

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