Difference between revisions of "ArchWiki:Requests"

From ArchWiki
Jump to navigation Jump to search
(Cleanup: installation category: Remove closed section.)
(General requests: link to new status templates and respective categories, see ArchWiki:Requests#Should we remove or archive obsolete articles?)
Line 8: Line 8:
; [[:Category:Pages or sections flagged with Template:Accuracy|Inaccurate content]]: Pages flagged with [[Template:Accuracy]].
; [[:Category:Pages or sections flagged with Template:Accuracy|Inaccurate content]]: Pages flagged with [[Template:Accuracy]].
; [[:Category:Pages or sections flagged with Template:Out of date|Outdated content]]: Pages flagged with [[Template:Out of date]].
; [[:Category:Pages or sections flagged with Template:Out of date|Outdated content]]: Pages flagged with [[Template:Out of date]].
; [[:Category:Pages or sections flagged with Template:Deletion|Irrelevant or unhelpful content]]: Pages flagged with [[Template:Deletion]].
; [[:Category:Pages or sections flagged with Template:Archive|Obsolete pages]]: Pages flagged with [[Template:Archive]].
; [[:Category:Pages or sections flagged with Template:Remove|Irrelevant or unhelpful content]]: Pages flagged with [[Template:Remove]].
; [[:Category:Pages or sections flagged with Template:Expansion|Incomplete content]]: Pages flagged with [[Template:Expansion]].
; [[:Category:Pages or sections flagged with Template:Expansion|Incomplete content]]: Pages flagged with [[Template:Expansion]].
; [[:Category:Pages or sections flagged with Template:Style|Content with language or style issues]]: Pages flagged with [[Template:Style]].
; [[:Category:Pages or sections flagged with Template:Style|Content with language or style issues]]: Pages flagged with [[Template:Style]].

Revision as of 09:41, 7 February 2016

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...

See ArchWiki:Reports to report questionable contributions. Please sign your edits and feel free to comment on others' requests.

General requests

Inaccurate content
Pages flagged with Template:Accuracy.
Outdated content
Pages flagged with Template:Out of date.
Obsolete pages
Pages flagged with Template:Archive.
Irrelevant or unhelpful content
Pages flagged with Template:Remove.
Incomplete content
Pages flagged with Template:Expansion.
Content with language or style issues
Pages flagged with Template:Style.
Non-standard laptop pages
Pages flagged with Template:Laptop style.
Duplicate effort or overlapping scope
Pages flagged with Template:Merge.
Misleading names
Pages flagged with Template:Move.
Poor translations
Pages flagged with Template:Bad translation.
Incomplete translations
Pages flagged with Template:Translateme. See also ArchWiki Translation Team.
Incomplete content
Pages flagged with Template:Stub.
Deprecated titles
Pages flagged with Template:Redirect.
Dead or broken links
Pages flagged with Template:Dead link. Should be repaired or replaced.
Templates with an undefined parameter
Pages automatically flagged with Template:META Error
Unexplained presence of an article status template
Pages automatically flagged with Template:META Unexplained Status Template.
Application listed without links to packages
Pages automatically flagged with Template:META Missing package.
Misspelled or deprecated templates
Need to fix template or change to new template.
Noindexed pages
Automatic tracking category.
Duplicate arguments in template calls
Automatic tracking category.

Also note that Special:WantedCategories can show additional automatic tracking categories.

Problem redirects

Note: Redirects should not point to other sites and ones that do sometimes erroneously show up on these pages.

Broken package links

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Add documentation for all the hints: meaning + recommended action (Discuss in ArchWiki:Requests#Strategy for updating package templates)

ArchWiki contains many broken links to packages not found either in official repositories or AUR, which is the result of packages being merged, split or removed from the repositories. All pages in the main namespace are regularly checked by a bot, which checks all instances of AUR, Grp and Pkg templates, tries to automatically update them and marks them with Template:Broken package link when it is not possible to update them automatically.

To fix a broken package link, do not simply remove the reference to the packages from the wiki, do some research first:

  • Search the package database (pacman -Ss) and AUR, it is possible that the package was merged/renamed.
  • If looking for a specific file, for example a binary that was part of the package, pkgfile might do the trick.
  • If unsure, mark the page or section with an appropriate status template rather than completely removing the reference to the package.
  • For AUR3 package links marked with Template:Aur-mirror, you may consider resubmitting them to the AUR if interested in maintaining them.

All pages with broken package links are tracked in Category:Pages with broken package links.

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).


How to configure SAMBA PDC + LDAP in Arch Linux? (Moved from another page. Hokstein 19:57, 16 September 2007 (EDT))

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)

Input methods

Currently there is no page on ArchWiki properly describing various input methods generally. There is only Internationalization#Input_methods_in_Xorg, but it has several problems:

  • missing descriptions
  • X compose key does not fit in
  • GTK has a default "simple" input method featuring the Ctrl+Shift+u shortcut for entering a unicode character (this was added recently into a wrong article: [1]) - again, no description
  • no description of XIM - outdated, but sometimes used as fallback?

So this is quite enough material to start a new great article ;)

-- Lahwaacz (talk) 18:23, 18 December 2013 (UTC)

Update to note: While Internationalization#Input_methods_in_Xorg itself still remains a stub, we had editors contributing language specific instructions which were set as subpages of the article:
Internationalization/Japanese and Internationalization/Korean
--Indigo (talk) 21:57, 11 January 2015 (UTC)


An article, or even stub that links to resources, explaining what DRI is, why it's important, differences between DRI 1, 2, 3, how DRI1 is no longer supported as of xorg-server 1.13, simple xorg.conf code explaining the DRI section, enabling the composite and render extensions there, these and more. Just my thoughts.


ldns is a core package with no wiki documentation. It is also relatively new in the world of DNS tools and is not well covered on the Internet. Documentation of basic features and what it is not (eg a replacement for bind) would provide a valueable resource. MichaelRpdx (talk) 20:07, 17 February 2014 (UTC)

The description of the ldns package is "Fast DNS library supporting recent RFCs". The official homepage mentions that several example programs are included with the library, the official docs is probably best for programmers. -- Lahwaacz (talk) 21:37, 17 February 2014 (UTC)


Surprisingly, there is no wiki page describing the installation and configuration of Perl, unlike Python, Ruby etc. Could include the installation of CPAN modules and a list of good tutorials for beginners, too. So far there is only guides for packaging Perl and its modules (Perl Policy and Perl package guidelines respectively) -- bluestreak0 01:32, 17 April 2014 (UTC)

Linux console

I was thinking that a new page for the console would be a good idea. The Wikipedia:Linux console article gives a short general overview, but obviously doesn't concern the configuration. Since it's an independent system, configured separately from any graphical environment, it would bring together several related sections across multiple articles in one place. It's a fairly complex system and difficult to cover in any depth in small sections across other articles (such as Fonts). I've put together a basic example, User:Teppic74/Linux_console. -- Teppic74 (talk) 17:11, 3 July 2014 (UTC)

Sounds interesting, but I don't know how deep you want to go in the description, it may be too much for a single page as, according to your outline, the resulting article would cover all Fonts#Console fonts, Keyboard configuration in console, part of Extra keyboard keys, Map scancodes to keycodes and Extra keyboard keys in console. The keyboard configuration is split mainly because the configuration for Xorg is connected to it, I don't know how this would be done if the low-level description is moved. On the other hand, some of these articles could use some reorganization, so it may still be possible... -- Lahwaacz (talk) 13:17, 4 July 2014 (UTC)
I feel this is part of the problem, that the details concerning the console are tacked on to other articles rather than being naturally associated with them. As things stand, I think the documentation is lacking. I don't think a huge amount of information is needed, it would just be helpful to be in one place, as the console is mostly isolated from the rest of the system. The other articles could link to the console article for further details. Another possibility is separate articles exclusively for the console display and keyboard, but they're obviously part of the same topic. -- Teppic74 (talk) 18:48, 4 July 2014 (UTC)


I think creating a page and mentioning ways to improve sublime-text integration with Gnome would be a good idea. The trick is if you run sublime with --class=<filename of sublime text .desktop file, e.g. sublime_text_3>, it would help Gnome and XFCE to group sublime instances with its respective desktop file. This is mentioned in the comments of the aur package but I think it's better that this would be in the wiki.--183.amir (talk) 12:41, 19 December 2014 (UTC)

Forum link

Moved from Talk:Bash/Functions -- Alad (talk) 11:13, 23 October 2015 (UTC)

The article has two types of forum links:

Which one is right again? --Dettalk 11:44, 24 July 2015 (UTC)

