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

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

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)[reply]

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

Voting

Default languages for Captions and Descriptions on Wiki Commons

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

Discussion

Voting

Expand signature length

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

Discussion

Although they work fine, I know. However, they should be a bit longer. Therefore, they must be expanded to a few more words or bytes. Thank you. Empire AS (talk) 09:59, 1 December 2020 (UTC)[reply]
Yes I can. In the past I wanted this signature (Empire AS Talk!) but due to the its length, I couldn't get it. And I used this signature (Empire AS Talk!) instead as it was shorter. Therefore, I made this proposal to expand its length. It was all that I explained. Thank you. Empire AS (talk) 07:30, 9 December 2020 (UTC)[reply]

Voting

Allow sanitized-CSS to use pointer-events

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)[reply]
@TheDJ: Sorry, I’m not sure I understand. Why pointer-events property might be abused? Pseudo Classes (talk) 02:49, 21 November 2020 (UTC)[reply]
K. checked. the reason why pointer-events is not supported, is because it is CSS that is part of the SVG2 module which is not included in the sanitizer right now. It will also be added to the upcoming CSS level 4, but the sanitizer only supports Level 3. —TheDJ (talkcontribs) 12:21, 21 November 2020 (UTC)[reply]
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)[reply]

Voting

Input Forms

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

Discussion

Voting

Make deleted edits visible to their author

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

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)[reply]

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

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

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

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

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

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

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

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)[reply]
@MarioSuperstar77: I don't think that it would happen anymore. As I can guess, an editor would use deleted edits to stop them from happening in future. Therefore, they would not repeat such edits anymore and admins would've no need to delete that edits again when they wouldn't be even made. Thank you. Empire AS (talk) 10:13, 9 December 2020 (UTC)[reply]
@Victor Schmidt: According to your view point it would happen. But as I see and can guess, I don't agree with you. Deleted edits visibility may help users to stop rehappening them and admins working here may help there in any other field of encyclopedia instead of deleting revisions that were happening due to not knowing the reason of their deletion. Thank you. Empire AS (talk) 10:26, 9 December 2020 (UTC)[reply]
@Martinkunev: the proposal isn't about live edits. It is about that edits that are deleted known as 'deleted edits' only visible to admins checkusers, oversighters etc but not to even their authors. Thank you. Empire AS (talk) 06:22, 10 December 2020 (UTC)[reply]

Display default/recommended values at Special:Preferences

Discussion

Voting

Improve pdf outprints

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

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

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

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)[reply]

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

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

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

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

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

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

Voting

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

Discussion

Voting

Social interaction

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

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)[reply]
  • Your claim that "These forms of interaction are essential for motivating people to contribute content on the Internet" might be true for some web sites, such as Instagram. However, Wikipedia has had huge amounts of contribution from a huge number of people without the features you listed, so clearly they are not needed for motivating people to keep contributing to Wikipedia. For me personally, these features would just add noise. Silver hr (talk) 00:45, 1 December 2020 (UTC)[reply]
  • Web browsers already include an option to share. So does the Wikipedia app. --NaBUru38 (talk) 21:15, 10 December 2020 (UTC)[reply]
  • Just the fact that this is framed in terms of Harry Potter references is a bad sign.  — SMcCandlish ¢ >ʌⱷ҅ʌ<  07:00, 15 December 2020 (UTC)[reply]

Voting

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

Support more OSM relation types in Extension:Kartographer

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

Discussion

Voting

Add filters to history pages

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

Discussion

Voting

Add a tracker for CSS selectors

  • 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)[reply]

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)[reply]
  • 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)[reply]

Voting

Add a Quick Settings Panel/Page

  • 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)[reply]

Discussion

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)[reply]
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)[reply]

Voting