ArchWiki talk:Requests

From ArchWiki
(Redirected from ArchWiki:Reports)
Latest comment: 17 December 2023 by Ectospasm in topic Creation requests
Note: Questionable edits should be reported directly on the page itself via an appropriate article status template, or on the respective talk page.

Is the wiki missing documentation for a popular software package or coverage of an important topic? Or, is existing content in need of correction, updating, or expansion? Write your requests below and share your ideas...

Creation requests

Here, list requests for topics that you think should be covered on ArchWiki. If not obvious, explain why ArchWiki coverage is justified (rather than existing Wikipedia articles or other documentation). Furthermore, please consider researching and creating the initial article yourself (see Help:Editing for content creation help).

Left-Handed Adjustments for Desktop Environments

I was thinking it would be helpful for lefties if there were a list of configuration options for each desktop environment that facilitate left-handed use of mice and touchpads. I'm not sure if this is related enough to Arch to include in this wiki, but I haven't had a lot of luck finding information for my own DE (KDE) let alone for others. I will start writing down information, and if no one else thinks there should be a separate page for this, I'll just add the information I find to each individual DE's page. —ajrl 2013-08-11T15:09−06:00

I think a separate page is better. -- Fengchao (talk) 11:58, 12 August 2013 (UTC)Reply[reply]

iPXE

iPXE is a powerful network boot program with many features. Currently, there is no iPXE specific page to describe iPXE in details. There are some pages mentioning iPXE in the wiki, mostly related to network booting, without any further instruction on how to get iPXE to work. So I think it's worth to add a page with detailed iPXE explanation in the wiki. Alive4ever (talk) 10:08, 21 July 2016 (UTC)Reply[reply]

I have recently added ipxe to [community], which apart from the defaults also features the binaries required to allow iPXE booting towards the Arch Linux specific endpoint. It would be great to have a page for this and I will try to work on iPXE as soon as time permits. Davezerave (talk) 09:54, 17 June 2021 (UTC)Reply[reply]

Missing redirects

--Larivact (talk) 15:35, 21 October 2018 (UTC)Reply[reply]

I think I might create TOML, however I first will check how many pages attempting to link to this to see how wanted it is.
TOML has grown a lot over the years, so it would be a useful page to list the packages, such as libraries, which are toml compatible, and also give a brief explanation of what TOML is (by quoting their docs), and also linking to their docs.
Have a good day, PolarianDev (talk) 10:56, 11 May 2023 (UTC)Reply[reply]
This is the only page which links to TOML, might be a waste of time linking to it... especially how alal the other serialisation and configuration langauges (json, yaml etc) also do not have pages. PolarianDev (talk) 10:57, 11 May 2023 (UTC)Reply[reply]

Mirror troubleshooting

Unfortunately, Mirrors#Troubleshooting is a bit lacking and can definitely benefit from more information such as how to detect a bad mirror. A mirror becoming faulty is not extremely uncommon so this topic should definitely be covered, including who to tell about the bad mirror so it can e.g be removed from the mirrorlist.

This topic is impacting enough people that it is worth putting it into here.

-- NetSysFire (talk) 00:07, 6 August 2021 (UTC)Reply[reply]

The bad mirror case i covered now. Should another section, about a mirror returning 404, be added or information in is Pacman#Packages_cannot_be_retrieved_on_installation enough? --Mpan (talk) 08:19, 6 August 2021 (UTC)Reply[reply]
Thanks for contributing! The content you added looks good. Some information helping how to determine that a mirror is faulty is still missing. The section you mentioned is unfortunately not containing enough information on that and would be specific to the Mirrors article anyways. If any developer or other person knowing mirror internals sees this, please share your knowledge in debugging mirrors.
-- NetSysFire (talk) 17:19, 6 August 2021 (UTC)Reply[reply]

Random page - only with specific language ?

I like the "Random page", https://wiki.archlinux.org/title/Special:Random , but often it provides me the articles not in English, e.g. today fstab in Português which is above my pay-grade :-) Is it possible to call the random page url with an extra option and get e.g. only wiki articles in English ? Thanks. Ua4000 (talk) 09:34, 19 May 2023 (UTC)Reply[reply]