Full URLs should be avoided, see Help:Style#Hypertext_metaphor, otherwise I know of no recommended wording for forum links. -- Alad (talk) 12:13, 24 July 2015 (UTC)
That section doesn't actually even talk about external links, while Help:Editing#External links says "just type the full URL", but also that "it is often more useful to make the link display something other than the URL". --Dettalk 16:04, 24 July 2015 (UTC)
This was already mentioned somewhere some time ago, I don't remember where nor when, anyway [2] would seem to justify the creation of a Template:BBS, just like we have Template:Bug. — Kynikos (talk) 15:18, 25 July 2015 (UTC)
The problem with a BBS template is that links to the full thread have simple query string ?id=number, whereas links to posts have ?pid=number#number. There would have to be two different templates, which would get confusing very quickly.
There are more problems with existing links to the BBS: from looking at the list you posted, there are many links specifying the page number in the query string (p=num), but FluxBB has variable/configurable number of posts per page. The links should point to either the full thread (first page), or a specific post.
-- Lahwaacz (talk) 15:31, 25 July 2015 (UTC)
Like with links to bugs, a bbs url has to be pasted and manually modified anyway, but most of the times the conversion to Template:Bug ends up being done by a bot, which would be able to use two different BBS templates appropriately.
I see 5 types of viewtopic.php links:
  1. ?id=number: these could be changed to Template:BBSid instances.
  2. ?id=number&p=number: when number is 1, they could drop it and use Template:BBSid; otherwise they should point to a post as you say and use a Template:BBSpid template (we could publish a list of such links for manual fixing, since the correct post has to be found by a human, a bot can't do it).
  3. ?pid=number: these could be changed to Template:BBSpid instances, the link fragment is the same as number with a prefixed p, so it's easy to add using the same template argument.
  4. ?pid=number#pnumber: these could be changed to Template:BBSpid instances, number needs to be specified only once.
  5. ?t=number: these seem to be all broken, so they should be marked as dead, or fixed.
I've chosen Template:BBSid and Template:BBSpid instead of e.g. Template:BBSthread and Template:BBSpost thinking that it would be easier to get their relation to the url when used manually, but I'm still quite undecided (provided that we actually decide to introduce the new templates).
Kynikos (talk) 04:27, 26 July 2015 (UTC)
3. and 4. are identical (btw. haven't you confused their descriptions a little?), except that 3. only opens the page with the given post (based on the user's posts-per-page setting), but stays at the top of the page, whereas 4. points directly to the post (the #pnumber is the trick to do it). So 3. should also never be used, but it's trivial to transform it to 4. -- Lahwaacz (talk) 09:50, 26 July 2015 (UTC)
Of course, I was reasoning from a bot's point of view, which would indeed see 3. and 4. as different cases. My description of 3. was assuming that the need for a fragment was obvious (hence the mention of how easy it is to add it even if it's not in the original link), but what's important is that you seem to have understood anyhow :P — Kynikos (talk) 10:44, 26 July 2015 (UTC)
I agree on using only PID and ID. If you're linking to a page, you most likely should link to a PID. To distinguish between both, you could use ## for PID and # for ID.
I don't have suggestions on automating the implementation. -- Alad (talk) 11:18, 23 October 2015 (UTC)

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 #General requests 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.

Automatic loading of kernel modules

There are notes like "Since kernel 3.4 all necessary modules are loaded automatically" and "Newer versions of udev load the module automatically", which are usually followed by rather long section "If that does not work, do modprobe foo" and "To make it permanent after reboot, add the following to /etc/modules-load.d/module.conf".

Examples: Kernel_modules#Configuration, CPU frequency scaling, CPU frequency scaling#CPU_frequency_driver, Network configuration#Check_the_driver_status, Wireless_Setup#Device_driver.

There are several problems with this, so quick list of tasks:

-- Lahwaacz (talk) 19:09, 5 August 2013 (UTC)

As the minimum supported kernel version is apparently 3.10 at the moment, we should get rid of those modprobe commands and just link to Kernel_modules#Configuration. -- Lahwaacz (talk) 21:02, 29 November 2013 (UTC)
When cleaning modprobe usage, I found many # modprobe fuse instance. Any one familiar with fuse could confirm if it is still needed? -- Fengchao (talk) 11:59, 24 January 2016 (UTC)

Links to Gentoo wiki

http://en.gentoo-wiki.com/ is offline for some quite time now, the new address is http://wiki.gentoo.org/. There are several links that need to be updated: [3]. I don't really know what (and when) happened there, I just suppose that there has been some major restructuring of the Gentoo documentation - there is not direct 1:1 mapping of the old links to the new address, so it will have to be done manually. -- Lahwaacz (talk) 14:06, 22 February 2014 (UTC)

Actually, there is Gentoo Wiki Archives, but is it safe to link there considering that it is read-only? -- Lahwaacz (talk) 22:27, 6 March 2014 (UTC)
http://wiki.gentoo.org/ is of course preferable, however if there's really no alternative and the article in the Archives is still relevant, the fact that it's no longer editable shouldn't prevent from linking there. -- Kynikos (talk) 01:43, 8 March 2014 (UTC)

Should we remove or archive obsolete articles?

Ubuntu One is one I stumbled upon. I think it can be safely deleted. -- Karol (talk) 19:22, 30 July 2014 (UTC)

Could you explain in more details what you mean by archiving and deleting? I am all against completely removing information from public viewing however.
axper (talk) 15:44, 31 July 2014 (UTC)
Deleting means we remove the article and archiving means we e.g. lock the page or just add a note / warning at the top, saying that it's obsolete, not used anymore. Initscripts/rc.conf would be another such page. -- Karol (talk) 21:45, 31 July 2014 (UTC)
Well, Ubuntu One is discontinued and the related AUR packages are deleted, I would really delete it, @axper do you have any particular objections?
About Initscripts/rc.conf, there has been some work done in init, and its content may be re-used for the initscripts fork?
-- Kynikos (talk) 06:41, 2 August 2014 (UTC)
About deleting articles from wiki in general: Any article is documentation and deleting it wrong in my opinion. For example someone might want to design a similar program in the future find the information useful. Or some historian/statistican interested for example why the particular program failed to gain traction. Or Wikipedia or a similar resource might might use our articles for citations. Or the program might still be used by stable/old distros. Or finally, the project might be revived in the future!
I vote for archiving:
  1. Add a corresponding notice at the top of the article
  2. Remove the article from category pages
  3. Remove all links to that article from this wiki
Or if Mediawiki has any support for archiving - move such articles to separate namespace/whatever (needs more research).
axper (talk) 16:32, 2 August 2014 (UTC)
With MediaWiki, nothing is ever really deleted; deleted pages are just hidden from regular users. IMHO, deleting instead of archiving results in much cleaner wiki in general (mostly categories and search results). Also, unlike deletion, there is no "Archive" button, so every archival solution is very laborious. -- Lahwaacz (talk) 16:55, 2 August 2014 (UTC)
hidden from regular users has mostly same effects as deleted, because it's accessible only by half a dozen chosen individuals. See the reasoning in my post above.
About cleaner wiki:
  1. Categories: Just remove the page from category
  2. Search results:
    • Mediawiki search results: By default only (Main) namespace is searched. So a separate namespace would solve this.
    • Google/other search engines: Nothing can really be done (or should be done). If someone searches for "ubuntu one" and finds our archvied page, it's very normal behaviour!
I don't think moving to separate namsepace is a lot more laborious than pressing "delete" button.
Solutions other than separate namespace should be considered as well I think.
axper (talk) 17:52, 2 August 2014 (UTC)
Any archive would have to be organized in order to be useful. I don't think we have the manpower to do this even if archiving required just clicking a button. Also, I don't think that ArchWiki is intended to be a (partial) archive of any kind.
Regardless, dead projects are quickly forked if they were really useful and died just because of the maintainer's lack of time, or they are lost forever regardless of the archived documentation. I don't see why we should keep a page about projects dead for ~5 years, the more when upstream has its own documentation archived.
-- Lahwaacz (talk) 18:12, 2 August 2014 (UTC)
I counted only 25 (twenty-five) English articles in (Main) namespace marked for deletion as a whole [4]. I don't see how keeping them together unorganized would make them less useful. Anyone interested in them would specifically search for the name in a search engine.
Why keep pages about dead projects - see my first post above. Besides, this wiki often contains higher quality and quantity documentation than upstream's.
Now, pages which do not contain any meaningful text whatsoever (like Beginners_Guide_to_C++), it's a different matter.
axper (talk) 05:13, 3 August 2014 (UTC)
From Special:Log/delete, we deleted about 300 pages in past 4 months.
Dig through the out of date pages for usefully information is usually harder than starting from scratch because you need to know what is out of dated and what is not.
So in theory, you can re-use these pages. In practic they just pollute "What links here" system. I say this with my KDE wiki contributor hat on which does use Archive namespace for out of date pages.
--Fengchao (talk) 13:29, 9 August 2014 (UTC)
Instead of manually looking for content worth digging out I was/am suggesting to make available/archive everything. Unless, of course, it is spam or nonsense.
It is possible to filter out namespaces in "What links here" pages.
axper (talk) 14:06, 9 August 2014 (UTC)
As I explained below, simple archiving is an inconsistent solution, because when part of an article is removed for some reason (out of date, inaccurate...) it's not archived (though it remains accessible in the history of the article), so there's no reason entire articles should be treated differently. The only solutions that can be considered are those that allow everybody visit the history of "deleted" articles. -- Kynikos (talk) 08:26, 10 August 2014 (UTC)
Ok, I admit I don't have (and probably there can't logically be) any counterarguments against the generic "it might be useful again in the future" argument, and I guess the whole point here is that the deleted content is no longer accessible to regular users, not even in the history of a page, because it seems noone has anything against e.g. removing outdated portions of articles, or removing closed discussions. This means that both deleting and archiving don't comply with the requirements, do we agree on this?
The only solution consistent with all this seems the redirection idea proposed below, but in that case the content of those articles wouldn't appear anymore in any kind of search results, so a user interested in retrieving their content should be aware of the existence of both Deprecated pages and of the old page that redirects there. This would however still sort of answer the problem of possibly breaking external links, as following one would lead to Deprecated pages, which in turn could inform the user on what happened to the article (s)he was looking for.
Considering all this, maybe, and I say maybe, a new policy to address deletions could be to:
  1. Assess if it's possible to redirect the article to another one, as we're already doing.
  2. If not, assess if the history of the page is meaningful enough to justify redirecting the article to Deprecated pages instead.
  3. If not, really delete the article.
