[go: up one dir, main page]

Jump to content

MediaWiki talk:Recentchangestext

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This message on other sites, and in other languages on this site

[edit]

Note that interlanguage links show up differently on a talk page like this.

Meta | Commons | Wikibooks | Wikiquote | Wikisource | Wiktionary | Wikivoyage | Wikidata | Deutsch | Français | Nederlands

This message on this site, depending on the user-specified interface language:

    en (English):

  • af (Afrikaans / Afrikaans): -
  • ar (Arabic / العربية): -
  • bg (Bulgarian / Български): -
  • bn (Bengali / বাংলা): -
  • da (Danish / Dansk): -
  • de (German / Deutsch): -
  • eo (Esperanto / Esperanto): -
  • es (Spanish / Español): -
  • eu (Basque / Euskara): -
  • fr (French / Français): -
  • fy (West Frisian / Frysk): -
  • it (Italian / Italiano): -
  • la (Latin / Latina): -
  • li (Limburgian / Limburgs): -
  • nl (Dutch / Nederlands): -
  • no (Norwegian / ‪Norsk (bokmål)‬): -
  • pl (Polish / Polski): -
  • pt (Portuguese / Português): -
  • ru (Russian / Русский): -
  • sv (Swedish / Svenska): -

Pages in the MediaWiki namespace regarding this message

Adding a tickbox to only show the edits that are the most recent

[edit]

G'day, I do frequent the recent changes page a fair bit but am always manually checking if the listed edits have a [rollback] tag as around 90%+ edits that are not the most recent are because they have already been reverted / resolved. Can this become an actual function to enable to hide non-current edits? I feel it would be useful for other edittors without Rollback permissions or another alternative — IVORK Discuss 04:29, 1 March 2018 (UTC)[reply]

Support. I personally would find this extremely useful. — MrConorAE (👤U | 💬T | 📝C) 04:56, 10 November 2020 (UTC)[reply]
@ 👤U Maybe I'm misunderstanding, but is there not already a check box to only show "Latest Revision" down below the Minor edit filter? Back in 2018 when IVORK made that request it was probably not a thing, but it's there now (and, yes, it's very useful). Matt Deres (talk) 13:38, 10 November 2020 (UTC)[reply]
Matt Deres, indeed there is! How have I not seen that? Thanks so much. :D — MrConorAE (👤U | 💬T | 📝C) 18:49, 10 November 2020 (UTC)[reply]

Click 'diff' or 'hist' to open in a new tab please

[edit]

I've been monitoring Recent Changes for some time now, and I would really welcome not having to right-click either 'diff' or 'hist' each time to get the results to display in a new tab. A simple mouse click ought to do it. It seems very unlikely that editors reviewing Recent Changes would want to intentionally leave that page, only to return and wait for their settings to reload after each check. So a simple click to open either a new tab or a new widow would be a very welcome enhancement to the interface. Nick Moyes (talk) 23:09, 10 June 2018 (UTC)  [reply]

Just to add, that for mobile users the problem is terrible. For the last 18 months (since I first posted this) I've been predominantly editing via a mobile or a tablet. There's obviously no mouse on a mobile, and trying to tap the correct link on a tiny screen often results in the wrong change being selected, and having to go back and reload RecentChanges every single time basically stops me wanting to contribute to anti-vandalism whilst away from my home PC. Nick Moyes (talk) 09:18, 6 February 2020 (UTC)  [reply]

Span markup causing lint error and suppressing display

[edit]

Prior to the two edits of Roan Kattouw (WMF) of 6 December 2017, the wikitext was

This is a list of [[Help:Recent changes|recent changes]] to pages linked from a specified page (or to members of a specified category).<span id="mw-specialpage-summary-hidegreen"> Changes to pages on your watchlist are shown with a <span style="color:darkgreen; font-weight:bold;">green</span> bullet.</span>

displaying as

This is a list of recent changes to pages linked from a specified page (or to members of a specified category). Changes to pages on your watchlist are shown with a green bullet.

Following those two edits, the wikitext is

Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). <span id="mw-wlheader-showupdated">Changes to pages on your Watchlist are shown<span id="mw-wlheader-bold"> in <strong>bold</strong></span><span id="mw-wlheader-green"> with a <span style="color:darkgreen; font-weight:bold;">green</span> bullet</span>.

