2017 Community Wishlist Survey/Bots and gadgets

From Meta, a Wikimedia project coordination wiki
Jump to: navigation, search

2017 Community Wishlist Survey

Bots and gadgets
11 proposals, 36 contributors

Go-previous.svg Anti-harassment  •  Citations Go-next.svg

Wikidata reference "stated in" from url bot

Edit proposal/discussion

  • Problem: Many Wikidata items with reference urls do not have a "stated in" property. This makes it hard to quickly glance at item references to determine source and potential trustworthiness by seeing a name. Also, makes it harder to potentially run queries that could generate a list of potentially notable items by Wikidata references to create a worklist for edit-a-thon organizers using the query engine.
  • Who would benefit: community and people running workshops
  • Proposed solution: a bot is created that sees a url from P184 on references like www.nytimes.com or huffingtonpost.com and adds a "stated in" of "New York Times" or "Huffington Post".
  • More comments: Beyond this, general improvement of referencing section of Wikidata would assist in credibility building, by encouraging more people to add references.
  • Phabricator tickets:


  • Isn't this something that should be proposed at the Wikidata community? And if it is approved there, shouldn't it be handled as a regular community-bot task? Alsee (talk) 06:24, 8 November 2017 (UTC)
I don't know enough about bot development to do it. --LauraHale (talk) 10:49, 9 November 2017 (UTC)
I don't think we have to worry about the bot being too complicated, if it gets approved someone can probably do it. A Den Jentyl Ettien Avel Dysklyver (talk) 14:56, 9 November 2017 (UTC)
This should probably be tackled on Wikidata. Sourcing on Wikidata is currently done in different ways and isn't very consistent.
  1. Get agreement on the best and consistent way to source things.
  2. Inform bot operators of the consensus so they can update their code
  3. Run bot jobs to make existing sources more consistent
  4. Set up regular reports and bot jobs to improve sources.
I think the first step is actually the most difficult one. Feel free to copy this somewhere on Wikidata. Haven't really gotten around to starting this discussion. Multichill (talk) 16:51, 17 November 2017 (UTC)

P184 is doctoral advisor, you probably meant something else. --Tgr (WMF) (talk) 05:55, 18 November 2017 (UTC)

Wikipedia in the news

Edit proposal/discussion

  • Problem: Wikipedia in the News is currently maintained in two locations: WP:Press coverage master list, and article talk pages with Template:Press. It's done manually with high overhead. It's something of a PITA to add stories so coverage is haphazard.
  • Who would benefit: all editors and journalists
  • Proposed solution: A web-based form for adding 'In the News' events. It automatically adds entries to the appropriate places (talk pages and master lists).
  • More comments: Data could be stored in Wikidata. Modify templates to draw from Wikidata. This will allow truly global 'In the News'
  • Phabricator tickets:
  • Proposer: GreenC (talk) 20:35, 9 November 2017 (UTC)


  • You're talking only about enwiki, right ? --Framawiki (talk) 17:57, 17 November 2017 (UTC)
Initially that seems like a good idea, but with the vision if the external links were stored in WikiData there's no reason it couldn't become a global database of Wikipedia in the News, regardless of country or language. -- GreenC (talk) 21:02, 18 November 2017 (UTC)

Make Flow database accessible on Tools Labs

Edit proposal/discussion

  • Problem: Flow is a new extension that totally change user experience about discussions, and technical specifications. One of the important problem of the usage of this extension on Wikimedias wiki is that tools, bots and other programs hosted on Tools labs servers can't access easily to these datas. For example, the web service that provide lots of statistics about users can't deal with Flow edits, that are not take into account.
  • Who would benefit: Users of the many applications hosted on the tools. Many bots and other tools could benefit indirectly from it.
  • Proposed solution: Make Flow database available / accessible on Labs/Tools, so developers can access to these datas and show them to readers.
  • More comments:


  • Noting that this is currently blocked by phab:T69397 MusikAnimal (WMF) (talk) 18:35, 17 November 2017 (UTC)
    I've changed this proposition according to this consideration, but I'm not sure that it fits completely within the scope of CommunityWishlist. --Framawiki (talk) 20:44, 17 November 2017 (UTC)

Turn UTCLiveClock into an extension