The only new step would be 2., which is not so different from 1., so it could even start making sense. This is a very intricate issue, let's see what the comments to this post will be.
-- Kynikos (talk) 11:02, 4 August 2014 (UTC)
What are the security implications of making Special:Undelete available to everyone? See also mw:Help:Undelete. -- Lahwaacz (talk) 11:20, 4 August 2014 (UTC)
That would indeed be a kiss way of solving the problem. I haven't found any discussions about that, and the only bad implication I can think of is if somebody creates a defamatory article and we delete it, we wouldn't be able to prevent anyone from linking to the deleted revision(s) anyway, thus exposing the wiki to possible legal consequences. However, the same attack could be carried out on an already existing useful article, and the same fix could be used in both cases, i.e. using the "change visibility" feature.
Maybe we could ask upstream about other possible consequences.
-- Kynikos (talk) 16:45, 5 August 2014 (UTC)
That is an even better option. axper (talk) 15:21, 8 August 2014 (UTC)
I have sent a mail to the MediaWiki mailing list, let's wait for response... -- Lahwaacz (talk) 09:06, 18 August 2014 (UTC)
Well done, I've subscribed and will step in if necessary. -- Kynikos (talk) 01:46, 20 August 2014 (UTC)
Adding Template:Deletion at the top of a page is a reasonable note/warning in these cases, then the admins can go through Special:WhatLinksHere/Template:Deletion and consider each page. Or is this a general discussion about deletion and archival on this wiki, possibly intended to devise a proper archival solution (e.g. separate namespace)? -- Lahwaacz (talk) 14:59, 2 August 2014 (UTC)
How about making a separate page, Deprecated pages? Any deprecated articles would be blanked, references to them removed, and then redirected to that page. They're "deleted", yet easily accessible via "What links here" should the need arise. -- Alad (talk) 19:28, 2 August 2014 (UTC)
Seems reasonable to me. axper (talk) 05:19, 3 August 2014 (UTC)
Why not just visit Special:Log/delete. Any difference here?--Fengchao (talk) 13:32, 9 August 2014 (UTC)
Well, Special:Log/delete contains (references to) all deleted pages. As Kynikos mentioned, a page like Deprecated pages would only contain articles with notable content in the past, but that is now no longer relevant. -- Alad (talk) 09:07, 10 August 2014 (UTC)
Exactly. The logs are overdose for the intention. I do like the consideration of having a Deprecated pages for singular cases when the admins evaluate a deletion template as well, if that keeps search history neat & up-to-date. I have a limited view on the topic, but it sounds to me that a separate archiving-namespace would be overkill for this.
Imho Karol started this discussion with the best examples for both cases: Ubuntu One wiki information will surely float around the web for very long, there is nothing an Arch wiki article about using it with this distro can add after it was shut down. The Initscripts/rc.conf, however, is Arch's own history. Another one like that: I tried to update the non-resolving package links for Pacbuild to no avail. Probably the fellow who created it (and the article) back in 2006 would not mind it being deleted now. Yet, the wiki might want to care about the Arch legacy to that extend anyhow. A buffer like the idea of Deprecated pages could help out there. It could have simple sections (e.g. separating Arch-specific content and other content considered notable in different categories, etc.). I also could imagine cases where it makes the decision easier for the admins - some content could be deprecated first and deleted after a safeguarding time. --Indigo (talk) 20:20, 11 August 2014 (UTC)
Well, the new "article" would only be used as a redirect target in place of deletions with something like #REDIRECT [[ArchWiki:Deleted]]. Then in it we would instruct users to look at the WhatLinksHere page to see which articles are linked and browse their history. We can't implement anything more complicated than that, i.e. there would be no content to be separated into sections. -- Kynikos (talk) 14:12, 12 August 2014 (UTC)
Ah, thanks for clarifying. Picking up another thought from above not clear to me: Given we cannot distinguish the #REDIRECT [[ArchWiki:Deleted]] from the extensively employed regular redirects to guide to most relevant current content. Might it happen that, e.g. after pursuing that route for a year or two, those redirects start to spoil/pollute search results for the regular user seeking only current content? Or is that not a problem (e.g. due to amount of pages we anticipate to deprecate like that or maybe we can control somewhere that they are only listed at the bottom of search results)? Or is the extra effort small enough to justify testing it out and change route in case it does become a problem (and we might profit from the deprecate-delete decisions already been taken)? --Indigo (talk) 21:39, 12 August 2014 (UTC)
This discussion may be related ... -- Alad (talk) 21:44, 12 August 2014 (UTC)
Well, the content of those "semi-deleted" articles wouldn't be parsed by the search engine, so only their titles could constitute a problem in search results. Now, it's unlikely that titles like "Ubuntu One" could pollute the search results for other still-alive terms, and in case some of them did, that would probably mean that instead of "semi-deleting" them, we should have redirected them to some other related article (see step 1. in the checklist in one of my posts above).
Anyway if this became a problem in the future, all the semi-deleted articles could be quickly and easily finished off with a bot.
-- Kynikos (talk) 01:58, 13 August 2014 (UTC)
@Alad: Yes, it is - ensuring quality of the regular redirects is not spoiled longterm.
@Kynikos: Ok, I take from that the extra redirect can be a worthwhile exercise to try and see. Something that cannot be done with the fourth option without more certainty about consequences.
Re "finished off with a bot": and the tagging as "semi-deleted" could also be useful to recycle the bunch another way (e.g. if route is changed to something else than "delete" for whatever reason).
Now for the fourth identified option to publicize Special:Undelete I wonder about search accuracy as well: would turning it on spoil internal search results? (no) How about external search engines? Any chance those get confused and suddenly index deleted content that they don't crawl now? --Indigo (talk) 20:29, 13 August 2014 (UTC)
You've answered the first question: no.
Second question: to view the content of a deleted revision, a POST request is needed, and that's something that search bots don't do, at least the normal ones. But even if that wasn't the case, history pages, old (not top-level) revisions and deleted revisions (and many other kinds of pages) all have <meta name="robots" content="noindex,nofollow" /> in the head, which allows me to confidently answer "no" as well.
-- Kynikos (talk) 04:31, 14 August 2014 (UTC)
When redirecting the page to Deprecated pages, the operation would be (btw. see the table below for comparison with other solutions):
  1. Update/remove all backlinks (as is done today when deleting a page)
  2. Redirect the page
  3. Protect the archived page to prevent updates