displaying as

Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category). Changes to pages on your Watchlist are shown in bold with a green bullet.

There are two problems.

  1. There is a missing end tag lint error for <span> because there are 4 <span> and only 3 </span>. The missing </span> could presumably go at the end.
  2. the <span id="...">...</span> markup suppresses display. At least in my universe, all I see is
Enter a page name to see changes on pages linked to or from that page. (To see members of a category, enter Category:Name of category).

This is bizarre. What is going on? —Anomalocaris (talk) 10:04, 6 May 2019 (UTC)[reply]

(clarification: this is about MediaWiki:Recentchangeslinked-summary, whose talk page redirects here for some reason)
@Anomalocaris: Whoops, sorry about the missing </span> tag. I've fixed it, thanks for pointing it out.
As for the markup suppressing the display, what's going on here is that the sentences in the span tags are only visible if you've got certain gadgets enabled. For example, if you have the "Display green collapsible arrows" gadget enabled, then MediaWiki:Gadget-WatchlistGreenIndicators.css will cause the text about green bullets to be shown, and if you have the "Display pages on your watchlist that have changed since your last visit in bold" gadget enabled, then MediaWiki:Gadget-WatchlistChangesBold.css will cause the text about bolding to be shown. If you have neither of those enabled, MediaWiki:Gadget-WatchlistBase.css hides all of these spans. This way, the text matches the features you have enabled: if your watchlist is configured not to show green bullets, you also don't see the part of the message that explains what the green bullets mean. Hope that makes sense, and happy to answer any follow-up questions. --Roan Kattouw (WMF) (talk) 00:25, 7 May 2019 (UTC)[reply]
Roan Kattouw (WMF): Thank you for the explanation and for fixing MediaWiki:Recentchangeslinked-summary, but I think you want to move the final </span> to after the period, because for those of us with the gadgets disabled, we see the above noted sentence, except it ends period space period. —Anomalocaris (talk) 00:40, 7 May 2019 (UTC)[reply]
Good catch! Fixed. --Roan Kattouw (WMF) (talk) 00:42, 7 May 2019 (UTC)[reply]
Roan Kattouw (WMF): All fixed now, thanks! —Anomalocaris (talk) 02:22, 7 May 2019 (UTC)[reply]

Protected edit request on 23 May 2019

[edit]

Please remove

 [[Wikipedia:Milestones|Milestones]] –

since Wikipedia:Milestones is marked as historical. Thanks, --DannyS712 (talk) 19:01, 23 May 2019 (UTC)[reply]

 Done — Martin (MSGJ · talk) 12:36, 24 May 2019 (UTC)[reply]

alvin kageliza rueywa

[edit]

le a e parti on voye so promine du large — Preceding unsigned comment added by Alvin kageliza (talkcontribs) 17:13, 16 July 2020 (UTC)[reply]

Interwiki (at Wikidata) not available for special page

[edit]

This change (Special:Diff/565539355) makes the interwiki links disappears because the special page has no items on the wikidata. Manual interwiki links shouldn't be deleted, also, I've tested it at idwiki here. --Hidayatsrf (talk) 04:24, 3 August 2020 (UTC)[reply]

 Not done WP:BRD, phase 3. I don't think this is necessary, we don't put interwiki links on any of our other Special pages (e.g. Special:Watchlist, Special:NewPages), Special:Log) so don't really need these here either. — xaosflux Talk 14:07, 3 August 2020 (UTC)[reply]

Filter options changes

[edit]

