Community Wishlist Survey 2021/Miscellaneous

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



Make CentralAuth extension to log actions everywhere

Edit proposal/discussion

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

Discussion

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)

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

Voting

Default languages for Captions and Descriptions on Wiki Commons

Edit proposal/discussion

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

Discussion

Voting

  •   Support TheDesertboy (talk) 18:19, 8 December 2020 (UTC)
  •   Support I would definitely be interested to see that feature. MarioSuperstar77 (talk) 19:37, 8 December 2020 (UTC)
  •   Support makes work easer Leftowiki (talk) 00:35, 9 December 2020 (UTC)
  •   Support I would definitely benefit Qoan (talk) 01:49, 9 December 2020 (UTC)
  •   Support PianistHere (talk) 02:06, 9 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:03, 10 December 2020 (UTC)
  •   Support Kizule (talk) 06:07, 10 December 2020 (UTC)
  •   Support Em-mustapha User | talk 06:49, 10 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:30, 10 December 2020 (UTC)
  •   Support Strong support. BoldLuis (talk) 17:32, 11 December 2020 (UTC)
  •   Support. Meiræ 22:02, 11 December 2020 (UTC)
  •   Support --Acer11 (talk) 02:53, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  16:16, 12 December 2020 (UTC)
  •   Support Nemo Le Poisson (talk) 10:35, 13 December 2020 (UTC)
  •   Support 4nn1l2 (talk) 18:13, 13 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:13, 15 December 2020 (UTC)
  •   Support --Sphilbrick (talk) 16:53, 17 December 2020 (UTC)
  •   Support This would be the right attitude regarding languages in general. Many people can read and contribute in several languages, so why not let them specify those languages in Preferences to encourage activity in relevant areas? Joalbertine (talk) 08:36, 18 December 2020 (UTC)
  •   Support +1 to Joalbertine, yes, and good for monolinguals as well: if we unshow that, then on smaller screen you won’t push by chance a button nor panic. Could we add a UI message instead, so that you know captions are added later in other languages as well? Omotecho (talk) 21:09, 18 December 2020 (UTC)
  •   Support HLHJ (talk) 03:17, 20 December 2020 (UTC)

Expand signature length

Edit proposal/discussion

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

Discussion

  • 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)
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)
  • 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)
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)
  • Forbid any formatting in signatures, those penis prosthetics are just annoying. Grüße vom Sänger ♫(Reden) 22:45, 19 December 2020 (UTC)

Voting

  •   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)
  •   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)
  •   Oppose No good reason was given for this. Silver hr (talk) 21:21, 8 December 2020 (UTC)
  •   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)
  •   Strong oppose per MarioSuperstar77, Braveheidi, and.....Lollipoplollipoplollipop Firestar464 (talk) 05:46, 9 December 2020 (UTC)
  •   Strong oppose --Ján Kepler (talk) 14:32, 9 December 2020 (UTC)
  •   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)
  •   Strong opposeputnik 18:31, 9 December 2020 (UTC)
  •   Strong oppose - Cabayi (talk) 20:29, 9 December 2020 (UTC)
  •   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)
  •   Oppose Libcub (talk) 19:37, 10 December 2020 (UTC)
  •   Oppose per Braveheidi — OwenBlacker (Talk) 21:40, 10 December 2020 (UTC)
  •   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)
  •   Strong oppose — --Noel baran (talk) 16:45, 11 December 2020 (UTC)
  •   Strong oppose --Kusurija (talk) 19:00, 11 December 2020 (UTC)
  •   Support -Xbony2 (talk) 19:46, 11 December 2020 (UTC)
  •   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)
  •   Strong oppose is just a sign. Francois-Pier (talk) 12:01, 12 December 2020 (UTC)
  •   Strong oppose Ad Huikeshoven (talk) 14:19, 12 December 2020 (UTC)
  •   Oppose Philiptdotcom (talk) 14:19, 14 December 2020 (UTC)
  •   Oppose --WTM (talk) 00:48, 15 December 2020 (UTC)
  •   Strong oppose — TARDIS Builder (talk) 00:42, 16 December 2020 (UTC)
  •   Oppose PorkchopGMX (talk) 12:49, 16 December 2020 (UTC)
  •   Strong oppose en: totally exaggerated / de: völlig übertrieben --Dirk123456 (talk) 09:08, 18 December 2020 (UTC)
  •   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.
  •   Oppose per Braveheidi et al. —2d37 (talk) 09:11, 21 December 2020 (UTC)
  •   Support <span> tags take many symbols. Golmore (talk) 12:25, 21 December 2020 (UTC)
  •   Oppose Signatures are supposed to be short and simple. Nachtbold (talk) 12:41, 21 December 2020 (UTC)
  •   Oppose--David1010 (talk) 13:19, 21 December 2020 (UTC)

Allow sanitized-CSS to use pointer-events

Edit proposal/discussion

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

Discussion

@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)
@TheDJ: Sorry, I’m not sure I understand. Why pointer-events property might be abused? Pseudo Classes (talk) 02:49, 21 November 2020 (UTC)
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)
  • 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)
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 https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events WhoAteMyButter (talk) 04:48, 13 December 2020 (UTC)

Voting

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

Input Forms

Edit proposal/discussion

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

Discussion

  • Seconded. Keepcalmandchill (talk) 11:05, 17 November 2020 (UTC)
  • 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)
    @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)
    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)
    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)
  • 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.

Voting

  •   Support Matěj Suchánek (talk) 19:37, 8 December 2020 (UTC)
  •   Support Why not? MarioSuperstar77 (talk) 19:54, 8 December 2020 (UTC)
  •   Support Though I realy want to note that security is a problem. Take this small form for example: <form action="https://tracer.secretapp.secret"><input name="usname" placeholder="Your username"><textarea id="wpReason" placeholder="Why do you believe this block to be unjustified or no longer nessesary"></textarea><input type="submit"></form>, which could be part of a block appeal form. Victor Schmidt (talk) 20:19, 8 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:48, 8 December 2020 (UTC)
  •   Support Sabas88 (talk) 21:54, 8 December 2020 (UTC)
  •   Support Really needed on several meta page. — Jules Talk 23:15, 8 December 2020 (UTC)
  •   Support * Pppery * it has begun 02:02, 9 December 2020 (UTC)
  •   Support Shizhao (talk) 02:57, 9 December 2020 (UTC)
  •   Support Yeenosaurus (talk) 03:46, 9 December 2020 (UTC)
  •   Support ElKevbo (talk) 05:55, 9 December 2020 (UTC)
  •   Support This would help quite significantly in making Wikipedia more welcoming for newcomers. {{u|Sdkb}}talk 06:01, 9 December 2020 (UTC)
  •   Support --Till.niermann (talk) 07:08, 9 December 2020 (UTC)
  •   Support Sannita - not just another it.wiki sysop 15:20, 9 December 2020 (UTC)
  •   Support Ibrahim.ID 20:01, 9 December 2020 (UTC)
  •   Support JPxG (talk) 05:53, 10 December 2020 (UTC)
  •   Support Sohom Datta (talk) 07:08, 10 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:27, 11 December 2020 (UTC)
  •   Support. Meiræ 22:09, 11 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:58, 12 December 2020 (UTC)
  •   Support Khoshhat (talk) 20:39, 12 December 2020 (UTC)
  •   Support Could be cased on templateData. Trizek from FR 20:41, 12 December 2020 (UTC)
  •   Support I couldn't count the number of empty semi-protected edit requests I've read because the user didn't understand what they needed to do. More complicated templates in procedures also trip up experienced editors fairly regularly. — Bilorv (talk) 03:54, 13 December 2020 (UTC)
  •   Support GiFontenelle (talk) 21:55, 16 December 2020 (UTC)
  •   Support Patsagorn Y. (Talk) 13:02, 17 December 2020 (UTC)
  •   Support This will lower the bar for some forms of meaningful participation by new users, and will make things easier for quite a few of the experienced ones. Uanfala (talk) 00:03, 20 December 2020 (UTC)
  •   Support USI2020 (talk) 18:47, 20 December 2020 (UTC)
  •   Support Nachtbold (talk) 12:39, 21 December 2020 (UTC)

Make deleted edits visible to their author

Edit proposal/discussion

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

Discussion

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)

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

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

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

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)

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)

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

-- Cabayi (talk) 14:13, 15 December 2020 (UTC)
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)
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)
@Cabayi: Yes, something like that, but I will see exactly this and you this. JAn Dudík (talk) 14:47, 16 December 2020 (UTC)
  • 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)

Voting

  •   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)
@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)
  •   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)
  •   Support Chaddy (talk) 19:43, 8 December 2020 (UTC)
  •   Support Trang Oul (talk) 19:58, 8 December 2020 (UTC)
  •   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)
@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)
  •   Support --NGC 54 (talk / contribs) 20:16, 8 December 2020 (UTC)
  •   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)
@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)
  •   Support of visible titles, not content JAn Dudík (talk) 20:45, 8 December 2020 (UTC)
  •   Support , even if just the page title and edit summary without text. Certes (talk) 21:10, 8 December 2020 (UTC)
  •   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)
  •   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)
  •   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)
  •   Weak support for this one. This would reduce workload on WP:REFUND (especially on zhwiki). H78c67c (talk) 01:21, 9 December 2020 (UTC)
  •   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)
  •   Strong support per the proposal made by me. Empire AS (talk) 10:34, 9 December 2020 (UTC)
  •   Support Jjkorff (talk) 13:58, 9 December 2020 (UTC)
  •   Oppose Per Sdkb. --Ján Kepler (talk) 14:33, 9 December 2020 (UTC)
  •   Oppose per the opposers! Em-mustapha User | talk 16:04, 9 December 2020 (UTC)
  •   Strong oppose - we don't need to provide assistance to spammers. Cabayi (talk) 20:36, 9 December 2020 (UTC)
  •   Oppose NMaia (talk) 23:57, 9 December 2020 (UTC)
  •   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)
  •   Strong support Ciao • Bestoernesto 04:13, 10 December 2020 (UTC)
  •   Strong oppose per CaptainEek. Possibly (talk) 07:10, 10 December 2020 (UTC)
  •   Support Kisnaak (talk) 22:28, 10 December 2020 (UTC)
  •   Oppose Edits are deleted for a reason. This just opens it up for easy "undo". —  HELLKNOWZ   ▎TALK   ▎enWiki 22:28, 10 December 2020 (UTC)
  •   Support   Oppose test JonathanLa (talk) 18:49, 11 December 2020 (UTC)
  •   Oppose This should be decided by the communities themselves. I can think of several negative consequences. SarahSV talk 04:50, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  16:11, 12 December 2020 (UTC)
  •   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)
  •   Weak support Only titles, per JAn Dudík. — Draceane talkcontrib. 13:14, 15 December 2020 (UTC)
  •   Support Thanks, EDG 543 (message me) 15:09, 15 December 2020 (UTC)
  •   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)
  •   Support Golmore (talk) 18:34, 16 December 2020 (UTC)
  •   Support Kku (talk) 07:48, 17 December 2020 (UTC)
  •   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)
  •   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)
  •   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)
  •   Oppose Why? USI2020 (talk) 19:03, 20 December 2020 (UTC)
  •   Oppose Nachtbold (talk) 12:33, 21 December 2020 (UTC)

Display default/recommended values at Special:Preferences

Edit proposal/discussion

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

Discussion

