Community Wishlist Survey 2019/Miscellaneous

17 proposals, 251 contributors, 455 support votes
The survey has closed. Thanks for your participation :)

New special page "Outgoing links"

  • Problem: The special page "What links here" shows the recent edits for all pages linked from a page. However, there's no way to see additional information about those linked pages, especially in the case of categories, WikiProject watchlists and media galleries. I think there should be a sister special page "Outgoing links" that shows a table with all the outgoing links and related information.
  • Who would benefit: Editors and experienced readers.
  • Proposed solution: The table of outgoing links should have sortable columns with the pages' name, first edit date, last edit date, file size, number of editions, and additional buttons to view "History", "Page information" and "Outgoing links".
  • More comments:
  • Phabricator tickets:


@NaBUru38: The 'Problem' section currently does not explain which underlying problem would get solved by such a special page, and why you need to see a list of outgoing links. Could you please clarify? Thanks! --AKlapper (WMF) (talk) 14:59, 31 October 2018 (UTC)Reply[reply]

There is an existing API module and database table that does exactly this. MER-C (talk) 15:24, 31 October 2018 (UTC)Reply[reply]
Ok, so we need a proper user interface for the existing API. To be usable, the information must appear in a sortable table, with web links as described in the proposal. --NaBUru38 (talk) 19:04, 6 November 2018 (UTC)Reply[reply]
@AKlapper (WMF), a problem that might be solved by the proposed feature is to find a picture in Commons to match a Wikipedia article. This image is not in use, but it has in the description links to several Wikipedia articles – 'Outgoing links' on Wikipedia could link to the information given on Commons, information that would otherwise be easyily missed. Jürgen Eissink (talk) 19:13, 7 November 2018 (UTC).Reply[reply]


Automatic display authority control template

  • Problem: There are a lot of articles at the bottom that have a authority control template, and a large number of articles have not yet added this template. If we can automatically display authority control template instead of manually adding it one by one, this aspect of maintenance will be greatly reduced.
  • Who would benefit: Wikipedia editors and readers
  • Proposed solution: Add a new message at the bottom of the page (Displayed above the category), authority control template or other content can be added here.
  • More comments:
  • Phabricator tickets:
  • Proposer: Shizhao (talk) 08:28, 5 November 2018 (UTC)Reply[reply]


There should be universal footer on every page, so not only Authority control but also Commonscat or some tracking categories should be here. JAn Dudík (talk) 09:06, 22 November 2018 (UTC)Reply[reply]


Separate templates in "What links here"

  • Problem: "What links here" does not distinguish incoming links made from templates (particularly navboxes) from direct links made in article text. That makes it hard to fix incoming links after a page move, particularly when creating a disambiguation page on the previous title, or deleting a page. The problem is aggravated by the database lag after updating template links (even if you retarget the offending template link, "what links here" will still display the transcluding page as being linked).
  • Who would benefit: All editors, particularly page movers, dab page resolvers, and admins deleting pages.
  • Proposed solution: 1) (Better) Indent links made from templates below the template listing, in the same manner as links to redirects 2) (Alternatively) Make sure that "What links here" is updated immediately after the offending template is edited, rather than with a lag (that takes between several minutes and a couple of hours, in my experience).
  • More comments:
  • Phabricator tickets: phab:T5241 (most apt), phab:T14396 (similar 2016 wishlist idea), phab:T3392 (one of many duplicates)
  • Proposer: No such user (talk) 09:45, 5 November 2018 (UTC)Reply[reply]


  • See also: Stop ifexist checks from appearing in Special:WhatLinksHereTheDJ (talkcontribs) 10:29, 5 November 2018 (UTC)Reply[reply]
  • It's not always that simple. If a link is part of the text passed into the template as a parameter, is that link from the template or not? What if the template generates the link by combining passed-in parameters?

    I note the proposed solution option #2 is likely impossible. When thousands of pages use a template, it's always going to take time to go through and reparse them all. Anomie (talk) 16:47, 5 November 2018 (UTC)Reply[reply]


