Wikimedia Meta-Wiki

Community Wishlist Survey 2022/Bots and gadgets

< Community Wishlist Survey 2022
Community Wishlist Survey 2022
Bots and gadgets
13 proposals, 252 contributors, 418 support votes
The survey has closed. Thanks for your participation :)



Fix ListeriaBot memory issues

  • Problem: Since the release of ListeriaBot v2, 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: Fix the issue with loading big external entities, possibly a caching problem.
  • 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:
  • Phabricator tickets:
  • Proposer: MarioGom (talk) 19:49, 10 January 2022 (UTC)[reply]

Discussion

  • I'm afraid this might be out of scope, although I'm not sure. Listeria is a tool by Magnus Manske. If the issue is the tool running low on memory or resources, this should probably be addressed by Toolforge and/or Cloud VPS admins (if it runs there) and ask them to increase the memory quotas. If the issue is with the tool code itself, however, I'm afraid this can only be fixed by Magnus. I note that the repository does not have any license (Issue #80) so contributing patches over there might not be possible or advisable either. CC: MusikAnimal (WMF). Best regards, —MarcoAurelio (talk) 12:27, 11 January 2022 (UTC)[reply]
    I haven't done much investigation but I assume we'd be able to help in some way, either assisting the bot operator or building something new from scratch, if we have to. Perhaps a job queue system needs to be introduced, or assuming it lives on Toolforge, maybe this is deserving to move to VPS where we have more memory to work with. Or maybe it's a simple as giving the bot more memory on Toolforge. So while there is a reliance on Magnus Manske, I wouldn't necessarily say this is out of scope, in my view. MusikAnimal (WMF) (talk) 14:27, 11 January 2022 (UTC)[reply]
    I agree, this should go to the bot operator himself to correct the code. Some bots are controlled by the community, I think... Thingofme (talk) 02:36, 12 January 2022 (UTC)[reply]
    most bots are —TheDJ (talk • contribs) 10:52, 12 January 2022 (UTC)[reply]

Voting

Give gadgets the option to read current timezone used on wiki

  • Problem: Many wiki's use other timezones than UTC, some of them even alternate with daylight saving time (DST). As a result, some gadgets that use the current time on the wiki (Twinkle for example) have to be modified when ported to another wiki. Also, JavaScript does not have a nice solution to detect when a wiki goes in to DST. (An example is nlwiki switching between CET and CEST).
  • Proposed solution: Create a JavaScript variable (eg. mw.currenttimezone) with the time difference from UTC as its value.
  • Who would benefit: All wiki's that do not use UTC as their timezone.
  • More comments:
  • Phabricator tickets:
  • Proposer: Bas dehaan (talk) 21:15, 22 January 2022 (UTC)[reply]

Discussion

Voting

Add option to insert category before current category in Cat-a-lot

  • Problem: Suppose you are browsing a certain category on Wikimedia Commons. Using Cat-a-lot, you decide to pick a couple of files and add another category to them. The new category will be automatically added next to the category you are browsing. But you might wish that the new category will be inserted before the category you are currently browsing, instead of after it, if you think the order of categories of files important. Currently, Cat-a-lot doesn't allow you to do this.
  • Proposed solution: Make it possible for a user to choose that a new category be inserted either before or after the current category.
  • Who would benefit: All Wikimedia Commons users.
  • More comments:
  • Phabricator tickets:
  • Proposer: トトト (talk) 20:36, 10 January 2022 (UTC)[reply]