Voting

  •   Support Support for convenience. MarioSuperstar77 (talk) 19:34, 8 December 2020 (UTC)
  •   Support for convenience. Certes (talk) 21:08, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:46, 8 December 2020 (UTC)
  •   Support Sabiusaugustus (talk) 00:49, 9 December 2020 (UTC)
  •   Support * Pppery * it has begun 02:02, 9 December 2020 (UTC)
  •   Support It’s so annoying not to be able to determine what settings one has changed over the years. Nick Moyes (talk) 09:14, 9 December 2020 (UTC)
  •   Support Thomas Kinz (talk) 10:51, 9 December 2020 (UTC)
  •   Supportxaosflux Talk 12:28, 9 December 2020 (UTC)
  •   Support ‐‐1997kB (talk) 13:06, 9 December 2020 (UTC)
  •   Support --Sphilbrick (talk) 13:34, 9 December 2020 (UTC)
  •   Support Yes, gotta know these things, keeps one sane. GenQuest (talk) 15:10, 9 December 2020 (UTC)
  •   Support and maybe add an explanation about why a certain setting is default (in a tooltip? I don't know). Петър Петров (talk) 17:26, 9 December 2020 (UTC)
  •   Support Support for default option Browk2512 (talk) 22:47, 9 December 2020 (UTC)
  •   Support dwf² (talk) 22:58, 9 December 2020 (UTC)
  •   Support NMaia (talk) 23:54, 9 December 2020 (UTC)
  •   Support CaptainEek Edits Ho Cap'n! 03:15, 10 December 2020 (UTC)
  •   Support JPxG (talk) 05:55, 10 December 2020 (UTC)
  •   Support Em-mustapha User | talk 06:55, 10 December 2020 (UTC)
  •   Support Libcub (talk) 19:48, 10 December 2020 (UTC)
  •   Support Srđan (talk) 22:20, 10 December 2020 (UTC)
  •   Support Also important to highlight if the default was changed — GhostInTheMachine talk to me 23:26, 10 December 2020 (UTC)
  •   Support KevinL (aka L235 · t) 01:05, 11 December 2020 (UTC)
  •   Support Hazard-SJ (talk) 02:07, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 15:34, 11 December 2020 (UTC)
  •   Support Dodger67 (talk) 18:04, 11 December 2020 (UTC)
  •   Support Xnet1234 (talk) 22:25, 11 December 2020 (UTC)
  •   Support. Meiræ 22:26, 11 December 2020 (UTC)
  •   Support DGG (talk) 01:32, 12 December 2020 (UTC)
  •   Support ~Cybularny Speak? 11:29, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:57, 12 December 2020 (UTC)
  •   Support Vincent Simar (talk) 22:53, 12 December 2020 (UTC)
  •   Support Jamesmcmahon0 (talk) 08:44, 13 December 2020 (UTC)
  •   Support Utile. Nemo Le Poisson (talk) 10:22, 13 December 2020 (UTC)
  •   Support -- the wub "?!" 18:31, 13 December 2020 (UTC)
  •   Support Kimsey0 (talk) 22:35, 13 December 2020 (UTC)
  •   Support ~ Amory (utc) 13:22, 14 December 2020 (UTC)
  •   SupportThanks for the fish! talkcontribs 22:45, 14 December 2020 (UTC)
  •   Support WTM (talk) 00:31, 15 December 2020 (UTC)
  •   Support Yes, and show options that have changed by developers or been added since the last time that preferences page was changed by the user.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:02, 15 December 2020 (UTC)
  •   SupportTeratix 06:13, 16 December 2020 (UTC)
  •   Support Ita140188 (talk) 07:53, 16 December 2020 (UTC)
  •   Support Pelagic (talk) 13:24, 16 December 2020 (UTC)
  •   Support with links to explanation (per Петър Петров) and highlight of changes (per SMcCandlish) ◅ SebastianHelm (talk) 14:20, 16 December 2020 (UTC)
  •   Support Jurbop (talk) 18:10, 16 December 2020 (UTC)
  •   Support Épico (talk)/(contribs) 23:31, 16 December 2020 (UTC)
  •   Support I've had occasion to be flummoxed by a bug, where I didn't encounter it until _long_ after I'd modified the troubling setting. I had to reset everything first in order to find the bad setting. And of course then had little enough idea what the _other_ setting I'd changed were. Simple flags on modified settings would have made it much easier. Shenme (talk) 02:11, 18 December 2020 (UTC)
  •   Support Joalbertine (talk) 08:38, 18 December 2020 (UTC)
  •   Weak support Grüße vom Sänger ♫(Reden) 16:11, 19 December 2020 (UTC) Nothing really important, but nice to have
  •   Support HLHJ (talk) 03:14, 20 December 2020 (UTC)
  •   Weak support per Sänger; stronger support if an overview of one's settings that have been changed from the default is included —2d37 (talk) 09:17, 21 December 2020 (UTC)
  •   Support EEMIV (talk) 15:12, 21 December 2020 (UTC)
  •   Support NicoScribe (talk) 16:51, 21 December 2020 (UTC)

Improve pdf outprints

Edit proposal/discussion

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

Discussion

  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)

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

  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)

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

  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)

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

  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)

Voting

Use sitelinks to link to Commons in the Wikipedia sidebar

Edit proposal/discussion

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

Discussion

Voting

  •   Weak support Why not? MarioSuperstar77 (talk) 19:59, 8 December 2020 (UTC)
  •   Support Pmau (talk) 21:28, 8 December 2020 (UTC)
  •   Support It's unfortunate that the phab task has been stuck. {{u|Sdkb}}talk 06:34, 9 December 2020 (UTC)
  •   Support NMaia (talk) 23:55, 9 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:08, 10 December 2020 (UTC)
  •   Support Robby (talk) 05:24, 10 December 2020 (UTC)
  •   Support JAn Dudík (talk) 07:21, 10 December 2020 (UTC)
  •   Support Rodw (talk) 08:28, 10 December 2020 (UTC)
  •   Support Izno (talk) 16:23, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:26, 11 December 2020 (UTC)
  •   Support --Kusurija (talk) 18:57, 11 December 2020 (UTC)
  •   Support Tom Ja (talk) 12:13, 12 December 2020 (UTC)
  •   Support 4nn1l2 (talk) 18:15, 13 December 2020 (UTC)
  •   Support S8321414 (talk) 14:16, 21 December 2020 (UTC)

Social interaction

Edit proposal/discussion

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

Discussion

  • 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)
  • 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)
  • Web browsers already include an option to share. So does the Wikipedia app. --NaBUru38 (talk) 21:15, 10 December 2020 (UTC)
  • Just the fact that this is framed in terms of Harry Potter references is a bad sign.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:00, 15 December 2020 (UTC)

Voting

  •   Neutral The thanks are enough in my opinion. MarioSuperstar77 (talk) 19:55, 8 December 2020 (UTC)
  •   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)
  •   Oppose as per my comment. Silver hr (talk) 21:36, 8 December 2020 (UTC)
  •   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)
  •   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)
  •   Oppose Wikimedia should indeed not turn into a social network. JopkeB (talk) 05:05, 9 December 2020 (UTC)
  •   Oppose We are not a social network. --Ján Kepler (talk) 14:12, 9 December 2020 (UTC)
  •   Oppose - Wiki isn't social media. Cabayi (talk) 20:39, 9 December 2020 (UTC)
  •   Strong oppose per others NMaia (talk) 01:06, 10 December 2020 (UTC)
  •   Strong support --Ciao • Bestoernesto 04:41, 10 December 2020 (UTC)
  •   Strong oppose! Wiki is not social. Em-mustapha User | talk 07:03, 10 December 2020 (UTC)
  •   Support share button;   Oppose the others because of how they can be mis-used Libcub (talk) 19:41, 10 December 2020 (UTC)
  •   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)
  •   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)
  •   Strong oppose Yeah, let's not turn this site into social media. Some1 (talk) 05:04, 11 December 2020 (UTC)
  •   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)
  •   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)
  •   Oppose. --BoldLuis (talk) 15:32, 11 December 2020 (UTC)
  •   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)
  •   Oppose No. --JonathanLa (talk) 17:48, 11 December 2020 (UTC)
  •   Oppose We are not a social network. Francois-Pier (talk) 12:14, 12 December 2020 (UTC)
  •   Neutral per Mario, Klaas `Z4␟` V:  16:18, 12 December 2020 (UTC)
  •   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)
  •   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)
  •   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)
  •   Oppose Wikis aren't social medias, and there's already the "thank" button. Golmore (talk) 18:45, 16 December 2020 (UTC)
  •   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)
  •   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)
  •   Strong oppose I fear that Wikipedia can turn into a battleground over likes and popularity. Positron832 (talk) 12:48, 17 December 2020 (UTC)
  •   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)
  •   Oppose this is not a good idea.--Malvinero10 (talk) 03:19, 21 December 2020 (UTC)
  •   Oppose We are supposed to be different than social media plattforms. Nachtbold (talk) 12:51, 21 December 2020 (UTC)
  •   Support S8321414 (talk) 14:18, 21 December 2020 (UTC)

Support more OSM relation types in Extension:Kartographer

Edit proposal/discussion

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

Discussion

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

Voting

Add filters to history pages

Edit proposal/discussion

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

Discussion

  • Seconded. It could be helpful. --Piotrus (talk) 04:49, 17 November 2020 (UTC)
  • 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)
  • Very helpful :D HeartGlow30797 (talk) 14:35, 22 November 2020 (UTC)
  • Show/hide users marked by templates as having COIs by en:Template:Connected contributor? HLHJ (talk) 03:01, 20 December 2020 (UTC)
  • 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)

Voting

Add a tracker for CSS selectors

Edit proposal/discussion

  • Problem: We don't have a query service for searching CSS selectors (e.g. id and classes). It makes really hard to clean up the legacy codes. Because of that, it took several years to supersede deprecated "prettytable" class in Commons. Until the legacy selectors are completely eliminated, we must keep the legacy codes for really long time. Also, we are not able to evaluate the impact of the style modifications.
  • Who would benefit: interface administrators and developers, template editors
  • Proposed solution: Add a special page to search pages using the specific id or class selectors
  • More comments:
  • Phabricator tickets:
  • Proposer: – Kwj2772 (msg) 14:56, 18 November 2020 (UTC)

Discussion

  • Hello Kwj2772! You should be able to identify use of CSS selectors by simply doing a insource search. For example, here is an example of where I'm searching for the wpFilterRules selector (I intentionally did not include the # (ID) symbol in case there was some JavaScript that used for instance document.getElementById()). You can also search via regular expression. If you need to search across multiple wikis, try the Global Search tool. That tool has a convenient link to search only JS/CSS/JSON as well. It also supports regular expressions, among other features. Do any of these solutions work for you? MusikAnimal (WMF) (talk) 21:33, 18 November 2020 (UTC)
    • Difficult point still exists when the classname is defined in common words. For example, you would have much trouble when you have to find the classname "notice". – Kwj2772 (msg) 09:44, 19 November 2020 (UTC)
      https://w.wiki/nkE for example seems to work well. The regular expression could be tweaked to be more strict, if needed. I'm not sure how would we even be able to track use of IDs/selectors. MusikAnimal (WMF) (talk) 22:30, 23 November 2020 (UTC)
      @MusikAnimal (WMF): You can search on content model which I usually prefer: like so. As for intitle, the period is one of those 'unimportant characters', so it's just as easy to remove the period for intitle searches. (Regex is slightly supported there, but I've found contentmodel to do the best job of finding the CSS pages I care about.) --Izno (talk) 16:07, 11 December 2020 (UTC)
  • Kwj2772, what I have been doing recently is a search like this: insource:infobox insource:class insource:/class[^}]{0,25}infobox/ prefix:A. Basically, looks for insource:infobox and insource:class, then also insource:class followed by no template-end characters up to 25 times, then the word infobox, for all pages that start with A. Hope this helps in your future. --Izno (talk) 16:02, 11 December 2020 (UTC)

Voting

  •   Support Support for convenience. MarioSuperstar77 (talk) 19:35, 8 December 2020 (UTC)
  •   Oppose insource: already does this. Devs should not reinvent the wheel.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:11, 15 December 2020 (UTC)
  •   Oppose insource: (and Global Search) should suffice for 99-100% of cases. I have succesfully removed prettytable from numerous wikis using this feature, and not once heard about missed cases after the fact. Worst case scenario, an lesser-styled table still functions well, so the damage is minimal and easy to improve for most editors. Granted, that's merely a worst case scenario, which I have not yet encountered in practice. --Krinkle (talk) 03:51, 21 December 2020 (UTC)

Add a Quick Settings Panel/Page

Edit proposal/discussion

  • Problem: In order to change simple settings, you have to navigate through a fairly lengthy Preferences section with many pages.
  • Who would benefit: Readers (as in, people who come just to read, not to edit), less experienced editors, anyone who frequently changes a setting.
  • Proposed solution: I propose that their should be a sort of quick setting panel or page, one that is very straight forward and simple for just a regular, non-techsavvy person to do simple things, such as change font size, time, appearance, language, I don't really know, just whatever the most changed settings are. It would be very clean and simple, and maybe even customizable for logged in users to include a few of their favorite settings, but that last part isn't the main point. The main point is making it very easy for the average reader to change a simple setting.
  • More comments:
  • Phabricator tickets:
  • Proposer: Thanks, EDG 543 (message me) 15:52, 17 November 2020 (UTC)

