Community Wishlist Survey 2019/Bots and gadgets

From Meta, a Wikimedia project coordination wiki
Bots and gadgets
10 proposals, 218 contributors, 330 support votes
The survey has closed. Thanks for your participation :)

Create HotCat-like functionality for stub templates

  • Problem: Stub editing can be a very repetitive process
  • Who would benefit: Anyone who patrols and categorizes stubs
  • Proposed solution: Extend HotCat functionality to allow for adding stub templates or more specific stub templates
  • More comments: I've been using a nice script located here, but the tool is (understandably) not as slick as HotCat. It would be of great help if HotCat could be extended to easily add and remove stub templates. I already made a request for this on the HotCat talk page.
  • Phabricator tickets:
  • Proposer: Furicorn (talk) 11:10, 6 November 2018 (UTC)[reply]



User Script to Guide Students

  • Problem: Students struggle with the same issues class after class. Often it is simple stuff:
    • They place references before punctuation
    • They use a LOT of capital letters in headings
    • They link to the inside net of their university library (1,300 instance yet to be cleaned up) -> we have an abuse filter that now stops these
    • They use books but do not provide page numbers
  • Who would benefit: Those involved with educational efforts on Wikipedia.
  • Proposed solution: Build a user script that those involved with teaching classes can opt to install on their students accounts. When the student hits "Publish page" the script will analyse their edit for basic concerns and provide direct feedback for the issues it finds. The student will than have the chance to make the correction and hit save again or hit ignore and publish anyway. If no issues are detected than the edit will publish normally. Each issue to be analysed should be a module within the tool so that projects and languages can easily customize for the issues they most commonly deal with.
  • More comments:
  • Phabricator tickets: [1] (a first draft)


How can this be made more versatile to allow {{sisterprojects}} (and sister languages) to develop similar wizards for their article creations? Gryllida 22:17, 30 October 2018 (UTC)[reply]

You build it out of modules. People than select which modules they want in the version of the script they wish to activate. In Japanese the punctuation goes after the reference for example so they would have a module that would request people to do the opposite. Modules would also be potentially different for classes working on different topic areas. Doc James (talk · contribs · email) 01:31, 31 October 2018 (UTC)[reply]
Doc James are you a JavaScript programmer or do you know of any? Help:Dialog may suit the need, it is rather modular. Gryllida 05:22, 31 October 2018 (UTC)[reply]
Nope not a programmer. Doc James (talk · contribs · email) 05:26, 31 October 2018 (UTC)[reply]
Hi Doc James. This is an interesting idea and I can see it being useful. Thanks for proposing it. I have a concern about the modules you mention above. Since different languages have different rules about punctuations and different wikis may have different rules about what text is allowed and what isn't etc - the only good way to make this work would be to allow people to define their modules and define what the module checks and how. We don't have a database of punctuation issues across languages - we're quite far from having anything like that. :) This then turns into a much bigger project because user scripts are not as flexible. Do you have ideas on how to go about this? -- NKohli (WMF) (talk) 02:21, 1 November 2018 (UTC)[reply]
Technically not really. The idea would be to start with a couple of functions and test them on a small group. And if useful expand from there. Doc James (talk · contribs · email) 04:50, 1 November 2018 (UTC)[reply]


Globalize some of Twinkle's functionality

  • Problem: enwiki Twinkle is really powerful tool, but it requires Javascript knowledge to port to other wikis (not talking about translating UI) - knowledge, that's not available in many small/medium projects (or devs, who doesn't have time for that), who would really want to use it.
  • Who would benefit: RC patrollers, powerusers
  • Proposed solution: Create a gadget with some basic(?) functionality, that is easily customizable.
  • More comments:
  • Phabricator tickets:
  • Proposer: Edgars2007 (talk) 17:23, 4 November 2018 (UTC)[reply]


It doesn't nessecarily does have to be called Twinkle, it can be a completely new product. Most wikis won't need all those very specific modules, that enwiki has. I would propose such "modules":

  • propose deletion of page - most wikis simply add {{delete}}-like template on the page. No daily subpages, PROD, speedy etc.
    • with option to add a notification on user's talk page
  • "last" module from enwiki, as is
  • "unlink" module
  • "restore and rollback" module
  • page tagging with maintenance templates
  • general deletion module.

Of course, details can be discussed. Edgars2007 (talk) 17:23, 4 November 2018 (UTC)[reply]