Create a dissemination platform for Wikinews

  • Problem: People don’t usually go to Wikinews to search for its content. While reading Wikipedia is an active interaction, as we look for the content, reading news is usually a passive interaction on internet. We log on our platforms waiting for them to show us the news. Good or bad, that is a reality.
  • Who would benefit: Wikinews community
  • Proposed solution: Create a dissemination platform to reach readers on their usual place of interests, social networks. That platform would contain new articles of Wikinews and readers will be shown that. Whether it’s a blog, an App, a social network account, or all of them I am not sure, but Wikinews can’t beat all other medias that already are where the readers are.
  • More comments:
  • Phabricator tickets:
  • Proposer: —Teles «Talk to me ˱C L @ S˲» 22:08, 6 November 2018 (UTC)Reply[reply]


  • Thanks for your proposal, Teles. It sounds like you are asking for giving Wikinews articles more publicity using Wikimedia's social media accounts and official blog. Does that sound correct? -- NKohli (WMF) (talk) 21:49, 7 November 2018 (UTC)Reply[reply]
@NKohli (WMF): It would have to be something specific, like an app or a social media account for that purpose. That would have to be well integrated with on-wiki interface though and that’s the hard one. I know it may not perfectly fit with the purpose of Community Survey but I just wanted to provide food for thoughts for probably the only thing that could save Wikinews.—Teles «Talk to me ˱C L @ S˲» 18:40, 10 November 2018 (UTC)Reply[reply]
  • For your reference 1) Wikipedia home page features 'news section' with events which are over 3 days old whose 5Ws are painfully difficult to identify. Overcoming this problem requires a high degree of cooperation and learning which hinders the development of some of language editions of the Wikinews project. However Russian, Spanish, German Wikinews are productive and prolific and the comments below about sunsettings things are uncalled for in my opinion. 2) I don't think this proposal is about official blog of Wikimedia NKohli (WMF), I think it is about outreach to attract more people so if you know of any outreach experts or people who can do organizing workshops via online means etc it would be great. I am in the process of transforming how newcomers receive feedback on their first edits, however this is a slow process and as of now I am supported in my endeavours by only a small group. Having an expert from Wikimedia movement who could consult me on this would be great. (WM-AU are unsupportive, WM-RU is another language I speak and I have not yet queried them about this; this is on my todo.) --Gryllida 07:46, 23 November 2018 (UTC)Reply[reply]


  •   Support Liuxinyu970226 (talk) 08:43, 17 November 2018 (UTC)Reply[reply]
  •   Strong oppose I can support a proposal that chooses to terminate a comatose project.Winged Blades of Godric (talk) 08:11, 18 November 2018 (UTC)Reply[reply]
  •   Support NMaia (talk) 10:38, 18 November 2018 (UTC)Reply[reply]
  •   Support Benjamin (talk) 10:30, 19 November 2018 (UTC)Reply[reply]
  •   Support Novak Watchmen (talk) 01:35, 21 November 2018 (UTC)Reply[reply]
  •   Support Vulphere 04:50, 21 November 2018 (UTC)Reply[reply]
  •   Oppose Sadly, I believe that Wikinews has not succeeded as a project, and therefore promoting it is not a good idea. The project should probably be shut down, but the Wikimedia movement is notably bad at making the hard decisions when it comes to sunsetting things. --Deskana (talk) 11:56, 22 November 2018 (UTC)Reply[reply]
  •   Support interesting idea, poorly discussed at this point to be fair, I would be glad to discuss it in greater detail on-wiki Gryllida 07:36, 23 November 2018 (UTC)Reply[reply]
  •   Support Sahaquiel9102 (talk) 17:24, 23 November 2018 (UTC)Reply[reply]
  •   Oppose Victorgibby 03:02, 25 November 2018 (UTC) Wiki Tribune tarde o temprano va reemplazar a Wikinoticias y conserva el mismo formato MediaWikiReply[reply]
  •   Support — AfroThundr (u · t · c) 03:12, 26 November 2018 (UTC)Reply[reply]
  •   Oppose PMG (talk) 17:07, 26 November 2018 (UTC)Reply[reply]