It's been a while since I've done recent changes patrol and I love the new filtering mechanism, but I have a question and a couple of requests:

  • Sometimes, I don't see the options regarding User Intent Predictions. The Contribution Quality, User Reg, and other options are always there (AFAICT), but the User Intent section seems to come and go. Any idea why that would be? The issue persists even if I clear my filter preferences.
  • First request: would it be possible to allow for expanding the number of returns or going back further in time? At times, I'll get "caught up" to the 50 diffs that show and there's no way for me to go back any further other than changing the filters, which somewhat defeats the purpose of the filters. Even just showing 100 or 150 instead of 50 would be great.
  • Second request: I really like the predictive filters and they seem to work pretty well, but there's another angle to finding vandalism and that is the fact that some topics are higher targets for what I'll call "Casual vandalism". These are not typically the targets of dedicated vandals, but the stuff that kids tend to mess around with. The ones that immediately come to mind are schools, dates, and towns. Everyone likes adding their friend's name as "greatest sex machine". I know our categories are maybe not perfect, but is there a way we could use them to establish a filter regarding how likely the topic of the article is as a target of poor edits?

Just some suggestions; the tool is already much better than the ones I used previously; I really appreciate all the work that surely went into it. Please PING me with any replies. Matt Deres (talk) 17:24, 23 October 2020 (UTC)[reply]

Matt Deres - as far as I know, you can modify the number & timespan of edits to display by clicking the button on the far right of the screen that says X changes, X days. — MrConorAE (👤U | 💬T | 📝C) 19:46, 10 November 2020 (UTC)[reply]
MrConorAE - Thanks! Matt Deres (talk) 22:59, 10 November 2020 (UTC)[reply]

Filters sometimes do not appear

[edit]

Sometimes, certain categories of filters do not show up when I open the recent changes page. It seems to affect the "Contribution quality predictions" and "User intent predictions" most often. Refreshing my browser's cache does not resolve the issue, but it does go away on its own. Has anyone else experienced this?

I'm mainly using Chrome. Ixfd64 (talk) 00:54, 6 December 2020 (UTC)[reply]

Suggested page layout improvements

[edit]

RecentChanges is a repetitive process, and anything to minimise the unnecessary mouse movements, or keyboard and finger taps would be likely to be an improvement for everyone. The following layout suggestions would make the task a lot simpler in my view, and I propose that they be implemented: *Line up 'diff' links so that they appear directly above one another (and the same with 'hist' links). i.e. Move them to appear as two columns between the timestamp and the article title. This would avoid the need to constantly move the mouse cursor around the page to click each diff or to view other details via a Navigation Popup mouseover. On a mobile, one sometimes has to move the whole screen around when the article title is a long one in order to find the diff link before attempting to tap it.

  • Increase the spacing between between 'diff' and 'hist' links for mobile phone users in desktop mode to avoid frequent accidental tapping of the wrong link.
  • Make each clicked link open automatically in a new Tab - this would keep the main Recent Changes page open for continued monitoring. Needed for both mobile users and desktop users. First suggested here in 2018

*In mobile (BUT desktop) view: Centre the timestamp with the row text - it looks terrible with the timestamp top-justified and the rest of the row text lower down (as seen in Safari on iOS).

  • In mobile view: Increase the font size of the text for 'diff' and 'hist' - these are the most important bits of the page to tap, yet are the tiniest and hardest to locate on a small screen.

I'm sure the layout and functionality of this page didn't used to be this poor. Maybe it's my imagination, but nothing I see in the current, illogical layout seems to offer anything like the efficient process it once was. I would welcome other Change Patrollers' feedback on these proposals. Nick Moyes (talk) 19:58, 29 December 2021 (UTC)[reply]