Discussion

  • Why would one frequently change a setting? Which settings would one frequently change? · · · Peter (Southwood) (talk): 07:23, 22 November 2020 (UTC)
Pbsouthwood, well, it's not so much that the individual would need to change the setting over and over, I just was referring to a setting that any random user (non-editor) would likely want to change but couldn't because of there is no easy way for them to change it. I don't really know which specific setting the average reader would want to change, but it wouldn't be hard to conduct a survey or something. Thanks, EDG 543 (message me) 14:43, 30 November 2020 (UTC)
EDG 543, Thank you for clarifying. It would appear that the first step would be to establish a need and the settings that would be involved. Cheers, · · · Peter (Southwood) (talk): 06:00, 1 December 2020 (UTC)
  • It would be flexible. So the user can select which items to include in the QSP (Quick Setting Panel). --BoldLuis (talk) 17:29, 11 December 2020 (UTC)

Voting

  •   Support I remember my time back from 2018 when I first started using Mediawiki, it was quite cumbersome to get started. Definitely supporting that feature. MarioSuperstar77 (talk) 19:51, 8 December 2020 (UTC)
  •   Support The particular way I would want to see this applied to is to redesign the preferences pages so that all settings that could be useful for non-editing readers could be found together. {{u|Sdkb}}talk 08:59, 9 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:45, 10 December 2020 (UTC)
  •   Support Kizule (talk) 06:09, 10 December 2020 (UTC)
  •   Support good Rhodewarrick471 (talk) 13:29, 10 December 2020 (UTC)
  •   Support Libcub (talk) 19:45, 10 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:29, 11 December 2020 (UTC)
  •   Support. Meiræ 22:10, 11 December 2020 (UTC)
  •   Support DGG (talk) 01:31, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:44, 12 December 2020 (UTC)
  •   Support Ziad Rashad (talk) 17:58, 12 December 2020 (UTC)
  •   Support TheLatentOne (talk) 19:39, 12 December 2020 (UTC)
  •   Support As the proposer, I am counted automatically, but I felt the need to be part of the list! Thanks, EDG 543 (message me) 15:00, 15 December 2020 (UTC)
  •   Support Golmore (talk) 18:44, 16 December 2020 (UTC)
  •   Support S8321414 (talk) 14:18, 21 December 2020 (UTC)
  •   Support Nachtbold (talk) 15:35, 21 December 2020 (UTC)

Global events calendar

Edit proposal/discussion

  • Problem: It is hard to keep track on what events are planned, going on or happened, especially online ones (across time-zones) which leads to people that would have enjoyed, and constructively contributed to, are missing some events. This is due to several factors, and mostly in escalation of events (and meetings) online, as it makes it possible to attend previously local/physical events.
  • Who would benefit: All users that are (potentially) interested in organizing and attending events.
  • Proposed solution: A single place to promote and coordinate events. The most important part is that this calendar manage to capture all events in the entire movement, no matter what type they are or which part of the community is organizing it. This should be filterable by language(s) used, place and platform, but also possibly by project, theme, capacity, urgency or even custom #hashtag. The system should have few good calendar view options. A feature to export events to your personal calendar would be nice to have. Another nice to have feature (if it's not possible to the regular watchlist) is to subscribe to changes via email or via user talk page. Perhaps a feature that would really make this spreading across the projects quickly would be the ability to transclude a filtered selection of the events in another project.
  • More comments: There are some previous work in this topic, the best working solution in my opinion right now is Events calendar. On meta there is also Events and the experiment on Wikimedia Space was promising.
  • Phabricator tickets:
  • Proposer: Ainali talkcontributions 09:55, 22 November 2020 (UTC) and Zblace (talk) 12:47, 22 November 2020 (UTC)

Discussion

  • I would not mind seeing an option of also projecting tentative event plans in calendar just to avoid collisions and potentially have coordination (or even collaborations) of such events. Zblace (talk) 16:45, 22 November 2020 (UTC)
    That's perhaps a useful tool, but then it's not just a calendar anymore but almost a full-fledged project management tool. Let's keep this proposal to something smaller. Ainali talkcontributions 16:51, 22 November 2020 (UTC)
    Awesome! Note that Wikimedia CH is developing this wiki-Calendar with federation in mind that may be our solution: Meta:Wikimedia CH/Cronos --Valerio Bozzolan (talk) 08:37, 24 November 2020 (UTC)
    @Valerio Bozzolan: would you mind writing some kind of introduction on that page? Like what is it for, who is building it and what is the timeline? Right now it's quite hard to get a grasp of and even though you posted the link here several times, I didn't understand the purpose of it. Ainali talkcontributions 16:40, 3 December 2020 (UTC)
    @Ainali: Ouch... yes that homepage was terrible... is it better now? --Valerio Bozzolan (talk) 00:02, 4 December 2020 (UTC)
  • I totally support this proposal :) As more and more events are organized by various stakeholders, a real calendar tool is very much needed. As Jan mentioned, the attempt on Wikimedia Space was promising, but was mostly a blog post tool tweaked into a calendar, which came with issues, such as the unability to list events tagged with a certain tag in the order of the date. See also a former discussion about needs for a calendar tool for Wikidata-related events.
    I'd also mention the need of dealing with various time zones. For the Celtic Knot Conference 2020 we had a dedicated user script, for the Wikidata birthday we used an external website, none of these options are ideal. Lea Lacroix (WMDE) (talk) 17:06, 24 November 2020 (UTC)
  • I support this proposal. This allow small to large organizers notify the community on what event they plan to organize, and to make it easy for users to plan their commitments ahead of time. This also reduce the burden of doing an extensive search in meta pages & local language wikis. Exec8 (talk) 14:12, 27 November 2020 (UTC)
  • Yes! there have been a few attempts to do this, and it's harder than it seems because of issues of multilingualism and helping people know the calendar exists, but it's very needed. -- phoebe | talk 15:48, 27 November 2020 (UTC)
  • absolutely necessary to track all community meetings and events so people can allocate time as necessary Gnangarra (talk) 04:17, 29 November 2020 (UTC)
  • I've noted elsewhere, but it's worth reiterating that a highly valuable open source tool for collaborative event scheduling was developed for the open publishing fest. The full code and implementation is at this github link. If possible, it would be more efficient and effective to use this system compared to organising only on-wiki (e.g. ability to filter events by region, theme, and format). I am certain the devs (Julien Taquet, Yannis Barlas, Boris Budini & Kevin Muñoz) could be asked to assist in setting setting up. T.Shafee(Evo﹠Evo)talk 04:26, 29 November 2020 (UTC)
  • I completely support this proposal and invite volunteers to work on translating the same for a greater reach.Rajeeb (talk) 07:00, 29 November 2020 (UTC)
  • We truly need this proposed Events Calendar and I wholly support it. User:Buszmail (talk) 03:26, 30 November 2020 (UTC)
  • I su
  • While for face-to-face meetups we have the calendar already, but not so for online. This is a good initiative, in which we can have one centralized page of listing all of the online Wikimedia events which are open to public (anyone can join, not just by invitation). I believe we can have that based on sequential date and also by its language medium (if it will be done in English or other language). And also not to forget to list down the topic, preface or minutes from any previous discussion (if that event is a follow up ones). Time should be listed in that particular country timezone (usually the main organizer/speaker) and UTC/GMT timezone, plus we shall add a one-click timezone converter (for time & date adjustment). Chongkian (talk) 04:23, 30 November 2020 (UTC)
  • I totally support this proposal and we need this. NinjaStrikers «» 05:20, 30 November 2020 (UTC)
  • Hello, I'm Chris on the Movement Communications team at the Foundation. One possibly I've been talking with the Events team about recently is a central community calendar. Folks at the Foundation (like those on the Events team and myself in Comms!) agree that it's a problem for the movement to not have a centralized, well-supported, easy to use calendar. One possibility we're considering was a calendar in Diff, the community-focused blog. It's the successor in many ways to the Wikimedia Space prototype Jan mentioned. Diff runs on WordPress (open-source, pre-existing, and well-supported), is multilingual, open to participation, and soon you'll be able to authenticate with your Wikimedia account. While it's early in the discussions, I've been looking at something like The Events Calendar plugin (demo). I'd love to hear your thoughts. I personally think supporting a central resource like a community calendar is something the Foundation is well suited to do. :) CKoerner (WMF) (talk) 15:50, 30 November 2020 (UTC)
    @CKoerner (WMF): As already note (apologies) here a relevant prototype: Meta:Wikimedia CH/Cronos, that is a MediaWiki calendar trying to be accessible (no JavaScript), federated (support multiple sources - still needing some thoughts), and it works without extensions or gadgets. Could it be interesting? --Valerio Bozzolan (talk) 16:35, 30 November 2020 (UTC)
    Having a link named "calendar" beside the "logout" option on the upper right across all wiki projects (meta, wikipedia, etc) will allow any user peek though events of the movement. Exec8 (talk) 06:14, 1 December 2020 (UTC)
    @Exec8: Interesting feature. I want to bring your idea to the attention of the Meta:Cronos project manager. --Valerio Bozzolan (talk) 15:45, 2 December 2020 (UTC)
  • This would be a great proposal if it also offers reminders to be written on user talkpages. It could become part of a wider set of tools for remote participation, something that this corona year has shown to be very desirable. I think remote participation options can enable not just better documentation beforehand due to capturing and answering more questions beforehand, but also perhaps enable better documentation during and after the event, just because more people can attend. Jane023 (talk) 18:03, 30 November 2020 (UTC)
  • We (WikiDonne) tried to adapt Les sans pagEs's French calendar (in this moment I cannot find to give it as example) to our uses, but an international one to be used in all projects (with an icon for the related project which is refered) is much needed. --Camelia (talk) 16:44, 1 December 2020 (UTC)
  • This is so much needed!! From Europe, I pointed our fairly new Caribbean contributors to the Wikimedia North American conference which I happened to come across. I would have never seen that, had I not stumbled on the request for a CN banner on Meta. So yes: help the word get around and create one big overview! Ciell (talk) 16:07, 2 December 2020 (UTC)
  • I support this as it is so badly needed now that we do so many things virtual and not in person. However, any system must be flexibly editable via wiki or other platforms. That is, we need a system to sync up changes so that whether things are edited on wiki, or in a modern calendar system (Google, Airtable, whatever) they are reflected back out to the systems of users. Otherwise, requiring all the event content to be centrally locked up in one place would seem to defeat the purpose of such a system. -- Fuzheado (talk) 18:19, 2 December 2020 (UTC)
    It could be Wikidata Bridge like solutions right? Like, all the "actual" editing could be happening in only one place, but the user doesn't need to leave their wiki to edit. This removes the need of "syncing" since it's all stored in one central place (just like Wikidata). (And also, "locking things up centrally" in Commons and Wikidata was a great improvement even without Bridge and so I think a centrally edited solution would be an improvement even if it is not a perfect system.) Ainali talkcontributions 08:03, 3 December 2020 (UTC)
    @Fuzheado: any system must be flexibly editable via wiki or other platforms: 100% sharing your values and working on this prototype to cover your ideas: it keeps everything on the wiki, allows to create or edit an Event using wikitext, using VisualEditor or add one event using one easy external web form but keeping everything on the wiki also in this case. Well, we can stay in touch to improve/test/fix some features to discover if this prototype makes sense. --Valerio Bozzolan (talk) 09:18, 3 December 2020 (UTC)
  • Just a note, I have moved this to the Miscellaneous category as it was the only proposal in Programs & Events. Best, MusikAnimal (WMF) (talk) 19:30, 7 December 2020 (UTC)
  • It is really interesting to observe how the same idea appears simultaneously in different places. In October, I started making a tool that could collect information about events from different pages: events.toolforge.org. And as it turned out, this is not such an easy task, because in the Wikimedia community there are dozens of different places and formats in which planned events are announced (most of them are not machine-readable). It also turned out that we globally do not announce recurring events, and in the end I decided that the best option at that moment was to improve the Events calendar. There is also a @wikimedia_events Telegram channel works now and it broadcasts events from the calendar, but there are still problems with the update timeouts (we also use similar announcements in one of the Russian-language channels). But all these actions are just an attempt to somehow improve the current situation with a complete lack of communication between different parts of the Wikimedia community. I'm not sure which solution we need: will it be a tool for adding events or a tool for parsing events, or maybe we just need to ask all the Wikimedia teams and organizations to just start publishing their events in one of the existing places. But we definitely need a solution that allows users to be aware of all the events that take place within the Wikimedia community. — putnik 17:30, 9 December 2020 (UTC)
    • @Valerio Bozzolan: If you can reuse code for recurrent events from Module:Events calendar for Meta:Cronos, I think it should be very helpful at least as short-term solution. — putnik 17:35, 9 December 2020 (UTC)
      @Putnik: I like your challenge. Yep. Meta:Cronos right now reads data from the source of Module:Events calendar and it also provides an high-level abstraction of these Events (object-oriented). In short, from Cronos you read that (todo: and others) sources without caring much about each data model of each source. --Valerio Bozzolan (talk) 11:41, 10 December 2020 (UTC)
    • And one more important point: if we leave a solution like a Events calendar or Meta:Cronos, then it should definitely be possible to use it in various projects. This means that the data must be located e.g. on the Wikimedia Commons to be available in every project, and modules and templates must be able to be easily copied into projects where they are needed. — putnik 17:42, 9 December 2020 (UTC)
      Again I like your challenge. Waiting for mw:global templates that it's not currently implemented, actually this is feasible. It could be also automated with a small bot in the meanwhile to avoid manual inter-wiki "copypasta". --Valerio Bozzolan (talk) 11:41, 10 December 2020 (UTC)