Discussion

  • I think the people who benefit from this idea is not only the Commons users, but also some users who use Cat-a-lot on other wikis. However, the order of categories is sometimes important for big-small category. Thingofme (talk) 00:51, 11 January 2022 (UTC)[reply]
  • Today I learned categories are actually displayed in the order they appear on the page, so this proposal has an actual purpose. I was sure categories are sorted alphabetically in the parser output. ToBeFree (talk) 06:22, 11 January 2022 (UTC)[reply]
  • It would be nice if categories displayed in alphabetical order. It saves time when checking if a page is in a specific category, or in each of a set of categories. It would also be nice if a category editing tool collected and sorted the categories in the wikitext automatically when used. Also useful on Wikipedias · · · Peter (Southwood) (talk): 07:43, 11 January 2022 (UTC)[reply]
    • en:User:Alex_21/script-categoriessort is "a script that sorts categories in an article alphabetically." It makes an edit and saves the changes to the live article. Apparently it's contentious whether cats should be alphabetized vs organized in other ways. But it seems like it wouldn't be hard to write a .js that simply operated on the display (reader-level) rather than changing the article source itself for those who wanted it. DMacks (talk) 10:45, 11 January 2022 (UTC)[reply]
    • The order of categories is VERY contentious within the WP projects. In German WP, biographies are categorized by "field of profession", "all other categories", "birth by...", "death by...", "gender", just for example. Contrary, on Commons I don't think there is any preferred order - instead we are glad if correct categories exist at all. --Enyavar (talk) 12:04, 11 January 2022 (UTC)[reply]
      Additionally, some scripts/bots are definitely re-ordering them alphabetically along with other non-cosmetic changes – changing the behaviour within Cat-a-lot would be contrary to this apparently non-controversial kind of generic cleanup. ~~~~
      User:1234qwer1234qwer4 (talk)       22:17, 7 February 2022 (UTC)[reply]
  • I would support this. Daniel Case (talk) 06:01, 13 January 2022 (UTC)[reply]
  • Categories represent relations. So the order of cat entries on a page is a purely cosmetical thing. --Achim55 (talk) 18:44, 17 January 2022 (UTC)[reply]
  • You haven't explained why you think the order in which the categories are displayed is important, or why it would be useful to have some subjective ordering of categories. Since categories are basically a poor man's ontology (unlike proper ontologies like Wikidata is becoming), and a category simply denotes a class of an instance, specifying subjective category orderings makes no sense, in general. I suppose I might support the ability if it only applied to the user, i.e. if a particular user wants categories on a page to be displayed in a particular arbitrary order for them, so be it. But having some global subjective category ordering is undefined and meaningless. Silver hr (talk) 17:35, 1 February 2022 (UTC)[reply]

Voting

A bot or gadget to publish public Git repo to a gadget or user script

  • Problem: It is hard to develop JavaScript scripts and gadgets within MediaWiki. No build tools (especially transpilation), no way to push out changes to many files in one go. Also no review tools (like pull requests).
  • Proposed solution: Provide a publishing tool that would effectively publish a script from e.g. GitHub or GitLab to one of Wikipedia sites. I would assume that the code repository would need to be public (to avoid authentication). On the other hand the tool would publish as the user using it. So the tool would need to have Wikimedia OAuth or use Bot passwords. The publishing tool would be setup using:
  1. Some title of the gadget.
  2. Source and destination URL(s).
  3. Additional info like e.g. default publish message (e.g. providing source URL in the description but also attribution).
  4. Note that I assume the person creating the publisher do not have to be the author of the script.
  5. Once the gadget-publisher is set up, one can publish with one click (optionally adding info to the default publish message to e.g. add version info).
  • Who would benefit: Gadget developers and their users
  • More comments: So at the time of writing Gadgets only support ES5. It is nice that some work on ES2015 is starting, but you know this is kind of all figured out in the frontend world. I think it would all just be easier if wiki developers would use things most other frontend devs use and just quickly publish to Wikipedia. It shouldn't be too hard. The hardest part would probably be making a decent GUI and auth. Other then that you just download one text file and push the text to wiki.
  • Phabricator tickets: (related)
    • phab:T36958: User-level gadget repositories
    • phab:T71445: Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites.
  • Proposer: Nux (talk) 00:22, 19 January 2022 (UTC)[reply]

Discussion

Come to think of it probably more then one file per gadget would need to be published in some cases. For example build.js (could be a result of Babel transpilation or simple Gulp concatenation) and build.css (maybe built with Less or Sass). And probably some meta like name/title and maybe a project description. Default publish message would be a good thing too. --Nux (talk) 00:48, 19 January 2022 (UTC)[reply]

