Community Wishlist Survey 2021/Miscellaneous

27 proposals, 405 contributors, 772 support votes
The survey has closed. Thanks for your participation :)

Make CentralAuth extension to log actions everywhere

  • Problem: The CentralAuth extension doesn't log some actions on every wiki but just the wiki from where the action was performed (for Wikimedia, It's Meta-Wiki). This also makes us to have a local Steward and a local Global Renamer user group on Meta to keep the logs on Meta. If someone wants to see the logs then they will have to visit Meta-Wiki, this is really annoying. List of logs:
· Special:Log/gblblock (globalblock), You can't see logs of global IP blocks from wikis other than Meta.
· Special:Log/globalauth/Special:CentralAuth (centralauth-lock), You can't see logs of global account locks/unlocks and hide/unhide (private, only shown to users with centralauth-lock) from wikis other than Meta.
· Special:Log/gblrename (centralauth-rename), You can't see logs of global account renames from wikis other than Meta, You can see log entry at Special:Log/renameuser only if the account is locally created.
· Special:Log/gblrights (globalgroupmembership/globalgrouppermissions), You can't see logs of global user rights and global group management changes from wikis other than Meta.
  • Who would benefit: Everyone
  • Proposed solution: Make CentralAuth extension to log actions everywhere. Some third-party sites who use CentralAuth may don't want this, so add option to disable it.
  • More comments:
  • Phabricator tickets:
  • Proposer: CptViraj (talk) 05:32, 17 November 2020 (UTC)Reply[reply]


Seems like this will either take a lot of technical work (to mirror everything) or it will require many more (hundreds more times) database entries - one for every wiki for every logged action. KevinL (aka L235 · t) 01:05, 11 December 2020 (UTC)Reply[reply]

I'm wondering why this could not be implemented similar to universal login? - Jc37 (talk) 16:14, 15 December 2020 (UTC)Reply[reply]


Default languages for Captions and Descriptions on Wiki Commons

  • Problem: When uploading new pictures on Wikimedia Commons, you have to click "Add a caption in another language" and then again "Add a description in another language" for each picture, and for each language. When you can speak several languages, and you want to contribute as much as you can, this leads to a number of unnecessary, annoying clicks and it takes too much time, if you upload more pictures at once, as you have to do this with every language for every picture twice.
  • Who would benefit: every contributor using more languages
  • Proposed solution: I propose to add option of default languages (with possibility to choose more languages) for user, so you could choose several languages you speak and use, and after uploading a picture, caption and description boxes in these languages would be added automatically to each picture.
  • More comments:
  • Phabricator tickets:
  • Proposer: Lukáč Peter (talk) 21:51, 25 November 2020 (UTC)Reply[reply]



Expand signature length

  • Problem: The signature in Wikipedia is limited to some words. However, some users want a large signature consisting of more words. But they are bound to the short signature. I also faced the problem. And couldn't select my favourite signature due to its short length.
  • Who would benefit: Everyone
  • Proposed solution: Expand the length of signature to double or triple.
  • More comments: All above
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 09:04, 30 November 2020 (UTC)Reply[reply]


  • Signatures are used to indicate authorship of comments, and they seem to work well for this purpose as they are. How would this proposal improve this? Silver hr (talk) 01:13, 1 December 2020 (UTC)Reply[reply]
Although they work fine, I know. However, they should be a bit longer. Therefore, they must be expanded to a few more words or bytes. Thank you. Empire AS (talk) 09:59, 1 December 2020 (UTC)Reply[reply]
  • Can you provide some examples of signatures that would benefit, both in the currently limited form, and the desired form? --DragonHawk (talk) 19:26, 8 December 2020 (UTC)Reply[reply]