I'm assuming here that the solution should be similar to the current way in that archived pages should not be updated and that archived pages should not be linked. And this is the problem, we can't technically prevent linking to archived pages if we choose this solution.
-- Lahwaacz (talk) 23:16, 13 August 2014 (UTC)
I'm not sure if protection is needed, after all deleted articles can be freely recreated, so semi-deleted articles shouldn't have a higher level of protection.
About links, the fact that the semi-deleted articles are redirects that point to ArchWiki:Deleted should already discourage linking to them. The same goes for any kind of links, we can't technically prevent any kind of nonsensical links, I think that's an unrelated problem. Yes, it's possible that somebody links to an old revision of the semi-deleted article with an external link, but that's already true for the old revisions of the existing articles.
-- Kynikos (talk) 04:31, 14 August 2014 (UTC)
Right, when we provide an archive, it should be possible to link to the archived revisions. Anyway, there could be a difference between redirecting and deleting as it seems that I can't link to specific revision of a deleted article - the preview button from [5] just gives this url: https://wiki.archlinux.org/index.php?title=Special:Undelete&action=submit.
-- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
There is a difference, you can't link to a fully-deleted revision because only its plain source text can be queried normally (mw:API:Deletedrevs and mw:API:Undelete#Token), so the rendered page can only be previewed (I guess with the same algorithm that previews normal pages being edited), which requires a POST request (i.e. no parameters visible in the url => unlinkable). This is another parameter for the table below; I'm not sure if the ideal solution should allow linking or not. -- Kynikos (talk) 14:52, 15 August 2014 (UTC)
About protection, is the ideal solution controlled (i.e. admins (+maintainers?) control which pages will be archived/restored) or open (where anybody can archive/restore a page)? I don't see a problem with controlled as users could ask for the operation to be performed. On the other hand, open archival could bring problems. I think that ideally archival would be controlled and restoration open.
-- Lahwaacz (talk) 11:15, 14 August 2014 (UTC)
IMO we should use MediaWiki's default behavior: if we go for the visible deleted revisions, then the archiving operation is a deletion which by default is controlled; if we go the ArchWiki:Deleted way, then the archiving operation is a redirection which would be patrolled just like any other redirection for any other purpose, so it could stay uncontrolled. The same could go for restoration, although if we allow everybody see the source of deleted revisions, it's not necessary to have undelete rights to restore the article, it would be enough to just re-create the article by pasting the source there (I know, it wouldn't be the proper way because all the history would be lost). -- Kynikos (talk) 14:35, 15 August 2014 (UTC)

Why exactly was the "separate namespace" way discarded? Was it FS#35545? -- Lahwaacz (talk) 23:20, 13 August 2014 (UTC)

Apart from 35545, if I understand correctly the "separate namespace" solution would consist in moving the candidate articles into a special namespace without hiding their content with a redirect; yes, all their backlinks would have been cleared, but they would still keep linking to other articles, thus polluting those articles' backlinks, and also some special pages, and that's something that I'd like to avoid. -- Kynikos (talk) 04:31, 14 August 2014 (UTC)

I have modified the row "Permission to perform archiving" for the "ArchWiki:Deleted" way to be simply "editors", which is the least privileged group which could perform archiving under ideal circumstances. There are some cases when editors wouldn't be able to perform the operation by themselves: for example if the archived page had some redirects pointing to it, they should be deleted, because archiving would create a double redirect and "normal" fix would cause the redirects to be archived too, which is useless since there is usually no history.

Also note that archiving would most likely involve more people from different groups: for example everybody could propose a page to be archived, then after reaching a consensus, admins/editors would archive the page, then editors/patrols would check the operation etc. This is not a good material for the table below since it applies to all methods, however it should be discussed because we will have to write guidelines for the archiving anyway.

-- Lahwaacz (talk) 19:53, 16 August 2014 (UTC)

I agree with redirects, they should be deleted when archiving their target, unless for some reason they can be diverted to some other article.
And yes, we should really start writing guidelines not only for archiving, but also for the other common operations (creating/moving/deleting a page, moving a section in the same article or another article, generic redirection...), something like already exists in ArchWiki Translation Team#Create a new page and its translation.
-- Kynikos (talk) 03:36, 17 August 2014 (UTC)
Absolutely, we need to cover that. @Lahwaacz: Also all good with just "editors", but one step we want in the process is the decision about "notable content" in that column, no?. E.g. (1) Karol identifies Ubuntu One as deprecated, (2) ideally proposes a method (redirect or delete) due to content in the template, (3) the delete gets no objections. Now at the latest that "archiving" (deletion in this case) proposal should get to the admins to review/perform. (Just wondering if the simplest would be to use two redirect templates at that point, i.e. "Archwiki:Deleted" and "Archwiki:Obsoleted" or something, but might be totally unnecessary). I must say I am curious what the others think about the current table!? any objections we concentrate on column 3/4? --Indigo (talk) 10:58, 17 August 2014 (UTC)
Yes, the decision step about notability should be in the guidelines.
I'm not sure what you mean about the "Archwiki:Deleted" and "Archwiki:Obsoleted" pages: in case we go for the redirect solution, obsolete pages will be redirected to the dedicated "ArchWiki:..." page if they have a notable history, otherwise they will be normally deleted like we're doing now.
Are 3/4 0-based indices? Just to make it clear, I'd concentrate on the last 2 columns.
-- Kynikos (talk) 01:46, 20 August 2014 (UTC)
When I added above rough idea quoting "Archwiki:Deleted" and "Archwiki:Obsoleted" I was thinking again about the easiest workflow to distinguish the decision to either archive or delete. Sticking to "Ubuntu One": how do you get to know that (1) the deletion proposal had no objections and (2) it's time to delete it.
To my understanding the admins currently either consider a deletion template set by others by running across it, or by getting notified individually. The idea was that using two new redirect templates (deleted/obsoleted) instead of one, the two buckets could be filled - each to be reviewed at its own pace. Clearer? --Indigo (talk) 07:40, 20 August 2014 (UTC)
Then you have used the wrong prefix, you meant "Template:Deleted" and "Template:Obsoleted". There is already Template:Deletion, so I would use "Template:Archival" for the new template. Maybe it would be clearer to use just the verb: "Template:Delete", "Template:Archive", "Template:Move", Template:Merge... -- Lahwaacz (talk) 10:46, 20 August 2014 (UTC)
Uhm, with "two buckets" I actually meant two new redirect targets: one for semi-delete/archive (column 3), one for delete. If the delete-redirect would be set by an editor, the admins only have to check that bucket for new redirects and review/delete those articles. Likewise for the semi-delete/archive (column 3) redirect the notable content decision would be checked.
Using two templates for the distinction instead, you in your admin role still have to track status of the deletion template(s) across the wiki somehow, your fellow admin maybe does it as well, etc. Maybe it is clearer, if you see the two redirect-targets as patrol-points.
Does that make sense/sound practical? (I may well be over-engineering our case:) --Indigo (talk) 14:16, 20 August 2014 (UTC)
I think that you over-complicate things here... Unlike archival, deletion is a core feature of MediaWiki, there is no need to use the redirect-to-some-dummy-page workaround. Using the MediaWiki's feature, deleted pages are just "gone" for the regular users (at least until the fourth/last column is implemented). Obviously the solutions in columns 3 and 4 (redirection and deletion) can't be combined, redirecting a deleted page would make it undeleted.
We are trying to devise a solution for archiving pages, which is not implemented directly in MediaWiki, so let's focus the discussion on this topic. Also, for now I would like to focus on choosing the archiving technique (the technological solution), the guidelines (user interaction, used templates etc.) can be discussed later as this will inevitably depend on the chosen technique.
-- Lahwaacz (talk) 21:28, 20 August 2014 (UTC)
After reading your post again, another idea occurred to me: perhaps you meant the problem of differentiation between deleted and archived pages? This is a problem exclusively for the last method, i.e. archiving by deleting. If we wanted to somehow distinguish archived pages from "normal" deleted pages, it would be likely done by the "Reason for deletion" (see mw:Help:Sysop_deleting_and_undeleting), which would store the information in the Deletion log. We could probably mark the pages with appropriate template before actually deleting it, but using the "Reason for deletion" seems more natural and useful. -- Lahwaacz (talk) 21:49, 20 August 2014 (UTC)
Thanks for taking the time for above too Lahwaacz. Sure, this can wait. To your question: yes, that's what I meant. I'm going to stop about it, but just a tiny example: User:Indigo/Test1. Now for the example the admins would only have to check the backlinks of that redirect, review & delete (with "Reason for deletion" as usual). We could also use such for the last method as well I believe, if at all useful. --Indigo (talk) 19:50, 21 August 2014 (UTC)
We can re-use the advice to fix the link that led the user there in the redirect for simply-archived pages, although it will make sense only for external/full links, as a good admin will have fixed all the internal backlinks before archiving or deleting an article. About your idea in general, we can already check Special:WhatLinksHere/Template:Deletion, there's no need for a "temporary redirect" after the page has been marked for deletion. -- Kynikos (talk) 13:59, 22 August 2014 (UTC)
Ok, no change deemed necessary then. --Indigo (talk) 16:11, 22 August 2014 (UTC)
I think we should delete Ubuntu One article, because it is no need anymore. Also, please delete Ubuntu One (Русский) article too. Agent0 (talk) 08:19, 3 October 2014 (UTC)
+1. Your heads-up for the second link got overlooked. --Indigo (talk) 21:10, 11 January 2015 (UTC)
Done. — Kynikos (talk) 03:34, 12 January 2015 (UTC)
Help talk:Procedures#Deal with talk pages after redirecting a page to another is related. — Kynikos (talk) 01:37, 2 January 2016 (UTC)

List of suggested solutions

A table of additional properties to follow the discussion more easily:

Ideal Delete, don't look back
(current method, not a solution)
Separate namespace
Redirect to a page like
Publicize Special:Undelete
Type of archive operation - delete move redirect
(i.e. modify content, then protectquestioned)
Permission to perform archiving ??? admins depends on config editors admins
Permission to undo archiving ??? admins depends on config (?)
(can be forced w/ copy/paste)
editors admins
(can be forced w/ copy/paste)
Page titles show in wiki search results no no yes yes
(if redirects are included)
Page content shows in wiki search results no no yes no no
Page titles/content show in external search results no no yes
(unless disabled
with 1 or 2)
no no
Secure (see discussion) yes yes yes yes ???
(ask upstream)
Pollutes other pages' backlinks and special pages no no yes no no
Can link to archived revisions ??? no yes yes no


In light of recent issues, I'd say it's time to finalize this discussion: anyone against enforcing the ArchWiki:Deleted redirect way? The new "deletion" procedure would be:

New but inappropriate articles:

  • If inappropriate because of spam or other clearly malicious content (evaluation is made by an admin), it's deleted right away.
  • In most of the other cases the article should be moved as a subpage of its author's User page.

Old articles gone deprecated:

  1. Mark for deletion;
  2. Wait at least 7 days: in absence of discussions/objections, redirect to ArchWiki:Deleted.

Double redirects might be created after redirecting to ArchWiki:Deleted: these will have to be deleted, unless for some reason they contain part of the history of their targets; in this case a merge should be considered, or the redirect should be moved to a "Target page (redirect[0-9]+)" title and redirected to ArchWiki:Deleted too, thus making it clear where to look for the more recent history.

In both cases, all the backlinks to the deleted or semi-deleted page will have to be removed.

I've left out the "notability" assessment (redirect if notable, fully delete if not) as there can't be objective guidelines for the choice and it might unnecessarily expose the responsible admin to complaints.

The ArchWiki:Deleted page (better title proposals will be considered) must be initialized with an evident link to its WhatLinksHere page.

I think it would make sense to start a campaign to restore articles that are currently in a deleted state; requesting restorations should be explicitly made possible in ArchWiki talk:Deleted.

Do we want to rename Template:Deletion to Template:Archive or similar?

We'll also need a news entry to make this official, I'll probably get there by the upcoming weekend in absence of substantial objections. Please help improve the procedure in case I missed something: it will have to be moved to Help:Procedures once enforced.

Kynikos (talk) 06:09, 6 May 2015 (UTC) (Last edit: 03:02, 21 May 2015 (UTC))

PS: We must also address the problem of what to do with the talk pages of deleted articles, since I've seen discordant actions recently. — Kynikos (talk) 06:18, 6 May 2015 (UTC)

PPS: I'd also like to better define "inappropriate", and at the same time give a more liberal and inclusive definition of "Stub", possibly shifting a bit our traditional perception of short-and-ugly articles, giving them more chances of being expanded/improved by other users than the original authors. Please share your ideas. — Kynikos (talk) 06:33, 6 May 2015 (UTC)

Restoring revisions and redirection

About restoring revisions deleted in the past, we can use mw:API:Deletedrevs to list and filter them. — Kynikos (talk) 03:05, 9 May 2015 (UTC)

It's good you changed your mind. It would be a pretty major change and we sure need not only to discuss the details, but also play with it. I'd even say before such a change is done, the admins should use it first only in order (1) to ensure it is straight-forward/KISS enough to perform and (2) to extrapolate how it may turn out. Still, I would find it beneficial and reasonable, if the status quo (detailed in/above the table) could be fixed in the meantime. Not to disturb with this request, I have opened Template talk:Deletion#Expansion on deletion process for that.
To your above proposal: I like it, except for seven days seem too quick for the wiki. I'll return too if I have input/ideas. --Indigo (talk) 05:34, 9 May 2015 (UTC)
Well, redirecting to the new "dustbin" is not something that we can prevent normal users from doing; perhaps we should run an "experimentation" session after approving the procedure, but before adopting it publicly. If we change our mind, it shouldn't be hard to fully delete the redirects.
About the waiting period, since the articles could be restored by anyone (and their history browsed as easily), I thought that 7 days would be enough, but we can open a poll for that.
Kynikos (talk) 04:42, 10 May 2015 (UTC)

> anyone against enforcing the ArchWiki:Deleted redirect way? Since it is the only method that does not involve waiting for Godot Pierre, it seems logical to at least try it. After all, returning to the current method in case of dissatisfaction would involve only deleting the restored pages. Since we want MediaWiki to do something it is not built for, there are many issues. The most outstanding is the limited control over the archive. We've had disagreements in the maintenance team, imagine what might happen when everybody is technically, not per policy able to archive pages. -- Lahwaacz (talk) 21:43, 9 May 2015 (UTC)

Well, technically everybody is already able to redirect whatever page wherever they want: I don't think that enforcing this new deletion policy would encourage that, and the current patrolling that we're already doing should be enough to catch violations. In case of unresolved disagreement, an admin's opinion should always prevail, otherwise it's a jungle, but that's true for every kind of edit. — Kynikos (talk) 04:49, 10 May 2015 (UTC)
I hope you're right, nevertheless it will still expand the area that needs to be checked and the probability of making a mistake or missing something will grow larger. -- Lahwaacz (talk) 20:33, 10 May 2015 (UTC)
Sorry for humbly insisting, but what I'm saying is instead that the area that needs to be checked will not expand, since everybody is already free to redirect any article at their own will, so I don't see how enforcing this new policy would make it more likely to miss a misredirection, be it to ArchWiki:Deleted or anywhere else :)
Redirection diffs look like this, pretty hard to miss, and they're also usually accompanied by a bold-red negative byte count in RecentChanges, something that always immediately attracts my attention.
Kynikos (talk) 11:19, 11 May 2015 (UTC)

