Gadget kitchen/Requests

Fast Per-User Diff / Contributions Viewer
The Wikimedia Foundation folks organizing education programs around the world (where students improve Wikipedia articles as an assignment) are looking for better tools for professors to review student contributions.

One of the needs that's come up is a more user-friendly, consolidated view of all changes made by a user -- either for a timeframe, or a given page.

That is:
 * allow student / page-level filtering of a user's contributions
 * render a series of diffs below each other on one page
 * collapse adjacent edits by the same user into a single diff

Only sets of adjacent edits by the same user should be collapsed (User A->User A). If a user made multiple non-adjacent changes (User A->User B->User A), those should be shown separately.

The idea here is to facilitate quick review of relevant changes or changesets made by a student. If we can surface additional information in the process (edit survival, summary information about edits made by others, etc.) which provides professor-understandable context, that would be great, but even a fast diff viewer would be very helpful.

You'd fetch diffs one-by-one via the API (can load them asynchronously onto the same page, allowing the reviewer to start on the latest or earliest edits and keep on going even while things load).

This shouldn't cause extra load versus loading the same diffs manually, but will be a lot nicer for the person reviewing it.

This could make a big difference for getting hundreds more students to work on educational content -- it's a Good Thing. And it's probably useful in and of itself.

Minimal mock-up
Contributions by user: ________________ Set filter (optional) Begin date:   (CALENDAR WIDGET) End date:     (CALENDAR WIDGET) Article:      ___________________ Sort order:   [ oldest first ^] [Show contributions] => Contribution by  to  on  (DIFF) Contribution by  to  on  Note: Three adjacent edits are collapsed (DIFF) (SPINNER) Loading contributions

Implementations
User:Jarry1250 had taken a first crack at this as a toolserver script (outdated weblink).

Automatic updates to pages with bug templates
We have bug templates, like Template:Tracked, which are used to help users understand whether a bug they care about has been fixed or not.

It would be nice if users could quickly see what the status is without having to visit Bugzilla. This could be accomplished by a gadget (which could be promoted to site script if it works well) which uses the Bugzilla JSON-RPC API to fetch the bug status for all the bugs on a page, and then injects little status messages to the HTML.

We can get the status for a bunch of bugs like this (use POST not GET for using the API), e.g. to get both status and last update time for a few bugs:

 https://bugzilla.wikimedia.org/jsonrpc.cgi?method=Bug.get&id=158&params=[ { "ids": [32353, 26065, 26079],"include_fields":["last_change_time","status"]} ]

See the JSON-RPC documentation for more info and see BugTender for an example web application that uses it.

Gadget, preference, or default setting to open search results and suggestions in new tab
I propose a gadget, preference, or default setting for opening search results and suggestions in new tabs. I suggest basing it on the JavaScript found here:
 * commons:MediaWiki:Search-results-new-tab.js

I have tested it on both Wikipedia and the Commons. It works great. For more info read the talk page here:
 * commons:MediaWiki talk:Search-results-new-tab.js

I am an admin on a Wikia wiki too, and would like this to be a gadget, preference, or default setting on that MediaWiki installation too. That is why I would prefer it to be a core gadget, preference or default setting in MediaWiki. This way it would work on all MediaWiki installations.

I think the best thing would be for it to be the default setting in the MediaWiki software. Once one has used it for awhile on any wiki one has no desire to go back to opening up search results or suggestions in the same tab of a browser. --Timeshifter (talk) 23:45, 14 April 2012 (UTC)

Advanced search link in sidebar
Putting an advanced search link in the sidebar would fix the problem too. It would link to Special:Search. Then people would not have the problem of search results and suggestions covering up the last page one is reading. --Timeshifter (talk) 17:54, 19 April 2012 (UTC)

Colour-coded character sets in edit box
In Russian Wikisource I was looking at a book, where lists of literature references contain a mix of Russian and German titles. This book was OCRed for Russian, so when the print says "Barentz" in Latin letters, the OCR text says "Вагепгг", which are Cyrillic (Russian) letters that look similar, but actually transcribe to the nonsense "Vagepgg".

