Wikimedia Meta-Wiki

Community Wishlist Survey 2017/Bots and gadgets

< Community Wishlist Survey 2017
Community Wishlist Survey 2017
Bots and gadgets
10 proposals, 231 contributors



Deploy Article Alerts to other languages

  • 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 also 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. (Edit: See en:Wikipedia:Article alerts/Roadmap for a tentative roadmap.)
  • More comments:
  • Phabricator tickets:

DiscussionEdit

  • 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)Reply[reply]
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)Reply[reply]
Not even all larger Wikipedias use WikiProjects, though. It's not only a size thing, but also history (how have we organized) and editing culture. It's probably good for editors to be keenly aware of the fact that if they don't have WikiProjects, the infrastructure for something like this isn't there on their home wiki, and it won't work for them. /Julle (talk) 12:29, 4 December 2017 (UTC)Reply[reply]
@Julle: To a point. You don't have to be organized by Wikiproject, you can be organized by categories for instance, or organize via any other grouping of topics. For instance, you could have alerts based on the transclusion of an infobox, such as en:Template:Infobox biography. So even if you don't have a Wikiproject structure in your own wiki, there are still ways this could be used. That's part of what the proposal is. Have the WMF take over, and have a team that's dedicated to making it work for the specific needs of other (non-en:wiki) Wikipedias. Headbomb (talk) 20:20, 4 December 2017 (UTC)Reply[reply]
  • 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 meReply[reply]
  • I would love WMF to make this as a wiki-compatible configurable tool (at least to English WP for start) rather than an external bot. The benefits are too numerous for me to list, but multiple languages is certainly one of them. This would be much too big of a project for me to do to convert it into an extension or tool labs bot or something of the sort. It's been quite a few years since coding AAB and real life certainly means that one volunteer coder for the project is unfeasible for any serious expansion into other languages or complex workflows and on-wiki features. The code is also pretty atrocious and team-unfriendly now that I can look at it with some 10 years of experience. It was more of a "wow, this sounds like a cool bot I can code" rather than a plan for a community-driven open source tool. The things that would be different/new/incompatible for a tool that directly works with database and/or MediaWiki is again too numerous to list. I can fix and keep the bot running when issues occur, but getting to new features and even bugs is a hurdle that could be abruptly terminated by a bus. —  HELLKNOWZ  ▎TALK  ▎enWiki 23:26, 1 December 2017 (UTC)Reply[reply]
  • Don’t underestimate yourself User: Hellknowz (and you too User:Headbomb). The code you wrote ten years ago may not be up to your standards of today, but it is robust and has served Wikipedia’s community well. I worry that the code the WMF staff replaces it with will be inferior in terms of features.
Also I wanted to add a comment about statistics, which are not harvested and put to good use. For example, Alerts of AFD discussions show the number of participants in each deletion discussion when they are displayed on the project(s) page(s). However, no one is capturing this information for statistical purposes as far as I know. Wouldn’t it be nce to know how many articles are deleted overall based on the votes/consensus of one or two people? Ottawahitech (talk) 19:39, 2 December 2017 (UTC) Please ping me Reply[reply]
@Ottawahitech: The bot has served the community well, we're well aware of that. I gave a restropective at Wikimania this summer, where WMF devs expressed interest in taking over [assuming it's endorsed on the community survey]. To be frank, the code's status has gotten to a point that whatever new feature we wanted to have, we can't have either because it would blow up the whole bot because of en:spaghetti code, or take too much of Hellknowz' time to implement. Very little has been done on en:WP:AALERTS in over two years. WMF taking over would mean much better integration (e.g. possibly even integrate this with en:WP:Notifications), have much better/reliable performance [we need manual restarts on our personal machines if the bot crashes, if we're busy, that can take a few days before we get to it], and allow other languages to benefit from it. It might have less features at first, but over time they would likely do more, and do it better. Headbomb (talk) 19:51, 2 December 2017 (UTC)Reply[reply]

VotingEdit

Wikidata reference "stated in" from url bot

  • 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:

DiscussionEdit

  • 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)Reply[reply]
I don't know enough about bot development to do it. --LauraHale (talk) 10:49, 9 November 2017 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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

Maybe the property P248 "stated in". --X:: black ::X (talk) 14:08, 5 December 2017 (UTC)Reply[reply]
  • I don't understand, whether this question concerns about taxon boxes, i.e. why WikiData is filling automatically empty places there. It Should not. --Höyhens (talk) 12:57, 6 December 2017 (UTC)Reply[reply]

VotingEdit

Make adding "Wikipedia in the News" easier

  • 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:

DiscussionEdit

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)Reply[reply]
  • Clarification The votes are trending negative and I don't understand the reasons given (or "reason" since they all cite the same reason). To clarify, a tool (website) is used to enter the "In the News" data into Wikidata, where a bot then automatically distributes the data. For example on Enwiki, it would automatically create the WP:Press coverage master list, and article talk pages with Template:Press. Other project languages might have different methods, but same scenario, a bot would automatically create whatever pages or templates they use, drawing from the centrally located "In the News" database which anyone from any language can update. -- GreenC (talk) 22:14, 2 December 2017 (UTC)Reply[reply]
    • I don’t know any reason to store this data in Wikidata. It can be stored on the page where it’s currently stored (w:WP:PRESS), and a bot can distribute it without any fancy tool. This bot can be written by an enwiki bot owner for enwiki. I, as a Hungarian speaker, am not interested in Catalan-language news about Wikipedia, it makes no sense to maintain it internationally. –Tacsipacsi (talk) 09:32, 3 December 2017 (UTC)Reply[reply]

VotingEdit

  •   Support --Liuxinyu970226 (talk) 12:58, 28 November 2017 (UTC)Reply[reply]
  •   Support Thomas Obermair 4 (talk) 21:40, 28 November 2017 (UTC)Reply[reply]
  •   Oppose It's just a problem for wp:en. Wp:en can resolve it itself. --Nouill (talk) 00:27, 29 November 2017 (UTC)Reply[reply]
  •   Oppose per Nouill. NMaia (talk) 13:04, 29 November 2017 (UTC)Reply[reply]
  •   Support As someone who frequently manually updates the page, I strongly support a simpler way to add items to the list. I also support moving the list to Meta-Wiki in order to encompass press coverage from all Wikimedia projects. Daylen (talk) 01:21, 30 November 2017 (UTC)Reply[reply]
  •   Oppose per Nouill. --Superchilum(talk to me!) 16:17, 1 December 2017 (UTC)Reply[reply]
  •   Oppose per Nouill Aunva6 (talk) 16:21, 1 December 2017 (UTC)Reply[reply]
  •   Oppose per Nouill. -Theklan (talk) 18:32, 1 December 2017 (UTC)Reply[reply]
  •   Oppose per Nouill. --Terra ❤ (talk) 06:55, 2 December 2017 (UTC)Reply[reply]
  •   Oppose as a fancy tool. Talk pages can be edited by a bot based on the master list. —Tacsipacsi (talk) 18:57, 2 December 2017 (UTC)Reply[reply]
  •   Oppose I don't see this as a development priority. Kudpung (talk) 20:23, 6 December 2017 (UTC)Reply[reply]
  •   Weak oppose Involves only Wikipedia, Wikinews, and Wikidata. But this really is a problem. Mr. Guye (talk) 22:46, 7 December 2017 (UTC)Reply[reply]
  •   Support RandomDSdevel (talk) 01:17, 9 December 2017 (UTC)Reply[reply]
  •   Oppose, each wiki has its own workflow for press mentions. For example, Ukrainian Wikipedia uses a completely different system (uk:ВП:ППВ) which does not have this problem. In my view it is up to English Wikipedia to find which system to use for press mentions tracking — NickK (talk) 13:29, 11 December 2017 (UTC)Reply[reply]

Combined Desktop/Mobile/App-View for the Pageviews Analysis

  • Problem:

On of the most common questions when it comes to pageviews analysis is, to compare the percentages of the pageviews from different platforms (mobile, desktop, app). With the current tool this is quite complicated, since the tool is not able to display more than one platform at a time. Therefore a direct graphical comparison is impossible.

  • Who would benefit:

All Readers and Editors interested in pageview-statistics

  • Proposed solution:
  1. Create an additional view, where the bars of all the different platfoms are stacked in one diagram.
  2. Or convert the "platform"-selection menu from a singe select dropdown to multiselect radio buttons, so that it is possible to configure a customized diagram
  • More comments:
  1. I agree with the problem and the benefits of a solution. I'm just not sure that the proposed solution is the optimal one. I'm a newby and I have a newby perspective on everything. FWIW I have some experience in 'Application Portfolio Management' which undoubtedly influences my views. From my perspective, I feel that 'the movement' would be better served (now and in the future) by moving towards a much more consolidated, integrated set of apps (functionally, technically and in terms of user experience) rather than by maintaining/improving/expanding the current large collection of disparate individual gadgets/tools. The current gadgets and tools are difficult to find and use for newbies and are limited in scope and functionality. Today (after hours of searching) I discovered the Wikistats 2.0 Design project. The project currently has a prototype up and running for evaluation and will be released soon. It's the first version and improvements/extensions will surely follow. It seems to me that any solutions to limitations on pageviews/platforms would be better integrated with Wikistats 2.0 or follow-up versions. The benefits would be that Wikimedians have just one app for Analytics on any selection of pages/projects/countries/languages/audiences(editor/reader) and devices. I'm used to working with Google Analytics and I hope that something similar becomes available through Meta-Wiki Just my opinion. If this solution proposal is quick/cheap fix then it may be a worthwhile short-term solution. Otherwise, I think the effort would be better spent on a solution consolidated/integrated with other improvements to Analytics.