Wikimedia CH and Cronos, the cross-wiki calendar

Hello everyone, I confirm that the problem of a cross-wiki calendar was a very sensitive issue for Wikimedia CH which immediately proceeded to find a solution already in 2018 for a cross-wiki calendar to serve all communities. Not having a single Wikipedia community, as Switzerland is multilingual, the issue had a high priority as we have a calendar for German community, another for French community, another for Italian community, another for the association and another for Wikidata community. We currently have a calendar but it requires manual updating and, like all calendars, it can't sync with others.

We looked at the existing solutions but they didn't satisfy us for several reasons. For example, it required the installation of a gadget or someone was not adequate on mobile but the main issue is that they were not able to be federated.

So in 2018 we dedicated part of our budget and set an expert team (Valerio Bozzolan and Wiki Valley) to create a new solution for us that had these characteristics:

  • possibility to include the calendar in every wiki using a template
  • facilitated insertion/update through a single form for all wikis but allowed only to users logged in through Oauth
  • easy configuration of the federation of calendars
  • responsive interface
  • no installation of gadgets or configuration of JS by the user

The project has been completed in its first version and will be released shortly on our pages. The same project can be used safely by any Wikimedia community. We are working on better documentation. --Ilario (talk) 10:59, 11 December 2020 (UTC)

  • Evidence that the support button does not work properly. It has put it here, instead of in the right place.

Export and zoom - videoconferencing

  • I suggest it can be exported to iCalendar, User's Google Calendar and other standar web calendars. And also use in nowadays the videoconferencing link or feature --BoldLuis (talk) 15:37, 11 December 2020 (UTC)
  • Instead of this lot of text, it could be used an explanation video. --BoldLuis (talk) 15:42, 11 December 2020 (UTC)

Voting

  •   Support Sagivrash (talk) 19:02, 8 December 2020 (UTC)
  •   Support It seems like a neat idea, so I will support. MarioSuperstar77 (talk) 20:05, 8 December 2020 (UTC)
  •   Support --NGC 54 (talk / contribs) 20:14, 8 December 2020 (UTC)
  •   Strong support - As per my suggestion above. Exec8 (talk) 01:31, 9 December 2020 (UTC)
  •   Support Pharos (talk) 02:27, 9 December 2020 (UTC)
  •   Support Shizhao (talk) 02:56, 9 December 2020 (UTC)
  •   Support ✍ Janwo Disk./de:wp 02:59, 9 December 2020 (UTC)
  •   Support Yes please! Pru.mitchell (talk) 04:19, 9 December 2020 (UTC)
  •   SupportAmmarpad (talk) 04:28, 9 December 2020 (UTC)
  •   Support ··· 🌸 Rachmat04 · 04:41, 9 December 2020 (UTC)
  •   Support Nickw25 (talk) 08:31, 9 December 2020 (UTC)
  •   Support Abductive (talk) 08:57, 9 December 2020 (UTC)
  •   Support Nomnomgol (talk) 09:01, 9 December 2020 (UTC)
  •   Support Buszmail (talk) 10:35, 9 December 2020 (UTC)
  •   Support OrCer (talk) 10:49, 9 December 2020 (UTC)
  •   Support Centralized dashboard would be very useful Frhdkazan (talk) 11:52, 9 December 2020 (UTC)
  •   Strong supportNiklitov (talk) 13:43, 9 December 2020 (UTC)
  •   Support Takot (talk) 15:23, 9 December 2020 (UTC)
  •   Support Baltakatei (talk) 17:02, 9 December 2020 (UTC)
  •   Support especially if that will make the Village Pump messages redundant. Петър Петров (talk) 17:24, 9 December 2020 (UTC)
  •   Support. We definitely need to improve the current situation with event announcements. — putnik 17:43, 9 December 2020 (UTC)
  •   Strong support for the concept. (1) Please, not on another site (e.g. Diff, Space, etc.); Meta seems like the right place to me, especially if I can opt-in for certain ping updates. (2) I'd like it to sync to existing calendars, e.g. Google, etc. --Rosiestep (talk) 17:54, 9 December 2020 (UTC)
  •   Support Rafael (stanglavine) msg 18:38, 9 December 2020 (UTC)
  •   Strong support Too often I see an event mentioned on Twitter or Facebook and then can't find it again until after it's over. If it allows conversion from UTC to local time even better. Oronsay (talk) 18:51, 9 December 2020 (UTC)
  •   Support It should be done before. Alphama (talk) 18:54, 9 December 2020 (UTC)
  •   Support the idea looks good to me and should be helpful in co-ordination. -- টিটো দত্ত (কথা) 18:56, 9 December 2020 (UTC)
  •   Support It would be easier to centralized every events so everyone may choose which one they prefer to join. It's somehow one of way to learn how and what other communities are working on that can be implemented in our local. CyberTroopers (talk) 19:04, 9 December 2020 (UTC)
  •   Support Sounds good, i support it, due to ongoing pandemic each good decision for making things easily workable, indeed a good idea. JogiAsad (talk) 19:20, 9 December 2020 (UTC)
  •   Strong support Camelia (talk) 19:22, 9 December 2020 (UTC)
  •   Strong support Li-Yun Lin (talk) 19:23, 9 December 2020 (UTC)
  •   Support Meursault2004 (talk) 19:36, 9 December 2020 (UTC)
  •   Support Ecritures (talk) 22:05, 9 December 2020 (UTC)
  •   Support Browk2512 (talk) 22:49, 9 December 2020 (UTC)
  •   Support dwf² (talk) 22:59, 9 December 2020 (UTC)
  •   Strong supportDrThneed (talk) 00:40, 10 December 2020 (UTC)
  •   Support Kunokuno (talk) 00:44, 10 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:13, 10 December 2020 (UTC)
  •   Support NinjaStrikers «» 03:24, 10 December 2020 (UTC)
  •   Support JPxG (talk) 06:00, 10 December 2020 (UTC)
  •   Support Fuzheado (talk) 14:19, 10 December 2020 (UTC)
  •   Support much needed VIGNERON * discut. 19:33, 10 December 2020 (UTC)
  •   Support DaSupremo (talk) 20:29, 10 December 2020 (UTC)
  •   Support I was waiting to be a good reason to support this calendar launching. Great idea. Tima93Lb (talk) 20:42, 10 December 2020 (UTC)
  •   Support Srđan (talk) 22:18, 10 December 2020 (UTC)
  •   Support Chongkian (talk) 00:14, 11 December 2020 (UTC)
  •   Support Gnangarra (talk) 00:53, 11 December 2020 (UTC)
  •   Support Steven Sun (talk) 01:10, 11 December 2020 (UTC)
  •   Support Michaelelijahtanuwijaya (talk) 03:16, 11 December 2020 (UTC)
  •   Support--BoldLuis (talk) 15:41, 11 December 2020 (UTC)
  •   Support --Amir E. Aharoni (talk) 18:11, 11 December 2020 (UTC)
  •   Support. Meiræ 21:59, 11 December 2020 (UTC)
  •   Support Lylla08 (talk) 08:19, 12 December 2020 (UTC)
  •   Support Ameisenigel (talk) 16:37, 11 December 2020 (UTC)
  •   Support JonathanLa (talk) 18:52, 11 December 2020 (UTC)
  •   Support Xnet1234 (talk) 22:20, 11 December 2020 (UTC)
  •   Support --Alaa :)..! 01:19, 12 December 2020 (UTC)
  •   Support There was such a thing at 'space' until somebody killed 'space'. Good to salvage the calendar. Ad Huikeshoven (talk) 14:24, 12 December 2020 (UTC)
  •   Support Gnom (talk) 15:54, 12 December 2020 (UTC)
  •   Support A solution working locally would be nice too. Trizek from FR 19:46, 12 December 2020 (UTC)
  •   Support Emperork 🐋🐰 23:58, 12 December 2020 (UTC)
  •   SupportTulsi Bhagat contribs | talk ] 04:32, 13 December 2020 (UTC)
  •   Support NaidNdeso (talk) 10:37, 13 December 2020 (UTC)
  •   Support Tiputini (talk) 18:08, 13 December 2020 (UTC)
  •   Support Geert Van Pamel (WMBE) (talk) 21:12, 13 December 2020 (UTC)
  •   Support Sadads (talk) 11:49, 14 December 2020 (UTC)
  •   Support Michel Bakni (talk) 14:00, 14 December 2020 (UTC)
  •   Support Kasyap (talk) 08:48, 15 December 2020 (UTC)
  •   Support Ita140188 (talk) 07:51, 16 December 2020 (UTC)
  •   Support Great idea. I currently use Day Countdown template, but I have to maintain it manually. 'Add to calendar' would be great. More calendar functionality should be considered, such as adding groups - where user chooses to be part of a group and get group calendar notifications. Wolfmartyn (talk) 14:57, 16 December 2020 (UTC)
  •   Support Papuass (talk) 21:23, 16 December 2020 (UTC)
  •   Support GiFontenelle (talk) 22:15, 16 December 2020 (UTC)
  •   Support Would help bring the greater Wikimedian community closer together. JackFromReedsburg (talk) 00:45, 17 December 2020 (UTC)
  •   Support Blue Rasberry (talk) 00:30, 18 December 2020 (UTC)
  •   Support Shenme (talk) 01:49, 18 December 2020 (UTC)
  •   Support Wehe00 (talk) 10:37, 19 December 2020 (UTC)
  •   Support Agree with Rosiestep that an external calendar would not be desirable and meta seems a good place. Export to an open cross-platform format like ICalendar seems good, although there may be some problems with compatibility with local lunar calendars. HLHJ (talk) 03:08, 20 December 2020 (UTC)
  •   Support David1010 (talk) 13:16, 21 December 2020 (UTC)
  •   Support S8321414 (talk) 14:16, 21 December 2020 (UTC)

Kartographer icon improvements

Edit proposal/discussion

Icons urgently needed for Wikimedia maps
Some icons currently available, but of little use to Wikimedia maps
 
Currently, a skyscraper is an office, a capitol building is a town hall, a hotel is a bed, a church is a cross, and banks are credit cards?
  • Problem: There is no one clear set of icons dedicated to Wikimedia maps. Three things need to happen – (1) an established set of icons particular to Wikimedia mapping needs, (2) the rewriting needed in order to add this set of icons, and (3) better support to more easily add and modify icons in the future.
  • Background: Kartographer-based Mapframe maps work wonders to easily show maps in Wikipedia infoboxes and beyond. However the mapping tool really suffers from a lack of identifying icons. Especially for maps that show numerous features, editors are having to be creative to come up with icons that just barely associate with their topics. This is because MediaWiki uses an obsolete version of Maki icons, but even that still wouldn't fix all the problems relevant to Wikimedia spaces. The Maki icon set was designed for maps, though not for Wikimedia. Therefore it has numerous icons useless to Wikimedia spaces, and lacks icons essential to mapping here. There are at least 11 unclear icons, and at least 47 missing icons key to mapping here.
