Reported by @XXN.

Related to #39.

A user suggested in my talkpage that RTRC should provide a scollbar for the content of new pages (e.g. on this configuration )

There are still some elements of the interface which can't be translated.

• Header:
  • Real-Time Recent Changes ($1)
  • https://commons.wikimedia.org/wiki/File:RTRC_Placeholder.png
  • Help
  • MassPatrol
  • AutoDiff
  • Pause
• Diff frame:
  • Close
  • Skip
  • Unskip
  • Open in Wiki
  • [mark]
• Footer:
  • Legend
  • Abbreviations
  • Real-Time Recent Changes by Krinkle
  • Documentation
  • Changelog
  • License
• Sidebar:
  • Monitor and patrol recent changes in real-time. (tooltip)

Today I'm getting a page without formatting when I access:
https://pt.wikipedia.org/wiki/User:Krinkle/RTRC?uselang=en

Looks like RTRC uses the user option timecorrection. If this was saved by a user during the winter, and then used in the summer, the value is incorrect.

MediaWiki itself ignores the offset value and uses the offset name instead (e.g. "System" instead of "60" or "120", for nl.wikipedia.org).

Upstream logic: mediawiki-core:/includes/MWTimestamp.php

When monitoring a wiki in the background, it would be useful to notify the user in some fashion if the tab is in the background.

For example, we can add a symbol or number to the window title.

We could additionally make use of the HTML5 Notifications API and send notifications to the browser itself which are then replaced with successive edits (never showing more than 1). This provides a richer user experience than page titles (more visible, especially if you have lots of tabs open, the tab label is essentially just an icon, windows on other monitors, overlapping windows, ..).

Imported from meta.wikimedia.org:

• [MINOR SUGGESTION]: Window/Tab title notification
• Intforce filed the issue on 19:34, 11 September 2012

The RTRC tool is really a masterpiece of JavaScript here. I have a minor suggestion: I've mostly got the tool in a new tab in my browser. Would it be able to change the tab title to a sort of notification like: "(1 pending changes) RTRC: simplewiki" whenever an edit arrives? That would be very useful.

MediaWiki core already implements this for page conten with wikipage.content. I expect other hooks will follow soon for things like portlets, categories and diffs.

When it does, we can fire those hooks from RTRC so that other gadgets can universally add utility links (e.g. "rollback AGF", "rollback VANDAL" etc. like Twinkle does) regardless of whether the diffs are shown by MediaWiki or by RTRC.

Originally requested on meta.wikimedia.org by Matanya on 31 January 2011.

When it reaches a redirect on Wikidata, MassPatrol will stop working.

On some mobile devices the x in the diff box is too small and very hard to click on, please make it bigger.

I'm getting this error a lot on Wikidata, it will work after some time until it starts refetching again.