Yes I can. In the past I wanted this signature (Empire AS Talk!) but due to the its length, I couldn't get it. And I used this signature (Empire AS Talk!) instead as it was shorter. Therefore, I made this proposal to expand its length. It was all that I explained. Thank you. Empire AS (talk) 07:30, 9 December 2020 (UTC)Reply[reply]
  • Forbid any formatting in signatures, those penis prosthetics are just annoying. Grüße vom Sänger ♫(Reden) 22:45, 19 December 2020 (UTC)Reply[reply]


  •   Weak oppose This might allow people to abuse said signatures. I am really not positive about this idea. MarioSuperstar77 (talk) 19:57, 8 December 2020 (UTC)Reply[reply]
  •   Oppose People willing to say a lot about themselves have ample sufficiency to do so on their user page. Worth remembering Wikipedia is an encyclopedia, not a social media. Plus long words/signatures are not beginner-friendly. It took me ages to discover how I could interact with some who had special signatures. --Braveheidi (talk) 21:17, 8 December 2020 (UTC)Reply[reply]
  •   Oppose No good reason was given for this. Silver hr (talk) 21:21, 8 December 2020 (UTC)Reply[reply]
  •   Weak oppose Not against it in theory but I've never seen any examples where a signature is too long for the current system // Lollipoplollipoplollipop :: talk 03:09, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose per MarioSuperstar77, Braveheidi, and.....Lollipoplollipoplollipop Firestar464 (talk) 05:46, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose --Ján Kepler (talk) 14:32, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose! This may end up allowing stories or short bios included in a signature instead of it to serve as just a sign. Em-mustapha User | talk 14:36, 9 December 2020 (UTC)Reply[reply]
  •   Strong opposeputnik 18:31, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose - Cabayi (talk) 20:29, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose totally unnecessary. One can be distinctive with fewer characters. Long signatures are also sometimes disruptive to the readability of discussions.Possibly (talk) 07:01, 10 December 2020 (UTC)Reply[reply]
  •   Oppose Libcub (talk) 19:37, 10 December 2020 (UTC)Reply[reply]
  •   Oppose per Braveheidi — OwenBlacker (Talk) 21:40, 10 December 2020 (UTC)Reply[reply]
  •   Oppose Users who have extra stuff to say or show off can just put it on their userpages. Some1 (talk) 05:09, 11 December 2020 (UTC)Reply[reply]
  •   Strong oppose — --Noel baran (talk) 16:45, 11 December 2020 (UTC)Reply[reply]
  •   Strong oppose --Kusurija (talk) 19:00, 11 December 2020 (UTC)Reply[reply]
  •   Support -Xbony2 (talk) 19:46, 11 December 2020 (UTC)Reply[reply]
  •   Strong oppose. Long signature code just clutters page's source code and is usually used by people who like to put an excessive amount of colours, links and other unnecessary stuff in their signature. So no, hard no on this proposal. Meiræ 22:24, 11 December 2020 (UTC)Reply[reply]
  •   Strong oppose is just a sign. Francois-Pier (talk) 12:01, 12 December 2020 (UTC)Reply[reply]
  •   Strong oppose Ad Huikeshoven (talk) 14:19, 12 December 2020 (UTC)Reply[reply]
  •   Oppose Philiptdotcom (talk) 14:19, 14 December 2020 (UTC)Reply[reply]
  •   Oppose --WTM (talk) 00:48, 15 December 2020 (UTC)Reply[reply]
  •   Strong oppose — TARDIS Builder (talk) 00:42, 16 December 2020 (UTC)Reply[reply]
  •   Oppose PorkchopGMX (talk) 12:49, 16 December 2020 (UTC)Reply[reply]
  •   Strong oppose en: totally exaggerated / de: völlig übertrieben --Dirk123456 (talk) 09:08, 18 December 2020 (UTC)Reply[reply]
  •   Strong oppose Grüße vom Sänger ♫(Reden) 21:47, 18 December 2020 (UTC) I'd say: disallow useless bling in signatures, especially any <span>-junk, that's are just an eyesore.Reply[reply]
  •   Oppose per Braveheidi et al. —2d37 (talk) 09:11, 21 December 2020 (UTC)Reply[reply]
  •   Support <span> tags take many symbols. Golmore (talk) 12:25, 21 December 2020 (UTC)Reply[reply]
  •   Oppose Signatures are supposed to be short and simple. Nachtbold (talk) 12:41, 21 December 2020 (UTC)Reply[reply]
  •   Oppose--David1010 (talk) 13:19, 21 December 2020 (UTC)Reply[reply]

Allow sanitized-CSS to use pointer-events

  • Problem: Currently sanitized-CSS does not support pointer-events.
  • Who would benefit: Sanitized-CSS users
  • Proposed solution: As indicated by the title
  • More comments:
  • Phabricator tickets:
  • Proposer: Pseudo Classes (talk) 05:26, 19 November 2020 (UTC)Reply[reply]


@Pseudo Classes: I haven't looked into this, but this might be intentional, as it might not be desirable to fake certain pointer events and it might be used in situations of phising or something. Please make a better Problem description of where and how you would use this pointer-events (examples), so that the usefulness and risk can be eveluated. —TheDJ (talkcontribs) 11:01, 20 November 2020 (UTC)Reply[reply]
@TheDJ: Sorry, I’m not sure I understand. Why pointer-events property might be abused? Pseudo Classes (talk) 02:49, 21 November 2020 (UTC)Reply[reply]
K. checked. the reason why pointer-events is not supported, is because it is CSS that is part of the SVG2 module which is not included in the sanitizer right now. It will also be added to the upcoming CSS level 4, but the sanitizer only supports Level 3. —TheDJ (talkcontribs) 12:21, 21 November 2020 (UTC)Reply[reply]
  • I'm not sure what pointer-events are, and I doubt I'm alone in that. Would someone be able to explain it to help voters here assess the request? {{u|Sdkb}}talk 08:51, 9 December 2020 (UTC)Reply[reply]
The pointer-events CSS property sets under what circumstances (if any) a particular graphic element can become the target of pointer events. If set to none, the cursor will not change. See WhoAteMyButter (talk) 04:48, 13 December 2020 (UTC)Reply[reply]


  •   Oppose I really do not believe that to be a good feature. MarioSuperstar77 (talk) 19:53, 8 December 2020 (UTC)Reply[reply]
  •   Weak support Can be utilised to make cool user pages, but not very practical in articles. H78c67c (talk) 01:12, 10 December 2020 (UTC)Reply[reply]
  •   Support Ciao • Bestoernesto 04:10, 10 December 2020 (UTC)Reply[reply]
  •   Oppose en: What use? - lack of justification / de: Welcher Nutzen? - fehlende Begründung. --Dirk123456 (talk) 09:58, 18 December 2020 (UTC)Reply[reply]

