Community Wishlist Survey 2022/Miscellaneous

39 proposals, 391 contributors, 1169 support votes
The survey has closed. Thanks for your participation :)

Be able to find the largest edits of a user on XTools

  • Problem: I would like to know which of my edits have added the most amount of bytes. I don't mean the pages I have lots of edits on, I mean which single edits have added the most content. However this option is not available in XTools or Wikistats.
  • Proposed solution: Add a new tool to XTools that lists a users edits by their diff size.
  • Who would benefit: People who want to know statistics about their largest edits.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dunutubble (talk) 16:35, 13 January 2022 (UTC)



Add "yearly" as an optional date type to the Pageviews Analysis

  • Problem: When analysing pageviews with toolforge:pageviews, it is possible to quantize the data by day or by month. As our projects are getting older, a quantization by year becomes increasingly interesting.
  • Proposed solution: Add "yearly" as an optional date type.
  • Who would benefit: People who like to study pageviews.
  • More comments:
  • Phabricator tickets:
  • Proposer: Nachtbold (talk) 20:43, 17 January 2022 (UTC)


  • Developer note: We should aim to get yearly granularity added to the underlying pageviews API, but if all else fails we can still simulate a yearly date type in Pageviews Analysis. MusikAnimal (WMF) (talk) 03:01, 19 January 2022 (UTC)


Centralization of interwiki links

  • Problem: The project and language for interwiki links are currently specified separately. If you want to link to a location where both the language and project are different, or if you want to link to somewhere other than Wikipedia from a multilingual project (Meta, Commons, etc.), you need to go through the Wikipedia of that language or the English version of that project. That results in the creation of an unused account for the intermediary project, leaving extra logs and making the unified login information more confusing.

    For example, if you want to link to the Japanese Wikivoyage (ja.wikivoyage), you currently need to write ja:voy: or voy:ja:, which makes you go through the Japanese Wikipedia or the English Wikivoyage.

  • Proposed solution: Simplify interwiki links by removing the redirects so that it is a single link, such as [[ja-voy:]] (or, alternatively, "javoy").
  • Who would benefit: Mainly people whose mother tongue is the language of a different version, and people who often use multilingual projects such as Commons.
  • More comments:
  • Phabricator tickets:
  • Proposer: Mario1257 (talk) 16:16, 17 January 2022 (UTC)


  • @Mario1257:
    en: Are you aware of wikidata:Special:MyLanguage/Help:Sitelinks? The idea is to add all interwiki links on the Wikidata item itself. You only need to go to one page (the item page on Wikidata), then add the links one by one. This avoids the account creation problem you speak of, too. For example, see wikidata:Q60 on New York City. At wikidata:Q60#sitelinks-wikivoyage you can view and edit all the links to the different Wikivoyage projects. Does this work for you? You shouldn't need to write ja:voy: or anything similar on each language edition. Add the sitelinks only on Wikidata.
    日本: ウィキデータ サイトリンク を知っていますか? アイデアは、ウィキデータアイテム自体にすべてのインターウィキリンクを追加することです。 1つのページ(ウィキデータのアイテムページ)に移動し、リンクを1つずつ追加するだけです。 これにより、あなたが話すアカウント作成の問題も回避されます。 たとえば、ニューヨーク市の Wikidata:Q60 を参照してください。 wikidata:Q60#sitelinks-wikivoyageでは、さまざまなWikivoyageプロジェクトへのすべてのリンクを表示および編集できます。 これはあなたのために働きますか? 各言語版でja:voy:などを書く必要はありません。 ウィキデータにのみサイトリンクを追加します。 MusikAnimal (WMF) (talk) 19:01, 21 January 2022 (UTC)
    • @MusikAnimal (WMF): Thank you comment. The explanation was a shortage, so been maked misunderstanding this explanation. I add that when a link in the text (it's not wikilinks of sidebar), this problem is the occurs.--Mario1257 (talk) 17:58, 22 January 2022 (UTC)
      I understand now! Thanks for the follow-up. I'm going to get this proposal moved into the survey so it can be voted on. Regards, MusikAnimal (WMF) (talk) 22:41, 25 January 2022 (UTC)
  • Ohh, I'd never noticed that! So the idea is
Where the current situation is
I'm more likely to visit w:lang than say s:lang, so the extra login history doesn't affect me personally.
Pelagic (talk) 21:05, 28 January 2022 (UTC)
  • Comment Comment Can't the function of this idea be replaced by In other projects on the left? --Liuxinyu970226 (talk) 11:27, 29 January 2022 (UTC)
  • The Interwikimap would need to be expanded massively to achieve this. C933103 (talk) 15:02, 6 February 2022 (UTC)


  • Support Support I faced a related problem. For example, when jumping from the Korean Wikipedia to the Japanese Wikivoyage, if I write ":voy:ja:", it goes to Incubator, because Korean Wikivoyage is still in the test phase. This suggestion will solve that problem. --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:47, 29 January 2022 (UTC)
    This is not in the scope of this page. Thingofme (talk) 01:51, 31 January 2022 (UTC)
  • Support Support Lt2818 (talk) 06:44, 29 January 2022 (UTC)
  • Support Support Less problem with interwiki links and no wrong links. But we have to fix articles which have the interwiki prefix Thingofme (talk) 01:51, 31 January 2022 (UTC)
  • Support Support Glerium (talk) 12:34, 1 February 2022 (UTC)
  • Support Support Yes, but no new prefix styles needed. Wargo (talk) 23:29, 1 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
  • Support Support --Dipsacus fullonum (talk) 11:48, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:23, 6 February 2022 (UTC)
  • Support Support Zache (talk) 08:32, 7 February 2022 (UTC)

add MW messages to content pages

  • Problem: Allow displaying automatic stuff on content pages via MediaWiki messages (notices, user warnings, auto categorization, ...)
  • Proposed solution: Talk pages have specific MediaWiki messages (MediaWiki:Editnotice-NS_number-article_name and MediaWiki:Editnotice-NS_number) that can be modified to show specific content on each talk page. I propose adding a similar option to content namespaces.
  • Who would benefit: all editors
  • More comments: It could be used to show instructions for new Draft pages automatically, to categorize all kinds of content automatically (drafts, documentation subpages, articles whose name begins a certain way), to show protection templates automatically, show messages at the top of user pages, etc.
  • Phabricator tickets: phab:T151682
  • Proposer: —Ivi104 02:42, 11 January 2022 (UTC)


  • I do not understand this proposal. Maybe an example would help. · · · Peter (Southwood) (talk): 07:23, 11 January 2022 (UTC)
    @Pbsouthwood: When editing an article, there is no way to display a notice to say there is a draft page of the same name outside of manually including a template or module into every single page to check if a draft page exists. Similarly, when editing an existing draft, there is no way to display instructions or categorize the draft outside of adding a template to the top of every draft page. If a new editor makes a draft without a template, the draft is lost in the depths of the project until someone manually notices it and adds the template.
    I propose adding a MediaWiki system message to the top of content pages. Inside, we could check if the current page is in the draft namespace, and if so, show appropriate instructions, categorize the page automatically, and so forth.
    This feature exists when editing pages (MediaWiki:Editnotice-NS_number-article_name and MediaWiki:Editnotice-NS_number) and talk pages have their own system messages (MediaWiki:Talkpageheader and MediaWiki:Talkpagetext). I propose a new system message be added to the top of existing content pages. I hope this explanation conveys my idea. —Ivi104 01:16, 12 January 2022 (UTC)
    Would this system message just display automatically/bot generated information? · · · Peter (Southwood) (talk): 04:38, 12 January 2022 (UTC)

This seems to be an en.wp-only implementation which at first glance works for NS 0 (articles) as well. See en:Wikipedia:Editnotice for details. Improvements should probably be requested there.--Strainu (talk) 07:58, 12 January 2022 (UTC)

If you means edit notice in edit mode, see phab:T201613.--GZWDer (talk) 22:01, 12 January 2022 (UTC)
  • @Ivi104: are you wanting to have a per namespace site-notice (something that is displayed to readers)? If so, that is phab:T6469. (Though it seams you want a per-page-sitenotice ??) — xaosflux Talk 19:44, 14 January 2022 (UTC)
    @Xaosflux: Yes, that is what I would like, a sitenotice that is displayed to readers. I was thinking of one notice, and parser functions could be used to display different content in different namespaces, but this idea of a separate notice for each namespace works well too. —Ivi104 22:22, 14 January 2022 (UTC)
    So you want what we currently have for editnotices, but for all content. I think that is difficult because unlike edit pages, content is cached. So if anything changes about the 'calculation' (say a draft is created or deleted) it will take a LONG time for any notice to update. —TheDJ (talkcontribs) 15:07, 16 January 2022 (UTC)


  • Support Support Shizhao (talk) 03:51, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:48, 29 January 2022 (UTC)
  • Support Support We should create editnotices as a template and have it in default. Thingofme (talk) 01:47, 31 January 2022 (UTC)
  • Support Support Novak Watchmen (talk) 17:20, 31 January 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 07:25, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:34, 6 February 2022 (UTC)

Include section links in WhatLinksHere

  • Problem: When section names are updated in an article, it's difficult to find which articles link there, making it much more difficult to update broken section links.
  • Proposed solution: When caching Special:WhatLinksHere, add which section (if any) they link to. It would also then be possible to automatically generate a list of articles with links to sections that no longer exist.
  • Who would benefit: Editors trying to find broken section links, and so readers who will be redirected to broken sections links less frequently.
  • More comments:
  • Phabricator tickets: phab:T18561
  • Proposer: --YodinT 19:49, 18 January 2022 (UTC)


I usually use insource: search for this task. It lets me find any specific string of interest in the wiki-source. DMacks (talk) 09:51, 19 January 2022 (UTC)
That works, but only if you know previous section names. I guess there are many thousand links to non existant sections in articles that aren't being watched by an editor. This would let a new editor find all of these with one click (otherwise they would have to go through the page history to find all previous section names, and this wouldn't catch any section name typos in links either). It could also easily compile a list of all the broken sections links that are in the mainspace, in case any editors wanted to work through and fix some of them. --YodinT 11:18, 19 January 2022 (UTC)
I mis-read the proposal as targetted at the editor who is changing the section-name (to fix the inbound links themself at that time) rather than to catch broken links afterwards. I agree that some tools for finding and fixing inbound links to sections that don't exist would be useful. I think enwiki has some tool or bot, will look... DMacks (talk) 11:26, 19 January 2022 (UTC)
  • I support this, although I think it might be even better if section links were given a section of their own in the list.--YTRK (talk) 12:12, 22 January 2022 (UTC)
    • Having this, or some way to sort by section/anchor link would definitely help. --YodinT 20:55, 28 January 2022 (UTC)
  • Ideally this solution would extend to {{anchor}}s, not just section links. Danbloch (talk) 19:42, 28 January 2022 (UTC)
    • Completely agree. --YodinT 20:55, 28 January 2022 (UTC)
    They (as well as anchors that do not actually exist in the article) are handled/displayed the same by WhatLinksHere anyway, so I doubt there would be a problem with that. ~~~~
    User:1234qwer1234qwer4 (talk)
    21:42, 8 February 2022 (UTC)
  • I don't know if this holds true for all Wikipedias, but at least in the English Wikipedia, WhatLinksHere shows the target anchor/section of redirects in the list as