Hi Edgars2007, I tweaked the title of the proposal to clarify that you're asking for the basic functionality. Thanks for the proposal! -- DannyH (WMF) (talk) 18:15, 13 November 2018 (UTC)[reply]
  • Tools like Twinkle have been associated to the drop-off in editor retention in numbers of active editors since 2007. Does anyone have any estimates as to what this proposal might do to editor retention in smaller wikis? HLHJ (talk) 04:04, 14 November 2018 (UTC)[reply]
@HLHJ: To what are you referring? Has anyone argued that access to tools like this has a measurable effect on retention? Blue Rasberry (talk) 15:51, 17 November 2018 (UTC)[reply]
Yes, it's argued in Research:The Rise and Decline, which also discusses other possible reasons; if anyone has a more definitive discussion of the problem, please post. Graphs below.
These are all just the English Wikipedia. Graphs for all other languages are available; some show the same 2007-ish change in editor growth, others do not. I have not seen an analysis of these changes by the rate and nature of automated tool use on each of these wikis. MMiller (WMF), do you know of any? If this proposal is accepted, I would strongly suggest that the rollout be used as an experiment to better characterize the effects of Twinkle (and the way in which Twinkle is used) on editor retention. Twinkle provides a lot of useful abilities to editors, especially for fixing vandalism. But I think it would be a missed opportunity not to study its effects. We might learn ways to improve it.
By "improvement", I mean something like this excellent proposal for tagging fixable additions. Or adding a new-user flag when users are reverting a newbie so they can respond as they see fit (maybe by linking jargon and giving more encouragement in the message). Or a way to tag excellent edits and exemplary new editors as models for newbies. Or whatever editor-retention aids the Twinkle community wants to try; some readers will almost certainly have better ideas, and I hope they will post them on en:Wikipedia talk:Twinkle. HLHJ (talk) 19:51, 17 November 2018 (UTC)[reply]
@HLHJ: I'm sorry for the long delay on my response. The "Rise and Decline" paper that you linked to is the definitive source on how automated tools have impacted the experience of new editors, with the theory being that the impersonal bureaucratic experience that newcomers get from those tools makes it difficult for them to find their place in the wikis and learn comfortably. That said, I think it is quite possible for automated tools to be designed with care such that they retain a "human touch" and do not alienate newcomers. As you said above, perhaps this proposal could be an opportunity to try out different wording and functions that could lead to better outcomes. -- MMiller (WMF) (talk) 00:56, 29 November 2018 (UTC)[reply]