Recover text of old revisions for the Massachusetts article

  • Problem: The deletion and undeletion events from 2005 were terrible events that have caused lots of old revisions from January 2005 and earlier for the Massachusetts article to have lost their text. This is a catastrophe that had never been fixed for over 13 years.
  • Who would benefit: Everyone
  • Proposed solution: Download some database dump from February 2005 and extract the Massachusetts article edits. Then create a temporary page (perhaps a talk subpage) containing the fact that the text had been lost, and use Special:MergeHistory to merge all of the article edits from 7 January 2005 and earlier to the temporary page's history. Next, delete the temporary page and restore the latest creation as well as the few earlier non-problematic revisions. After that, merge the earlier non-problematic revisions back to the Massachusetts article's history. Then, import all the old Massachusetts article edits from the database dump. And optionally, create a maintenance script that attempts to copy the text of the imported revisions to the corresponding deleted revisions for the temporary page, and rev_len and rev_sha1 to ar_len and ar_sha1 respectively. Unfortunately, this is more complicated due to the fact that MCR means that we are not going to have rev_text_id and ar_text_id fields anymore. Finally, re-delete the temporary page (optionally also).
  • More comments:



Wanted (by articles) pages

  • Problem: Difficult to easily see what pages are really missing on a site. Current Special:WantedPages such as voy:Special:WantedPages shows a list that are mainly red links on talk and project pages not main space article pages. Takes a lot of clicking to see really needed pages.
  • Who would benefit: Article authors looking for ideas for pages to create. Clean-up contributors looking for problem links.
  • Proposed solution: Create a page similar to Special:WantedPages but the number of redlinks shown to only be from mainspace pages and not talk and admin pages. One alternative idea is to make the existing page a table with a column showing number of redlinks from each namespace type (mainspace, talk of article, user page, template, ....) and make it possible to reorder the table based on descending number of each source page type.
  • More comments:
  • Phabricator tickets: T208935
  • Proposer: Traveler100 (talk) 18:35, 4 November 2018 (UTC)Reply[reply]


@Traveler100: Could it make more sense to allow filtering that list by namespace, instead of creating yet another special page? --AKlapper (WMF) (talk) 12:29, 5 November 2018 (UTC)Reply[reply]

A namespace filter on the existing page would be a good idea but remember it is not filtering the pages in the list but filtering the pages that link to the pages in the list and the number of links result needs to reflect the source red-links count not the target count. Not sure if that can be handled real-time with a filter. --Traveler100 (talk) 12:39, 5 November 2018 (UTC)Reply[reply]
Both filters would be nice. --NaBUru38 (talk) 20:48, 7 November 2018 (UTC)Reply[reply]
A real problem, this is ridiculously packed with lots of non mainspace items, echo the opinion that both filters will be nice to have. --Cohaf (talk) 21:10, 7 November 2018 (UTC)Reply[reply]
I'm afraid this suggestion only makes sense for editors but not for readers. ---Super Wang on zhwiki (Share your opinions) 23:53, 16 November 2018 (UTC)Reply[reply]
I do not see that that matters, and it is clear from Who would benefit. PJTraill (talk) 23:55, 26 November 2018 (UTC)Reply[reply]


Display more information about users on the user page

Example implementation of this idea by the userinfo.js user script
  • Problem: Right now, it takes a lot of clicking around to find out basic information about a user—how long they've been editing, how many edits they've made, what user rights they have, whether or not they're an admin, etc. There are a some external tools to help with this such as XTools, but it would be better if this information was readily available just from going to their user page. A popular user script, userinfo.js, does a nice job of this, but requires knowing about the script and installing it.
  • Who would benefit: Anyone who interacts with editors (admins, other editors)
  • Proposed solution: Convert most of the functionality from userinfo.js into an extension so that you can see basic user info directly on the user page.
  • More comments:


Isn't this provided by Wikipedia:Tools/Navigation popups ? Cabayi (talk) 08:06, 30 October 2018 (UTC)Reply[reply]
Oh, I didn't know that. Regardless it would be good to have this functionality baked into MediaWiki rather than having to use wiki-specific gadgets or user scripts. Kaldari (talk) 16:54, 30 October 2018 (UTC)Reply[reply]

I think it needs to be opt-in for my account, I don't want my privileges to be seen by others - I don't think it matters in most discussions.