Edit proposal/discussion

  • Problem: The UTCLiveClock is one of the most used gadgets across the projects (typically within the top 5). There are 3 problems with it:
    1. It loads after the rest of the page loads, which causes the other links in the user toolbar to shift, often leading to people accidentally clicking the "Log out" link.
    2. Some projects don't have the gadget.
    3. Because it's a gadget rather than a preference, it won't be available as a global preference.
    Turning it into a extension will solve all three of these problems.
  • Who would benefit: All current and future users of UTCLiveClock
  • Proposed solution: Turn it into an extension with its own preference. Migrate people who are using the existing extension.
  • Phabricator tickets:
  • Proposer: Kaldari (talk) 20:01, 8 November 2017 (UTC)


  • I added a similar idea to mw:Extension:Purge the other day: https://github.com/Hutchy68/Purge/issues/16 Perhaps the UTCclock and MediaWiki:Gadget-purgetab.js could be combined into one extension? Sam Wilson 00:30, 9 November 2017 (UTC)
  • I have all sorts of things up there in my top bar, which looks like: A Den Jentyl Ettien Avel Dysklyver - Alerts (0) - Notices (0) - Talk - Sandbox - AfDs Closing - Page Curation - AfDs Today - AfDs All - Preferences - Beta - Watchlist - Contributions - Log out - 15:10:00, and they load all at different times over a few seconds, anything to get them to load at the same time would be useful. A Den Jentyl Ettien Avel Dysklyver (talk) 15:13, 9 November 2017 (UTC)
  • It's a bit hacky, but you can use peer gadgets to put in the space with CSS before the JavaScript loads, so that things don't jump around. This is already being done with the UTCLiveClock gadget on English Wikipedia and mediawiki.org. If you wanted to source the gadget as a user script (in global.js, for instance), you'd have to add the necessary CSS as well (e.g. see the bottom of User:MusikAnimal/global.css). But an extension is still better! I think it makes just as much sense to include it as part of Purge, too — MusikAnimal talk 20:17, 9 November 2017 (UTC)
  • I understood that Performance team were working to remove the purge action entirely from MediaWiki. This seems to go against that work? Jdforrester (WMF) (talk) 02:16, 15 November 2017 (UTC)
    That's being tracked in phab:T56902, and seems like it'd be a reasonably complex and lengthy project (that ticket's been open for four years). On the other hand, cleaning up these gadgets would be a pretty easy thing to do (and most of the work has already been done). So I think it's still worth it, even if it's only used for a year or two. Maybe. Happy to be convinced otherwise though! Sam Wilson 06:47, 15 November 2017 (UTC)
    Fair. I'm just uneasy about giving such high profile endorsement (even if we don't think of it that way) to a feature we're already planning to kill… People might feel misled. Jdforrester (WMF) (talk) 20:08, 15 November 2017 (UTC)
    The Performance team is working on making sure that purges are never triggered with GET requests. Getting completely rid of them is more of a long-term aspiration (that would require major changes in our caching and parsing architecture) than something being worked on, I think. --Tgr (WMF) (talk) 06:09, 18 November 2017 (UTC)
  • I agree that we should assume that purging will eventually be deprecated (even though it might take a very long time for that to happen). Thus I would favor implementing this as a separate extension that has purging as an optional feature, rather than turning the UTC clock into an optional feature of the Purge extension. Kaldari (talk) 22:46, 16 November 2017 (UTC)
  • The clock thing is one of those usability train wrecks that have been around so long that we have mostly stopped noticing how bad they are. Using a clock to purge the current page, and then putting it into the personal toolbar, just makes no UX sense whatsoever. As a clock, it has poor usability anyway; the reasonable approach would be something like Google Calendar's world clock where you can set which timezones you want to see (plus maybe integration with timestamps on the page). But I doubt anyone cares about the clock part anyway. The purge link should just live in the page action dropdown. --Tgr (WMF) (talk) 06:09, 18 November 2017 (UTC)

Convert AWB into a special page

Edit proposal/discussion

  • Problem:
    • Malfunctions
    • No translations
    • Need to download and continuous updates
  • Which users are affected?
  • Who would benefit:
    • All program users (including administrators)
  • Proposed solution:
    • Conversion AWB to a special page can only be used by program users (including administrators) and will be translated into all languages by translatewiki.net
    • And we will get rid of d:Q11214943
  • More comments:


Fix search in AWB

