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 <User> to <Article> on <timestamp>

(DIFF)

Contribution by <User> to <Article> on <timestamp>
Note: Three adjacent edits are collapsed

(DIFF)

(SPINNER) Loading contributions

Implementations

User:Jarry1250 has taken a first crack at this as a toolserver script here (repl. username with whoever).

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)