Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Bots and gadgets

< Community Wishlist Survey 2023
Community Wishlist Survey 2023
Bots and gadgets
10 proposals, 211 contributors, 372 support votes
The survey has closed. Thanks for your participation :)



Edit-war-detecting bot or bots

  • Problem: Admins trying to calm down edit wars are limited to those they know about, those reported to AN/I, AIV, ANEW or RFPP. Others happen where the participants do not know to report or do not care ... I recall reading about one such EW that was discovered years ago by a similar technology to what I am proposing in which two users who edited only one article had been reverting each other up to 20 times a day on that article. Certainly there have to have been or be other situations like that.
  • Proposed solution: A bot that would, at the very least, look at edit summaries and tags for the keywords: "undid", "restored" or "reverted" (and maybe "3RR", "warn", "report" or "stop you stupid idiot"  ), as well as maybe edits that are substantially similar to each other in terms of affected content, being made in close proximity to each other. This is what I as a human do when reviewing ANEW or RFPP reports; it shouldn't be much harder for a bot to learn to do it.

    Such a bot could then make reports to a bot-reported section of, say, ANEW, much as the anti-vandal bots do at AIV.

  • Who would benefit: Everybody, in terms of edit wars less likely to go unnoticed.
  • More comments:
  • Phabricator tickets:
  • Proposer: Daniel Case (talk) 04:55, 6 February 2023 (UTC)[reply]

Discussion