Edit proposal/discussion

  • Problem: For AutoWikiBrowser it is impossible to make the list using insource with regexp and other keywords. The list has to be done in other complex ways, although in Wikipedia everything works through a simple search.
  • Who would benefit: AWB editors
  • Proposed solution: Improve the search in AWB so that it works with keywords and so that you can pick up a list of what you can get in the search on the site. Would be useful search option in a separate namespace.
  • More comments:
  • Phabricator tickets:


brainstorming for wiktionaries

Edit proposal/discussion

  • Problem:

It is impossible from the current form of all wiktionaries to create a pdf book for:

    • lang to lang (definitions only, ex. Italian-English)
    • specialized dictionary of lang (ex. Greek medical dictionary, Magyar etymological dictionary)

Also it is impossible to view a wiktionary only in the above mentioned way.

  • Who would benefit:


  • Proposed solution:

Create a page for proposes on how to achieve this.

    • by creating gadgets?
    • by creating new mediawiki extentions?
    • ...

Maybe one or more trial new (lang)projects that will collect (temporarily) data from some selected wiktionaries in order to make there trials.

  • More comments:

Most wiktionaries differ in the way they present data. It is difficult to create a common gadget. That's why I am not proposing a gadget but a place to discuss problems and solutions specific to that direction.

  • Phabricator tickets:


Science templates

Edit proposal/discussion

  • Problem: Generally, all edits need a reference. But science is arithmetics, so F= °C, miles= km and meter= feet conversion templates are allowed.

For example, cristalline minerals with a solved structure have a position for each atom. Chemical formulas need to be charge-balanced, but copies and typos make errors and these errors live forever (there are ions, but their half-life is less than one second). I think that in the next 25 years we should check more data on Wikidata. A scientist makes many experiments, he publishes some experiments, the papers are cited in a secondary literature, the secondary literature is cited in Wikipedia. The sources for errors are unbelievable infinite. Cristal structure, atomic volume and chemical formula are interlocked through arithmetics. There are many possible errors, at no time is everything right.

  • Who would benefit: science articles.
  • Proposed solution: the laws of physics should get more templates and bots.
  • More comments:
  • Citation (CNMNC Newsletter 39 (August and September, 2017)): "After the approval of the new mineral magnesiobeltrandoite-2N3S (IMA2016-073; see CNMNC Newsletter 34 (October and November, 2016)) the authors became aware that the approved chemical formula of the mineral was not charge-balanced."
  • Citation (rruff.info/ima): "Note that chemical formula is not charge-balanced in this report. The formula from the 1987 paper is kept."
  • Hogarth D D (2006) Fluoro-potassic-magnesio-arfvedsonite, KNa2Mg5Si8O22F2, from the Outaouais region, Quebec, Canada, The Canadian Mineralogist 44, 289-289.
  • Phabricator tickets:


  • How is this problem not solved by creating the templates and Lua modules yourself and having a community-run RFC for a find and replace? No development work is necessary. MER-C (talk) 12:50, 10 November 2017 (UTC)
    • This problem is huge (strategic). Science is arithmetics, Wikidata building must aim for interlocking its data. For example, the chemical formula would need a periodic table as data in the background. We do not have cristallographic data of a mineral structure, this would be a huge data input. Sure a programmer can make initial steps with templates and lua modules (maybe, the initial step should be physics). It is "just" a wake up call, and strategy is meta. --Chris.urs-o (talk) 05:53, 11 November 2017 (UTC)
  • @Chris.urs-o: If I understand correctly, you're talking about things like being able to, "list all statements citing a source that cites a specific journal article that was retracted"1 - if that is correct, see d:Wikidata:WikiProject Source MetaData and WikiCite for the people already working towards this. If I've misunderstood, please explain in a bit more detail. Thanks! Quiddity (WMF) (talk) 23:36, 13 November 2017 (UTC)
    • It is about strategy. Science is arithmetics. A chemical formula of a mineral should be charged-balanced. The measured density and the calculated density (atomic volume and mass) of a mineral structure should be the same; and so on... The physics of many numbers (data) should be interlocked to find out any typos. Something must be done in the future. --Chris.urs-o (talk) 04:54, 14 November 2017 (UTC)
      • @Chris.urs-o: Ah, now I think I understand. You are proposing something more akin to wolframalpha. This would be to help with various things within the existing content projects, such as prevent typing errors (perhaps by highlighting when an editor has typed something physically impossible, e.g. Al + O2 -> Al2O4 (should be Al203, per)). -- If that is correct (?) it is a grand idea, but much too big in scope for this wishlist process. I recommend starting a new page at Computational engine or similar, to give more detail to the idea and more time for slow discussion. I'll move this proposal to the archive section in a day or two. Cheers :) Quiddity (WMF) (talk) 20:31, 17 November 2017 (UTC)
        • Ok, you are right. The literature has typing errors as well. --Chris.urs-o (talk) 21:11, 17 November 2017 (UTC)
  • Are you basically asking for arithmetic-based Wikidata constraints? --Tgr (WMF) (talk) 05:43, 18 November 2017 (UTC)