Other problems include, for accessibility, making more options for legibility. Right now, icons only display white. Icons should be able to be at least colored black, if not more colors, for increased contrast when the marker color is set to a lighter color. Markers should also have options for shapes other than the default teardrop shape, to allow for differentiation when using grayscale maps and for people with low color recognition (see task T131618).
  • Who would benefit: Innumerous Wikimedia spaces, primarily Wikipedia and Wikivoyage, but including numerous unique projects like Wiki Loves Monuments and Wiki Loves Earth, which need good mapping.
  • Proposed solution: Developing an additional entirely new set of icons, including many of the below missing or unclear examples:
Part one: coding
  • Code to allow for easy icon additions and improvements. This needs to happen now, and likely as Kartographer becomes more widespread on WMF projects, future changes will be necessary.
Part two: icon/marker formatting
  • Icons, currently only available in white, should be available at least in black as well, for increased contrast when marker-color is set to a light color
  • Markers should have more shape options behind the tear-drop shape.
Part three: fixing unclear icons
Part four: adding missing icons
  • More comments: The above set of icons proposed are only ones I have found immediately relevant; others in the current Maki set or elsewhere may prove to be as well. Careful care needs to be taken to ensure a non-Western view, as some instances of map icon bias have already been pointed out.
How this should best be solved needs investigation, whether it be adopting later Maki items, WMF or community creating new icons, utilizing existing free Commons files, or a combination of those options. Nevertheless, the technical function of adding and modifying icons needs to take place.

Discussion

  • I support this, because one of most painful limitation is task T141335 the impossibility to use 3 digits on markers. --Andyrom75 (talk) 21:41, 20 November 2020 (UTC)
  • I support this, since this issue already lead to quite a lot of discussions on Wikivoyage. --Nw520 (talk) 22:15, 22 November 2020 (UTC)
  • It would be useful to have access to the MIL-STD-2525D and APP-6D installation icons, at the very least. Other subsets like Activities would also be useful.

Voting

  •   Support It seems to be a minor fix that can return a huge impact for all project. I'm all for it. Sannita - not just another it.wiki sysop 19:28, 8 December 2020 (UTC)
  •   Support MarioSuperstar77 (talk) 19:42, 8 December 2020 (UTC)
  •   Support DerFussi 19:46, 8 December 2020 (UTC)
  •   Support Braveheidi (talk) 21:26, 8 December 2020 (UTC)
  •   Support Sabas88 (talk) 21:57, 8 December 2020 (UTC)
  •   Support Huge improvement mainly for Wikivoyage but also for other wikis. Nw520 (talk) 22:34, 8 December 2020 (UTC)
  •   Support Evad37 (talk) 23:26, 8 December 2020 (UTC)
  •   Support Don-vip (talk) 23:40, 8 December 2020 (UTC)
  •   Support -Another Believer (talk) 00:23, 9 December 2020 (UTC)
  •   Support Alkari (talk) 01:23, 9 December 2020 (UTC)
  •   Support Pharos (talk) 02:26, 9 December 2020 (UTC)
  •   Support ··· 🌸 Rachmat04 · 04:42, 9 December 2020 (UTC)
  •   Support Ottawajin (talk) 05:07, 9 December 2020 (UTC)
  •   Support --Ita140188 (talk) 05:38, 9 December 2020 (UTC)
  •   Support Maps are important and need to be improved! :) OrCer (talk) 10:44, 9 December 2020 (UTC)
  •   Support Thomas Kinz (talk) 10:49, 9 December 2020 (UTC)
  •   Support Clarinetjo (talk) 12:13, 9 December 2020 (UTC)
  •   Support I don't see why not, it would only be a benefit to maps on Wikimedia websites. As a frequent mapframe user, I've often have to make do with the wrong icon. epicgenius (talk) 14:02, 9 December 2020 (UTC)
  •   Support Jts1882 (talk) 14:14, 9 December 2020 (UTC)
  •   Support Absolutely. Ján Kepler (talk) 14:34, 9 December 2020 (UTC)
  •   Support Urhixidur (talk) 16:21, 9 December 2020 (UTC)
  •   Supportputnik 18:43, 9 December 2020 (UTC)
  •   Support Create or give the author the possibility to upload icons TheAmerikaner (talk) 20:51, 9 December 2020 (UTC)
  •   Support NMaia (talk) 23:53, 9 December 2020 (UTC)
  •   Support  Y will improve every language Wikipedia, and Commons, and Wikidata in a visible way  Y reduces the cultural bias of the limited icon set  Y makes the Wikimedia platform more attractive to the off-wiki mapping community  Y choosing icons is a fun beginner activity in outreach  Y Wikipedia's maps are awesome and should look awesome. Blue Rasberry (talk) 01:35, 10 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:11, 10 December 2020 (UTC)
  •   Support This is something nice to see Em-mustapha User | talk 06:53, 10 December 2020 (UTC)
  •   Support JAn Dudík (talk) 08:42, 10 December 2020 (UTC)
  •   Support carlinmack (talk) 14:35, 10 December 2020 (UTC)
  •   Support MichaelSchoenitzer (talk) 18:53, 10 December 2020 (UTC)
  •   Support Libcub (talk) 19:49, 10 December 2020 (UTC)
  •   Support OwenBlacker (Talk) 21:32, 10 December 2020 (UTC)
  •   Support Srđan (talk) 22:18, 10 December 2020 (UTC)
  •   Support Michaelelijahtanuwijaya (talk) 03:17, 11 December 2020 (UTC)
  •   Support Strong support. BoldLuis (talk) 15:33, 11 December 2020 (UTC)
  •   Support Husky (talk) 16:24, 11 December 2020 (UTC)
  •   Support czar 18:30, 11 December 2020 (UTC)
  •   Support JonathanLa (talk) 18:53, 11 December 2020 (UTC)
  •   Support expecially for 3 digits --Andyrom75 (talk) 19:23, 11 December 2020 (UTC)
  •   Support Xnet1234 (talk) 22:27, 11 December 2020 (UTC)
  •   Support  Michael Z. 2020-12-11 23:59 z 23:59, 11 December 2020 (UTC)
  •   Support Francois-Pier (talk) 12:32, 12 December 2020 (UTC)
  •   Support Rdyornot (talk) 22:31, 12 December 2020 (UTC)
  •   Support Nemo Le Poisson (talk) 10:34, 13 December 2020 (UTC)
  •   Support -- the wub "?!" 18:32, 13 December 2020 (UTC)
  •   Support ~ Amory (utc) 13:22, 14 December 2020 (UTC)
  •   Support Daniel Mietchen (talk) 21:35, 14 December 2020 (UTC)
  •   Support The Grid (talk) 17:59, 15 December 2020 (UTC)
  •   Support Jstalins (talk) 04:33, 16 December 2020 (UTC)
  •   Support PinkPanda272 (talk) 08:55, 16 December 2020 (UTC)
  •   Support Papuass (talk) 21:21, 16 December 2020 (UTC)
  •   Support Épico (talk)/(contribs) 23:30, 16 December 2020 (UTC)
  •   Support Mmitchell10 (talk) 21:09, 17 December 2020 (UTC)
  •   Support Rehman 02:11, 20 December 2020 (UTC)
  •   Support HLHJ (talk) 03:12, 20 December 2020 (UTC)
  •   Support DutchTreat (talk) 13:20, 20 December 2020 (UTC)
  •   Support Nachtbold (talk) 15:32, 21 December 2020 (UTC)
  •   Support Charles Alexis Gérard (talk) 17:45, 21 December 2020 (UTC)

Check if a page exists without populating WhatLinksHere

Edit proposal/discussion

  • Problem: Does a wiki page exist? You would expect that this would be a simple thing to check, and it partly is - you can use the #ifexist parser function. However, this has unexpected consequences: the wiki page that does this check will now appear in Special:WhatLinksHere. These false flags causes 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 templates that check for the existence of a page to see if they should link to it.
  • Who would benefit: Template developers and editors resolving disambiguation links on all wikis
  • Proposed solution: Stop checks for the existence of a page from appearing at WhatLinksHere
  • More comments: This was included in the 2015, 2017, and 2019 community wishlists: while it only had 1 oppose vote, it did not get enough support votes to be addressed. It is tricky to resolve, but it should be fixed.
  • Phabricator tickets: phab:T14019 (started on 18 November 2007 - happy 13th birthday!), this is part of the larger task described at phab:T268526 ("Use a dedicated mechanism to track page dependencies")
  • Proposer: Mike Peel (talk) 22:14, 18 November 2020 (UTC)

Discussion

I do not know how important this is, but I'll support since it keeps getting asked over and over again apparently. Hopefully, that gets implemented. MarioSuperstar77 (talk) 22:37, 18 November 2020 (UTC)

  • I created Template:Linkless exists to address this issue. It has disadvantages: please read its documentation before using! However, I'd still like to see a built-in and supported equivalent. Certes (talk) 01:09, 23 November 2020 (UTC)
    Thanks for that, Certes. I thought a simple work-around was possible; I actually opened a tab in my browser pointing to en:Template:If exist as a reminder while I waited the light bulb telling me how to do it turned on (there are probably multiple ways). But I hadn't considered using the PROTECTIONEXPIRY parser function as the trick to implement it. See User talk:Wbm1058##ifexist for links to another work-around implemented in 2016 which used alternative logic that avoided the need to explicitly check if a page exists. Wbm1058 (talk) 15:34, 23 November 2020 (UTC)
I've supported this fix every year. I hope the 13th is the lucky one ;-) --Andyrom75 (talk) 17:35, 23 November 2020 (UTC)

Voting

  •   Support Per my comment. MarioSuperstar77 (talk) 19:32, 8 December 2020 (UTC)
  •   Support Especially useful when the checked page is a dab whose spurious links waste disambiguators' time. Certes (talk) 20:58, 8 December 2020 (UTC)
  •   Support Evad37 (talk) 23:51, 8 December 2020 (UTC)
  •   Support Kaybeesquared (talk) 14:42, 9 December 2020 (UTC)
  •   Support Arlo Barnes (talk) 16:09, 9 December 2020 (UTC)
  •   Support Urhixidur (talk) 16:14, 9 December 2020 (UTC)
  •   Supportputnik 18:29, 9 December 2020 (UTC)
  •   Support Paul1764 (talk) 20:30, 9 December 2020 (UTC)
  •   Support Cabayi (talk) 20:38, 9 December 2020 (UTC)
  •   Support Charitwo (talk) 21:21, 9 December 2020 (UTC)
  •   Support Huji (talk) 00:56, 10 December 2020 (UTC)
  •   Support every year 😪 Jack who built the house (talk) 04:32, 10 December 2020 (UTC)
  •   Support Rodw (talk) 08:28, 10 December 2020 (UTC)
  •   Support Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:31, 10 December 2020 (UTC)
  •   Support Wbm1058 (talk) 01:43, 11 December 2020 (UTC)
  •   Support czar 18:32, 11 December 2020 (UTC)
  •   Support --Andyrom75 (talk) 19:22, 11 December 2020 (UTC)
  •   Support --Matthiaspaul (talk) 17:06, 12 December 2020 (UTC)
  •   Support -- the wub "?!" 18:31, 13 December 2020 (UTC)
  •   Support Anything proposed and supported this long should get implemented. Community Wishlist Survey is rather broken, in accepting only what has the most votes this year, which is never, ever going to be stuff template editors need.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:08, 15 December 2020 (UTC)
  •   Support β16 - (talk) 09:03, 15 December 2020 (UTC)
  •   Support --מושך בשבט (talk) 09:48, 15 December 2020 (UTC)
  •   Support. Shalomori123 (talk) 10:25, 15 December 2020 (UTC)
  •   Support. Do2or (talk) 14:04, 15 December 2020 (UTC)
  •   Support. This issues has been bugging editors on our wiki, but just now we realized it is a global bug. Please fix this!--Naḥum (talk) 12:09, 15 December 2020 (UTC)
  •   Support Shahar9261 (talk) 12:15, 15 December 2020 (UTC)
  •   Support אחיה יאיר וודקה (talk) 12:24, 15 December 2020 (UTC)
  •   Support --Roxette5 (talk) 12:30, 15 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:13, 15 December 2020 (UTC)
  •   Support Dovi (talk) 16:55, 15 December 2020 (UTC)
  •   Support strong support Atamari (talk) 20:00, 15 December 2020 (UTC)
  •   Support«« Man77 »» [de] 22:36, 15 December 2020 (UTC)
  •   SupportTeratix 06:15, 16 December 2020 (UTC)
  •   Support נריה קלר (talk) 09:25, 16 December 2020 (UTC)
  •   Support This is rather a prudent bug fix than a discretionary feature request. SebastianHelm (talk) 13:57, 16 December 2020 (UTC)
  •   Support GiFontenelle (talk) 22:29, 16 December 2020 (UTC)
  •   Support Kku (talk) 07:14, 17 December 2020 (UTC)
  •   Support He3nry (talk) 07:30, 17 December 2020 (UTC)
  •   Support Golmore (talk) 06:57, 18 December 2020 (UTC)
  •   Support * Pppery * it has begun 22:59, 18 December 2020 (UTC)
  •   Support Uanfala (talk) 00:06, 20 December 2020 (UTC)
  •   Support Amir E. Aharoni (talk) 07:41, 21 December 2020 (UTC)
  •   Support Pashute (talk) 14:13, 21 December 2020 (UTC)

