Community Wishlist Survey 2023/Miscellaneous

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2023
Miscellaneous
20 proposals, 248 contributors, 565 support votes
The survey has closed. Thanks for your participation :)



Add user-profile previews to page previews

  • Problem: It can be difficult to get a quick insight to who an editor is and access the information relevant to them.
  • Proposed solution: Expand Page previews with functionality to show a small profile of a User. It could show join date, user groups, edit count over last 30 days, if they are blocked or not, a link to their talk page and contributions, and maybe something like their mentor from Growth. All kinds of little helpful nuggets of information. There could also be an optional lede/intro and page image provided by the user.
  • Who would benefit: Makes it easier for editors to get some insight into a user really quickly, straight from talk/history/RC pages etc. Makes this functionality, which is already a feature of the 18 year old navigation popups and makes it available to all Wikimedia editors.
  • More comments:
  • Phabricator tickets:
  • Proposer: —TheDJ (talk • contribs) 15:46, 5 February 2023 (UTC)[reply]

Discussion

Voting

Possibility of thanking for more subsequent edits

  • Problem: Somebody made subsequent edits in a single article in a short period of time. I see them in my watchlist and I can add "thanks" for a single edit. But when I open the diff (example), I must first go to history, select one of edits and thank for single edit only.
  • Proposed solution: For subsequent edits of one user, provide the [thank] link in the diff view.
  • Who would benefit: Editors and watchlist users
  • More comments: The notification could read "You received thanks for your edits in <compare link>".
  • Phabricator tickets:
  • Proposer: JAn Dudík (talk) 08:20, 31 January 2023 (UTC)[reply]

Discussion

I would very much appreciate this. It's sort of stupid to thank someone for the last edit in a link, one that was probably a minor fix to spelling, when you really appreciated the series of edits. Daniel Case (talk) 00:00, 1 February 2023 (UTC)[reply]

You could just thank the largest edit. I don't think thanking a range would be hard technically, but for a less experienced user the link to a combined diff might be less understandable than the diff to a single edit. They will still see the specifics of their last edit (timestamp, edit summary etc) as that's how range diffs are displayed. (The task for improving that is T14191.) --Tgr (talk) 03:55, 5 February 2023 (UTC)[reply]

The problem is that I usually see only the last in a series of edits. Or no one edit is the one I found most helpful. Daniel Case (talk) 06:21, 18 February 2023 (UTC)[reply]

Voting

Search bar at preferences

  • Problem: Too many preferences, no way to easily search through them
  • Proposed solution: Add a simple search bar to function as a filter
  • Who would benefit: Everyone
  • More comments: The title is self-explanatory.
  • Phabricator tickets: T313804
  • Proposer: Klein Muçi (talk) 13:55, 27 January 2023 (UTC)[reply]

Discussion

This may be the same solution that phab:T53147 is looking for, just for all the prefences not just one tab of them. — xaosflux Talk 15:30, 27 January 2023 (UTC)[reply]

  • Xaosflux, I'm not sure if T313804 has thought about this detail (it didn't look so with a quick glance at the comments) but I'd wish that the said search bar would work with the English terms no matter what language was chosen, same as English namespace terms work globally. A lot of time you'll read documentation or help pages referencing a specific preference that needs to be toggled but you'll have no idea what that preference is actually called in your language (documentation is usually provided in English). — Klein Muçi (talk) 16:45, 27 January 2023 (UTC)[reply]
    It could probably be set to work the the canonical name (generally in English) and the label name. — xaosflux Talk 16:52, 27 January 2023 (UTC)[reply]

Voting

Improvements to requested articles pages

  • Problem: In my opinion, as a relatively novice user, the requested articles pages on English Wikipedia are a bit daunting. For example social sciences or music. There's a really long list of requested articles. Sometimes they're already completed but they're still listed. Other times they have a redirect but aren't completed. There can be a description or just a title. Sometimes there are sources with full names or just numbers. It's not easy to see what's actually a candidate for making an article versus just a request without any research. I only just today that there's even a list of rejected requests.
  • Proposed solution: I don't have a concrete idea of how this could be improved but I'd love to hear what others think.
  • Who would benefit: I think this would be helpful for users trying to request an article, for editors looking for things to write, and generally to encourage people to get involved by an easy first step like requesting an article.
  • More comments: Some small ideas include:
  1. A voting system, so people could show support for articles they want. This would be nice because I think many people want to write about things that many others are interested in.
  2. A way to automatically show people existing/past requests before they add a new one.
  3. A way to automatically remove articles (or suggest to remove them) one they've been created.
  4. A standardized way of listing sources (this and the following kinda fit into the category of making a template for requests)
  5. A standardized way of writing a description of the page and maybe even why you personally find it interesting.
  6. A field that would let people indicate if they have found something to be notable or not notable yet.
These are just a few rough ideas coming from someone who occasionally makes pages but would like to request pages more often and may be more motivated to make pages if I see others requesting it or voting for it.

Discussion