As another note on the redirect method, it should be mentioned that even redirects can be categorized, which could be utilized. -- Lahwaacz (talk) 21:43, 10 May 2015 (UTC)

Additional note: I think on the ArchWiki:Deleted page we should encourage users to re-redirect the "deleted" titles to more appropriate existing pages, when possible. — Kynikos (talk) 03:35, 22 November 2015 (UTC)
Separation of archive content

Next issue is with separation of the archive from the normal content. Since your proposed way of dealing with double redirect involves messing with the pages' histories and titles, there is inevitable need to organize the archive. I think that "ArchWiki is not a muzeum" should still apply regardless of the chosen archival method, ideally the motto would be as easily followed as it is now. Ideally the archive functionality would be built into MediaWiki itself (or any other backend we might use in the future), but publicizing Special:Undelete is the closest (also accidentally keeping the maintenance burden on minimum). As far as I learned since the last summer, the "security" consideration could be dealt with by deleting an individual revision instead of the whole page, for which there is a separate deleterevision right. -- Lahwaacz (talk) 21:43, 9 May 2015 (UTC)

Can you please elaborate on the "need to organize the archive" part? How would the new policy influence "separation of the archive from the normal content"? — Kynikos (talk) 04:54, 10 May 2015 (UTC)
In the first post in #Enforcement you described how double redirects would be managed, which suggests that the archive would be organized (at least a little) in order to allow easier searching. When a page is restored, either with updated or completely new content, it would make sense to also restore these "archived redirects", otherwise we risk having the same titles in the archive and the main namespace. But what if a page with the title of the former redirect is restored? Everything could be likely managed with the merge feature (and it may be interesting to find its limits), but the point is that all this seems like a lot of work for little benefit. Browsing the archive will never be a cakewalk due to broken links and old templates. -- Lahwaacz (talk) 20:33, 10 May 2015 (UTC)
The problem of redirects to deleted/restored articles is already present: what we're doing now is simply delete/restore them without taking care of renaming, merging, etc. The procedure that I've outlined above tries to address such problem, but it's actually disconnected from the deletion method itself (full-deletion, redirect...), so if we feel it requires too much effort for little benefit, and you may indeed make a point there, we can just go back normally fixing the double redirects, and this wouldn't affect the practicability of the redirection delete method. After all, in theory redirects to a deleted article can still be found by e.g. browsing the contribution history of the "deleter" and looking at the edits that were made around the deletion date, since, if the article was properly deleted, those redirects will have been edited at the same time. — Kynikos (talk) 11:38, 11 May 2015 (UTC)
We can also nuke the wiki a la AUR3 -> AUR4 ;P
Every year we're going to suggest which articles should be kept and the rest is going to e.g. 2015-archive (read-only?). Every article in the archive should have a template at the top saying it's outdated and users are encouraged to update them in the main namespace.
I think there's little reason to put the wiki on such a harsh diet and the separation could discourage users from touching the old articles at all. Some content may have been rephrased and merged into other articles and instead of using our old 'deletion' and 'merge' templates and having a history of what has been moved where, we would be stumbling on missing or duplicate content more than we do now. -- Karol (talk) 13:22, 8 August 2015 (UTC)
I know it's a humongous discussion :P but isn't this practically the "Separate namespace" method that we discarded above? — Kynikos (talk) 04:06, 19 August 2015 (UTC)
I've noticed the discussion got stuck (unless I'm overlooking something), so I wanted to prod it, to see if it's still alive ;P
Yes, it's the 'separate namespace' idea and I think other ideas are a bit better, especially the 'publicize Special:Undelete' way. Any news from that front?
I agree that the separate namespace is not the greatest idea, but "Page titles show in wiki search results" would be a better argument if the wiki search didn't require wading through results I don't care about as it is. "Pollutes other pages' backlinks and special pages" could be solved by removing some links but that's either more manual work or a fancy bot that would mark these backlinks as 'linking to archived content'.
Tl;DR: is this horsie dead yet? ;-) -- Karol (talk) 09:26, 19 August 2015 (UTC)
To combine the "Separate namespace" and "Publicize Special:Undelete" suggestions, we could create an external archive hosted e.g. on Github, including only the deleted pages (either all or manually selected). The history of wikicode could be kept in the master branch and the rendered static HTML pages could be in the gh-pages branch and accessible from github.io. The pros: does not pollute other pages' backlinks nor special pages and it is faster to implement than publicizing Special:Undelete (although my knowledge of git is so far too limited to do it). The cons: can you think of any?
Sorry, I think the horsie has still many years ahead :P
-- Lahwaacz (talk) 10:11, 19 August 2015 (UTC)
Moving articles out of the Arch wiki would break the links on the archived articles and in the articles that link to them. -- Karol (talk) 11:16, 19 August 2015 (UTC)
Linking to archived/deleted pages would be at least discouraged in any case, but technically linking to external archive would be possible with an interwiki link, which is syntax-wise identical to the separate namespace solution. On the ArchWiki backend side, an entry in the interwiki map would have to be created.
The other way round, the links from the archived pages could be mangled automatically by the export script to always point either to ArchWiki or the archive, something similar is already done in arch-wiki-docs.
-- Lahwaacz (talk) 14:58, 19 August 2015 (UTC)
Honestly I think we're losing sight of the real problem, leading to an overengineering of the solution: every day there's a lot of content that is deleted from the wiki, even if the articles it belongs to aren't deleted themselves (outdated sections, closed discussions, ...). If content gets deleted, there is usually (and hopefully) a good reason, and MediaWiki gives natively a way to retrieve it with the lists of article revisions.
Our problem number (1) is that we currently have 2 kinds of deleted content, accessible and inaccessible, and this distinction doesn't reflect the nature of the deleted content at all. Eliminating this distinction is IMHO what we should first focus to do. If we create an external archive to make inaccessible revision lists accessible, I don't think we fix the problem, but we complicate things even more. We have to make all revisions visible on this wiki (redirects, separate namespace, special:undelete?).
Then, once (1) is fixed, we're left with problem number (2), i.e. the fact that there isn't a search engine that (optionally) also looks through text in non-top-level revisions. This would be a great idea for a MediaWiki extension, or alternatively a service that could indeed be performed by a bot, probably on a per-article basis, since the database of all the revisions of all the articles would be too big to be queried/downloaded at every search.
Kynikos (talk) 11:30, 20 August 2015 (UTC)
Double redirects