This task probably wants ES6 to be fully supported in gadgets based on the motivation, which is probably phab:T75714 (and phab:T178356?), so that might be a good separate wish. Izno (talk) 05:03, 19 January 2022 (UTC)[reply]
A proposed bot could easily implement babel to transpile ES6 code to ES5 Ed6767 (talk) 10:53, 19 January 2022 (UTC)[reply]
meh. I don't think naive ES6 is critical, babel and rollup or web pack or whatever can take care of that just as part of the build process.. What I do think would be pretty cool is if we had some sort of NPM package and json standard that would allow you to map dist/ paths to pages on a wiki and then would automatically publish it for you (if you have the credentials). —TheDJ (talk • contribs) 09:33, 19 January 2022 (UTC)[reply]
Yes, something like that. But not with JSON as I would prefer a GUI. That would make this more independent and easier to extend. When you have some description standard then adding new fields and references is getting complicated and progresses slowly. Also there really is no need for the tool to be published just by the author of the script. I think it would be good if anyone could update the script. Nux (talk) 11:17, 19 January 2022 (UTC)[reply]
This request seems to mix easy publishing and a request for ES2015 and I really think those are two separate things that should not be in one request. "but you know this is kind of all figured out in the frontend world" Cool and all, but as long as there is no PHP implementation of an ES2015 parser, that's irrelevant to us, since we are NOT frontend and NOT nodejs, and shelling out to other languages for essential functionality is problematic (see parsoid which was in nodejs but is now in php again, because it was too problematic). —TheDJ (talk • contribs) 09:41, 19 January 2022 (UTC)[reply]
I'm proposing easy publishing instead of tools for building stuff. And I would argue that gadgets are from frontend world. I did some changes in popups a few years back and it was... well a bit of a headache. It would be so much easier if I could just fork a repository for plwiki and the changes I need. Maybe add a pull request for some of them. Then just compile and click to publish. Nux (talk) 11:24, 19 January 2022 (UTC)[reply]
@Nux I agree with TheDJ and others that the wording of the proposal seems to imply you want (a) ES2015+ support in gadgets/user scripts and (b) essentially a deploy script from a GitHub repo to the wiki. I think focusing on just (a) would be more appropriate. For (b), it might be difficult to come up with a standardized system that works for everyone. Many gadgets such as MoreMenu and Twinkle are written in ES2015+ and transpiled it to ES5 as a build step. That build step can vary based on developer preference. Some like GruntJS, others like Webpack, etc. A configurable deploy script, with a CLI interface (give it your BotPassword credentials, the JS file and the wiki page to deploy it to) is something I think we could make, and quite easily at that. But I don't think it's good to mix both ideas of build steps and deployment, since this varies.
Do you think you could reword this proposal to focus on either (a) native ES2015+ support in gadgets/user scripts or (b) a configurable deploy script (that does not include build steps like ES5 transpiling)? MusikAnimal (WMF) (talk) 18:58, 20 January 2022 (UTC)[reply]
@MusikAnimal (WMF) OK, I re-worded the problem description. ES2015+ was just an example of things that are hard because of how MW works. I also added some more info in the Proposed solution part. Let me know if you think it is still not clear yet. --Nux (talk) 22:25, 20 January 2022 (UTC)[reply]
This looks great, thank you! The problem statement I think is more clear now. We can definitely deliver on the deploy script. Rethinking this, as a CLI tool (pass in BotPasswords credentials) or even a Toolforge tool (where you login with OAuth), we should be able to offer build steps as options, such as ES5 transpiling. We can iterate on it together :) Thanks for putting all this work into your proposal! I'm going to mark it for translation now. MusikAnimal (WMF) (talk) 05:03, 21 January 2022 (UTC)[reply]
I also trimmed down the proposal a tiny bit to aid translators (hope this is okay!), and removed the mentions of phab:T75714 and phab:T178356. These are going to happen anyway, and are about ES2015+ support in gadgets (which is what I originally thought you were talking about in your proposal). Anyways again, your problem statement is clear, and that's all that matters. Together we'll come up with the best solution! MusikAnimal (WMF) (talk) 05:30, 21 January 2022 (UTC)[reply]

Voting