Keep maintenance categories and links up to date

Edit proposal/discussion

  • Problem: Changes to MediaWiki code related to parsing can leave links tables out of date. Sometimes code changes will add new tracking categories, typically related to error tracking. But until the page is edited, null edited, or purged with links update, the page will not show up in the category. Some pages do not get edited or refreshed for years, which means that errors in pages will go undetected and unfixed.
  • Who would benefit: Gnomes; WMF developers who want to move to new technologies but need editors to clean up existing pages first; readers who encounter strange page behavior.
  • Proposed solution: Null-edit all unedited pages, or do some equivalent action, on a known periodic basis, perhaps once a month. Publicize the schedule so that it is known that any new template changes or MW code changes may take N weeks to be reflected in all relevant locations on the corresponding MW site.


  • In theory that sounds like a great ideea, which I support. However, it worries me that that could lengthen the category update time even more, and right now they're SLOW. What can we do to mitigate this risk?--Strainu (talk) 12:31, 7 November 2017 (UTC)
  • I like it but who would be responsible for the Null editing/updating the categories you reference? Zppix (talk) 19:37, 7 November 2017 (UTC)
  • That's a big problem on Commons. In general, most (if not all) pages the categories of which are assigned via templates suffer from that. Right now about 1,400,000+ pages on Commons are not categorised correctly due to that problem. If a category is changed by altering the template a touch on every template-categorised page is necessary to fix the categorisation that else stays pointing to a redirecting page. Another example: Because c:Category:Non-empty disambiguation categories had become completely useless keeping about 8000 empty categories I started many months ago a weekly touch run for to keep it usable. --Achim (talk) 20:24, 8 November 2017 (UTC)
  • I would support this, but only if the null edit does not appear in edit history's, and happens at a long schedule, something like monthly or yearly runs, repeating, with all articles spread over the month/year to avoid server load. A Den Jentyl Ettien Avel Dysklyver (talk) 14:51, 9 November 2017 (UTC)
  • null edit can be done using pywikibot's touch.py. But this is solution only for smaller wikis, ~100k pages takes ca 10 hours. JAn Dudík (talk) 11:54, 10 November 2017 (UTC)
  • I think it would be useful to add touch capability to AutoWikiBrouwser, as proposed in phabricator:T167283, so there is more than one way to touch pages. --Jarekt (talk) 19:36, 15 November 2017 (UTC)

Commons deletion notification bot

Edit proposal/discussion

  • Problem: When images that are used in a Wikipedia article are put up for deletion on Commons, the Wikiproject or article associated with those images are not notified.
  • Who would benefit: The Wikiprojects may have connections with the uploading institution and thus able to get permission or may be able to find a substitute for the image being deleted. Either way it will improve collaboration between WP and Commons.
  • Proposed solution: Add links to these Commons discussions to the Article Alerts for Wikiprojects and / or the article talk page
  • More comments:


Supposedly there is something on Fr WP that does this.[1] Doc James (talk · contribs · email) 21:49, 13 November 2017 (UTC)

  • @Doc James: Hi. (1) I suggest you tweak this proposal to be more focused on individual uploaders, and less focused on WikiProjects which don't exist (or work in consistent ways) in many language Wikipedias and sibling projects. (2) See also 2016 wishlist...#Automatic notification of page creators when page is nominated for deletion, and the more positive 2016 wishlist...#Notifications for when your image is used for related ideas & discussions from last year. :) Quiddity (WMF) (talk) 00:10, 14 November 2017 (UTC)
    • Sure the bot could also notify the individual account that uploaded it and put a note on the talk page of the article that will be affected. Doc James (talk · contribs · email) 00:15, 14 November 2017 (UTC)
      • A notice on the talk page of the article (where the file is used) would be really nice. The notice can be uniform, but it should use prepared translations (f. e. German translation for German wikiprojects). --Vachovec1 (talk) 20:56, 14 November 2017 (UTC)
      • @Doc James: Please update the actual proposal wording above, so that when voting begins, people can get the clear summary from just reading the summary. (This discussion section might be collapsed when the voting starts, as it was last year. This section is primarily for us to discuss improvements to the proposal wording, before the voting starts.) Thanks! Quiddity (WMF) (talk) 21:51, 16 November 2017 (UTC)