Improve the information returned on hovering links from the references section

  • Problem: When hovering over links from the references section that return to a citation's inline anchor, the text previewed is always a snippet from the article's lead, regardless of where the reference is anchored inline. It would be better if the snippet displayed text that the reference was inline to support instead.
  • Who would benefit: Both editors and readers would benefit from the increased functionality (when verifying an article's content) and Wikipedia would benefit, as well, as her stature, as a trusted tertiary source, began to increase.
  • Proposed solution: Instead of displaying a snippet of the article's lead, return a prescribed block of text immediately preceding the reference's inline anchor where the cursor returns.
  • More comments: I believe that this can be done without a great deal of technical difficulty.
  • Phabricator tickets: I am not aware of any such "Phabricator tickets".
  • Proposer:--John Cline (talk) 19:18, 30 October 2018 (UTC)[reply]


This is a pretty hard problem to solve, as the gadget Navigation Popups uses its own wikitext parser from 2005. it also has no idea how to parse from arbitrary starting points and the whole gadget is very hard to adapt as its very old code. oh and this is a gadget, so it is not available to ppl withou an account.—TheDJ (talkcontribs) 19:51, 30 October 2018 (UTC)[reply]

Thank you for sharing these important considerations. I need to disclaim any notions of technical prowess on my part — this is truly a wish from me, and not a suggestion.
Being lay, I did not mention a few things (for not knowing the lingo, or the ropes) but I do remember that our developers released an enhancement similar to pop-ups, but editors could only use one or the other, not both. Before wishing this, I did disable pop-ups, and evaluate the version developed in house. It would be that version where I hold my best hope of seeing it come to pass. I thought that I heard it called "reference tooltips", or "h-cards", but don't really know. Nevertheless, when hovering with pop-ups disabled, our software engine produces similar information when hovering from the inline anchor, but it produces no output from the reference side. I understand that pop-ups is difficult to maintain, but hope our in house team can do something with our version. If this is a technical impossibility, like trisecting angles with compass and straight edge, the proposal would best be withdrawn. I'll yield to the powers that be, to that end. Thank you again for your interest, and your reply.--John Cline (talk) 03:14, 31 October 2018 (UTC)[reply]


Make PopUps display diffs in green/red line by line

Original title: Dans l'historique d'un article, afficher TOUTES les vrais différences vert/rose ligne par ligne

  • Problem:
    English (translation): In the article history, the pop-up window which opens when the cursor touches “diff” only displays a small part of the differences in green/pink (except if the differences are very small) because of “truncated differences…” OR it displays entire paragraphs of text in pink strikethrough (cancelled) text, followed by same paragraphs, as edited in the new version, in green, without any way of knowing where the differences are located.

    French (original): Dans l'historique d'un article, la fenêtre pop-up qui s'ouvre au contact du curseur sur DIFF n'affiche qu"une petite partie des modifications vert/rose (sauf si les modifications sont peu nombreuses) pour cause de "différences tronquées..." OU met en rose barré (= annulé) des paragraphes entiers suivis des mêmes paragraphes en vert donc modifiés selon la nouvelle version, sans qu'on sache où ont porté les modifications.
  • Who would benefit:
    English (translation): Contributors who don’t have time to click on “diff” for each article among hundreds they monitor.

    French (original): Les contributeurs qui n'ont pas le temps de cliquer sur le DIFF des centaines d'articles qu'ils surveillent.
  • Proposed solution: ? (technical computer solution)(solution technique informatique)
  • More comments:
    English (translation): If this proposal is accepted and technically implemented, it would save contributors like me hours of time. Thank you in advance.

    French (original): Si cette proposition est acceptée et techniquement mise en place, cela ferait gagner des heures aux contributeurs comme moi. Merci d'avance.
  • Phabricator tickets:
  • Proposer: Mylenos (talk) 19:36, 5 November 2018 (UTC)[reply]


@Mylenos: Je ne sais pas si je comprends exactement comment on peut voir le probleme. Je vais a et mon curseur est sur "diff", mais il n'y a pas une fenêtre pop-up. Qu'est-ce que je dois faire? Merci d'avance! --AKlapper (WMF) (talk) 14:25, 6 November 2018 (UTC)[reply]

@Mylenos and AKlapper (WMF):, je suppose qu’il s’agit du gadget Navigation popups. Mylenos, le cas échéant, as-tu essayé de modifier le paramètre popupDiffMaxLines dans ton commons.js? —Pols12 (talk) 19:53, 8 November 2018 (UTC)[reply]
@AKlapper (WMF): It's asking for NavPopup diffs like this to be improved: (mouseover "← Previous edit" at...) test page, and screenshot. I don't know how complicated changing/replacing the diff parser would be, or if it's possible to change personal configuration for what the performance-truncation cutoff is (I couldn't see anything appropriate in w:en:WP:NAVPOP#Configuration (optional)). @TheDJ: quick thoughts? (is this applicable for wishlist voting?) Quiddity (WMF) (talk) 19:09, 9 November 2018 (UTC)[reply]

Merci Pols12 mais je ne sais pas ce qu'est un "commons.js" et ce qu'on peut y faire quand "Navigation popups/popupDiffMaxLines" a juste écrit : "100, an integer". Oui, ok, mais ça veut dire quoi ? il faut faire quoi ? - Mylenos (talk) 17:22, 23 October 2019 (UTC)

Perhaps, as in the mouseover for a link to an article, there should be a more…-button to replace the current display by the full difference. PJTraill (talk) 01:15, 27 November 2018 (UTC)[reply]


2FA available for all concerned editors

  • Problem: Available 2FA for all concerned editors. Everyone should have additional security on their account if they so desire. Why is it just limited to users with advanced permissions?
  • Who would benefit: Currently these user group's still vulnerable (Template editor,Mass message sender,Ipblock-exempt,Edit filter managers,Pending changes reviewer,rollbacker,autoreviewer,patroller). And all the concerned editors who dont like to be hacked.
  • Proposed solution: First, enable the "existing" 2 factor authentication for these user groups. Then make "Toolforge" enough capable so that it can provide "2fa" service for all editors.
  • More comments:
  • Phabricator tickets: phab:T166622
  • Proposer: Ahm masum (talk) 13:15, 8 November 2018 (UTC


@Ahm masum: Are you sure that phab:T100373 is the task about this proposal and not phab:T166622 instead? --AKlapper (WMF) (talk) 12:44, 9 November 2018 (UTC)[reply]

@AKlapper (WMF): OPP'S, MY BAD . THANKS.--Ahm masum (talk) 21:03, 9 November 2018 (UTC)[reply]
  • I support this wholeheartedly. I even duplicated it here before realizing this had been started. But, better security should be for everyone on Wiki, not just a selected few groups. 2FA should be available to everyone. DaneGeld (talk) 19:32, 10 November 2018 (UTC)[reply]
  • This needs better ways to revoke and reset credentials, and also being able to test the solution to see if the user fully understands how it work. No, it is not a real solution to email a reset link or to SMS additional codes, but it could be sufficient during a one-day or one-week training phase. — Jeblad 08:15, 18 November 2018 (UTC)[reply]
  • When my phone with authenticator on it died, I lost the ability to access my account. Will I agree all functionaires should use 2FA would need to check to see if there is resources to support all editors. Doc James (talk · contribs · email) 03:58, 20 November 2018 (UTC)[reply]
  • What Doc James said is the exact reason this has not happened yet: 2FA reset can currently only be done by developers, which does not scale. The problem is being worked on and 2FA for everyone who wants it is definitely the end goal. Until then, if you feel particularly unsafe, you can request membership in the oathauth-tester global group as a temporary workaround (example). --Tgr (talk) 22:30, 25 November 2018 (UTC)[reply]
Hi Tisza Gergő . I've seen your contribution at phabricator. Highly appreciate it. Please give me some info. What's the current status of phab:T195207  ; phab:T180896 & Special:DisableOATHForUser ? What's it actually mean? Does it mean we implemented a "Special page" but it wont work until some specific criteria is fulfilled (triage)? Am i missing something?
whats the most viable solution for these problems, you think?
How could we make & MAINTAIN a web interface in such a way so that the "reset process" can't take "wmf stuffs" valuable time?@Tgr:@AKlapper (WMF):@TheDJ: -- Ahm masum (talk) 10:53, 27 November 2018 (UTC)[reply]
@Ahm masum: the special page works but there is no limitation on its usage so only extremely highly trusted users can be given access to it (stewards, at best; maybe just staff). IMO that's not good enough for wide deployment and the page needs to be made less powerful (I'm not really involved in the decisionmaking about OATH though so that's just my personal opinion). But understandably people are more worried about making sure that the user who already can use 2FA actually do (since the hijacking of a privileged account is much much more problematic than the hijacking of a couple or even many non-privileged ones), so fixing the special page is lower priority. --Tgr (talk) 18:34, 27 November 2018 (UTC)[reply]
  • Anyone can already get 2FA access by asking on SRGP. We could make a separate page for requesting 2FA access if needed, maybe one that's simpler where you just add your username (or click a fancy js button that does it for you) and then stewards can assign based on that. The page could also include all the required reading and warning to save the scratch codes. – Ajraddatz (talk) 01:43, 26 November 2018 (UTC)[reply]
  • Just a heads up that SMS 2FA will not be implemented, it's been against best practices for years because it's very insecure [2], never mind having to deal with saving personal information such as peoples mobile phone numbers. Reedy (talk) 23:33, 6 December 2018 (UTC)[reply]
  • I understand , as a question of better security , "foundations" current focus is the "advanced user groups". Of course; the hijacking of a privileged account is much much more problematic than the hijacking of a couple or even many non-privileged ones. So here's some idea that i got (inspired from TheDJ) so that both parties could be happy & it won't cost WMF stuff's valuable time.

proposed solution for advanced user groups (just thoughts):

  1. In the "simple 2fa" make a option so that advance users can save their "Emergency tokens/scrath codes" in another location/device (it can be dropbox , lastpass or Keeper). As a additional security give them the ability to "make their own security question & answer's ". It could be stored in the same location. It'll only required when he'll make a "reset" request.
  2. Give them a web interface to request a reset . it could be a special page like "Special:ResetRequest" (SP:RR), similar to Special:DisableOATHForUser or it could be a "pop up" similar to those of fb/googles (as a part of mediawiki software). it could have a "dropdown menu" so that he can select his netive wiki & known admins. it could also have a "textbox area" where the user will write down something & try to prove his identity.
  3. Make that "interface/pop up" conditional , similar to those of fb/googles so that most of the hacker couldn't even make a request.

User needs to enter his name and password to initiate request.

    • Check if user knows his password
    • Check if verified email address and password were not changed recently (last 30 days?)
    • Check if user knows his correct "security answer".
    • Log if user was still logged in when making the request
    • Log if request was initiated from known device's,browser or ips.

After all these criteria is fulfilled , the request will be automatically posted in two different place's . one will be the village pump (his netiv wiki) & the other will be the META (Steward_requests/Permissions#Removal_of_access). only after the the local community confirmed his identity , the local admin will ping a steward & he'll made the decision (by executing Special:DisableOATHForUser).

Proposed solution for all the non privileged editors (just thoughts):

  1. Like all the other popular web entity's (Fb/G) , we could make a SMS based authentication as a "Optional Beta Features". Though it's not the most secure way but we must agree that it make the user feel more safer then before.
  2. Like all the other popular web entity's (Fb/G) , we could make a "Saved Device & Login Notification" feature as a "Optional Beta Features". when someone try to login from a unknown device user will get a login notification & SMS.
  3. We could make a cryptographic feature similar to Fb's "Encrypted notification emails" . as a "Optional Beta Features" it'll make the reset & notification email more secure even when the email is compromised. mediawiki could have a function to generate "OpenPGP Public Key" like the way "igolder" do & it could be saved in another location/device (it can be dropbox , lastpass or Keeper).

It's just some thought that i wanted to share. I have no expertise in these fields. please excuse my noviceness.THANKS --- Ahm masum (talk) 20:37, 29 November 2018 (UTC)[reply]

Most of the suggestions here have nothing to do with the actual wish as stated up top, but FWIW, SMS notification is T150902, and encrypted emails is T12453. --Tgr (talk) 07:04, 10 December 2018 (UTC)


You don't need to remember the numbers, your 2FA app will give you the numbers you need. --Terra  (talk) 15:32, 20 November 2018 (UTC)[reply]
No it doesn't require Ops. Reedy (talk) 23:31, 6 December 2018 (UTC)[reply]

Wikipedia in the News

  • Problem: Wikipedia Press coverage is currently tracked manually and haphazardly across individual language wikis, or not at all in many cases. For example on Enwiki, the news stories are first listed in one place (manually) then listed on the article talk pages (manually) and often not in sync or consistent formatting and limited to Enwiki.
  • Who would benefit: Anyone interested in knowing when Wikipedia is mentioned in the press. Such as for gathering statistics, making reports, academic studies.
  • Proposed solution: A central database and interface for listing notable mentions of Wikipedia in the Press, in any language. It would have an API so that bots and tools can access the data. An example bot application would be to update article talk pages that they were mentioned in the press (the bots would be language-specific and not part of this proposal). The database would have standard fields such as for a regular cite-web eg. "url", "title", "work", "language", "date", "author" etc.. a field for related Wikipedia articles, and a quote. The database interface would support multiple languages.
  • More comments:
  • Phabricator tickets:


  • @GreenC: I think this would be suitable for Wikidata, since items may qualify as notable if they are structurally useful (e.g. if they are used as sources). An item could be created for each source, and then the query service could be used to find articles about e.g. the Croatian Wikipedia, or WMF projects other than the Wikipedias. I'm not sure if that would be a good task for Community Tech, though, since the item creation could be done by a single user. Jc86035 (talk) 15:16, 30 October 2018 (UTC)[reply]
Yeah it might make sense to use Wikidata as a backend database, but what about a front-end page where users can enter the data and be landing point with instructions. -- GreenC (talk) 15:25, 30 October 2018 (UTC)[reply]
@GreenC: I don't really understand what this proposal is asking for. Would this be a database of Wikipedia articles about news stories or news stories about Wikipedia? On English Wikipedia, "In the News" is the former and "In the Media" is the later. Kaldari (talk) 04:40, 31 October 2018 (UTC)[reply]
Ahh yes that is confusing. I've updated it to be about Wikipedia press coverage. -- GreenC (talk) 05:03, 31 October 2018 (UTC)[reply]
@GreenC: I'm not sure if it would be useful to have a front-end page specifically for adding sources. Usually Wikidata items are imported in the QuickStatements format (Q12345|P31|Q5707594|P50|Q5568842), and I'm guessing it could be difficult for users not experienced with Wikidata to fill out something like this. Given that it's fairly likely that this proposal (or any given proposal) won't end up in the top 10, I think the easiest solution would be to have a wikitext table with columns for each Wikidata property, where users can add new articles, and then once in a while a Wikidata user comes along and imports the whole table into Wikidata. Jc86035 (talk) 05:46, 31 October 2018 (UTC)[reply]
That solution might work but it has problems with languages because a user who only speaks Bulgarian might have trouble editing a wikitable that is in English. If the suggestion is each wiki-language have its own table that is kind of what we already do and it's not very good and it would be very hard to co-ordinate across 300+ wikis to make them all consistent for import into Wikidata. The idea is a single universal front end for adding these sources into a database that can generate reports, export via API etc..
@GreenC: But then you would have to translate the front-end into all those languages? I think if you were to host the table on Wikidata itself it would largely take care of the translation problem, since the property template is already automatically translated based on the user's interface language (and the existing translations for each property's name). Most of the table itself probably wouldn't need translation (e.g. dates, URLs, authors' names, published in, relevant Wikimedia projects). You could also use d:User:ListeriaBot or something like that to auto-generate tables of relevant articles. Jc86035 (talk) 17:18, 31 October 2018 (UTC)[reply]
Ok your saying use Wikidata because of this, but don't use Wikidata because it's too complex for most users. I tend to agree Wikidata probably wouldn't be widely used if that was the main interface for adding links. Wikidata is basically a database level it has limits, it's fine to use Wikidata as a backend database. -- GreenC (talk) 21:03, 31 October 2018 (UTC)[reply]
IMHO there isn't really anything inherently wrong with setting up a whole database to store new data, although if Community Tech doesn't do it then someone else would have to write the code (you would probably have to set up a project on Tool Labs with an OAuth web interface), and then someone else would have to deal with monitoring it for junk and uploading the data to Wikidata every few weeks. An alternative would be extending one of the existing Wikidata user scripts (for filling in item data) to work for news articles, but generally Wikidata script UIs are designed with the expectation that the user knows exactly what they're doing so it would again have the learning curve issues and would probably result in input errors. Jc86035 (talk) 10:24, 1 November 2018 (UTC)[reply]
Agreed that would be part of it. -- GreenC (talk) 13:47, 31 October 2018 (UTC)[reply]