I would think the number of edits does not matter in any circumstances as it may result in harsher attitude towards people who have not made any edits and

may result in people aiming to increase their edit count just to seem more important. Gryllida 22:39, 30 October 2018 (UTC)Reply[reply]

Account privileges are already visible to people using this script; the proposal is only asking for it to be made into a MediaWiki feature. Enterprisey (talk) 04:58, 31 October 2018 (UTC)Reply[reply]
I am not sure that it's a good idea to broadcast far and wide how many hats and edits - or how few - someone has. People routinely attach a lot more significance to these numbers than they deserve. Jo-Jo Eumerus (talk, contributions) 09:32, 2 November 2018 (UTC)Reply[reply]

Just saying, because this does not seem to have been mentioned or considered yet: The mobile design of Wikipedia already includes exactly this information for every diff view. See Special:MobileDiff/18448513 for example; you may need to scroll down to see it ToBeFree (talk) 19:19, 3 November 2018 (UTC)Reply[reply]

I guess when a user visits their user page they could be presented with a wizard that allows them to show/hide

  • their edit count
  • their contributions ({{Special:Contributions/Gryllida}})   Done
    • pages they created
  • their privileges
  • their participation at sister projects

the first step would be availability of this information as templates which they can put at their user page by hand. I think that's something Wikimedia Community Team could implement...?

I oppose implementing this hardcoded like the mobile diff mentioned above. --Gryllida 07:32, 23 November 2018 (UTC)Reply[reply]

Normally I favour transparency, but in this case, transparency could facilitate abuse. Having editor info prominently served up front-and-centre is the wrong emphasis, and potentially increases ease of wikihounding/harassment by new editors who may not yet have acclimated to WP conventions (e.g. edit reverts). I think new users should have to discover this functionality (e.g. via Wikipedia:Tools/Navigation popups, script etc) since in the process they will be exposed to more WP culture (in other words, I support the status quo, and I oppose hardcoding). The lack of opt-out is also a serious red-flag for me; if there was an opt-in I would be more inclined to support. ifny (talk) 03:08, 27 November 2018 (UTC)Reply[reply]


Save the revision that a translated article is based on

  • Problem: We, the another wikipedian (non English) try to translate mostly from English Wikipedia. When we create any article in another language, we frequently notice in spite of passing out several days, no edition has been done there. But in the meantime, we find so many editions in the same English wikipedia article. It is very difficult to us to find out the exact edition in English wikipedia.
  • Who would benefit: The translator who try to enrich a wiki article which is in another Wikipedia of different language.
  • Proposed solution: So, I suggest if any tool can be created and by using it we can understand the differences of editions which have been done in a specific wikipedian article page, it will be so beneficial to us for translating the information.
  • More comments:
  • Phabricator tickets:
  • Proposer: প্রলয়স্রোত (talk) 13:42, 11 November 2018 (UTC)Reply[reply]


@প্রলয়স্রোত: It's unclear to me what exactly is requested here... Why do you need to find the exact edition in English Wikipedia that corresponds to a version in another Wikipedia? I'm not sure I understand the underlying problem. When you translate an article from English Wikipedia, do you use mw:Extension:ContentTranslation? --AKlapper (WMF) (talk) 13:32, 12 November 2018 (UTC)Reply[reply]

@AKlapper (WMF): Assuming "editing" and "addition" were meant by "edition", this is a request for some sort of version control system, like the one used on multilingual projects (but using an English Wikipedia article as the source). I might be wrong, but it seems to make a lot of sense. Jc86035 (talk) 18:09, 12 November 2018 (UTC)Reply[reply]
@Jc86035: Does "some sort of version control system, like the one used on multilingual projects" mean something like that exists already? Could you provide some example link (or steps how to see that system)? Thanks! :) --AKlapper (WMF) (talk) 22:58, 12 November 2018 (UTC)Reply[reply]
@AKlapper (WMF): I was referring to mw:Extension:Translate (I forgot what it was called). Jc86035 (talk) 08:49, 13 November 2018 (UTC)Reply[reply]

How about putting an HTML comment in the source, like this: <!-- based on (2018-11-12) -->? PJTraill (talk) 23:50, 26 November 2018 (UTC)Reply[reply]