I agree to most of the procedure. For double redirects, I vote for just delete them. Check their history is to much effort. --Fengchao (talk) 13:04, 27 May 2015 (UTC)

Maybe the procedure I devised for double redirects should be executed by a bot, it shouldn't be too hard to program it. In that case, the policy would be to not fix double redirects to ArchWiki:Deletion manually, and the bot could be run daily or weekly. — Kynikos (talk) 03:59, 28 May 2015 (UTC)
Rename Template:Deletion

As for the Template:Deletion --> Template:Archive renaming, I think that we could make use of both. After all archiving does not fully replace deleting, there are more reasons for deletion (archiving is currently one of them). Moreover, Template:Deletion can be used to flag sections, whereas Template:Archive is/will be only for the whole pages. In a similar fashion, I think that the master page should not be called ArchWiki:Deleted but ArchWiki:Archived. -- Lahwaacz (talk) 15:18, 1 June 2015 (UTC)

Regarding Template:Deletion being used per section there is no confusion now & there is the template reason. Introducing something like ArchWiki:Archived easily gives the wrong impression about what ArchWiki:Deleted is about for starters. Besides, I am pretty sure most editors will be very hesitant to perform a deletion. Maybe something like a separate template is useful at some stage, but it should be easier to see how it goes and figure an enhancement then - not? I agree regarding the reasons for deletion; it should be clear only content pages are subject. --Indigo (talk) 18:09, 1 June 2015 (UTC)
True, Template:Deletion will have to stay in any case, at least for sections only. I didn't think of that, so now I feel that having a separate Template:Archive could complicate things a little too much: I'm not sure what side I support now, maybe adding Template:Archive is something that we could implement later as Indigo says?
If we decide to have both templates, maybe we should reconsider Template talk:Deletion#Rename and indeed rename "Template:Deletion" to "Template:Delete" so that it's more consistent with "Archive".
I agree MediaWiki:Deletereason-dropdown should be updated.
Regarding ArchWiki:Archive (which I think I'd prefer to "Archived") I think I quite like it, and maybe we could use that title even if we decide to keep using Template:Deletion to mark pages for archiving; I don't think that would create confusion. On the other hand, I'm not sure if this is what Indigo was saying, but ArchWiki:Deleted could indeed be more effective at preventing users from redirecting pages there without permission. In this case, perhaps we could start with ArchWiki:Archive and keep ArchWiki:Deleted as a plan B to implement in case we see that people misunderstand its purpose and the related archiving guidelines/procedure.
Kynikos (talk) 13:19, 2 June 2015 (UTC)

Broken redirects

I have written a simple script to list redirects with broken fragments (i.e. when no section with given title is found on the target page). After filtering out some false positives, here is the result. (And because I am incredibly selfish, I have eaten the low-hanging fruit before sharing the rest with others ;) )

As usual, please strike the fixed items off the list. Some things to consider:

  • The section might have been renamed, either to simplify the title, or just to fix capitalization as per Help:Style#Section headings.
  • Or it might have been merged with other, more generic section. Use the most relevant section for the redirect, or just redirect directly to the relevant page.
  • In the worst case, there is no relevant content on the target page. This will probably deserve a separate discussion.

-- Lahwaacz (talk) 20:01, 18 August 2014 (UTC)

Nice script. I fix zh-cn Chinese pages. --Fengchao (talk) 13:25, 19 August 2014 (UTC)
A little tip, check the date when the redirection was made, then check the history of the target page from that date to see what happened to the section. Alternatively, searching for the keywords of the missing section can help. -- Kynikos (talk) 01:21, 20 August 2014 (UTC)

Update: I have removed the fixed redirects for better readability of the rest, for reference they can be found here. -- Lahwaacz (talk) 17:51, 26 December 2014 (UTC)

Another update to the list, there are about 50 more broken redirects since the last time... -- Lahwaacz (talk) 13:33, 11 April 2015 (UTC)

Hide irrelevant pages in search suggestions

Is it possible to hide some irrelevant pages in search suggestion? For example, we should not hide Dkms page, because someone will looking that word. But we should hide irrelevant suggestions, such as Internet Share. It pollutes search and more unpleasant, I have sometimes created russian page with wrong title, because of this. I mean, I just added ' (Русский)' to english title, because when you are redirected, page's title in address string is still wrong. I understand, that we could not just delete them, because of some forums may use old titles. But making them invisible in Archwiki I think is good idea. Agent0 (talk) 14:39, 9 October 2014 (UTC)

Theoretically it would be possible to hide the redirects which differ only in capitalization, but MediaWiki is not able to do this. You can either get results including all redirects (default), or none: on search page click Advanced in the search bar and then unselect List redirects checkbox (and click Search to renew the results).
It seems that starting with MediaWiki 1.24, the URL for redirect pages will be rewritten to the target URL[7], which would certainly prevent the kind of mistakes you described. By the way, does anybody have an idea why ArchWiki is still at 1.22 branch?
-- Lahwaacz (talk) 17:41, 9 October 2014 (UTC)
Ok, and what about hiding pages, which titles differ not only in capitalization? For example, begin typing search string 'wire', you will see many pages named "Wireless Setup", but you cannot see what ever pages' titles begins with 'wire'.
Thanks for advice. I can do advanced search, but usually I use search box, which is in left side of each page. And the problem is that I do not want to hide ALL redirects, but want hide SOME redirects, that are irrelevant.
By the way, about hiding: is it theoretically possible to hide other languages suggestions in which languages I am not interested in? For example, I want to see which pages exists with title beginning like "Blueto". In suggestions I see many "Bluetooth (Language)" pages, but do not see, that there are article about bluetooth keyboard.
It's good, that URL will be overwritten, we will wait for Archwiki to be updated by some admin.
Agent0 (talk) 18:51, 9 October 2014 (UTC)
@Lahwaacz: I've always wondered too why Pierre is maintaining a "mw-1.23" branch in the repo but not merging it; I've posted a message in arch-general about that.
@Agent0: The wiki search engine is MediaWiki's vanilla, with all its features and limitations; for an alternative, you can try an external search engine like Google, appending site:wiki.archlinux.org to the search strings. In any case, a search engine will not understand what is "relevant" and what is not, unless it's given an algorithm to do so, which is not the case for our wiki. About languages in search results, you can already add the name of a language to the search strings in order to limit the results to that language; restricting results to English is not currently possible and will be fixed by Help_talk:I18n#Language_namespace(s)_in_place_of_suffixes?.
-- Kynikos (talk) 03:38, 11 October 2014 (UTC)

Article guideline