Input Forms

  • Problem: Currently, many Wikipedia processes require users to fill out information. This range from edit requests to edit filter reports to all sorts of nominations. The current solution is usually using preload templates, asking users to fill in details as template parameters. This can be very confusing to users unfamiliar with the template syntax, especially newcomers. “What does <!-- —>mean? Where do I fill in the page title?” some users may try to figure out how the seemingly baffling template syntax works, but most would probably give up, frustrated.
  • Who would benefit: Newcomers who have little understanding of template syntax and experienced users who could address the newcomers' issue more easily
  • Proposed solution: I could think of 2 ways to solve this. First way is an overhaul of the InputBox extension, allowing the creation of forms with multiple text fields and, if possible, even other controls (switches, checkboxes, etc.) The second way may be a gadget that displays an intuitive input form to users, in which the form is constructed by reading, for example, a JSON containing the form structure.
  • More comments:
  • Phabricator tickets:
  • Proposer: H78c67c (talk) 07:11, 17 November 2020 (UTC)Reply[reply]


  • Seconded. Keepcalmandchill (talk) 11:05, 17 November 2020 (UTC)Reply[reply]
  • I think the Page Forms extension was written for this. Maybe it only needs some work to be available on Wikimedia wikis as well? --Matěj Suchánek (talk) 16:58, 17 November 2020 (UTC)Reply[reply]
    @Matěj Suchánek: from what I can tell, not exactly. The Page Forms extension is for creating or editing pages with structural data, including those inside templates, which is already partially achieved with VisualEditor and TemplateData. What I am proposing is almost like InputBox, but with support for multiple form inputs, not just one. Please correct me regarding the Page Forms part if I am wrong. H78c67c (talk) 06:50, 18 November 2020 (UTC)Reply[reply]
    You are maybe right. Sorry, but I am not that much familiar with Page Forms. In fact, I recalled a comment from this my task (which would benefit from this proposal, right?) but that comment mentions a tool called "FormWizard". --Matěj Suchánek (talk) 11:10, 18 November 2020 (UTC)Reply[reply]
    mw:Extension:FormWizard is almost exactly what I’m looking for! I wonder what needs to be done to install it on WMF wikis. H78c67c (talk) 15:39, 18 November 2020 (UTC)Reply[reply]
  • I am almost finished with WSForm (although I have been saying that for a long time), but I guess that is what you are looking for. Not much use now, as its not released yet. Just thought I'd mention it, here's a small intro to WSForm.


Make deleted edits visible to their author

  • Problem: Make the deleted edits visible to its author. Deleted edits are restricted to admins and checkusers. I think that a user should be able to see his/her deleted edits not of others.
  • Who would benefit: All users who would like to see their deleted edits
  • Proposed solution: Just make the edits visible to their authors.
  • More comments: All above.
  • Phabricator tickets:
  • Proposer: Empire AS (talk) 07:01, 22 November 2020 (UTC)Reply[reply]


There should be some security problems, but at least I would like to see titles of deleted pages I had edited - useful eg in commons - according to name I can search it in log and maybe made new upload with correct licence. JAn Dudík (talk) 09:43, 23 November 2020 (UTC)Reply[reply]

I think that there would be no problems regarding security. A user should be able to see only his/her edits, not of others. So, in future, he/she might stop the increase in his deleted edits. Empire AS (talk) 11:42, 23 November 2020 (UTC)Reply[reply]
No. This will let people just posting their deleted spam / defamatory posts / vandalisms/ hoaxs etc more easier w/o the need to keep it somewhere else. Camouflaged Mirage (talk) 11:53, 23 November 2020 (UTC)Reply[reply]
I support any version of this proposal that can provide me with a *minimum* of information about *which* of my edits were deleted (I agree here with JAn Dudík's comment). If I'm not mistaken, as it currently stands we can only find info about deleted pages but not deleted edits. I just need some kind of info for reference/tracking purposes, especially in order to understand what was deleted and *why* so that I don't repeat my mistakes again (I agree here with Empire AS's comment). And for added safety allow this function/privilege only to the authors of the deleted edits who are also *Extended-Confirmed* users. Cordially, History DMZ (talk) 19:33, 8 December 2020 (UTC)Reply[reply]

@Martinkunev: Well you shouldn't be able to view deleted edits right now, you do not have admin rights on any Wikimedia wikis. The deleted edits here refer to the content of deleted pages and revisions, not text simply removed from the page and publicly visible on the history page. H78c67c (talk) 01:18, 9 December 2020 (UTC)Reply[reply]

  • Editors wouldn't use these deleted edits to repost their 'deleted spam / defamatory posts / vandalisms/ hoaxs etc more easier' but they'll stop making such edits after knowing to them, I guess. I may tell an incident here that in the beginning when I was too new, I used Xtools to see my edits + the no. of deleted edits. However, the number of deleted edits was increasing day by day and I didn't even knew how or why it was happening. Therefore, I reached an admin who told me that most of my deleted edits are from my sandboxes. Then I understood my mistake that I didn't move the sandboxes to the articles but rather used copy-paste method and tagged sandboxes with G7. However, after knowing, I controlled the increase in my deleted edits by moving them. If I really knew this before (that was possible if I was able to see my deleted edits), then I wouldn't have big no. of deleted edits. Besides this, deleted edits would also help users to understand what sort and type of their content was deleted and why so happened. They would be able not to repeat such mistakes in future, and such content (like deleted spam / defamatory posts / vandalisms/ hoaxs etc) wouldn't be uploaded anymore. The backlog of WP:REFUND would also decrease. Thank you. Empire AS (talk) 10:00, 9 December 2020 (UTC)Reply[reply]

Reading the opposing comments I'd just like to make a point: spammers could always have a copy of what they published, whether this feature is available or not. H78c67c (talk) 01:06, 10 December 2020 (UTC)Reply[reply]

They could, H78c67c. But we don't need to help them, or to make it unnecessary to keep a copy. Cabayi (talk) 14:13, 15 December 2020 (UTC)Reply[reply]

Do you mean you'd like the developers to develop :-