Gadget: Who is active

  • Problem: Sometimes you look for any active user on a list of users (campaigns, WikiProjects, experts etc.) to make a request. Often you have to check many of them until you find one active. Sometimes no one on a given list has been active for years and only time is wasted.
  • Proposed solution: There is a script that allows to see, after entering the user's page, when the user made the last edit. Perhaps we could build a tool that would present such information next to the link to the user page, just like the gadget "Replies with links" does. The displayed information could be the date of the last edition, or the active / inactive icon, if the user also set in their .css the range to which someone is considered as active (X minutes, X hours, X days, etc.).
  • Who would benefit: Organizers, Wikimedians looking for active users on various lists
  • More comments:
  • Phabricator tickets:
  • Proposer: Hedger z Castleton (talk) 17:16, 20 January 2022 (UTC)[reply]

Discussion

Navigation popups will show the date of a user's first and latest edits. Reywas92 (talk) 20:58, 3 February 2022 (UTC)[reply]

Supported: but please keep the privacy safe. 🌸 Sakura emad 💖 (talk) 19:01, 7 February 2022 (UTC)[reply]
  Comment: Similar script to the one linked in the description available at de:Benutzer:Schnark/js/letzteredit (multilingual). ~~~~
User:1234qwer1234qwer4 (talk) 22:26, 7 February 2022 (UTC)[reply]

Voting

Add built in API to add buttons for editing gadgets

  • Problem: It's hard to add buttons for editing tools in a single, visible group.
  • Proposed solution: Basically want I want is a replacement for this toolbar library. It allows adding buttons but it is kind of hard to maintain especially when new editor is added/removed. Same with VE editor (code and non-code) -- don't really have a simple, unified API that would allow adding buttons to toolbars.
  • Who would benefit: Gadget creators and gadget users.
  • More comments: Also it is hard to add something else then an image. Like and image with text which would be less confusing then just an image. Or add a button with an input (the code adds the button to advanced section which kind of sucks and is said to be bad, but I see no other way).
  • Phabricator tickets:
  • Proposer: Nux (talk) 00:06, 12 January 2022 (UTC)[reply]

Discussion

  • @Nux: Could you say a bit more about the shortcomings with adding new buttons to the toolbar? The existing system for adding a button in a gadget (to the existing top-level 'insert' group) is something like this:
    		mw.hook( 'wikiEditor.toolbarReady' ).add( function ( $textarea ) {
			$textarea.wikiEditor( 'addToToolbar', {
				section: "main",
				group: "insert",
				tools: {
					strikethrough: {
						type: "button",
						label: "Strike-through",
						oouiIcon: "strikethrough"
					}
				}
			} );
		} );
    This seems reasonable, but I'm probably missing some context of your proposal.
    For the second part, would T286759 Allow arbitrary HTML for buttons solve for what you're trying to do? It certainly would be good to be able to add things other than icon-buttons (CommTech might even get to doing this quite soon as part of the Real Time Preview for Wikitext wish).
    — SWilson (WMF) (talk) 06:06, 12 January 2022 (UTC)[reply]
    That is just a bad API for me, at least for gadgets:
    1. A section is not added if its is missing.
    2. A group is not added if its is missing.
    3. The image must be a square.
    4. No way to provide a text beside the image or instead of the image (or at least none that I know of).
    Nux (talk) 19:49, 14 January 2022 (UTC)[reply]
  • Gadgets and user scripts are having some codes for this, and I think we don't need to add buttons. Thingofme (talk) 11:03, 13 January 2022 (UTC)[reply]
  • "don't really have a simple, unified API that would allow adding buttons to toolbars." I'll also note that part of this is because a lot of (requested) complexity has been added over the years. VE and the old editors are very different in design and capabilities. Wrapping a 'button' to work in multiple, much more advanced editors (which I think is what you want) is just not that easy to do and doesn't actually make it much easier to work with. —TheDJ (talk • contribs) 23:07, 13 January 2022 (UTC)[reply]
    Sure, I can understand it is not easy. That's why I would prefer not to do that 😉. We (at plwiki) always figured some way to do that. But lately there is this discussion about using API rather then hacking into classes or relaying on structure. I'm all for using APIs if they are good enough. In all of the editors you basically need: an icon, maybe text, a handler and a container for all that. Most of the time that should be enough.
    Adding stuff like "action: encapsulate" might be fun for doing something for yourself, but seems to simple for a gadget. At least I don't have any gadgets like that... Well I think I added one button like that on plwiki, but not as a gadget.
    BTW. Making an easier API for manipulation text and selection in an editor would be great, but that is another problem. Nux (talk) 20:07, 14 January 2022 (UTC)[reply]