<page name> (redirect to section "<anchor>")
since perhaps two or three years ago.
However it does this only for redirects. I guess this is down to the fact that there can be only one such link in a redirect, but there could be many links pointing to the same page in an article and they do not necessarily all point to the same target anchor/section. Also, parsing a redirect for such target anchors is quickly done, but searching a whole article for them is an expensive operation (when done on demand and without caching). If there are multiple links from a page to the target page, but to different anchors in that page, WhatLinksHere could (group and) list them in separate lines like:
<page name> (link to section "<anchor>")
Since this is an expensive operation I think there should be a selection box in the header of WhatLinksHere to activate the feature only when it's actually needed.
It would also be great, if WhatLinksHere would actually check if a target anchor/section name exists on the target page, and display modified messages instead:
<page name> (redirect to non-existing section "<anchor>")
<page name> (link to non-existing section "<anchor>")
Given, that parsing the target article is an expensive operation as well, there should be a check box to enable this feature on demand only.
If the target article gets parsed for the anchors/section names already, the messages could actually distinguish between anchors and section names in the resulting messages like:
<page name> (redirect to section "<anchor>")
<page name> (link to section "<anchor>")
<page name> (redirect to anchor "<anchor>")
<page name> (link to anchor "<anchor>")
<page name> (redirect to non-existing section/anchor "<anchor>")
<page name> (link to non-existing section/anchor "<anchor>")
And finally a remark: Fixing broken anchor names is fine by either editing the source or the target, but it should be communicated to over-ambitious editors that blindly removing them is not. A link to a non-existing anchor does no "harm" by itself, it is perfectly valid HTML etc., the browser will just set the focus to the top of the page. There are often groups of links from articles and redirects pointing to the same anchor in a target article, and even if it does not exists, it still carries useful semantic information on which specific content is missing in an article, which of the incoming redirects are synonyms or at least semantically closely related, and which source links need to be updated in other articles and redirects when the missing contents get added/moved somewhere. This semantic infrastructure info is useful for article maintenance and reverse lookup, and by blindly deleting dangling anchor fragments, this information would get lost.
Thinking about it, it might even be useful to have an option in WhatLinksHere to sort the resulting list entries by anchor names (regardless if they exist in the target page or not), so that incoming links pointing to the same anchor can be grouped.
--Matthiaspaul (talk) 21:28, 29 January 2022 (UTC)
What would be the technical/syntactical difference between a non-existent section and a non-existent anchor? ~~~~
User:1234qwer1234qwer4 (talk)
21:43, 8 February 2022 (UTC)
Sorry for the late reply, seeing this only now... That's a good point, as they are non-existing, they can't be distinguished. I have updated the suggested list above accordingly.
--Matthiaspaul (talk) 02:53, 28 February 2022 (UTC)
  • I agree with your points about redirects, and links to more than one anchor/section from one page. Grouping by anchor names would tie well into the suggestion by YTRK above. --YodinT 00:42, 11 February 2022 (UTC)
  • Let me point you to a discussion in German Wikivoyage where we discussed broken links to anchors. In de-wv we're using excessively a template that as a side effect creates an anchor for the item. The known problems for sections apply here too. A fix would be a big help for the project. --4omni (talk) 13:24, 30 January 2022 (UTC)
    • Good example! Even if this proposal doesn't make it this year, I'm hoping that there's a chance that it (and sorting alphabetically, etc.) might be still included if WhatLinksHere is overhauled. --YodinT 00:42, 11 February 2022 (UTC)


  • Support Support * Pppery * it has begun 18:43, 28 January 2022 (UTC)
  • Support Support Danbloch (talk) 19:43, 28 January 2022 (UTC)
  • Support Support for anchors, not only sections --Andyrom75 (talk) 20:19, 28 January 2022 (UTC)
  • Support Support — Draceane talkcontrib. 21:38, 28 January 2022 (UTC)
  • Support Support Izno (talk) 23:27, 28 January 2022 (UTC)
  • Support Support Broken section links are absolutely a problem, since bots fixing them haven't always been operational. This would help. {{u|Sdkb}}talk 00:23, 29 January 2022 (UTC)
  • Support Support Dexxor (talk) 12:47, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:38, 29 January 2022 (UTC)
  • Support SupportBruce1eetalk 14:13, 29 January 2022 (UTC)
  • Support Support Good idea. — Jules* Talk 18:29, 29 January 2022 (UTC)
  • Support Support With all the related extensions proposed in the discussion above. --Matthiaspaul (talk) 21:29, 29 January 2022 (UTC)
  • Support Support Including anchors/fragments, not just sections. Nw520 (talk) 23:44, 29 January 2022 (UTC)
  • Support Support czar 23:54, 29 January 2022 (UTC)
  • Support Support SD0001 (talk) 03:47, 30 January 2022 (UTC)
  • Support Support YTRK (talk) 07:46, 30 January 2022 (UTC)
  • Support Support --4omni (talk) 13:24, 30 January 2022 (UTC)
  • Support Support Wotheina (talk) 15:40, 30 January 2022 (UTC)
  • Support Support DerFussi 15:44, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 22:10, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:46, 31 January 2022 (UTC)
  • Support Support It's good for archiving talk pages, as we can link section links (however, we can't do that in edit summaries) Thingofme (talk) 01:48, 31 January 2022 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 14:42, 31 January 2022 (UTC)
  • Support Support Havang(nl) (talk) 16:11, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 20:44, 31 January 2022 (UTC)
  • Support Support Trey314159 (talk) 22:50, 31 January 2022 (UTC)
  • Support Support -- Ahecht (TALK
    ) 21:36, 1 February 2022 (UTC)
  • Support Support Daniel Case (talk) 22:42, 1 February 2022 (UTC)
  • Support Support ~ Amory (utc) 20:47, 2 February 2022 (UTC)
  • Support Support Uanfala (talk) 21:53, 2 February 2022 (UTC)
  • Support Support YBG (talk) 07:17, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 15:44, 3 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 19:22, 4 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 05:49, 5 February 2022 (UTC)
  • Support SupportKPFC💬 11:35, 5 February 2022 (UTC)
  • Support Support Ealdgyth (talk) 17:27, 5 February 2022 (UTC)
  • Support SupportThanks for the fish! talkcontrib (he/him) 21:39, 5 February 2022 (UTC)
  • Support Support Waldyrious (talk) 00:10, 6 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:34, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 07:15, 6 February 2022 (UTC)
  • Support Support Emaus (talk) 08:27, 6 February 2022 (UTC)
  • Support Support Voice of Clam (talk) 10:40, 6 February 2022 (UTC)
  • Support Support C933103 (talk) 15:10, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 21:35, 6 February 2022 (UTC)
  • Support Support --Achim55 (talk) 09:02, 8 February 2022 (UTC)
  • Support Support ~~~~
    User:1234qwer1234qwer4 (talk)
    21:40, 8 February 2022 (UTC)
  • Support Support Rots61 (talk) 22:08, 8 February 2022 (UTC)
  • Support Support Gaurav (talk) 06:38, 11 February 2022 (UTC)

Improve plain-text change tag selector

  • Problem: The plain-text tag selector (on Special:Contributions, Special:Log and some other special pages or views) is not very user friendly. You need to remember the internal tag name, which for localized tag is different from the name you are used to seeing (imagine: is it mw-revert or mw-reverted? 🤔). There are more and more supported tags added every month.
  • Proposed solution: Implement the selector as a drop-down menu or add suggestions as you type.
  • Who would benefit: Power users, admins, etc.
  • More comments: The best experience is offered in Special:RecentChanges et co.
  • Phabricator tickets: phab:T27909, phab:T23383
  • Proposer: Matěj Suchánek (talk) 10:42, 17 January 2022 (UTC)