-- Cabayi (talk) 14:13, 15 December 2020 (UTC)Reply[reply]
Those are lists of pages we created (which still exist). That sort of format would work, but instead it might show edits we made to pages which have now been deleted. To address other editors' concerns, we might not want to make the text available, just the editor, timestamp and edit summary (unless revdeled, of course). The proposal wouldn't give me access to anything secret: I can now download my contribution history daily and save it locally in case a page gets deleted, but the suggested change would be more convenient for me and avoid bothering the server by regularly downloading data I'll never read. Certes (talk) 14:28, 15 December 2020 (UTC)Reply[reply]
I echo Certes here, the above format suggested by Cabayi (if applied to deleted *edits*) could work. It would include the timestamp, page title, and edit summary. But it's missing the log link with the admin's reason for deletion (see XTools example below, next to my vote). Cordially, History DMZ (talk) 15:43, 15 December 2020 (UTC)Reply[reply]
@Cabayi: Yes, something like that, but I will see exactly this and you this. JAn Dudík (talk) 14:47, 16 December 2020 (UTC)Reply[reply]
  • Exposing deleted edit content needs to be on a per-edit basis, set by an administrator, and only if the request is in accordance with a "what admins are allowed to let contributors see" per-project policy. I think the API already allows you to see certain meta-content of deleted edits, including who made them, how big the edit was, and the timestamp on the edit, tags, but not the edit summary or content. Making it easier to see this already-accessible content, perhaps via a gadget or external tool, would be a good thing. Davidwr/talk 16:29, 21 December 2020 (UTC)Reply[reply]


  •   It is doubtful I am unsure whether it is a good idea or not. On one hand you allow them to learn why it was deleted. On the other hand, edits only get deleted if they're offensively bad from what I have seen, so if they can review their edits, they can just copy that and slap that back into the article on a new revision and the admins will have to delete that edit again. MarioSuperstar77 (talk) 19:40, 8 December 2020 (UTC)Reply[reply]