Private Notes

Edit proposal/discussion

  • Problem: To make notes that no one else should read, third-party software is required.
  • Who would benefit: All Users
  • Proposed solution: A MediaWiki extension that allows to make private notes.
  • More comments: The extension is not for a Sandbox. It should have minimal formatting options such as bold and italic and Onwikilinks.
  • Phabricator tickets:
  • Proposer: 𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 20:00, 16 November 2020 (UTC)

Discussion

  • @WikiBayer: I'd suggest making a more comprehensive description of the problem. What problem does it solve (in terms of the article writing process), how many people/how regularly have people asked for this functionality ? I mean.. my first idea would be.. use the notepad functionality of your computer.. It's easy, its there, you are already familiar with it. As we shouldn't cram the functionality of an entire operating system inside MediaWiki if we can avoid it, why would it be so much better to have it in the MediaWiki software that it would eleviate the burden of making and keeping such basic functionality provided by so many other pre-existing and focused systems ? —TheDJ (talkcontribs) 21:19, 16 November 2020 (UTC)
    en:Signal (software) has self-send functionality which it treats as notes. I know that private messaging in MediaWiki is a perennial, so there's a potential crossover there. --Izno (talk) 22:00, 16 November 2020 (UTC)
Alternative software is always more cumbersome than a function in the Mediawiki. Appropriate programs are required on all PCs/Smartphones. A "interview" by WMF with CheckUsers has also shown that they keep making alternative notes.---𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 08:13, 17 November 2020 (UTC)
  • @WikiBayer: We'd like some more details about what sort of connections or features these Private Notes would have? Is the desire here to be able to use Wikitext? Link to wiki articles? Do sandbox development in private? We'd like to see the specific use cases be at the heart of the proposal so that it's clearer, more specific, and easier for voters to understand (and support). --AEzell (WMF) (talk) 23:21, 2 December 2020 (UTC)
@User:AEzell (WMF) The proposal is intended as a pure administrative aid and organizational aid. It is only intended to enable you to take notes and to format them minimally so that longer notes remain clear and can be navigated quickly. It should be possible to create Links to Wiki Articles and write in bold and italic.--𝐖𝐢𝐤𝐢𝐁𝐚𝐲𝐞𝐫 👤💬 08:49, 3 December 2020 (UTC)

Voting

  •   Neutral I fail to understand how that will be useful to anyone MarioSuperstar77 (talk) 19:44, 8 December 2020 (UTC)
  •   Support thinking of something like private margin notes... useful for reading and later editing. Ponor (talk) 22:13, 8 December 2020 (UTC)
  •   Strong oppose having to host content that the community is not able to moderate. No objections to plugins/app features that would store these client-side. — xaosflux Talk 02:30, 9 December 2020 (UTC)
  •   Strong oppose Not useful. --Ján Kepler (talk) 14:38, 9 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:36, 10 December 2020 (UTC)
  •   Weak support The proposed changes to watchlists (adding notes to pages when adding them to watchlist) could cover this use case // Lollipoplollipoplollipop :: talk 05:36, 10 December 2020 (UTC)
  •   Support JPxG (talk) 05:55, 10 December 2020 (UTC)
  •   Oppose no good clarifications as why this is useful. Em-mustapha User | talk 07:14, 10 December 2020 (UTC)
  •   Neutral. I can imagine some usecases, but there might be some privacy problems. Who can access these notes? When only editor, it will be great feature for spammers etc. (invisible sandbox). When also admins, it will be not really private and what about storing some critical infos like password? Yes. some type of notes would be useful, but I am afraid, this one would have more problems than pluses. JAn Dudík (talk) 08:39, 10 December 2020 (UTC)
  •   Oppose A solution to a problem that is not a problem for a Wiki. —  HELLKNOWZ   ▎TALK   ▎enWiki 22:38, 10 December 2020 (UTC)
  •   Oppose --Kusurija (talk) 19:03, 11 December 2020 (UTC)
  •   Oppose not necessary for a Wiki. Francois-Pier (talk) 12:28, 12 December 2020 (UTC)
  •   Oppose for private notes one has: e-mail, chats, private websites etcetera; wikis are not developed to support such gadgets, Klaas `Z4␟` V:  16:09, 12 December 2020 (UTC)
  •   Support Melroross (talk) 16:31, 12 December 2020 (UTC)
  •   Support Novak Watchmen (talk) 17:57, 14 December 2020 (UTC)
  •   It is doubtful I do not think we should offer private content hosting. --WTM (talk) 01:07, 15 December 2020 (UTC)
  •   Oppose w:en:WP:NOT#WEBHOST, and similar policies at other projects. Just open a text editor. If you use Windows, I can recommend Notepad++, which auto-saves as you edit, and has innumerable useful plugins.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:04, 15 December 2020 (UTC)
  •   Oppose Not needed --Sudonet (talk) 17:14, 17 December 2020 (UTC)
  •   Oppose similar to xaosflux ; we're not a storage host for non-public data Shenme (talk) 02:05, 18 December 2020 (UTC)
  •   It is doubtful en: I did not completely understand. However, I fear that something like this could be unreliable and difficult to maintain. / de: Ich habe es nicht vollständig verstanden. Ich befürchte jedoch, dass so etwas unzuverlässig und schwer zu warten sein könnte. --Dirk123456 (talk) 10:16, 18 December 2020 (UTC)
  •   Oppose per Xaosflux Malvinero10 (talk) 03:24, 21 December 2020 (UTC)
  •   Oppose If it is not supposed to be public, it is not supposed to be stored on our servers. Nachtbold (talk) 12:47, 21 December 2020 (UTC)

Make signature global

Edit proposal/discussion

  • Problem: After a username change all self created signatures become invalid
  • Who would benefit: All users who got name changed
  • Proposed solution: make signature global so only once the signature needs to be updated and not on all projects
  • More comments: another option might be to change the app/procedure used for user rename, but that might be a tad more complicated
  • Phabricator tickets: T188200
  • Proposer:  Klaas `Z4␟` V:  22:05, 20 November 2020 (UTC)

Discussion

  • A lot of signatures contain language specific portions like (talk) and thus can't be global. ChristianKl❫ 13:55, 24 November 2020 (UTC)
    The (talk) part can be solved by using {{int:Talkpagelinktext}} instead, just like how Wikidata does. H78c67c (talk) 02:21, 25 November 2020 (UTC)

Better if we can't edit our sig at all. Stryn (talk) 20:48, 8 December 2020 (UTC)

  • The user could employ exceptions in the update. --BoldLuis (talk) 17:25, 11 December 2020 (UTC)

@SMcCandlish: Sorry for bothering you, but would you please explain a bit on how the usage of interface message would be "using dynamic content"? H78c67c (talk) 06:06, 16 December 2020 (UTC)

I have no idea how all projects approach this, but at en.Wikipedia, we don't permit in sigs the use of templates, parser functions, and other code which may produce changeable content after the sig is rendered. That's for several reasons (e.g. we don't want to make templates be even more of a vandalism target by having them able to mess up millions of sigs at once), but the main one is that sigs shouldn't change. The way it appeared when originally signed at 21:20 15 October 2015 (UTC) or whenever, at a particular page, is how it should continue to appear if the comment is moved (e.g. to an archive page), or quoted whole on another page or even another wiki. It's implicit in what a signature is that it is fixed in time, "indelible". Its possible that projects with such restrictions might make an exception for something like auto-translation, if this were really desired community-wide (on the same basis that we'd already permit something like link-repair in a sig in a post copied from one wiki to another so that the links went to the right page, without altering the appearance of the sig, or permit w:en:WP:LINT cleanup to replace obsolete <font ...> markup with validating but visually equivalent <span style="...">, markup). Given the triviality of sigs (and the ease of just copying your sig from site A to site B), I don't think this is something the WMF devs should expend any resources on, absent a clear mandate from the community that we collectively wanted this more than other wishlist work in this category.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  08:00, 16 December 2020 (UTC)

Voting

  •   Comment This is a cool idea, but this is not mandatory. i'll prefer other changes, so I wont support this proposal--ValeJappo【〒】 18:47, 8 December 2020 (UTC)
  •   Support MarioSuperstar77 (talk) 19:58, 8 December 2020 (UTC)
  •   Support --NGC 54 (talk / contribs) 20:16, 8 December 2020 (UTC)
  •   Support * Pppery * it has begun 02:02, 9 December 2020 (UTC)
  •   Support —— Eric Liu留言百科用戶頁 04:41, 9 December 2020 (UTC)
  •   Support Cherryblossom000 (talk) 07:18, 9 December 2020 (UTC)
  •   Support Sohom Datta (talk) 11:43, 9 December 2020 (UTC)
  •   Support MilkyDefer (talk) 13:01, 9 December 2020 (UTC)
  •   Support Minorax (talk) 13:14, 9 December 2020 (UTC)
  •   Oppose We don't need this at the moment. --Ján Kepler (talk) 14:30, 9 December 2020 (UTC)
  •   Support Mannivu · 15:24, 9 December 2020 (UTC)
  •   Support Em-mustapha User | talk 16:05, 9 December 2020 (UTC)
  •   Support Oaktree b (talk) 16:41, 9 December 2020 (UTC)
  •   Supportputnik 18:30, 9 December 2020 (UTC)
  •   Support dwf² (talk) 22:58, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:13, 10 December 2020 (UTC)
  •   Support but only if there is an option to retain specific sigs for different projects. JPxG (talk) 05:53, 10 December 2020 (UTC)
  •   Oppose. There are projects where are allowed only simple signatures without colors or fonts. And this sounds like hack for this rule. JAn Dudík (talk) 07:26, 10 December 2020 (UTC)
  •   Support - yona B. (D) 07:53, 10 December 2020 (UTC)
  •   Support ··· 🌸 Rachmat04 · 10:08, 10 December 2020 (UTC)
  •   Oppose I agree that this is not necessary. --OosWesThoesBes (talk) 17:15, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:25, 11 December 2020 (UTC)
  •   Oppose Some Wikis don't allow fantasy unicorn-colored blinking signatures, others do. This would overrule Wikis that only allow signatures that are soothing to the eye. --Gereon K. (talk) 17:45, 11 December 2020 (UTC)
  •   Support of course if sig is according to strictest rules. A different one on a specific project should be allowed like with all options  Klaas `Z4␟` V:  19:35, 11 December 2020 (UTC)
  •   Support --Alaa :)..! 01:19, 12 December 2020 (UTC)
  •   Support disable customization altogether would solve this Ad Huikeshoven (talk) 14:25, 12 December 2020 (UTC)
  •   Strong oppose Custom signatures should be prohibited in all Wikimedia projects. All users should use their username as their signature. 4nn1l2 (talk) 18:08, 13 December 2020 (UTC)
  •   SupportEihel (talk) 21:26, 13 December 2020 (UTC)
  • {{support}} only if you can retain specific sigs for different projects. PorkchopGMX (talk) 13:50, 14 December 2020 (UTC)
    • Changing my vote to   Oppose. Yes this would be nice to have, but there are too many issues that make this unfeasable. PorkchopGMX (talk) 15:44, 18 December 2020 (UTC)
  •   Support Michel Bakni (talk) 14:01, 14 December 2020 (UTC)
  •   Oppose Not globalizable, and the "solution" of using {{int:Talkpagelinktext}} would be against various projects' policies about using dynamic content in signatures.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  06:59, 15 December 2020 (UTC)
  •   Oppose Not worth the effort of implementation and adaptation. ◅ SebastianHelm (talk) 14:06, 16 December 2020 (UTC)
  •   Support Golmore (talk) 18:44, 16 December 2020 (UTC)
  •   Oppose en: Effort and benefit unbalanced / de: Aufwand und Nutzen unausgewogen. --Dirk123456 (talk) 09:17, 18 December 2020 (UTC)
  •   Support David1010 (talk) 13:18, 21 December 2020 (UTC)
  •   Oppose Nachtbold (talk) 15:06, 21 December 2020 (UTC)
  •   Support EEMIV (talk) 15:09, 21 December 2020 (UTC)