Add an option to switch between user accounts

  • Problem: If you are working with more accounts, there is no simple way to switch between your accounts without logging out and logging in with other credentials.
  • Proposed solution: Add an option to log in to more than one account at one moment. By clicking on your user name, you should be able to switch to another account. I think that this should be restricted to only few accounts (max. 5 [?]). The security aspects should be taken into concern.
  • Who would benefit: users with multiple accounts (bot accounts, test accounts, WMF/WMXY accounts, employee accounts...)
  • More comments: The actual workaround is to have more instances of the web browser (or more browsers, e.g. one account in G Chrome, other in Mozilla Firefox). I perceive the opportunity of switching the accounts as a standard feature in 2020s.
  • Phabricator tickets:
  • Proposer: — Draceane talkcontrib. 19:55, 15 January 2022 (UTC)


  • I personally have 3 accounts: my primary account for the majority of the Wikimedia work, the second one is a bot account – I use AWB for bot edits, but I also use the bots account in the web browser for the category-related tasks (Cat-a-lot); the 3rd account is dedicated to mass imports of files of the third parties to Commons. — Draceane talkcontrib. 19:55, 15 January 2022 (UTC)
  • See also: phab:T16409--GZWDer (talk) 07:14, 16 January 2022 (UTC)
  • Yes, please. Whe I have 2FA enabled and use my account on more devices, it is pain to login again. Current workaround is using different browser, but there are some browser specific (eg. Vivaldi tiled tabs) and I sometimes want to use specific browser with specific account. JAn Dudík (talk) 12:29, 17 January 2022 (UTC)
  • Neutral Neutral I have 2 accounts. Generally I work with 2 browsers open (Windows and Firefox) and I'm logged in with both browsers as different user. No problems. Taivo (talk) 20:09, 28 January 2022 (UTC)
  • Firefox Containers does exactly this. Just set up a container per account. The tabs are even colour coded, and you can open any link in a specific other container (the effect being to open that link as another account). Inductiveload (talk) 23:32, 28 January 2022 (UTC)
  • I think this would be nice, but one downside to weigh is that it'd make socking a lot more convenient. {{u|Sdkb}}talk 00:20, 29 January 2022 (UTC)
    • @Sdkb: I understand this concern; the tool might be restricted to trusted users only, or the user should make the switched accounts public (or the switch could be logged.) — Draceane talkcontrib. 18:03, 29 January 2022 (UTC)
  • @Wostr, Agus Damanik, and Dreamy Jazz: I'll be glad, if you bring at least some feedback on the proposal... — Draceane talkcontrib. 16:03, 31 January 2022 (UTC)


  • Support Support --Matěj Suchánek (talk) 19:48, 28 January 2022 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 08:20, 29 January 2022 (UTC)
  • Neutral Neutral – can be abusable and can increase sockpuppetry. – Aca (talk) 13:40, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 13:54, 29 January 2022 (UTC)
  • Oppose Oppose Wostr (talk) 19:47, 29 January 2022 (UTC)
  • Oppose Oppose I think it's just lead to a bigger possibility of sockpuppetry Agus Damanik (talk) 14:43, 9 February 2022 (UTC)
  • Oppose Oppose --𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 09:45, 30 January 2022 (UTC)
  • Support Support Jmaxx37 (talk) 18:39, 30 January 2022 (UTC)
  • Oppose Oppose For bot accounts, but there are concerns about sockpuppetry. Many vandals have a lot of accounts, and for Toolforge bots, they don't need to login much. Thingofme (talk) 01:41, 31 January 2022 (UTC)
  • Oppose Oppose Dreamy Jazz talk to me | enwiki 14:49, 31 January 2022 (UTC)
    • Since I was pinged here to provide rationale, I agree with the issues presented around sockpuppetry plus the ways presented for legitimate users to get around this via multiple browsers etc. seems like the easier option than the large amount of developer time that would be spent on making this possible. Dreamy Jazz talk to me | enwiki 02:08, 1 February 2022 (UTC)
  • Oppose Oppose --Havang(nl) (talk) 16:20, 31 January 2022 (UTC)
  • Support Support It might be only for some group of users. It can be granted by admin, it can be only for eg. rollbackers etc.BUt yes, please JAn Dudík (talk) 20:56, 31 January 2022 (UTC)
  • Oppose Oppose Would seem to be a built in sockpuppetry promotion. IAmChaos (talk) 21:30, 31 January 2022 (UTC)
  • Oppose Oppose Per others, could support if only available for users of bot accounts, and then only with explicit permission to do this. Daniel Case (talk) 22:53, 1 February 2022 (UTC)
  • Oppose Oppose Ayumu Ozaki (talk) 07:37, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:40, 6 February 2022 (UTC)
  • Oppose Oppose Legitimate users already know how to work with this. The feature enhances Sockpuppetry — DaxServer (t · c) 21:00, 6 February 2022 (UTC)
  • Oppose Oppose It encourages sockpuppetry. It's not a problem to use multiple accounts with Chrome profiles or alternatively using an incognito window or multiple browsers. Grillofrances (talk) 05:51, 7 February 2022 (UTC)
  • Neutral Neutral --Bikepunk2 (talk) 21:54, 7 February 2022 (UTC)
  • Oppose Oppose not for everyone. Prawdziwy Mikołajek (talk) 17:55, 9 February 2022 (UTC)
  • Support Support Absolutely. More generally, Mediawiki should store data about linked accounts, to formalize acceptable "alternate accounts" and distinguish between them and prohibited sockpuppets. Yair rand (talk) 00:29, 11 February 2022 (UTC)
  • Oppose Oppose DSparrow14 (talk) 17:09, 11 February 2022 (UTC)

Automatically log in to all projects if you are logged in to one

  • Problem: Now I have to log in seperately at all projects (like the Wikpedias, Wikibooks, Wikidata), even if I am logged in to Commons, though the inlog codes are the same for all projects. Sometimes I forget it and then my edits are registered on my IP adress. Going from any project where I am logged in to Commons, I am automatically logged in to Commons, so it is possible.
  • Proposed solution: Automatically log in to all projects if you are logged in to one, no matter which one, like now in Commons.
  • Who would benefit: All editors who regulary switch from one project to another to make changes/edits.
  • More comments:
  • Phabricator tickets: phab:T217519, phab:T226797
  • Proposer: JopkeB (talk) 05:57, 11 January 2022 (UTC)


  • Isn't this supposed to be default already? · · · Peter (Southwood) (talk): 08:44, 11 January 2022 (UTC)
    If it is, it certainly doesn’t work for me? Jcshy (talk) 08:47, 11 January 2022 (UTC)
    It didn’t work just now for me, logged in to but not here. -- TheInternetGnome (talk) 10:19, 11 January 2022 (UTC)
    Same here, which is why I submitted a different proposal that is apparently a subset of this one. RSLitman (talk) 19:58, 11 January 2022 (UTC)
    It is, but the CentralAuth extension responsible for the the global account system hasn't been properly maintained in years. I suspect automatic cross-wiki login broke after some browser privacy change (see for example phab:T257853). Majavah (talk!) 06:56, 12 January 2022 (UTC)
    Yes this stopped working years ago. First on Safari, then on Firefox and since a years or two on Chrome and Edge. —TheDJ (talkcontribs) 12:09, 12 January 2022 (UTC)
    I think it is like a browser problem; and I don't see any problems with unified login. Some tools to patrol cross-wiki needs to have a global account. Thingofme (talk) 03:24, 16 January 2022 (UTC)
  • Added an phab ticket.--Snævar (talk) 08:53, 11 January 2022 (UTC)
  • Agreed. Don't know why this isn't the default already. BetweenCupsOfTea (talk)
  • Comment. Please, make this togglable in the preferences ("Disable/enable the unified login" or something like that), so that you can easily use different usernames on different wikis (for example, the username "EnglishWikipedian321" on en-wiki and the username "ItalianWikipedian123" on it-wiki). Having to log out and in constantly between those two accounts in order to edit both wikis at the same time is a pain in the... 11:56, 13 January 2022 (UTC)
    User accounts are global so there's no reason to have a different account on each wiki. You can use another browser then. Stryn (talk) 15:08, 13 January 2022 (UTC)
    Thanks but I'm aware. Here are some reasons I can think of why it's important to implement the togglability:
    • 1) Better privacy
      • Maybe you are very open of who you are on your userpage in another wiki, but you would like to stay as anonymous as possible on another wiki you edit for whatever reason. E.g., you can be pretty open about your political views, sexuality or gender etc. on many wikis, but, sadly, that's not the case on every wiki (not going to name any specific wiki here, but there are language editions whose some users are not used to the same level of liberty of any developed country). Thus, you would be prone to harassment either on wiki, social media or maybe even IRL.
    • 2) Better security
      • When you edit any language edition that could possibly lead you to problems with authorities of specific countries (again, not going to name any specific country, but you probably know at least one authoritarian country with very limited freedom of speech). There's always a risk of this happening. Your less-anonymous other wiki identities would only be clear to users that have a cross-wiki IP check tool or something like that, so it wouldn't be 100% risk-free but still.
    • 3) Personal preference and accessibility
      • When you, e.g., want to use a Latin-script username ("User:John Doe") in a Latin-script wiki, and a Chinese-script username ("User:雨果奖等") in the Chinese-language wiki. This would also make others in that wiki feel you're more approachable when, in their eyes, your username is not in a foreign script. It would be easier to remember someone's username in order to find their userpage to contact or ping them. I personally find it very hard to remember and write usernames like "User:بالتاريخ", "User:дюжин листов" or "User:ギリシャ経済危" compared to a username like "User:John Doe".
    • 4) Username means something else in another language
      • Maybe your username happens to be a name of a large company in some other country? Or a profanity in that wiki's language perhaps? And when something like that gets your username banned from editing that wiki due to that wiki's username policies, you would have to register another username there, and then you would have to use different browsers to edit those two wikis at the same time. I'd imagine there already are some cases like this.
    • 5) No more cross-wiki alerts or emails
      • When you visit another wiki for whatever reason while logged in and your account gets automatically registered there, you're prone to get spammy alerts and emails later on when, e.g., bots leave foreign-language messages to your user talk page on wikis that are foreign to you, i.e. those that you never edit. Sometimes they also like to send you foreign-language emails that you don't wish to receive.
    • 6) It wouldn't be against any policy(?)
      • Well, maybe someone else knows better, but I believe it's not. And I don't think implementing this would cause any cross-wiki abuse--at least I can't think of any possibilities this would open to vandals and such.
    I can't think of any good reasons to not implement this for us who want this waterproof togglable option to opt-out from cross-wiki logins easily. "Use different browsers" = you're prone to make a human error all the time. Also, using a different browser that you're used to is very inconvenient. 20:02, 5 February 2022 (UTC)
  • It somehwat works, but there are many bugs. E.g. T257853, T257852, T256525, T257803. --Tgr (talk) 02:33, 30 January 2022 (UTC)


Allow Users to Add Their Own Personal Notes to a Page

  • Problem: I will discuss this with respect to Wikipedia, but it applies to most Wikimedia projects.

    If I am logged in and I want to add a comment or a list of notes to an entry, it would be good to be able to. The notes would only be readable to me or anyone logged into my login. Think of this as something like the notes page at the back of a reference book.

    The implementation would be relatively simple and with reasonable limits on what could be placed in the notes, the storage overhead should not be a problem based on 2022 storage standards.

    I made this proposal directly to S. Sastry at Wikimedia a couple of years ago, but I believe it was lost in the noise at that time. This is a better place for it.

  • Proposed solution:
  • Who would benefit: Everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Bezenek (talk) 22:26, 20 January 2022 (UTC)


  • There are multiple browser extensions that provide this functionality already (and apparently Edge can do this natively). Why should the tech team spend time on this? --Izno (talk) 05:47, 21 January 2022 (UTC)
    Because this functionality would not depend on specific browser or computer. Many wikipedians have their comments in their user space, but this is not very comfortable workaround. Riha (talk) 13:33, 30 January 2022 (UTC)
  • You can use w:en:User:Bradv/Scripts/Notepad.js for this – which stores notes persistently and can be accessed across different computers. Best, KevinL (aka L235 · t) 20:54, 30 January 2022 (UTC)
  • de:benutzer:Schnark/js/notizen allows for by-page personal notes and alerts, but should be changed to use mw.user.options rather than the browser's localStorage for the suggested cross-browser functionality. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:40, 9 February 2022 (UTC)