I wonder if that was what I was describing. Daniel Case (talk) 03:23, 16 February 2023 (UTC)[reply]
with detection of "stop you stupid idiot" @User:Novem Linguae kindly created a dump of edit histories for a month.There are a LOT of false positives,but the abuse level was far lower than I expected (Does antivandalism remove them??? Wakelamp (talk) 10:38, 20 February 2023 (UTC)[reply]
@Iluvatar has a Discord bot with some related functionality. ~~~~
User:1234qwer1234qwer4 (talk) 17:34, 24 February 2023 (UTC)[reply]

Voting

Make Navigation Popups work on grandchild sub-cats from category pages

  • Problem: on a category page, en:WP:POPUPS already shows the members of immediate sub-cats. However, if these are "tipped open" to show grandchild or lower-level sub-cats by clicking the triangle icon, Popups does not show the members of those lower sub-cats when hovering a mouse pointer over them.
  • Proposed solution: Extend the functionality of Popups to show the contents of grandchild & lower subcats on category pages.
  • Who would benefit: Users exploring categories.
  • More comments: This would be of frequent benefit to participants & admins at en:WP:CFD, but also helpful to all readers who have enabled the Popups gadget.
  • Phabricator tickets:
  • Proposer: Fayenatic london (talk) 11:50, 2 February 2023 (UTC)[reply]

Discussion

Voting

A more performant bot to replace ListeriaBot

  • Problem: Since the release of ListeriaBot version 2, there is a problem with lists with many links to big entities (for example, links to countries), which make the list generation fail. See some previous discussions: 1, 2. The issue is reported in the official repository: magnusmanske/listeria_rs#66
  • Proposed solution: Create a new, more performant bot or fix the memory issues with ListeriaBot. An enhanced version of ListeriaBot, one that can carry us into the 2030s.
  • Who would benefit: ListeriaBot is used to automatically maintain lists of Wikidata items in various Wikipedias. It is used intensively by Women in Red in various languages, as well as other projects (3,204 lists in English, 1,152 in French).
  • More comments: A similar proposal by MarioGom was merged into this one.
  • Phabricator tickets:
  • Proposer: Edelseider (talk) 18:13, 23 January 2023 (UTC)[reply]

Discussion

Tracked in Phabricator:
Task T329380
Also see ListeriaBot returns "Last line: ERROR: Login failed":
M2k~dewiki (talk) 18:18, 10 February 2023 (UTC)[reply]

I think I fixed the problem that the "bot passwords" login did not work via API on some WMF wikis (any insight into that?) by switching the login to OAuth. I also fixed the table column problem, which was caused by a Pull Request that I foolishly merged. Right now the bot is somewhat limited by the Toolforge kubernetes constraints; relaxed constraints (more RAM, more CPUs per pod) would help there. Barring serious malfunction, the bot should now update every list on every wiki once every two days. If that does not work for some tasks, TABernacle provides a possible alternative. --Magnus Manske (talk) 14:37, 13 February 2023 (UTC)[reply]

I often get a Killed by Memory Overload message, if I dont limit the number of entries to 1000 (for example, depending on the number of columns) whith LIMIT 1000. For 1500 or 2000 entries I get a Killed by Memory Overload message. M2k~dewiki (talk) 14:40, 13 February 2023 (UTC)[reply]
@Magnus Manske:@M2k~dewiki: Even a slight change of query (see here), and it's "killed by OS for overloading memory". It has been like this and it still is like this. --Edelseider (talk) 15:50, 13 February 2023 (UTC)[reply]
What is concerning is the bot will load the entire item for each items involved. This is really not a good thing. GZWDer (talk) 18:27, 17 February 2023 (UTC)[reply]
Indeed. I haven't looked into this for a while, but the problem used to be not so much about number of results, but about number of big items present in some fields, such as some geographical entities. MarioGom (talk) 12:38, 18 February 2023 (UTC)[reply]

Voting

Make Navigation Popups & Page Previews work cross-wiki

Discussion

Voting

Support ASGI on Toolforge

  • Problem: Toolforge does not provide support for Python ASGI (Asynchronous Server Gateway Interface). This prevents tool developers from using modern, more performant frameworks such as FastAPI.
  • Proposed solution: WMF devs add toolforge support for ASGI
  • Who would benefit: Volunteer developers using toolforge, and the editing community, who benefits from new tools.
  • More comments:
  • Phabricator tickets: phab:T296729
  • Proposer: FASTILY 07:23, 25 January 2023 (UTC)[reply]

Discussion

Voting

Make Navigation Popups into an Advanced-mode of Page Previews

Discussion

Voting

DabFix

  • Problem: The DabFix tool for rapidly populating disambiguation pages is no longer available.
  • Proposed solution: Create an in-house version of DabFix capable of populating disambiguation pages with appropriate information (e.g., birth and death dates of human subjects, and short descriptions of their significance).
  • Who would benefit: Editors who create disambiguation pages.
  • More comments: Copied from a 2021 suggestion by BD2412. See that page for more comments.
  • Phabricator tickets:
  • Proposer: Certes (talk) 00:19, 2 February 2023 (UTC)[reply]

Discussion

Voting

DabLinks

  • Problem: The DabLinks tool for resolving links to disambiguation pages is no longer available.
  • Proposed solution: Create an in-house version of DabLinks, a semi-automated editing tool which helps editors to fix wikilinks.
  • Who would benefit: Editors who fix links to disambiguation pages.
  • More comments: The tool presents a page's wikitext, with links to disambiguation pages highlighted. Clicking on those links brings up suggested replacements – perhaps [[Mercury]] should read [[en:Mercury (planet)|Mercury]] – and assists the editor in replacing each link.
  • Phabricator tickets:
  • Proposer: Certes (talk) 00:26, 2 February 2023 (UTC)[reply]

Discussion

The source code can be found here, allow it has unclear licensing. Qwerfjkl (talk) 07:34, 5 February 2023 (UTC)[reply]
So it's hard to use other codes in the site. Thingofme (talk) 15:25, 11 February 2023 (UTC)[reply]
Gadget pl:MediaWiki:Gadget-disFixer.js allows to detect links to disambigs in current article and choose replacements. --Wargo (talk) 20:53, 13 February 2023 (UTC)[reply]
As do Navigation popups and w:User:Qwertyytrewqqwerty/DisamAssist.js. ~~~~
User:1234qwer1234qwer4 (talk) 17:39, 24 February 2023 (UTC)[reply]

Voting

Allow client-side scripts to convert dates in the format used in MediaWiki interface

  • Problem: Software, including MediaWiki APIs, usually handles dates in Unix time (e.g. 1672543856) or ISO format (2023-01-01T12:30:56Z), but MediaWiki shows them in human-friendly formats such as "04:30, 1 January 2023" or "2023年1月1日 (日) 20:30". But script developers have no access to the logic according to which these formats are produced (or even the difference between the user/site's time and UTC, which can vary with DST) and can't show dates in a way that is consistent with how the user sees the rest of the MediaWiki interface.
  • Proposed solution: Expose the server-side logic for formatting dates for each language/format through an API and develop a JavaScript library, perhaps as an extension to mw.language, that can convert a date in the format set by the site or user (and preferably vice versa).
  • Who would benefit: Users and developers of MediaWiki and its extensions, gadgets and scripts
  • More comments: PageTriage even replaced JavaScript's native Date object, which obviously ran into problems, so now it uses the Moment library, which is also to be replaced. Even then you can't account for every one of the numerous ways users see the MediaWiki interface without an unreasonable amount of reinventing the wheel, because various users, sites and languages use not only different timezones but different numerals, eras and calendars.
  • Phabricator tickets: T21992
  • Proposer: Nardog (talk) 06:51, 6 February 2023 (UTC)[reply]

Discussion

  • @Nardog: To clarify, this proposal is about exposing an API function to convert date/times (such as the timestamp 1672543856, or the ISO 8601 2023-02-07T20:16:29+00:00) to "human-friendly" date/times, such as those specified in Special:Preferences? — TheresNoTime-WMF (talk • they/them) 20:19, 7 February 2023 (UTC)[reply]
    @TheresNoTime-WMF: As opposed to...? The answer is yes, of course, but I'm not sure what I'm supposed to clarify between. If it's between a synchronous function that can convert dates completely offline (once the module is downloaded) versus an asynchronous one where you have to send the dates to the server every time, the former is obviously preferable, but failing that, an option to receive dates in a specified (or user-preferred) format in conjunction with the Unix/ISO dates in the same API call (much like you receive canonical page names) would be very handy, as those would be the primary use cases (I ran into the present problem as I built CatChangesViewer and MoveHistory, where I'm begrudgingly showing dates in ISO/UTC).
    AFAICS, the pieces of information needed to show a date in the same format as the MW interface are: timezone, format, numerals, era, and calendar. And currently only numerals are fully avaialble (via mw.language.getDigitTransformTable()). mw.user.options.get('timecorrection') gives only one value for the UTC offset so it's of little use; you have to match the location with a timezone database (which Moment provides—perhaps the data should be its own RL module). The formats (like H:i, F j, Y) are in /languages/messages/. AFAIK they aren't available through the message or languageinfo API, and it'd be swell if they were. The logic for non-Common eras and non-Gregorian calendars (in use in Iran, Thailand, Japan, etc.) appears to be in Language.php. It doesn't look too complicated to port to JS but it'd be nicer if both server and client used the same codebase.
    (The opposite direction (from a formatted date to a computer-friendly one) is harder and probably in less demand, but come to think of it, it's exactly what DiscussionTools has figured out, isn't it? It's how it tells where each comment ends and the next begins after all. Exposing that function as an asynchronous API might prove useful.)
    Now I'm realizing none of these seem like "less than a year-long project", and I'm talking myself out of the original proposal! How about changing the solution to something like:
Proposed proposed solution

An option in <tvar name=1>Action API</tvar> that, if the response contains any dates, appends versions of them in the language/format/timezone specified in the request (somewhat similar to the "<tvar name=2>normalized</tvar>" object in <tvar name=2>action=query</tvar>). It should accept values like "<tvar name=3>site</tvar>" (the site's default format) and "<tvar name=4>user</tvar>" (the logged-in user's preferences) in addition to specific languages/formats/timezones (like <tvar name=5>uselang</tvar>). And a separate but similar API function that receives acceptable timestamps and returns them in the language/format/timezone specified in the request.

Nardog (talk) 00:31, 8 February 2023 (UTC)[reply]
Thank you, was just wanting to make sure I understood the scope correctly   As an aside, this would be a really useful thing to have from my own volunteer dev experience wrestling datetime formats.... — TheresNoTime-WMF (talk • they/them) 10:16, 8 February 2023 (UTC)[reply]
Okay, then I guess the alternative above should be thought of as a starting point or an acceptable compromise. Nardog (talk) 18:36, 8 February 2023 (UTC)[reply]
  • Modern Javascript has Intl.DateTimeFormat which is very capable (arguably more capable than MediaWiki's server-side logic). Unless your goal is to very specifically match the server-side date format, or to parse human-readable date strings back into numbers, you are probably best off doing that. --Tgr (talk) 03:12, 11 February 2023 (UTC)[reply]

Voting

Automate WikiProject weekly collaborations

  • Problem: Collaborations such as the historical WikiProject collaborations of the week are a proven effective wiki-based tool for improving vital articles, but they are hard to maintain in the long-term, requiring a dedicated volunteer to manage them every week or month.
  • Proposed solution: Universalize the automation system established for Articles for improvement on enwiki, so that it can apply to any language, WikiProject or arbitrary list of articles.
  • Who would benefit:

Discussion

Voting

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