Voting

Improvement to the AIV helper bot

  • Problem: Currently, the AIV helperbot (HBC AIV helperbot5) on enWiki only removes entries itself if the user gets blocked or if the entry is x amount of hours old (from what I've seen the number is usually around 4). Unfortunately, not all entries on AIV end up with the user blocked, sometimes the user simply gets warned or the user's edits are determined not to be vandalism, or the user stops editing before getting reported to AIV meaning the user isn't blocked because blocking is only used as a preventative measure and not as punishment. The issue comes when the user starts vandalizing again and the report hasn't been removed. Most admins will probably see that the user has been determined to no longer be an issue and the user is able to continue vandalizing. If someone re-reports the user and the previous entry for the user has not been removed, the bot will automatically combine them, making it harder for the user to properly be reported. There's also the issue of admins not checking the AIV regularly enough and some vandals being able to get away with their vandalism because their report became stale.
  • Who would benefit: Anyone who reports users to AIV and also admins who manage AIV.
  • Proposed solution: Add to the functionality of the bot by having the stale timer for each reported user only decrease if they aren't editing after X amount of time, and also having the bot remove any unactionable reports (i.e user being warned, edits not being vandalism) automatically after a bit and if the user vandalizes again, they can be reported again without the new report being merged into the older report that was determined to be unactionable.
  • More comments: I had discussed this before with Alexis Jazz here, however they told me doing so is not feasible for the time being since the creator of another one of the bots at AIV (Mdaniels bot) has health issues and wasn't the one who wrote the AIV function for the bot. If this isn't something that is able to be done let me know.
  • Phabricator tickets:
  • Proposer: Blaze Wolf (talk) 18:28, 10 January 2022 (UTC)[reply]

Discussion

Voting

Edit summary assistant

  • Problem: Regarding edit summaries, many edits do not include them, some editors do not leave them with their edits, and many summaries that are left are less helpful than is possible, often lacking links to supporting information, and being written in a wide range of varied styles.
  • Proposed solution: It would be useful to have means easily available while using edit windows, maybe via drop down menu, maybe from the "Edit summary" field, to help editors to leave helpful standardized edit summaries. Such a capacity could save time and improve quality. I have compiled a page of edit summaries which can provide an initial source of standardized summaries. That page is linked in my User page, in the section titled "Edit summaries". Feel free to copy anything on that page and edit it elsewhere in any way desired, but please do not edit that page. Thank you.
  • Who would benefit: All editors, even the most expert.
  • More comments:
  • Phabricator tickets:
  • Proposer: Jerryobject (talk) 09:55, 22 January 2022 (UTC)[reply]

Discussion

Convenience link to the page mentioned in the description: w:User:Jerryobject/Edit summaries.

I think it would be useful to have a few standardised edit summaries available, translated into different languages. I only speak English but there's quite a lot of small maintenance tasks on other wikis that are actually easy to perform without much knowledge of a language (other than wikitext). However what always puts me off is not knowing what to put in the edit summary. the wub "?!" 16:48, 23 January 2022 (UTC)[reply]

This is w:Wikipedia:Canned edit summaries. It could be useful, but there are concerns it'd help facilitate vandalism, so it's necessary to tread cautiously. {{u|Sdkb}} talk 19:00, 28 January 2022 (UTC)[reply]
We actually have something like this on pl.wiki almost since forever :pl:MediaWiki:Gadget-edit-summaries.js. There aren't as many as on the above list. I'm not sure if such a long list could be done in a useful way. We have a short and pretty universal list with buttons divded into groups (about 30 buttons). You can see it in action as green buttons: example edit in Polish (buttons are only shown in Polish).
Note that users can add their own summary-buttons in their vector.js or common.js (just a simple function call). The script kind of works in VE even, layout is not perfect, but it mostly works. Nux (talk) 13:05, 30 January 2022 (UTC)[reply]
Many projects have a variation of this, but standardising them into a single tool (not necessarily enabled by default) seems helpful. ~~~~
User:1234qwer1234qwer4 (talk) 22:22, 7 February 2022 (UTC)[reply]
Predictive typing may be nicest solution: a drop-down takes 1 click,which requires additional user attention, but getting the right item by typing a couple first characters may make it super-fast (or at least faster than typing out or clicking around). It could a drop-down that filters itself as you type. Cryout (talk) 14:55, 11 February 2022 (UTC)[reply]

Voting

Add data namespace support to ListeriaBot or fix TabulistBot

  • Problem: Generate datasets from SPARQL-queries which can be shared between wikimedia wikis
  • Proposed solution: Add Wikimedia Commons data namespace support to ListeriaBot or fix TabulistBot
  • Who would benefit: All wikimedia wikis
  • More comments: Wikimedia wikis should have some useful way to generate data files that could be shared between multiple wikis. For example list of populations or locations. With federated SPARQL-queries data sources could be wider than just Wikidata. Also when the results are stored in pre-generated JSON files which are used in wiki pages it is not a problem if the query phase is slow.
  • Phabricator tickets:
  • Proposer: Zache (talk) 14:59, 22 January 2022 (UTC)[reply]

Discussion

Voting

  • Problem: There are so many uploads on Wikimedia Commons that are copyright violations. Some of them are snapshots of some computer screen or some other image like a poster. I estimate that about 3-6% of all files on Commons (most of them probably images) are copyright violations. I already had some files around the time when Commons started that were copyright violations and nobody ever noticed.
  • Proposed solution: A bot or tool that checks uploaded files and flags them if they are potentially copyright violations
  • Who would benefit: Wikimedia Commons as such as well as admins
  • More comments:
  • Phabricator tickets: phab:T120453
  • Proposer: --D-Kuru (talk) 14:00, 18 January 2022 (UTC)[reply]

Discussion

In my opinion copyright violations share one or more of these features:

  • EXIF data: Copyvios usually do not have EXIF info. Not said that they can not include them.
  • Size: Copyvios are usually small in size (usually websize like around 800 px for the long length). Not said that they can't be larger.
  • Account edits: Copyvios are often uploaded by what I call hit and run accounts. So the account is created, uploads one copyvio and is never to be used ever again.
  • Can be found in the web: Copyvios can often be found on other websites. Not said that they can not be freely shared by other people on sites like flickr.
  • Author: No matter how impossible it is, the file is tagged with "own work" and the upload as the author name
  • Percentage of useruploads: When a hit and run account uploads three images and two of them are speedy deleted because of copyright violation, the third one should may be checked.
  • Content: Copyvios usually look better than the average image on Wikimedia Commons. All other parts are probably possible to check rather easy. But this one would need a highly specialised AI that can tell good from bad quality. For a project like Wikimedia I guess this is next to impossible if nobody like Google steps in to help out.

There are also hints that indicate a file is a legit one: GPS data (not possible for every file), upload by a user with many edits over many years, user who has a global account with more profiles on different projects, etc.

My suggestion is NOT to have a bot run wild and delete files it deems as copyvios, but to have a bot that assigns a (public?) score to an image and checks how likely it is that some file could be a potential copyvio so that less of them slipp by.

I thought about creating something like a Trusted Author who has to meets certain criteria to ensure that people can use uploads by this user. There is a tiny story behind this: I was asked by somebody via Mail if they can use my image in a school book and what they would have to do to use it. I said of course and told them all they would have to do is to credit me and the licence. They ended up not using my image (even I own the copyright and have it licenced under a free licence) because they can't be sure for 100% and they could potentially get into legal troubles if they use the image without having a real permission. This might not be a big deal for a website, but can be a huge deal for a (school) book that is printed and sold over many years. --D-Kuru (talk) 20:21, 20 January 2022 (UTC)[reply]

  • @D-Kuru: This is a valid proposal, but it's a bit wordy. phab:T120453 is basically what you're asking for (a bot to flag Commons uploads that are possible copyvios). Is that correct? If so, with your permission, may I simplify the wording of your proposal? It will eventually be marked for translation, so putting in fewer words will make it easier on the translators. For instance, the symptoms you mention in "More comments" such as looking at EXIF data, size, etc., are helpful but not really necessary to understanding the wish. We could move that here to the discussion section. Thanks, MusikAnimal (WMF) (talk) 19:06, 20 January 2022 (UTC)[reply]
@MusikAnimal (WMF): I did not have the time to check the ticket, but from your description this sounds about right. I moved the More comments section as suggested. --D-Kuru (talk) 20:21, 20 January 2022 (UTC)[reply]
Ok thanks. I have done some slight rewording of your proposal for better translatability, which I hope is okay :) Best, MusikAnimal (WMF) (talk) 22:07, 20 January 2022 (UTC)[reply]
This had a lot of support, so I have made a bot solution that can be expanded that should fulfil some of the needs of this wishlist. You can read the bot request here: https://commons.wikimedia.org/wiki/Commons:Bots/Requests/CommCheck Ed6767 (talk) 19:21, 9 February 2022 (UTC)[reply]