Eye icon when creating an account or logging in

  • Problem: When creating an account or logging in, it is sometimes hard to find out if you entered the correct characters for password.
  • Proposed solution: Add an eye icon in the "Password" field at Special:CreateAccount and Special:UserLogin. Once pressed, it will show you the characters already entered by you in this field.
  • Who would benefit: Registered users
  • More comments: This is very useful if you use a longer password.
  • Phabricator tickets:
  • Proposer: --NGC 54 (talk / contribs) 11:12, 11 January 2022 (UTC)


  • Agree. No explanation needed. Jmaxx37 (talk) 16:44, 11 January 2022 (UTC)
    One could argue that a) the "Confirm password" field already alleviates the need for such a button, but more importantly, b) this is a client-side thing the browser should provide, not some kind of JavaScript messing with the field type in the form. Making it a non-hidden text could, for example, cause mobile keyboards to remember the typed word and suggest it the next time you're typing a WhatsApp message. It would also prevent the browser from offering you to save the password for you. ToBeFree (talk) 20:26, 11 January 2022 (UTC)
    I usually remain logged in (no shared devices), but because I had to recover my WikiMedia password and set a new one today, I got logged out on all devices/browsers I use. As I went on to all of my devices and browsers, I noticed while using Edge on my Windows 10 computer, I did get the eye icon. It happened to be the last log in that I did, so I didn't have a chance to glance at this on my other browsers and devices. Maybe this is something that only happens in Edge, which I use a lot less often than Chrome on this computer. RSLitman (talk) 23:08, 11 January 2022 (UTC)
    I agree with this idea because some strong passwords are hard to remember and to fill the correct one is challenging. Sometimes, I can fill it wrong and don't know why. The eye feature would help you with this, but remember to not click this when at the public. Thingofme (talk) 03:30, 16 January 2022 (UTC)
  • Agree completely. I've struggled many times while writing my password because of this. BetweenCupsOfTea (talk)
  • For security reasons (to prevent others from unknowingly discovering your password), clicking on the "eye" icon should ask you to enter your Windows or Mac credentials if you are using a laptop or desktop. If you are using an iOS or iPadOS device, then it should ask for your Apple ID credentials. If you are using an Android device, then it should ask for your Google account credentials. GeoffreyT2000 (talk) 04:14, 16 January 2022 (UTC)
    That's not reasonable at all and not how modern websites work either. Izno (talk) 22:28, 18 January 2022 (UTC)
  • 'Agree. It is standard behavior. --Frettie (talk) 09:03, 18 January 2022 (UTC)
  • Although this should be a standard browser feature in an ideal world (so far it is supported as -ms-reveal in MS family of browsers from IE to Edge / EdgeChromium), it is currently not standard. Yet it is very useful e.g. for accessibility purposes (some people have to use very cumbersome input methods). --SSneg (talk) 21:02, 29 January 2022 (UTC)


  • Support Support USI2020 (talk) 20:26, 28 January 2022 (UTC)
  • Support Support — Draceane talkcontrib. 21:31, 28 January 2022 (UTC)
  • Support Support Sea Cow (talk) 22:57, 28 January 2022 (UTC)
  • Support Support Izno (talk) 23:33, 28 January 2022 (UTC)
  • Support Support Daud Iffa (talk) 00:16, 29 January 2022 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 08:18, 29 January 2022 (UTC)
  • Support Support Meiræ 12:35, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:15, 29 January 2022 (UTC)
  • Support Support Viticulum (talk) 18:16, 29 January 2022 (UTC)
  • Support Support --SSneg (talk) 21:02, 29 January 2022 (UTC)
  • Oppose Oppose: Use a browser that offers this feature if you need it; request it to be added to a browser if that's not an option. This is not something for a specific website to fix through JavaScript. Any time spent on developing this workaround is lost in the moment it becomes a browser feature. ToBeFree (talk) 22:57, 29 January 2022 (UTC)
  • Support Support Tgr (talk) 00:04, 30 January 2022 (UTC)
  • Support Support Agus Damanik (talk) 02:15, 30 January 2022 (UTC)
  • Support Support --g (talk) 21:33, 30 January 2022 (UTC)
  • Oppose Oppose as ToBeFree said, implement a specific solution to this problem only for MediaWiki is a workaround. in this case is better wait for browser support of the feature, then change the login page. --valepert (talk) 22:33, 30 January 2022 (UTC)
  • Support Support ok, as sometimes strong passwords are hard to remember. Thingofme (talk) 01:52, 31 January 2022 (UTC)
  • Support Support HugoHelp (talk) 04:03, 31 January 2022 (UTC)
  • Support Support Trizek from FR 12:17, 31 January 2022 (UTC)
  • Oppose Oppose per ToBeFree; this is (or should be) a browser feature. Silver hr (talk) 21:50, 1 February 2022 (UTC)
  • Support Support Agree that it's better as a browser feature, but it's becoming so common that I don't think we can/should wait until it's ubiquitous that way. But better to make it something users can opt in to, rather than a default option. Daniel Case (talk) 22:56, 1 February 2022 (UTC)
  • Support Support Hampcky (talk) 15:43, 2 February 2022 (UTC)
  • Support Support Rotavdrag (talk) 11:37, 3 February 2022 (UTC)
  • Support Support β16 - (talk) 10:38, 4 February 2022 (UTC)
  • Support SupportThanks for the fish! talkcontrib (he/him) 21:43, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:51, 6 February 2022 (UTC)
  • Oppose Oppose As ToBeFree said — DaxServer (t · c) 21:24, 6 February 2022 (UTC)

Show edit count at Special:Contributions

  • Problem: Edit counts are hard to determine unless you know about external tools and user scripts that show this information, or if you explicitly state how many edits you have on your userpage. Attempting to paginate through a user's contributions to count their edits can take a very long time if they have a very high edit count.
  • Proposed solution: Show a user's edit count at Special:Contributions, similar to how it is done on mobile web.
  • Who would benefit: An editor's edit count can be an indicator of how experienced they are. If somebody who recently edited the page had only 50 edits, an editor would be sure to review the edit with caution, because newer editors will generally mess up more often than experienced editors with 150,000+ contributions. Edit counts can also helpfully determine what kind of editor a person is (e.g. whether an editor edits to add more information to the site, or is a wiki gnome who fixes spelling errors and formatting).
  • More comments:
  • Phabricator tickets:
  • Proposer: MrMeAndMrMe (talk) 19:13, 10 January 2022 (UTC)


  • Just add this to your global.js and have a look at someone's user page afterwards: mw.loader.load(''); – The currently easiest built-in way involving no custom scripts is to open Special:CentralAuth/Username and to sort the table by "edit count". ToBeFree (talk) 19:17, 10 January 2022 (UTC)
    Thank you for that link. However, I would think that it would be easier for it to be a built-in function instead of that MrMeAndMrMe (talk) 19:24, 10 January 2022 (UTC)
    A reasonable wish. And with MusikAnimal (WMF)'s statement below, one I'll support. ToBeFree (talk) 19:37, 10 January 2022 (UTC)
    This is a reasonable wish, and I think it should be implemented in all installations of MediaWiki. In Wikimedia, we have XTools for viewing the others' edit count, but in wikis with no CentralAuth and XTools like other installations, we can't see others' edit count easily. Thingofme (talk) 02:51, 16 January 2022 (UTC)
  • FYI phab:T32353, phab:T213110, phab:T278506 (and likely many others) have been repeatedly declined due to claimed problems with caching. — xaosflux Talk 19:25, 10 January 2022 (UTC)
    Those asked for a magic word to be used in wikitext, which needs to be cacheable. MobileFrontend puts it at Special:Contribs which is not cached in the same way, and we could definitely do the same in native MediaWiki. Showing the system edit count is super cheap too, so I think this proposal is very doable, it would just need minimal design input. MusikAnimal (WMF) (talk) 19:30, 10 January 2022 (UTC)
    And it is readily available via the API (example for OP). — xaosflux Talk 19:33, 10 January 2022 (UTC)
  • That's a good suggestion. It does seem to take a long time (and sometimes X-tool can't see it) when looking at records with a large number of posts, such as Bot. Also, on a related note, I would like to suggest that the difference between registered users and IPs be removed for the following points.
    In Special:CentralAuth, you can see the registration and permission status for each project, but IPs cannot see the number of posts made.
    X-tool allows you to see the number of submissions, but there are no links to other projects, so you have to search for each one from the search screen.
    -- 03:18, 20 January 2022 (UTC)
    Viewing CentralAuth's contribution counter is not restricted to logged-in users. ToBeFree (talk) 22:45, 29 January 2022 (UTC)
    Why we can't easily view the number of IP edits? We can use a special page like Special:GlobalContributions/(the IP address) to do this. Thingofme (talk) 01:39, 31 January 2022 (UTC)
    IP edit counts most likely won't happen in production, for performance reasons. XTools counts the actual number of revisions, what you might consider more exacting, and that's why it's slower. MediaWiki's "system" edit count is a running tally that is incremented on every edit, meaning we can query for it very quickly. However it is only applied to registered users (who have a row in the user table), and what constitutes an edit has changed over time, which is why it could be considered approximate. More info at mw:Special:MyLanguage/XTools/Edit Counter#Edit counts. MusikAnimal (WMF) (talk) 00:17, 9 February 2022 (UTC)
It would be better also if the edit count of a user is visible on diffs, so if the editor edited an article, we may wish to see his edit on diffs and if edit count of that user is there, it's easy to identify if the user has enough experience in editing. Just in the mobile version. Ctrlwiki (talk) 06:33, 11 February 2022 (UTC)