Mike Morrell49 (talk) 23:18, 29 November 2017 (UTC)Reply[reply]

  • Phabricator tickets:

DiscussionEdit

User:West.andrew.g does this for the top 5000 medical articles on a weekly bases.[1] And the overall top 5000 articles.[2] Doc James (talk · contribs · email) 01:54, 5 December 2017 (UTC)Reply[reply]

VotingEdit

Make Flow database accessible on Tools Labs

  • 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:

DiscussionEdit

VotingEdit

Turn UTCLiveClock into an extension

  • 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:

DiscussionEdit

  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
    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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
    • @Tgr (WMF): Actually, I only care about the clock part (which I use a lot). I don't even want purging ability. I don't think setting the time zone is needed. I just need UTC time so that I can tell when various on-wiki actions occurred. Kaldari (talk) 18:19, 20 November 2017 (UTC)Reply[reply]
  • 1) The visible layout change after page-load was fixed on mediawiki.org. 2) Creating an extension seems overkill for this feature, especially because it seems to bypass the existing project for "Global gadgets" which would solve this. This could become one of the first gadgets to be ported to WikimediaGadgets.git. 3) It is indeed safe to assume the current Gadgets system will not support "Global Preferences" because they are per-wiki (similarly named gadgets could be different things on different wikis). However, it is also safe to assume that this restriction does not apply to global gadgets. As such, if this gadget were a global gadget, it would be trivial to add its preference to the list of global preferences. --Krinkle (talk) 04:33, 21 November 2017 (UTC)Reply[reply]

VotingEdit

Convert AWB into a special page

  • Problem:
    • Malfunctions
    • No translations
    • Need to download program and install continuous updates
  • Which users are affected?
  • Who would benefit:
    • All program users (including administrators)
  • Proposed solution:
  • More comments:

DiscussionEdit

  • @Magioladitis, Reedy, and Rjwilmsi: FYI this proposal. Please help improve the proposal if you can, or give other input on the difficulties that might be involved. Thanks! Quiddity (WMF) (talk) 23:04, 13 November 2017 (UTC)Reply[reply]
  • This sounds good, but I worry we don't have enough resources to complete this *rewrite*.--YFdyh000 (talk) 10:17, 28 November 2017 (UTC)Reply[reply]
  • I am concerned that this is such a backwater discussion page that very few people who use the program even know of its existence. The voting should reflect the community. The handful of people who have logged in votes here are not representative of the AWB using community. Also, the proposal is so vague as to be almost incomprehensible. Who will be allowed to use it? And who will be making that determination? On Wikipedia, the Wikipedia community decided the restrictions. Will those restrictions still be honored, and how? The Transhumanist (talk) 00:41, 2 December 2017 (UTC)Reply[reply]
  • I think en:WP:JWB already takes care of whatever this proposal is supposed to be. Headbomb (talk) 04:03, 3 December 2017 (UTC)Reply[reply]
  • It sounds like not everyone will have access to it. It also sounds like it will be starting over, with fewer features. If it will have the same access restrictions as we currently have (anyone with 500 main namespace edits can use it), and will start out with all the same features as the current version of AWB, I would support. Otherwise, it will be a major step backwards. The Transhumanist (talk) 23:27, 1 December 2017 (UTC)Reply[reply]
  •   Question: I'm unclear on the permissions here... Right now anyone can use AWB. Would that change? --Zackmann08 (talk) 02:25, 2 December 2017 (UTC)Reply[reply]