@RayScript: We just wanted to clarify with you if this is English Wikipedia specific? Thanks for your time in making this proposal! GMikesell-WMF (talk) 21:19, 1 February 2023 (UTC)[reply]

I am not familiar with the requested articles process on other language Wikipedias. However, I assume that it's relatively similar so this would apply to multiple languages. RayScript (talk) 10:32, 2 February 2023 (UTC)[reply]

Hey, Ray - I don't think this is a good fit for this survey in particular, since a change to the structure of this process on en.wp requires only local initiative, not developer time. If you want my honest opinion, the whole concept is just plainly moribund and no longer serves any particular purpose, if it ever did. Might be more productive to just try and stick a fork in it, since I'm not sure anyone would even care enough to object. Doctor Duh (talk) 22:04, 10 February 2023 (UTC)[reply]

I totally get this and agree with some of it! About #2: There are a lot of cross links that are outrageous in content and organization. I think a forced template could fix this. The template would include these things and make them "required". It should check for duplicates or similarities rather than require the user to do so because most won't look themselves. I understand the popularity subjects #'s 1, 5 and 6, but what we want and what we need are two different things. For example, Wikipedia has become very popular with college students, who come here to research a subject. I myself use it for research. I believe #4 is being addressed in Citations, and that is probably the #1 complaint: the tediousness of adding citations. That alone deserves a vote. They're always a mess and editing is a nightmare. Magnoliasouth (talk) 23:59, 10 February 2023 (UTC)[reply]

Voting

Add a new content model for member lists

  • Problem: When users join a user group, a WikiProject, etc., they usually sign on a particular page or section. However, users can be renamed. And after the renaming, the signatures on various pages won't change automatically. It can lead to trouble when trying to find a particular user on a list, especially after the renaming didn't leave a redirect behind.
  • Proposed solution: Develop a new content model or extend MassMessage lists, so that users can more easily sign up for a project. The page stores the user's user ID (and other data like timestamp). When being viewed, the page shows the signed users' current usernames.
  • Who would benefit: Users who sign on pages before renaming, users who wish to navigate others via lists on wikipages.
  • More comments:  
    1. The content model should allow "edit source." (i.e., if it uses JSON, we should be able to edit the JSON file.)
    2. Entries should include user ID (automated), note (optional), timestamp (automated). Should allow strikethrough and postscript (useful when user is announcing departure).
    3. Since some users would like to quit and join again, it should allow multiple signatures from one user.
  • Phabricator tickets:
  • Proposer: 魔琴 (talk) 09:56, 26 January 2023 (UTC)[reply]

Discussion

  • Hi @魔琴:. This wish includes a lot of technical detail. I think it might be wise to rename it into something like "Allow changing signatures in old content" or something that at least be more understandable to the general voting audience ? —TheDJ (talk • contribs) 23:37, 26 January 2023 (UTC)[reply]
    @TheDJ: I fear one will misterpret "changing signature" as the action you do in Special:Preferences. How about "Develop a sign page which auto-updates after username change"? --魔琴 (talk) 02:59, 27 January 2023 (UTC)[reply]

I think changing wikitext in old content would be way off here. It sounds like this needs 2 parts, that may not be "very hard":

  1. Have a way to stamp your userid to a revision (e.g. 魔琴 --> 14127964)
  2. Have a function to retrieve the current username for an id (e.g. 14127964 --> 魔琴)

Then someone could "sign" a page, and the display would be able to show their username. @魔琴: is that what the root of what you are looking for is? (i.e. that is, it isn't really about what style of 'signature' you have configured in prefences). The API is already able to access all of this, so it isn't secret - there just isn't a magic function for it. Of course, if this is in a page revision it wouldn't dynamically update until a purge or subsequent edit occurred. — xaosflux Talk 15:17, 27 January 2023 (UTC)[reply]

@Xaosflux: Yeah, I think that's an economical way to do it. Suppose we have parser functions {{userId}} and {{username}}, we can sign with {{username:{{safesubst:userId}}}} or something like that. --魔琴 (talk) 16:04, 27 January 2023 (UTC)[reply]
I think both of those magic words can be implemented quite easily. What makes this wish difficult is updating the HTML whenever the signature changes. In doing this we have to invalidate the cache. For someone like Xoasflux who has 13,000+ talk page edits on just one wiki, that's potentially 13,000+ pages that need to be re-parsed. User's signatures should not have this kind of effect of the job queue, which is why we discourage using templates in signatures.
Also worth mentioning is the talk pages project, which essentially cements the use of wikitext in on-wiki communication. If we were to change how signatures work, I can only assume mw:Extension:DiscussionTools (or at least the reply tool) would need to be radically reworked as well. MusikAnimal (WMF) (talk) 20:59, 30 January 2023 (UTC)[reply]
@MusikAnimal (WMF): I don't mean changing the signatures on talk pages. I'm talking about the "members list" some WikiProjects or User Groups are using to list the users who participate in them. Like w:en:Wikipedia:WikiProject Chile#Members or Persian Wiki User Group#Participants. But the parser functions would be abused, now I'm aware of. Maybe a new content model, which would restrict the usage, would be better? --魔琴 (talk) 02:25, 31 January 2023 (UTC)[reply]
@魔琴 Ah, I'm terribly sorry I misread this! That seems considerably more "doable" than auto-updating signatures across a whole wiki :) I don't really know exactly how hard adding a new content model would be, but it seems probably within Community Tech's scope.
I realize in your problem statement you clearly say "When users join a user group, a WikiProject, etc., they usually sign on a particular page or section", which I somehow skimmed over, but would you mind if we rename your proposal? A more fitting title might be "Add a new content model for signatures". I wonder what "SignPad" is and if that is that something voters need to be aware of? MusikAnimal (WMF) (talk) 03:58, 31 January 2023 (UTC)[reply]
@MusikAnimal (WMF): I think it would be great! But maybe the word signature will still lead to misunderstanding. How about "member lists" instead? --魔琴 (talk) 05:12, 31 January 2023 (UTC)[reply]
Even better! I agree, saying "signatures" could lead someone else thinking you meant replacing signatures everywhere, and we don't want to give that impression!
Before we rename it, let me run this by the team again tomorrow. With the scope now clarified and much smaller, I think we can probably move it back into Miscellaneous. Apologies again for the hasty assessment of your proposal. MusikAnimal (WMF) (talk) 05:24, 31 January 2023 (UTC)[reply]
That would be great. Thank you for your effort. --魔琴 (talk) 10:39, 31 January 2023 (UTC)[reply]
Done, and no problem :) MusikAnimal (WMF) (talk) 21:12, 31 January 2023 (UTC)[reply]