I wonder if calculating hashes on uploaded files could help... there's not likely a database we could bump against, but we could probably track hashes of uploaded files over time, and if a file with the same hash is uploaded again, that could be one factor into such a score. Alternatively, it could help indicate if the file exists already, under a different name? = paul2520 (talk) 19:37, 5 February 2022 (UTC)[reply]

I would suggest on upload always use the "This file is not my own work." -upload form. If it is own work, they should declare that they are the author. Many people just use the simpler form, which leads to copyvio. If they declare author and source it is easier to detect copyvios, than images wrongly taged as own work.  — Johannes Kalliauer - Talk | Contributions 18:41, 16 February 2022 (UTC)[reply]

Voting

Readability scores gadget

  • Problem: Many of our articles are (accidentally) written for an academic audience, leaving behind our average reader (see for instance this journal).
  • Proposed solution: Made a gadget that can show (various) readability scores of article(s), and paragraphs within. Most readability scores like the Flesch reading ease score are based on word and sentence length. Others like Dale-Chall readability formula are based on how familiar (or common) the used words are. I think it is good to have at least one of both categories. The weighting of these tests typically varies by language, so maybe it would only be feasible to do this for the biggest 10-20 languages. Smaller wikis that translate would benefit indirectly.

    Available tools are often insufficient. Readability of Wikipedia is English-only, and quite buggy. Copy-pasting it to websites like Hemingway is time-consuming as citations need to be manually removed.

  • Who would benefit: Readers with an average education level. On simplewiki, English-language learners and younger readers.
  • More comments: Add some basic statistics about article/section/paragraph being translated is a similar proposal focused on translated text.
  • Phabricator tickets:
  • Proposer: Femke (talk) 20:08, 20 January 2022 (UTC)[reply]