@MarioSuperstar77: I don't think that it would happen anymore. As I can guess, an editor would use deleted edits to stop them from happening in future. Therefore, they would not repeat such edits anymore and admins would've no need to delete that edits again when they wouldn't be even made. Thank you. Empire AS (talk) 10:13, 9 December 2020 (UTC)Reply[reply]
  •   Support. At least, let us see the same info we already see about deleted pages, like Jimbo Wales example. History DMZ (talk) 19:41, 8 December 2020 (UTC)Reply[reply]
  •   Support Chaddy (talk) 19:43, 8 December 2020 (UTC)Reply[reply]
  •   Support Trang Oul (talk) 19:58, 8 December 2020 (UTC)Reply[reply]
  •   It is doubtful towards   Oppose In my experience, many, very many editors would use this to immedately restore the edit by pasting their edit back into the live edit box (especially trolls and PR folks who know what they are doing. If you do decide to implement this, add a checkbox "Allow the user to see this edit", though I dont see how edits that are revision deleted would improve the encyclopedia at all, since revision deletion is often used for a reason. (including by these guys) Victor Schmidt (talk) 20:11, 8 December 2020 (UTC)Reply[reply]
@Victor Schmidt: According to your view point it would happen. But as I see and can guess, I don't agree with you. Deleted edits visibility may help users to stop rehappening them and admins working here may help there in any other field of encyclopedia instead of deleting revisions that were happening due to not knowing the reason of their deletion. Thank you. Empire AS (talk) 10:26, 9 December 2020 (UTC)Reply[reply]
  •   Support --NGC 54 (talk / contribs) 20:16, 8 December 2020 (UTC)Reply[reply]
  •   Weak oppose The proposal seems unclear to me - I can always go to history and see the edits. I don't see a problem that this solves. Martinkunev (talk) 20:22, 8 December 2020 (UTC)Reply[reply]
@Martinkunev: the proposal isn't about live edits. It is about that edits that are deleted known as 'deleted edits' only visible to admins checkusers, oversighters etc but not to even their authors. Thank you. Empire AS (talk) 06:22, 10 December 2020 (UTC)Reply[reply]
  •   Support of visible titles, not content JAn Dudík (talk) 20:45, 8 December 2020 (UTC)Reply[reply]
  •   Support , even if just the page title and edit summary without text. Certes (talk) 21:10, 8 December 2020 (UTC)Reply[reply]
  •   Oppose I just can't see the point. And this is just the tool mass-spammers are waiting for, so nope, not a very good idea. --Braveheidi (talk) 21:22, 8 December 2020 (UTC)Reply[reply]
  •   Oppose, in the very rare instance where this wouldn't be abused, the user can just ask an admin to tell them what happened. Abductive (talk) 23:41, 8 December 2020 (UTC)Reply[reply]
  •   Support This makes sense. I may be more worried about the risk of account theft and expect it to have a validity period. YFdyh000 (talk) 23:47, 8 December 2020 (UTC)Reply[reply]
  •   Weak support for this one. This would reduce workload on WP:REFUND (especially on zhwiki). H78c67c (talk) 01:21, 9 December 2020 (UTC)Reply[reply]
  •   Oppose on the grounds that this is better discussed as an issue of community consensus, not a feature request. {{u|Sdkb}}talk 08:44, 9 December 2020 (UTC)Reply[reply]
  •   Strong support per the proposal made by me. Empire AS (talk) 10:34, 9 December 2020 (UTC)Reply[reply]
  •   Support Jjkorff (talk) 13:58, 9 December 2020 (UTC)Reply[reply]
  •   Oppose Per Sdkb. --Ján Kepler (talk) 14:33, 9 December 2020 (UTC)Reply[reply]
  •   Oppose per the opposers! Em-mustapha User | talk 16:04, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose - we don't need to provide assistance to spammers. Cabayi (talk) 20:36, 9 December 2020 (UTC)Reply[reply]
  •   Oppose NMaia (talk) 23:57, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose Nothing like allowing our COI spammers and expletive flinging vandals to copy and paste their deleted content so they can spam it back even faster. CaptainEek Edits Ho Cap'n! 03:18, 10 December 2020 (UTC)Reply[reply]
  •   Strong support Ciao • Bestoernesto 04:13, 10 December 2020 (UTC)Reply[reply]
  •   Strong oppose per CaptainEek. Possibly (talk) 07:10, 10 December 2020 (UTC)Reply[reply]
  •   Support Kisnaak (talk) 22:28, 10 December 2020 (UTC)Reply[reply]
  •   Oppose Edits are deleted for a reason. This just opens it up for easy "undo". —  HELLKNOWZ   ▎TALK   ▎enWiki 22:28, 10 December 2020 (UTC)Reply[reply]
  •   Support   Oppose test JonathanLa (talk) 18:49, 11 December 2020 (UTC)Reply[reply]
  •   Oppose This should be decided by the communities themselves. I can think of several negative consequences. SarahSV talk 04:50, 12 December 2020 (UTC)Reply[reply]
  •   Support  Klaas `Z4␟` V:  16:11, 12 December 2020 (UTC)Reply[reply]
  •   Support Make the titles visible, oppose making content visible. It provides clear feedback to good faith editors, while bad faith editors...will eventually be blocked anyways. Shushugah (talk) 19:26, 13 December 2020 (UTC)Reply[reply]
  •   Weak support Only titles, per JAn Dudík. — Draceane talkcontrib. 13:14, 15 December 2020 (UTC)Reply[reply]
  •   Support Thanks, EDG 543 (message me) 15:09, 15 December 2020 (UTC)Reply[reply]
  •   Support I've seen it where a new user creates incomplete article, it gets deleted next day, and the admins refuse to reinstate or move it to draft. This just feeds some of the admins egos and puts off new users. Wolfmartyn (talk) 14:38, 16 December 2020 (UTC)Reply[reply]
  •   Support Golmore (talk) 18:34, 16 December 2020 (UTC)Reply[reply]
  •   Support Kku (talk) 07:48, 17 December 2020 (UTC)Reply[reply]
  •   Support conditionally. I am active in copyright issues but not active in vandalism reversion. Much of the opposition relates to vandalism issues. Speaking about copyright issues, it is quite common that I identify what appears to be a copyright violation, then do a revision deletion to hide the material, per policy. It is not uncommon (dozens of times each year) that the editor will challenge the claim, believing that it is not a copyright violation. However, because they can no longer see the material, that makes it difficult to discuss. My usual procedure is to undo the revision deletion, give them time to review the material possibly copy at off-line for further review, then asked them to let me know when they are done and then redo the revision deletion (obviously only if they are wrong, which they almost always are). This is a rather tedious sequence of events. If the material remained not visible to all editors except the editor who added it, then they could check the material, confirm that it actually is a copyright violation or enter into a discussion with me if they disagree. Much simpler. I don't know whether it's feasible but the obvious refinement to this feature request would be to allow viewing by the editor in the case of a revision deletion for copyright reasons, but not for vandalism reasons. If that's not feasible, then we have to think through whether the harm and allowing vandals to see the edit outweighs the benefit to allowing copyright violators to see the edit.--Sphilbrick (talk) 16:04, 17 December 2020 (UTC)Reply[reply]
  •   Oppose while it could be educational for nice users, it would facilitate the not-nice-at-all users aka vandals Shenme (talk) 01:56, 18 December 2020 (UTC)Reply[reply]
  •   Support Oh, that would be awesome! If there are concerns about vandals, just turn it off for users who are not autoconfirmed. Uanfala (talk) 00:00, 20 December 2020 (UTC)Reply[reply]
  •   Oppose Why? USI2020 (talk) 19:03, 20 December 2020 (UTC)Reply[reply]
  •   Oppose Nachtbold (talk) 12:33, 21 December 2020 (UTC)Reply[reply]

Display default/recommended values at Special:Preferences

  • Problem: At Special:Preferences, it's impossible to know which settings you have changed away from the default (or have acquired a new default value since you signed up) without doing a full reset.
  • Who would benefit: All editors who like to customize their settings, and particularly longer-term editors who may not be aware that some settings have acquired new default values.
  • Proposed solution: Show some kind of default indicator, as mocked up by Quiddity.
  • More comments: This was discussed at en-WP at Wikipedia:Village pump (proposals)#Clearly display each Default setting at Special:Preferences and received clear support.
  • Phabricator tickets: task T70689
  • Proposer: {{u|Sdkb}}talk 03:03, 17 November 2020 (UTC) (but really mostly Nick Moyes, who put forward the Village pump discussion, and Quiddity)Reply[reply]



Improve pdf outprints

  • Problem: PDF does not work anymore
  • Who would benefit: Anyone who wants to use wiki in printed form
  • Proposed solution: Make PDF possible again. In older times there were two versions: text in one column including tables and text in two columns excluding tables. It would be desirable if the text could come in two columns and including tables as well as images in a suitable format (eg image (s) with text next to it in full page width). This would make the printout more "professional" in its design.

On the same occasion, the text should be corrected so that text arranged in list form (with numbers or hyphens) gets the same form as other running text (which was not the case before).

It is desirable if it becomes possible to edit a pdf layout and update the appearance until it gets the desired look prior to printing.

  • More comments: Not all people are computer geniuses, so the possibility to the ability to edit the text should be fairly simple to understand.
  • Phabricator tickets:
  • Proposer: Sven Halfdan Nielsen (talk) 07:19, 17 November 2020 (UTC)Reply[reply]


  Comment It's possible to download PDF with Chrome, but not for Firefox. We need also to do a review of this. I'm not sure if it's the same problem or one different, but apparently are related. --Ganímedes (talk) 09:48, 17 November 2020 (UTC)Reply[reply]

@Ganímedes: can you elaborate ? It works just fine for me. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)Reply[reply]

  Comment I'm a teacher, I sometimes use wikibooks with my students and this could be an important improvement, because they often need a good print version in order to follow properly the activities during the lesson in class. The majority of students don't have digital devices so a good print would help a lot.--AGeremia (talk) 11:04, 17 November 2020 (UTC)Reply[reply]