Microbot for mundane tasks

  • Problem: The problem is the time it takes to update the properties of a series of established articles that are linked by a specific property, e.g. an infobox property on the James Spence Medal article series and need to update to add additional that content.
  • Who would benefit: Anybody who would like to update a series of articles quickly with additional properties, without doing it manually, which is a real joy killer and completely unproductive, or having to go outwith Wikipedia to use it.
  • Proposed solution: A Microbot for Mundane Tasks, which can be quickly configured to select a series of articles, perhaps via a category, if available, or by manual selection, select the property that is needed updated and apply the property.
  • More comments:
  • Phabricator tickets:
  • Proposer: Scope creep (talk) 16:19, 5 November 2018 (UTC)[reply]


Manual update to article properties, e.g. adding an infoboxes property and value, or a category for articles in a series is extremly unproductive, slow and prone to mistakes. There is other methods to achieve the same result within WP, of course, the Bot process/and manufacture and AWB. Both have their limitations and specialisms. The Bot process/manufacture/release/test cycle is slow and bureaucratic, and is designed for large changes, across hundreds of articles. AWB can accomplish the same process, but is outside wikipedia, is also complex, and designed for very large scale updates in the thousands. Whereas the AWB work on the large scale, and bot framework works works on the mid to small, there is truly no small scale utility that update <50 articles at time, and that is an upper bound.