Enable wiki URL changes

  • Problem: From no later than year 2006, a number of Wikipedia and other Wikimedia projects have been trying to change their language code. However, even after more than 1.5 decades, due to a number of technical roadblocks, this is not currently possible, and the only site that have gone through such process, from be-x-old to be-tarask, is under a perpetual state of technical failures, for example Content Translation tool still fail to function properly for the wiki due to the change in code from a decade ago.

    In order to fix the editing environment of such the renamed wiki, and to correct the name and language codes of all the wikis that are currently having various problems with their current name/url/language code, it is necessary to clear those long-standing technical roadblocks, and also to prevent new ones from being created.

    It might be a bit too large of a project for the Community Tech team to clear all of the blockers, but there should be a number of those blockers that the Community Tech team should be able to help clear, thus making the goal of changing the name, language code, and URL of different Wikipedia or other Wikimedia projects much easier.

    Examples of affected site (While most of the following used Wikipedia URL as example, other non-Wikipedia sites for these languages are also being affected, and in some cases are also blocking the creation of new projects for these languages due to intention to avoid related technical troubles):

  1. was renamed
  2. There are petitions to rename into, so as to reflect the site's language being Norway's Bokmål
  3. should be changed to, in order to reflect it is a Wikipedia for Simple English, and comply with the language tagging standard
  4. Serbo-Croatian Wikipedia currently use a language code sh. But the language code have been invalid since year 2000. The language code for the language is now hbs and proposal have been made to move the wiki to accordingly.
  5. Classical Chinese Wikipedia, currently located at, have its own language code lzh, so it have been suggested to move to
  6. Cantonese Wikipedia,, being described as Wikipedia for a variant of Chinese speaking in Guangdong, Guangxi, Hong Kong, Macau, and in diaspora around the world, is usually considered a language, and have its ISO language code "yue". Thus proposals have been made to remove the "zh-" and just use the standard language code for the Wikipedia's URL, turning it into
  7. Min Nan Wikipedia, aka the Wikipedia for Minnanese and Taiwanese, is now located at, due to the way some classify the language. However, the language have an official language code "nan", and proposal have been made to move the site to, accordingly.
  8. Swiss German Wikipedia, which have been placed under, have since year 2005 received official language code "gsw", and is thus desirable to change the wiki's link to
  9. Syriac Wikipedia, is now currently working under another name of Aramaic Wikipedia, at, which is an historical language which have disappeared long ago, and is not the language of the project. It would be favorable to change its name to Syriac Wikipedia and change its link to, to properly reflect the language used in the Wikipedia.
  10. Norman language from Normandy is now having a Wikipedia at Yet "nrm" is actually a language code for Narom language from Malaysia. Hence it have been proposed to change the wiki's URL from to to reflect the correct language code for the Norman language.
  11. The Wikipedia for Emilian language from Italy, currently located at, is actually using the old language code for the combined "Emilian-Romagnol language". As the language code have been separated and Emilian language is encoded as "egl", it have been proposed to change the link to, although there are also opinion against such change
  12. Võro language from Estonia, as part of the Finno-Ugrian languages, now have their Wikipedia at Since the language received its own language code in 2009 as "vro", it have been desired to move the site to
  13. Currently, is used by Wikipedia of Bhojpuri language in the Bihari languages group from India. Yet the language code "bh" have been deprecated, separating into individual language codes for each language, with Bhojpuri having the code "bho", and thus proposal have been made to move the wiki to, to avoid confusion with other Bihari languages.
  14. is the URL for Wikipedia in Zamboangueño dialect of Chavacano language. As the dialect have been said as the only living version of the language from the Philippines, proposal have been made to move it directly to representing the language.
  15. The Wikipedia for the Eastern Baltic language of Samogitian, have received its own language code "sgs", and thus proposal have been made to move the wiki's location from the current location of to
  16. Aromanian Wikipedia, is currently located at, with rup representing Aromanian language roa supposedly mean "Other romance languages", which is meaningless, and thus should be moved to simply
  17. Currently, there is an "Old Wikisource" located at It have been proposed to rename it as Multilingual Wikisource and be moved to, to better reflect its nature of collecting text in multiple languages that don't have their own Wikisource projects.
  • Proposed solution: Resolve as much bugs in phab:T172035 as possible, in accordance with the Community Tech team's capability.
  • Who would benefit: All readers and editors of affected wiki, all future developers of tools for the MediaWiki software, and all users of affected languages across the globe (Since Wikipedia language codes are sometimes being taken as de facto standard for languages by others far beyond just the Wikipedia itself, instead of the base BCP-47 standard, fixing these language codes will also promote fixing them everywhere else across the internet or even off the internet)
  • More comments: This is a resubmission of wish from 2019 Community Wishlist and based on a proposal written in the sandbox.
  • Phabricator tickets: phab:T172035
  • Proposer: C933103 (talk) 12:10, 16 January 2022 (UTC)


  • Have you ever read Limits_to_configuration_changes#Changes_that_are_likely_to_be_stalled,_though_not_declined? --Liuxinyu970226 (talk) 01:30, 17 January 2022 (UTC)
  • Please be noted that I mentioned "It might be a bit too large of a project for the Community Tech team to clear all of the blockers, but there should be a number of those blockers that the Community Tech team should be able to help clear" so I do not expect the Community Tech Team to totally resolve the issue, but rather help resolve as much parts of it as possible, in accordance with their capability. C933103 (talk) 03:12, 17 January 2022 (UTC) Edit: highlight added: 04:30, 17 January 2022 (UTC)
    @C933103 If so then your proposal is OOS for CWS, move to Community_Wishlist_Survey_2022/Archive or not? Liuxinyu970226 (talk) 04:20, 17 January 2022 (UTC)
    @MusikAnimal: In the current form, isn't this "On roadmap of another team"? This looks like something that server admins should focus on, instead of Community Wishlist team. Liuxinyu970226 (talk) 05:33, 17 January 2022 (UTC)
    Is it on the roadmap of another team? If it is, then yes we can archive it as there's no reason to vote on this wish. Otherwise, as the proposer states, we might be able to help with some of the subtasks, but certainly not the whole wish. It is rather odd for our team, though, since we generally build new products or have some sort user-facing deliverable. Here we'd just be assisting with some busy work that may actually result in the wish being resolved at some later time in the future. Peculiar for us, but not necessarily out of scope in my opinion. MusikAnimal (WMF) (talk) 20:46, 17 January 2022 (UTC)
    So far as I know, this one is not on anyone's roadmap to actually do anything about. Izno (talk) 22:27, 18 January 2022 (UTC)
    @Izno phab:T30443 told me that @Vladimir Alexiev: is probably handling this one subtask, as they re-triaged the priority of it from Lowest to High. Liuxinyu970226 (talk) 02:23, 19 January 2022 (UTC)
    I don't think so, there has not been change on that task for some time. Izno (talk) 04:42, 19 January 2022 (UTC)
  • This is an unacceptable state of affairs that has gone on for far too long. In particular, the situation where a Wikipedia language edition (be-tarask) is experiencing ongoing technical failures, rendering parts of the software unusable, is entirely unacceptable. The Community Tech team could play a valuable role as "shepherds", taking ownership of the issue and making sure that the different WMF teams come together to get it resolved. IThis, that and the other (talk) 13:00, 18 January 2022 (UTC)
    @This, that and the other: Would you like to take over this wish? As I have exceeded the number of permittable proposal. You can take over the wish by changing the proposer name to your's. C933103 (talk) 13:43, 19 January 2022 (UTC)
    @C933103 It's alright, we up'd the limit to 10! That rule only ever existed to ensure proposers are responsive. You are being responsive, so there's no problem :) MusikAnimal (WMF) (talk) 20:20, 19 January 2022 (UTC)


Graph showing which articles link to each other for incubator

  • Problem: This isn’t really a problem that necessary harms users, just a suggestion for something that would help.
  • Proposed solution: For every test wiki, it will be possible to choose an article, then get a graph with arrows showing what articles the specified article links to, and what articles the linked articles link to. Probably a maximum of 3-5 jumps.
  • Who would benefit: Editors in test wikis in the incubator.
  • More comments: Will be useful to estimate how much content the test wiki has and if it uses wikilinks correctly.
  • Phabricator tickets:
  • Proposer: Gifnk dlm 2020 Happy New Year 🎄❄️⛄️🎇 (talk) 16:51, 16 January 2022 (UTC)


  • Comment Comment since Special:WhatLinksHere already exits, it’s possible to use the same algorithm and creating a graph of what pages link to this page, again a maximum of 3-5 jumps. Both would be equally useful so implement the way that will be easiest to implement. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 13:57, 18 January 2022 (UTC)
    • The result will be a png image which can be uploaded to commons. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 14:27, 18 January 2022 (UTC)
  • @Gifnk dlm 2020: Some sort of visual link graph tool exists, I know because I've seen it before... alas I cannot find it! Perhaps someone else reading this proposal will know what I'm talking about; but regardless there's a good chance the tool doesn't support Incubator wikis. As you say Special:WhatLinksHere and the database tables it uses can be queried directly, so this seems perfectly feasible. However this proposal might have better chances if you ask for a link graph tool that works on any wiki, including Incubator wikis. Just a suggestion! MusikAnimal (WMF) (talk) 04:35, 19 January 2022 (UTC)
    • @MusikAnimal (WMF):, thank you very much! It will probably really be better for all wikis and not just incubator to be helpful for a wider variety of contributors. I feel like it will be useful only for Wikipedia and test Wikipedia projects and suggested it as a tool that will help incubating however if it’s useful also for other purposes I’m all for it. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 07:54, 19 January 2022 (UTC)
      • Yes, it will help us a lot while working in incubator test wikis. :) Haoreima (talk) 07:57, 19 January 2022 (UTC)
  • Why specifically only incubator?C933103 (talk) 15:00, 6 February 2022 (UTC)