Large portion of my Arch Wiki time is spent to below pages. Need a way to improve the situation. I think Archwiki:Contributing could/should hold such information.

  • Specific Laptop pages - User should: Only add information to fix things that do not work. Do not list things already work well. Do not duplicate information from Laptop.
  • Specific Application pages - If the application work out of box and the page only list needed packages. Add it to List of applications.
  • Network related apps. For example OwnCloud, only base platform setup (php, Apache) are Arch Linux specific. General settings should go upstream instead.

--Fengchao (talk) 09:50, 11 December 2014 (UTC)

In accordance with Help talk:Style#Better structuring, I'd like to minimize the centralization of style rules for specific pages in single articles, be it Help:Style, ArchWiki:Contributing etc. This is my position:
-- Kynikos (talk) 04:49, 14 December 2014 (UTC)
+1. To add to above:
--Indigo (talk) 12:59, 14 December 2014 (UTC)
I wouldn't like to add too many specific recommendations to ArchWiki:Contributing, but at the moment I'm not strongly against either, since I want to largely reorganize that page anyway one day; maybe the "Specific Application pages" and "Network related apps" rules would better fit ArchWiki:Contributing#Creating.
About renaming ArchWiki:Contributing#Announce massive edits in a talk page I'm against: I want to keep those rules as basic as possible, since their only goal must be to prevent damage that can only be fixed with complete reversions; for this reason they shouldn't refer to style rules; also their headings should be complete sentences; if a massive edit is announced in a talk page, we can point the author to Help:Style#Hypertext metaphor if necessary.
-- Kynikos (talk) 15:39, 17 December 2014 (UTC)


A new page, TrackPoint, has been created to cover the configuration of the special input device typical to all/most ThinkPad laptops. There are still many pages duplicating the information, below is a complete list of pages that need to be merged. -- Lahwaacz (talk) 20:56, 22 December 2014 (UTC)

Renamed software

Nautilus got renamed to Gnome Files

Do we want to rename every occurrence of 'nautilus' in Arch wiki or is the redirect enough? -- Karol (talk) 23:49, 21 August 2014 (UTC)

The redirect has only 3 backlinks, 2 of which are talk pages. About normal strings, this should be a comprehensive list, but it seems pretty dangerous to do a blind mass rename with a bot.
Moving this back to the normal requests.
-- Kynikos (talk) 14:06, 22 August 2014 (UTC)
I replaced appropriate occurrences of 'nautilus' yesterday. I preserved upstream software names e.g. (Nautilus Terminal), package names and gschema names (for obvious reasons) and executable names. -- Chazza (talk) 14:50, 5 November 2014 (UTC)
Well done once again, Chazza, but the search I linked above still seems to show some appearances of "Nautilus" as file manager, so I guess we can't close this item yet. -- Kynikos (talk) 09:57, 6 November 2014 (UTC)
I started going through the pages in the search you link to. I think it will have to be done manually seeing as paths, gschemas, executables and upstream projects that use nautilus in their name cannot be renamed. Regarding foreign language pages, if there are just a handful occurrences of 'Nautilus' google translate can be used to get the gist of a sentence and see if it is safe to change 'Nautilus' to 'GNOME Files' or 'Files' - usually it is. But for the Spanish and Arabic pages Nautilus pages, there are dozens of occurrences so I would much rather leave that to native speakers. -- Chazza (talk) 11:41, 6 November 2014 (UTC)
Doh, I said the discussion was to be kept open, but I struck the heading anyway ^^' (thanks for re-opening it)
I was only referring to the English pages, I agree that the presence of out of date translations shouldn't be enough to keep requests in this page open, unless they are specifically about translations, which is not this case.
-- Kynikos (talk) 13:36, 7 November 2014 (UTC)

A list of pages where all possible instances Nautilus have been changed so we know what's been done and what hasn't. I will add to the list as I go through the pages returned in the search. -- Chazza (talk) 11:41, 6 November 2014 (UTC)

XBMC renamed to Kodi

Since version 14 XBMC was renamed to Kodi, see FS#43220. There are also some typos that say 'xmbc'. -- Karol (talk) 10:59, 25 December 2014 (UTC)

I checked backlinks to Kodi of the now moved article. I think we got it covered. Can this be closed? --Indigo (talk) 09:22, 4 January 2015 (UTC)
Thank you Indigo, unfortunately there's more, including an entry in List of applications/Multimedia and an entire section in XScreenSaver :) — Kynikos (talk) 09:21, 5 January 2015 (UTC)
Ah, thanks for search fu. I amended the last two for starters of this lot [8] [9]. Simple thing to watch for the rest is that the config directory stays ~/.xmbc/. --Indigo (talk) 14:50, 5 January 2015 (UTC)


Gummiboot is included in systemd since 220-2 as systemd-boot. Relevant search: gummiboot -- Lahwaacz (talk) 14:05, 30 August 2015 (UTC)

Cleanup: links to non-existent packages

As of today, there are exactly 714 invalid uses (413 unique) of Template:AUR or Template:Pkg, spread across 398 pages. The complete list is on User:Lahwaacz.bot/Report 2014-04-05. I will try to go through it and update the links, but this is not a one-man job, so I would really appreciate some help. Please remember to strike/remove the items from the list to save others' time. -- Lahwaacz (talk) 16:42, 5 April 2014 (UTC)

The previous report is closed for further updates, please contribute to User:Lahwaacz.bot/Report 2014-05-11. -- Lahwaacz (talk) 09:15, 12 May 2014 (UTC)
The previous reports are closed for further updates, please contribute to User:Lahwaacz.bot/Report 2014-12-24. -- Lahwaacz (talk) 13:14, 25 December 2014 (UTC)
The previous reports are closed for further updates, please contribute to User:Lahwaacz.bot/Report 2015-02-06. -- Lahwaacz (talk) 23:08, 6 February 2015 (UTC)
After introducing "package not found" link, should the bot pages above be removed now? --Fengchao (talk) 13:05, 10 March 2015 (UTC)
I'll delete them eventually, for now I think they could be useful for searching through the user notes when fixing localized pages (not that many user do this...) First I will need to implement the automatic report page as suggested in #Strategy for updating package templates. -- Lahwaacz (talk) 13:00, 13 March 2015 (UTC)

Surrounding link text

While performing #Cleanup: links to non-existent packages, the bot updated a lot of package links, but of course it couldn't update the text around them accordingly, for example [10], so that's something else that could be done. Here's the list of the changes: [11]. -- Kynikos (talk) 03:24, 7 April 2014 (UTC)

Technical detail: the last link is now slightly inaccurate, it shows all edits of the bot made in April 2014. Is there a way to set a specific day? (in this case 5th April) -- Lahwaacz (talk) 21:46, 9 April 2014 (UTC)
Cool, there's really a way, I've just noticed it :D https://wiki.archlinux.org/index.php?title=Special:Contributions&target=Lahwaacz.bot&offset=20140406000000 (the magic is in the offset parameter!) -- Kynikos (talk) 13:51, 11 April 2014 (UTC)
Update: the edit list for the 2014-05-11 cleanup is [12]. -- Kynikos (talk) 09:42, 12 May 2014 (UTC)
Update: the edit list for the 2014-12-24 cleanup is [13]. -- Lahwaacz (talk) 13:14, 25 December 2014 (UTC)
Update: the edit list for the 2015-02-06 cleanup is [14]. -- Lahwaacz (talk) 23:08, 6 February 2015 (UTC)

Strategy for updating package templates

It is an open secret that the current strategy for updating package templates, which lies in creating a dedicated report page, is not very effective. The number of broken package links was 714 before the first cleanup almost a year ago. Today, after several successful cleanups the number is 979.

The first problem is that the report page is being noticed only a short time after announcing the cleanup and (almost) completely overlooked after a few days. Updating a wiki should be a continuous effort, but this strategy relies on announcing an event.

The second problem is that only English pages were consistently updated in the cleanups. No wonder since the events were announced only in English...

I have a proposal to solve the first problem, and partially also the second: instead of creating report pages and organizing cleanups, the broken package links could be marked directly in wiki pages, similarly to the way external links are marked with Template:Dead link. The result could look like this: pkgnamebroken link: hint where "broken link" is a link to a section with detailed instructions to fix the package link and "hint" is a short hint uniquely identifying the problem (given by the bot).

The proposal could be implemented in multiple ways:

  1. By introducing a single template, e.g. "Broken package link", which would take "hint" as a parameter and produce <sup>broken link: hint</sup>. This template would be added immediately after the broken instance of Pkg, AUR or Grp, exactly the same way as Template:Dead link is added to broken external links.
  2. By introducing a separate template for each Pkg, AUR and Grp, for example "Broken Pkg link", "Broken AUR link" and "Broken Grp link". These templates would take two parameters, the (broken) package name and the hint. Then, "Broken Pkg link" would produce {{Pkg|pkgname}}<sup>broken link: hint</sup> and so on.

So far I'm for the second way, which should be more favourable to the bot.

The advantage of this strategy is that broken package links and hints are continuously visible to everybody reading the wiki page, which are presumably people most interested in the topic at the moment, while maintainers can still easily go through full lists generated by Special:WhatLinksHere. Also, I would not have to announce events :)