The whole point of the system is would be limited functionality. Ideally it would be quick to configure, to use and to check the work has been completed.

The ideal utility would have a collection of predefined scripts that would have to be approved upfront.

  • For example, adding the honorific tag to the James Spence Medal articles and interrogating each article in turn to determine if each one was Professor Sir, or Professor, or Sir, and adding to the infobox. Fundamentally a regexp search, then a write to the infobox to place the attribute with result. Tiny script.

Initial proposal. I intend to update several times over the next few days before closing. Scope creep (talk) 16:19, 5 November 2018 (UTC)[reply]

How is this different from AWB? MaxSem (WMF) (talk) 18:10, 5 November 2018 (UTC)[reply]
  • Stuff like awards is probably more waiting for Wikidata support of queries on the clients as well as perhaps better integration of bots between Wikidata and the other wikis. --Izno (talk) 02:31, 6 November 2018 (UTC)[reply]

Update again tomorrow.


Port Twinkle functionalities to mobile web page

  • Problem: Twinkle is a very nice tool that can be used for many convenient operations. However it cannot be used in the mobile web interface, users who would like to use Twinkle on their mobile device now would need to switch to "desktop view" which have small font size and is difficult to read. Hope that a mobile version Twinkle can be made in upcoming future.
  • Who would benefit:
  • Proposed solution:
  • More comments:
  • Phabricator tickets:
  • Proposer: -Jimmyshjj (talk) 13:22, 31 October 2018 (UTC)[reply]


  • Translated C933103 (talk) 18:26, 1 November 2018 (UTC)[reply]
  • @Jimmyshjj: Currently gadgets (such as Twinkle) are not supported on mobile (mainly because of the catch-22 that most gadgets aren't written with mobile support in mind). Thus it's unlikely that Twinkle itself will be made available in mobile. It's entirely possible, however, for the WMF to build something similar to Twinkle that would work in mobile (and hopefully not be limited to English Wikipedia). Twinkle does a million things though. Please specify which Twinkle functionalities you want the most so that those could be prioritized. Kaldari (talk) 17:47, 2 November 2018 (UTC)[reply]
    • Do I need to translate this question back to Chinese? C933103 (talk) 18:10, 5 November 2018 (UTC)[reply]
      • @C933103: Yes, please. Thanks! Kaldari (talk) 19:33, 5 November 2018 (UTC)[reply]
        • @Jimmyshjj:翻譯信息:現在Twinkle等小工具因為編寫時沒有考慮到流動版本支援,並且反之亦然,所以其本身現在並不支援而未來也不大可能支援流動版。但是可以做的是,另建一個可以在流動版上用的類似Twinkle的新工具。在這情況下,由於Twinkle本身有很多不同的功能,所以請指明你最想要用的Twinkle功能是什麼以便在實行時可以安排優先順序。翻譯由C933103 (talk) 21:01, 6 November 2018 (UTC)提供[reply]
        • @Kaldari:Thanks for responding.@C933103:(谢谢您的翻译,帮忙再翻译下,英语不好,谢谢)如果说优先顺序的话,那么提存废讨论,提报关注度,提报侵权,快删等除了在页面上挂相应模板外还必须在其他的相应进行编辑(中文维基是这样,英文维基应该差不多吧),需要经常切换,十分不方便,希望能先出(其实感觉twinkle的功能都很常用)。但如果有其他比较容易移植到移动版的功能能先出也是可以的。-Jimmyshjj (talk) 04:45, 7 November 2018 (UTC)[reply]
          • TL @Kaldari:: In term of priority, operations like submitting articles to deletion discussion/notability/copyright violation/speedy deletion that requires additional edits on top of putting templates onto relevant pages are rather inconvenient without Twinkle as editors would have to switch between different pages to complete the process, and thus it would be nice if they can be supported first. But if there are other functions that can be ported to mobile edition more easily then it's also okay to have them first. TL by C933103 (talk) 05:22, 7 November 2018 (UTC)[reply]
  • It would be very nice if Twinkle can be internationalized. However, doing that with the current code seems difficult to say the least. A complete overhaul of the code would be required to make twinkle in it's entirety workable for all wikis. Discussion on the topic can be found at issue 129 on github and T110148 at phabricator. As far as I can see, a kind of framework may be created allowing GUI based creation of Twinkle modules which offer separate functionality. The GUI could be along the lines of the current Twinkle Preferences panel, and would allow to edit/create javascript objects corresponding to Twinkle modules. The underlying code to do the actual work could be created and maintained centrally (at meta maybe?) and the module JSON objects could be wiki-specific or user-specific. Then for a wiki to migrate Twinkle would be as simple as importing the JSON object page from another wiki and edit it using the GUI to customize the module to their wiki's needs. A fresh project using conceptual elements from the current Twinkle would probably be easier than rewriting the current code.--Siddhartha Ghai (talk) 07:32, 4 November 2018 (UTC)[reply]

just remove mobile frontend altogether and use the mobile-friendly timeless skin. i believe it can run gadgets and has large font size, Jimmyshjj? --Gryllida 08:22, 23 November 2018 (UTC)[reply]

  • @Gryllida:I have tried the timeless skin(using Chrome browser on my android mobile phone), however, I found that the font size is really small(if it' necessary, I can upload the screenshot.). I don't think it is convenient to use it, for I need to zoom in or out from time to time. By the way, I'm sorry that I didn't reply immediately, cause I didn't get the mention, if it's necessary, please {{ping}} me, thank you very much.-LabMem No.SHJJ Contact Me 10:27, 24 November 2018 (UTC)[reply]


Machine readable diffs

  • Problem: Diffs cannot be read without screen scraping. Even the API output requires HTML parsing to get at the wikitext changes.
  • Who would benefit: Any semi-automated or fully automated consumer of diffs (e.g. bot operators, data scientists, tools, researchers).
  • Proposed solution: Exactly what it says on the tin. Add a different diff format to the API that JSON/XML parsers can understand.


I like this idea. Gryllida 22:17, 30 October 2018 (UTC)[reply]

  • Could you provide an example of how this API's output might look? MaxSem (WMF) (talk) 23:56, 30 October 2018 (UTC)[reply]
  • And examples of use cases where the lack of this format proved prohibitively expensive or blocking? —TheDJ (talkcontribs) 08:00, 31 October 2018 (UTC)[reply]
  • I note there are likely four parts to this request:
    1. Determine the "machine readable" format that will be used. Is there an existing standard that could be used, or do we have to invent something?
    2. Create a DiffFormatter subclass that generates that format.
    3. Update the wikidiff2 extension to be able to output structured diff data, either in a format that can be handled by DiffFormatter or in the "machine readable" format directly.
    4. Adjust exiting code to expose the structured output via the API.
    I note that third-party sites using $wgExternalDiffEngine will likely have to gracefully not support this feature. Anomie (talk) 15:54, 31 October 2018 (UTC)[reply]
    The problem I want to solve is that I want to perform analysis on the content added or removed. As for the output - I can work with something like this, although the text of the initial revision should also be returned for completeness. The refactoring required for this task will also knock out the technical debt preventing phab:T104072, phab:T117279 and phab:T38902 (moving MobileDiff into core, and making it available through the API) so there are more use cases than that given here. MER-C (talk) 19:39, 31 October 2018 (UTC)[reply]

  • On benefit: Yeah, various applications would need such an interface to inspect and analyse edits.
  • On output format:
    • JSON or XML or best both, when on workbench anyway.
    • The contents will be ruled by current wikidiff structure. Other systems would be possible, if collected information is not directly sent to output stream.
      • Simply an array of difference groups, each containing the same information as visible by two column output today.
      • Each group consisting of two objects, before and later.
      • Each object with line range, recently suggested: last detected headline, and Array of paragraphs.
      • Each paragraph with +/- state, and single line content, if any.
      • Each line content as an Array of tupels, each tupel of changed/unchanged flag and string (escaped according to output format).
    • The same as HTML today, just in different syntax according to JSON or XML.
    • The diff itself needs to be wrapped by some informative data:
      • Both revID involved.
      • Method/structure, currently constant wikidiff2 but may be subject to changes over decades.
      • The wikiID (can be derived from request URL, but for sake of completeness).
      • Other information, if present anyway, like pageID or nick or timestamp or page name, but these may be derived from revIDs later.
  • On special features:
    • An API request might provide control information, like number of paragraphs ahead and after, which are constant values for HTML special pages, but parameter values numContextLines already.
    • A research application might drop paragraphs around which are helpful for human readers to identfy the context.
  • On implementation efforts:
    • Unfortunately the 15 years old procedure does not create a complete diff object first, then starting output formatting.
      • Formatted output is collected immediately when each diff is found.
      • Otherwise the entire output object could be just thrown into a serializer for JSON or XML.
    • The two column output is formatted by TableDiff.cpp today.
      • Two copies of this need to be made, JsonDiff.cpp and XmlDiff.cpp.
      • Then appropriate atomic syntax is to be generated like HTML, with proper encoding of some " and < characters.
    • The stream needs to be wrapped into output head and termination, and usual administrative business.

Greetings --13:03, 4 November 2018 (UTC)PerfektesChaos (talk)

Note that the diff engine should not generate JSON or XML directly. It should generate a data structure built out of PHP associative arrays and other PHP native types, which the API will then turn into JSON, XML, or serialized PHP based on the 'format' parameter as it does for every other API request. Anomie (talk) 15:54, 5 November 2018 (UTC)[reply]
Or HTML for the front end in either desktop or mobile format. MER-C (talk) 18:58, 6 November 2018 (UTC)[reply]