VotingEdit

  •   Oppose Sounds bad, it's better to make it as a Portable application than either download-install or on-wiki application. --Liuxinyu970226 (talk) 12:52, 28 November 2017 (UTC)Reply[reply]
  •   Support Thomas Obermair 4 (talk) 21:38, 28 November 2017 (UTC)Reply[reply]
  •   Support Xaris333 (talk) 19:22, 29 November 2017 (UTC)Reply[reply]
  •   Support Luan (discussão) 20:03, 29 November 2017 (UTC)Reply[reply]
  •   Support I like this idea, would make page maintenance easier. Reception123 (talk) 19:30, 30 November 2017 (UTC)Reply[reply]
  •   Support Syced (talk) 15:41, 1 December 2017 (UTC)Reply[reply]
  •   Support --Superchilum(talk to me!) 16:18, 1 December 2017 (UTC)Reply[reply]
  •   Support Honischboy (talk) 21:31, 1 December 2017 (UTC)Reply[reply]
  • I do not understand the proposal as written (perhaps someone with native English-language skills could clarify the description for us), but it sounds like the proposal is to convert AWB from a downloadable program (for Windows only) to a web-based interface of some sort. If that is the case, I   Support the proposal. As a Mac OS user, I have been unable to use AWB, which would enhance my gnome editing significantly. Jonesey95 (talk) 23:37, 1 December 2017 (UTC)Reply[reply]
  •   Weak support I like the idea but I think this proposal needs to be better explained. --Zackmann08 (talk) 19:57, 2 December 2017 (UTC)Reply[reply]
  •   Support in theory, subject to being able to restrict access to those with a user right. This proposal really needs more detail before anyone can make an informed decision, though. ~ Rob13Talk 03:15, 2 December 2017 (UTC)Reply[reply]
  •   Oppose What? This proposal is hard to understand. Are you trying to turn the AWB program in to a webpage? Do you plan on it running server side? What about people that use it on non-WMF wikis? Is this a "FORK AWB" proposal? — xaosflux Talk 04:44, 2 December 2017 (UTC)Reply[reply]
    Also, who will maintain this? (WMF? Volunteers?) — xaosflux Talk 04:47, 2 December 2017 (UTC)Reply[reply]
  •   Oppose per Liuxinyu and Xaosflux. --Terra ❤ (talk) 06:53, 2 December 2017 (UTC)Reply[reply]
  •   Oppose as unclear. I'm concerned that the "database scanner" may disappear; I use it with regexes that are far too complex for the MediaWiki search box. I'm concerned that I may lose the ability to configure find+replace rules in a text file; my rules are up to 2.5 megabytes and are sometimes edited with Notepad. -- John of Reading (talk) 08:04, 2 December 2017 (UTC)Reply[reply]
  •   Oppose is the proposal trying to make AWB an online tool like twinkle? Simply put: I dont think it would work reliably. Also per TerraCodes, and John of Reading. —usernamekiran(talk) 11:39, 2 December 2017 (UTC)Reply[reply]
  •   Oppose, improve the existing tool instead. Currently it’s absolutely possible to internationalize and localize C# programs, and even to run them on *nix systems like macOS and Debian GNU/Linux. —Tacsipacsi (talk) 18:27, 2 December 2017 (UTC)Reply[reply]
  •   Oppose - If this is proposing to change AWB into a page then I can't see how it's going to work and as Xaosflux says who's going to run it and keep tabs on it ?, If I have read this right then I don't the point in changing it all at all ..... if I've read it wrong and it's Twinkle or something else related then you've lost me ..... –Davey2010Talk 15:44, 4 December 2017 (UTC)Reply[reply]
  •   Oppose - the proposal is too vague. Having fun! Cheers! Checkingfax (talk) 20:27, 4 December 2017 (UTC)Reply[reply]
  •   Support AWB is hard to get started on, and making the onramps a little nicer would help. NessieVL (talk) 18:34, 5 December 2017 (UTC)Reply[reply]
  •   Oppose For all of its esoteric and arcane controls and processes and its supposed faults and steep learning curve, AWB is valuable tool. The proposal appears to be based on the assumption that turning it into a special page will somehow remove its problems. There's no reason to suppose that such a translation would deliver the expected benefits. More probably, it would result in a neutered tool with a reduced feature-set.--DavidCane (talk) 21:44, 5 December 2017 (UTC)Reply[reply]
  •   Weak support as this is egalitarian, but the proposal is vague. Mr. Guye (talk) 22:33, 7 December 2017 (UTC)Reply[reply]
  •   Oppose per John of Reading and Xaosflux Ronhjones (talk) 16:27, 8 December 2017 (UTC)Reply[reply]
  •   Support This sounds like a wonderful idea! It's always good to see software go cross-platform! RandomDSdevel (talk) 01:07, 9 December 2017 (UTC)Reply[reply]
  •   Oppose Per xaosflux SQLQuery me! 04:41, 9 December 2017 (UTC)Reply[reply]
  •   Support Haxpett (talk) 23:42, 10 December 2017 (UTC)Reply[reply]
  • Strong   Oppose - AWB give us Modulity. We can add plugin and and can make module according to our requrement. But Wikimedia will allow anyone to upload .dll file into their Server (For Secuirt Resons). And This will destory AWB wide uses. Hence I am oppsing this. And Other thing which is "Same Faciltiy is given by JWB. But you can see major Diff between Both". Thanks-Jayprakash >>> Talk 06:27, 17 December 2017 (UTC)Reply[reply]