Of course I'm still open to other suggestions on solving the above problems, or any other if I missed something.

-- Lahwaacz (talk) 18:51, 10 February 2015 (UTC)

I totally support this, although method 1. looks cleaner to me, because:
  • It makes it clearer and more natural for users how to fix the template (just remove the message Vs fix the template name AND remove the message).
  • It's consistent with Template:Dead link.
Why would method 2. "be more favourable to the bot"?
Kynikos (talk) 00:51, 11 February 2015 (UTC)
The second method would only add checking additional templates. The first method would need checking for an adjacent template, which could be tricky to implement. I haven't tried it yet though, in the end it may be equally easy to the second method. -- Lahwaacz (talk) 07:59, 11 February 2015 (UTC)
Other thing is that one of the mistakes when using AUR/Pkg/Grp templates is invalid number of parameters, e.g. [15]. If the additional parameters are to be preserved and not automatically removed by the bot, this would be impossible to mark using the second way. Well, almost impossible, we could still set the hint using a named parameter, but it would be really unclear how the link marked this way should be "fixed". So we should definitely use the first method. -- Lahwaacz (talk) 19:32, 11 February 2015 (UTC)
Regarding your last point, I think those instances are very rare and editors will figure how to fix the link/sentence correctly (once they did the tricky part of finding where the package went). In my view this should not deter from using method 2, if there are any doubts method 1 with the bot might be problematic (over time).
Either method would be great. One suggestion regarding the current report pages: How about still producing them additionally, but onto a static page (overwritten on next run, noting a schedule, e.g. quarterly, on top)? Reason: Particularly if an editor wants to fix articles of a language, Special:WhatLinksHere is unwieldy to swim through for articles in the language. --Indigo (talk) 10:20, 12 February 2015 (UTC)
I could certainly still produce the reports. Also being it a static page, the updating could be done automatically similarly to ArchWiki:Statistics (so far I have created the report pages manually).
I have implemented the first method in the bot script today. Since it has taken me almost half a day, it was probably not "equally easy" to the second method, but I think it works quite well and safely now. Template:Broken package link is now created and its "broken link" link points to #Broken package links, feel free to improve both.
I was also thinking about how to integrate #Surrounding link text into #Broken package links, maybe the link to the bot's "contributions" with fixed date should be automatically put somewhere on each run? This task also depends too much on context, so the links like [16] are not very useful. In a way, it is already marked on the pages, because the link points e.g. to AUR and the context says otherwise. Also, we probably don't have the workforce to do systematic checking on this task, so is it even worth to include these instructions/links?
-- Lahwaacz (talk) 20:59, 12 February 2015 (UTC)
Sorry I did not mean to incur an extra manual task regarding the static page, just recalled how helpful it is to do the task systematically. It is related to your question about a run result page of the bot though. For cross-checking the bot's contributions for consistency we can filter like you do above and that should be enough imo. To work on the content, a bot result page probably would require manual transformation like the current method again. So, not required but an option.
Regarding the template: I would leave out "the hint" because the sup-text gets too long and breaks text badly on small resolutions. "Broken link" should be enough, not? Also I would let "Broken link" link itself to Template:Broken_package_link. This way we can change the link to the instructions (#Broken_package_links) noted there in case they move (e.g. to ArchWiki:Contributing) at a later point, or we decide to expand the instructions in the template itself a little, without needing a bot run over existing broken links again. --Indigo (talk) 22:45, 12 February 2015 (UTC)
I actually like your idea about the report page. Don't worry about the manual work, it can all be automated :) The report page could also include some statistics that can be collected during the update, e.g. how many broken links are there per language/in total.
I think that it is important to include the hint, except for the obvious "package not found", which is included only for consistency (and because the template would otherwise end with the : ] sequence). It may be silly that the hint is longer than the package name (the message "invalid number of template parameters" is probably too long anyway), but the only alternative I can think of is using some cryptic abbreviations like "PNF" for "package not found", which would be explained among other instructions pointed to by the "broken link" link.
Having the instructions on this page has the advantage that it is linked from the navigation bar on the left, whereas Template:Broken package link would not be as easily discovered "by accident". The template page should serve mainly as a description of the template itself and just link to the instructions, so I'd leave it this way. Of course if the instructions are moved, the link in the template can be updated accordingly.
-- Lahwaacz (talk) 15:32, 13 February 2015 (UTC)
(I was writing this while Lahwaacz was writing his post above, and he saved before me, but I think this comment can still be useful)
Well done Lahwaacz for implementing method 1.
The problem of grouping broken links by language would IMO be more naturally solved with localized Template:Broken package link templates, instead of using a report: it would be easy to add this feature to the bot.
The problem of the context wording is clearly unsolvable automatically, but for completeness I would mention it briefly in #Broken package links. I don't think adding any links is going to be of any usefulness; in theory a list of the changes could indeed be maintained in a report, and the entries stricken whenever each link's surrounding text is manually checked to be mentioning the correct location of the package; I'm not sure how popular such a list would be though, and the text would also be fixed anyway by casual users whenever they notice the inconsistency while reading the article. An alternative is using the bot to only always add the broken link template, even when the package template could be updated automatically, letting instead the users do all the actual updates manually; this method could be integrated with Wiki Monkey's editor assistant, which would complete the template updates in the editor, but still allow checking the changes before saving (already implemented there).
About leaving out "the hint", maybe we could instead remove "broken link: " and move the link to "the hint". Would adding a light-red background to "the hint" help having it recognized as a link status template, even if "broken link: " isn't there anymore? But still, this method would make the template inconsistent with Template:Dead link, unless we want to update that one too.
If we want the link to ArchWiki:Requests#Broken package links to be flexible in case we want to move the instructions somewhere else, I'd say the most natural way would be to use a redirect like Broken package link that we can point to wherever we want.
Kynikos (talk) 15:50, 13 February 2015 (UTC)

index.php in url address

Admins of Arch Wiki, do you noticed, that in every page address begins with https://wiki.archlinux.org/index.php?title=? Why? It is uncomfortable. Why could not you do just article name after https://wiki.archlinux.org/? — Agent0 (talk|contribs) 22:48, 6 March 2015 (UTC)

Administrators can't configure the entry-point urls, that's something that should be done in LocalSettings.php, which however is currently unpatchable because of FS#35545.
Nonetheless I agree with you, urls could be prettified by removing "index.php/", I think wiki.archlinux.fr has the best configuration in this respect. Documentation is in mw:Manual:Short URL/LocalSettings.php. Backward compatibility wouldn't be a problem since urls can be easily rewritten by the http server.
Kynikos (talk) 01:49, 7 March 2015 (UTC)
I have noticed, that article's path became https://wiki.archlinux.org/index.php/Page_title. Better, but still with ugly index.php. I agree with you, french arch linux wiki did varian which I wanted: just clearly https://wiki.example.com/Page_title. But according to [17] it is not recommended in some cases. As I understand, it just do not allow you (Pierre) to use some titles as articles, for example https://wiki.example.com/favicon.ico, but really, what reason to have such articles =D. And another problem may be that it may require root access to hosting server. Does wiki.archlinux.org is running on virtual server or it is hosted on a normal server? — Agent0 (talk|contribs) 09:59, 17 August 2015 (UTC)

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)

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

User and group pacnew files

I just went about handling .pacnew files of filesystem and believe we are missing content for it. It's important, as one can havoc a system mishandling them. Neither Users and groups nor Pacnew and Pacsave files mentions it; both should in my view. I'm creating the item here to:

  1. Check if I missed where it may be mentioned.
  2. Confirm procedure for handling them: can anyone think of valid reasons/cases in the current situation not to delete passwd/group/shadow.pacnew files?
  3. Ensure we add it to the relevant places. Opinions?

--Indigo (talk) 12:03, 18 April 2015 (UTC)

Well, the user and group database files are handled also from filesystem.install so the only difference I ever got from a .pacnew file was different ordering or (compatible) database format changes. Anyway, I'm wondering as well what is the best way to handle the .pacnew for these 4 files. -- Lahwaacz (talk) 21:46, 18 April 2015 (UTC)
Thanks. Searching the BBS yields a few threads, e.g. [18]. All I saw seem to suggest the files can be deleted. I remember an update where bash path changed; the .pacnew used /usr/bin while the original still had /bin path. I guess that would count as an example under "compatible" changes. A manual sorting with pwck and grpck could be part of the explanation how to diff the files before deletion. Also grpconv and pwconv should be mentioned briefly in my opinion. I added [19] and [20] for now.
Anyone has input for (2.) or (3.) above? --Indigo (talk) 09:33, 23 April 2015 (UTC)


The FAQ could use an entry like "After upgrading my kernel, I can't mount USB devices", preferably linking FS#16702. See [21] for a case where users are not aware of this. -- Alad (talk) 22:55, 18 September 2015 (UTC)

+1, but I'd place it into General troubleshooting. -- Lahwaacz (talk) 07:52, 19 September 2015 (UTC)

Bot requests

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