When proofreading such a text in a wiki edit box (using the ProofreadPage extension, as Wikisource does), it would be a great help if all Cyrillic letters (a range of Unicode characters) in the edit box could be coloured different from the Latin ones. Is this possible to achieve with a personal or site-wide Javascript, stylesheet or gadget?

What I would like is a gadget that allows the user to decide if Unicode range XX to YY in the edit box should be coloured in ZZ,

Here is a diff link to the page in question, http://ru.wikisource.org/w/index.php?title=%D0%A1%D1%82%D1%80%D0%B0%D0%BD%D0%B8%D1%86%D0%B0%3AGeo_stat_rus_imp_4.djvu%2F863&diff=702229&oldid=701373 The large print is the text of an encyclopedic article. The small print is the list of literature references. --LA2 04:15, 8 March 2012 (UTC)

Gadget / script to see namespace names in English in non-English wikis
I am comfortable with the English namespace names, but when I am in other Wikipedias, specially those that don't use the Latin script, it becomes a little difficult to deal with the local namespace names in the URLs and page titles that are served. This problem is compounded if the characters show up as boxes. I am aware that English namespace names work as aliases in other language projects, and we can change the interface language on any wiki, so can we have a script or gadget to have the namespace names in URLs and page titles in English on non-English wikis? Is there already some way to do this, and is it technically possible? A possible generalisation of this concept could be to show the namespace names in the interface language selected by the user. The Discoverer (talk) 11:58, 4 May 2016 (UTC)
 * Here:

$( function {	var cns = mw.config.get( 'wgCanonicalNamespace' ),		title = mw.config.get( 'wgTitle' );	if ( cns ) {		$( '#firstHeading' ).text( cns + ':' + title );	} });
 * This uses "Project" for the project namespace, though, instead of an English translation of the project name. Is that okay? --Yair rand (talk) 20:58, 4 May 2016 (UTC)


 * Hello Yair rand, thanks for your quick reply. The code works well and converts the titles into English. It is helpful for me because it lets me know exactly which namespace I'm in on any Wikipedia, and I can easily create valid links using the page title, which is now in English, without having to use another script.


 * I noticed that it does not change the URL that is served nor the html tag, and I guess that this would not be possible for a user script or gadget, and it would require a modification of the MediaWiki software. Am I correct?


 * The Konkani Wikipedia (gomwiki) has the content and interface in both, the Latin and Devanagari scripts. At present, the namespaces are only in the Devanagari script (gom-deva), with no aliases (except, of course the English namespaces, which work globally). I'm thinking that if we add the Latin Konkani (gom-latn) namespaces as aliases, we can have a gadget that allows users to choose to see page titles in either gom-deva, gom-latn or en, and all these titles would be valid wikilinks. A simple gadget that can go a long way in improving the users' localisation experience. What are your thoughts on this?


 * Thanks and regards, The Discoverer (talk) 08:09, 5 May 2016 (UTC)
 * Okay, new version:

$( function {	var cns = mw.config.get( 'wgCanonicalNamespace' ),		title = mw.config.get( 'wgTitle' ),		pagename = mw.config.get( 'wgPageName' ).replace( /\_/g, ' ' );	if ( cns ) {		$( '#firstHeading, title' ).text( function ( i, t ) { return t.replace( pagename, cns + ':' + title ); } );	} });
 * This fixes the, but doesn't do anything about the URL. Fixing the URL as well is possible, but somewhat more difficult.
 * Re Konkani, that would require having a list of the namespaces in both variants, which is not immediately accessible, but could, I suppose, but compiled manually. However, I'm hesitant to have a gadget in widespread use doing this kind of thing. It should be possible for namespaces to be displayed based on user settings from the Mediawiki side of things. I think there's a task open somewhere on Phabricator for this. --Yair rand (talk) 08:54, 5 May 2016 (UTC)
 * Thanks Yair rand! I was surprised to see the simple solution for changing the title tag. I agree with your point that it's best if this kind of things are done by Mediawiki itself. Thank you for your help and information. Regards, The Discoverer (talk) 08:47, 6 May 2016 (UTC)