Create 'Related changes' tool that extends beyond 30 days

  • Problem: Even though 'Related changes' can show up to 500 changes, it has a short lifespan, just 30 days maximum, so rarely shows more than 20-30 before they time-expire. 'Related changes' uses the recentchanges table, which for performance reasons on Wikimedia cannot be increased from 30 days worth of data.
  • Proposed solution: Create an external tool that works just like Special:RecentChangesLinked, except it extends beyond 30 days.
  • Who would benefit: Editors checking for changes on related pages.
  • More comments: It is very easy to forget to check 'Related changes' monthly. Extending it to a year would allow editors to keep a more relaxed overview of checking changes on related pages without worrying if they've missed anything important.
  • Phabricator tickets:
  • Proposer: MPF (talk) 21:21, 10 January 2022 (UTC)


  • This would be a useful addition in two contexts related to categories, as "related-changes to Category:foo" gets me pages recently edited that are in or added to that cat...a form of watchlist for all articles in the category. One use-case is occasional vandal-pattern of adding incorect categories (one that comes to mind was adding a certain ethnicity to all sorts of inventions by anyone marginally associated with that geo-ethnic region). A second use-case is that I periodically check certain maintenance categories that are very full but non-trivial to fix, and use recent-changes to prioritize fixing based on which ones are popular (also catches recent edits that make mistakes...opportunity to educate/get-assistance-from those editors themselves). DMacks (talk) 21:46, 10 January 2022 (UTC)
    I think some related changes have a lot of links and some pages have a lot of small links, and some page can have unrelated changes for the article. I think we should only increase to 90 days and 1 year when the edits are low enough to ensure performance. The appliances of the idea is to categories, and other lists. Thingofme (talk) 03:05, 16 January 2022 (UTC)
  • Related changes uses the recent changes table to get its data, which is bound by $wgRCMaxAge. On the WMF cluster that's set to 30 days. I'm somewhat certain there's little chance of increasing that, or at least not without consulting the DBAs and/or the performance team first. I believe it used be higher but they had to reduce it for performance reasons, hence why I doubt they'd reverse that decision. Pinging ASarabadani (WMF) for input. MusikAnimal (WMF) (talk) 22:43, 10 January 2022 (UTC)
    @MPF: I have confirmed that making Special:RecentChangesLinked for 100 days is out of the question :( Amir may or may not reply here with more info, but my inclination is that if we want to take on this wish, it would probably have to be an external tool that queries the revision table. This means it won't be built into the interface like a Special page, and it might also be really slow to use. I'm not sure if that would satisfy this wish or not? If it would, could you reword your proposal to be about an external "related changes" tool? I don't want other !voters to be misled into thinking we could do something for Special:RecentChangesLinked. Thanks, MusikAnimal (WMF) (talk) 16:59, 11 January 2022 (UTC)
    @MusikAnimal (WMF): - thanks! That's a shame. What about a smaller extension? Even 50 or 60 days would still be better than 30 - MPF (talk) 17:22, 11 January 2022 (UTC)
    I'll let Amir reply to that, but as I understand it on some wikis like Wikidata, we may even have to reduce the RCMaxAge. Overall I'm still leaning towards an external tool if anything, since those are allowed to be slow. MusikAnimal (WMF) (talk) 17:27, 11 January 2022 (UTC)
    For 500 edits, it's ensure performances, but higher than 500 it is too slow to load. Thingofme (talk) 03:06, 16 January 2022 (UTC)
    It's not just the query runtime that's the problem, it's the size of the table. When it gets really really big, weird things happen. MusikAnimal (WMF) (talk) 04:00, 19 January 2022 (UTC)
    I would bet pages with higher numbers of results are loading slowly mostly due the client side (rendering the HTML), not the server side (querying the edits). 500 edits is still nothing compared to the size of the recentchanges table. ~~~~
    User:1234qwer1234qwer4 (talk)
    22:04, 8 February 2022 (UTC)
    @MPF Is an external tool (not Special:RecentChangesLinked, but it would work in the same way), not an acceptable solution? If so, please reword your proposal accordingly. I can help, if you need. If the desire is solely for Special:RecentChangesLinked, then I'm afraid it's at the very least out of scope for our team. We can offer to put it in the Larger suggestions category so we can still gauge the popularity of the idea. You decide. MusikAnimal (WMF) (talk) 04:04, 19 January 2022 (UTC)
    I recall that, before Special:RecentChanges changed to the current interactive format, it was possible to see up to 91 days of changes? Am I recalling correctly? C933103 (talk) 12:14, 16 January 2022 (UTC)
    That used to be the default from 2007 till some point yes, but I think it changed quite a while ago, possibly even before wikidata was introduced ? —TheDJ (talkcontribs) 15:13, 16 January 2022 (UTC)
    Was there any documented reason behind such change? As undoing intentional changes would be out of scope for the community tech team. C933103 (talk) 08:08, 17 January 2022 (UTC)
  • In addition to the Proposed solution: An other possibility would be be to remove the time-border completely, and instead just keep track of the last say 250 edits.T.vanschaik (talk) 18:37, 18 January 2022 (UTC)
    @T.vanschaik and MusikAnimal (WMF): That would be a huge improvement - I checked one page I like to keep an eye on, and the current top allowed "Max 1,000 changes, last 30 days" only showed 11 related changes because of the 30 day time limit. So the last 250 related changes would actually cover the last two years or so - MPF (talk) 08:55, 19 January 2022 (UTC)
    @MPF I'm afraid that's not feasible, either. In order to accommodate the last 250 related changes of every page we'd have to increase the size of the recent changes table several times over. I'll ask one last time – would an external tool suffice? It would basically offer the same functionality as Special:RecentChangesLinked except allow you to go back any arbitrary number of edits or time period, with the caveat that you may need to wait up to say 30 seconds to get a result. If this is acceptable, I'll help you rewrite your proposal. Otherwise it needs to be moved to the Larger suggestions pile. Please advise on what route you'd like to go. Thanks, MusikAnimal (WMF) (talk) 15:48, 19 January 2022 (UTC)
    The number of 250 was just a proposal. On the other hand, the list could have two limits, one on the number of entries, again say 250, and one one the time elapsed since the edit, say one year. Whichever one is met first springs into action to remove the entry from the list.T.vanschaik (talk) 16:51, 19 January 2022 (UTC)
    @T.vanschaik and MusikAnimal (WMF): - I'm not sure how an 'external' tool would work? Otherwise, any shift of the current limits from 'high number, short time limit' towards more of a 'low number, long time limit' would help, whatever is feasible (even a max of 50 would be better if it allowed a more open-ended time limit) - MPF (talk) 00:34, 20 January 2022 (UTC)
    @MPF The external tool would more or less work exactly like Special:RecentChangesLinked does, except it would be external (i.e. hosted on and not usable within the on-wiki interface). Admins on your local wiki could add a link to the external tool so that it is easily accessible. The results this tool give you would match Special:RecentChangesLinked exactly, except it'd be able to give you more results, which I believe is what you want. Does that sound okay? MusikAnimal (WMF) (talk) 22:35, 20 January 2022 (UTC)
    Thanks! Yep, that sounds OK, if it can be made as easily accessible as the current 'related changes' link - MPF (talk) 22:43, 20 January 2022 (UTC)
    Okay, done! Thanks again. MusikAnimal (WMF) (talk) 18:40, 26 January 2022 (UTC)


Check if a page exists without populating WhatLinksHere

  • Problem: Does a wiki page exist? This should be a simple thing to check in a template or module, and it partly is – you can use the #ifexist parser function. However, due to the way that this has been implemented in MediaWiki, this has unexpected consequences: pages that call the templates/modules that do this check will now appear in Special:WhatLinksHere. These false flags cause significant problems for editors that are working on resolving misplaced wikilinks, such as links to redirects or disambiguation pages. That in turn leads to them objecting to the use of any template/module that checks for the existence of a page to see if they should link to it.
  • Proposed solution: Rework the MediaWiki database structure so that uses of #ifexist do not also appear in Special:WhatLinksHere – although this is not easy.
  • Who would benefit: Template developers who need to check if a page exists. Editors resolving disambiguation links on all wikis who don't want to see false links.
  • More comments: This is a perennial request to fix some long-standing technical debt. It has been proposed in the 2015, 2017, 2019, and 2021 wishlists. There is a work-around that uses page protection information, see en:Template:Linkless exists, but this isn't a long-term solution.
  • Phabricator tickets: phab:T14019 (from 2007), phab:T268526 (the wider database structure issue)
  • Proposer: Mike Peel (talk) 19:04, 14 January 2022 (UTC)


This also causes a quirk at Wikisource. The proofreading statistics (how many pages exist, how many are proofread or validated, etc) for an index can be gathered using Lua. Obviously, this has to check that pages exist, which means registering a template dependency on every page in the index, existing or not so that if pages change status the stats are correct (note: the actual counts of page statuses in an index don't require to access every page). The upshot is that pages like the monthly overviews of things like the s:en:Wikisource:Monthly Challenge appear to transclude very very many pages, though they actually do not transclude a byte of content. There is an idea for a workaround to add an "approximate" mode to the stats function, which would dispense with the template link, but this would rely on pages using approximate stats to purge regularly, as changes to or creations of the pages would not cause an update. It would be better if there could be some concept of non-transcluded, non-linking dependency. Inductiveload (talk) 20:09, 14 January 2022 (UTC)

Procrastination is the #1 reason why the problem still has not been fixed despite requests from past surveys. People put things off all the time, so the developers put off implementing the required changes (in other words, they procrastinate). Next time, we should set reminders and deadlines so that the developers know to implement the required changes to prevent pages with #ifexist checks from appearing in Special:WhatLinksHere and stop procrastinating. GeoffreyT2000 (talk) 21:26, 14 January 2022 (UTC)

Why isn't en:Template:Linkless exists a long-term solution? Seems to me it would likely be a lot easier to make the #ifexist parser function use the "linkless exists" technique than to rework the MediaWiki database structure. I tried voting support below, but tired of the edit conflicts and it's not worth the waste my time to try voting again. Wbm1058 (talk) 20:45, 28 January 2022 (UTC)

@Wbm1058: It seems to work as a work-around, but having to ask 'what is the page protection' if you want to ask 'does this page exists' is fundamentally illogical. It also doesn't seem to be available via Lua (unless I've missed something). Thanks. Mike Peel (talk) 21:03, 28 January 2022 (UTC)
Because it's a hack. It works because of the peculiar behavior of the {{PROTECTEDEXPIRY:}} magic word, which might change at some point. Also not sure the caches are correctly updated when the page exists. Strainu (talk) 21:12, 28 January 2022 (UTC)
Well, I say just HACK AWAY! You'll get more satisfaction than waiting for the Cleveland Browns to appear in a Super Bowl. And if the developers are sufficiently annoyed by the hacks then that might just motivate them to fix it right. Wbm1058 (talk) 21:26, 28 January 2022 (UTC)
@Wbm1058, Strainu, and Mike Peel: Yes, it's a hack, or possibly an exploit of a data leak in MediaWiki. If you can think of a more elegant way to achieve this, please enhance the template! The Lua version was deleted per en:Wikipedia:Templates_for_discussion/Log/2018_October_10#Module:Linkless, but I have my original effort stored locally if anyone would like to use it in another module. Certes (talk) 19:45, 21 February 2022 (UTC)

Unexplained "oppose" comments such as that below are very unhelpful. There is nothing in them that can be addressed, nor that informs other editors of any problems that might have been identified. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:47, 9 February 2022 (UTC)


  • Support Support * Pppery * it has begun 18:42, 28 January 2022 (UTC)
  • Support Support Procrastinators, please start working on the required patches this year! GeoffreyT2000 (talk) 18:46, 28 January 2022 (UTC)
  • Support Support It is essentially a bug at the moment — GhostInTheMachine talk to me 18:56, 28 January 2022 (UTC)
  • Support Support. Arlo Barnes (talk) 19:25, 28 January 2022 (UTC)
  • Support Support Wikisaurus (talk) 19:25, 28 January 2022 (UTC)
  • Support Support Kaybeesquared (talk) 19:27, 28 January 2022 (UTC)
  • Support Support. It's an annoying issue, which should have been fixed years ago already. --Matthiaspaul (talk) 19:29, 28 January 2022 (UTC)
  • Support Support Long overdue. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:40, 28 January 2022 (UTC)
  • Support Support again. Debatably a bug. We can afford to fix this. Certes (talk) 19:41, 28 January 2022 (UTC)
  • Support Support yet again. Just fix it.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  19:45, 28 January 2022 (UTC)
  • Support Support The presence of a self-check means that essentially any page tagged for speedy-deletion will warn that there are inbound links when I go to delete it. That makes the inbound-link-check feature useless. DMacks (talk) 19:52, 28 January 2022 (UTC)
  • Support Support He3nry (talk) 20:00, 28 January 2022 (UTC)
  • Support Support I support it, again and again and again ... until it will be implemented :-) --Andyrom75 (talk) 20:04, 28 January 2022 (UTC)
  • Support Support — AfroThundr (u · t · c) 20:07, 28 January 2022 (UTC)
  • Support Support Galobtter (talk) 20:12, 28 January 2022 (UTC)
  • Support Support Kaganer (talk) 20:18, 28 January 2022 (UTC)
  • Support Support --Atamari (talk) 20:19, 28 January 2022 (UTC)
  • Support Support USI2020 (talk) 20:27, 28 January 2022 (UTC)
  • Support Support Schazjmd (talk) 20:36, 28 January 2022 (UTC)
  • Support Support Cabayi (talk) 20:41, 28 January 2022 (UTC)
  • Support Support --Serhio Magpie (talk) 20:46, 28 January 2022 (UTC)
  • Support Support completely agree, and hope that any overhaul of this also considers other QoL improvements requested for WhatLinksHere at the same time! --YodinT 20:59, 28 January 2022 (UTC)
  • Support Support Yes, please! Strainu (talk) 21:00, 28 January 2022 (UTC)
  • Support Support — Draceane talkcontrib. 21:32, 28 January 2022 (UTC)
  • Support Support enL3X1 ¡‹delayed reaction›¡ 22:04, 28 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 22:31, 28 January 2022 (UTC)
  • Support Support Jon Harald Søby (talk) 22:40, 28 January 2022 (UTC)
  • Support Support Jheald (talk) 23:21, 28 January 2022 (UTC)
  • Support Support Inductiveload (talk) 23:27, 28 January 2022 (UTC)
  • Oppose Oppose Given a) the technical challenge and b) almost 0 value in doing this proposal. --Izno (talk) 23:29, 28 January 2022 (UTC)
  • Oppose Oppose I'm surprised to see the number of votes here. Resolving technical debt is good, but I'm not seeing a strong benefit here to warrant the high development cost. {{u|Sdkb}}talk 00:30, 29 January 2022 (UTC)
  • Support Support This longstanding technical debt has negatively impacted wiki link tracking for years. I think those who oppose the idea should instead try to convince the community to close the Phab ticket. Huji (talk) 01:36, 29 January 2022 (UTC)
  • Support Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 01:50, 29 January 2022 (UTC)
  • Support Support Betseg (talk) 02:08, 29 January 2022 (UTC)
  • Support Support every year 😪 JWBTH (talk) 03:00, 29 January 2022 (UTC)
  • Support Support stop making sexy new gadgets that will get left to decay, start fixing the existing technical issues. Gnangarra (talk) 06:38, 29 January 2022 (UTC)
  • Support Support«« Man77 »» [de] 09:38, 29 January 2022 (UTC)
  • Support Support WhatLinksHere is already broken, it populates many unexpected links on many Wikidata items. --Liuxinyu970226 (talk) 11:23, 29 January 2022 (UTC)
  • Support Support Astronemma (talk) 13:11, 29 January 2022 (UTC)
  • Support Support NguoiDungKhongDinhDanh 13:13, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:44, 29 January 2022 (UTC)
  • Support Support BSMIsEditing (talk) 15:10, 29 January 2022 (UTC)
  • Support Supportputnik 15:42, 29 January 2022 (UTC)
  • Support Support Marwin H.H. (talk) 16:09, 29 January 2022 (UTC)
  • Support Support --Naḥum (talk) 17:58, 29 January 2022 (UTC)
  • Support Support Shalomori123 (talk) 18:23, 29 January 2022 (UTC)
  • Support Support Fixing long-standing MediaWiki bugs, even if doing so is tough, and even if the result is just a little improvement, should be the main priority of all paid WMF developers. If fixing this issue is impossible, say so and decline the phabricator tasks. Leaving them "open" all the time is not an option. ToBeFree (talk) 23:07, 29 January 2022 (UTC)
  • Support Support Bien sur. –SJ talk  00:22, 30 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 07:57, 30 January 2022 (UTC)
  • Support Support Dominic Z. (talk) 14:51, 30 January 2022 (UTC)
  • Support Support --Metrónomo-Goldwyn-Mayer 16:18, 30 January 2022 (UTC)
  • Support Support Geraki TL 16:29, 30 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 22:36, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:45, 31 January 2022 (UTC)
  • Support Support 1dragon (talk) 00:50, 31 January 2022 (UTC)
  • Support Support Thingofme (talk) 01:44, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 06:19, 31 January 2022 (UTC)
  • Support Support No such user (talk) 07:32, 31 January 2022 (UTC)
  • Support Support Iniquity (talk) 09:07, 31 January 2022 (UTC)
  • Support Support β16 - (talk) 10:59, 31 January 2022 (UTC)
  • Support Support the wub "?!" 14:22, 31 January 2022 (UTC)
  • Support Support Dreamy Jazz talk to me | enwiki 14:40, 31 January 2022 (UTC)
  • Support Support Matma Rex (talk) 16:33, 31 January 2022 (UTC)
  • Support Support Novak Watchmen (talk) 17:08, 31 January 2022 (UTC)
  • Support Support Normal Name (talk) 22:50, 31 January 2022 (UTC)
  • Support Support Patsagorn Y. (Talk) 04:05, 1 February 2022 (UTC)
  • Support Support Bencemac (talk) 11:40, 1 February 2022 (UTC)
  • Support Support Charitwo (talk) 18:17, 1 February 2022 (UTC)
  • Support Support Gahoo (talk) 18:48, 1 February 2022 (UTC)
  • Support Support -- Ahecht (TALK
    ) 21:36, 1 February 2022 (UTC)
  • Support Support Wargo (talk) 21:49, 1 February 2022 (UTC)
  • Support Support Daniel Case (talk) 22:40, 1 February 2022 (UTC)
  • Support Support ~ Amory (utc) 20:47, 2 February 2022 (UTC)
  • Support Support ☕ Antiqueight chatter 23:38, 2 February 2022 (UTC)
  • Support Support FrozenPlum (talk) 00:10, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 15:45, 3 February 2022 (UTC)
  • Support Support Rzuwig 12:21, 4 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 06:10, 5 February 2022 (UTC)
  • Support Support Otr500 (talk) 13:53, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 15:11, 5 February 2022 (UTC)
  • Support SupportThanks for the fish! talkcontrib (he/him) 21:39, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:34, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 07:20, 6 February 2022 (UTC)
  • Oppose Oppose --Ciao • Bestoernesto 17:31, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 20:52, 6 February 2022 (UTC)
  • Support Support ~Cybularny Speak? 20:53, 7 February 2022 (UTC)
  • Support Support Sunpriat (talk) 01:25, 11 February 2022 (UTC)
  • Support Support Facenapalm (talk) 15:12, 11 February 2022 (UTC)
  • Support Support Nehaoua (talk) 16:01, 11 February 2022 (UTC)
  • Support Support While Linkless exists exists, it is not a long-term solution. stjn[ru] 16:52, 11 February 2022 (UTC)
  • Support Support -BRAINULATOR9 (TALK) 17:25, 11 February 2022 (UTC)