Fix search in AWB

  • 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:

DiscussionEdit

insource: does work in AutoWikiBrowser. It used to not work, but version 5.9.0.0 already supports it (and maybe some earlier versions too). —Tacsipacsi (talk) 18:50, 2 December 2017 (UTC)Reply[reply]

Why has this proposal not been retracted yet? --bdijkstra (talk) 19:38, 8 December 2017 (UTC)Reply[reply]

VotingEdit

Keep maintenance categories and links up to date

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

DiscussionEdit

  • In theory that sounds like a great idea, 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)Reply[reply]
    • The proposal is for the back-end software (MediaWiki itself, or a job queue, or something similar) to null-edit pages that are stale. The proposal, if implemented, would shorten category update times, not lengthen them. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)Reply[reply]
  • 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)Reply[reply]
    • The proposal is for the back-end software to null-edit pages that are stale. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)Reply[reply]
  • 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)Reply[reply]
    • I think the issue with c:Category:Non-empty disambiguation categories is that {{PAGESINCAT:... is not considered a dynamic parser function (like e.g. {{CURRENTDAY}}) which would cause the pages to be reparsed regularly. We also don't keep track of links for pagesincat, so we can't purge when someone adds something to a category via job queue. Given this is using {{PAGESINCAT:... for the current category, we probably wouldn't even need to keep track of links, only if the current page is checking how many cats are in itself, so we could probably fix that much easier than purging all pages. BWolff (WMF) (talk) 22:23, 28 November 2017 (UTC)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • 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)Reply[reply]
  • I'm doubtful how practical this is for all pages on large wikis. I have no idea how long such a reparse would take. It wouldn't surprise me if we're talking months to run through all pages. Maybe even years. BWolff (WMF) (talk) 22:23, 28 November 2017 (UTC)Reply[reply]
    • The first step in implementing this proposal would be to investigate a few different methods for doing this refresh and assessing their practicality. The status quo is that some pages never get updated, so even "years" would be an improvement, but I think we can get it down into the "months" or even "weeks" range with some clever work. Jonesey95 (talk) 23:48, 1 December 2017 (UTC)Reply[reply]

VotingEdit

Commons deletion notification bot

  • 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:

DiscussionEdit

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

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

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

phab:T91192 may be an alternative. Jo-Jo Eumerus (talk, contributions) 10:10, 26 November 2017 (UTC)Reply[reply]

For article Alerts, as they currently exist, you'll have to talk to en:User:Hellknowz and make a Features Request for Article Alerts. However, see this Article alerts-related proposal. A dedicated bot putting notices on talk pages could be handled at en:WP:BOTREQ. Headbomb (talk) 04:38, 29 November 2017 (UTC)Reply[reply]

I made the proposal on Wikiversity, which was a response to a problem: Users trust Commons content, use it, and years later someone finds (or imagines) a copyright problem and the Commons file is deleted, then Commons Delinker comes and removes the link. At that point, all the file information from Commons is now deleted. (Really, that information should never be deleted even if the image itself is removed). The original user may be long gone. So content is damaged and fixing it can be time-consuming, creating a possibly unnecessary maintenance cost). We could go to Commons and ask an admin for a copy of the file, but that's cumbersome and not actually legal, if the copyright failure was real. However, if the file is hosted on Commons, there is no doubt that we can legally copy it to Wikiversity. We just don't do it because it seems unnecessary. Later, if the file is deleted from Commons, our own copy could be tagged, if appropriate, for fair use (or deleted if fair use is not appropriate, whatever it takes to satisfy the EDP requirements -- but Wikiversity tends to have liberal fair use practice.) So the proposal was to copy all WV-used Commons content to Wikiversity, by local bot. However, if Commons would notify Wikiversity of pending deletions, for all files used on Wikiversity, we wouldn't need that dual hosting. The NonFreeWiki proposal would be far more efficient if it were simply a filespace on Commons, where used files were moved. That's basically a no-cost solution. --Abd (talk) 14:48, 1 December 2017 (UTC)Reply[reply]

VotingEdit