Hi প্রলয়স্রোত,

The extension for translating articles is Content Translation and not Translate. I'll assume that this wishlist item is about Content Translation.

Content Translation has saved the revision that a translated article is based on from the very start, since it was launched in January 2015. The link to this revision can be easily found in the edit summary of the first translated revision. For example, if you go to the article Haenyeo (হেনিয়ো), then to its revision history (ইতিহাস দেখুন), you'll see the edit summary on the oldest revision: ("Haenyeo" পাতাটি অনুবাদ করে তৈরি করা হয়েছে). "Haenyeo" is a link to the English Wikipedia article revision from which this article was translated. Does it address the request in the title of this wishlist item? --Amir E. Aharoni (talk) 11:30, 27 November 2018 (UTC)Reply[reply]

It is my bad not clearly express what I wanna say. I am going to give an example now: hope it will make sense of my statement:@AKlapper (WMF):,@Jc86035:,@PJTraill:,@Amire80:;
Optical physicist w:Donna Strickland received nobel in 2018. After getting nobel I translated wiki article on her to bangla wiki instantly. Hope, she will live longer but as law of nature she has to die. Suppose she would die on 2021. As of lack of our manpower in Bangla Wikipedia it might be happened that no bengali wikipedian would update her Bengali wiki biography between the three years. So after hearing her death news any of Bangla wikipedian would come to her bangla biograph and will try to compare bangla article with English article for knowing which info is not in Bangla wiki.
And it is very time consuming to read sentence by sentence to compare the two articles which is in different languages or to browse every history pages and it's editing. Because in those three years there may be more than thousand history pages in English wiki.
But, if there are a tool to check only those editings which exists only and can be shown in one page by setting date range, e:g: October 2018-November 2021, it would be helpful for the translator, especially for the large page like w:List of atheists in science and technology, w:Evidence of common descent etc. Sorghum 17:51, 28 November 2018 (UTC)


Stop ifexist checks from appearing in Special:WhatLinksHere

  • Problem: #ifexist is the parser function that checks if a page exists. It is also available as a Lua function. It is potentially a very useful function for Wikidata-enabled infoboxes as it can be used to discover redirects to existing articles (since allowing the creation of links to redirects in Wikidata has been under discussion since 2017 and is unlikely to be resolved soon). However, doing the check also makes a link appear in Special:WhatLinksHere - and that causes problems for Wikimedians who are checking links to disambiguation pages. It is not currently possible to stop that link from appearing.
  • Who would benefit: People writing template code who want to use #ifexist to provide extra functionality, but currently can't as it causes. People doing disambiguation checking while people are using #ifexist statements.
  • Proposed solution: Either stop #ifexist from creating a link in Special:WhatLinksHere, or create a new magic word that does the same as #ifexist without creating the link.


See also: #Separate_templates_in_"What_links_here"TheDJ (talkcontribs) 10:28, 5 November 2018 (UTC)Reply[reply]


Clear roadblock for wiki site URL changes

  • Problem: The domains of several Wikimedia wikis should be renamed. This was done once, when was renamed to, but this renaming exposed several issues. Performing any more renaming is not advised until these issues are resolved.
  • Who would benefit: Users of wiki sites pending for rename.
  • Proposed solution: Clear roadblock for wiki project language code changes so that they can be changed
  • More comments: It have been a decade since these renaming were initially requested.


  • @C933103: It looks like the link Phabricator task has been resolved. Regardless, I don't think this is something Community Tech could help with, as it isn't a matter of software development but rather site operations and/or systems administration. Perhaps I am missing something? MusikAnimal (WMF) (talk) 22:26, 30 October 2018 (UTC)Reply[reply]
    • @MusikAnimal: Ah I have manually typed a wrong phab code. It have been updated and corrected. While the actual process for site renaming is related to site operation and administration, it seems like there are things that prevent it to occur that are blocking it at a more general level.C933103 (talk) 01:14, 31 October 2018 (UTC)Reply[reply]