simple export of SpecialPages

  • Problem: There are special pages like ancient, lonely or what links here. If someone wants use this list for further work he must copy it, in some cases clean (e.g. in Special:AncientPages delete date or add [[]] or both) and then use. It would be useful, if this list can be exported as wikipage, plaintext, csv or json.
  • Proposed solution: Provide possibility to export specified number or all entries in special page.
  • Who would benefit: Maintenancers, experienced users, bot operators
  • More comments: This is possible using Petscan or Quarry, but needs more skills and not everything is possible. Petscan is easier to use, but probably not useful for creating list of lonelypages. query have more possibilities, but only few users know how to use it.
  • Phabricator tickets: phab:T248440
  • Proposer: JAn Dudík (talk) 09:54, 20 January 2022 (UTC)



  • Support Support Lectrician1 (talk) 05:17, 29 January 2022 (UTC)
  • Support Support Dexxor (talk) 14:22, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 23:04, 29 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 23:24, 29 January 2022 (UTC)
  • Support Support Riha (talk) 14:06, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 22:32, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:45, 31 January 2022 (UTC)
  • Support Support But, we need to update special pages (for database reports) more quickly. Thingofme (talk) 01:43, 31 January 2022 (UTC)
  • Support Support Wargo (talk) 21:48, 1 February 2022 (UTC)
  • Support Support 公車迷阿暄 (talk) 08:29, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:49, 5 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 07:24, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:36, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 21:11, 6 February 2022 (UTC)
  • Support Support Rots61 (talk) 22:20, 8 February 2022 (UTC)
  • Support Support and when you copy the titles, you can even unexpectedly find (on some special pages) RTL tag at the end. Exporting even via API would be more convenient than copying. Sunpriat (talk) 01:21, 11 February 2022 (UTC)

Shared talk page section for related articles

  • Problem: Often times, related articles (e.g. for various general elections in the same country) will re-use certain conventions, etc. (e.g. whether to treat a coalition as a single party or multiple parties). It is good to keep those conventions consistent among related pages. However, because it each article has its own talk page, it can be difficult to ensure editors of every page are alerted and able to participate in the discussion; this can result in the inability to gain consensus, or else create a false consensus.
  • Proposed solution: Create a feature which allows multiple articles to share a talk page section. When someone edits/updates the shared talk page section in one of the articles, the corresponding section of the talk page would update for all other articles contained the shared section of the talk page. (Perhaps having a shared talk page section would involve using a common category. Or perhaps it would use a tag hidden from people who read but do not write Wikipedia.)
  • Who would benefit: Editors would be the ones to directly benefit
  • More comments: Here is a real-life example of where I believe this would be beneficial. The infoboxes of articles on Australian elections treat the Liberal Party and the National Party as a single political party. I believe this should be changed so the infoboxes reflect that they are two different parties. Normally, I might propose on the talk page of "2019 Australian federal election" article to make this change. However, people who edit related articles (e.g. "2016 Australian federal election" and "2013 Australian federal election") are unlikely to see my proposal. (It would not be practical to post my proposal on the talk page of every article on an Australian election, and doing so could lead to branched debates/consensuses.)
  • Phabricator tickets:
  • Proposer: ROADKILL (talk) 21:46, 14 January 2022 (UTC)


This can already be achieved via mw:Extension:Labeled Section Transclusion.--GZWDer (talk) 07:09, 16 January 2022 (UTC)

  • There is a notifier script that exists on English Wikipedia at en:User:Newslinger/Notifier.js that will suffice to let other pages know a discussion is happening. (Flow before its death could also have been used for this.) --Izno (talk) 22:44, 18 January 2022 (UTC)


  • Oppose Oppose Per discussion section above, wondering why this can't be archived? --Liuxinyu970226 (talk) 11:24, 29 January 2022 (UTC)
  • Support Support Libcub (talk) 22:27, 30 January 2022 (UTC)
  • Neutral Neutral We can redirect the talk pages for centralized discussion, but we can't do that in independent articles. Thingofme (talk) 15:52, 31 January 2022 (UTC)
    @Thingofme: I don't think {{n}} is what you wanted here. Perhaps you meant {{neutral}}? MusikAnimal (WMF) (talk) 23:57, 31 January 2022 (UTC)
    Yes, it's the wrong template. Thingofme (talk) 01:27, 1 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:18, 6 February 2022 (UTC)