Customizable sidebar

Edit proposal/discussion

  • Problem: Right now we have a "one size fits all" situation, where all users get the same sidebar menu. It doesn't matter if you are an occasional reader, a first-time contributor or a veteran with 15+ years of experience. For me (and probably many other long-time users) the sidebar is almost useless. To be quite honest there are only three positions in the sidebar of my homewiki that I sometimes use; I have to get to my "favorite" pages via the watchlist, search bar or URL bar in my browser. In my opinion users should be able to customize their own sidebars. Some might want to put there the articles they often check, some external links to often used references or tools, while some might prefer the default setting.
  • Who would benefit: Experienced users as they can have their workflow improved
  • Proposed solution: I'd have some ideas but don't know if any of them is good. I would see it as a Special Page (Special:Customize sidebar? Additional tab in Preferences?) because I don't think we can trust users to not break their sidebars if that was done in any other way (like creating own pages like MediaWiki:Sidebar). The special page can check if everything (or at least technical aspect) is okay with user's input. The special page could be a form that looks somewhat like this:
Customize your sidebar
Section: (Main) [buttons: create new, edit, remove] [checkbox: collapsible Y/N]
Link: [Text Input] Name to display: [Text Input] [Buttons: Edit Remove]
Link: [Text Input] Name: [Text Input] [Buttons: Edit Remove]
Of course everything done in OOUI, where you can drag and drop elements, with options to create new elements, edit them or whatever, decide whether or not to display the logo, etc. The "Tools" or other "page-specific" sections ("Print/export", "Languages") of the sidebar should not be customizable (so that users cannot break them).
  • More comments:
  • Phabricator tickets:
  • Proposer: tufor (talk) 22:04, 16 November 2020 (UTC)

Discussion

  • It's really easy to add and remove from sidebars using CSS and Javascript. This doesn't seem like a good investment. --Izno (talk) 22:46, 16 November 2020 (UTC)
    • It jumps and it is annoying. Also, not everyone can code in js. tufor (talk) 01:17, 17 November 2020 (UTC)
      • I understand "jump" but "not everyone can code in JS" is not a barrier. It's a single line of well-known Javascript to add a single item in the sidebar, and then just repeat for each item you want to add. --Izno (talk) 19:49, 17 November 2020 (UTC)
        • @Izno: If you don't mind, I am apparently out of the loop on this and am wondering if you can post or link to an example of the single line of well-known Javascript here. I want to have it so I can make such changes for myself and I think it would be good to have just for the purposes of record keeping and for helping others. —The Editor's Apprentice (talk) 19:33, 20 November 2020 (UTC)
  • I like this idea. I currently use my user page, in part, for useful links (and I know others do too), which would work much better as a proper menu, and would be really handy if it were accessible on any page (sidebar would be great). -EdGl (talk) 03:25, 17 November 2020 (UTC)
  • I like this idea. I can't write the code necessary to do this on my own and I, too, keep a list of things on my userpage that would, more usefully to me, be on the sidebar. Jessamyn (talk) 04:38, 17 November 2020 (UTC)
  • I have created a gadget for this on the Romanian Wikipedia: ro:Wikipedia:Unelte/Scripturi/Sidebar (sorry, no translation). You could probably use it in any wiki, although it requires non-trivial configuration. A nice Twinkle like control page could make it more useful.--Strainu (talk) 12:04, 17 November 2020 (UTC)
  • I like it. I never use the sidebar and I've been on Wikipedia for nearly 15 years. Livingston7 (talk) 16:06, 17 November 2020 (UTC)
  • I agree that we could that sidebar is too complex for beginners and too poor for advanced users. For advanced users, I've designed a new sidebar with useful informations and links. See the French version fr:w:Utilisateur:PAC2/Rock your side box and the English outdated version en:w:User:PAC2/just a click away PAC2 (talk) 07:41, 9 December 2020 (UTC)

Voting

  •   Oppose I think this would be useless, since there are already tools for that, and because adding them via js isn't that difficult--ValeJappo【〒】 18:32, 8 December 2020 (UTC)
  •   Support If it ever gets implemented it should only alter javascript and not make major changes to the website's layout. MarioSuperstar77 (talk) 20:04, 8 December 2020 (UTC)
  •   Support Useful, and custom toolbar buttons. But a good program framework is enough, no UI is needed. YFdyh000 (talk) 23:48, 8 December 2020 (UTC)
  •   Oppose CSS and JS scripts can already do that. CaptainEek Edits Ho Cap'n! 03:13, 10 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:06, 10 December 2020 (UTC)
  •   Support JPxG (talk) 05:59, 10 December 2020 (UTC)
  •   SupportThe Editor's Apprentice (talk) 04:31, 11 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:32, 11 December 2020 (UTC)
  •   Support. Meiræ 22:06, 11 December 2020 (UTC)
  •   Support DGG (talk) 01:29, 12 December 2020 (UTC)
  •   Support We can do a lot of the shortcuts we already have normally in just JS, but we have them as gadgets built-in for convenience. It's not always about "there's already a way to do this", moreover, "how can we make this better? convenient? efficient?" This is an example of a tool that I definitely see as handy. WhoAteMyButter (talk) 05:34, 12 December 2020 (UTC)
  •   Support Strainu (talk) 10:19, 12 December 2020 (UTC)
  •   Support per WhoAteMyButter,  Klaas `Z4␟` V:  16:22, 12 December 2020 (UTC)
  •   Support Gdarin | talk 17:21, 12 December 2020 (UTC)
  •   Oppose Various user-side scripts already do this, in innumerable ways. This would just be more wheel-reinvention.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:12, 15 December 2020 (UTC)
  •   Support SeGiba (talk) 18:13, 15 December 2020 (UTC)
  •   Support not everyone is confident, or even familiar with, JS and userscripts – Teratix 06:19, 16 December 2020 (UTC)
  •   Support Joalbertine (talk) 08:41, 18 December 2020 (UTC)
  •   Support There is a gagdet like this on French Wikipedia. Golmore (talk) 12:29, 21 December 2020 (UTC)
  •   Support David1010 (talk) 13:15, 21 December 2020 (UTC)
  •   Support S8321414 (talk) 14:15, 21 December 2020 (UTC)
  •   Support Nachtbold (talk) 15:08, 21 December 2020 (UTC)

Bring back PDF book rendering

Edit proposal/discussion

  • Problem: PDF book rendering has been "ŧurned off for a short term in September 2017" but never brought back. It was an useful feature.
  • Who would benefit: Anynone wanting to collect pages into a book and then download PDF for printing.
  • Proposed solution: Get PDF book rendering back to life. We know it's doable. Maybe it's a lot work, but it would be so nice to have this feature back!
  • More comments:
  • Phabricator tickets:
  • Proposer: Tchoř (talk) 16:33, 25 November 2020 (UTC)

Discussion

Wikisource has some relevant tools, automatically making PDFs but also EPUBs etc. out of any page and any source text. For groups of pages, there's Creator, which seems to be down but was being worked on in 2019 (clarification welcome. Could you use that, Tchoř? HLHJ (talk) 02:49, 20 December 2020 (UTC)

Voting

  •   Neutral MarioSuperstar77 (talk) 20:01, 8 December 2020 (UTC)
  •   Support Frettie (talk) 23:04, 8 December 2020 (UTC)
  •   Support 5225C (talkcontributions) 00:10, 9 December 2020 (UTC)
  •   Support OrCer (talk) 10:45, 9 December 2020 (UTC)
  •   Support I miss it, too. Jjkorff (talk) 13:47, 9 December 2020 (UTC)
  •   Support There are people that would use this, I believe, so yes. Ján Kepler (talk) 14:29, 9 December 2020 (UTC)
  •   Support Lirazelf (talk) 17:00, 9 December 2020 (UTC)
  •   Support Tylwyth Eldar (talk) 18:49, 9 December 2020 (UTC)
  •   Support NaBUru38 (talk) 21:13, 10 December 2020 (UTC)
  •   Support OwenBlacker (Talk) 21:33, 10 December 2020 (UTC)
  •   Support Alexcalamaro (talk) 15:26, 11 December 2020 (UTC)
  •   Support --Aristeas (talk) 16:43, 11 December 2020 (UTC)
  •   Support Somej (talk) 21:10, 11 December 2020 (UTC)
  •   Support SarahSV talk 04:48, 12 December 2020 (UTC)
  •   Support — AfroThundr (u · t · c) 05:04, 12 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  15:55, 12 December 2020 (UTC)
  •   Support Mds08011 (talk) 04:43, 14 December 2020 (UTC)
  •   Support Boehm (talk) 22:20, 14 December 2020 (UTC)
  •   Support --Túrelio (talk) 20:01, 15 December 2020 (UTC)
  •   Support and how about zim, btw. Kku (talk) 07:40, 17 December 2020 (UTC)
  •   Support i found the feature nice, but the results terrible without editing, if there is a save-LaTex-Option i am in (there are tools that does these) -- A1000 (talk) 21:25, 17 December 2020 (UTC)
  •   Support Valerio Bozzolan (talk) 14:42, 18 December 2020 (UTC)
  •   Support Quedel (talk) 21:41, 18 December 2020 (UTC)
  •   Support Afernand74 (talk) 13:17, 20 December 2020 (UTC)
  •   Support 郑洲扬 (talk) 14:55, 20 December 2020 (UTC)
  •   Support Nachtbold (talk) 12:48, 21 December 2020 (UTC)
  •   Support S8321414 (talk) 14:17, 21 December 2020 (UTC)

Put the pages in my language automatically

Edit proposal/discussion

  • Problem: In Mediawiki, Meta, and the help pages of Commons and Wikidata have a menu to change the language. The pages are by default in English.
  • Who would benefit: Each user who reads these pages and does not know English.
  • Proposed solution: Redirect automatically all pages in the language selected in the preferences.
  • More comments:
  • Phabricator tickets:
  • Proposer: USI2020 (talk) 11:16, 29 November 2020 (UTC)

Discussion

  • Can't an in-browser translator be used instead? —Eihel (talk) 21:29, 13 December 2020 (UTC)

Voting

  •   Support Martin m159 (talk) 19:05, 8 December 2020 (UTC)
  •   Support MarioSuperstar77 (talk) 19:34, 8 December 2020 (UTC)
  •   Support But some translations are incomplete or outdated, and may have problems, there should be a reminder always. YFdyh000 (talk) 23:49, 8 December 2020 (UTC)
  •   Support PianistHere (talk) 02:07, 9 December 2020 (UTC)
  •   Support Mbkv717 (talk) 06:50, 9 December 2020 (UTC)
  •   Comment We don't need this at the moment and a lot of translations are outdated. Maybe only when the translation is completed. --Ján Kepler (talk) 14:31, 9 December 2020 (UTC)
  •   Weak oppose. We already have MyLanguage special page which can be used for this purpose (e.g. Special:MyLanguage/Help:Help). I don't really like the idea of redirecting from a real page, not a service one. Unless it can be implemented through a gadget that will not be enabled by default. — putnik 18:41, 9 December 2020 (UTC)
  •   Support TheAmerikaner (talk) 20:49, 9 December 2020 (UTC)
  •   Oppose It appears to me that this feature is already available. For users who want to see content in their local language, they can set it in their preferences. When they click on a link with Special:MyLanguage/ prefix they are automatically redirected to their desired language, if available. H78c67c (talk) 01:41, 10 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:51, 10 December 2020 (UTC)
  •   Support Oui! --Mathieugp (talk) 18:02, 11 December 2020 (UTC)
  •   Support Oui! --Acer11 (talk) 02:56, 12 December 2020 (UTC)
  •   Support Libcub (talk) 19:50, 10 December 2020 (UTC)
  •   Support Strong support. Multilingual environment. BoldLuis (talk) 17:27, 11 December 2020 (UTC)
  •   Support especially, from the browser language Theklan (talk) 18:07, 11 December 2020 (UTC)
  •   Support certo, sicher, sure, zeker  Klaas `Z4␟` V:  15:50, 12 December 2020 (UTC)
  •   Support SeGiba (talk) 18:15, 15 December 2020 (UTC)
  •   Support Golmore (talk) 06:58, 18 December 2020 (UTC)
  •   Support Joalbertine (talk) 08:18, 18 December 2020 (UTC)
  •   Support Changing the default from English to user-preference seems reasonable. Have I understood correctly that this is the request? HLHJ (talk) 03:16, 20 December 2020 (UTC)