Voting

Links for preferences

  • Problem: We have links for preference tabs. We don't have links for individual preferences in those tabs.
  • Proposed solution: Have links for individual preferences the click of which highlights the said preferences.
  • Who would benefit: Everyone, mostly new users.
  • More comments: Many times in help requests you'll need to toggle on or off certain preferences. You either get told to do so, or tell someone you're trying to help. Currently you can't link to individual preferences, only to their tabs. This complicates matters with new users who may get easily confused, especially when what you're talking about is not in the same language as the one they're reading their preferences in. Having links for them would make everyone's lives easier and greatly tone down the need for screenshots in these cases.
  • Phabricator tickets:
  • Proposer: Klein Muçi (talk) 17:29, 27 January 2023 (UTC)[reply]

Discussion

Voting

Add "No keyword" as the default option in the Gerrit search dropdown list

  • Problem: If the last word you entered in the Gerrit search box is part of a Gerrit keyword (e.g., "merged"), you would be forced to manually modify the URL after hitting the "Enter" key, because a dropdown list with Gerrit keywords (ending with colons) would pop up.
  • Proposed solution: Add "No keyword" as the default option in the Gerrit search dropdown list. That way, if you really meant to search for the word "merged", you would not be forced to enter a random date after "mergedafter:" and then manually modify the URL.
  • Who would benefit: Gerrit users
  • More comments:
  • Phabricator tickets:
  • Proposer: GeoffreyT2000 (talk) 16:27, 3 February 2023 (UTC)[reply]

Discussion

The following all work:

  • put the keyword in quotes
  • add an extra space at the end
  • hit ESC to hide the dropdown
  • hit a horizontal cursor key to hide the dropdown
  • hit a "noop" key (e.g. shift or insert) to hide the dropdown

--Tgr (talk) 00:08, 5 February 2023 (UTC)[reply]

Also I'd recommend proposing this in the Gerrit issue tracker first, and making sure they wouldn't oppose such a change, as it would have to be done upstream. --Tgr (talk) 00:11, 5 February 2023 (UTC)[reply]

Voting

Checksums of files at dumps.wikimedia.org

Discussion

Voting