New browsers implement a Page Visibility API which we can use (polyfill) to determine whether the tab is currently focused. Using that hook we could reduce the refresh interval so we produce less load when users have the tab open in the background while multi-tasking (e.g. when dealing with a bad edit discovered in RTRC, we don't need to continuously refresh).

I've used this before for the Zuul status page (source).

See also #26.

The "[my patrol log]" link has user=null if the user is not registered. The tool could get the IP from Geo.IP – Helder, 22:44, 3 October 2012 (UTC)

Thanks! I'll convert it into a different bug. Anonymous users don't have the patrol right, as such linking to their log is useless. That link shouldn't be shown unless there is a patrol token received. – Krinkle, 22:13, 4 October 2012 (UTC)

Indeed! That solution is also good. – Helder, 11:24, 5 October 2012 (UTC)

Originally requested on meta.wikimedia.org

How to reproduce:

1. go to https://he.wikipedia.org/wiki/%D7%A9%D7%99%D7%97%D7%AA_%D7%9E%D7%A9%D7%AA%D7%9E%D7%A9:Amire80 and make an edit after enabling RTRC
2. the edit doesn't appear in RTRC interface.

Can we make revisions reviewed by clicking mark button? It is not useful for us now.

This used to be possible via vPopSpeed [1](by Henna), and later SpeedPagePatrol [2](by me), but is no longer possible due to (very valid) security restrictions [3]. It wasn't supposed to be possible to have a Tool just open a page and automatically patrol a bunch of edits for you.

I later attempted to implement this inside RTRC (by adding a page-name filter, similar to the user-name filter), however this too had to disappear due to this feature no longer existing in the MediaWiki API backend [4] (the query is not optimised by SQL index, and thus caused Wikimedia production requests to time out).

The idea is to use the Query tool (Krinkle/mw-tool-query#1) to fetch the rcids of the specified page name, and feed those back to the MediaWiki API.

• [1] vPopSpeed:
  • it.wikipedia.org - VPopSpeed
  • nl.wikipedia.org - VPopSpeed
• [2] SpeedPagePatrol:
  • https://github.com/Krinkle/ts-krinkle-misc#speedpagepatrol
• [3] Security bug:
  • https://github.com/wikimedia/mediawiki-core/blob/1.17.5/RELEASE-NOTES#L284
  • https://bugzilla.wikimedia.org/show_bug.cgi?id=24418
• [4] API feature request: https://bugzilla.wikimedia.org/show_bug.cgi?id=55377

To use the costum script in combination with semantic form please
change

    // Only on editpage
    if ($.inArray(mw.config.get('wgAction'), ['edit', 'submit']) !== -1) {

into

    // Only on editpage
    if ($.inArray(mw.config.get('wgAction'), ['edit', 'submit', 'formedit']) !== -1) {

Thanks!

Switch I18N backend from the old I18N.php at Toolserver to the API of the Intuition instance at Tool Labs (Krinkle/TsIntuition#3).

which loads https://meta.wikimedia.org/w/index.php?title=User:Krinkle/RTRC.js&action=raw&ctype=text/javascript

In the Firebug-Network-Tab, I notice that
https://tools.wmflabs.org/intuition/load.php?env=mw
still loads while this error-message appears and finishes after about 5s successfully.

Browser: Mozilla

Firefox 24.0

It would be very useful along with the edit tool also showed the log except for the verification of edit.

Though the Tip feature has been removed, it can still be hard to (for example) select a user name because after each fetch, the feed html is replaced.

On wikis that have Translate installed, such as mediawiki.org, sometimes the review interface gets broken unrecoverably because RTRC was unable to retrieve a patrol token.

api.php?format=json&action=query&list=recentchanges&rctoken=patrol&rclimit=1&rctype=new

Though the patrol token is the same for every page, it is expose via ApiQuery on a per item base. And when that top item from rclimit=1 is a translateable page, Translate extension throws an exception and makes the query return { error: unknown .. tpt-target-page .. } instead.

Implement rollback.

Imported from meta.wikimedia.org:

• [FEATURE REQUEST]: Rollback via ajax request
• Freaky Fries opened this issue on 06:35, 8 September 2010 (UTC)

I think "Skip", "Prox", "[mark]" and "Open in Wiki" should have keyboard shortcuts.

Sometimes a user has made several consecutive edits in an article. At this situation it may be easier to check the whole diff of changes made by the user.

Currently if I want to do that, I will need to open the article (or a diff) and then click on page history and then select ...
If there was a link to the page history at RTRC's user interface it would have made my job one step easier.

(Although it would be much better if RTRC could directly show the whole changes made by a user in recent edits and mark them as patrolled at once. But I thought that it may be hard to implement, so for now just adding a link to page history would be nice.)

I would like to be able to include the flood and bot flagged edits in the RTRC feed, obviously off by default. Thanks for this tool, by the way, it is very handy.

I always forget what is the meaning of that "R" inside the .mw-rtrc-settings-refresh lavel.
Since there is plenty of space, this one letter label should be changed to something more descriptive.

it should get the "parsedcomment" parameter from API:Recentchanges instead of "comment": parsed comments are easier to read, often shorter, and with useful links.
--Ricordisamoa 08:28, 1 July 2013 (UTC)

Originally requested on meta.wikimedia.org by @ricordisamoa

Expose the rctag option.

• https://www.mediawiki.org/wiki/Manual:Tags
• https://www.mediawiki.org/wiki/Special:Tags
• https://www.mediawiki.org/wiki/API:Recentchanges#Parameters
• https://www.mediawiki.org/wiki/API:Tags

I was about patrolling AWB-edits in mass-patrol mode, filled-in the user, and attempted to scroll down to the list but it was not very pleasing because it often collapsed the diff-section completely before showing the new diff. Can this be enhanced e.g. not fading out until the new diff is not faded-in/ ready to fade-in?

So that when opening a diff further down the list the user doesn't have to scroll up manually.

/cc @mardetanha

A user suggested at
https://pt.wikipedia.org/w/index.php?diff=37155688&oldid=37154849
that it would be useful to have a "« Prev" button (similar to the "Next »" button) to help navigating between the diffs, and also to go back after clicking on the "Next »" link by accident.

Currently the raw message shows up:

{{GENDER:$1|User}} contributions

When I acces this page using Google Chrome 34.0.1847.131 m (on Windows), I get the message "This program requires functionality not supported in this browser."
For some reason, $.support.modernizr4rtrc.generatedcontent seems to be false.

Currently, RTRC links all users' pages, while the link does not work for anonymous ones. The link should be removed or directed to the user's contributions. mw.util.isIPv4Address and mw.util.isIPv6Address can be used to distinguish registered users and link to their user page.

I suppose this involves L264.

Originally reported here.

Even when enabling the "Unpatrolled only" filter (which should be set by default when enabling MassPatrol) it's still possible to hit a patrolled change by accident if someone else patrols it between fetching the feed and the iteration over them.

In that case MassPatrol should ignore them and iterate over unpatrolled changes only. Basically we should make sure to filter client-side as well, not just in the query for the feed from the server.

Right now it checks the ORES' API index to make sure the ORES has models for the wiki, but it doesn't verify which models ORES has. Most wikis only have reverted, not `damaging.

We should probably also try reverted if damaging is unavailable, though that has issues at the moment (see https://phabricator.wikimedia.org/T129624).

On RTL wikis the sidebar is on the right... Here is an screenshot (from fawiki):

Migrating from https://toolserver.org/~krinkle/CVN/API/ to http://cvn.wmflabs.org/api.php.

See also https://github.com/countervandalism/cvn-api, as this is more than just a switch. The API itself has been rewritten to integrate better with jQuery, but requires some changes on our end to work the same (some properties have been renamed).

Consider adding a link to the default recent changes page of the wiki pointing to your customized version (i.e. your /RTRC subpage on that wiki), so users can find it more easily (just in case they are expecting the script to improve the existing special page, which is something I've seen...)

Originally requested on meta.wikimedia.org by @helder-git on 13:49, 15 January 2013 (UTC).

To save having to query the same users and pages again. RTRC can be kept open for a long time (hours or even days). Make sure objects (and absence of objects) is not cached for more than a few minutes at most.

Add a option to mark users with specific templates on the talkpage of the user. Maybe in a pop-up named "Advanced filters".

Firefox:

Chrome:

Like #35, but for users. Select a user from the list and auto-masspatrol all their edits.

I miss an option to restrict the list of changes to those pages which are in my watchlist.

Due to the I18N being required and loaded from Toolserver:

• https://toolserver.org/~krinkle/I18N/export.php
• https://toolserver.org/~krinkle/I18N/export.php?lang=en

.. and the web server there frequently returning gateway errors, as a result the interface never loads.

As a user reported on ptwiki, the MassPatrol feature is dangerous and, contrary to what is documented, doesn't seems to be requiring a 'Userfilter' to be defined. Is there a easy way to disallow this on ptwiki?
Helder 20:08, 1 September 2013 (UTC)

Originally requested on meta.wikimedia.org by @helder-git

Recently the cvn-api has been down a lot due to issues with cvn's infrastructure at WMF Labs. Let's temporarily disable this so that existing permalinks don't hang on it.

Eventually we should implement logic that will recover from its downtime and continues without it.

A quick way to open RTRC for specific operations, like mass-patrolling.