Discussion

Yes "Readability of Wikipedia" does not seem to tell you what is hard to read. And it sometimes comes up with the confusing "Some errors were detected in the mark-up of the Wikipedia article, which could affect the Flesch score" even for featured articles, which seems unlikely. There does not seem to be a way to report bugs. If it is no longer being maintained maybe the creators would give it to us for someone to improve and integrate in as a tool? Chidgk1 (talk) 13:14, 26 January 2022 (UTC)[reply]

Voting

Improve Mix'n'Match performance

  • Problem: Mix'n'match has poor performance, even when searching in only one catalog. Descriptions often fail to load.
  • Proposed solution: Give the tool better hardware and/or rewrite code to improve performance.
  • Who would benefit: Any Mix'n'match user
  • More comments:
  • Phabricator tickets:
  • Proposer: Bargioni (talk) 09:36, 15 January 2022 (UTC)[reply]

Discussion

Voting

Get Twitter ID

  • Problem:
     
    Flagged Suggestion In Wikidata
    There is constraint/suggestion against "Twitter username" asking for the "Twitter user numeric ID" and "start time", but if it's not easy, people don't often do it
  • Proposed solution: Have a bot that crawls for missing "Twitter user numeric ID" and "start time" then using data from the Twitter API fills them in
  • Who would benefit: With Twitter currently such a ubiquitous identifier of people and things, using fixed numeric id (rather than the changable text name) improves quality
  • More comments:
  • Phabricator tickets:
  • Proposer: Back ache (talk) 10:19, 21 January 2022 (UTC)[reply]

Discussion

Voting

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