Looking at mw:Manual:Random page, it doesn't looks like it's possible since ArchWiki has all translations in the main namespace. -- nl6720 (talk) 09:40, 19 May 2023 (UTC)Reply[reply]

Observability

This article could start by quoting and linking to the Wikipedia article on the same topic. I also have an idea of adding a brief blurb to the General Recommendations page, or even to the list of applications (with a link to the main Observability article prominently at the top of the section).

As a budding cloud engineer, I've become more interested in observability in web applicationd/services, and in my own hobby projects. I've done some research into it, and I'm slightly familiar with a few different options. Most of what I found are open source, and I'd like to link to some options from within this Observability page, with possibly full-blown wiki articles describing various options. There are more turnkey, commercial offerings as well, and we could list some of those with links for more information. I actually went with one of those to start off with, mainly so I could learn which features were important to me, before I cobble together some of the more manual options.

When I was searching for ways to monitor my personal web projects, I stumbled upon an ad for New Relic, one of the many commercial services. What struck me as interesting, was that most of New Relic's tools are open source (under an Apache 2.0 license, written in Go). They offer 100GB of data upload per month for free, which has been plenty for observing my hobby projects on my VPS. I've already drafted (but not published) PKGBUILDs for some of the tools I've used, mostly from their pre-compiled debs. There are PKGBUILDs in the AUR (like newrelic-cliAUR and newrelic-infraAUR), but I didn't see a Wiki article describing how to use them. Unfortunately Arch Linux isn't currently supported by New Relic, and their method of bootstrapping New Relic using only the newrelic command (part of newrelic-cliAUR) didn't work for me so I've had to follow their dispersed manual instructions. I've run across a few issues so I've gotten onto their forums to seek help. They have community members who provide the first line of support, and for at least one of my issues they've actually created a New Relic support case for it.

I even learned about Pressure Stall Information, and wrote my own scripts to monitor and alert when CPU, I/O, or memory pressure gets too high. It's in a public Git repository, but I wanted shore up some of the documentation before I share a link to it anywhere.

Would an Arch Wiki article like this be worthwhile? I think it would be, but I didn't want to simply start writing it without having a discussion first. Ectospasm (talk) 18:00, 17 December 2023 (UTC)Reply[reply]


Installation Recipes

