Wikimedia Meta-Wiki

Community Wishlist Survey 2021/Miscellaneous

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



Make CentralAuth extension to log actions everywhere

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

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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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 (talk • contribs) 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␟` V:  16: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

Global events calendar

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

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)[reply]
    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)[reply]
    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)[reply]
    @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)[reply]
    @Ainali: Ouch... yes that homepage was terrible... is it better now? --Valerio Bozzolan (talk) 00:02, 4 December 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • absolutely necessary to track all community meetings and events so people can allocate time as necessary Gnangarra (talk) 04:17, 29 November 2020 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • We truly need this proposed Events Calendar and I wholly support it. User:Buszmail (talk) 03:26, 30 November 2020 (UTC)[reply]
  • 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)[reply]
  • I totally support this proposal and we need this. Ninja✮Strikers «☎» 05:20, 30 November 2020 (UTC)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    @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)[reply]
  • 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)[reply]
  • 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)[reply]

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

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

Export and zoom - videoconferencing

Voting

Kartographer icon improvements

 
 
 
 
 
 
 
 
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
(tracking for infoboxes here)
  • 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

Voting

Check if a page exists without populating WhatLinksHere

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

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

I've supported this fix every year. I hope the 13th is the lucky one ;-) --Andyrom75 (talk) 17:35, 23 November 2020 (UTC)[reply]

@MarioSuperstar77, Certes, Evad37, Kaybeesquared, Arlo Barnes, Urhixidur, Putnik, Paul1764, Paul1764, Charitwo, Huji, Jack who built the house, Rodw, Pigsonthewing, Wbm1058, Czar, Andyrom75, Matthiaspaul, The wub, SMcCandlish, Beta16, מושך בשבט, Shalomori123, Do2or, Nahum, Shahar9261, אחיה יאיר וודקה, Roxette5, Draceane, Dovi, Atamari, Man77, Teratix, נריה קלר, SebastianHelm, GiFontenelle, Kku, He3nry, Golmore, Uanfala, Amire80, and Pashute: If you're still interested in this issue, please see Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere. Thanks. Mike Peel (talk) 19:16, 28 January 2022 (UTC)[reply]

Voting

Private Notes

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

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 (talk • contribs) 21:19, 16 November 2020 (UTC)[reply]
    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)[reply]
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)[reply]
  • @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)[reply]
@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)[reply]

Voting

Make signature global

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

Discussion

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

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

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

Voting

Customizable sidebar

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

Discussion

Voting

Bring back PDF book rendering

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

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

Voting

Put the pages in my language automatically

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

Discussion

Voting

MediaWiki message delivery must consider order of messages

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

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

Voting

Include size change in diffs

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

Discussion

Voting

Show all active sessions

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

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

Voting

Stay logged in to XTools

  • Problem: Even if you log in to XTools (https://xtools.wmflabs.org/), it is inconvenient because you will be automatically logged out in a short time.
  • Who would benefit: Users who want to stay logged in with XTools
  • Proposed solution: I would like you to add an option to the login screen to keep you logged in so that you will not be logged out automatically.
  • Other comments:
  • Phabricator tasks: phab:T224382
  • Proposer: Keruby (talk) 04:17, 18 November 2020 (UTC)[reply]

Discussion

Voting

Unify Preferences and Global Preferences

Discussion

  • Some users want to have some different preferences across all Wikimedia projects. The signature setting is the most important here, I guess, because user signatures typically contain a link to the talk page of the signer and it is good if the link can be translated. For example, I use “PiotrekDDYSKUSJA” on pl.wikt, but would like to use “PiotrekDTALK” here or on en.wikt. (Actually, I have just set it here.) PiotrekDTALK 21:33, 17 November 2020 (UTC)[reply]
There's already a task to add signatures in global preferences, but as you said some people want different signature for different wikis, there can be an option to apply A sign on X, Y, Z wikis and B sign on others. All I'm trying to say is that having one place for all user preferences is much preferred than 700+ different preferences. ‐‐1997kB (talk) 06:40, 20 November 2020 (UTC)[reply]
  • I don't think they should be unified, instead, we should simply flick the default for new users who never know about, nor would care very much about the fact that you can have local preferences. —TheDJ (talk • contribs) 10:53, 20 November 2020 (UTC)[reply]
  • While this product was being built, I told the team the design was horribly backwards. The current design theoretically provides the needed functionality, but in reality it is almost unusable. It is particularly unhelpful for new users. If this project is taken up you can ping me and I'm happy to discuss details. In short here is my suggested userstory:
    1. A new user finds their way to the Preferences for the first time. They look for, find, and change a setting. They expect this change to apply globally (which is what it should do). This is the primary and basic use-case. The user likely returns to this use case many times before encountering the next use case.
    2. The user becomes more experienced, more sophisticated, their needs become more sophisticated. They realize they want/need a different preference-value for something on this particular wiki. They either click a special option displayed next to the preference, or they enter some more advanced mode, and they create a LOCAL override for this preference. The user can then change the local setting, which only applies on the current wiki.
    3. When the user returns to the preference panel they see all active preferences. Most preferences display the GLOBAL setting for simple direct editing, but where a LOCAL override exists then the LOCAL value is displayed for simple direct editing. (The local-value-display directly replaces the global-value-display, and the UI uses a colored-background or other styling to highlight that a LOCAL preference is displayed in this slot.)
I considered writing comparison Story for a user attempting to use the current interface, but it would be long and ugly as the user repeatedly runs into problems.
P.S. I am not thrilled with consuming another Community tech slot to complete a project was abandoned in an almost unusable state. Alsee (talk) 10:05, 21 November 2020 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Miscellaneous&oldid=23556480"