Centralized Incident Management

  • Problem: When reports about production issues are opened on WMF projects, it is difficult for those reporting the issue to know when the production issue is purportedly resolved.
  • Proposed solution: Expand the use case for Phabricator to include incidents and problem, instead of only tasks for solutions.
  • Who would benefit: Users
  • More comments: Phabricator states are really only used to indicate that software changes have been created merged, not that they have actually been deployed. People with issues are generally trying to open "incident reports" - not "software requests" - they are telling a user story, but their story doesn't end until the situation is no longer presenting to them.
  • Phabricator tickets:
  • Proposer: — xaosflux Talk 18:22, 10 January 2022 (UTC)


We currently use phabricator for bug tracking, feature requests, and other items. A common scenario is that contributors from a WMF project finds something malfunctioning - this may be occurring simultaneously on multiple WMF projects. What happens next: one or more phabricator tasks get opened, reporting instances - this works OK, and bug wranglers will merge duplicate reports. Next, if confirmed someone may decide to work on the problem. A common scenario is that the problem is code in need of improvement, and someone working on it may create some new code, and the new code may be released. At this point all of the tracking comes to an end - however notably this does not mean that from the point of view of the original reporters that their actual production problem is resolved. Why - because that doesn't mean that WMF servers are actually running the new code, and it certainly doesn't mean that resolution acceptance in production has occurred. What is lacking here? Tracking of the actual incident and/or problem from report to resolution. Additionally, no information about the priority (the impact and urgency) of the incident or problem is gathered (a priority field that can be misleading is tracked, but this is the priority that software developers are declaring). The primary place that incident tracking may be occurring is on disparate wiki pages across all projects. So what is lacking: A process and system to manage and track actual incident reports. This could be phabricator, however this is going to require more of a human element and mindset improvement than just technology. Should this be a call to help to the volunteer community - a call to help to ask WMF to assign some of this "service desk" functions to staff - not sure the "best" but additional ideas are welcome below! xaosflux Talk 18:22, 10 January 2022 (UTC)

I think this is often implemented by having two different states, like To Deploy/Done. This way things that are fixed in code can be moved to To Deploy once they are committed, and to Done only when the change is live. It seems a very easy fix in technical terms, but probably big for developer workflows. MarioGom (talk) 08:18, 12 January 2022 (UTC)
Even a workflow like that may help, a user story or incident isn't "done" until the situation leading to it is actually usable. — xaosflux Talk 14:36, 12 January 2022 (UTC)
I do note that we have deploy labels on tickets WITH dates of when something starts entering production. It's just that this does not match the expectations of normal users where to look. Then again, closed is special state, which has all kinds of workflow affects that are generally rather important for developers, so splitting that in two in the software is not that easy. But I agree that it is confusing and especially if sometimes some WMF teams even deviate from what happens in most of the rest of the tickets. —TheDJ (talkcontribs) 16:22, 12 January 2022 (UTC)
I also agree it's awfully confusing. Those deploy labels can be wrong, such as this week when the deployment train was halted. To those who don't know: The most exacting way to tell is to (1) go to the Phab task (2) look at the linked Gerrit patches (3) on the gerrit patch, you'll see an "INCLUDED IN" link on the right above the list of files. That tells you what branches it lives on. (4) Go to toolforge:versions and see if the branch you need is on your wiki. Easy, right? :) Making that process easier is something worthy of a proposal on its own. Maybe a Phabricator extension or something, that talks to whatever it needs to in order to tell us definitively if it's live or not on a given wiki.
@Xaosflux There are a lot of good ideas here. At the very least I ask we expand on the "Problem statement" (i.e. "I have no way of knowing the fix for T12345 has been deployed", and then maybe expand on the proposed solutions. This year proposals get marked for translation, but for obvious reasons the comments do not. So to a non-English reader, they won't be able to infer much with what you have now :) Thanks for starting this conversation, and for participating in the survey! MusikAnimal (WMF) (talk) 05:09, 14 January 2022 (UTC)
@MusikAnimal (WMF): see above - better? I mostly understand the current phab process - but I'm certain 99%+ of users of our system do not - which is why I know this is a problem :) — xaosflux Talk 11:07, 14 January 2022 (UTC)
Better, yes! I may make a few tweaks for translatability but this otherwise looks good and is a great proposal. Thanks, MusikAnimal (WMF) (talk) 03:38, 19 January 2022 (UTC)

T280 and T88136 are somewhat related. --Tgr (talk) 00:02, 30 January 2022 (UTC)


  • Support Support As proposer! — xaosflux Talk 18:59, 28 January 2022 (UTC)
  • Support Support Aca (talk) 13:46, 29 January 2022 (UTC)
  • Support Support Most likely will improve relations between users and developers, since users will understand better what happens with their tasks. Snævar (talk) 16:02, 29 January 2022 (UTC)
  • Support Support Hemantha (talk) 05:51, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 22:36, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 00:44, 31 January 2022 (UTC)
  • Support Support Thingofme (talk) 01:37, 31 January 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:52, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 17:38, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 21:16, 6 February 2022 (UTC)
  • Support Support careful support, as i do think we can be more 'user oriented' in some of our approaches, but i'm afraid of the "yet another system, that will fix it"-syndrom —TheDJ (talkcontribs) 18:10, 7 February 2022 (UTC)

The "tag name" on the change line should link directly to "tagged changes"

  • Problem: The tag on the change line currently looks like this:

        14:33 John Callahan's Quads!‎ (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: Visual edit, Mobile web edit)

    The tag name is either a link to a help page or just plain text. It is not easy to find edits with the same tag.

  • Proposed solution: Change the tag display on the change line. The tag name should link directly to the "tagged changes" at Special:RecentChanges. For example: the tag "VisualEditor" would link to Recent Changes but showing only edits with the #VisualEditor tag (example), tag "Mobile web edit" links to example, etc. Like this:

        14:33 John Callahan's Quads!‎ (diff | hist) .. (−12) .. Rng0286 (talk | contribs) (lorem ipsum) (Tags: VisualEditor, Mobile web edit)

    A new Special redirect could be introduced as well, such as Special:Tags/tag_name page that would redirect to Special:RecentChanges showing only edits with the given tag.

  • Who would benefit: All editors
  • More comments:
  • Phabricator tickets:
  • Proposer: Shizhao (talk) 07:09, 19 January 2022 (UTC)


  • @Shizhao: Did you know you can find "tagged changes" through Special:RecentChanges? Look for the "Tags" button towards the right. See the English Wikipedia results for Visual edit, for example. Is this what you are looking for?

    I think it's sensible to link recent changes from the tag names in revision histories, as you are suggest, but then how would we ever show a link to the documentation for the tag? Special:RecentChanges doesn't have an intuitive way surface this (you can also filter by multiple tags). Also, if it wasn't clear, these links to documentation pages are defined in interface messages. Those could be updated by any admin to link to Special:RecentChanges for that tag, if there's consensus to do so. The "Visual edit" tag for instance is defined at en:MediaWiki:Tag-visualeditor. MusikAnimal (WMF) (talk) 21:28, 19 January 2022 (UTC)

    For pages which need/have the additional documentation, adding some text "help" or whatever would work. I would be more than happy to see, for example, the VE tag changed today just to demonstrate it's possible to do what is being suggested today. --Izno (talk) 23:04, 19 January 2022 (UTC)
  • I would love this! I have clicked these too many times and thought "gosh, I wish this actually took me to the list of changes with this tag". --Izno (talk) 23:04, 19 January 2022 (UTC)
    "find "tagged changes" through Special:RecentChanges" is another way, and it's a lot more troublesome than clicking the link directly. The tags also appears in watchlists, user contributions, and page history. Shizhao (talk) 02:45, 20 January 2022 (UTC)
    Great points! A link to see changes with the tag seems most intuitive, doesn't it. Well, let's see what people have to say! I also like the idea of serving some help text or what have you through the |title= attribute. I'm going to get this proposal setup for translation. MusikAnimal (WMF) (talk) 06:32, 21 January 2022 (UTC)
    I also did a little tweaking to the proposal that I hope is okay. Towards the end you were proposing a Special:Tags/tag_name page that shows only edits with this tag. Instead, I wrote it to utilize Special:RecentChanges for this purpose, which gives you many other features while still only showing the tagged edits. I hope this is okay :) Looking forward to seeing what people have to say! MusikAnimal (WMF) (talk) 07:18, 21 January 2022 (UTC)
  • see phab:T301063--Shizhao (talk) 08:36, 6 February 2022 (UTC)


  • Support Support — Draceane talkcontrib. 21:49, 28 January 2022 (UTC)
  • Support Support Izno (talk) 23:22, 28 January 2022 (UTC)
  • Support Support Shizhao (talk) 03:49, 29 January 2022 (UTC)
  • Support Support Jon Harald Søby (talk) 10:53, 29 January 2022 (UTC)
  • Support Support Aca (talk) 13:49, 29 January 2022 (UTC)
  • Support Support Steven Sun (talk) 00:19, 30 January 2022 (UTC)
  • Support Support Riha (talk) 14:09, 30 January 2022 (UTC)
  • Support Support Titore (talk) 18:09, 30 January 2022 (UTC)
  • Support Support Thingofme (talk) 01:46, 31 January 2022 (UTC)
  • Support Support The display name should appear at "MediaWiki:Tag-tagname" as plain text, and the help page should then be defined at "MediaWiki:Tag-tagname-help page" so that e.g. "visualeditor" would display as Visual edit (help). GeoffreyT2000 (talk) 04:24, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 06:18, 31 January 2022 (UTC)
  • Support Support Wargo (talk) 23:27, 1 February 2022 (UTC)
  • Support Support —— Eric LiuTalk 06:09, 5 February 2022 (UTC)
  • Support Support USI2020 (talk) 21:33, 5 February 2022 (UTC)
  • Support Support A no-brainer IMO. Waldyrious (talk) 23:55, 5 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 04:23, 6 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 06:32, 6 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 21:34, 6 February 2022 (UTC)

Enhanced Move Logs

  • Problem: When a page is moved, the log entry is associated with the old page, and not the new page. In order to find what the history behind how a page ended up where it is, you may have to dig through the move logs of other pages first. This makes it difficult to determine prior titles for a given page.
  • Proposed solution: Include both the source and destination in move logs, integrate these in to log displays.
  • Who would benefit: Editors
  • More comments: This proposal page is a good example. The move log is empty, however the page was moved from a different title.
  • Phabricator tickets: