ArchWiki talk:Maintenance Team

From ArchWiki
Note: This talk page is not reserved to wiki maintainers: any user can write here to contact the team about organization or administration issues not related to a specific article.

Reorganization

The Maintenance Team was officially launched 3years-2weeks ago, and has since become an indispensable resource for the wiki, vastly improving the effectiveness of wiki maintenance, and also proving to be a fantastic ground for training new future administrators.

However, even things that work well can be further improved, and through time I've collected several ideas that I'd like to outline here:

  1. I'd like to rename the "Maintainers" group as a more commonly recognized "Moderators".
  2. ✓ This page would stay with this title, and the "Maintenance Team" would represent the team made by admininstrators and moderators, serving as the central page where to organize the collaboration workflow.
  3. ✓ We should use this very talk page as the best place to point users to for generic questions, complaints etc., instead of ArchWiki talk:Administrators (e.g. update the link in ArchWiki:Contributing#Complaining).
  4. ✓ I'd like to deprecate ArchWiki:Reports, and just invite to report issues directly in the affected articles' talk pages, possibly also adding proper status templates where useful. I don't know if we should keep the Reports page as an additional page where to also report urgent problems, what I've seen is that almost each of us has his own methods for keeping track of discussions, and the "Recent talks" page in the left column is quite efficient at signalling new issues for those who don't follow the full recent changes.
    Historically, ArchWiki:Reports was created because there wasn't anybody doing a systematic patrolling of the changes, even if only limited to talk pages, but in modern days this seems to have improved, so this can be another argument in favor of its deprecation.
    Maintainers who add entries to the table manually wouldn't be too much affected, since it takes the same effort to add an entry to a table or add a quick report to a generic talk page. Those who instead are using Wiki Monkey to add quick reports to the table, will of course see a difference, but I will commit myself to modifying the plugin so that it can insert reports in the article's talk page, probably with an explicit message stating that the report has been created automatically.
  5. Note mostly to myself, Wiki Monkey has some feature requests that are related to this restructuring: #175, #176, #197 and #198.
  6. ✓ The ArchWiki:Maintenance_Team#Current_patrols list can be deprecated, since it hasn't helped improving the number of full-range patrols, also apparently ending up including inactive members.
  7. ✓ ArchWiki:Maintenance_Team#Statistics was useful to track the evolution of the initial 146 reports, but now I think it's useless and can be deprecated together with ArchWiki:Reports.

Opinions needed. — Kynikos (talk) 09:11, 6 May 2015 (UTC)

Point 1) Sounds good to me.
Point 2) Agreed.
Point 3) I think that's a good idea. In so doing, that would ensure that the admin talk page is freed up for purely administrative discussions.
Point 4) Personally, I agree with the removal of the reports page. The people who are most likely to be able to fix issues for a particular article are probably the people who keep track of that article's talk page. I don't think that trying to centralize issue reporting achieves much.
Points 6 & 7) Agreed
-- Chazza (talk) 10:11, 7 May 2015 (UTC)
1,2,3. Also agree, this matches the BBS title "Forum Moderator". We could perhaps ask Jason to update the profiles of maintainers with a BBS account
4,7. I'm neutral on this... I think having ArchWiki:Reports as a central place for edits offers a better overview than WhatLinksHere, Recent Talks, and whatnot, also considering the table format. But perhaps I'm just lazy. :)
6. Yep, and not including active members as well. -- Alad (talk) 19:10, 7 May 2015 (UTC)
Also agreed. W.r.t 4 & 7, we might also try to generate some lists/tables based on the status templates and make a nice, sorted, filtered and ranked report e.g. once per month. Extracting the original flag date would be probably difficult, but perhaps not impossible.
Is it also the time to consider ArchWiki_talk:Administrators#Meaning_of_Administrator at this point?
-- Lahwaacz (talk) 19:27, 7 May 2015 (UTC)
About 1, I'm adding that it has to be done in 3 steps: create the moderators group, then move each maintainer to moderator, and finally delete the maintainers group.
Of course point 4 is the most controversial, replacing it with some kind of fully automated log/report would be ideal, but IMO it can be implemented later on. @Alad: I understand your concerns, but the benefits of always reporting directly in the articles' talk pages are quite clear now that talk pages seem to be much more watched than they were in the past (also thanks to the fact that IIRC finally MediaWiki is adding modified/created pages to watchlists by default for new users), and if we start doing that, keeping ArchWiki:Reports would mean having to do at least two edits for each report (or three if a status template is added), so that's why I proposed deprecating it; as I said, I will try to update Wiki Monkey to automate the new reporting procedure as much as possible, and I guess I could still have it append entries to ArchWiki:Reports too, but the problem would be keeping the table in sync with the linked reports in the talk pages... I'll think about it.
ArchWiki_talk:Administrators#Meaning_of_Administrator could surely be implemented in this article, it's very related indeed.
— Kynikos (talk) 14:21, 8 May 2015 (UTC)
I'm ok with everything, but +1 to keep (4) the reports. There is no question that you are right, items should be handled in the respective article's talk pages - the sooner, the better. Yet, I believe this is done anyway by all and the current reports are only a residual. I find it valuable to keep this as an opportunity (also for the visible quicklink), at least for some time. Reason: Imagine someone patrols a problematic in recent changes but the article is outside the own interest/ expertise and/or time to open a proper talk item (which would often be more elaborate than the report comment) is sparse. It would be a pity, if it is foregone or tracked in the backhead todo list only.
How about doing it like you propose, but changing procedure for the reports that may still be opened: They could be moved directly by anyone (incl. the creator on return) to the respective talk pages. If we then see the list stays tiny, it can be fully deprecated. --Indigo (talk) 19:07, 10 May 2015 (UTC)
My idea (which I hadn't eleaborated yet here) was to allow the creation of quick reports (also automated with Wiki Monkey) in articles' talk pages similar to the current entries in ArchWiki:Reports' table, probably also using a template to stress the fact that the comment has been added quickly and the reporter may only be confused about the edit and in need for confirmation. I'll use an existing report from ArchWiki:Reports as an example of how it could look instead in the affected article's talk page:

Quick report

[This is an automatic report about https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943, please help reviewing it]
Comment: I'm not qualified to check the content, but style is poor regardless. -- User, Timestamp
The whole thing could be manually added simply with:
{{Report|https://wiki.archlinux.org/index.php?title=PhpPgAdmin&curid=11293&diff=346886&oldid=345943|I'm not qualified to check the content, but style is poor regardless.}} -- ~~~~
The link to ArchWiki:Reports (the "report" anchor text) could be useful to list all the open reports with a search like https://wiki.archlinux.org/index.php?title=Special%3AWhatLinksHere&target=ArchWiki%3AReports&namespace=1 since it's unlikely that Talk pages link there for other reasons.
If using Wiki Monkey, more details could be added automatically, e.g. the timestamp and author(s) of the edit(s), Special:Diff could be used instead of the full link, and it could create the report in full text (i.e. like using the template with subst).
— Kynikos (talk) 10:54, 11 May 2015 (UTC)
Now in this case I'd like to nominate "(4) to deprecate Archwiki:Reports" for the Archwiki Understatement of the Year(TM) category. No, really - ace idea. That would be an ingenious enhancement imo. --Indigo (talk) 21:48, 11 May 2015 (UTC)
Yeah sorry, my original idea was still very vague, replying to your post has given me the chance to develop it into something that could actually work, although it would still need some refinement. I'm glad you like it, hoping that you weren't sarcastic of course :P Maybe we can see what the others think of it too, since I'm sure you're not the only one who didn't imagine that (4) was about something like that... — Kynikos (talk) 15:55, 12 May 2015 (UTC)
For the moment I've done points 6 and 7. — Kynikos (talk) 03:43, 24 May 2015 (UTC)
I think you got it, but of course it was not sarcasm, just trying to make a funny remark. Your idea with the quick report is great lateral thinking. One small reservation I have is about using a Template for it. We all know the hazzle of template breaking characters and I wonder if it might be cumbersome to use a template, but that can be seen. In any case it should be useful to get forward with a decision on where to go with the reports. Anyone else want to share an opinion on (4)? --Indigo (talk) 20:14, 29 July 2015 (UTC)
Eheh I got it I got it, thanks for confirming your support. I think the quick report would only be for short messages, like those in ArchWiki:Reports' table, which are probably even worse when it comes to breakability, so unsupported characters wouldn't be an added problem. I suppose that if somebody wants to reply to a new-style quick report, they can do it below (i.e. outside of) the template, like in a normal discussion.
I don't think we'll find many more people interested in replying, anyway I'm waiting to find some time to update Wiki Monkey's plugin, that's probably my main reason for delaying (4).
To complete the status update, (5) will come with (4), while (2) and (3) practically depend on (1), which in turn is on the shoulders of who is currently maintaining the back-end, even though it's a micro patch.
— Kynikos (talk) 20:54, 11 August 2015 (UTC)
Even if the WikiMonkey additions aren't completed yet, I'd now suggest to deprecate ArchWiki:Reports rather sooner than later. Over the course of the year, it has hardly seen any usage, and old reports which are long fixed amassed on the page. -- Alad (talk) 12:49, 13 September 2016 (UTC)
I'm still on with this plan. About Wiki Monkey (and my other software projects) I should be able to resume allocating some time within a couple of weeks, without promising anything, but yes, I don't want it to be a blocker for this idea. — Kynikos (talk) 10:51, 14 September 2016 (UTC)
I've flagged the page for archiving for now [1]; it should be straightforward to translate the few remaining reports to article templates. We can do the actual redirect once WikiMonkey is updated -- take your time. :) -- Alad (talk) 11:40, 14 September 2016 (UTC)
I'd like to know if there's still consensus on 1?
If it were to be implemented, here's a list of things to do:
  1. Replace $wgGroupPermissions['maintainer'] = array(); with $wgGroupPermissions['moderator'] = array(); in LocalSettings.php and get it deployed.
  2. Ask DevOps to run php maintenance/MigrateUserGroup.php 'maintainer' 'moderator'. See mw:Manual:migrateUserGroup.php.
  3. Move MediaWiki:Grouppage-maintainer to MediaWiki:Grouppage-moderator.
  4. Delete MediaWiki:Group-maintainer and MediaWiki:Group-maintainer-member.
  5. Create MediaWiki:Group-moderator and MediaWiki:Group-moderator-member.
  6. Update ArchWiki:Access levels and roles, ArchWiki:Maintenance Team and other pages.
-- nl6720 (talk) 06:26, 26 October 2021 (UTC)

Regular Wiki Cleanup Days

I think it would be really useful to have regular wiki cleanups where people gather together to work on the wiki. This could help with organizing categories, cleaning out mentions of rc.conf, or doing major edits/reorganizations. They could be held every 3 months (4x a year) with lots of advertisement and be a great way to get more people involved in Arch Linux. Meskarune (talk) 19:45, 11 October 2016 (UTC)

Admin guidance

Show we add some guidence that an admin should follow, the responsibilty they should take?

Example:

  • Encourage contribution from Arch users.
  • Guide new contributor to follow Arch Wiki Style.

--Fengchao (talk) 13:23, 11 July 2014 (UTC)

Well, if somebody becomes an admin, (s)he's probably been judged to be already fully aware of all his/her responsibilities, since becoming an admin requires quite a bit of experience as an editor (most likely as a maintainer first). Yes, some users are given administration rights because of other roles in the community, e.g. Devs, TUs, forum admins etc., but they usually don't act as "real" wiki administrators. Nonetheless, some guidelines may help users understand what is the role of an admin, and the same goes for maintainers, and we could create a proper page for that, as was conceived in #Meaning of Administrator. -- Kynikos (talk) 06:06, 12 July 2014 (UTC)
"Encourage contribution from Arch users" sounds like something even maintainers should do, in my opinion.
-- NetSysFire (talk) 14:53, 28 April 2021 (UTC)

Convention for splitting sections to new page

Under what circumstances should sections be split into new articles ? (I could not find any articles mentioning it exploring ArchWiki:Contributing. For exemple current OpenSSH#Tips_and_tricks, or pacman#Troubleshooting.

-- Apollo22 (talk) 22:01, 15 June 2019 (UTC)

Hi, it would probably be too hard to find generic criteria to decide when it's ok to split sections, it's always been discussed case by case. If you have solid arguments in favor of splitting those examples, you can flag them with Template:Move and start a discussion in their talk pages (not here).
Otherwise you can try to propose some generic guidelines, for the moment we have a procedure to implement a split after an agreement has been reached.
-- Kynikos (talk) 09:03, 16 June 2019 (UTC)
Maybe not generic criterias, but specific ones. For example sections like Tips and tricks or Troubleshooting can expand quickly. A generic rule like: if more than 10 subsections are listed, you can move the section in a subarticle without asking first -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
Another example is applications lists. Splitting them in a subarticle would allow direct inclusion in both the specific article and the applications list. -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
That's not enough, because e.g. Chromium/Tips and tricks is flagged to be merged with the main page again. In any case, splitting sections into separate pages has to be discussed first, because it is a radical restructuring of an article and we have ArchWiki:Contributing#The 3 fundamental rules. -- Lahwaacz (talk) 11:59, 16 June 2019 (UTC)
In case the Chromium page, I believe the separation in two pages is sane (I think the main page is long enough to justify the split). Also, in my mind, splitting a file is not a radical restructuring, but I understand the position of always announcing it first. Which template should be used to announce a split ? The Template:Move description suggest it is only for renaming articles ? -- Apollo22 (talk) 10:18, 17 June 2019 (UTC)
I've fixed the Template:Move description, the template has frequently been used to flag sections to be split, e.g. Network configuration#Device driver, Arch terminology#Arch Linux or List of applications#Network managers, which works pretty fine. -- Kynikos (talk) 16:16, 17 June 2019 (UTC)

Also, the related articles sidebar can appear to be a little bloated on some articles (for exemple pacman). Should there be a dedicated side bar for subarticles (not sure about the name) like pacman/Tips_and_tricks in pacman ?

-- Apollo22 (talk) 22:01, 15 June 2019 (UTC)

I don't find pacman's related articles box bloated; I'm instead afraid that I would find a separate dedicated side bar for subarticles to be an unnecessary complication. -- Kynikos (talk) 09:03, 16 June 2019 (UTC)
I understand. On a related note, how about adding an explicit rule/procedure to put subarticles first or last ? Also, if this is accepted, shoud/could there be a separator between subarticles and related articles ? Current exemple in ArchWiki:Sandbox -- Apollo22 (talk) 10:58, 16 June 2019 (UTC)
I don't have a preference about the order of subarticles in related links, you can see if you gain some interest in Help talk:Style, I suggest listing some example articles and show how their related boxes would change if an ordering rule was enforced, and assess pros and cons.
About separators, I don't like them in this context regardless of the links order :)
-- Kynikos (talk) 16:26, 17 June 2019 (UTC)

Remove redirect page with bad title

This topic is similar to above #Removing unnecessary redirects / pages but with a different target redirections.

Background:

  • The Help:Article naming guidelines changes along the years, so there exist many Old_Title -> New_Title redirections.
  • Many new users contribute to Arch Wiki before they notice there is Help:Article naming guidelines, so there exist many Bad_Title -> Good_Title redirections.
  • The Arch Wiki search field got a suggestion function years ago (Maybe since v1.3?), it is more user friendly but a new problem arise.

Problem: Redirect pages show up in search suggestion, so the search suggestion is usually very messy. For example for "Installation", I may get some thing likes: 

Installation guide
Installation Guide
Installation guide(Català)
Installation guide (Català)
Installation Guide (Català)

Solution: Delete pages with bad_title/old_title after some transition time? 6 months or 1 year? Any objection or better suggestion?

—This unsigned comment is by Fengchao (talk) 14:21, 14 May 2020‎ (UTC). Please sign your posts with ~~~~!

I think that pages with bad titles can be deleted after a week, and pages with old titles can be deleted after half a year. -- Blackteahamburger (talk) 09:21, 7 June 2020 (UTC)
I think this makes sense, also discouraging redirects with spelling errors (like "Flatpack" to Flatpak which was recently suggested). Of course, all this assuming that the redirect does not contain any relevant history which should be kept. — Lahwaacz (talk) 10:30, 9 May 2021 (UTC)
One such redirect (that I think should be deleted) is Keeping Docs and Info Files. No other wiki pages link to it either. -- Flyingpig (talk) 18:44, 9 May 2021 (UTC)
That one contains a history, so it should be kept (or archived at most). — Lahwaacz (talk) 15:37, 15 May 2021 (UTC)
What about renaming it (to something like Keeping documentation and information files) and deleting the page with the old title? I think that should keep the revision history while maintaining compliance with style guidelines. -- Flyingpig (talk) 18:14, 15 May 2021 (UTC)
I think "info" here was referring to info, but it's still better than the old title which I now deleted. — Lahwaacz (talk) 14:01, 7 June 2021 (UTC)
Thanks. I guess the "bad" title wasn't as bad as I thought then. -- Flyingpig (talk) 15:17, 7 June 2021 (UTC)
Guys, I have made some mess while moving a page into a user subpage, so some redirect pages ought to be deleted:
-- Duodai (talk) 06:26, 8 June 2021 (UTC)
Both pages are now deleted. -- nl6720 (talk) 10:11, 8 June 2021 (UTC)
Thanks. I have found that there are a lot of badly named redirects in the Russian AW (Pacman/Tips and tricks (Русский), Pacman (Русский)/Советы и приёмы, etc.), so later I shall create a list of such pages and put it here.
-- Duodai (talk) 10:44, 8 June 2021 (UTC)
Here is one, please delete it: RTorrent(简体中文)。 -- Blackteahamburger (talk) 10:27, 22 June 2021 (UTC)
Done. -- nl6720 (talk) 15:47, 24 June 2021 (UTC)
I'm joining in here with two more pages that should be deleted : Securing arch linux and Arch Linux Server, neither have an history and both are needlessly using Arch Linux in the page title without being used anywhere. --Erus Iluvatar (talk) 19:05, 4 March 2022 (UTC)
And one more Etkinleştir --Erus Iluvatar (talk) 19:29, 4 March 2022 (UTC)
All done, thank you. -- Kynikos (talk) 06:16, 20 March 2022 (UTC)
Thank you ! I've stumbled upon one more : Expansão, which links to Template:Expansion but is not used anywhere as this template should not be used on translations. --Erus Iluvatar (talk) 08:41, 20 March 2022 (UTC)
Done. -- nl6720 (talk) 12:18, 20 March 2022 (UTC)
Three unnecessary redirects from today: ASUS B9450CEA, ASUS B9450 and ASUS ExpertBook B940CEA and three older ones: Partial upgrades, TUXEDO InfinityBook S 14 v6 and Lenovo ThinkPad X1 Titanium Gen 1 --Erus Iluvatar (talk) 17:32, 25 July 2022 (UTC)
I removed all the laptop redirects. -- nl6720 (talk) 06:34, 26 July 2022 (UTC)
Thank you! Should I ask about partial upgrades? It was flagged with Template:Style since 2018, we have partial upgrade already, only two user pages use it, and it has no history as far as I can tell. --Erus Iluvatar (talk) 07:27, 26 July 2022 (UTC)
It was created by User:Kynikos, so I'll leave it up to him to decide what to do with it. -- nl6720 (talk) 10:48, 26 July 2022 (UTC)
Good work everyone, I've deleted partial upgrades. -- Kynikos (talk) 14:19, 21 August 2022 (UTC)
Thank you! --Erus Iluvatar (talk) 14:20, 21 August 2022 (UTC)
One more redirect with no history nor page linking to it: Terminal as a Transparent Wallpaper. --Erus Iluvatar (talk) 10:25, 3 August 2022 (UTC)
Removed. -- nl6720 (talk) 10:56, 3 August 2022 (UTC)
Thanks! Three other old and unused redirect without history, but for these I am not sure they deserve deletion: /etc/fstab, OS X and /. --Erus Iluvatar (talk) 12:30, 7 August 2022 (UTC)
Here are a few more redirects with no history, flagged with Template:Remove for a while: Category:Dynamic WMs, Category:Tiling WMs, Category:Stacking WMs, Category:Lietuviškai, Category:Slovenský and Category:Česky. --Erus Iluvatar (talk) 12:15, 10 August 2022 (UTC)
Deleted. Can you update the backlinks of the first three? — Lahwaacz (talk) 05:50, 11 August 2022 (UTC)
Thank you! I have found Category:Stacking WMs (Italiano) while doing so, it can probably be deleted too. --Erus Iluvatar (talk) 07:04, 11 August 2022 (UTC)
Thanks, deleted that one too. — Lahwaacz (talk) 07:19, 11 August 2022 (UTC)
Two more candidates for deletion: Xterm Automatic Transparency and Configuring Terminal as a Transparent Wallpaper. --Erus Iluvatar (talk) 19:05, 11 August 2022 (UTC)
Both deleted. Please fix Special:WhatLinksHere/Configuring Terminal as a Transparent Wallpaper. -- nl6720 (talk) 08:47, 12 August 2022 (UTC)
Thank you! User page updated to the right redirect, the last link is this discussion. --Erus Iluvatar (talk) 10:17, 12 August 2022 (UTC)
One new redirect which is unused and without history: Workstation. --Erus Iluvatar (talk) 20:13, 17 August 2022 (UTC)
It's gone. -- nl6720 (talk) 14:08, 18 August 2022 (UTC)
Thanks! --Erus Iluvatar (talk) 14:57, 18 August 2022 (UTC)
On today's menu:
--Erus Iluvatar (talk) 12:14, 19 August 2022 (UTC)
I deleted some of them.
MSI GE75 8SX has history, so it cannot be deleted. It was moved by copy-pasting instead of doing it properly.
-- nl6720 (talk) 09:44, 20 August 2022 (UTC)
Thanks! --Erus Iluvatar (talk) 12:32, 20 August 2022 (UTC)
Deleted the Asus stuff. Please fix Special:WhatLinksHere/Asus EEE PC 1025c, Special:WhatLinksHere/Asus EEE PC 1215n, Special:WhatLinksHere/Asus Eee PC and Special:WhatLinksHere/Asus x205ta. -- nl6720 (talk) 09:55, 31 August 2022 (UTC)
Thank you very much, the pages in user space are fixed! --Erus Iluvatar (talk) 10:31, 31 August 2022 (UTC)
Three more redirects with no history: Dv7-2120so, Install and configure xorg and IPv6 - Disabling the Module. --Erus Iluvatar (talk) 15:20, 30 August 2022 (UTC)
I have encountered three ancient redirects that are unused and have no history: Internet Access, Dialup Access and Direct Modem Connection. --Erus Iluvatar (talk) 19:36, 5 September 2022 (UTC)
More redirects I have stumbled upon today: Automatic Configuration with Cdist, Tiling window managers (we already have tiling window manager), Official Repositories Web Interface, Lenovo Ideapad Z580 --Erus Iluvatar (talk) 12:26, 15 September 2022 (UTC)
One more today: MBA --Erus Iluvatar (talk) 10:43, 30 September 2022 (UTC)
One more while fixing broken section links: CloudCross (portugues). --Erus Iluvatar (talk) 07:58, 18 October 2022 (UTC)
It's gone. -- nl6720 (talk) 08:01, 18 October 2022 (UTC)
/o\ I never said thanks! I found an other one today: Alacrity. --Erus Iluvatar (talk) 08:17, 21 October 2022 (UTC)
Done. -- nl6720 (talk) 08:57, 21 October 2022 (UTC)
Thanks! --Erus Iluvatar (talk) 05:35, 22 October 2022 (UTC)
I've encountered Localization（文言文） today, it can be safely deleted. --Erus Iluvatar (talk) 07:09, 27 May 2023 (UTC)
It's gone now. -- nl6720 (talk) 07:13, 27 May 2023 (UTC)
Thanks! --Erus Iluvatar (talk) 08:05, 27 May 2023 (UTC)
Here's a recent one: Dell 7440 :) --Erus Iluvatar (talk) 08:03, 15 July 2023 (UTC)
It's been put to rest. -- nl6720 (talk) 08:06, 15 July 2023 (UTC)

Are there statistics of page access?

Out of curiosity, is there a resource of analytics or any other statistics of pages access for, e.g., knowing which pages are more demanded by users? This subject came up in my translation group when talking about where to focus translation in. -- Josephgbr (talk) 00:05, 28 June 2020 (UTC)

I don't think so, but you can try asking the devops team to filter the web server logs and make some statistics public. -- Lahwaacz (talk) 08:43, 28 June 2020 (UTC)
I think this is very good and can be used to confirm the priority of translation and confirm the pages that should be maintained from time to time. -- Blackteahamburger (talk) 10:00, 28 June 2020 (UTC)
Agreed. Would be nice to review and assist with what matters most to our users. Adamlau (talk) 05:13, 11 July 2020 (UTC)
In the meantime, we can have a good approximation with Special:MostLinkedPages and Special:MostRevisions, possibly with Special:MostTranscludedPages. --Erus Iluvatar (talk) 16:24, 12 July 2022 (UTC)

Acceptable user names and signatures

Ban custom signatures

2) While I'm at it I'd also propose to ban custom signatures, which are very rare, but when used they badly mess up the source text of talk pages for no reason.

-- Kynikos (talk) 12:44, 11 August 2020 (UTC)

Or at least ban custom signatures that hide or change the real username. -- Kynikos (talk) 17:59, 13 August 2020 (UTC)
User:😎 just registered, although this is just a test account of User:Klausenbusk, who is a member of the devops team, this is still relevant. I am still in favor of adopting the blocklist used by Wikipedia, as mentioned in #Abusefilter.
-- NetSysFire (talk) 02:34, 5 June 2021 (UTC)

Obscene usernames

I'd like to point out that a user was just deleted for having an obscene username (credits to me for finding and annoying the wiki admins with it). Having a wikipedia-like automated check if the username matches a regex would definitely help with detection of that. Wikipedia:Wikipedia:Usernames for administrator attention. -- NetSysFire (talk) 15:38, 26 December 2021 (UTC)

I don't see any automation on that wikipedia page. If you give us a regex, we could try blocking that with AbuseFilter (assuming it actually works...). — Lahwaacz (talk) 08:12, 29 December 2021 (UTC)
The automation is doing a bot, which does regex matching. The bot reports it on the aforementioned page so it can be reviewed since false positives are a thing. We are not as big as wikipedia anyways, so just having something report it might even be a bit too much. The other part is users reporting accounts since a bot can not possibly catch everything. There is a list of regexes that the bot uses though: Wikipedia:User:AmandaNP/UAA/Blacklist
-- NetSysFire (talk) 10:53, 29 December 2021 (UTC)
I tried those patterns in Special:AbuseFilter/test using 
_regex := "INSERT_REGEX_HERE";
action === 'createaccount' & accountname irlike _regex
From 2021-12-22 it matched only three account creations.
❄️❄️ nl6720 (talk) 11:58, 29 December 2021 (UTC)
A little while ago I created Special:AbuseFilter/16. It blocks usernames matching w:User:AmandaNP/UAA/Blacklist and a few other words, but not Unicode ranges. So far it has 49 hits. -- nl6720 (talk) 10:40, 2 February 2022 (UTC)
The account name regex matching is part of AbuseFilter/15. -- nl6720 (talk) 17:07, 24 September 2022 (UTC)
Using Wikipedia:User:AmandaNP/UAA/Blacklist results in blocking more than we may want. The user caught in Special:AbuseLog/36741 reported the issue in #archlinux-wiki. As can be seen in [2], some names that do not deserve being blocked.
Should we curate the Wikipedia regex or build our own?
-- nl6720 (talk) 17:07, 24 September 2022 (UTC)
I removed a few things from AbuseFilter/15 for now. -- nl6720 (talk) 17:22, 24 September 2022 (UTC)
Removed one more following a request on #archlinux-wiki.
Perhaps using Wikipedia:User:AmandaNP/UAA/Blacklist in AbuseFilter was not the best idea.
-- nl6720 (talk) 18:15, 30 November 2022 (UTC)
And another one. I removed that Wikipedia blacklist from AbuseFilter/15. We're back to manually policing the user names, let's see how that goes. -- nl6720 (talk) 07:51, 13 February 2023 (UTC)
Unfortunately we had at least two problematic usernames in the last week. Namely one with both the N-word and the F-slur that rhymes with maggot and User:Semee1488. 1488 is a known hate symbol and there are next to no false positives. And the chances that the user was born on the 1st of april in 1988 or 4th of january are exceedingly slim. I agree that we do have false positive problems BUT wikipedia is using that list for reporting ONLY. Banning is still manual there, too but I am not sure if that applies to the harder slurs such as the N-word, which would make sense to ban automatically. We can probably thin out the list a bit and remove some less offensive stuff. So I would potentially accept usernames such as "FuckTypos" but not "IFuck<insert something here>", IrrelevantIdiot, one mentioned just above, is also fine.
-- NetSysFire (talk) 14:44, 23 March 2023 (UTC)
So it didn't last long, sadly. AbuseFilter/15 once again has a curated Wikipedia:User:AmandaNP/UAA/Blacklist. And I deleted the mentioned user account (it didn't have any contributions). -- nl6720 (talk) 15:23, 23 March 2023 (UTC)

Visual editor

[Moved from Help talk:Editing#Visual Editor. -- nl6720 (talk) 09:22, 23 September 2020 (UTC)]

Why isn't there any visual editor in ArchWiki, as in Wikipedia? -- FOSS ভক্ত (talk) 12:54, 18 September 2020 (UTC)
AFAIK no one has proposed adding a visual editor. -- nl6720 (talk) 13:28, 18 September 2020 (UTC)
Oh, I see. How to make a request? I'm talking about the editor of Wikipedia which contains both Visual Editor and Source Editor. -- FOSS ভক্ত (talk) 17:39, 23 September 2020 (UTC)
You already have :) And I gathered that you're talking about Extension:VisualEditor.
MediaWiki 1.35.0 will be released this week, so VisualEditor together with 2017 wikitext editor are a valid option to consider as the new default editor.
The concerns with VisualEditor is how will the wikitext turn out. We'd also need to create TemplateData for all templates. Looking at Wikipedia, adding templates is not at all intuitive if you don't know which template you need beforehand. But that's probably not that relevant since we have rules that govern wiki editing.
-- nl6720 (talk) 06:43, 24 September 2020 (UTC)
In the meantime I think the Extension:VisualEditor got quite some time to stabilize itself and maybe also to improve its generated wikitext. What would be needed in order to get support for said extension into archwiki? I would assume just LocalSetting.php needs changing as there are no additional deps to be installed since MediaWiki 1.35.0. Gromit (talk) 10:27, 28 March 2023 (UTC)
Also as discussed on IRC it also is possible to enable for some namespaces only (as per https://www.mediawiki.org/wiki/Extension:VisualEditor#Changing_active_namespaces), so a partial rollout and some practial testing would be possible.
-- Gromit (talk) 10:24, 27 July 2023 (UTC)
If the talk pages can serve as a testing ground, and it avoids us "wasting" our time with Template:Unsigned by also enabling DiscussionTools I'm for it. --Erus Iluvatar (talk) 10:31, 27 July 2023 (UTC)
Note that VisualEditor requires setting up Parsoid, which might be quite hard to configure properly. — Lahwaacz (talk) 06:40, 27 July 2023 (UTC)
Since Version 1.35 Extension:VisualEditor does not require parsoid anymore as the used things are now built into their own API.
-- Gromit (talk) 08:04, 27 July 2023 (UTC)
It still requires Parsoid, just not as a separate service. Parsoid#Installation says "If you are using a MediaWiki version newer than 1.35, explicitly loading Parsoid is required since August 24, 2020". I'm wondering if we need any further configuration or not. The documentation on VisualEditor is completely outdated, talking about 1.36-alpha as the newest version... — Lahwaacz (talk) 10:01, 27 July 2023 (UTC)
It might require parsoid in the background, but configuration is not a problem here. I have just confirmed with archlinux/archwiki (Mediawiki version 1.40) that adding wfLoadExtension( 'VisualEditor' ); is enough to get it working. You can have a look at the full LocalSettings.php here if you want to.
I'd also volunteer to take care of technial details if this is an addition we want.
-- Gromit (talk) 10:21, 27 July 2023 (UTC)
Then I guess their documentation is wrong or outdated... Thanks for testing it. — Lahwaacz (talk) 11:58, 27 July 2023 (UTC)

Extension:VisualEditor shows a notice when creating a new page:

You have followed a link to a page that does not exist yet. To create the page, start typing in the box below (see the help page for more info). If you are here by mistake, click your browser's back button.

We would want to modify the link to stay on the same site.

— Lahwaacz (talk) 12:26, 5 August 2023 (UTC)

Outdated pages in the DeveloperWiki

I have encountered DeveloperWiki:Linux Conferences which is horribly outdated. I hereby request the deletion of the page. I asked about this in the IRC channel and was advised to take this here by User:Svito, which also mentioned that it might make sense to discuss some other, more general questions here:

  1. Who is responsible for those?
  2. Where to nag people to update/archive them? (My comment on this: I already asked on the talk page of a DeveloperWiki article to remove a bit from the page because it has a dead link (as you all might have noticed, I like to fix dead and broken links).)
  3. There are some pages in the DeveloperWiki with one or multiple issues (mostly broken/dead links and outdated stuff), what should be done about that? It clutters the statistics a bit in my opinion

NetSysFire (talk) 02:23, 15 February 2021 (UTC)

  1. Developers are responsible for DeveloperWiki.
  2. Refer to 1.
  3. Generally we try to refrain from touching DeveloperWiki (that's why it's in such a horrible shape). If you want to change something in a page, it's better to ask a developer to do it.
-- nl6720 (talk) 05:21, 15 February 2021 (UTC)
The DeveloperWiki is basically a wild west. Discussions on talk page will be ignored for the most. The pages are not updated for ages. As the pages are public, the users may want to improve/update the content on such pages if they find it relevant. But users basically are unable to do so. For example, I wanted to update info in the DeveloperWiki:UID_/_GID_Database. I asked in irc channel my request, but I was told "The devwiki isn't there to teach the general userbase about anything". Then I cannot see a reason to show the page to non-developers users. And I was told "Why hide it?".
From the reader's perspective of view, such pages are uneditable junk. And no one is going to update it: developers do not care or do not have time, and the developers users are a really little number of people.
So I think either some pages should be hidden (so in the main wiki userspace users will create an "updatable" version) or info on such pages should be editable in some way (probably by moving some pages to normal namespace). What do you think? Ashark (talk) 16:25, 8 May 2021 (UTC)
Pages in the DeveloperWiki are written by developers for developers, i.e. not for general userbase. From my point of view, they are already "hidden" behind the DeveloperWiki: prefix. If this is not obvious enough, maybe we should make it more understandable somehow.
As for the DeveloperWiki:UID_/_GID_Database page, its purpose is/was to allocate numbers for specific packages. That's it. The documentation of what these users and groups are for and how they should be used belongs to separate pages dedicated to the relevant package. If it is a general system group, it would be described in Users and groups#Group list.
— Lahwaacz (talk) 22:18, 8 May 2021 (UTC)
In theory, my understanding was the pool of people both qualified to edit it, and capable of actually doing so, was supposed to be greatly expanded by allowing TUs to do so, but this was waiting on "permission models" of some sort? Eschwartz (talk) 01:21, 31 May 2021 (UTC)
I don't think giving TUs access to DeveloperWiki was ever considered from the wiki administrator side. The "privileged" access level was created and assigned to developers with a different motivation. Though now that it exists, it can be used for such purpose, but such decision must come from developers. -- nl6720 (talk) 10:14, 31 May 2021 (UTC)
The problem with that, unless we create yet another access level, is that 59 TUs would get "privileged", which can edit the same pages as cosysop (reserved to wiki maintainers). So we'd undo the whole effort of not giving unnecessary wiki-wide permissions to accounts that only need it to edit a few select pages. -- Alad (talk) 15:22, 12 June 2021 (UTC)
User:Jelly composed a list of pages that can be removed. I think we can mark them for archiving (or redirection if possible) and per ArchWiki:Archive, archive them after a week. -- nl6720 (talk) 10:40, 15 August 2021 (UTC)
User:Davezerave and I recently accidentally recreated part of the above list since we didnt know this existed. From our perspective there are now a few more pages that can be cleaned up in the DeveloperWiki Namespace:
-- Gromit (talk) 12:12, 3 August 2023 (UTC)
This discussion has been inactive for a while, let's consider it closed ? The page that started the topic is archived. --Erus Iluvatar (talk) 12:04, 4 March 2022 (UTC)
The marked pages in the linked list have not been archived (or even flagged for archiving) yet. -- nl6720 (talk) 13:40, 4 March 2022 (UTC)
My bad, you are right there are many pages left on the link... But from the content of some of them I think they are still in use (the first that comes to my mind is DeveloperWiki:Building in a clean chroot). We have to migrate them then ? --Erus Iluvatar (talk) 14:15, 4 March 2022 (UTC)
It says: Pages checked are marked for removal. -- nl6720 (talk) 14:18, 4 March 2022 (UTC)
It is possible to move the DeveloperWiki out of ArchWiki. DeveloperWiki should not actually be a part of ArchWiki. ArchWiki is not a place just for developers. -- Blackteahamburger (talk) 19:17, 4 March 2022 (UTC)
I don't think we should do that. Arch Linux developers are part of Arch Linux, so there's no harm in them having their little corner in the ArchWiki. That said, for projects on gitlab.archlinux.org, some already use the project specific wikis available there. -- nl6720 (talk) 19:24, 4 March 2022 (UTC)

Creation of a hardware team

As you might have noticed, there was significant recent activity on pages documenting hardware, especially laptops. The Laptop page guidelines have been created and all uncompliant pages have been flagged.

There is a lot more to hardware pages than just laptop pages, even if there are roughly 450 laptop pages (440 flagged, and there are a handful of good, newer ones). There are docks on the wiki, exotic USB devices, more exotic USB devices, modems and more. Also tablet PCs and apparently ARM-devices (yes User:nl6720, I agree that they do not belong here but they are still hardware pages).

Combined this may not yet be 500 pages but this is still a significant amount, this is why I propose the creation of a hardware team.

There are currently maybe two people (me and User:DerpishCat) working on hardware pages, but there should still be a central place to discuss everything relevant to hardware pages.

The goals are:

  1. Enable transparent discussions and decision making, this sounds awfully like a buzzword. But I want users to know why we do things and how
  2. Make current tasks public so others know what we need help with
  3. Coordination between users, also very buzzword-like. However it makes sense to split tasks sometimes.

The final goal we want to reach is that hardware pages are not a mess anymore. It is well-known that the wiki admins (fail to) pretend those pages do not exist since they sometimes ignore e.g Help:Style, some even violate the Code of Conduct by specifying things specific to e.g Manjaro, there is a big bunch of outdated pages and every page looks different in a bad kind of way.

-- NetSysFire (talk) 00:49, 7 April 2021 (UTC)

So you want to create ArchWiki:Hardware Team? With only two team members, I think it's a little too soon for that.
If you simply want a central discussion page, you can use Category talk:Hardware.
-- nl6720 (talk) 07:59, 7 April 2021 (UTC)

Abusefilter

As you all may know, the Abusefilter is currently not very helpful. It randomly marks newly registered users as spam and sometimes (not very often though) even marks new pages as spam even though they are legitimate. These are two different things, I want to specifically discuss the filter that marks new users as spam.

I am in favor of adopting the "block"list that Wikipedia uses, with a few modifcations of course. There are a few things that are just not fitting or not necessary (like the filter for football clubs) and things I would add, for example:

  • If certain derivatives (e.g Manjaro) or other distros are in the name.
  • Mentioning of the archwiki or other related projects (e.g the AUR) perhaps? As a sort of self-reference.
  • This is quite old, but since there has been harassment of Allan in the past, maybe add some well-known nicks or names to the list, too? This would also be nice to highlight anyone who potentially tries to impersonate someone.

Fortunately there is not much spam currently, but it is always good to be prepared. Wikipedia also uses a variety of other things, like ClueBot NG but these may be overkill or just not applicable. I do not know how well the bot would work here, since the ArchWiki is much more technical in nature than Wikipedia. I can imagine there may be many false positives.

It may also be possible to instantly undo edits not using a (proper) edit summary this way. This is something that is purely beneficial in my opinion. Even very minor edits should have an edit summary.

-- NetSysFire (talk) 14:50, 28 April 2021 (UTC)

We should also enable mw:Extension:AntiSpoof. — Lahwaacz (talk) 07:14, 30 April 2021 (UTC)
I agree with that. That looks like it will be beneficial, too.
-- NetSysFire (talk) 10:01, 30 April 2021 (UTC)

Visited links are gray

This makes the links blend in with the regular text on the page, especially when using Dark Reader. —This unsigned comment is by Glibg10b (talk) 07:30, 16 May 2021 (UTC). Please sign your posts with ~~~~!

From an accssibility/usability perspective, this is a terrible choice; something with some contrast for colourblind or visually impaired people would be a much better choice. Jasonwryan (talk) 06:00, 31 May 2021 (UTC)
Which color would you prefer for visited links? The archweb site currently uses the same color for visited and unvisited links, which effectively disabled highlighting visited links... — Lahwaacz (talk) 18:52, 4 June 2021 (UTC)
Sorry, I missed this reply :p I would probably opt for the standard purple: it should provide sufficient contrast for low/impaired vision readers and will be familiar to anyone from the early web. No idea how graphic designers will react to it tho... Jasonwryan (talk) 00:22, 2 March 2022 (UTC)
I totally agree with Jasonwryan; one cannot differentiate a normal text from a visited link in ArchWiki for the current color scheme but they are semantically different so should look different. Of course everyone can change this from the Wiki preferences but the default one should provide an acceptable UX as well IMHO. Ismailarilik (talk) 09:20, 24 May 2023 (UTC)

How to change packaging policies

I recently made a note about the Wine Package Guidelines talk page because I want to modify them slightly. I'm new to editing here, so I was wondering if there was a proper procedure for doing this. Do I simply take initiative and watch for if people complain?

VinceUB (talk) 07:42, 5 August 2021 (UTC)

Long, cluttered and hard to maintain pages

Unfortunately there are some pages on here which are hard to maintain because:

  • It is hard to validate the information without the specific hardware or software (which tends to be proprietary and may cost a lot)
  • No one knows if this still applies since the information may be ancient and the above still applies
  • There is so much content that transformed the page into something that is not feasible to maintain.

These are pages where lots of users contributed their individual solutions to and this basically spiralled out of control. The worst pages in this category are:

Other pages which are not as bad yet but should be monitored:

Both lists are unfortunately yet incomplete I suspect.

-- NetSysFire (talk) 01:23, 10 August 2021 (UTC)

The same applies to almost all troubleshooting sections and pages: Network configuration/Wireless#Troubleshooting drivers and firmware, Bluetooth#Troubleshooting, PulseAudio/Troubleshooting, Firefox#Troubleshooting, NVIDIA/Troubleshooting etc. — Lahwaacz (talk) 06:56, 10 August 2021 (UTC)
At least for troubleshooting sections, Help:Style#"Troubleshooting" section says to link the bug or create a bug report if there isn't any. There's nothing we can do for sections that don't include any bug links. -- nl6720 (talk) 09:50, 10 August 2021 (UTC)

User menu for logged out users

ArchWiki is now using the new Vector skin by default. That includes the user menu.

For logged out users, the user menu shows "Pages for logged out editors (learn more)".

The text can be customized in MediaWiki:vector-anon-user-menu-pages and the link title in MediaWiki:vector-anon-user-menu-pages-learn. The "learn more" link is hardcoded to Help:Introduction in MediaWiki 1.37, but it will use MediaWiki:vector-intro-page in some future release (see phab:T290813). There's also MediaWiki:vector-anon-user-menu-pages-label, but I'm not sure where that is shown.

So now we should decide what to do with these:

-- nl6720 (talk) 08:59, 21 December 2021 (UTC)

Help:Introduction could probably be redirected to ArchWiki:Contributing. ❄️❄️ nl6720 (talk) 08:50, 26 December 2021 (UTC)
I moved it to MediaWiki:vector-intro-page, the target is still the same: ArchWiki:Contributing. -- nl6720 (talk) 05:54, 6 July 2022 (UTC)
There doesn't appear to be a pressing need to change the rest of these pages. Closing. -- nl6720 (talk) 09:06, 28 August 2023 (UTC)

Syntax highlighting in code blocks

MediaWiki since version 1.21 has the SyntaxHighlight extension bundled. It adds the <syntaxhighlight> block, which lets editors add code blocks with syntax highlighting in specified language for easier readibility. As ArchWiki is a highly technical wiki, with configuration file and script snippets sprinkled everywhere, I was surprised to find this wasn't enabled yet.

Is there a specific reason for this omission? If not, I'd happily welcome this addition to the wiki. -- Zaroth (talk) 12:39, 15 February 2022 (UTC)

I wouldn't say there's a "specific reason for this omission". It simply was never enabled. Even if we do get it enabled, we would not want it to be used directly in pages, only through templates. I think it should be possible to adjust Template:bc and Template:hc to add an additional parameter to specify syntax highlighting language. -- nl6720 (talk) 09:36, 17 February 2022 (UTC)
That sounds reasonable, I understand that the parameter would be directly passed to the tag and would have to be one from the list of languages that SyntaxHighlight supports. Assuming that approach, I looked at the extension's parameters to check which ones also would be useful to expose via template on ArchWiki. So:
  • lang - specifies lexer to use for highlighting, e.g. python, cfg, pacmanconf or one of many others. Would be useful in {{bc}}, {{hc}}, possibly even {{ic}} (for e.g. shell one-liners, using shell-session lexer so the # prompt is correctly interpreted)
  • highlight - highlights specified line(s), e.g. 3-5, 7. I can see this being useful in {{bc}} and {{hc}} for e.g. showing context of a config file section while highlighting the important/modified lines.
  • line and start parameters enable showing line numbers and choose the start of the shown numeration, respectively. I don't see it being particularly useful on ArchWiki, especially since the highlight parameter works fine without them. If one finds a plausible usecase, I guess they could be exposed in {{bc}} and {{hc}}.
  • class, style and inline parameters control style and are already covered by the existing templates, so no need to consider them (except maybe when modifying the templates' code).
I wanted to be helpful and try my hand at drafting what the new template code could look like. However, I can't tell whether the <pre> hack used in {{bc}} and {{hc}} will still be needed with the extension enabled without trying it out. If not, this change would certainly make these templates' code easier to read and understand. -- Zaroth (talk) 10:39, 17 February 2022 (UTC)
I don't think we should care about any parameter other than lang.
Also adding wfLoadExtension( 'SyntaxHighlight_GeSHi' ); to LocalSettings.php will not be enough. The extension requires python-pygments python. I think, it would need to be added to https://gitlab.archlinux.org/archlinux/infrastructure/-/blob/master/roles/archwiki/tasks/main.yml#L20.
-- nl6720 (talk) 11:26, 21 February 2022 (UTC)
Actually, I was wrong. pygmentize is shipped in extensions/SyntaxHighlight_GeSHi/pygments/pygmentize, so only python is needed. -- nl6720 (talk) 12:34, 21 February 2022 (UTC)
Thinking about it more, it doesn't feel quite right to have a python binary running on the server just to provide syntax highlighting for a few code blocks. -- nl6720 (talk) 05:14, 10 April 2022 (UTC)
There is another way: Highlightjs integration, which, instead of doing the highlighting server-side via pygmentize, shift the burden to the client using highlight.js. AFAIK, it's intended to be a drop-in replacement for SyntaxHighlight, so the syntax and functionality should be nearly identical. Obvious cons of this solution are:
  • not being bundled with Mediawiki, which adds more maintenance weight of downloading and updating the plugin separately
  • making ArchWiki pages heavier due to added JS
But if including Python binary is the main issue, highlight.js is an alternative to that. -- Zaroth (talk) 07:47, 10 April 2022 (UTC)
It's not a real issue, but just my subjective feeling. Last time I asked, DevOps were ok with python on the server. I'll go with whatever solution other Maintenance Team members support. -- nl6720 (talk) 16:59, 11 April 2022 (UTC)
I would love to see some kind of syntax highlighting extension in the wiki. However I also think it makes sense to have lang, highlight and line as options to configure. They are vital configuration options to any good syntax highlighting. Segaja (talk) 20:07, 4 July 2022 (UTC)
I opened a MR to enable the extension: https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/667 ❄️❄️ nl6720 (talk) 14:22, 29 December 2022 (UTC)
👍 from me for enabling with the lang parameter, line is of dubious use since every change would have to be reflected on all text referencing the line number, while highlight is clashing a little with our existing usage of bold. --Erus Iluvatar (talk) 12:38, 30 December 2022 (UTC)
After some testing I got: {{#tag:syntaxhighlight|{{{1|{{META Error}}}}}|lang={{#if:{{{lang}}}|{{{lang}}}|text}}}}. The issue with it is that you can't use MediaWiki markup inside it :/ ❄️❄️ nl6720 (talk) 13:17, 30 December 2022 (UTC)
Now that's something of a blocker since we rely on italics for pseudo variables :/ --Erus Iluvatar (talk) 13:33, 30 December 2022 (UTC)
As pointed out by Lahwaacz, there are issues with Extension:SyntaxHighlight. -- nl6720 (talk) 09:55, 5 January 2023 (UTC)

Adding code of conduct and terms of service links in the footer

According to mw:Manual:Footer#Add links to the footer additional footer links can be created by editing LocalSettings.php. I think it would be a good idea to links to the code of conduct and terms of service.

I've prepared https://github.com/archlinux/archwiki/pull/53 https://gitlab.archlinux.org/archlinux/infrastructure/-/merge_requests/583. Thoughts?

-- nl6720 (talk) 11:06, 21 February 2022 (UTC)

I like the idea. What determines the order of the links? Can we order the three "Terms" links alphabetically? — Lahwaacz (talk) 11:16, 25 June 2022 (UTC)
No idea. From what I understand, the hook simply appends. -- nl6720 (talk) 14:57, 25 June 2022 (UTC)
Seems like so, it's still better than nothing. — Lahwaacz (talk) 13:57, 31 December 2022 (UTC)

Moving pages to User page

In Help:Procedures#Remove_an_entire_page, it says:

Here is my understanding of above rule: 1. If an article could be markd with Template:Merge or Template:Redirect, prefer such action. Only use Template:Move when an redirect is not appropriate. So could we both agree that Redirect is better than User page? Maybe we can make it more clear here. 2. If an article is an old page/is already edited by more than one contributor, it should not be moved to author's User page. We can relax this rule and create a rule fix both new and old pages as long as a Template:Move is only used as the last option.

So in my opinion, below pages could/should be merged and redirected:

Remove directly:

Remove user's page to reduce duplication:

--Fengchao (talk) 06:17, 6 October 2022 (UTC)

For the pages where you have preferred a redirect/merge, I
would not have the same reading for the following:
am unsure:
For the page you would have removed, I'm agreeing with you on all of them.
To get back at the rewording of the rules, how about simply adding "in order of preference" to highlight the fact that moving to userspace is the last resort?
I'm agreeing with you that pages that have become obsolete or have multiple contributors (but I would like to highlight the fact that I think a contribution to the content is different than a simple fix to the style) should not be moved to a user's page.
--Erus Iluvatar (talk) 08:28, 6 October 2022 (UTC)
Great! I always think moving some pages into user's page is something like a technical debt. It make maintaining easy right now but someday later we have to face them. But I do not have enough time/evidence to convince other admins. --Fengchao (talk) 05:04, 12 October 2022 (UTC)
I understand what you're getting to, and I'm glad to see you want the whole wiki to get better, but I'm not sharing that analysis. User pages are not visible by default in searches, are not indexed by search engines, and touching them sends a mail to the account owner by default: unless they require an intervention (e.g. archiving a page, mass replacing links) I believe they should stay how their "owner" set them, even if they become outdated or wrong. If anything, they behave like the Developer's wiki namespace to me: a place to be actively ignored. --Erus Iluvatar (talk) 07:11, 12 October 2022 (UTC)
Just because they don't show up in search by default doesn't mean they're not there, rotting, just outside everyone's sight. -- nl6720 (talk) 07:49, 12 October 2022 (UTC)
That's true, but do we want to do something about it, and if so, what exactly do we consider acceptable actions on a user's page? --Erus Iluvatar (talk) 15:13, 12 October 2022 (UTC)
It is just a dark corner.
  • Some pages are complete not related to Arch, so it should be discouraged.
  • Some pages are related to Arch but not fit main pages. Some pages are draft dropped by owner or moved by maintainers from main namespace. Sometime it still contains valuable information sometime it does not.
Because we have rule or consensus that a user's page is unremovable, unarchivable or even un-editable by anyone else, they are keeping growing which is a bad thing in years later. I am thinking to relax the un-editable rule. For example if a page is marked as draft or moved from main pages, just treat them as normal pages. Thoughts?
--Fengchao (talk) 04:21, 13 October 2022 (UTC)
Yeah, it reminds me of the laptop pages before we started caring again for them.
Given how that can of worms is going on, I'm not sure we have any valuable content to be found in the userspace, but if only one page has something that is missing from the main pages it should be done.
Do we start enforcing the code of conduct for user pages? This would mean that User:Cmsigler/RISC-V, User:VARGUX or User:Pongo1231/Arch on Steam Deck should not exist then, since the first one is about an unsupported architecture, the second is an unofficial installation guide and the last one documents a derivative distribution.
I'm of the opinion that some leeway should be given for these situation, in particular for the unsupported architectures, since we may want to expand on day beyond x86_64.
On drafts, I'm not sure editing the user's pages would do any good: either it has content that is missing from a main page and that should be merged directly without touching the userspace or it is shaped enough to be moved back into the main space before updating it within the mainspace. This does not apply to active drafts, where contacting the "owner" of the page one way or an other before working with him on the draft feels like a better approach.
Deleting, moving back to mainspace and archiving in a single day / with a week long delay feels fine to me for pages that were at one point in the main space and got moved to the userspace.
--Erus Iluvatar (talk) 06:40, 13 October 2022 (UTC)
It is like a round trip. What I propose is that we should not increase non-usefully pages into user's page because currently no one care about them. Whenever I saw someone moved some pages into user's talk page, I always wonder why such page is moved here instead of just archive/delete them? What value the original author what to add? Does the page still contain a tiny usefully info so that even the maintainer can not just archive it.
For user's pages the user added themself, we can add somewhere that it should related to linux/Arch linux. I think unofficially supported packages/arch/distro is fine.
--Fengchao (talk) 05:35, 25 October 2022 (UTC)
I'm not strictly against that, but in my mind archiving was reserved for old articles that had become obsolete. I.e. it is not a catch-all for bad content but a repository of previously good pages that are no longer relevant.
E.g. I don't see a good reason to archive User:Dginovker/System76 Pangolin, User:Tsuibin/Devtools or User:Darksaber/NetSim.
On the opposite side, User:Edvinonan/NVIDIA instalación de controlador privativo would have only amounted to create yet an other unused redirect of disputable value, since nothing is this page is worth keeping but the name could be used to redirect to NVIDIA#Installation. We already have a good amount of bad redirects and I'm not too happy about creating new ones instead of signaling to the writer that his page is not following Help:Editing#Creating pages.
Speaking of "caring about" user pages, I'd be OK to help do something about them, but I don't really see what can be done without being over reaching.
--Erus Iluvatar (talk) 06:18, 25 October 2022 (UTC)

Procee update for bad translations

During the migration of zh-hans translation to its own wiki, I found some translated pages are redirected to English pages. The redirect process follow ArchWiki:Translation Team#Dealing with old translations so it is perfect fine from a maintainer's view:

  • They are out of date, or many sections are not translated at all.
  • It seem no one care about them for at least a year
  • They are maintaince burden, consume valuable time to fix out-of-date link/packages

But as a translator, I find maybe we are push too hard on translations. Some pages should be keep because:

  • Although some sections are out of date, other sections especially installation and configuration sections are mostly fine.
  • No one care about the out of date pages because lack of time and because sometime the out of date sections are not important enough.
  • If the pages are redirecd to English pages, the interlanguage link is gone. Some non-English readers just want to find how to install and use the default configuration.

Below is my thoughts about dealing with above problem:

  • Maintainers should mark the page with out-of-date/bad translations, the same as current process
  • If a translation page is marked as out-of-date, it is local teams responsibility for further manual edits. I means the wiki bots will process them as before but wiki maintains could just ignore them.
  • The choice whether to redirect it to English page should be made by local team. The choice should be made case by case based on page content, not by a fix flag time.

Any thougts? --Fengchao (talk) 02:14, 11 December 2022 (UTC)

In no particular order, here are a few remarks and questions.
  • The rule has been discussed over the course of 2021 in Special:PermanentLink/750896#Dealing_with_ancient_translations and had received either explicit approbation or indifference, then was applied in the first half of 2022. Rules should always be open to modification and be challenged when required, but this feels like a recent enough addition so the consensus would probably not change.
> This case is a little special. The above discussion lack input from i18n translation team. So below is my input as zh-hans translator, not as a administor.
Thanks for your input, since I'm the major contributor to the French translation team in the last year, I can see the fear of "having the rug pulled out from under you". --Erus Iluvatar (talk) 07:46, 12 December 2022 (UTC)
  • Keeping existing pages up to date should be prioritized by the translators over creating new pages. Especially when using the proper Template:TranslationStatus, following the changes of the original page is less time consuming than the whole translation of a new page.
> It should base on a contributor's interest. Some contributor only want to translate large trunk of text. They do not want to compare between two different text. A wiki should encourge both type. A wiki fix this problem by enlarge both type of user base.
I think the maintenance side of the translation is not being given enough importance to the eyes of contributors, but I'm not saying it should be the only thing they are allowed to do. For example, see the tip in Help:Procedures#Request solving where we suggest an order of importance in handling the tasks from ArchWiki talk:Requests --Erus Iluvatar (talk) 07:46, 12 December 2022 (UTC)
  • If the page is not redirected to English page, the interlanguage link stays, but the reader is provided with out of date information. This should be evaluated on a page-by-page basis, but packages can be merged or change name, and the page then requires maintenance to be of any use regarding the "Installation" section. The same reasoning applies to the configuration when major changes occur, be they from upstream or packaging changes. Some of these could be handled by a non-native speaking maintainer, while more involved updates would require a translator.
> As said before, an out of date flag should be added on top of the page. The user will be informed by this flag.
I don't have a counter-argument to that, let's just hope it does not cause non-English speaker complaints about the relevance of the information we provide. --Erus Iluvatar (talk) 07:46, 12 December 2022 (UTC)
  • IMO, the translator/maintainer relationship should be symbiotic: the more eyes on a page and its translation, the better it gets in the end. If we bar maintainers of touching pages when they are out of date, we let pages rot unnecessarily (e.g. when a simple change can be reflected on the translations like a package changing name, or the removal of an out of date section) and adds more work on the shoulder of translators which diminishes the time they can dedicate to other tasks (which fits in nicely with your remark about translation not being updated because of the lack of time).
> Maintainers should not changing/rediect a page without reading both language. For example, I can read both zh-hans and English, so I could redirect a page based on my reading and how out of date the page really is, not based on a flag date.
I don't share that analysis. After enough time has passed, translations are far enough from the active page that starting from scratch is faster than salvaging what's already there. Any page in that state should be allowed to be redirected to the English page. I would love to have your view on ne last two points I have raised. --Erus Iluvatar (talk) 07:46, 12 December 2022 (UTC)
  • What do we do for translations where there are no active translators?
    • E.g. the Greek translation has a single contributor in the last years and they have not edited since 2021-12-03.
    • The Installation guide (Ελληνικά) is "only" two years out of date for now, when can we consider as a rule of thumb that a page is abandoned?
    • Judging on by-content basis sounds good and well, but how can one judge the content of a translation if they do not speak the language and there are no translators left to decide?
    • Do we have to wait like what happened to General recommendations (Ελληνικά) (or MySQL (Italiano)) which went mostly untouched for 10 years?
  • Do we let local teams do nothing with the pages forever? As discussed in #Moving pages to User page, letting old pages pile up and grow in number is like leaving around technical debt in a software project: it will one day have to be dealt with.
    • XScreenSaver (Español) was flagged since 2017, not updated since 2013 and looked nothing like the English page, Ext4 (Español) had no updates since roughly 2012, was flagged since 2020-12-12. The Spanish translation team is not inactive, but I'm not sure how the "noise" of maintainers asking about their old and non prioritized pages flagged with Template:Bad translation would be received as opposed to simply redirecting pages to up to date information if no one has cared for them in a long while.
    • Pages flagged with Template:Translateme or Template:Bad translation often stay flagged for years without being updated. Two more examples other than the Spanish pages above: QEMU (简体中文) was flagged 2017-11-28 but only got updated between 2020-09 to 2021-01, CUPS (简体中文) was flagged in 2012 but only got updated in 2020.
    • Cursor themes (简体中文) received no updates since 2014, was flagged since 2021-07-06 when it got redirected 2022-01-21, though happily a translator picked the page 2022-07-21 in the end. I think this is a good example of my point about prioritizing updating pages as opposed to creating translations for pages who do not already have one: if this page had been updated regularly, less total translation time would have been needed since it would have avoided the start from scratch in 2022.
--Erus Iluvatar (talk) 11:49, 11 December 2022 (UTC)
The Chinese translation team checkd such redirected pages and the conclusion is that most of them is still usefully to Chinese users. So they build a bot to recover all such page in new zh-hans wiki. If a translator found them too hard to diff, they will re-sync and re-translate them.
I discussed with current zh-hans wiki admins the reason why they want a seperate wiki with so much maintain effort. There are many reasons that I could argue with they. But below is the most significant reason that I could say nothing:
"We feel current Arch Wiki is very hard to contribute to. It weight too much on perfectionism insteaf of usefully to end user."
The departure is done for zh-hans. I think the move is good for both. Large maintaince burden is reduced for Arch wiki and zh-han team could make the contribution much easier and pages could be kept as long as they are usefull.
The question is does other i18n team have such feeling?
--Fengchao (talk) 04:59, 12 December 2022 (UTC)
Do they have specific examples of our perfectionism being the enemy of contribution? I'd love to see us improve that situation, since we are nothing without user contribution, and having too high of a barrier to entry would be detrimental to that.
On the other hand, I can remember multiple exchange with users (though outside of translations) who simply disagree with established style rules (the most common ones being Help:Style#Package management instructions and Help:Style#systemd units operations) and where refusing to bend the rules is a net positive for the coherence/structure of the wiki as a whole.
Thanks for sharing the sentiment so that we can make things better. --Erus Iluvatar (talk) 07:16, 12 December 2022 (UTC)
Partial translated pages and some out of date pages are not perfect but very usefully to users. Partial translation is still greate contribution which are valuable and should be kept with best effort. The Chinese team create a bot script to recovery all pages that are redirect to English page (See those history). It is waste of time of both maintainer's and translators. --Fengchao (talk) 01:25, 13 December 2022 (UTC)
In the first pages on your link I find zh-hans:Kodi fully untranslated, zh-hans:Xen with only the section titles translated, what benefit do they provide? I also stumbled upon zh-hans:SonyEricsson samba sharing which is archived in English, is that voluntary to resurrect outdated content and add maintenance burden on your side? --Erus Iluvatar (talk) 07:19, 13 December 2022 (UTC)
The page template is there so that a newly translator has less to check (interlanguag link, category, headers) before a first contribution. It is not perfect, but it indeed make a easier start.
For zh-hans:SonyEricsson samba sharing, sure there are other such pages too. The bot recovered about 400 pages from history. And the bot creator forget to filter out the pages redirect to Archive. It take long time for someone to dig out the pages and remove them again. I will contact the team to see if they could create another bot to clear such pages. But so what, no one read them and no one is harm by it. Just take it easy.
--Fengchao (talk) 14:03, 13 December 2022 (UTC)
I don't agree with that methodology, but I'm leaving you handle wiki.archlinuxcn.org as you intend on this point. I will just point out that for this specific page, it is a good example of what I see as wasted time, since the page was untranslated since 2015, as Special:Diff/563637 shows, you replaced the whole content with the updated one from the English page on 2019-01-18 (un-doing the work that had been done to translate the section titles in Chinese), but no one worked on the translation again until it got redirected to the updated English page. The version imported in archlinuxcn.org is thus providing broken package links to the reader, and is quite different compared to the English one.
Sorry if my last question in particular, or even my general tone came out as vindictive, that is not my intention. I'm just having a hard time understanding how you balance the quality of translations we offer to readers of various languages with the expressed desire of keeping where possible the contributions, so I'm trying to pry a little to see what your reasoning is. --Erus Iluvatar (talk) 19:37, 13 December 2022 (UTC)
There is an opposite situation in Russian ArchWiki: no one reads russian articles because they are "out-of-date by default", regardless of their usefulness ¯\_(ツ)_/¯ -- andreymal (talk) 09:56, 12 December 2022 (UTC)
When I first come to Arch Wiki more than 10 years ago, Chinese forum has the same saying. "If you encounter any problems read English pages first". I am proud to say that this is not the case anymore. I think here are the most things that are done right:
1. Use Template:TranslationStatus to "Show translation status of i18n pages. Record the last translated history id of the English page. Provide a link to check diff after last translation id". Compared with just an out of date notice, a reader could know how old the translated page is. If the time is long ago, the reader could check how much the English page has changed. And for a tranlator, the could compare the history by a simple click.
2. Make every page an contribution invitation. Also in Template:TranslationStatus, there is a link to Chines Translation Team. If readers want to contribute, they could find the how to easily. I myself subscribe to new page creation notice to make sure all newly created translation pages have TranslationStatus.
3. There are an active local irc/matrix channel. Users will be guide to wiki pages. If an user report an issue about the wiki, it will be fixed. So we are somewhat confident that the hot pages and hot sections that most users read are fine. With enough eyes, all out of date info are shallow. We should fix out of date pages by attracting more users to contribute, not by removing the pages.
--Fengchao (talk) 02:24, 13 December 2022 (UTC)
This is all great for active teams, but does not provide a solution for translations where no one speaking the language is still active on the team. See the previous state of many Italian or Greek page. --Erus Iluvatar (talk) 07:07, 13 December 2022 (UTC)
Fine, then we can relax the rule. Maintainers first requst for reply in local teams page, if indeed no one is active and no one answers, maintains could just remove all out-of date i18n pages. I am totally fine with such conditions. --Fengchao (talk) 14:03, 13 December 2022 (UTC)
That's a middle ground that sounds reasonable to me. --Erus Iluvatar (talk) 19:54, 13 December 2022 (UTC)
As I see, there are three possible statuses:
  • out-of-date but still useful (as decided by the local team);
  • so critically out-of-date that it's better to delete the translation (as decided by the local team, or in case if the local team doesn't respond);
  • out-of-date, but no one has yet decided if it's useful or not.
Perhaps it would be a good idea to create templates for all these statuses? The existing Template:Translateme and Template:Bad translation don't distinguish between them.
A notable example is Font configuration (Русский). It was deleted (Special:Diff/722157), but I immediately reverted the deletion (Special:Diff/722168) because it was still useful. In this case, I could add an "out-of-date-but-useful" template so that ArchWiki maintainers know that it is not necessary to delete this translation. Such template can be used as a response from the local team.
-- andreymal (talk) 21:43, 13 December 2022 (UTC)
Maybe we can get away with repurposing the existing template as follows?
-1 from me for any large trunk of remove if a maintainer do not know the removed text. If maintainer do fully understand the translated text, it is Ok for me. --Fengchao (talk) 15:04, 14 December 2022 (UTC)
We're back to square one here… You were saying it was OK for you to redirect a page "if indeed no one is active and no one answers, maintains could just remove all out-of date i18n pages". What am I misunderstanding in your answer? --Erus Iluvatar (talk) 15:23, 14 December 2022 (UTC)
The circuit for an out of date translation should then be a first flag with a Template:Translateme, without answer in 6 months it can be updated to Template:Bad translation, and the redirect can happen 6 months afterwards unless the flag is changed to Template:Keep translation.
We should have a provision somewhere on what delay is considered acceptable to replace a Template:Keep translation with Template:Translateme, otherwise we can run into situations where pages stay in a bad state indefinitely.
This would mean only a single template has to be created, and the text of the existing ones only needs small changes.
Maybe we should also put an emphasis on the fact that the templates should be preferably put in the offending sections instead of flagging a whole page when a single section needs an update? (I think I'm guilty of doing that on some pages)
--Erus Iluvatar (talk) 09:07, 14 December 2022 (UTC)
I think we'd better create a list in local translation team's page. At least some translators will check the page frequently. But for old pages that only a few people need, maybe it will sit there for years before anyone even notice. I myself only monitor English pages and remove zh-hans pages from my watchlist. And now I start watch zh-hans too ... --Fengchao (talk) 15:04, 14 December 2022 (UTC)
The issue with a list on the local translation team's page is that it's not obvious if all translators will follow it or not. It will also be kind of a clutter depending on what you expect the maintainers to put in the list? It would probably need at least a link to the out of date page, since when it is out of sync and a description of what is out of date on the page. Meanwhile a template on the page can easily be found with a category, e.g. Category:Pages or sections flagged with Template:Bad translation (简体中文), and be tracked by translators that way. --Erus Iluvatar (talk) 15:41, 14 December 2022 (UTC)
It should be opt-in instead of opt-out. We first check with each translation team whether they agree a maintainer could redirect a whole page to English once the page is out-of-date for 6 monthes and a maintainer will do the redirect even without understanding the tobe removed translation. --Fengchao (talk) 03:39, 15 December 2022 (UTC)
My proposal is for 6+6months, so a year total. I don't think giving a translation team a whole year to update a page is asking too much. If this is opt-in, we stay with the status quo of out of date and partially translated pages going nowhere for decades. --Erus Iluvatar (talk) 07:09, 15 December 2022 (UTC)
I changed my proposal based on my analysis of recent pages flag as bad translations. If the page is partially translated, it should be marked as Translateme and stay there as long as it is not critically outdated. When it is changed to Bad Translation, in the template comment, it must list the reason why it is [[ArchWiki:Translation Team#Dealing with old translations critically outdated and if no one fix them, the whole page will be redirect to Englih in 6 month. If a page is really critically outdated, 6 monthes are more than enough. My concern here is that some pages are not truely critically outdated. --Fengchao (talk) 14:24, 5 January 2023 (UTC)
That sounds reasonable, that means we only need to make sure we're on the same page for the definition of "critically". --Erus Iluvatar (talk) 15:34, 5 January 2023 (UTC)

About Partial translations

(Split from #Procee update for bad translations)

> This rule should be changed too. A partical translations should be kept if the translated part is useful to a user that can not read English.
I would love to have other people chiming in on this one, I do not share the view that a partial translation is more than maintenance burden. --Erus Iluvatar (talk) 07:46, 12 December 2022 (UTC)
We could divide ArchWiki pages into different classes. Some pages (e.g. Help:Editing, ArchWiki:About, Main page) are fundation pages that should be kept up-to-date and fully translated. Some pages (e.g. pages in Category:Laptops, DeveloperWiki) are out-of-date quickly themself so that a translation may not be needed. But there are still large number of pages sitting in between.
  1. Some pages are very long (e.g. Virtualbox), when translate those pages, a translator may translate only the Installation and Configuration sections while leave Tips and tricks or Troubleshooting untranslated. Most users will leave the page after reading Installating and Configuration anyway. I fear that few readers will read such pages carefully from top to bottom unless they are a translator :) Translation team is always lack of manpower so valuable resources should be used to translated the partitions that users read the most, not the Troubleshooting sections a user rarely read unless they encounting the trouble.
  2. Some pages/sections are moving fast and the English sections are a mess/out-of-date , (In my memory, Xorg,Wireless,Systemd are some example). When translate such pages/sections, I usually translate only the fixed part and waiting for the sections to evolve into a good/steady state. Sometime this process may take years.
  3. Some contributors' English is not good enough to fully translate a page. So a translator may only translate Installation section, and leaving other parts for other more capable ones. We could not/should not say to them: "Don't start contribution unless you are capable of fully translate the page". This rule weight two much on perfectionism than contribution. So a page may started partically translated by such contributors and then no further contributor are interest or having enough time. But what's the matter than, just leaving them there.
Partical translation and partical sections are easier to sync with English pages, just copy and paste the whole sections. Chinese translation team are always in shortage of manpower. If we have to choose between the two below, we choose 2.
  1. Fully translate a page one by one even though some sections are rarely read by a reader.
  2. Partial translate a page and translate only the hot sections.
--Fengchao (talk) 03:47, 13 December 2022 (UTC)
My main issue with that is the inevitable situation where the partially translated page gets out of sync with the existing page, a "drive-by" contributor translates the out of date content and updates the Template:TranslationStatus to the latest revision of the English page, and the resulting page is now a complete mess to untangle.
Right now the simple fix is a member of the maintenance team updating the English text, but there are too many pages to do that reliably since they are not listed by a category.
My solution would be to have only the translated sections in the i18n page and a link to the relevant sections for the untranslated ones.
See Window manager (Français) for an example of such page.
It would also avoid the presence of templates which should not be used on translations.
It should also always be tracked by a Translateme template.
--Erus Iluvatar (talk) 06:32, 13 December 2022 (UTC)
When I create Template:TranslationStatus ten years ago, I write Chinese first and translate them into English. The Chinese word “同步” make it very clear that they should import the diff from English one and then translate. "同步" was translated into English as "synchronize the translation". Maybe the translated one is not as clear as what we really want. So should we change them to something like "import the content from English one and then translate them"? It will help prevent users from translate before sync with English page.
Link directly into English one is indeed another solution when a translator know he/she will not complet the translation. We should document them somewhere and from my memory, it is what a maintainer will do years ago. We just change that section into English when we are sure that it is wrong (for example contain kernel26, rc.conf) and only remove the wrong sections, not a whole page. So from my point of view, the most valuable contribution of a maintainer is to make sure everyone's contribution is kept and not accidentally deleted by someone else. When some readers contribute translation, we should not just delete the whole page because some part are out of date. It is a wiki after all, even Englih pages have lots of out-of-date sections, should we just delete them. My answer is "No".
--Fengchao (talk) 13:50, 13 December 2022 (UTC)
I would have to dig into my edit history to find the pages which were translated from the text on the page without having synced the content first, but an update of Template:TranslationStatus might be in order to make abundantly clear that any non-translated content should indeed be checked against the English page first. I'm not sure what the best wording would be.
I'd be happy to have historical contributors chiming in if they remember the reason why we stopped linking to the English page when a section should be skipped during translation.
Linking to the English page does not avoid partially updated pages for partial translations, though. For example, a page is beginning to be translated up to and including section X, leaving Y and Z pointing to the English page. Someone then translates section Y and Z from English, but does not update what has changed from the English page up to the section X. We need to make it clear in the Template:TranslationStatus that in this situation the page is still not fully in sync.
My issue with trying to keep every contributions at all cost is that when most of the page is in various bad states, it's really hard to make sense of the hodgepodge for someone trying to clean up and get it in sync. This is then actively worse, since it becomes off-putting for the maintenance oriented contributors, and starts a self-perpetuating circle. Especially if we have more people willing to translate whole/new pages instead of maintaining existing ones, it might be more efficient to redirect the whole page when it's getting out of date, so that starting from scratch invites a translator.
--Erus Iluvatar (talk) 19:06, 13 December 2022 (UTC)
The intention is great but if the action is based on flag time instead of understanding of both language, the result will be bad. Many pages are redirected because just a small part are out-of-date for a year, not because it is too hard to sync with English page. See this change as example, I just update a tiny section and the whole page is up to date again. Whether a translated page should be deleted and re-translated again should be made by a translator. I myself sometime just recopy all English sections when a page structure are changed greatly. That is OK as long as I understand both pages.
Some redirect could be summarized as: Large trunk of translated text are removed to prevent that maybe someone in the future do not know they should sync with English first. Really harm is done to prevent a rare possibility. Just leave them there and give more guide if needed. Trust every contributor, every translator. Do not make decision for them, they will learn along the way and become a better contributor.
Most of the time, it take much less time to translate based on previous work instead of start from scratch again. At least it the consensus from Chinese team. That's why a bot is created to recover all of the redirected zh-hans pages even when there are a small percent of them should indeed be archived.
--Fengchao (talk) 23:41, 13 December 2022 (UTC)
> Most of the time, it take much less time to translate based on previous work instead of start from scratch again. After redirecting a translated page, its history is of course still there so translators don't have to start from scratch. Is it really so hard to find the previous outdated translation? — Lahwaacz (talk) 06:45, 14 December 2022 (UTC)
The reality is yes, it is indeed hard. Before the Chinese team recover all the pages, I told two translators that there are already an old version that they could base on. They just thought no one ever translate them when they see the page is just a redirection. I myself is confused about the redirection too. I dig into history because I did translated the page years ago. The reality is most new contributors are not familiar with the wiki. Not like us, they know nothing about history, template, category, interlanguage, style. Each one is a little tiny thing for us, but huge obstacles for them. --Fengchao (talk) 14:22, 14 December 2022 (UTC)
My apologies if I redirected pages that were deemed useful to your translation team. I sincerely believe that most of the pages I redirected were not in a state where the offered more value than pointing the reader to the up to date English page, but if I have made some wrong calls, know that it is not as a lack of respect for the hard work every contributor has made to the pages up to that point.
On the example you have chosen, it's not simply that CDemu was out of date, it's also that it was partially translated and not finished since 2012 when I redirected it in 2022-08.
From a quick look at zh-hans:CDemu, the introduction mentions dbus and libmirage, but I do not see those terms used on the English page (it looks like they were removed in 2009). The diff you have linked is similar to the updates the English page has seen since 2013, but the two pages still do not look like each other in the end (e.g. there is still a systemctl command on your page, which is not present in the English page per Help:Style#systemd units operations), and the page is still not fully translated since your update from 2012.
This is very similar to what I'm warning about: you have updated some of the page, but not what was already translated. The end result is a page in a mixed state, where the Template:TranslationStatus shows it should be similar to the English page from 2013 but it's not the case, and it's visibly not up to date either.
I do not see a redirect as removing anything: it's easy to revert in the event that the page can be salvaged. I see no harm done in that action.
It is hard to find. As my reply above, how could a newly contributor knew that he should dig the history and find something useful when the page is a redirection? If follow your logic, I could delete text of all wikis and it is not a deletion, it is no harm to ArchWiki because it is easy to revert? --Fengchao (talk) 14:31, 14 December 2022 (UTC)
Now you're putting words in my mouth: I did not say redirecting everything indiscriminately was without consequence, just that in the case of old/inadequate translations it is not the insurmountable mountain you seem to make it. Yes, digging into history is a part of wiki editing, understanding when and why a change was made on a page is frequently useful, no it is not something that is obvious at first, neither is our template system, neither is following the style rules, neither is MediaWiki formatting, all those things are learned gradually by new contributors, yes we should accompany them along the way, but no we should not keep everything "as is" at all cost if a better solution exists. The wiki does not revolve solely about its contributors, the readers deserve quality content too. As you said elsewhere, it's a delicate balance to find. --Erus Iluvatar (talk) 14:51, 14 December 2022 (UTC)
The "rare possibility" you mention is much more common than you think. Again, I would have to dig through my history to find all the pages where I have seen it happen, but I can promise you it is far from uncommon.
As the quasi-single contributor to the French pages in the last twelve months, I can attest to the fact that very out of date pages are really not faster to update than fully starting from a blank slate. It's too bad that wiki.archlinux.fr is no longer reachable to compare the state of disrepair it was in to what the French pages look like now, and the diffs needed to get there, but you can take my word for it: I've spent many hours on the first pages trying to save what existed before picking up the speed when I changed my way of working and started fresh on all pages.
I'm happy to see your translation team has found a way to revert to a state which fits you more on wiki.archlinuxcn.org --Erus Iluvatar (talk) 08:40, 14 December 2022 (UTC)
For zh-hans:CDemu, then what is the matter here. Does it hurt anyone because the page contain a systemctl command? I leave it here because I thought the English wording ("which contains also a handy cdemu-daemon.service") is not clear and not follow the Help:Style. I do not have enough time right now to fix it and just leave it to someone else. When English page is updated, than Chinese one will follow. I though you still not get my point. zh-hans:CDemu is not perfect, but should we redirect it to English one and remove large trunk of translate work because it is not a perfect translation? --Fengchao (talk) 14:31, 14 December 2022 (UTC)
I did not say it was an issue, I just pointed out that the page you chose as an example of a wrong redirection to English displays the symptoms of rushed editing (which I'm all too often guilty of) and fits right into the warning I'm trying (and I fear, failing) to convey to you: partially updating a translation is setting the future contributor up for failure.
By your reasoning, we could also add a pacman -Syu cdemu-client too, what harm does it do? We have a set of rules to stay coherent in the way we convey information to our readers. If we don't follow our own rules (zh-hans:Help:Style has not removed the guideline about systemctl) how can we ask our contributors to do the same?
Yes, that is exactly what I want to convery. We do not. We should not require a new contributor read Help:Style before contribution. I used to guide some users to Help:Style only after they contribute long enough. For systemctl and pacman command, they are the standard style more than 10 years ago, they are all over the place, no one is harmed by them. Left some junior jobs there make it more to contributors. Maybe use this method, French translation team could attract more contributors. Below is what Chinese translation team told in local chat channel what the different between the two wiki: "In zh-hans wiki, just contribute your knowledge right away, style is much much less important than knowledge here.".
--Fengchao (talk) 02:05, 15 December 2022 (UTC)
So you do not hold yourself to a higher standard than new contributors?! If it was an update made by any small volume translator I would simply fix it after them (as I daily do).
"they are the standard style more than 10 years ago, they are all over the place": I am proud to say that there should be not a single English page in that situation, because I have fixed them every time I've seen them.
I believe in leading by the example, instead of leaving the trash to be picked by newcomers.
The French translation is at its present state because there simply is no one interested in working on it other than me (believe me, I regularly talk about it on our IRC channel), the French community is also much smaller than the English or Chinese one, and all the historical contributors burned out.
Form is not above function, but it should be regarded as an integral part of conveying information: just because we should not judge a book by its cover does not mean it's pointless to make it nice looking.
Edit: you did not address my first point, you got yourself caught by a partially updated page, where the translated content still contains information that was removed in 2009 from the English page.
--Erus Iluvatar (talk) 07:27, 15 December 2022 (UTC)
I completely understand what you mean about perfect being the enemy of good, but sometimes I think we don't hold ourselves to a high enough standard. Leaving a page partially translated for 10 years does not feel right to me, no matter how you want to describe it.
You are right that CDemu is not well enough written though: I've fixed it.
--Erus Iluvatar (talk) 15:18, 14 December 2022 (UTC)
When view a half translated page, I though mostly the already translated part, how it will give help to the user while you thought mostly the untranslated part, not perfect and some sections even contains ugly styles. ArchWiki need both type as long as we do not fight with each other :)
Sorry if you see me as "fighting", I'm just trying to promote the idea that "we can do better" and not wallow in "it's good enough".
Edit: For example, when I see User:Lahwaacz editing with clockwork regularity, tirelessly educating users that made unhelpful edits, always checking over new contributors edits and improving them, it makes me want to be as knowledgeable as he his.
On the opposite side, when I find a neglected translation, I've been fixing them right and left where I can but got discouraged so I limit myself to flagging them (even more so when I do not speak the language at all) so that the translation team hopefully does something. Months pass and nothing gets better.
--Erus Iluvatar (talk) 07:27, 15 December 2022 (UTC)
If I have 100 hours a day, I will do better. After a week There are still more than 200 pages wating for me to check and redirect to zh-hans wiki so I will skip any problems I meet until it is done.
And left some junior jobs for starter is the experience I learn from KDE community. There are many junior jobs in KDE bugzilla that could be fix with very little code. I could never contribute to KDE without such junior bugs. I copy the method here and use it to attract more translators.
The French translation team is like a Cathedral model, its page size is small but every existing page is perfect and clean. The Chinese translation team is like a Bazaar model, it like a mess from an out-sider, some pages are perfect while others are in a very poor state. But as already proven by open source world, sometime Bazaar model will grow much faster. So let's back to the topic by a vote.
--Fengchao (talk) 13:39, 15 December 2022 (UTC)
I feel the need to explicitly point out that I'm not criticizing your hard work, just pointing out that the way we currently handle translations leads to pages staying in a bad state for years (some even a decade).
I had heard of the 15-Minute Bug Initiative from KDE, but I don't think this is applicable here, since we have no central point yet to direct new contributors to easy picks.
It's not only the French translation that focuses on fully translated pages: see the Russian, Polish, Spanish or Portuguese pages.
See Wikipedia:List of languages by number of native speakers#Top languages by population, you have the chance to be in the translation team with the highest number of speakers on earth, and I guess this plays a non-negligible role in the popularity of your translation effort.
Yes, what I want you understand is that some rule you thought and argue about perfect fix a small team, but they will not fix a dynamic community of tens of contributors. It is too dynamic so we have to choose the Bazaar model. --Fengchao (talk) 02:18, 16 December 2022 (UTC)
I get your point, but I disagree on your conclusion. Even in the bazaar model, there are self-imposed rules (e.g. see the kernel coding style for column length). Dynamism does not have to prioritize quantity over quality. --Erus Iluvatar (talk) 07:10, 16 December 2022 (UTC)
There is a rule, or a warning in Chinese translation page("Warning: If you do not intend to translate most of the page, try not to create new Chinese Simplified pages. It takes a lot of effort to check for updates to English pages, and pages without translations add to the maintenance burden. When cleaning up history pages, administrators may change pages that have not been translated for a long time to redirect to English pages."). But I could not force every translator to follow it, or even read them. Give the team size, partital translation is unavoidable. We have to face the reality.
If I can set up a rule, I will create a rule that every contributors only touch the one they most good at. For me it is Chinese & English, for you it is English and French. Giving the same time, this will benefit the wiki most. Sadly, I could not force you to do such things. Then just imaging there are 100 French contributors and everyone have their own opinion. The end result will be a mess.
--Fengchao (talk) 13:33, 16 December 2022 (UTC)
I think it is our role as maintainers/administrators to enforce the rules. When bad pages are created in English, they are dealt with (see Special:Log/delete for example). Why should translations become exempt of this reasoning?
Playing devil's advocate here on your suggested rule: restricting people to only the area they are familiar with hinders them on learning in new areas.
As with every community project, some kind of consensus needs to be reached where the majority decides of the course of action. See the Debian/Devuan split for an example of dissenting opinions leaving a project where they did not feel like their voices were heard. Yet the Debian project lives on and is not a mess as far as I can tell.
--Erus Iluvatar (talk) 14:48, 16 December 2022 (UTC)
this is an live example that a partial translated page attracted a new contributor. Translating some existing text is much easier than start a new page. Most Chinese contributor come from such road: Start from some partial translated sections, then learn Style/Category/Interlanguage link/TranslationStatus much later. That is why partial translation could be seen as bait for new contributors. --Fengchao (talk) 13:10, 21 December 2022 (UTC)
And this is an example of a new contributor creating and fully finishing a translation in two days. I'm happy that you have found a different way to work on translations for your team, but I maintain my disagreement on the method. I'd be tempted to link to Wikipedia:Broken windows theory but the parallel has its flaws. --Erus Iluvatar (talk) 17:41, 21 December 2022 (UTC)
Before casting my vote, I need some clarity on the consequences of each options:
  • Majority of Yes:
  • We allow partial translations, details on how they are handled need to be discussed?
  • We allow partial translations, un-translated sections link to the English section?
Compared with below, it a choice between maintaince and readbility. It will increase another page jump. The most complains I always heard of about ArchWiki is that there are too many subpage jumps. When a new Arch users want to install it through Installaiton guide, they usually need to dig into pages after pages to fully understand what should be done. I myself find it like a maze, especially in partition section. We kill Beginner's Guide to reduce duplication and maintaince burden. How much damage it is done for Arch Linux is another hot topic that I leave for future. But right now I hope to reduce page jump unless necessary.
People always complain about things that are unfamiliar to them (then change of default CSS on the wiki has been an other example). The relatively strict adherence to the DRY principle has allowed us to stay relevant over time by minimizing the maintenance cost of the ever growing number of pages (and from what I can tell, this approach has been discussed at length). You're regularly pointing out our time is limited: I am not OK with voluntarily increasing our maintenance burden for a benefit I do not see. Furthermore, your argument to allow partial translation is that the untranslated parts are not the "hot" part of the page, thus very few readers will be bothered by the additional page to go through. --Erus Iluvatar (talk) 09:06, 16 December 2022 (UTC)
  • We allow partial translations, un-translated sections are copied from the English page at a given date, and can be updated until they get translated?
I like this options most. It increase a little maintaince burden but the reader do not need to jump back and force.
  • Equality:
  • We keep the current rule of giving two years for a translation team to complete a page?
  • Majority of No:
  • We strictly forbid any partial translation in the main namespace, ongoing translations need to be in the user namespace or on a sub-page of the translation team's page?
I would also like to know who you expect to be voting on this? Only maintainers and admins, other translation team members?
Everyone could give their vote here.
Thank you again for the time you have taken for our exchange. --Erus Iluvatar (talk) 19:15, 15 December 2022 (UTC)

Should a partial translation be allowed in ArchWiki, please give your vote and comment:

  • Yes
    • Yes, and a maintainer could swap out-of-date translations into English direrctly. But non out-of-date translations shoud be kept. --Fengchao (talk) 13:39, 15 December 2022 (UTC)
    • Yes, and a maintainer could link out-of-date sections into English page.
  • No
    • No - Move them to user namespace
    • No - Move them to sub-page of the translation team

I vote for this last option, hoping it does not hinder collaboration, while keeping the main namespace from accumulating out of date content when translations stall. --Erus Iluvatar (talk) 14:53, 16 December 2022 (UTC)

I vote to maintain the status-quo. In practice, old partial translations neither update their translations nor their English content, so this becomes a maintanence burden for the regular maintenance team as well. It's hard to tell how useful measures like moving old pages to sub-pages of the translation team are, since most translation teams haven't engaged in this discussion. And the team requesting to make changes to the existing wiki rules has already left the wiki for an external domain. -- Alad (talk) 16:31, 16 December 2022 (UTC)

As I said in the begining, for such pages, a maintainer could just stop keeping it up-to-date if he could not read the content. Or he could just swap or link the out of date sections into English. But for already translated part, especially hot sections like Installations and Configurations should be kept. I am totally fine that an out of date sections are removed. But currently, I see some translations are cempletely removed just because some sections are not in sync with English. Compared with the Installation, the out of date sections are far from important. --Fengchao (talk) 03:13, 17 December 2022 (UTC)

Replace PNG images with SVG

Special:ListFiles lists many PNG files from the Tango icon set. Since there are SVG versions in commons:Tango icons, I think we should use those. They will look better on higher DPI screens. -- nl6720 (talk) 14:25, 30 December 2022 (UTC)

When User:Lahwaacz tried to upload SVG format histograms, we discovered that it's not that simple.
For it to work, we need mw:Extension:NativeSvgHandler and $wgFileExtensions[] = 'svg'; in LocalSettings.php.
I created https://github.com/archlinux/archwiki/pull/65 to add the extension.
-- nl6720 (talk) 14:15, 2 January 2023 (UTC)
To increase the fun, Extension:DarkMode sets SVG image background to white. .client-darkmode #mw-content-text .image img[src*='svg'] { background-color:#090603; } can be added to MediaWiki:Common.css as a workaround. -- nl6720 (talk) 14:21, 2 January 2023 (UTC)

Dealing with deceased users

As you might already know, User:Jonathon has sadly passed away. See https://lists.archlinux.org/archives/list/aur-general@lists.archlinux.org/thread/UA6NYEGLXKTDW6PE22E3EJTGB27O46XR/

My proposal is, I already reached out to his brother and he would be fine with that, is to create a userpage for him which reads something like "This user has passed away and his contributions will never be forgotten.", signed by the maintenance team and fully protected. Same for the talk page maybe? Additionally also block the user because unfortunately the account will never be used again, but wikipedia does not do that for example: Wikipedia:Deceased Wikipedians

-- NetSysFire (talk) 11:15, 11 January 2023 (UTC)

I don't see a need to protect his user page or block the account. And I'm quite sure we don't want a policy for these kind of situations, the less bureaucracy the better. -- nl6720 (talk) 15:45, 11 January 2023 (UTC)
Since the news item is out, how about linking to it from his user page? -- nl6720 (talk) 12:42, 13 January 2023 (UTC)
This seems both appropriate, and a nice gesture. Jasonwryan (talk) 22:44, 19 January 2023 (UTC)
This seems like a good idea... At least there is something to commemorate the efforts the users have put into the ArchWiki/AUR/Arch Repositories/Arch Development
Side question, is this the first TU which has died? because there is no existing measure to do when a member passes away?
PolarianDev (talk) 12:46, 7 February 2023 (UTC)

Improving the default MediaWiki "page changed" template

Currently, the "page you're following has been changed" emails use the default formatting. I believe this can be seen here and looking at `enotif_body`.

Current template results in this email.

My suggested template would look something more like this.

My suggestion could probably use some changes if this is to be actually done, I put it together quickly just to show what massive improvements can be gotten.

I brought this up on #archlinux-wiki initially, and it was pointed out to me that this would be somewhat of a large undertaking due to this change needing to be applied for all the translations. I can help with the Czech one if this change is desired.

C0rn3j (talk) 09:24, 5 July 2023 (UTC)

Enable the Thanks extension

After 1.40 MediaWiki will bundle Extension:Thanks.

Can we enable it once we've updated ?

It would allow for a faster and less convoluted way to express gratitude for an edit than adding a message to the user's talk page.

--Erus Iluvatar (talk) 05:49, 10 July 2023 (UTC)

This sounds like a good way to strengthen the community! IMO if it turns out to be problematic we can still disable it again :)
-- Gromit (talk) 10:07, 10 July 2023 (UTC)
I support this. Recognizing contributions from new users, especially those which are high-quality, is a valuable part of the process of onboarding and retaining editors. With the straightforward tone of edit summaries, there's no convention to show gratitude without a pertinent discussion. In cases like Special:PermanentLink/768009#re: SSH keys and Special:PermanentLink/758060#Listen, this would have been useful for preemptively communicating our intent. -- CodingKoopa (talk) 04:16, 13 July 2023 (UTC)

Enable the DiscussionTools extension

When preparing the merge request for MediaWiki 1.40 it was noted on IRC that it also ships Extension:DiscussionTools. Some people were in favor of adding it, but it was noted that this should still be discussed here so people not on IRC could voice their opinions aswell!

I am very much in favor of adding it after testing it for a bit.

-- Gromit (talk) 11:44, 2 August 2023 (UTC)

What do we gain by enabling this extension? -- nl6720 (talk) 12:15, 2 August 2023 (UTC)
The extension allows for a better workflow when discussing changes on talk pages, especially that one can directly reply to already given answers and the text is then indented on the right level. If you want to take a look here is a screenshot from my test instance:
Smaller features include a live preview of the rendered answer, automatically setting the signature & edit summary and the possibility to also use the WYSIWYG editor.
-- Gromit (talk) 17:08, 2 August 2023 (UTC)
+1 from me if it means we don't waste our time with Template:Unsigned --Erus Iluvatar (talk) 14:53, 2 August 2023 (UTC)
Retrieved from "https://wiki.archlinux.org/index.php?title=ArchWiki_talk:Maintenance_Team&oldid=786356"