Happened to notice this discussion right after I posted about the same thing at w:Wikipedia:Village pump (idea lab)#Notification system for files on Commons nominated for deletion. If there's enough support for it then I'm happy to tackle this task -FASTILY 23:46, 16 November 2017 (UTC)

Daniel Kinzler's bot CommonsTicker did that a long time ago, but fell into disrepair. --Tgr (WMF) (talk) 05:50, 18 November 2017 (UTC)

Deploy Article Alerts to other languages

Edit proposal/discussion

  • Problem: Article Alerts, is an automated subscription-based news delivery system designed to notify WikiProjects and Taskforces when articles tagged by their banners or placed in their categories enter various formal workflows (such as Articles for Deletion, Requests for Comments, Peer Review, and many more). See WikiProject Physics/Article alerts for example. This is currently an English-Wikipedia exclusive, and is maintained by one user (en:User:Hellknowz), meaning the bus factor leaves the whole project in a fragile state.
  • Who would benefit: Every edition of Wikipedia. For scale, on the English Wikipedia, 1467 WikiProjects and Taskforces subscribed to the Article Alerts system. Virtually every active project is subscribed, and the system is one of the best lines of defense against improper deletions and one of the best ways to advertise ongoing high-level discussions to communities of interest.
  • Proposed solution: Have the WMF / larger Wikimedia community create a more solid and scalable framework for Article Alerts that can be deployed to all languages. Maybe it's not possible to have something as customizable as the English Wikipedia's implementation, but there are loads of things that could be ported and deployed.
  • More comments:
  • Phabricator tickets:


  • I rank this as one of the most useful watchlist tools on en.wikipedia, and the bus factor worries me, although the code could presumably be shared even as is. However the main barrier to overall global implementation is probably on places like simple.wikipedia where there are no WikiProjects and the category’s are generally incomplete. Therefore it will probably be of more use on Wikipedia language editions with a larger userbase like de.wikipedia. A Den Jentyl Ettien Avel Dysklyver (talk) 15:08, 9 November 2017 (UTC)
To clarify, there is redundancy in code access (two people have it), the problem is that there's only one coder. This makes new features / bug fixes /general maintenance dependent on the will, time, and capabilities of one person. Running the bot on the toolforge would also be great and make the bot more reliable during holidays if there's a power failure and such. The bot clearly is more useful for the larger Wikipedias (certainly all 10 Wikipedias feature on the main landing page would greatly benefit from this), but if a framework can be designed and ported, it wouldn't be a lot of work for dedicated subcommunities on smaller wikis to benefit from this as well even if it's easier to follow every discussion on a smaller Wikipedia. Headbomb (talk) 18:33, 9 November 2017 (UTC)
  • I love Article Alerts! It is a great tool that can be used for informing large groups of editors about issues that interest them without annoying others. It is also wonderful for those interested in collecting wiki-statistics. Wikiprojects that have been set up to look after a group of articles can add Article Alerts to the wikiproject with minimal effort, and have the Article Alerts available to anyone who knows where to look for them. There was a good Signpost article about Article Alerts back in 2009.
The en.wiki has thousands of Wikiprojects (the Signpost has many articles about individual wikiprojects). Wikiprojects are a great way for editors to find other editors interested in a certain topic, which can be a great motivator for many. Tools such as Article Alerts help shift the burden of running wikiprojects from human editors to BOTs. This in turn helps retain editors since much of this task is repetitive/tedious and tends to burnout humans.
I am shocked to hear that Article Alerts depends on one individual editor. I hope the Wikimedia Foundation has taken out an enormous life insurance policy on this individual. Ottawahitech (talk) 17:17, 12 November 2017 (UTC) Please ping me