Fix Wikipedia IFTTT integration

  • Problem: Wikipedia IFTTT integrations are broken
  • Proposed solution: According to phab:T294448#7584863, the code of the IFTTT service needs to be rewritten
  • Who would benefit: Wikipedia current and potential reader and editor using IFTTT
  • More comments: In 2015, WMF partnered with IFTTT to create a Wikipedia IFTTT channel with a bunch of applets to automate content delivery, e.g. get the word of the day sent to me as a text message, automatically update my Android wallpaper to the featured image of the day, etc. (https://ifttt.com/wikipedia). details see [1]. They are all broken after September 2021.

(Usage data from phab:T294448#7583788)

Discussion

Voting

Vote and statistic server

  • Problem: Non-existent easily and quickly available voter statistics on vote.wikimedia.org
  • Proposed solution: Expand vote.wikimedia.org about voting and analytics tools.
  • Who would benefit: Provide statistics and results in one click (for non-technical election administrators). Bring better presentation of results example n. 1, example n. 2 or example n. 3.
    • Offered overall statistics for current elections and comparison of different ones with each other
    • Efficiency. The statistics and characteristics of the voters (like rights, aka home wiki, how the contribute wiki) are the same for every vote.
    • To have one expert position (as well as technically) in terms of statistics, which is known in the Wikimedia Movement.
  • More comments:
  • Phabricator tickets:
  • Proposer: Dušan Kreheľ (talk) 20:37, 5 February 2023 (UTC)[reply]

Discussion

Voting

Update TemplateStyles CSS rules to current CSS spec versions

  • Problem: The CSS specification is undergoing major changes. For example, CSS logical properties and values, CSS variables, etc. However, TemplateStyles has not kept up with the updated CSS specification. Therefore, when using these new properties and values, you will get the error "Unrecognized or unsupported property" and will not be able to save them.
  • Proposed solution: Update properties and values that are supported by all modern browsers (which can be found by checking Can I use) to correspond to TemplateStyles, unless experimental, deprecated, or cannot be supported for security reasons. If the CSS sanitizer requires significant effort to update to support all CSS, external tools (e.g., stylelint) may be utilized.
  • Who would benefit: Template authors who want to use new CSS properties. The same goes for Wikisource users who use Page styles.
  • More comments:
  • Phabricator tickets: phab:T322482, phab:T320322, phab:T277755 and others listed at https://phabricator.wikimedia.org/tag/css-sanitizer/
  • Proposer: Likibp (talk) 16:57, 31 January 2023 (UTC)[reply]

Discussion

  • I was just about to propose something like "update TemplateStyles CSS rules to current CSS spec versions". I don't want to sort-of duplicate this, but I feel a TemplateStyle request could be more ambitious - most of the time required from CommTech would be figuring out how the whole thing works, once you get that, adding one rule vs. several rules is not that huge a difference. The last update was three years ago, a bunch of CSS specs have changed since then. Some features have been requested explicitly, but the most maintainable (and most mindful of the sanity of the person who will update it the next time) would be to just select some CSS specification versions which are currently reasonable well-supported and then compare them to the versions currently used by TemplateStyles and apply all changes. CSS spec drafts usually come with a section explaining what changed compared to the previous version(e.g.) and implementing that will be a lot more manageable in the long term than cherry-picking and trying to keep track of what's in and what's out. --Tgr (talk) 01:29, 2 February 2023 (UTC)[reply]
  • @Likibp: We reviewed this proposal and before approving it we would like to ask you if you would like to update it to include "update TemplateStyles CSS rules to current CSS spec versions" as Tgr mentioned so that your proposal makes a bigger impact :). HMonroy (WMF) (talk) 22:11, 3 February 2023 (UTC)[reply]
    Yes, I would like to be updated on that proposal. Likibp (talk) 17:13, 5 February 2023 (UTC)[reply]
    Proposal updated.Likibp (talk) 13:17, 6 February 2023 (UTC)[reply]
  • Some things I think updating this library needs to think about in general, which I think the previous maintainer was pretty correct about: 1) accepting changes only from revisions that have reached a certain kind of published status (e.g. not editor's draft but instead candidate recommendation); 2) not just updating the set of documents supported in the library already but the set of documents that have have been created since the library was originally devised. Izno (talk) 07:41, 13 February 2023 (UTC)[reply]
    • Thanks for pointing that out. To a decent extent I was also guided by usage data (e.g. https://caniuse.com/): if there were high levels of browser support for something from a draft I'd be inclined to pull it in (particularly draft updates to an existing recommendation). And if a recommendation was published but hadn't been picked up by browsers for years, that was a negative sign. The other thing to keep in mind is the security aspect: any syntax allowing reference to an external resource needs to enforce filtering, which also means something like CSS Variables is difficult. Anomie (talk) 13:45, 14 February 2023 (UTC)[reply]

Voting

Show syntax highlighting on View Source/protected pages

Discussion

  • I had a similar idea on WP's idea lab a few years ago: Allow previewing protected pages. SD0001 suggested that it had already been declined by devs on the grounds that it would be confusing to newcomers, but I don't buy that because we can show sufficient warning before they can preview it. Nardog (talk) 07:35, 25 January 2023 (UTC)[reply]
  • Newcomers are a very important user group for us, that we are trying to accommodate as much as possible, so it might very well be that we decide in their favour. I do understand the thought of the wish though, it can be helpful to understand the template code. KSiebert (WMF) (talk) 10:54, 25 January 2023 (UTC)[reply]
    • Note WikiEditor is already loaded on protected pages where CodeEditor is loaded (example). I imagine it would be a relatively simple flip of a switch. The absence of the "Publish changes" button already communicates the situation quite clearly, and, more to the point, I fail to see how loading of WikiEditor could affect newcomers' ability to understand it. Nardog (talk) 06:29, 26 January 2023 (UTC)[reply]
    Not sure why syntax-highlighted wikitext would be more confusing to new editors than non-syntax-highlighted wikitext. I'd worry about performance implications though - CodeMirror can be quite slow for large pages. --Tgr (talk) 02:23, 1 February 2023 (UTC)[reply]
  • It's a good proposal. It's probably too late for that, but I'd put it in the Editing section and not in Miscellaneous. --Amir E. Aharoni (talk) 11:58, 22 February 2023 (UTC)[reply]

Voting

Improve PagePile or create new tool for article lists for communication metrics

  • Problem: Wikipedia lacks communication industry analytics, which is major barrier to organizational partnerships. Tools such as Magnus Manske's PagePile that allow creating arbitrary article lists which can then be fed into analytics tools such as Massviews, but there are limitations.
  • Proposed solution: Start by making a better "article list" generator which feeds into analytics tools, or improve the existing PagePile tool. The article list tool should have multilingual and cross-wiki support, and the ability to edit the list.
  • Who would benefit: Museum partners, communication professionals, Wikimedians in Residence, university collaborators
  • More comments: Check out this open source software traffic report demo for English Wikipedia which uses Massviews Analysis and the PagePile tool. Ideally we could do this without the use of two tools, or at least improve PagePile so that we can change the list
  • Phabricator tickets: phab:T231891
  • Proposer: Bluerasberry (talk) 19:19, 26 January 2023 (UTC)[reply]

Discussion

Massviews Analysis of software pageviews is one application of an article list generator. If we had Gulp as a reliable tool, we could develop other reports for editing, image or citation use, multilingual support, or just better list management.

As stated in the nomination, to understand this proposal check out this open source software traffic report demo for English Wikipedia. Here is what is happening in this demo:

  1. A human user is interested in any arbitrary set of Wikipedia articles in any languages. They want to know which ones are popular and underdeveloped so that if they improve those articles, then they can make the biggest impact with the least effort.
  2. The user creates a list of those articles using the PagePile tool.
  3. The user puts the PagePile into Massviews Analysis, documented at Pageviews Analysis.
  4. The output is a traffic report for those articles.

The problem to address is that all organizations in the world with a communication department are making major money and resource investments in new media platforms, but Wikipedia is not the target of these investments. For marketing and promotion the investment is unwanted anyway, but it is problematic that Wikipedia is undesirable as a partner to universities, museums, research institutes, and government agencies which provide general information such as census, culture, demographics, and geography. When an organization has general reference information to share, they should recognize Wikipedia as a good communication option, but instead their investment too often goes in to Facebook, Twitter, YouTube, TikTok, Instagram, or their own websites. Wikipedia is worthy of being a communication partner! Every university in the world has staff who manage social media accounts - at least some of these could be persuaded to develop Wikipedia a little.

There are a few reasons why this does not happen, but one major difference between Wikipedia and all the other platforms is that only Wikipedia fails to provide an obvious entry point for communication professionals. If an institution wants to hire a professional social media manager, then that manager will immediately begin tracking dashboard metrics of how many people read their posts, which posts get user engagement, and where their efforts have the most impact. Wikipedia is not social media, and there are differences, but at least we need to support communication professionals with some measurable feedback. For example, a health organization may want to consider all the Wikipedia articles related to a medical condition to identify the most popular articles as targets for editing, and metrics could for example reduce a possible 5,000 articles on cancer to only the most popular 100 articles. We have 1000s of climate change articles, but the top 10% of them probably get more traffic than the other 90% put together, and identifying those popular ones is difficult. Wikimedia categories do not work for this because they include unwanted topics and exclude wanted topics; organizations simply must make their own lists.

en:Magnus Manske made https://pagepile.toolforge.org/ years ago and proposed Gulp as an update in 2019. I am proposing now that Gulp be the plan for this wish. This is a tool which creates lists of Wikipedia articles which a user can input into other tools to output metrics.

When such a list generation tool works and is reliable, then I expect there will be demand for many other kinds of analytics tools, like aspects of the XTools editing reports for arbitrary lists of Wikipedia articles, or future applications like identifying which articles have translated versions, multimedia from Commons, references, and all the other metrics which Wikimedians check and encourage as part of content development and quality control. Another desired feature is new ways of list generation. PagePile methods include manually inputting Wikipedia article titles or Wikidata identifiers. Running Wikidata queries is possible too. I also want to be able to input a Wikimedia URL and get a list with all the articles linked or Q ids linked on that page. If we went with this, I can imagine 100 feature requests for analytics across languages, Wikimedia projects, and data visualizations. This can start small and grow as needed. It would be a step toward major external investment in Wikimedia development from our partners. Bluerasberry (talk) 19:19, 26 January 2023 (UTC)[reply]

@Bluerasberry It sounds like the primary pain point is with list building, not with collection of metrics. Is that correct? I'm wondering if this proposal could be rewritten to basically be more about "make a better PagePile". "Gulp" is not a well-known name and the solution we come up with may differ considerably from Gulp, so for better voting chances I recommend renaming the proposal as well. Let me know if you need any help. Thanks, MusikAnimal (WMF) (talk) 20:37, 30 January 2023 (UTC)[reply]
@MusikAnimal (WMF):
  • Yes this proposal is for list building
  • A list builder is a means and not the end. I want the metrics and not a tool for organizing metrics, but since wishes have to be small, I am starting with the list builder.
  • If you or anyone you know care to revise the text then feel free. I would estimate that pagepile has fewer than 50 regular users but Magnus has 1000 fans who know his name and support his proposals on name recognition. To me calling a proposal a Magnus proposal seems like better promotion than the pagepile brand name. If you think there is confusion here, I think I would get the most votes by emphasizing Magnus' name.
  • Also an aside - I think that all the Pageviews Analysis variations (Massviews, Topviews, etc) should all get rebranded to one single name because documenting use of all these similar branded products by different names is a challenge. Ideally we could also get rid of the branding for Pagepile and Gulp too, and call everything something like "Wikimedia metrics dashboard" like Twitter does, with one branded product including 100 unbranded features. To me the important part of the tools is not their function, but the end use that they all inform communication and media professionals. I have thought about documenting the tool at https://www.protocols.io/ so that other academics could start using the tool while citing a published methodology. Bluerasberry (talk) 21:57, 30 January 2023 (UTC)[reply]
@MusikAnimal (WMF): Read the changes, love them all, this expresses what I want. 👍 Bluerasberry (talk) 17:37, 3 February 2023 (UTC)[reply]
Great! Approving now :) MusikAnimal (WMF) (talk) 18:17, 3 February 2023 (UTC)[reply]

Voting

Allow users to specify their location in their profile

  • Problem: It is extremely difficult to find other Wikimedians who are in my area. I want to be able to easily contact Wikimedians in my area, organize meetups, and collaborate on geographically-relevant topics.
  • Proposed solution: Add a "Location" field that you can optionally fill out as part of your user profile. The value of the field could be a particular coordinate or OpenStreetMap feature. Users could configure it to be viewable to anyone or only other users in their area to maintain privacy.Users could then view a map of all users who have shared their location around the world.
  • Who would benefit: Editors
  • More comments:
  • Phabricator tickets: phab:T317063
  • Proposer: Lectrician1 (talk) 06:43, 25 January 2023 (UTC)[reply]

Discussion

  • I have some concern about the potential for abuse here... If we have a field, then that field can be requested, meaning that ppl can do automated querying against it, and even if we allow for only limited accuracy, it might still come back to haunt users in ways they might not expect. —TheDJ (talk • contribs) 23:33, 26 January 2023 (UTC)[reply]
    I mean, people can do automated querying against userboxes that specify location... You can even infer where someone lives by looking at their editing history. Yes this is more convenient, but idk, make it so that you have to be authenticated in order to query it or don't make it public API endpoint. I'd argue the benefits are going to far outweigh the possible consequences for most users. We should add a warning then explaining possible implications of revealing your location. IDK, I just want to make my life and other's lives easier without requiring us to add a stupid userbox and then search through categories to find people. Lectrician1 (talk) 05:51, 27 January 2023 (UTC)[reply]
    I also think this make communities for multiple users from the location to meetups together or having regional bases for development. Thingofme (talk) 03:08, 12 February 2023 (UTC)[reply]
  • In Translatewiki there is a feature to change / set up their location. However there is a way for people to spam or discriminate people base on their country of origin / location, which is not good considering the racist nature of people. Thingofme (talk) 11:56, 29 January 2023 (UTC)[reply]
  • I think this is doable today with a template that geotags your user page; then geosearch could be used on the user namespace to find nearby users. --Tgr (talk) 01:04, 1 February 2023 (UTC)[reply]
  • Keep in mind that if someone decides to use this search feature, they can claim to be in some specific area, and find everyone in that area. The system doesn't actually know where you are, only where you claim you are. Even IP addresses can be modified by using open proxies. Animal lover 666 (talk) 21:40, 2 February 2023 (UTC)[reply]
    Yep. Lectrician1 (talk) 03:53, 3 February 2023 (UTC)[reply]
  • IMO, if we want to add support for this in MediaWiki itself (rather than e.g. using templates), then implementing it in the preferences (alongside language and gender, i.e. "How do you prefer to be described?") would make the most sense. Changing the default data model of user profile pages to contain structured data feels like a larger and less tractable project. --Waldyrious (talk) 05:08, 13 February 2023 (UTC)[reply]

Voting

Wikipedia logout: Logout confirmation

  • Problem: If I accidentally click logout in the menu, it logs me out without confirmation.
  • Proposed solution: Implement user confirmation when logging out.
  • Who would benefit: Everyone. A person does not have to deal with the login process and what he/she has, or where they have saved password.
  • More comments:
  • Phabricator tickets: T357484
  • Proposer: Dušan Kreheľ (talk) 17:38, 6 February 2023 (UTC)[reply]

Discussion

We already have a gadget for this. See zh:MediaWiki:Gadget-confirm-logout.js.--GZWDer (talk) 23:24, 8 February 2023 (UTC)[reply]
How can I install that? Please in language for a non-programmer, so step by step. JopkeB (talk) 09:12, 11 February 2023 (UTC)[reply]
There is really nothing Wikipedia-specific about this - it's a question of general UI design that applies to most every web site that supports long-term logins. The overwhelming consensus of the web design community--as evidenced by the behavior of web sites in general--seems to be that logouts should not require confirmation. An accidental logout has a simple and obvious affordance for undoing: logging in again. Generally speaking, user interfaces should assume that users are not helpless and that they intend the actions they perform. That's doubly true when an action is benign and easily reversible. NillaGoon (talk) 22:12, 11 February 2023 (UTC)[reply]
@NillaGoon: My proposal can be justified on a home computer, where there is no need to log out of the web browser. Dušan Kreheľ (talk) 17:43, 12 February 2023 (UTC)[reply]
Something different about from most other sites I use on a regular basis, is that logging out on one device logs me out on every device. That significantly increases the "cost" of an accidental button press. Barkeep49 (talk) 21:36, 14 February 2023 (UTC)[reply]

Voting

Change year range shown in date selection popup

  • Problem: In the Date selection popup, e.g. on the User contributions page after "To date:", if clicking Up Up (^ then ^), the list of years is the current and next decades (2020 to 2039). The next decade is unlikely to be required.
  • Proposed solution: Please change the range of years displayed to the previous and current decades.
  • Who would benefit: Users looking for contributions at dates earlier than 2020.
  • More comments: This would only save one click for each search, but it's an easy enhancement of usability. It would increase the number of times that users would enter dates by point-and-click rather than typing the date in full.
  • Phabricator tickets:
  • Proposer: Fayenatic london (talk) 12:56, 2 February 2023 (UTC)[reply]

Discussion

Voting

Photo and video requests to be fullfilled by Wikipedians all around the world

  • Problem: Sometimes you write an article about a subject far away from where you live and there are no copyright free photos or videos available.
  • Proposed solution: We're a community with members all around the world. Someone must be near the object you're writing about: a piece of art, a building, a statue, etc. Ask those people to photograph it for you.
  • Who would benefit: Eventually, the whole of the wiki community, because there will be a stream of copyright free photos and videos available for all projects to use.
  • More comments: It's really just a place where the requester and the requestee can easily meet each other. For example, I as a Dutchman, residing in the Netherlands, want to write a Dutch article about some animal or a plant species in the Australian Outback; great if I can post a request and an Australian volunteer picks it up who doesn't mind to snap a photo of that animal or plant if he/she has the opportunity.
  • Phabricator tickets:
  • Proposer: Wobuzowatsj (talk) 14:54, 26 January 2023 (UTC)[reply]

Discussion

Hello there, we discussed this as a team and wanted to clarify some questions we had. Namely, we wanted to understand if the problem here was the lack of an interface to be able to find such wikipedians and match the wikipedians that need a photograph with those people. If so, do you mind reflecting that in the problem statement or do you mind if I edit this to make it more clear that this would require developing a tool that helps users find others who opt into sharing their location? Otherwise, this may be more of a non-technical wish and we'll have to archive it. We believe with a couple of tweaks this could be a solid proposal! Thanks so much :) NRodriguez (WMF) (talk) 17:24, 26 January 2023 (UTC)[reply]
Pinging @Wobuzowatsj in case he missed this comment.
Note that some projects such as English Wikipedia have forums for requesting pictures. Any project can adopt the same practice. Another possible solution is reaching out to a WikiProject. For example, on English Wikipedia you could contact w:WP:NYC to request photos of something in New York City. MusikAnimal (WMF) (talk) 16:17, 30 January 2023 (UTC)[reply]
@NRodriguez (WMF) and @MusikAnimal (WMF): It's the lack of an interface that makes it harder to meet other Wikipedians. Such an interface would enable Wikipedians on all projects to find each other easily. Finding each other in projects is possible, but that's not ideal. Not about every subject there's a project going on. I wanted to request a photo of a tombstone in Česke Budějovice, Czech Republic. That's not easy... I have searched on the Czech version of Wikipedia and had to find English-speaking Czechs near this town. If the interface is there that facilitates meeting other Wikipedians who like going out with a photo camera and do not mind taking pictures on request if they're able to. Then we can all benefit from this. Wobuzowatsj (talk) 19:55, 30 January 2023 (UTC)[reply]
  • Note that on Commons several possibilies exist to request images and videos, see Requested files. Perhaps we should merge all possibilites into one portal/interface. I would suggest a search entrance on/sort by: location (continent/country/subdivision (like province/county)/municipality/populated place). --JopkeB (talk) 09:00, 11 February 2023 (UTC)[reply]
  • ̈Several ways exist in Commons and some in ENWP to make this connection. None works well. The way I solve this problem (to small degree) is through WikiShootMe. When in a place I haven't visited in a year or more, I look at that map for red dots, walk there, and snap and upload a picture, turning the dot green. Conversely, working an article about a place that ought to have a photo, I ensure that WikiData has an item with the correct coordinates. This puts a red dot on the map for photographers who happen to pass the place. I'm not at all sure we're talking to the right party to improve on this, but it could be improved by, for example, making a WD Property for "Wikiphoto requested" and having WSM make a different dot, and I'm confident someone, somewhere could think of better ways. Jim.henderson (talk) 17:21, 18 February 2023 (UTC) ̴̴[reply]
I just had a look at WikiShootMe and looked at a random sample of around 20 red dots. For most, a photo exists in WikimediaCommons, it's just not linked in a recognized way (many are linked but over 2-3 hops). For some, the location was simply wrong, e.g. Dreisam at this place. Both together make this tool not really useful to guide photographers to places we need a shot of 😐 --Schoschi (talk) 18:40, 23 February 2023 (UTC)[reply]

ː Yes, WSM depends on Wikidata, which has many errors and inadequacies. These indeed waste time. Last year as local ENWP editor, Commons photographer, and WD editor, I failed to find a Community Garden on 12th Street west of Avenue A where the red dot put it. A little walking showed that it was actually east of Avenue A. So, correcting WD, I also snapped a picture. Maybe someday an article will mention it. WD location is usually correct, so I snap the pic and upload it on the spot, with WSM or more often Commons App. Arriving home I may find that the subject is already photographed but there is no "Image" property in the WD item to link to it. So, I further edit WD to include the best few pix, and then look at any EN article that might benefit from these pictures. If there are many pictures, I even make a commonscat, also with WD link. Thus, one red dot may trigger considerable activity on my part. ː The method of first finding a relevant photographer, and then requesting a photo of one target, is also indirect, and will waste time in a different way. So, clearly if the target is important, it calls for the requester showing the way in ENWP, and in Commons, and in WD, all of which will snare different photographers besides the ones who join the "find me" system. And if there is no WD item, that ought to be part of the photo request, or else the requester should do it so as to attract more photographers. ̴Jim.henderson (talk) 21:41, 23 February 2023 (UTC)[reply]

Further Details clarifying Problem

Post scriptum: I was requested to clarify what exactly the problem is that I want to tackle. It's especially the lack of an interface that makes it harder to get in contact with Wikipedians outside your language version. Such an interface would facilitate Wikipedians, on all different projects, to engage with each other and request photos, videos, audio recordings, etc. This would mean that more articles and lemmas can get a proper photo, video or audio recording. If that content is uploaded to Wikimedia Commons we can literally all benefit from it. Wobuzowatsj (talk) 20:08, 30 January 2023 (UTC)[reply]
Great, I moved this to this section so that the translators could translate a shorter text. We are approving this wish to go into voting! Thanks for adding the context NRodriguez (WMF) (talk) 20:51, 30 January 2023 (UTC)[reply]

Voting

Wikipedia API: Output also in text or in TSV format

  • Problem: The output of the API is not in a simple format like plain text, but in JSON or HTML, where it is e.g. appropriate or requested (user request or according to API usage statistics).
  • Proposed solution: For example, enable this output, but via an API:
# List of revisions for user Dušan Kreheľ?
curl -s 'https://meta.wikimedia.org/w/index.php?title=User:Du%C5%A1an_Krehe%C4%BE&offset=&limit=500&action=history'|tr '"' "\n"|grep "oldid="|grep -v ";diff"|tr "=" " "|awk '{print $3}'|sort
21442049
21474908
21618555
21696280
22094013
22159891
22232863
22444821
22462733
23450518
23462853

Discussion

No please, JSON or XML is standard language to work with APIs. --Frettie (talk) 18:23, 10 February 2023 (UTC)[reply]

Moreover, there are plenty of command-line tools for massaging JSON data (and to a lesser extent, XML as well):
I can sympathise with wanting TSV output (it's far and away the easiest data format to parse and wrangle). It should be trivial to generate TSV output using the aforementioned tools; JQ sports a dedicated option for generating TSV-formatted output. Alhadis (talk) 19:10, 11 February 2023 (UTC)[reply]

Note that historically, the API supported a text format: txt. It was removed as it was useless: instead of a sensible format as proposed, it instead outputted human-readable debug information. —Mainframe98 talk 18:45, 10 February 2023 (UTC)[reply]

Voting

TOC in PDF versions can optionally include page numbers

  • Problem: The TOC of a pdf version is just a list of titles.
  • Proposed solution: The TOc can optionally include page numbers
  • Who would benefit: Users interested in printable versions of Wikibooks, as well as other users
  • More comments:
  • Phabricator tickets:
  • Proposer: Slava Ukrajini Heroyam Slava (talk) 19:11, 23 January 2023 (UTC)[reply]

Discussion

Voting

Fix security key (WebAuthn) support

  • Problem: MediaWiki's support for security keys (for example YubiKeys) via WebAuthn for two-factor authentication is, well, not very good. There are two main issues:
    • Security keys are tied to a single wiki. Combined with the broken cross-wiki auto-login mechanism this makes it annoying to log in.
    • It is only possible to add a single key to an account. Best practices for using security keys include having several keys with access in case a single key is damaged or lost.
  • Proposed solution: Fix the bugs mentioned above.
  • Who would benefit: Users who want to secure their user accounts.
  • More comments:
  • Phabricator tickets: phab:T244088, phab:T242031
  • Proposer: Taavi (talk!) 11:20, 30 January 2023 (UTC)[reply]

Discussion

Voting

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