ArchWiki 讨论:请求

来自 ArchWiki
（重定向自 ArchWiki:Reports）
最新评论：2024年9月17日 由 SolarpunkJulian 在主题 创建请求 中
注意： 有问题的编辑应直接在页面上通过适当的 文章状态模板 或在相应的 讨论页 上报告。

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

可观测性

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

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

当我在搜索监控我的个人 Web 项目的方法时，我偶然看到了 New Relic 的广告，它是众多商业服务之一。让我感到有趣的是，New Relic 的大多数工具都是开源的（在 Apache 2.0 许可证下，用 Go 编写）。他们每月提供 100GB 的数据上传量，这对于观察我在 VPS 上的业余项目来说已经足够了。我已经为我使用过的一些工具起草了（但尚未发布）PKGBUILD，主要来自他们预编译的 debs。AUR 中有 PKGBUILD（例如 newrelic-cliAUR 和 newrelic-infraAUR），但我没有看到描述如何使用它们的 Wiki 文章。不幸的是，Arch Linux 目前不受 New Relic 支持，他们仅使用 newrelic 命令（newrelic-cliAUR 的一部分）引导 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/Privacy 或 Firefox/Privacy）中，我们已经有关于特定应用程序隐私相关配置的页面，如果您搜索 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 驱动器命名是一种可行的方法。这将简化各种情况下的驱动器命名过程

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

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

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

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

嗨，关于您上面的示例：对于 /dev/mapper/* 设备声明使用 UUID 通常是不必要的（设备的唯一性在映射时确定）。我认为您高估了实际需要设置真正重要示例的用户数量（例如，外部驱动器）。我不明白的是，为什么您认为使用 UUID 更容易阅读/描述。首先，可怕的长 UUID 在许多情况下会破坏格式，例如，使代码块无法在文本中显示。UUID 本身不提供上下文提示，而设备名称则提供。如果您查看持久块设备命名#引导管理器中的三个示例，您真的觉得 UUID 的那个最容易理解吗？
我认为您肯定是对的，我们可能在某些文章中缺少指向Persistent_block_device_naming的交叉链接，而在这些文章中使用 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/[您的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)回复

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

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

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

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

schroot 重定向至 在 64 位系统中安装捆绑的 32 位系统。我认为我们应该继续保留一个页面，展示如何设置 schroot 的示例。在 schroot 中运行 Fedora、Ubuntu 等系统有时很有用。我认为这篇文章应该被修改（并重新命名），以使用 32 位 Arch 以外的其他系统作为示例。Bobpaul (讨论) 17:46, 2017年7月17日 (UTC)回复
看起来 在 64 位系统中安装捆绑的 32 位系统 已经被存档，但仍然有一些 传入链接。还有 在 64 位系统上构建 32 位软件包，但我不知道它是否过时了。Lonaowna (讨论) 14:34, 2017年12月14日 (UTC)回复
最后，由于没有 i686 依赖项的官方仓库可供构建，因此在 Archlinux 中不再有原生构建 32 位软件包的方法（唯一的办法是使用 Archlinux32 的仓库创建一个构建 chroot）。无论如何，这可能用途不大，因此，我已经存档了相关页面。quequotion (讨论) 14:53, 2019年6月5日 (UTC)回复

对于一些支持 x86_64 的硬件，存在 32 位 UEFI 限制。示例章节：统一可扩展固件接口#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) 网络应用程序使用专用用户，我扩展了关于 PostfixAdmin 的信息，并意识到关于 php-fpm 的信息分散在 nginx 和 apache 的文章中（可能还有其他一些 web server 页面中）。我认为，如果将此信息移动到专用页面，或者移动到 PHP 的子页面，则所有 web server 页面和 php 网络应用程序页面中的引用/链接将大大改进，因为它非常 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 Boxes。
--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 分支.

--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 用于“目录”，但该词条未使用句子首字母大写，并且查看其名称，过度依赖它可能不是一个好主意。
-- nl6720 (talk) 15:48, 2023年2月4日 (UTC)回复
也许问题是没有人提供翻译。我想说如果他们想添加翻译，那就添加一个 MediaWiki talk: 即可。无论如何，对于中文
en zh-hans zh-hant note
目录 目录 目錄
互动 参与 參與 “Interaction” 在中文中是一个相当正式的词（至少对于简体中文而言），翻译为“参与”。
贡献 贡献 貢獻
最近讨论 最近讨论 近期討論 从 "Recent Changes" 扩展而来，因此也需要一个带有内容 最近討論 的 /zh-hk。
请求 请求 請求
虽然，我不知道 MediaWiki 如何处理 Accept-Languages，但至少对于像我这样在 Special:Preferences 中设置界面语言的人来说，这将很有用。--Lakejason0 (talk) 04:59, 2023年2月5日 (UTC)回复
这有什么进展吗？ --Lakejason0 (talk) 08:50, 2023年2月22日 (UTC)回复

删除 Qt4 内容

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

更新到 Intel 域名的链接

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

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

— Lahwaacz (talk) 09:18, 2023年7月30日 (UTC)回复

Bug 迁移

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

Klausenbusk (talk) 20:42, 2023年11月25日 (UTC)回复

机器人请求

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

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

软件包链接到 wiki 链接

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

这没那么简单，因为像 git#Installation，List of applications 和可能许多其他地方的软件包链接不应该被替换。 -- Lahwaacz (talk) 19:35, 2018年8月11日 (UTC)回复

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

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

外部 wiki 可以使用与“英文标题（语言）”不同的标题，并且由于机器人不会说人类语言，因此它无法弄清楚哪些链接应该添加到哪些页面。 -- Lahwaacz (talk) 08:34, 2020年5月21日 (UTC)回复
可以通过外部 wiki 上的跨语言链接来判断吗？ -- Blackteahamburger (talk) 09:13, 2020年5月21日 (UTC)回复
可以，但是机器人必须连接到多个地方。它可能有效，但也可能最终比我们现在拥有的更混乱……当我没事可做的时候，我可能会尝试一下。 -- Lahwaacz (talk) 15:32, 2020年8月13日 (UTC)回复
是否可以检测链接的页面是否存在？我今天偶然发现了两个笔记本电脑页面，其中链接了日文翻译，但它不存在。 --Erus Iluvatar (talk) 13:55, 2022年10月20日 (UTC)回复

Template:Broken package link 的提示

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

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

Arch 的 git URL

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

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

GitHub 上的项目也将迁移到 gitlab.archlinux.org。 -- nl6720 (talk) 14:04, 2021年6月14日 (UTC)回复
我忘记了 git:// URL。已添加到列表中。 -- nl6720 (talk) 06:45, 2021年6月26日 (UTC)回复

失效的跨 wiki 链接

我们已经标记了外部链接，存储库和 AUR 中损坏的软件包：我们是否可以对跨 wiki 链接执行相同的操作？我最近看到一些手动修复的链接，尤其是在翻译中。 --Erus Iluvatar (talk) 19:41, 2022年3月2日 (UTC)回复

那是个好主意，我们只需要找到某人来委托实施…… — Lahwaacz (talk) 15:18, 2022年3月13日 (UTC)回复
取自“https://wiki.archlinux.org.cn/index.php?title=ArchWiki_talk:Requests&oldid=826081”