Note: I've struck some of my comments because I'd not realised my long standing favourite settings had been hijacked when I accidentally clicked on another user's settings at a Teahouse post and they changed mine to the awful layout seen when Group results by page is ticked in the settings here. That makes me think it could be helpful if one could somehow save one's preferred filter settings without them being accidentally lost in this way. Nick Moyes (talk) 21:37, 29 December 2021 (UTC)[reply]
None of these suggestions are realizable on this page. WP:VPT/WP:VPPRO and/or WP:PHAB for them as a start. I'll leave some comments anyway:
  • Increase spacing and size for mobile users of diff/hist: Mobile users (https://en.m.wikipedia.org/wiki/Special:Watchlist) have a much friendlier layout by default for watchlist and recent changes. I would guess you're using a desktop skin at mobile resolution as a result?...
  • New tabs: Bad for accessibility. If you need it, middle click or right click and so on. I'm sure it'd be a trivial user script as well.
  • Being hijacked by another's settings is a feature-bug to some degree, but already has a Phabricator task somewhere. I am pretty sure Whatamidoing (WMF) filed it.
In general, changes to this areas are hard to realize because of the multitude of settings that change what is sent to the browser (I vastly prefer group results by page as a particular example) and layouts of interest (mobile vs. desktop) and the fact that recent changes and watchlist have quite a bit of shared code. Izno (talk) 01:07, 4 January 2022 (UTC)[reply]
(Increasing the size and spacing of those elements can also be done in a local skin.css page.) Izno (talk) 01:18, 4 January 2022 (UTC)[reply]
@Nick Moyes, it sounds like you got bit by phab:T202916. There's a user script in the comments that aggressively re-fixes your prefs (every single time you load any page at all). Whatamidoing (WMF) (talk) 19:07, 4 January 2022 (UTC)[reply]
Oh, I can so relate to the angst in that Phab report! I still can't fathom what actual point there is to "Group results by page". I see absolutely no difference to content, other than an enhanced, shitty page layout. Yes, I edit on mobile, but always in desktop view (and sometimes under the bedsheets when I can't sleep at night!) Trivial user scripts may be trivial to some people, but to this mere mortal they're still magical pixie dust that I adore when someone else makes them. Prioritising accessibility over common-sense functionality is a proverbial pain in the a... Nick Moyes (talk) 01:33, 5 January 2022 (UTC)[reply]
Well, after reading the Phab ticket's description, you might have come to the conclusion that I have at least a slight preference for the One True™ format, aka the format that was the default when I was a new editor.
I agree with you that user scripts are basically magic. It is not reasonable to expect even experienced editors like us to be able to write them. One of the perks of this job is having a couple of devs I can whine at. If I'm annoying enough, they will sometimes write me a script to make me be quiet. If you look at m:User:Whatamidoing (WMF)/global.js, then the ones labeled "// Happiness //", "//Blame this one on Ed//", "//David L said not to use this //", and "// nowiki button for the 2017WTE" were all made because I whined about a problem. (Happiness is probably redundant to enabling DiscussionTools in Special:GlobalPreferences now. Ed's will give you a URL to an exact comment (not just a section), and could be useful to any experienced editor. David's adds the Special Character tool to the Reply tool's toolbar, to get me to quit whining about phab:T249072. The nowiki button (written by Matma Rex) adds a nowiki option to the 2017WTE's character formatting menu. Feel free to copy any of them that sound useful to you.)
Whatamidoing (WMF) (talk) 16:42, 5 January 2022 (UTC)[reply]

Filtering New articles

[edit]

Possible I've missed it but is there a way to filter redirects from appearing when one hopes to look at newly created articles? If there's not an explicit way to do so, is there a workaround, like only seeing page creations above a certain size? Thanks! — Mainly 15:55, 30 January 2022 (UTC)[reply]

Interface protected edit request on 31 May 2022

[edit]

Change the text to Track the most recent changes on Wikipedia on this page. on MediaWIki:Recentchanges-summary. TOPaner (talk) 10:27, 31 May 2022 (UTC)[reply]

 Not done if we were going to go back to mediawiki default, we wouldn't hard code that here. That being said, I don't think that is an improvement. So now we're at WP:BRD step 3, feel free to continue discussing below - if a consensus emerges for a change, reactivate the edit request above. — xaosflux Talk 15:00, 31 May 2022 (UTC)[reply]

Question about the filters

[edit]

Generally speaking, the first two filters at the top of the list are regarding quality (good versus problematic) and intention (good faith versus bad). However, sometimes when I check RC, the intention options are not available. Why is this? Matt Deres (talk) 20:45, 15 April 2023 (UTC)[reply]

Being bold here, but I would suggest adding Special:AbuseLog to the utilities section, piped as Edit filter log. I would place it after either RC patrol or Mobile contribs. I think it's a pretty useful page for counter-vandalism, and could help newer patrollers learn about it's existence. win8x (talking | spying) 19:44, 10 October 2024 (UTC)[reply]

 Done Izno (talk) 23:07, 21 October 2024 (UTC)[reply]