MediaWiki message delivery must consider order of messages

Edit proposal/discussion

  • Problem: In different projects and even on different pages of the same project, a different order of adding new messages is often adopted: somewhere they need to be added at the top, and somewhere at the bottom. User:MediaWiki message delivery completely ignores this order. In large projects, this leads to the fact that the message needs to be moved to the beginning of the page each time. In small projects, no one pays attention to this, and on forums where messages should be added at the top, no one reads mass messages at the bottom of the page, and they just go to the archive.
  • Who would benefit: All projects. Mostly small projects that do not have the resources to fight bots.
  • Proposed solution: It should be possible to indicate in the list of message recipients that new messages should be added at the top. Alternative solution: add the magic word like __TOPNEWSECTIONLINK__, which will affect not only the bot, but other scripts too.
  • More comments:
  • Phabricator tickets:
  • Proposer: — putnik 05:57, 17 November 2020 (UTC)

Discussion

  • I mean, this is an improvement, but it's not an improvement I would vote for. --Izno (talk) 04:37, 18 November 2020 (UTC)
  • The fundamental problem here is that messaging/discussion on WM projects uses the utterly inadequate tool of wiki pages. If we had actual proper tools for messaging and discussion, this problem would not exist. (And it's not like the tools don't exist in the wider world--forum software has existed for decades now.) Silver hr (talk) 01:04, 1 December 2020 (UTC)

Voting

  •   Support MarioSuperstar77 (talk) 19:41, 8 December 2020 (UTC)
  •   Support --NGC 54 (talk / contribs) 20:17, 8 December 2020 (UTC)
  •   Oppose This problem should be solved, but through a global revamp of how messaging/discussion works, not by patching a system that was never suited for the purpose. Silver hr (talk) 21:32, 8 December 2020 (UTC)
  •   Oppose per Silver hr --Ján Kepler (talk) 14:35, 9 December 2020 (UTC)
  •   Support Ciao • Bestoernesto 04:49, 10 December 2020 (UTC)
  •   Support Jack who built the house (talk) 04:50, 10 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:33, 11 December 2020 (UTC)
  •   Support  Klaas `Z4␟` V:  16:15, 12 December 2020 (UTC)
  •   Support Puisqu'on a décidé de tuer Flow... Nemo Le Poisson (talk) 10:28, 13 December 2020 (UTC)
  •   Oppose per Silver hr. ◅ SebastianHelm (talk) 13:04, 16 December 2020 (UTC)

Include size change in diffs

Edit proposal/discussion

  • Problem: While the change in size is shown for each change in Recent Changes and article history pages, it is not shown on the diff itself, nor in the API as far as I can tell
  • Who would benefit: People reviewing changes
  • Proposed solution: Add the change in size to the diff page and API
  • More comments:
  • Phabricator tickets: phab:T172698
  • Proposer: the wub "?!" 17:59, 30 November 2020 (UTC)

Discussion

Voting

  •   Weak support Why not? MarioSuperstar77 (talk) 20:03, 8 December 2020 (UTC)
  •   Support --NGC 54 (talk / contribs) 20:15, 8 December 2020 (UTC)
  •   Support I don't see any downsides to this Thryduulf (talk: meta · en.wp · wikidata) 20:59, 8 December 2020 (UTC)
  •   Strong support A very handy tool when trying to spot vandals erasing large chunks of content just for the fun of it. And yes, such vandals do exist. Braveheidi (talk) 21:06, 8 December 2020 (UTC)
  •   Support Why not? // Lollipoplollipoplollipop :: talk 03:14, 9 December 2020 (UTC)
  •   Support kennethaw88talk 06:01, 9 December 2020 (UTC)
  •   Support Abductive (talk) 08:56, 9 December 2020 (UTC)
  •   Oppose We don't need this. --Ján Kepler (talk) 14:36, 9 December 2020 (UTC)
  •   Support JPxG (talk) 05:52, 10 December 2020 (UTC)
  •   Support Why not? Kizule (talk) 06:11, 10 December 2020 (UTC)
  •   Support - yona B. (D) 07:52, 10 December 2020 (UTC)
  •   Support Dominic Z. (talk) 19:42, 10 December 2020 (UTC)
  •   Support NaBUru38 (talk) 21:13, 10 December 2020 (UTC)
  •   Support BoldLuis (talk) 17:22, 11 December 2020 (UTC)
  •   Support Why not? --Andyrom75 (talk) 19:25, 11 December 2020 (UTC)
  •   Support Redalert2fan (talk) 00:13, 12 December 2020 (UTC)
  •   Support Edgars2007 (talk) 10:45, 13 December 2020 (UTC)
  •   Support HAL333 (talk) 21:10, 13 December 2020 (UTC)
  •   Support Giraffer (talk) 19:55, 14 December 2020 (UTC)
  •   Support Tutwakhamoe (talk) 21:26, 14 December 2020 (UTC)
  •   Support β16 - (talk) 09:04, 15 December 2020 (UTC)
  •   Support — Draceane talkcontrib. 13:12, 15 December 2020 (UTC)
  •   Support SeGiba (talk) 18:14, 15 December 2020 (UTC)
  •   Support Threedotshk (talk) 06:46, 16 December 2020 (UTC)
  •   Support Trang Oul (talk) 11:40, 16 December 2020 (UTC)
  •   Support Kku (talk) 07:07, 17 December 2020 (UTC)
  •   Support Will makes things a little bit easier. Uanfala (talk) 00:01, 20 December 2020 (UTC)
  •   Support Anjen01 (talk) 20:40, 20 December 2020 (UTC)
  •   Support Malvinero10 (talk) 03:21, 21 December 2020 (UTC)
  •   Support. Ha, we already have this in MobileDiff. Enjoyer of World (talk) 10:02, 21 December 2020 (UTC)
  •   Support Nachtbold (talk) 12:44, 21 December 2020 (UTC)

Show all active sessions

Edit proposal/discussion

  • Problem: Sometimes we can forget to log out when using an other device than usually thus making it possible that someone can use your account.
  • Who would benefit: all users
  • Proposed solution: Create "active sessions" special page and let users to remove sessions they don't want to keep active. Similar like in Google/Facebook etc.
  • More comments:
  • Phabricator tickets: T58212
  • Proposer: Stryn (talk) 11:22, 17 November 2020 (UTC)

Discussion

  • This seems like it could be a big security improvement. I wonder what the common use cases would be. My first thought was that I know a significant number of editors work from library computers - I'd be interested in people's experiences of whether Wikimedia login sessions persist on library computers or get logged out by default. — Bilorv (talk) 19:38, 17 November 2020 (UTC)
  • I know we aren't voting now, but I think that's a great idea. I have a shared computer that I sometimes use when my personal computer is unavailable and my phone doesn't make the cut. I wouldn't want my young, mischievous siblings using my account. The security of everyone's account would be improved as well. You could easily see if someone were in your account, and could change your password accordingly if necessary. Thanks, EDG 543 (message me) 01:38, 18 November 2020 (UTC)
  • If nothing else, the ability to view a simple count of active sessions (or sometimes "sessions other than the current one"), along with the ability to log out all additional active sessions other than the currently-active one, is kind of the bare-minimum for account-management features in federated authentication systems of similar scale/scope to Wikimedia's. Gravy on top would be the ability to see when each session was last active, where each session was logged in from (either geolocation, network topology, OS / browser fingerprinting, etc.) and the ability to disconnect individual sessions instead of having no option other than the nuclear one. -- FeRDNYC (talk) 00:54, 24 November 2020 (UTC)

Voting

  •   Support Sagivrash (talk) 18:59, 8 December 2020 (UTC)
  •   Support Definitely interesting. Sannita - not just another it.wiki sysop 19:27, 8 December 2020 (UTC)
  •   Support Good for security. Some websites already employ a feature like this. MarioSuperstar77 (talk) 19:33, 8 December 2020 (UTC)
  •   Support General support, though I think this does not happen at all cases. For example, when you tick the "remember me" or "Keep me logged in for up to 365 days"-checkbox, you cannot actually log in on multiple devices. As soon as you log in to the second one, you are automatically logged off from the first one. Victor Schmidt (talk) 20:05, 8 December 2020 (UTC)
  •   Support Martinkunev (talk) 20:17, 8 December 2020 (UTC)
  •   Support Thryduulf (talk: meta · en.wp · wikidata) 21:00, 8 December 2020 (UTC)
  •   Support , especially the ability to log out one's other active sessions: very helpful if a device is lost. Certes (talk) 21:06, 8 December 2020 (UTC)
  •   Support Common security-related feature provided by many services. Nw520 (talk) 22:41, 8 December 2020 (UTC)
  •   Support YFdyh000 (talk) 23:45, 8 December 2020 (UTC)
  •   Support Mahir256 (talk) 01:36, 9 December 2020 (UTC)
  •   SupportBilorv (talk) 01:37, 9 December 2020 (UTC)
  •   Support per all arguments above ──post by kenny2wiki  Talk  Contribs  02:36, 9 December 2020 (UTC)
  •   Support Shizhao (talk) 02:57, 9 December 2020 (UTC)
  •   Support Rschen7754 03:26, 9 December 2020 (UTC)
  •   Support -- CptViraj (talk) 03:53, 9 December 2020 (UTC)
  •   SupportAmmarpad (talk) 04:22, 9 December 2020 (UTC)
  •   Support ··· 🌸 Rachmat04 · 04:42, 9 December 2020 (UTC)
  •   Support ElKevbo (talk) 05:58, 9 December 2020 (UTC)
  •   Support Michal0803 (talk) 09:26, 9 December 2020 (UTC)
  •   Support Samwalton9 (talk) 09:48, 9 December 2020 (UTC)
  •   Support Thomas Kinz (talk) 10:50, 9 December 2020 (UTC)
  •   Support Frhdkazan (talk) 11:53, 9 December 2020 (UTC)
  •   Support BugWarp (talk) 12:54, 9 December 2020 (UTC)
  •   Support MilkyDefer (talk) 13:02, 9 December 2020 (UTC)
  •   Support Jjkorff (talk) 13:48, 9 December 2020 (UTC)
  •   Support Sgd. —Hasley 14:05, 9 December 2020 (UTC)
  •   Support Geraki TL 17:41, 9 December 2020 (UTC)
  •   Support * Pppery * it has begun 17:49, 9 December 2020 (UTC)
  •   Supportputnik 18:31, 9 December 2020 (UTC)
  •   Support Rafael (stanglavine) msg 18:33, 9 December 2020 (UTC)
  •   Support JackFromReedsburg (talk) 22:12, 9 December 2020 (UTC)
  •   Support dwf² (talk) 22:59, 9 December 2020 (UTC)
  •   Support Eddie891 (talk) 23:31, 9 December 2020 (UTC)
  •   Support - Darwin Ahoy! 02:11, 10 December 2020 (UTC)
  •   Support // Lollipoplollipoplollipop :: talk 05:24, 10 December 2020 (UTC)
  •   Support JPxG (talk) 05:56, 10 December 2020 (UTC)
  •   Support Em-mustapha User | talk 07:05, 10 December 2020 (UTC)
  •   Support Srđan (talk) 22:18, 10 December 2020 (UTC)
  •   Support RSLitman (talk) 02:16, 11 December 2020 (UTC)
  •   Support Matěj Suchánek (talk) 14:57, 11 December 2020 (UTC)
  •   Support Bencemac (talk) 16:14, 11 December 2020 (UTC)