@AGeremia: I would file a separate request for book rendering to PDF, as this also requires combining multiple wikitext pages into a single document, which is a complex procedure with much additional logic. Please do file that as a separate request. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)Reply[reply]

  Comment @Sven Halfdan Nielsen: "Make PDF possible again". PDF already is possible, most wikis have a "Download as PDF" link right in the left column. Can you be more specific perhaps about where and when it does not work for you ? I also see you'd with additional layout options, which seems like a separate request from 'make pdf possible again".. —TheDJ (talkcontribs) 11:45, 17 November 2020 (UTC)Reply[reply]

@TheDJ: - when I made the proposal, I got the message, that it was not possible to download in pdf at all. But also: previously there were two different possibilities: one in two columns and one in full page. Later the two column possibility disappeared. I should like to see BOTH those possibilities restored. In fact, I should like possibilities to edit pdf-formats before saving/printing (but perhaps that is another theme). Sven Halfdan Nielsen (talk) 12:18, 17 December 2020 (UTC)Reply[reply]

  CommentPDF versions could be a good choice if they did not release author private information. For more information, read this page at Wikimedia. --Doostdar (talk) 14:03, 20 November 2020 (UTC)Reply[reply]


Use sitelinks to link to Commons in the Wikipedia sidebar

  • Problem: At the moment the link to Commons in the sidebars on Wikipedias and other projects is generated using the P373 ('commons category') property on Wikidata where there isn't a sitelink directly in the linked Wikidata item. P373 is frequently outdated and easy to vandalise, however, and using the sitelinks is a better way to provide the link (in particular, it is bi-directional and provides the links from Commons to the Wikipedias, and it is difficult to vandalise). Where there is a category for a topic, though, the Commons category sitelink is stored there rather than in the topic item, and does not get displayed without a P373 value. (For more background, see d:User:Mike Peel/Commons linking).
  • Who would benefit: Readers and editors going to Commons from Wikipedia articles
  • Proposed solution: The code should be updated to
  1. If there is a sitelink to Commons in the attached Wikidata item, use that (optional: unless it is to a gallery page)
  2. If there is a P910 ('topic's main category') value, follow that to the category item and use the sitelink to Commons from there
  3. If there is a P1754 ('category related to list') value, follow that to the category item and use the sitelink to Commons from there
  4. Otherwise, display nothing.
  • More comments: This is probably a straightforward change to implement, and it is an important step towards deleting P373, however it has been stuck on phabricator for over a year.
  • Phabricator tickets: phab:T232927
  • Proposer: Mike Peel (talk) 11:11, 27 November 2020 (UTC)Reply[reply]



Social interaction

  • Problem: Nowadays it is common for parseltongues to like, comment, rate and share content. These forms of interaction are essential for motivating people to contribute content on the Internet. But apart from the "thank you" function, there are no features in the Wikimedia projects that enable contemporary social interaction and feedback about content.
  • Who would benefit: People who feel motivated by likes, comments and sharing functions to contribute content.
  • Proposed solution: Which functions might be possible and useful would have to be discussed. The following functions could e.g. be considered:
    • A share button with which articles and multimedia files can be shared via email, messenger or in social media etc.
    • A like button for articles and multimedia files
    • A comment function for multimedia files that can be used to give personal comments on the content (in addition to the discussion page, which is used to improve the content).
  • More comments:
  • Phabricator tickets:
  • Proposer: Nicor (talk) 20:18, 24 November 2020 (UTC)Reply[reply]


  • Isn't this the purpose of user talk pages? :) In addition, Wikimedia projects are not social media sites, so I am not a big fan of adding functions that turn Wikimedia sites more social media site-like. Share buttons (provided by social networking sites) are also a privacy concern (read nightmare) to me. H78c67c (talk) 02:29, 25 November 2020 (UTC)Reply[reply]
  • Your claim that "These forms of interaction are essential for motivating people to contribute content on the Internet" might be true for some web sites, such as Instagram. However, Wikipedia has had huge amounts of contribution from a huge number of people without the features you listed, so clearly they are not needed for motivating people to keep contributing to Wikipedia. For me personally, these features would just add noise. Silver hr (talk) 00:45, 1 December 2020 (UTC)Reply[reply]
  • Web browsers already include an option to share. So does the Wikipedia app. --NaBUru38 (talk) 21:15, 10 December 2020 (UTC)Reply[reply]
  • Just the fact that this is framed in terms of Harry Potter references is a bad sign.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:00, 15 December 2020 (UTC)Reply[reply]


  •   Neutral The thanks are enough in my opinion. MarioSuperstar77 (talk) 19:55, 8 December 2020 (UTC)Reply[reply]
  •   Strong oppose I don't think that wikimedia should turn into a social network. This creates the wrong incentive for users and I think this will impact user experience negatively as a whole. Martinkunev (talk) 20:30, 8 December 2020 (UTC)Reply[reply]
  •   Oppose as per my comment. Silver hr (talk) 21:36, 8 December 2020 (UTC)Reply[reply]
  •   Oppose We already have issues with people seeing Wikipedia as a social media site by adding needless personal commentary, not to mention vandalism.   Neutral A "Share" button may be handy, but mostly as a shortcut to copy to clipboard for use as a reference. Jaguar83 (talk) 23:35, 8 December 2020 (UTC)Reply[reply]
  •   Oppose I support the "Like" button in principle, but not as something comparable to social media. Thanks and barnstars are good, but are pretty hard to miss and overall I think quite rare to receive. An anonymous, easy-to-find, and quick equivalent, I think, would see much more engagement and create a much friendlier community for editors. Likes on the articles themselves seem pretty pointless to me, though. I oppose big social media "Share" buttons as they tend to compromise user privacy and I oppose the comments on articles and files - take a look at Wikia's comments for how they tend to turn out. // Lollipoplollipoplollipop :: talk 03:28, 9 December 2020 (UTC)Reply[reply]
  •   Oppose Wikimedia should indeed not turn into a social network. JopkeB (talk) 05:05, 9 December 2020 (UTC)Reply[reply]
  •   Oppose We are not a social network. --Ján Kepler (talk) 14:12, 9 December 2020 (UTC)Reply[reply]
  •   Oppose - Wiki isn't social media. Cabayi (talk) 20:39, 9 December 2020 (UTC)Reply[reply]
  •   Strong oppose per others NMaia (talk) 01:06, 10 December 2020 (UTC)Reply[reply]
  •   Strong support --Ciao • Bestoernesto 04:41, 10 December 2020 (UTC)Reply[reply]
  •   Strong oppose! Wiki is not social. Em-mustapha User | talk 07:03, 10 December 2020 (UTC)Reply[reply]
  •   Support share button;   Oppose the others because of how they can be mis-used Libcub (talk) 19:41, 10 December 2020 (UTC)Reply[reply]
  •   Comment @Libcub: You can already share those articles by using their URLs. This share button wouldn't improve Wikipedia either way. MarioSuperstar77 (talk) 12:29, 11 December 2020 (UTC)Reply[reply]
  •   Oppose Wikis is a different target audience and social website influence should be reduced, not increased. The WikiLove stuff implementation is bad enough. —  HELLKNOWZ   ▎TALK   ▎enWiki 22:35, 10 December 2020 (UTC)Reply[reply]
  •   Strong oppose Yeah, let's not turn this site into social media. Some1 (talk) 05:04, 11 December 2020 (UTC)Reply[reply]
  •   Support I sure would like to see a more 'user friendly' way of communicating with people who remove our additions and edits - this system is so NOT 'user-friendly'! One (myself included) gives up instead of even trying to provide proper supporting explanations for edits which stem from sources which are not from the normal beaten path (I shall give you an example: I belong to the descendants of several royal bloodlines. The wives in one branch of my family have catalogued events in what is called 'The Great Book of the Family' which contains centuries of events, details, dates of births, marriages, burials and more - it is extremely accurate and even answers that which we do not know about in many sources today. . . When I tried to make an edit on a biography profile of one of my royal ancestors using this rare hand-written historical record, my edit was removed and the arguments which I was given did not hold a pail of water while the person relied on misinformation which is repeated time and time again today and is simply not correct.. . . So, how do you handle something like this ...really. . .). Aside this, the 'sidebar' system does NOT work and the discussion forums suck - we need something BETTER than this! We need a BETTER means to communicate where those who remove our work can receive an E-mail from us (more discreetly) and this would contribute to reduce the level of stupidity I see in here where some 'monitors' (for lack of a better word) resort to threats when this is off-the-charts and highly unjustified as well as DAMAGING to the person complaining as oppositions are oft made with such venom it is damaging to many of those who try to work sensibly in here. FAR TOO MANY IN HERE ARE ON A POWER TRIP which has no place here... I see this happen with people who do NOT have the proper background nor education necessary to make such decisions while they arbitrarily go and make changes 'at will' and remove very valuable information. Aside this, I even noted some SLANDEROUS comments in the profile of a scientist who is a relative of mine (Personal 'opinion' in biographies here has no place either...) and while I pointed out this slanderous comment, NO ONE GOT BACK TO ME to tell me it would be removed! Wikipedia is peddling misinformation and slanderous comments which can be damaging to living human beings while there is NO JUSTIFICATION NOR MERIT FOR THIS! Some in here ought to be sued for such garbage posted with the highest wanton disregard. It is hard to 'navigate' and manage things in here and I oft decide instead to keep my material to publish in my own books later. . . The platforms in here need to IMPROVE. . . There also needs to a EASILY-ACCESSIBLE COURSE on HOW TO WORK WITHIN WIKIPEDIA - WITH explanations for ALL the codes, shortcuts, processes, etc., etc. - and this should be done using videos as well. . . —The preceding unsigned comment was added by RoyalSnowbird (talk) 09:16, 11 December 2020 (UTC)Reply[reply]
  •   Neutral I agree with the not a social network messages, and don't agree with the proposed solution, but I like the problem statement. This is what eg WikiLove aims to solve. Some people are motivated more by appreciation for their work. We use good articles / featured articles / barnstars for this mostly. But exploring more ways to make editors feel appreciated is certainly worth looking into, but I'm not sure likes/comments/sharing is quite the answer. ProcrastinatingReader (talk) 11:22, 11 December 2020 (UTC)Reply[reply]
  •   Oppose. --BoldLuis (talk) 15:32, 11 December 2020 (UTC)Reply[reply]
  •   Oppose There are already too many so-called social media in this world; please don’t turn Wiki* into another one. --Aristeas (talk) 16:35, 11 December 2020 (UTC)Reply[reply]
  •   Oppose No. --JonathanLa (talk) 17:48, 11 December 2020 (UTC)Reply[reply]
  •   Oppose We are not a social network. Francois-Pier (talk) 12:14, 12 December 2020 (UTC)Reply[reply]
  •   Neutral per Mario, Klaas `Z4␟` V:  16:18, 12 December 2020 (UTC)Reply[reply]
  •   Strong oppose any sort of embedding of social media buttons, which are just free advertisement for the companies along with the ability for them to collect information from us. — Bilorv (talk) 23:02, 12 December 2020 (UTC)Reply[reply]
  •   Weak support I think the share button may be helpful, but that's about it. This isn't a social media site. Thanks, EDG 543 (message me) 15:11, 15 December 2020 (UTC)Reply[reply]
  •   Support I do find that sometimes wiki articles are too one-sided, or too oriented to a country that the creator is from, or fails to address criticism to the subject. What I do like about social media is that you get brutally honest opinions, which would be useful to improve wiki. Something like a plugin to corresponding topic in social media would be interesting. Sentiment analysis would be another side benefit. Wolfmartyn (talk) 14:51, 16 December 2020 (UTC)Reply[reply]
  •   Oppose Wikis aren't social medias, and there's already the "thank" button. Golmore (talk) 18:45, 16 December 2020 (UTC)Reply[reply]
  •   Strong oppose It will destroy Wikipedia as it would be lots of POV-pushing and meatpuppetry as there would be "wars" for who got more likes. Popular edits that are not neutral can get lot of likes while unpopular edits that are neutral will get nothing, disenfranchising people that tried to edit in a neutral way. Especially in highly polarizing article, this could reward bad behaviors but punish good behaviors. SunDawn (talk) 03:40, 17 December 2020 (UTC)Reply[reply]
  •   Oppose Such social features can be abused too easily and would in turn not bring much positive impact on encouraging editors. The issues with each individual function are:
    1. using sockpuppets to manipulate "like" count to discourage an editor
    2. spam or off-topic/personal attack messages in comments section (present in talk pages, but since talk pages are usually less visible to readers the impact is smaller)
    3. rate: pretty much the same issue as "like"
    4. share: privacy issues, many clients capable of viewing Wikipedia content already have native share capabilities --H78c67c (talk) 08:26, 17 December 2020 (UTC)Reply[reply]
  •   Strong oppose I fear that Wikipedia can turn into a battleground over likes and popularity. Positron832 (talk) 12:48, 17 December 2020 (UTC)Reply[reply]
  •   Oppose oneʼs motivation should be based on interest, not on how much fame or "likes" one gets. Seb az86556 (talk) 21:57, 19 December 2020 (UTC)Reply[reply]
  •   Oppose this is not a good idea.--Malvinero10 (talk) 03:19, 21 December 2020 (UTC)Reply[reply]
  •   Oppose We are supposed to be different than social media plattforms. Nachtbold (talk) 12:51, 21 December 2020 (UTC)Reply[reply]
  •   Support S8321414 (talk) 14:18, 21 December 2020 (UTC)Reply[reply]

Support more OSM relation types in Extension:Kartographer

  • Problem: The Kartographer extension can only display OSM relations of type multipolygon, route, and boundary on maps. Other relations like waterway, superroute, network etc. can not be displayed.
  • Who would benefit: Readers and editors of wiki pages which can be improved with interactive maps displaying OSM relations which are now unsupported.
  • Proposed solution: Add support for more or ideally all OSM relation types in Kartographer. Especially waterway relations (typically rivers) and superroute relations (typically international routes) would be nice to display.
  • More comments: OpenStreetMap (OSM) have free geodata for most geographic features in many parts of the world. It can be a big help for many Wikipedia articles and Wikivoyage to have access to these data to generate interactive maps showing their topics.
  • Phabricator tickets: T156433
  • Proposer: Dipsacus fullonum (talk) 01:28, 21 November 2020 (UTC)Reply[reply]


  • Could that be added to the river-template? Automatically generated river maps, that's what I've been looking for for so long. I would vote for that. --Smarties (talk) 20:59, 22 November 2020 (UTC)Reply[reply]
    Yes. Maps from OSM are used in many infoboxes on English Wikipedia. An example is wikipedia:Bundesautobahn 1. The infobox gets the map data for Bundesautobahn 1 from OpenStreetMap relation 9716761 which have type=route. If type=waterway was supported you could do the same for almost any river. --Dipsacus fullonum (talk) 22:16, 22 November 2020 (UTC)Reply[reply]
  • "Add support for more or ideally all OSM relation types" -- note that there isn't an exhaustive list of relation types due to osmwiki:any tags you like but using the most common ones will cover almost all of the relations in the database. Arlo Barnes (talk) 20:20, 9 December 2020 (UTC)Reply[reply]


Add filters to history pages

  • Problem: On some of the high traffic pages, due to volume of activity, it is difficult to identify true authors or find other editing patterns.
  • Who would benefit: Admins and editors investigating page histories.
  • Proposed solution: Add ability to filter/sort page histories, by for example:
    • Show/hide IP edits
    • Show/hide reverted edits and their reverts
    • Show/hide banned user edits
    • Show/hide bot edits
    • Show/hide minor edits
    • Show/hide/sort edits by number of bytes added/subtracted
    • Show/hide my edits
    • Sort edits by IP/username
    • Show/hide selected user's edits (if this is deemed uncontroversial)
    • Show/hide deleted edits (for administrators only?)
  • More comments: Reposting from 2017 survey
  • Phabricator tickets: T18619, T97020
  • Proposer: Renata3 (talk) 02:38, 17 November 2020 (UTC)Reply[reply]


  • Seconded. It could be helpful. --Piotrus (talk) 04:49, 17 November 2020 (UTC)Reply[reply]
  • Yes, this would be useful. I can't imagine controversy in showing/hiding edits by a specific user as this tool to list edits on a page by a user is linked in the page history on the English Wikipedia, and I believe runs on any Wikimedia project. — Bilorv (talk) 19:32, 17 November 2020 (UTC)Reply[reply]
  • Very helpful :D HeartGlow30797 (talk) 14:35, 22 November 2020 (UTC)Reply[reply]
  • Show/hide users marked by templates as having COIs by en:Template:Connected contributor? HLHJ (talk) 03:01, 20 December 2020 (UTC)Reply[reply]
  • This would probably be the right time to start thinking about MCR filters as well (ie. filter the history based on what slots are changed by each revision). This doesn't seem that important today but will become crucial as MCR gets used more. Tgr (talk) 21:52, 26 December 2020 (UTC)Reply[reply]