Thanks to the rolling release of Arch Linux, I've only actually installed Arch a handful of times. And the Wiki is wonderful in documenting the process. The first time I ever installed Arch, I didn't have another computer to access the wiki, and didn't think to use my phone. I just used separate virtual consoles on the desktop system I was using, and had the wiki loaded in a text mode browser (elinks or lynx, I don't remember which). I may have even enabled GPM so I could copy and paste with my mouse in the Linux console (this part I don't rightly remember).

However, each time I've installed Arch I've always wanted something specific, which generally meant searching, following, and backtracking through several Wiki articles to achieve my end. Now that I have a new laptop, and I'm planning on installing Arch on it very soon, I've drafted a "recipe" for myself to follow. I've been told that publishing such a "recipe" is against the spirit of the Wiki, but I'm finding it's a slog to go through all the articles to piece together how I want to do it, especially without planning ahead. I think many Archers might find such "recipes" useful, if only to get ideas for their own systems.

I think the format of these "recipes" would need to be debated, as I'm not sure what would be best. We definitely don't want to replicate or repeat sections within the wiki. Here's my proposed format, but I'm not settled that this is the best way to do it. First, start with hardware prerequisites for the recipe. A recipe for a file server or Network Attached Server (NAS) would be different from a laptop, or an x86_64 handheld or mobile device, as would a recipe for a virtual private server (VPS) or other virtual machine. The recipe could go on to describe the partition layout, filesystems, bootloader, network topology and corresponding network manager, etc. The reasoning behind each decision can be explained in whatever detail the author wants. It could then provide a link to a (pseudo-)script that executes it, possibly pausing where the user is intended to make a decision. I'm not familiar with the Archinstall, but if these work well perhaps they could be an optional component of the Archinstall script (this might be getting ahead of myself, though).

What would be the proper way to address this kind of documentation, and keep to the spirit of the wiki? Or is this really a bad idea? If it is a bad idea, why would it be so? I mean, such a section in the Wiki could have a disclaimer stating that it is a requirement for readers to understand the installation process, and not blindly follow what's listed. Of course, links back to the Wiki articles describing how to perform each task should be all over these "recipes," I don't think these are a substitute for understanding the installation guide. Maybe the wiki isn't the best place for this; the wiki could collect links to recipes by various users, and the recipes themselves could be hosted on the Arch Linux GitLab instance. Ectospasm (talk) 22:14, 17 December 2023 (UTC)Reply[reply]

Modification requests

Here, list requests for correction or other modification of existing articles. Only systemic modifications that affect multiple articles should be included here. If a specific page needs modification, use that page's discussion or talk page instead and one of the article status templates.

As a rolling release, Arch is constantly receiving updates and improvements. Because of this the Arch wiki must be updated quickly to reflect these changes.

Change drive naming/accessing to UUID?

Trying to install drives with/out Luks, LVM on internal, external drives is quite complicated currently. Following the ralated articles suggest different ways of reaching the goal. Many different drive name conventions are suggested, eg.:

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

Some of them don't work with portable external drives. This overcomplicates setting up encrypted drives in different situations. My suggestion is, to change all drive related articles to one specific solution of addressing drives universal. Currently I think of UUDI drive naming as a way to go. This would ease the process of drive naming in all kinds of situations:

  • The reader is guided through system setup along one red line
  • Troubleshootiing "no drie found" is strait forward
  • Many sections become clearer to read even when not reading the whole article
  • Articles are easier to write and maintain
  • Beginners have an easier read and geta better idea of how to access drives
  • Accessing internal/external encrypted drives is easy

' LMV or other virtual file systems are easier to describe and setup

Ok, I know it is a big suggestion. I wanted to bring it up here, bacause I have the impression that following one primary path would help a lot - everyone involved. It doesn't need to be done in one day. While I think to have one suggested guideline would be a good start. Then with thain mind, we all have it easier to change those sections while Writing/editing Wiki entries.

T.ask (talk) 11:22, 30 March 2015 (UTC)Reply[reply]

Hi, To your own examples above: using an UUID for a /dev/mapper/* device declaration is generally unnecessary (the uniqueness of the device is determined when it is mapped). I think you overestimate the amount of users who actually require setting up the examples where it really matters (e.g. external drives). What I don't understand is why you consider using UUIDs being easier to read/describe. For starters the terribly long UUIDs will break formatting in many cases, e.g. making code blocks in-text not possible. An UUID itself gives no contextual hint, something that a device name does. If you look at the three examples in Persistent block device naming#Boot managers, you really find the UUID one the easiest?
I think you are certainly right in that we may lack crosslinks to Persistent_block_device_naming in some articles where it may be important to use an UUID. Maybe we also need an example section to illustrate singular important points in Persistent block device naming and maybe there are individual articles/sections where content should indeed use a form of persistent naming straight away.
Suggestion: How about using Talk:Persistent block device naming to assemble a list of particular article sections with content where persistent naming should be made more prominent? That way we could also figure if and which examples may be useful to be added. --Indigo (talk) 17:47, 30 March 2015 (UTC)Reply[reply]
Hi, I started this topic because "by design" Linux has so many ways to assign drives and the Wiki uses them kind of "randomly". Finding the best drive naming method for the Wiki is my intention. Giving the reader a hand, by enabling him/her to understand one way of accessing drives and collect all the others somewhere.
I'm suggesting UUIDs, because they can be used for local and mobile situations. They are easy to use. The UUID format is universal and is independent of the location (local/mobile) or the context (LVM, Raid, Luks, ...) in which they are used.
The reason why I'm bring this up is, that it seems, the wiki has currently no standardized form of drive path declaration. If we can find one practical method, it will be easier to write, edit and maintain articles. Everyone involved will know then, which method is the recommended.
Therefore, I wanted to start an open conversation, to find ideas to improve the situation. I guess, UUIDs are also a good choice, because they are easy to substitute with pseudo code, eg.:
  • "mount /dev/disks/by-uuid/e9ea05ce-0ccb-87a1-c71e-90fab8be1944 /mnt"
could then be written as:
  • "/dev/disks/by-uuid/[UUID] /mnt"
instead of having the choice of:
  • "mount /dev/sda3 or
  • /dev/mapper/vgroup--lvm-root or
  • /dev/md/0 or
  • /dev/md0 or
  • ... /mnt"
The reader immediately knows:
  • "I just need to alter [UUID]"
There is no need to know of all possible alternative methods making use of the Wiki example. Because the user already learned (Beginners Guide) how to determine UUIDs those examples are well adoptable.
Reduced uncertainties like the reader had before:
  • Can I use that example's local path in my case, too?
  • What's my case anyway? And how is it different for the one provided?
  • Is my drive IDE, SATA or ... what?
  • Where and how is the correct format of my drive/partitions's path?
  • I need an example to boot my USB drive everywhere. That provided example doesn't work for me. Where is the article I need to know?
  • I skimmed through many articles, no success so far. There must be one, but where?
  • I have an Luks, Raid, LVM (or mixed) situation here. The current article just uses /dev/sdi3. What to do?
  • Which article do I need to read first? I can't use the current example. How about alternatives?
The reader's issue is, that "/dev/sdb3" drive paths aren't that descriptive without the knowledge of how and when they are used as written. They are nice for that particular situation, but may immediately loose their meaning in other use cases?!
If we could pick out one drive naming method the Wiki uses, then we are able to eliminate many of the upper soliloquies and ...
  • We get a good article structure for the writer, reader and maintainer.
  • The provided method will work in either situation (local/mobile/..).
  • All alternative methods can be listed in one conversion article/table.
The reader can quickly move on reading the article:
  • Great, I already know how to determine UUIDs. I just change it..
As you mentioned, crosslinks then point to one subpage, where the conversion to other alternative methods is explained.
Don't get me wrong, I don't want to imply something is wrong with the current way the Wiki does it. This just a natural process how something grows. A bit of standardization may help here.
I'm for UUIDs so far, because are easily exchangeable and can be written as [UUID] in the Wiki.
OMG, I wrote a huge wall of text. Sorry for that. It's not easy and very time consuming writing down what I wanted to say. as a non-native speaker. I hope, it's now easier to understand what my intention was. I'm kind of uncertain that I found the right words. --T.ask (talk) 13:24, 31 March 2015 (UTC)Reply[reply]
Thank you for elaborating on the background of why you propose it. No need to apologize at all for taking the time to give input how to improve our wiki! I just want to add two thoughts on it:
(1) One reason descriptive device declarations (/dev/sda/...) are easy to grasp is that everyone is used to them. It starts when you open any partitioning tool - you start it for a device from the /dev tree. Try to find the term "UUID" in the manpage of cfdisk/cgdisk/parted (fdisk has it, the others not a mention). With this I don't want to say your intention to introduce the user early to use persistent naming is wrong, just that using descriptive naming is common and, thereby, accessible to the reader.
(2) I like your idea of using a "/dev/disks/by-uuid/[YOURUUID] /mnt" format (we call other instances of such 'pseudo-variables'). Still, if you used it in an article context, e.g. an encrypted LVM, you would still have to more verbosely describe which dev/blockdevice/vg/lv UUID is meant to be mounted on /mnt. I still can't really picture for myself how writing and reading it is easier in general.
As I wrote above, I agree we might need to pinpoint the advantages of persistent naming more, but we do some already (e.g. right from the start: Beginners' guide#Generate an fstab). In short I believe we are better off with the way we have it (no rule on it, as long as the contribution fits the article contributed to all editors may choose what's best in context). That's it from me. Looking forward to read feedback & other opinions. --Indigo (talk) 20:46, 31 March 2015 (UTC)Reply[reply]
IMO man page examples are sometimes a bit behind "new standards". That's natural and this shouldn't prevent us from moving a bit more forward. With Arch we have UUIDs - lets use them :)
In case the user doesn't know UUIDs, we will guide him/her to a short conversion-table/article on how to switch to UUIDs. Actually it's much easier to grasp than often thought:
  • Just enter lsblk -f and it's obvious which UUID points to which drive in any context (raid, luks, lvm, ...). As this Get UUID example shows, just copy the corresponding UUID and use it with all UUID Wiki examples. IMHO it's quite easy.
I see where you are coming from, while I'm confident the reader will learn fast how UUIDs work. A new user will not even know which other options have been there before. Moreover, as the reader is already familiar with UUIDs he/she won't experience future problems with moving drives around. The experienced user just reads the conversion-table/article.
You see, I'm quite confident that the user will grasp UUIDs easily. Also, this will prevent him/her from experiencing future problems. We just need the courage to do the first step. It's not something we need to do in one day. We have all the time to slowly move into one direction.
That's why I would also appreciate other opinions on this topic here.
T.ask (talk) 12:45, 1 April 2015 (UTC)Reply[reply]
Hi, T.ask, thank you for discussing this, however I'm not sure if this is all only theoretical or you have a precise idea of how to put it into practice, because after reading all the discussion I haven't understood very well how this idea would change our articles. At this stage you must choose one of our important articles, e.g. LVM, and explain us how the article would change in details, so we can discuss on something more tangible. — Kynikos (talk) 14:37, 2 April 2015 (UTC)Reply[reply]
Hi, Kynikos. Yes, it's always better to have a good practical example if things seem to be complicated. I'm quite busy right now. When I find the time, I will start changing the Wiki (slowly) as I mentioned before. LVM is a nice example, while I would like to start with those sections which are easier to adapt and more commonly used. Especially if I need to add a new subsection (How do you work with UUIDs) beforehand. --T.ask (talk) 10:44, 21 April 2015 (UTC)Reply[reply]
As I said, it would be better if you showed us an example here or in your User page before starting to actually "chang[e] the Wiki". Take your time of course :) — Kynikos (talk) 02:30, 22 April 2015 (UTC)Reply[reply]

Drop of i686 support

Following [1] I've done these edits for the moment:

There are so many other articles that need updating, and also the edits above will need to be amended after November 2017. I think it's better to decide here whether we remove all the i686 content immediately, or we keep it until the final deprecation and do the cleanup then.

Kynikos (talk) 08:57, 26 January 2017 (UTC)Reply[reply]

Hi, I think for some of content it will depend on further decisions of the devs along the timeline, e.g. will there be changes to arch= options. We should wait a little to see how the migration plan looks like. IMHO it is useful to start updating once a topic is clear, i.e. before the deadline. Another moving target is whether a community effort to keep i686 somewhat establishes itself; any such would have an impact on what to change how.
In general I believe the related content changes will be so wide ranging that we should open a Archwiki:Requests/Drop of i686 support (or a top-level link like Archwiki:Drop of i686 support - easier to crosslink) to link to from here. Better to keep overview.
--Indigo (talk) 09:32, 27 January 2017 (UTC)Reply[reply]

I think it's good to keep Migrating between architectures around, it's also linked at least from the FAQ.

Kynikos (talk) 08:57, 26 January 2017 (UTC)Reply[reply]

About Makepkg#Build 32-bit packages on a 64-bit system and Install bundled 32-bit system in 64-bit system I'm not sure, perhaps they may be useful for somebody during the transition?

Kynikos (talk) 08:57, 26 January 2017 (UTC)Reply[reply]

schroot redirects to Install bundled 32-bit system in 64-bit system. I think we should continue to have a page showing an example of setting up an schroot. It's sometimes useful to run Fedora, Ubuntu, etc in schroot. I suppose the article should be altered (and re-titled) to use something other than 32-bit Arch as the example. Bobpaul (talk) 17:46, 17 July 2017 (UTC)Reply[reply]
Looks like Install bundled 32-bit system in 64-bit system has been archived, but there are still some incoming links. There is also Building 32-bit packages on a 64-bit system but I don't know how outdated that is. Lonaowna (talk) 14:34, 14 December 2017 (UTC)Reply[reply]
In the end, with no official repository of i686 dependencies to build against, there is no longer any method of building natively 32bit packages in Archlinux (the only way to do so would be to create a build chroot using Archlinux32's repository). There's probably very little use for this anyway and as such, I've archived the relevant pages. quequotion (talk) 14:53, 5 June 2019 (UTC)Reply[reply]

For some x86_64 capable hardware there are 32-bit UEFI restrictions. Example section: Unified Extensible Firmware Interface#UEFI Firmware bitness. It needs to be checked whether i386.efi bootloader files will continue to be built after i686 is dropped (FS#52772). Depending on result, it may be useful to rebase Category:Boot loaders content to x86_64 early on?

--Indigo (talk) 08:45, 30 January 2017 (UTC)Reply[reply]

Turns out my prior research was bad, 32-bit efi files are not packaged anyhow. Hence, users requiring those need to generate them, see FS#52772 for details. Still it is useful to weave this info in when references to i686 are eliminated in Category:Boot loaders articles. --Indigo (talk) 09:24, 2 February 2017 (UTC)Reply[reply]
I've done a little cleanup about this right now but there is probably some left. --Erus Iluvatar (talk) 19:12, 30 January 2022 (UTC)Reply[reply]

php-fpm

In preparation to making all (php) webapps use a dedicated user, I extended information on PostfixAdmin and realized, that the information on php-fpm is scattered all over the articles of nginx and apache (and probably all over some other web server pages as well). I think the citation/ linking in all of the web server pages and the php web application pages would greatly improve, if this information was moved to a dedicated page, or to a sub-page for PHP, as it is quite PHP specific (unlike e.g. uwsgi). Davezerave (talk) 00:55, 26 May 2019 (UTC)Reply[reply]

Templates & pages that need to be modified

I am modifying the template to deprecate Template:META Box Red, Template:META Box Blue and Template:META Box Green, but I cannot modify the Arabic template (probably because Arabic is arranged from right to left). These templates need to be modified:

Some Arabic pages also need to be modified, see Special:WhatLinksHere/Template:META_Box_Blue, Special:WhatLinksHere/Template:META_Box_Red and Special:WhatLinksHere/Template:META_Box_Green.

-- Blackteahamburger (talk) 16:53, 11 June 2020 (UTC) (EDIT: 11:20, 31 July 2020 (UTC))Reply[reply]

I've done Warning, Note and Tip, but yeah the rest gets trickier... -- Kynikos (talk) 11:40, 13 June 2020 (UTC)Reply[reply]
It seems that this can only be modified by Arabic users... -- Blackteahamburger (talk) 11:59, 13 June 2020 (UTC)Reply[reply]
See also [2]. -- Kynikos (talk) 04:05, 14 June 2020 (UTC)Reply[reply]
If Red, Blue and Green are deprecated, probably Template:META Box Yellow should follow, or be renamed to something more meaningful. -- Kynikos (talk) 04:22, 14 June 2020 (UTC)Reply[reply]
I think I've fixed Template:TranslationStatus (العربية), fixed the last content pages using Template:META Box Red, the last content page for Template:META Box Blue is Talk:Pacman so I've left it alone, fixed the last content pages using Template:META Box Green and Template:META Box Yellow looks good too ! --Erus Iluvatar (talk) 19:50, 30 January 2022 (UTC)Reply[reply]
I'm looking at the oldest pages flagged for archiving, which are these four META Boxes.
--Erus Iluvatar (talk) 19:22, 2 March 2022 (UTC)Reply[reply]

Update for new WirePlumber configuration format

WirePlumber's configuration format is changing. At a minimum, the paths of configuration files are changing, but there are likely actual content-related changes that need to be made. I wrote WirePlumber#Configuration file layout and WirePlumber#Modifying the configuration but I don't feel like handling these updates right now.

Affected articles (not comprehensive, feel free to modify):

Thanks, CodingKoopa (talk) 03:36, 28 October 2022 (UTC)Reply[reply]

php-legacy

PHP 8.2 update and introduction of legacy branch.

--Fengchao (talk) 01:23, 15 January 2023 (UTC)Reply[reply]

Information about older kernels/ program versions

Is there guidance on how long information about kernel and program versions should be kept ? e.g "btrfs supports this as of linux 5.0" or "fdisk supports GPT since...." It's mildly interesting when those are recent changes but a lot of occurrences on the wiki relate to versions which have been removed from repos for years... I think in most cases it adds unnecessary clutter, ideas ?

-- Cvlc (talk) 12:39, 23 January 2023 (UTC)Reply[reply]

There is an old stalled discussion at Help talk:Style#"as of version X.XX..." on this subject. --Erus Iluvatar (talk) 13:30, 23 January 2023 (UTC)Reply[reply]

Localize the sidebar texts

I don't know if I should post it under here, but here it is.

Since many of the languages' ArchWiki just directly sit on English ArchWiki, having sidebar being half-translated would be a bit weird.

so, on MediaWiki:Sidebar, each second level item represents a link (texts on the left of | is the destination and on the right of it is the "name". I'll call these "name"s as "message"s below, you'll know the reason), and some of the first level item represents a title. When displaying the sidebar, MediaWiki will try to retrieve the name from the MediaWiki: namespace (every page in that namespace is called a system message). For example in current MediaWiki:Sidebar:

MediaWiki:Sidebar
...
* Interaction
** :Category:Help|help
** {{ns:Project}}:Contributing|Contributing
...

Take Interaction as example. MediaWiki will first read the message MediaWiki:Interaction/user's display language (let's say Simplified Chinese, then it's MediaWiki:Interaction/zh-hans and assuming its content is 互动). If the page is there, the page's content 互动 will substitute "Interaction". If there isn't, then the root page, if still isn't, then leave it as-is. The whole mechanism may differ since the actual mechanism goes through a long list of language fallback (still take zh-hans, it may go through /zh-hans, /zh-hant, /en, root).

So, to localize the sidebar, we will going to create some MediaWiki: pages, or system messages, and their subpages with sub-title the corresponding interlanguage link prefix. Some of the messages are already translated by MediaWiki core, and I'll list those that aren't present now. I'd suggest renaming these pages as well to have kebab-case though, and then change them correspondingly in MediaWiki:Sidebar.

MediaWiki:Table of contents
MediaWiki:Interaction
MediaWiki:Contributing
MediaWiki:Recent talks
MediaWiki:Requests

(MediaWiki:Statistics is present due to Special:Statistics.)

Thanks! --Lakejason0 (talk) 13:52, 4 February 2023 (UTC)Reply[reply]

Sounds doable.
There's MediaWiki:vector-toc-menu-tooltip for "Table of Contents", but that one doesn't use sentence case and looking at its name, it may not be the best idea to rely on it too much.
-- nl6720 (talk) 15:48, 4 February 2023 (UTC)Reply[reply]
maybe the problem is that there isn't people providing translation. I'd say if they would like to add translations then just add a MediaWiki talk: though. Anyway, for both Chinese:
en zh-hans zh-hant note
Table of contents 目录 目錄
Interaction 参与 參與 “Interaction” is a rather formal word in Chinese (at least for simp.), translated as "Getting involved".
Contributing 贡献 貢獻
Recent talks 最近讨论 近期討論 extended from "Recent Changes", thus also need a /zh-hk with content 最近討論.
Requests 请求 請求
though, idk how MediaWiki handles Accept-Languages, but at least it would be useful for people (like me) who set interface language in Special:Preferences.--Lakejason0 (talk) 04:59, 5 February 2023 (UTC)Reply[reply]
Any progress on this? --Lakejason0 (talk) 08:50, 22 February 2023 (UTC)Reply[reply]

Drop Qt4 content

The Qt4 major version of the Qt GUI toolkit has not been supported by the Qt Company since 2015. It also has not been a part of the Arch repos (only in the AUR) since 2019-05. I believe that documenting software in the AUR (!= providing official support for AUR packages) is within the scope of ArchWiki; I can only think of dwm right now, but I am sure that there are more. However, maintaining old Qt content means keeping it in the Qt page and related pages (!). As adoption of Qt6 ramps up, I think we should consider removing Qt4 content from the main wiki. I have not searched for the occurrences yet, but I at least volunteer to aggregate them somewhere for User:CodingKoopa/Removed content. -- CodingKoopa (talk) 16:12, 25 June 2023 (UTC)Reply[reply]

Update links to Intel domains

Intel has changed their domains and all the following links lead to some general landing page:

Actually all Intel links should be checked by a human, because the script used by the bot gets status 404 for most Intel links, even those that work fine...

Lahwaacz (talk) 09:18, 30 July 2023 (UTC)Reply[reply]

Bug migration

As announced on the Mailing list all bugs have been migrated to GitLab, and GitLab is the new bug tracker. The pages refereeing to bugs.archlinux.org (e.g. Bug reporting guidelines) must be updated to point to our GitLab.

Klausenbusk (talk) 20:42, 25 November 2023 (UTC)Reply[reply]

Bot requests

Here, list requests for repetitive, systemic modifications to a series of existing articles to be performed by a wiki bot.

Package links to wiki links

It'd be nice if a bot went around changing links to packages that have a wiki entry to links to the wiki entry (e.g. change git to git), possibly also for aur packages (e.g. dropboxAUR to dropbox). Jabranham (talk) 19:42, 31 July 2018 (UTC)Reply[reply]

It's not that simple because package links like in git#Installation, List of applications and probably many other places should not be replaced. -- Lahwaacz (talk) 19:35, 11 August 2018 (UTC)Reply[reply]

Automatically add/update language links for languages hosted by external wikis

Some languages are hosted on external wikis, and I want the bot to automatically add / update language links for languages hosted on external wikis so that users do not need to add them manually. -- Blackteahamburger (talk) 15:27, 20 May 2020 (UTC)Reply[reply]

External wikis can use different titles than "English title (Language)" and since the bot does not speak human languages, it can't figure out which links should be added on which pages. -- Lahwaacz (talk) 08:34, 21 May 2020 (UTC)Reply[reply]
Can it be judged by interlanguage links on external wikis? -- Blackteahamburger (talk) 09:13, 21 May 2020 (UTC)Reply[reply]
It could, but the bot would have to connect to more than one place. It might work, but it might end up even more messy than what we have now... I might try this when I have nothing better to do. -- Lahwaacz (talk) 15:32, 13 August 2020 (UTC)Reply[reply]
Would it be possible to detect if a linked page exists or not? I've stumbled upon two laptop pages today where a japanese translation was linked but it did not exist. --Erus Iluvatar (talk) 13:55, 20 October 2022 (UTC)Reply[reply]

Hints for Template:Broken package link

Can the hints for Template:Broken package link marked on the localization page use the localized version? This allows users who do not understand English to understand the status of the software package. -- Blackteahamburger (talk) 11:34, 26 May 2020 (UTC)Reply[reply]

If you manually translate the hint, the bot will overwrite it to English later. Translations would have to be added to wiki-scripts, I'm not sure how to best do it. -- Lahwaacz (talk) 11:38, 26 May 2020 (UTC)Reply[reply]
I think you can add the translations to the wiki-scripts, I think it's good. -- Blackteahamburger (talk) 11:53, 26 May 2020 (UTC)Reply[reply]

Arch's git URLs

Sooner or later git.archlinux.org will cease to exist. It's not clear when (or if) there will be redirects and after a project has moved to gitlab.archlinux.org, the repo in git.archlinux.org might not get updated anymore. Lets prepare to update the links in the wiki pages.

-- nl6720 (talk) 08:47, 22 July 2020 (UTC)Reply[reply]

Projects on GitHub will move to gitlab.archlinux.org too. -- nl6720 (talk) 14:04, 14 June 2021 (UTC)Reply[reply]
I forgot about git:// URLs. Added to the list. -- nl6720 (talk) 06:45, 26 June 2021 (UTC)Reply[reply]

Dead interwiki links

We already flag external links, broken packages in the repositories and AUR: could we do the same for interwiki links? I've seen a few of those manually fixed recently, in particular on translations. --Erus Iluvatar (talk) 19:41, 2 March 2022 (UTC)Reply[reply]

That's a good idea, we just need to find someone to delegate the implementation to... — Lahwaacz (talk) 15:18, 13 March 2022 (UTC)Reply[reply]