Note that this is currently blocking creation and translation of Wikipedia into certain language projects. C933103 (talk) 08:21, 9 November 2018 (UTC)Reply[reply]
Currently nowiki is effectively perpetrating linguistic discrimination due to a domain and language code anomaly, and an age-old language conflict. This proposal would potentially make it possible for us to find a way out of this embarassing situation. - Soulkeeper (talk) 16:22, 9 November 2018 (UTC)Reply[reply]


Every special page that accepts wikitext should have normal editor toolbar

  • Problem: None of the Mediawiki editing extensions currently in use (like search and replace and CharInsert) are available for use with ExpandTemplates. Another missed opportunity, when previewing templates and template code is the inability to review the "Parser profiling data" to monitor and manage the work being done with respect to technical limitations.
  • Who would benefit: Any editor who uses the ExpandTemplates special page will benefit by having these editing extensions available when using that page for its intended purpose.
  • Proposed solution: I propose that the "input pane" be modified to mimic the "editing pane" used across our Wikimedia projects. And when input is rendered for preview, along with a visualization of the template/syntax after expansion, provide the "Parser profiling data", as well, to show the efficiency of said expansion when rendering said preview. I can hardly imagine another time when the information would be more empowering than when expanding/previewing templates and syntax on the ExpandTemplates special page.
  • More comments: If a Special NavBar is created — tailored to the unique purpose and needs of this special page — that would certainly be great! But, that is not what I am proposing at this time. I will be happy with the same "add-on array", currently in use, without modification. In my opinion it will be an immediate improvement to the ExpandTemplates page the moment these features become available. Thank you for considering this proposal.
  • Phabricator tickets: I am not aware of any.


@John Cline: So you want to make the Special:ExpandTemplate debug page, a full fledged Template editor or something, if I understand correctly ? —TheDJ (talkcontribs) 14:29, 2 November 2018 (UTC)Reply[reply]

I would like the page to mimic the full editing experience by making the header bar available (particularly for its "advanced" and "help" features) and a footer array of "Insertable wiki markup" (which could be customized to insert the most common "variables" and "conditional expressions" used in template code) without, of course, the footer bar (which allows the edit summary, marking change as minor, and publishing changes). I hope this has answered your question; please follow-on if it has not. Thank you.John Cline (talk) 15:26, 2 November 2018 (UTC)Reply[reply]


Global signature

  • Problem: For people who would like to have some uniqueness in their signatures, the default signature has to be re-configured over and over again every time we entered a new Wiki project. Besides, for people with non-latin usernames (like me), they might want to display a more recognizable, possibly Romanized signature on other Wiki Projects, and a more complicated username in their home wiki.
  • Who would benefit: Cross-wiki users; people having non-latin characters in their user names, and people reading their comments
  • Proposed solution: A global signature (maybe the one used in
  • More comments: I also hope that the default signature can be bolded, because the current plain link just make it merge into the discussions, and indistinguishable from other blue links.
  • Phabricator tickets: T188200
  • Proposer: 燃灯 (talk) 18:46, 4 November 2018 (UTC)Reply[reply]


  • Why doesn't just putting it in Special:GlobalPreferences work for this? BWolff (WMF) (talk) 02:15, 5 November 2018 (UTC)Reply[reply]
  • Translating scripts would probably make it easier for people unfamiliar with some scripts to recognize editors. But this might also make names unrecognizable across wikis; many people have natural names in multiple languages which are not obviously related to one another. If this gets implemented, could we please have a Languages section in the sidebar of user pages so that it's obvious what other names a user uses? HLHJ (talk) 03:03, 18 November 2018 (UTC)Reply[reply]
  •   Comment This could cause issues if global is the only option. I for example have a different sig here than on (the one here specifically targets to user page, where if the en one was used here it would target my meta user page). — Insertcleverphrasehere (or here) 15:34, 23 November 2018 (UTC)Reply[reply]
@Insertcleverphrasehere: How is your signature compatible with conventions, as there is no link to either your user page or your talk page in this project included, just links to outside this project? Grüße vom Sänger ♫(Reden) 05:26, 26 November 2018 (UTC)Reply[reply]
Sänger My user and talk pages on are the only ones that I maintain actively, therefore my signature directs to those. — Insertcleverphrasehere (or here) 08:54, 26 November 2018 (UTC)Reply[reply]