I would like to use this script when reviewing pending changes. However, when I see the pending changes, it only shows the diff, not the article with the changes implemented. Can an editor edit the my script so that it shows both the diff and article with the changes implemented? I don't know how to do it myself so I am asking for help. Interstellarity T 🌟 10:08, 21 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Not me, but DannyS712 can. --qedk (t 桜 c) 19:42, 21 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

QEDK, Can you find someone else that can do it if DannyS712 can't do it? Interstellarity T 🌟 20:09, 24 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Interstellarity, Hi there i have fixed that issue. ___CAPTAIN MEDUSAtalk 13:14, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I have just recently been having an issue: When I hit the preview button to check my edits then hit the publish button I get an edit conflict. When this first happened I treated it as such and it posted twice. After that I have reloaded and see it is already posted by only hitting the preview button. I have never had this issue, that was not a legitimate edit conflict, so am at a lose. Otr500 (talk) 16:09, 24 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Note: This has happened 4 times but when I previewed this edit then hit "publish changes" it worked fine. Otr500 (talk) 16:12, 24 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Apparently this is an issue only I am having but it is still ongoing. Otr500 (talk) 18:09, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Wikipedia:Village_pump_(technical)#Incorrect_Edit_Conflicts related? Galobtter (pingó mió) 18:24, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Very possible. Also whatever the issue is (I will have to look) it might be related to Wikipedia:Village pump (technical)#Block conflict that may just be another area where the edit conflict is occurring. Otr500 (talk) 12:19, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm getting inexplicable edit conflicts today. Doug Weller talk 19:55, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

And again when I tried to post the above. Doug Weller talk 19:56, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Again! Is it groundhog day? When this happens again I own't bother to mention it here. Doug Weller talk 19:57, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'd like to know if there is any bot or tool that can help me finding old vandalizing editions in a WP file history. Thanks. --Jotamar (talk) 23:56, 19 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

When I said WP files, I meant WP pages. Can someone at least tell me, where should I ask my question? --Jotamar (talk) 19:01, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Yes, Jotamar, probably WP:BOTREQ, how many edits are you looking for? There will be many millions. Fist step might be to look for edits preceding those with an edit summary of "rvv". Another good place to look is the edits prior to User:ClueBot's edits.

All the best: Rich Farmbrough, 10:49, 28 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

If you already know specific vandalized text in an article and want the edit which added it then click "Find addition/removal" at the top of the page history. It used WikiBlame until recently but the tool has problems and another is currently used. It's discussed at MediaWiki talk:Histlegend#Wikiblame replacement. PrimeHunter (talk) 11:09, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

What I have in mind is some sort of heuristic tool, capable of finding a short list of possible vandalazing editions that have not been reverted, in a group of pages, for instance, the pages under one category. In less popular, poorly maintained pages, it's not uncommon that such an edition can be easily reverted even after months or years, but first you have to find them, and that takes up a lot of time. --Jotamar (talk) 13:48, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I need help getting a reflist to fall at the bottom of the article. It is falling between 2 tables. [[1]]

I would like to understand why this happening so I can fix it myself in the future.

Thank you. Lore E. Mariano (talk) 14:02, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Fixed by [2]. PrimeHunter (talk) 14:10, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thank you so much! Lore E. Mariano (talk) 14:40, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Apparently there is a new bot creating cite errors. Article: WZ-551 Tag: Rescuing 14 sources and tagging 0 as dead. #IABot (v2.0beta15)

Is there a review process for new bots/tools? I have encountered many repeated errors that I assume are created by them. e.g. "coauthors=", "DUPLICATE_date". User-duck (talk) 17:39, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Communication failure between the bot owner and the community at WT:CS1. I fixed the WZ-551 page that Gog the Mild edited and will leave it to that editor to similarly repair any other error caused by the tool.

—Trappist the monk (talk) 17:56, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This is IABot via Oauth request by Gog the Mild. It was due to some miscommunications, my fault, iabot has been patched/rebooted and will look into fixing the errors added onwiki. -- GreenC 19:36, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Edit conflict. I had just written:

Thank you Trappist the monk. That would have been from me clicking "Fix dead links" on the "Revision history" page and not checking the result thoroughly enough. I shall recheck my other recent clicks of that button.

GreenC, do I need to do anything, other than recheck previous uses of "Fix dead links", and/or cease using it? Thanks Gog the Mild (talk) 19:44, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

You are good, it's ok now. Looks like the bug lasted 3hrs and somewhere between 100-200 articles. I might script a quick fix or request something at AWB request wouldn't worry about manually repairing. -- GreenC 19:48, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

21:22, 1 July 2019 (UTC)

Progression of events was:

1. Editor created a link to de:Otto Kirn (in article Pandeism, correcting from wrong link to Otto Kern).
2. Translated Otto Kirn added here.
3. Wikidata updated for articles now in two languages.
4. Tagged as an orphan here.

Question: Why doesn’t English addition to Wikidata automatically prompt changing of links previously made to point other languages? Hyperbolick (talk) 19:49, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

The edit said [[:de:Otto Kirn]]. This explicitly tells to link the German Wikipedia. {{Interlanguage link|Otto Kirn|de}}} could have been used instead to test for an English article called Otto Kirn. It would only have examined whether the page name exists and not whether it's in a Wikidata item. As far as I know we have no template for the latter. It is possible to pull information from Wikidata so maybe it could be added as a feature in {{Interlanguage link}}. I don't think it's possible for an English template to look up the Wikidata item for a German article so Q24529752 would probably have to be a parameter. A bot could be coded to automaticlly add the parameter when it's not supplied. PrimeHunter (talk) 21:12, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Could a bot check whenever a Wikidata item is connected from here? Got a notification here when it was, so somebody’s telling this Wiki. Hyperbolick (talk) 21:41, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Could someone knowledgable comment here, centrally, on whether there are database issues beyond the apparently temporary ones outlined in the above Tech News, and if so, what are their extent and when do we think they will be resolved? It appears multiple bots have for some time not been running DB intensive tasks (such as certain Wikipedia:Database reports), and it is very difficult to parse through all the bot/report talkpage chatter to get a true picture of what is actually going on. Thanks in advance! UnitedStatesian (talk) 02:46, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

The database replicas are undergoing maintenance (see T222978). This involves taking one replica host out of service at a time. The other two hosts then have increased load, which leads to replication lag and increased query time (previously long queries could fail to complete). Maintenance is usually ongoing during the week and paused over the weekends. I would expect this to be an ongoing issue for a while. I don't know how long the maintenance will take, but the DBAs are reaching the end of the maintenance one the first replica. The database items in the Tech News are unrelated. — JJMC89 (T·C) 05:29, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Dear All,

initially I turned to administrator regarding the issue, but unfortunetly he could not give an idea for solution. The details may be read there...Shortly, if I set it to list the changes back to 7 or 30 days, it is not working, just listing the last 250 changes, not more and I have as well no (previous/next) buttons...I need a solution, Thank You(KIENGIR (talk) 20:21, 1 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

@KIENGIR: This is Wikipedia:Village pump (technical)/Archive 174#did something break watchlist and make it too short again?. --Redrose64 🌹 (talk) 20:36, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Redrose64:,

Thank you it helped, I applied similar tweaks descibred there (in the detailed settings changing to 30 days and enabling 1000 entries as maximum). though, still I don't have 30 days, I assume mainly because of the 1000 entry limitation (I don't know where would be the url to tweak it higher). Thus practically I could go back two weeks, so my initial problem has been solved (going back between 4-7 days)...maybe as an important note for the others or the developers, even this worked only by unchecking the "Expand watchlist to show all changes, not just the most recent" in the Advanced Options...(initially at the first tweak attempt, I automatically checked this box assuming it is essential, but anything written above did not work until it was unchecked, ironically it had a contraproductive effect despite it's name...(KIENGIR (talk) 10:39, 2 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

Missing notification icons in MonoBook

I just spent ten minutes trying to figure out what was wrong on my end. If you're doing the same, it's not just you. See phab:T226503. Suffusion of Yellow (talk) 19:52, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm getting it in MonoBook too. The appropriate CSS rules are present in the stylesheets:

.oo-ui-icon-bell, .mw-ui-icon-bell:before {
    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=bell&format=rasterized&lang=en&skin=monobook);
    background-image: linear-gradient(transparent,transparent),url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Ebell%3C/title%3E%3Cpath d=%22M16 7a5.38 5.38 0 0 0-4.46-4.85C11.6 1.46 11.53 0 10 0S8.4 1.46 8.46 2.15A5.38 5.38 0 0 0 4 7v6l-2 2v1h16v-1l-2-2zm-6 13a3 3 0 0 0 3-3H7a3 3 0 0 0 3 3z%22/%3E%3C/svg%3E");
}
.oo-ui-icon-tray, .mw-ui-icon-tray:before {
    background-image: url(/w/load.php?modules=oojs-ui.styles.icons-alerts&image=tray&format=rasterized&lang=en&skin=monobook);
    background-image: linear-gradient(transparent,transparent),url("data:image/svg+xml,%3Csvg xmlns=%22http://www.w3.org/2000/svg%22 width=%2220%22 height=%2220%22 viewBox=%220 0 20 20%22%3E%3Ctitle%3Etray%3C/title%3E%3Cpath d=%22M3 1a2 2 0 0 0-2 2v14a2 2 0 0 0 2 2h14a2 2 0 0 0 2-2V3a2 2 0 0 0-2-2zm14 12h-4l-1 2H8l-1-2H3V3h14z%22/%3E%3C/svg%3E");
}

Switching to Vector displays them properly, even though the CSS rules are virtually identical - the only differences are that the word "monobook" becomes "vector" in the first and third url(...) value. --Redrose64 🌹 (talk) 20:21, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Um, did the fix also give a ton of scroll-space to the right of anyone else's window? I can now scroll for a very long time to the right, despite there being no content. Killiondude (talk) 23:42, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Killiondude: Yes, I see the same thing. (Firefox 67, Linux) Suffusion of Yellow (talk) 23:45, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Ditto here, IE 11 in Windows. They were missing for a while, but now they've reappeared. I think they're blurrier than before, however. Could someone ping me and thank me for this edit, so I can see whether the number notifications look any different. Nyttend (talk) 23:53, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Nyttend: (ping) Suffusion of Yellow (talk) 00:06, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thank you. Things are somewhat different; the numbers looked normal, but when I clicked each one, it was momentarily surrounded by a little dark box. The same is true if I want to review past notifications and click either of the icons when I have nothing new. Nyttend (talk) 10:51, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Nyttend: You might be right about the extra blurriness, I'm not sure (I took some screenshots a few years ago: c:File:Vpt redrose64 alerts.PNG, c:File:Vpt redrose64 alerts2.PNG, c:File:Vpt redrose64 alerts3.PNG back when the car door was still in place, now replaced by the TV set icon). You're certainly right about the little dark box, it's blue and there are two for each icon, one enclosing the number and the other enclosing the icon.

@Killiondude: The super-wide scroll space was present for me on all pages until about an hour ago, it's now stopped appearing. --Redrose64 🌹 (talk) 13:06, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

You guys aren't getting the icons? I'm getting only the icons — not the actual pings. On the upside, I get all thanks twice. See below. (Using Monobook.) Bishonen | talk 21:38, 27 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

@Bishonen: That's because this problem was fixed and the "fix" caused another problem. Try putting my "fix"-to-the-fix from the other thread in your monobook.css, and see if the links work as expected. Suffusion of Yellow (talk) 21:48, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm sorry, Suffusion of Yellow, I don't see a fix-to-the fix in the other thread (you mean "Someone has broken Thanks", right?), and altogether, you're speaking a foreign language. Could you tell me what to do as if explaining to your mother? Bishonen | talk 21:59, 27 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

@Bishonen: Sorry, there are too many threads about this right now. Try adding:

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

to your monobook.css. Works for me, at least. Suffusion of Yellow (talk) 22:07, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

And it worked for me. Thank you very much, Suffusion of Yellow.

Re-pinging Suffusion of Yellow. Bishonen | talk 08:10, 28 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

Suffusion of Yellow, I've just realized that my problem persists on Meta. Somebody pinged me, to test, and all I got was a three-year-old thanks. Can I put your magic code somewhere to fix that? (And hopefully Commons, Swedish Wikipedia, etc etc — I assume it's everywhere.) Bishonen | talk 19:30, 29 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

@Bishonen: the problem on meta-wiki, (and most all other projects) should get cleaned up with the next release train. If it doesn't I'll put the hack on meta-wiki. If you need it urgently, you can hack your own monobook.css there (or just click a bit further to the left). — xaosflux ^Talk 19:38, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Bishonen: You can also put the same code in your meta:Special:MyPage/global.css. In theory this could cause display problems if you view some wikis in non-monobook skins, but I just tried in Vector and Timeless and I didn't see any problems. Suffusion of Yellow (talk) 19:42, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Bishonen: Wait, just realized that it's possible to have the fix only apply to monobook. Give me a few minutes to work it out. Suffusion of Yellow (talk) 19:45, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

┌──────────────────────────────────────┘@Bishonen: Ok, try putting:

.skin-monobook #pt-notifications-notice .mw-echo-notifications-badge, .skin-monobook #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

in your meta:Special:MyPage/global.css. Suffusion of Yellow (talk) 19:54, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Suffusion of Yellow, now you're talking my language. It seems to work. Thank you. Bishonen | talk 20:20, 29 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

Excessive width on monobook

So if you are using monobook, you may now constantly think there is something off the page to the right. See phab:T226597 for the report. Apparently this is a hack that the dev's put in to work around the notifications mess above. — xaosflux ^Talk 03:14, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Merged to phab:T226594. — xaosflux ^Talk 03:41, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thank you. Just noticed this, and thought it was a broken ref spilling across the page I was on! Lugnuts ^{Fire Walk with Me} 06:54, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Jeez. Hadn't noticed. Can't unsee now. Here's a temporary fix. —RainFall 07:13, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-indent: 0px !important;
}

Yesterday, when I responded to the thread above ("please ping and thank me"), I looked for this and it wasn't the case, but now it is. Nyttend (talk) 10:53, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• I've added RainFall's fix temporarily to MediaWiki:Monobook.css after testing locally, revert if any new issues are caused (I tested with both notification types as well). — xaosflux ^Talk 11:58, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Does the temporary fix actually work? I've still got the excessive width. DuncanHill (talk) 12:00, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@DuncanHill: it took a min to update the central css, try force refreshing a page. — xaosflux ^Talk 12:01, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Xaosflux: Now working, thank you. DuncanHill (talk) 12:05, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Xaosflux: Now, when I click on the "talk" link to the right of the notifications, I get the Special:Notifications popup instead. It looks like the screen-reader text, hidden by color:transparent, is overlapping with the talk link. Suffusion of Yellow (talk) 21:24, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Suffusion of Yellow, DuncanHill, Nyttend, Lugnuts, and RainFall: OK, I reverted the .css in monobook.css, give it a few and see if it fixes that problem (resulting in the original problem) - seems like I'm having to argue with the dev team to get them to understand that the change they made is making the final page worse than before :( — xaosflux ^Talk 21:37, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

OK Talk is back, but so is super-wide-mode :( — xaosflux ^Talk 21:38, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Xaosflux: Argue with the The Knights Who Say "OOUI!"? Good luck! Suffusion of Yellow (talk) 21:52, 26 June 2019 (UTC) (discussiontools-replybutton)[(discussiontools-replylink)]

I'd like to laugh, but it's so annoying that breaking changes are just rolled out. If WMF want's to deprecate monobook they need to just say it - else stop breaking it.... — xaosflux ^Talk 22:31, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

"Quick - we need a distraction from Framgate, BREAK THINGS!" DuncanHill (talk) 22:32, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

please please please, don't feed to conspiracy theorists ... — xaosflux ^Talk 22:41, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

deprecate monobook: WP:BEANS! Suffusion of Yellow (talk) 22:33, 26 June 2019 (UTC) (discussiontools-replybutton)[(discussiontools-replylink)]

"Deprecate" would be too strong a word, but the end of official support for MonoBook was announced about half a dozen years ago.[7] Whatamidoing (WMF) (talk) 06:31, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I suppose I can put that code in my own css file, but I'd prefer that talk page link not to work over the wide screen space. I use trackpad shortcuts to move backward and forward through browser tab history a lot on Wikipedia. Having all the space to the right pretty much disallows moving forward in the history via that shortcut. Killiondude (talk) 22:35, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

If someone can come up with another hack for it that doesn't break things I'll happily force it back out there. — xaosflux ^Talk 22:42, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

If somehow this breaks the fundraising banner Seddon (WMF) is working on I bet it will get immediate attention...ijs... — xaosflux ^Talk 22:43, 26 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

For any of my over-the-top complaining on this, some of it is frustration - but I really would like to thank Catrope for their continuing efforts to resolve this. Last update, the width problem is fixed, but now there is an alignment issue with the areas to click (you have to click a little further to the left then you used to right now) - this is already reported to phab. — xaosflux ^Talk 03:46, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Ah, I was wondering about that. I was trying to get to my userpage from the link at the top, and kept getting info about notifications... Risker (talk) 04:16, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Related xkcd. The initial "fix" that caused this seems to be very problematic. Can we not revert back and make a proper, tested patch instead of applying these small hacks repeatedly? —RainFall 05:15, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hi all. I don't know if this is related, but I can't click on the link to my talkpage from the very top bar, it always goes to my notifications. This is in Firefox. Lugnuts ^{Fire Walk with Me} 06:29, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Lugnuts: the 'talk link' problem should be fixed now (at least in monobook). If you are still seeing it in monobook can you gather some more details: hover over "log out" and look at what the link would be, then slowly move your mouse to the left (over contribus/wl/pref/ etc..) and see if you get sandbox, then your talk link. If it is out of alignment let us know? The link to the "user page" is somewhat overlapping with notifications (See above) but should work if you approach it from its left edge. — xaosflux ^Talk 14:27, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks Xaosflux, that seems to be OK now. Lugnuts ^{Fire Walk with Me} 14:29, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I've just noticed that "Notices" now fills up most of the space between "DuncanHill" and "Talk", and "Alerts" partially overlaps "DuncanHill". I don't generally notice them unless I actually have an alert or a notice, as I use the blackscreen gadget and the words "Notices" and "Alerts" helpfully display in black text on a black background. Since these recent changes they have started shewing up in orange (like the other links at the top) but only when I point my mouse at them. DuncanHill (talk) 15:08, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Xaosflux: This fixes all the overlap issues for me, in FF67/Linux:

#pt-notifications-notice .mw-echo-notifications-badge, #pt-notifications-alert .mw-echo-notifications-badge {
	text-align: left;
}

I don't know why; I was just trying things at random. Might be worth trying in some other browsers. Suffusion of Yellow (talk) 21:33, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This code fixes all the things for me. :) Before inserting this, I couldn't access "alerts" (the bell) only "notifications" (the inbox icon). Killiondude (talk) 22:00, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I noted it at phab:T226594 to see if there will be an upstream fix before we start band-aiding again. — xaosflux ^Talk 22:18, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Suffusion of Yellow: That stops the overlap, but the text stays black when I point at it. Could someone thank and/or/ping me so I can see what it looks like then? Thanks, DuncanHill (talk) 22:24, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

User:DuncanHill, you annoy.---Sluzzelin talk 22:26, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks both, thanks and pings seem to shew up well and be clickable. Someday I'll get around to mentioning the incompatibility with the blackscreen gadget. I have to highlight the notification to read who it's from. But that's been like that for ever. DuncanHill (talk) 22:28, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@DuncanHill: Ideally, that should go in Special:MyPage/monobook.css instead of Special:MyPage/common.css, not I think it will make a big difference. Suffusion of Yellow (talk) 22:34, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks again, have moved it over. Seems to be much the same effect. DuncanHill (talk) 22:40, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Message & notification icons in Modern skin

The message & notification icons in the modern skin seem to have been changed to something less than ideal. Any recent changes to the stylesheet that would have made this happen? FWIW browser is latest version of Firefox (67.0.4). Nthep (talk) 14:52, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Nthep: - so in summary - there is a bunch going on and this is coming from upstream not local styles. See phab:T226684 (and some of the discussion at phab:T226594) to catch up on the goings-on. — xaosflux ^Talk 14:57, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks. Nthep (talk) 15:10, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Nthep: Same as the monobook issues, should be fully fixed at the end of the week/next week depending on how they're doing deployments. Unless you don't like how we fixed it once it does change, in which case do please tell me. -— Isarra ༆ 15:55, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Someone has broken Thanks

Now when I thank someone, instead of it happening all in the history page, it takes me to another page to ask me if I want to thank them, then to yet another page saying I have thanked them, and leaves me there and not where I was to start with and with no apparent way back. I expect it's an "improvement", but it makes life harder. DuncanHill (talk) 20:53, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@DuncanHill: Works normally for me. What you are describing is the expected behavior if you have JavaScript disabled. It is possible that the JS for the "thanks" feature didn't load properly. Try WP:BYPASS, and see if it works again. Suffusion of Yellow (talk) 20:58, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

 Works for me - but the servers were just also having some hiccups, can you try again? — xaosflux ^Talk 20:59, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I've been having intermittent weirdness of another type. On "Show preview", I've been getting a message that the servers are busy. If I refresh, it works fine. But the error has repeated numerous times today. I've been wondering if it's the new version of MediaWiki that Tech News mentioned would be on all wikis as of today. — Maile (talk) 21:00, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

(ec)I went back and in the page history it did not shew me as having thanked the person I had thanked. I tried again, nothing happened, then tried again and it behaved normally. I think there's a log somewhere where I can see if it went through, but can't remember where. DuncanHill (talk) 21:03, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hah! I found the thanks log, it's shewing me as having made the first thanks before I posted here, but not the second when I tried again. DuncanHill (talk) 21:06, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This is not about thanks (I think), but I got first one, then two notifications today for apparently nothing. I mean, there's a little red "2" in the usual place, but when I look there's nothing new there. I think the second one may have been for AGK's mention of me here, since it turned up right as I was reading his motion, but I've no idea what the first one is. Anybody know what's going on? If an arb offers a motion to examine my conduct, and has as far as he knows pinged me about it, it would be nice to get that ping. Can I go somewhere to find it? Bishonen | talk 21:20, 27 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

There's a Thanks log at this link. I don't think there's a ping log. People shouldn't rely on pings as 1) they don't always work at the best of times, 2) it's very rarely the best of times, and 3) I think you can turn notifications off. DuncanHill (talk) 21:26, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

There was a recent problem with notification (at least in Monobook) see here (look above), but I don't know whether there's a connection. I will henceforth thank and revert and ping users profusely and see how they react. ---Sluzzelin talk 21:27, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Duncan, you better stop thanking me, or I will report you to ... ---Sluzzelin talk 21:31, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

(edit conflict) (edit conflict) (edit conflict) I use Monobook, Sluzzelin, I'm old school. You know what? I just realized that the little notifications digit — the red one — shows the thanks I've got, just like the blue digit does. So, I get thanks twice, and notifications never. Bishonen | talk 21:32, 27 June 2019 (UTC).(discussiontools-replybutton)[(discussiontools-replylink)]

You can get a complete list of current and past notifications at Special:Notifications (which, frustratingly, works much better with javascript disabled). Doesn't help you realize there's new ones there if the main notice is broken, though. —Cryptic 21:57, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Sluzzelin: Wilco! DuncanHill (talk) 21:34, 27 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Bishonen, this happened to me (also a Monobook user) when someone replied to me in a topic which was archived in the time between their reply and when I saw the notification. Ever since then, whenever I go to a wiki project for the first time, there's a red number for notifications, even when there are none (because the default preference is to show cross-wiki notifications). On the bright side, I can always tell if it's my first visit to a project. BlackcurrantTea (talk) 07:48, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@BlackcurrantTea:, my problem was solved by a kindly techy type in a thread above. I don't know if the same magic would help you, but it's probably worth trying. Bishonen | talk 08:06, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Bishonen, thanks for the tip. That doesn't make a difference in my case, but it's not really a problem. BlackcurrantTea (talk) 08:36, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Stuck alert/notification

At the top of every Wikipedia page I open are my control tabs: Username, Alerts, Notifications, Talk, Sandbox, Preferences, Beta, Watchlist, Contributions, Log out.

There is a red number over my Alerts tab, and the tab isn't working. When I click on it, it shows all the Notifications, as does the Notifications tab.

I can't get rid of that red number. It has worked fine until today. Help! -- BullRangifer (talk) 03:19, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@BullRangifer: do you use Monobook for your skin? If so, see #Excessive width on monobook and specifically the last bit of code given that you can put into your css file to fix what the devs broke in the skin. Killiondude (talk) 03:23, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Still a problem. -- BullRangifer (talk) 06:53, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@BullRangifer: The problem is that although the bell and TV set icons are still links, their hotspots have shifted to the left by about their own width plus a bit more. So the TV set's hotspot is now where the bell is displayed. Therefore, to activate the bell, you click a little to its left - just over the letters "fer" should do it. --Redrose64 🌹 (talk) 11:05, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Several patches for this were worked on and hopefully it will be fixed very soon! — xaosflux ^Talk 11:07, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Redrose64:, you're right! That's exactly what's happened. When will this be fixed? -- BullRangifer (talk) 14:18, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@BullRangifer: My "fix" (developed using the tried-and-true XKCD method) should work, but you need to put it in your monobook.css, not your monobook.js. Isarra has submitted a patch which should fix this on all wikis, but it hasn't been reviewed yet and I don't know how long it will take to be merged. Suffusion of Yellow (talk) 17:45, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I don't have that subpage, but I'll create it and give it a try there. Thanks. -- BullRangifer (talk) 20:11, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

That worked instantly! -- BullRangifer (talk) 20:14, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I've worked out why the hotspots are overwide and overlapping. Whilst looking at DuncanHill's (unrelated) Blackskin problem with that gadget enabled, I happened to hover over the alerts icons - and behold! the text links "Alerts (1)" or "Notices (1)" become visible. It is those textual items that are invisibly appearing in front of the desired links. So to get the bell's link, you need to be to the left of the "N" of "Notices (1)". --Redrose64 🌹 (talk) 19:12, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

It'll be actually fixed here by the end of the week, or next week. Probably. Patch is merged; this is just the last place to get fixes when people aren't wildly swatting everything like lemurs. Mmm, lemurs. -— Isarra ༆ 15:50, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• @Suffusion of Yellow: I'm trying your css hack at testwiki:MainPage, it should be live in a few mins - just as another stopgap until the phab ticket is resolved - feel free to go look for bugs there before it gets promoted locally here. — xaosflux ^Talk 20:19, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm being over-notified.

Somebody rid me of those dang notifications, which won't go away. GoodDay (talk) 20:49, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@GoodDay: Are you using the MonoBook skin? If so, please visit the test wiki, WP:BYPASS your cache, and see if everything works as expected over there. Suffusion of Yellow (talk) 21:08, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I went to my All notifications & 'unread' them. It seems to have worked. GoodDay (talk) 22:05, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hack added to monobook.css

I'm adding Suffusion of Yellow's hack to MediaWiki:monobook.css for now - revert if it causes trouble. — xaosflux ^Talk 22:33, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Working for me, at least. Suffusion of Yellow (talk) 22:46, 28 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Deployment update

Thanks to User:Isarra's efforts on Friday, we now have full fixes for the notification badge issues in the Monobook and Modern skins. About 15 minutes ago (at 23:36 UTC) I deployed the fixes for Monobook, these are now live on all wikis. I didn't deploy the fixes for Modern because those are a little more complicated and that skin isn't used as much as Monobook is. If I get a chance, I may be able to deploy those 24 hours from now, and otherwise they'll come with next week's regular weekly deployment train on Thursday July 11 (there is no train this week due to the July 4th holiday). Thanks to User:Isarra for writing proper fixes for these bugs, and to User:Xaosflux for putting interim fixes in MediaWiki:Monobook.css in the meantime. And, again, my apologies for this disruption; I was the reviewer on the change that broke this, and I should have caught the fact that it changed the badge structure and the main badge CSS but did not update the Monobook CSS to match. --Roan Kattouw (WMF) (talk) 00:02, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Or there needs to be a setting in preferences to allow this. Scrolling is a pain. Half the page has to be scrolled to click the "show preview" button.

Weird thing is that the edit window here does not have the "Edit summary (Briefly describe your changes)" toolbar. It only has the "common edit summaries" toolbar.

So look at an article edit window, or an article talk page edit window. -- Timeshifter (talk) 08:34, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

If you begin editing by using the "new section" tab, then no, you don't get an edit summary window. Instead, a standard edit summary is constructed for you, consisting of the name of the new section wrapped in /* ... */ markers plus the words "new section". The edit summary window only appears when editing an existing section, or the whole page. --Redrose64 🌹 (talk) 16:25, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks, Redrose64. I see now. -- Timeshifter (talk) 08:42, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Edit window length is not remembered

A related problem is that the wikitext edit window length is not remembered. I can drag it up or down in length. But when I open another article or talk page, and then open an edit window, it is back to being a very lengthy edit window.

This exacerbates the previous problem of the "Publish changes" toolbar being separated by almost half a page of edit summary and terms of use stuff.

Lots of scrolling to do multiple previews. I am using Firefox on a 21-inch LCD monitor. --Timeshifter (talk) 08:24, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This in your CSS sets the edit box height:

textarea {height:15em}

User:Js/ajaxPreview#Installation adds a small preview button above the edit box. It makes other changes. PrimeHunter (talk) 09:59, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Or you can use alt+shift+p to preview. Galobtter (pingó mió) 10:14, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks, PrimeHunter. I installed both, and they both work great. They both should be preferences. -- Timeshifter (talk) 08:38, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Timeshifter: It has previously been suggested (see e.g. this thread)) that a setting such as the above rule textarea {height:15em} should be made a user pref. Unfortunately, this is not feasible since a value of 15em is not suitable for every user - we do not know how high anybody else's screen is. --Redrose64 🌹 (talk) 18:30, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Redrose64: Thanks. I see from that old thread that it was possible in the past to choose the size of the textarea. I vaguely remember that this existed at one time. You wrote in that old thread: "Each pref removed marginally improves page load time for logged-in users." Is it only prefs that are changed from default settings that effect page load time? If so, then the more preferences the better.

There should be a way to open up and activate a whole new set of preferences. That way newbs could start with a manageable set of preferences. Then over time, if desired, then people could look at other preferences. Without having to paste stuff into CSS and JS pages. People could make their own decision as to whether the marginal loss of page load speed was made up for by the improvements provided by the additional preferences. -- Timeshifter (talk) 02:53, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I wrote a query regarding CSD category counts being incorrect and SoWhy helpfully pointed me to archived threads on this board, like Category count wrong and several others with the same complaint going back to spring 2018. Editors responded by listing Phab tickets, like T200402, T195397, T221795 or T18036 (and there are probably more). I've checked all the different tickets that were mentioned in these threads on this common problem and they are either marked as a) closed, resolved, b) closed, duplicate or c) low priority. I don't see how this issue can be considered resolved when it continues to be a problem and it is disappointing to think that there is little to no chance that anyone will work on actually solving this problem. It's clear that a lot of work on this started last year, but then the ticket was mistakenly closed as resolved.

Is there any way to restart the process of review so that there is some investigation of this problem? Because as a "resolved, low priority" task, that means to me that it will never be examined again. Liz ^{Read! Talk!} 23:35, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

In Phabricator parlance "low priority" does not necessarily means the task is not important; quite the opposite at times. Phab:T195397 was closed as resolved because it was indeed resolved at the time, and when the problem resurfaces, it was not reopened since there are many other open tasks. Some were closed as duplicate, because they were what the label says; even here, I believe we don't like 'duplicate.' The main task now is at phab:T221795.

However, (for me to not be too evasive) I admit the problem is not given any sense of urgency from the technical side, but that's easily explainable. To be frank, there's nothing broken if category count is not correct. The problem has been noticed since 2008 or possibly earlier, and with adhoc fixes, everyone moves on until it returns and annoys another person. It's something obscure and which almost entire Wikipedia readers probably don't use nor care about. The editors who care for it (the count) are few, and even fewer know the problem exists. I don't know any way to speed up this, except (may be) to lobby the team working on it in the task, but keeping in mind, even if you think it needs immediate solution, others may not see it that way. – Ammarpad (talk) 06:37, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hi all,

I happened to notice that hundreds of links in hundreds of articles include fbclid=longstringofrandomlookingletters parameters. According to what I read, Facebook adds these to track users' browsing behavior. It works like this:

• Let's assume I discover something on www.example.com/cooltopic.html and share this URL with a friend on Facebook: "HEY CHEK THIS OUT!!!!!!!11"
• Facebook automatically adds a unique FaceBook CLick ID (fbclid) to every link that is passed through them by adding &fbclid=... or ?fbclid=... to it. This doesn't change the destination of the link i.e. the URL still works the same.
• The friend decides to add my URL as a reference/link to Wikipedia. Except, now the URL will read www.example.com/cooltopic.html?fbclid=xyz123.
• Thanks to their Click ID Facebook can now track the URL: If the link is emailed to a 3rd person, who sends it to a 4th via Whatsapp, Facebook recognizes the (modified) link as the one I originally shared with my friend, thus gathering data about which persons are communicating with whom.
• If the destination site of the link (example.com) has added a like-button to their page then Facebook even gets notified whenever anyone follows the link, i.e. they will know exactly which visits to www.example.com are a consequence of my original communication with my friend. (They use this to find out who is a valuable influencer.)

Long story short, IMHO all fbclid=... should be deleted from all (current and future) references and links on Wikipedia, because

• Facebook has no business tracking Wikipedia contributors or readers.
• The huge fbclid=... strings make references harder to read and edit.
• The fact that an Wikipedia article's reference's URL was passed through Facebook's infrastructure earlier is not relevant to the topic the article covers, so this information need not be preserved.
• The links work just the same after deleting the fbclid parameter.

So it would be great if some Wikipedia wizard could program and unleash a bot for this? Please?? Supposedly there are also Google Click IDs and others, however I haven't found their 'additions' in links. Maybe there is already a bot in place filtering them out? Then this bot would just need a little expanding.

I hope this is the right place to ask. Someone at the Teahouse was kind enough to point me here.

Thanks and regards, Jens (84.173.225.148 (talk) 20:27, 30 June 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

I believe there's a bot that's removing them already, though in a gradual way as there's no immediate harm while they're here. I think the bot is also removing them not only from Facebook's URLs but similar ones from Amazon.com and the like. – Ammarpad (talk) 20:35, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Yup, Wikipedia:Bots/Requests for approval/KolbertBot 4 was approved for this, but may be stalled/paused right now. User:Jon Kolbert is the operator, who may have more information. — xaosflux ^Talk 20:39, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Template:Cite web#URL says "Remove tracking parameters from URLs". insource:fbclid currently gives me 1720 results in articles. The normal place for a request would be Wikipedia:Bot requests. PrimeHunter (talk) 20:42, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

(edit conflict) Hi Jens, looks like User:KolbertBot per Wikipedia:Bots/Requests for approval/KolbertBot 4 should be removing it, but the bot isn't running; ping Jon Kolbert. Galobtter (pingó mió) 20:44, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'll talk to him. Many thanks to all of you. --Jens (84.173.225.148 (talk) 21:14, 30 June 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

Jens, thank you for bringing this to our attention! While we wait for him, I have begun (slowly) manually removing a lot of these trackers, if anyone wants to help, please do! TheAwesomeHwyh 22:59, 30 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

There are 1700 pages, many of which will have several affected links (the article where this issue came to my attention has 8 of them). While I admire your diligence, I do think it's best to let the bot handle this. Please consider that doing such tedious work manually is very error-prone, if you accidentally remove a bit too little or too much the link won't work any more. Best regards, Jens (84.173.225.148 (talk) 23:54, 30 June 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

Ah- I'm not planning on doing them all, just however many I can get to today (also, I check all the links before I upload), but yeah this is definitely something that's best suited for a bot once that gets running again. TheAwesomeHwyh 00:07, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hi there, I have been very occupied with a lot of other things - but I will make sure this task runs :-). Thanks for the note Jon Kolbert (talk) 18:14, 2 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Many thanks for your work. --Jens (84.173.228.245 (talk) 21:11, 3 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

It is easy to see that | is a permissible character to the right of the active | in a piped link. For example, [[red|green|blue]] produces the anchor text "green|blue" linking to the page red: green|blue.

In the lead sentence of the page Xiquets Copenhagen, however, the wikitext ([[Castell|{{lang|ca|castells}}]]) is obviously intended to produce the anchor text "castells" linking to the page Castell; but actually it does not produce a link at all, and most of the wikitext shows up as ordinary text in the article. If this is supposed to work as intended, perhaps someone can fix the bug. If it's intended not to work, perhaps someone can edit the article to do what is necessary to achieve the desired effect.

(If you have something to say, please say it here. I only came across the article via Special:Random, and don't expect to look at it again.) --76.69.117.113 (talk) 04:06, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Fixed The problem is that {{lang}} not only marks the text as non-English, it also adds [[Category:Articles containing ...-language text]] - and wikilinks may not contain wikilinks. -- John of Reading (talk) 06:23, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Ah, so it's intended not to work. Perhaps it would be helpful if there was some kind of error message, because the original construction looks legitimate until you know why not. --76.69.117.113 (talk) 02:57, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I would like to have both toolbars. Please make this possible. See: Wikipedia:Legacy toolbar.

See: Special:Preferences#mw-prefsection-editing. There one can enable this:

• Enable the editing toolbar. This is sometimes called the '2010 wikitext editor'.

I can't enable it because I have the 2006 editing toolbar (plus extensions) enabled:

I have the following 3 gadgets enabled in the editing section of gadget preferences:

• Enable the legacy (2006) editing toolbar. This will be overridden by the "Enable the editing toolbar" option in the Editing tab.
• refToolbar: add a "cite" button to the editing toolbar for quick addition of commonly used citation templates
• Add extra buttons to the old (non-enhanced) editing toolbar

They just add more buttons to the 2006 editing toolbar. -- Timeshifter (talk) 09:36, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Anybody? Is this technically feasible? -- Timeshifter (talk) 02:56, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

No, it is not possible to have both the 2010 and 2006 toolbar. You could however ask for an script that adds the missing buttons to the 2010 toolbar, which would be the hidden comment, quote and horizontal line.--Snaevar (talk) 16:53, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

That's a good idea. I only want the 2 buttons for instant link brackets (no intermediary popup). One button for an internal link. And one button for an external link. -- Timeshifter (talk) 05:20, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

 You are invited to join the discussion at Wikipedia:Teahouse#Two questions about the WMF's Android app . Airbornemihir (talk) 04:32, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

VVVV I've posted the question asked by Airbornemihir in its own section directly below this section. VVV Orville^talk 05:28, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Two questions about the WMF's Android app

The following questions have been copied from the Teahouse. The editor below has technical questions we are unable to answer there, and I'm hoping editors here can provide Airbornemihir with assistance. Orville^talk 05:21, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
I'm aware that it's a good practice to leave edit summaries, but I'm nonetheless curious about the official Android app apparently preventing an edit from going through if the edit summary is left blank. Is this an intended limitation of the app, or is there something I'm missing?

Tangentially related question: the list of Wikipedia mobile applications states that the Android app cannot open talk pages, but this doesn't seem to be true of the current version of the app which can open any page when looked up with the correct namespace. Is that something that should be updated? (Please ping when replying.) Airbornemihir (talk) 03:22, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

The above questions have been copied from the Teahouse. The editor above has technical questions we are unable to answer there, and I'm hoping knowledgeable editors here can provide Airbornemihir with assistance. Thank you Orville^talk 05:21, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Airbornemihir: Uhm, are you sure you are using the latest version? I just published this edit without an edit summary using the official Wikipedia app for Android. Also, the app is technically able to show talk pages, but it treats them as "normal" articles. I think the article (List of Wikipedia mobile applications) is referring to the "View talk page" option placed at the bottom of every page—including talk pages... yep—which the app doesn't yet "handle." —RainFall 07:27, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@RainFall: Thanks, I've noticed too that talk page links open by default in a different app, which is probably the intended meaning as you said. Regarding blank edit summaries, do you not get stuck during the edit at the place where it asks "How did you improve the article?" I can't seem to move on from there without either picking one of the canned edit summaries or writing one myself. Airbornemihir (talk) 07:46, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Airbornemihir: Yes, I did see the "How did you improve the article?" page; I tapped "Publish" leaving everything else untouched and it worked... again. —RainFall 07:52, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@RainFall: OK, it looks like it worked for me too. I'm not sure what was going on before. I edited the smartphone apps page to better reflect what the app can do, as well. Thanks everyone for your help. Airbornemihir (talk) 08:08, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Resolved

Moved from Wikipedia:Village pump (miscellaneous)/Archive 62 § Has syntax highlighting CSS just changed?: ―Mandruss ☎ 21:58, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I just noticed that the gap between lines in "Syntax highlighting" mode in the wikitext editor suddenly became wider. Was it a glitch of my browser not loading CSS properly, or did it actually change? —⁠andrybak (talk) 21:37, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Andrebak: can you be a bit more specific, Wikipedia:Syntax highlighting doesn't usually get used in .css pages, which use the code editor (not the source editor). Is this still occurring? Can you share the edit link you are using? — xaosflux ^Talk 22:28, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I guess andrybak was not editing a CSS page but just speculating that styling from some CSS file was not working properly when editing a normal wikitext page. If you refer to the highlighter marker button to the left of "Advanced" in a toolbar then it doesn't change spacing for me in Google Chrome 75.0.3770.100. PrimeHunter (talk) 09:43, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@PrimeHunter: Yes, but for me it has changed in the same mode ( turned on), but between different pages. It changed between two different gap sizes since then, so I think that it was just some networking issue when loading CSS. —⁠andrybak (talk) 10:12, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

A user (Console.frog) noted that when searching for "life on earth" on Google, the Life article appears in the middle of page 1 under the title life on Earth. This expression appears several times in the article but I can't figure out why the correct title is not brought up, and more importantly why "life" is not capitalized properly. Do you think there is something on our side causing this? -- Luk ^talk 11:27, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

A datapoint: "life on Earth" appears four times in the preamble, "Life on Earth" appears once in the preamble. —⁠andrybak (talk) 11:59, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

linksto:Life insource:"life|life on earth" finds many articles saying [[life|life on Earth]]. Maybe Google prefers to display this link text when it matches the search. PrimeHunter (talk) 12:01, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Situation confirmed; here's what I see with a US IP:

life on Earth - Wikipedia
https://en.wikipedia.org/wiki/Life
Evidence suggests that life on Earth has existed for at least 3.5 billion years, with the oldest physical traces of life dating back 3.7 billion years; however, some theories, such as the Late Heavy Bombardment theory, suggest that life on Earth may have started even earlier, as early as 4.1–4.4 billion years ago, and ...
Evolutionary history of life · ‎Timeline of the evolutionary ... · ‎Earliest known life forms

I'm using Internet Explorer, if that matters at all (or even if it doesn't). Nyttend backup (talk) 13:02, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Is there a bot or tool that can replace the phrase Kingdom of Hawaii to Hawaiian Kingdom across Wikipedia without having to edit each page and switch it over? This is just a logistical inquiry before a request for consensus for such a change. KAVEBEAR (talk) 21:01, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

AWB can do this. It shows up 54 pages, so it should be quite feasible, with about 10 seconds per page to allow manual check it could take 10 minutes. Graeme Bartlett (talk) 23:07, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This is not so much a VPT matter as a question for WP:BOTREQ - and I see that an identical thread has been posted at WT:BOTREQ, contrary to WP:MULTI. --Redrose64 🌹 (talk) 23:09, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

To answer the technical question KAVEBEAR, no - assuming this phrase appears in the source text it would require creating another version of the source text for each page (which yes a bot could do, but that is how it would do it). The only way around that would have been if the name was actually a template that could be changed once. — xaosflux ^Talk 13:19, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Not sure if this is the correct venue but the tooltip (hovertext) that logged-out readers see for Antananarivo stampede is stuck on an old incorrect version with the wrong date. This has been repeatedly pointed out at main-page errors but no one there knows how to fix it. The article was corrected on 28 June [8]. Any help appreciated as this is currently on the main page in the In the News section. Espresso Addict (talk) 23:34, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Espresso Addict: It's not just that one page. In fact, I'm not sure that the preview has updated for any page since June 28. See phab:T227033. Suffusion of Yellow (talk) 23:48, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thanks. At least someone is hopefully looking into the issue. Espresso Addict (talk) 23:52, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Resolved

Why isn't {{Google maps}} displaying the access date in, for example, the first ref at Bussell Highway? The use of accessdate in the article seems fine ... and I'm not that good with templates. Thanks for any help! Graham87 14:02, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Fixed the parameter as told in the documentation of the template. Stryn (talk) 14:18, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Ta muchly ... oops, didn't notice the underline there! One of the perils of not paying attention to punctuation with my screen reader ... but seemingly an easy mistake to make, whether you're sighted or not! Graham87 14:47, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I hope this is an appropriate place to describe this concern. If not, please advise me where to express it. On my laptop I'd like to be able to set desktop to be my wikipedia preference, so it would be my permanent default view, and mobile view never come up on it. I am using Firefox 67.0.4 (64-bit) browser on Windows 8.1. The problem I encounter is that when using my laptop computer and searching for something via google, sometimes when I click on a wiki search-find I get a presentation of a wiki article which I have discovered to be a MOBILE wiki presentation, which I don't want. I now finally understand that I can go to the bottom of such an article and click on 'desktop', and I'll get a desktop view, and that setting will also obtain for other wiki articles until I turn my laptop off. But the next time I turn my laptop on, mobile views can again present from google searches, and I have no use for mobile style views. I would think desktop view should be able to be set in Preferences. If that can't be made available in Preferences, is there some other way that I could set DESKTOP to be my wikipedia permanent default view? UnderEducatedGeezer (talk) 23:22, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

As far as I know, Wikipedia can't automatically switch you from the mobile view to the desktop view. If you're on a phone, and go to the desktop version (en.wikipedia.org), you can be switched to the mobile version (en.m.wikipedia.org), but the other way around doesn't work. Therefore, if you click on a link from somewhere else on the internet to the mobile version (en.m.wikipedia.org), you stay on the mobile version. The easiest way to change this is to remove the .m from the URL. rchard2scout (talk) 10:13, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

That does not work. Trying to remove ".m" without using the appropriate option will redirect you back to the mobile view. The opposite is not true and from the desktop view (without the ".m") accessing the mobile view by simply adding .m is possible. Now, the easiest way to flip the views is to go to the footer of the page and click "Desktop view" or "Mobile view" as you want it. It's cookied, so it sticks for a while, but once the cookie expires, it will reset back to mobile view (if on mobile) and desktop view (if on desktop). Note that these options are incompatible with browser-provided "Enable desktop view" options and will not work on Wikipedia. --qedk (t 桜 c) 12:25, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

"It's cookied, so it sticks for a while" is a key bug for me. I made that explicit "Desktop view" setting because I wanted it that way, and it might be a pretty long page I have to scroll through to get to the bottom to (re)change it. My request is that either the cookie have a much longer expiration or that it can be handled by a site (rather than browser) pref. DMacks (talk) 16:47, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

You can make a JS script and add it to your MySkin.js, all you need to do is detect the current URL and if it contains, ".m" and go to the URL + "&mobileaction=toggle_view_desktop", essentially forcing the desktop view. --qedk (t 桜 c) 17:20, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

That doesn't quite match my experience: for me, just removing the m. is all it takes. On a desktop, that is. But if someone drops a link from the mobile site (like in a diff) and you click on it, then you get the mobile version. I like the script idea. Ivanvector (^Talk/_Edits) 17:27, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Yep, if the default view is desktop (as in, how the page first loads), that is how it will work, but instead if your default view is mobile, it will not work. --qedk (t 桜 c) 18:36, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I have a bookmark on my mobile phone that does not have the m. It sometimes takes me to the mobile site, and then I can click the Desktop-site link at the bottom of the page to switch to desktop mode. From then on, for a while, the bookmark takes me to Desktop. But then sometimes it (that same bookmark, with no m) reverts to mobile mode, and I have to click Desktop-site switch it, and then it will again stay that way but only for a while. DMacks (talk) 18:53, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

That's how it works for me too. Not a bookmark, but any wikipedia URL I try to load will initially (if I haven't clicked the Desktop link in some time) automatically redirect to the mobile page. Then clicking on the Desktop link will keep me in desktop mode for ... some time, two weeks or a month or so, unless I click on another mobile URL. This is the case whether I check the "always request desktop version" setting in my mobile browser. Above, I was referring only to desktop behaviour, and I have no idea about setting "default view", I didn't know that was a thing. Ivanvector (^Talk/_Edits) 18:58, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@DMacks: Try bookmarking "https://en.wikipedia.org/w/index.php?title=Main_Page&mobileaction=toggle_view_desktop" and using that. --qedk (t 桜 c) 19:07, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• I often edit from my phone, but dislike the mobile view because it does not show all items on the page (specifically templates) and the incompatiblity with user scripts (none work). Therefore, I wish for pages to always display in desktop view. Senator2029 “Talk” 10:55, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• I often edit on my tablet, and occasionally for no apparent reason it will go to mobile view. This can happen even if I am currently looking at a page in desktop view and click a link on the page. It's very annoying. As DMacks said, sometimes it's a long page and not that easy to scroll to the bottom of the page. I'd love to have a preference (or even a js hack) that would disable mobile view while I'm logged in regardless of what device or browser I'm using. older ≠ wiser 19:04, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• @DMacks, Ivanvector, Bkonrad, and Senator2029: Hey guys, so I hacked together a script since a lot of you said it was an issue, which should work, {{subst:lusc|User:QEDK/forcedesktop.js}}. Just paste this into your Special:MyPage/common.js and it should work. I've tried it on my mobile (Android 8.1, Chrome 75) and Desktop (Windows 10, Firefox 67) and it works alright. If you run into any issues, I can try to fix it, but my focus is on AI/ML which is kinda far from web development, but I will surely try to fix it. Hope I could help. Also please note, if the script works ideally, you will not be able to access the mobile site at all, until you remove the script (and purge your cache). --qedk (t 桜 c) 08:57, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

There is some interesting chatter on a related topic at phab:T214998. --Izno (talk) 15:42, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Resolved: Thanks for pointing out the post above; closing this due to derpiness –Deacon Vorbis (carbon • videos) 21:29, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

The page preview for final item (as I'm writing this) on the "In the News" list on the main page (the Antananarivo stampede) mentions it occurred on 26 July, despite the article (correctly) saying it was 26 June. Looking at mw:Page Previews, it just says it uses a portion of the opening paragraph, so I have no idea what's causing the discrepancy. Does anyone know why this is happening and/or how to fix this? Thanks, –Deacon Vorbis (carbon • videos) 20:50, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

User:Deacon Vorbis, see #Stuck tooltips above. Over at Phabricator, it has an "Unbreak Now!" status, which means "drop everything you're doing and fix this". Nyttend (talk) 21:21, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Currently, one of the most backlogged processes is Request an Account (ACC) , which exists mainly (though not entirely) for helping with 3 purposes: Those having trouble completing CAPTCHA; enabling the choosing of a username that is too similar to an existing username under certain circumstances & creating an account for those hindered by a rangeblock.

The current backlog on pending requests is 4 months.

In the last couple of months multiple editors have signed up to be ACC tool users, Tool users are signed up to the confidentiality agreement and meet various other criteria.

Currently here are limits, however, on both their ability to create accounts. Two options could ease their work.

1. Raise the local account creation rate limit from 4 to 10. The new limit only to extended-confirmed users to prevent any abusive behaviour from IPs.
2. Automatically grant account creator permission, on request, to new ACC tool users. This would allow them both to bypass the limit entirely, but would also let them ignore the antispoof and title blacklist when making accounts.

Pinging all participants in the local chat discussion: @Ajraddatz, FlightTime, Xaosflux, TheSandDoctor, AfroThundr, QEDK, and Oshwah: Nosebagbear (talk) 13:11, 14 June 2019 (UTC) (discussiontools-replybutton)[(discussiontools-replylink)]

• NOTE: Option 2 is broader than Option 1, however they do not completely overlap. Option 1 would allow any EC-confirmed editor to create up to 10 accounts per IP address, option 2 is specifically targeted at ACC-users. Thus participants can !vote for either/both/none of the options.

Survey: Account creator rights

• Support for option 1 only. Speaking as an ACC administrator, I believe that automatically granting all new ACC tool users the account creator user right (option 2) would open the door for new tool users to potentially handle requests incorrectly and without limitations before it's caught and identified - which would not be a good thing at all. We need to have a limit for how many accounts that new tool users can create per day by default. When a tool user shows proficiency with handling requests correctly, they can apply for and (after approval by an ACC admin via a comment made to the request) be granted the account creator flag in order to remove those limits. Option 2 would remove the need for an ACC tool administrator to give their approval before an admin can grant the user rights to the requesting user. This approval is still necessary and absolutely needed. Raising the current limit of 4 creations per day to 10 creations per day would loosen the restrictions so that users can help take care of the current backlog of requests at ACC, while still being on a set limit during the time that they're learning and demonstrating their knowledge and proficiency with ACC tool user interface. This option is the best way to resolve the concerns expressed. :-) ~Oshwah~^{(talk) (contribs)} 13:25, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Support for option 1; encourage ACC admins to quickly work with new ACC volunteers to get them trained and empowered with additional flags as soon as feasible. — xaosflux ^Talk 13:43, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Support option 1 Per above. Also, as all rights on Wikipedia are, it is granted on the basis of need for the right, inherent oppose for point 2. --qedk (t 桜 c) 13:59, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Support option 1 as per my comment in the previous discussion. I also agree with Oshwah on automatically granting new users the ACC bit. The current method of granting the right after a couple weeks of activity allows the team to gauge the user's performance and whether or not they have learned the policies and procedures properly. Lowering the barrier further could lead to a problematic user potentially causing a lot more damage (no rate-limit, anti-spoof override, username title blacklist override) than they otherwise could if we had to manually grant those rights. On the other hand, when all is in order, granting them the right is usually quick and painless anyway. — AfroThundr ^{(u · t · c)} 14:04, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Support alternate option where an group named Account creation helper is formed, which would contain only the noratelimit right.--Snaevar (talk) 14:38, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I appreciate the idea, but I just don't see how this implementation would be useful here, or how it would resolve any issues that the account creator flag wouldn't already resolve. If an ACC admin user can trust an ACC tool user enough to have no account creation limit, that admin user should also trust the tool user enough to be able to correctly and properly handle requests that tripped the antispoof extension and require a flagged user to override (and vice versa). ~Oshwah~^{(talk) (contribs)} 14:45, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• Support 1. After thinking about this a bit more, I'm not sure if tying the rate limit to extendedconfirmed would be possible. If not, I still think we should raise the limit, but maybe to 6 like it was before instead. The limit was lowered mainly for projects without 300 active local sysops who couldn't instantly respond to mass account creation. -- Ajraddatz (talk) 15:16, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Rights like PMR have increased limits for certain flags (in that case, page moves), this would just mean adding a flag like that to EC right holders. --qedk (t 桜 c) 15:23, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Yes, most ratelimits are determined on a per-account basis (or per IP for anonymous users). But I seem to remember account creations being different, and being specifically tied to the IP. I assume/hope that a defined higher ratelimit for extendedconfirmed would override that. And no need to tie it to a specific permission; it can be done for the group itself. -- Ajraddatz (talk) 22:58, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Yep, but that's a non-issue as far as devs are concerned. Delving into the issue of newer technical changes, from my experience talking to people on SRE/Deployment (and Anomie, TheDJ), technically unfeasible things are pretty rare and I have not seen requests getting turned down (rarely, if ever) with "MediaWiki does not support this", if it's a feature change, or some irreproducible bug, it's a different thing but for example, during the RfC for Template editor rights, a lot of people were worried about the tecnical changes but eventually it was done, with no big deal at all. That's how it is for most new things (and TE rights had a new protection level as well), so I would say a change would be technically feasible until a dev says exactly otherwise. --qedk (t 桜 c) 07:50, 16 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  With dev time almost anything is possible; my concern would be if the current software doesn't support the change, then we should be looking at easier options like raising the max number to 6 / IP as it used to be. Adding a new protection level is easy to do through the software. Fundamentally changing the account creation throttle might be more difficult. But agreed that we should ask rather than muse about things we know little about :-) -- Ajraddatz (talk) 01:03, 18 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• (ACC admin comment) I'm pretty sure option 1 isn't possible without development, i.e. it is not a simple configuration change. AFAICT, IP account creation limits can only be set as a count per interval with the noratelimit right being the only way for a user to bypass that limit. (mw:Manual:$wgAccountCreationThrottle) Oppose option 2 for the reasons outlined by Oshwah. Support returning the daily IP limit to 6 unless the Security Team​​ provides a good reason that it needs to remain at 4. — JJMC89 (T·C) 05:50, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  The Security Team doesn't have a problem with bumping the IP limit from 4 to 6 or even 10, as originally proposed. SBassett (WMF) (talk) 21:32, 21 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @SBassett (WMF): thanks for the note, is this really something we need to worry about at a per-project level then? — xaosflux ^Talk 21:52, 21 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @Xaosflux: - see my response to JJMC89 starting here: https://phabricator.wikimedia.org/T212667#5274787. SBassett (WMF) (talk) 12:39, 22 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @JJMC89:, @Xaosflux: - just following up here, the account creation throttle revert was deployed today. SBassett (WMF) (talk) 21:47, 24 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• Comment. My preference would be to at least be granted access to the tool. I've waited for a week or so now. :/ –MJL ‐Talk‐^☖ 16:04, 18 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Oppose I think 6 is the highest we should go with general limits on account creation per IP. Given that changing IP is rather trivial, the higher we go the greater the risk of abuse. If we raised the limit from 4 to 10, and a bad actor switches from their laptop to their cellular data network when they hit a limit, that is an additional 12 accounts they would be able to create. I think 4 was fine, 6 is okay, but anything higher I am not in favor of. I am not in support of option 2 for the reasons above. Wugapodes [t^hɑk] [ˈkan.ˌʧɹɪbz] 19:05, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Support option 1 I'm not sure what option 2 is, so I can't support it. Option 1 seems fine, though. I think we should prioritize clearing up the backlog, though. Invalid^OS (talk) 23:13, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Discussion: Account creator rights

• @Nosebagbear: regarding your proposed options, and since this is VPT, can you explain the specific technical changes you are proposing - or is this more of a "let some developer figure it out" type of request? Is the "automatic" granting you are asking some sort of technical change you are proposing, or is it a procedural/policy change? — xaosflux ^Talk 13:24, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Xaosflux - If option 1 were to reach consensus, it would be corrected by filing a phab ticket to have this done. See phab:T212667. ~Oshwah~^{(talk) (contribs)} 13:27, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Thanks. — xaosflux ^Talk 13:29, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  (edit conflict) @Xaosflux: - changing the rate limit is obviously possible. Whether it can be changed "in bands" to different protection levels is, I'm afraid, I query for those more technically savvy than me. If they say that's impossible (or akin), then this would need to be rethought. Nosebagbear (talk) 13:29, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• For the problem that is trying to be solved - is overriding anti-spoof the normal resolution, or is getting them to pick a new username? — xaosflux ^Talk 13:25, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Xaosflux - For instances where similar usernames exist and are caught by anti-spoof, it depends. See this section of the ACC guide for the policy on when ACC tool users with the account creator flag can override the antispoof flag and proceed with creation. ~Oshwah~^{(talk) (contribs)} 13:30, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @Oshwah: thanks, option 1 above won't fix the antispoof ones, is that a significant part of the backlog? Just asking so we don't spend time getting something done that won't help. — xaosflux ^Talk 13:33, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Xaosflux - No. Requests that have tripped the anti-spoof extension make approximately 3.5% of all total requests at this time. Of those, users without the account creator flag can still see if the similar accounts are active, and decline the request if any of them are. The only time that a request requires a user with the account creator flag is when a request trips the antispoof extension and the similar accounts are all inactive. This means that the antispoof needs to be overridden, the request approved, and the account created. ~Oshwah~^{(talk) (contribs)} 13:37, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• Why not grant Wikipedia:Event coordinator to new members of ACC? EVC will give them ability to bypass 4 account limit and it also doesn't allow overriding antispoof/title ban restrictions. ‐‐1997kB (talk) 16:36, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  1997kB - Not a bad thought, but event coordinators can set new accounts as 'confirmed' using Special:UserRights, which is an ability that they don't need. Essentially, we'd be trading apples and oranges here if the concern is over access to some user rights they shouldn't have. As I said above, I believe that if an ACC admin can trust an ACC user to create accounts with no limit, they should also trust them to properly handle requests that tripped the antispoof extension and require a user with the account creator permissions to override and create (and vice versa). :-) ~Oshwah~^{(talk) (contribs)} 16:42, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @Oshwah: - I realise I agree with you, but to run with the Event-Coordinator compromise theory a bit further, it would be clearer cut - the damage possible is pretty tiny. Even if they made every account they created confirmed, it wouldn't cause a great uptick in carnage. Nosebagbear (talk) 22:36, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Fair point. ~Oshwah~^{(talk) (contribs)} 02:31, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  @Oshwah: what is the expected amount of accounts to be created by "new" ACC volunteers per period? (i.e. would 6 or 8 be enough?) since the "rights they don't need" here to ECC users is expected to be way more than is needed by the relatively minuscule ACC team. — xaosflux ^Talk 16:59, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  Xaosflux - Honestly, any increase from 4 would be beneficial. Even if the increase is just by a few... :-) ~Oshwah~^{(talk) (contribs)} 17:41, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

New bot

I think we should have a bot or some kind of tool check for accounts which are hitting the account creation limit but do not hold the rights event coordinator, account creator and are also not ACC tool users. The account creation limit was lowered for a reason and increasing it without keeping a check in place would be a gross violation of WP:BEANS imo. Thoughts, @Nosebagbear, JJMC89, Xaosflux, and Oshwah:? --qedk (t 桜 c) 14:19, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

A recurring database report may be able to solve this for you. — xaosflux ^Talk 14:27, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

If this is a major issue, the report would have to be run quite frequently, and viewed frequently by patrolling users. Otherwise, this method might not be effective enough at stopping abuse and quickly enough... ~Oshwah~^{(talk) (contribs)} 14:30, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

(edit conflict) QEDK - Doesn't sound like a bad idea to me. How would this new bot alert others that an account is hitting a limit and isn't within one of those groups? Who would this bot alert? Where? This is something that we should figure out if we're going to consider an idea like this... :-) ~Oshwah~^{(talk) (contribs)} 14:29, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

It can function the same way AnomieBot handles WP:TPERTABLE, there's no annoying notifications involved and interested people can simply watch the page and report when they find anyone suspect. --qedk (t 桜 c) 14:33, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

QEDK - Nice... I like it. :-) ~Oshwah~^{(talk) (contribs)} 14:36, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Functionally, a bot wouldn't be able to work "that way". Also, bot's wont be able to see "that you got denied by the limit" , but a bot could periodically generate a report of "accounts created per user over some time period" and could either filter out members of certain groups or just report the groups as well. — xaosflux ^Talk 14:38, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Why not? The logic is pretty simple, you would need to check creation logs iterating a certain period (maybe an hour) and track accounts which create another account for 24 hours at minimum and more if they somehow meet the limit each day (hence, suspect). Wikipedia accounts which do not have a similarly authorized account in ACC (or the other account creation rights as well) have demonstrably no reason to carry out actions like this, hence red-flagging them almost immediately. --qedk (t 桜 c) 14:49, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

A bot could create a report, technically it won't be able to tell if you actually got stopped by the limit, just that you hit it or approached it. It wouldn't work "the way" of the protected edit requests in that those don't mine logs, they make use of what links here/category memberships. But the output could still be made. Have a bot periodically (say hourly) ingest the user account creation log and make a report. I think it may even be helpful to have it report on everyone, or everyone with say 3+ creations - and also to identify accounts made by coordinators, etc - so they can be coached as needed. — xaosflux ^Talk 14:54, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Yeah, I mean, technically not. But I'm saying it like the logic is clear that an account cannot make more than 10, so an account which makes 10 accounts can be construed to have hit the limit, what's important is identifying if anyone is trying to make a large number of accounts in a short period of time, hitting the actual limit is more of a formality. --qedk (t 桜 c) 15:06, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Something like quarry:query/36938? It can't tell if they're an ACC tool user, obviously. If this query is correct, there's not a whole lot of ACC activity going on. — MusikAnimal ^talk 19:46, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@MusikAnimal: thanks for the query, even including everyone with 3+ creations over the last whole 10 days (quarry:query/36941). I haven't checked their groups, but the impact here seems to be very small. — xaosflux ^Talk 20:07, 14 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Almost all ACC users in that 10+ range, minus the one event coordinator. Unfortunately I won't be appearing in that query anytime soon due to a certain rangeblock with "account creation disabled" set. Really puts a damper on ACC work... — AfroThundr ^{(u · t · c)} 01:51, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@AfroThundr3007730: - I thought individual accounts could be exempted from rangeblocks? If so then ACC tool users would be a priority Nosebagbear (talk) 14:32, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@AfroThundr3007730: this is a known issue, even effects admins: phab:T189362. — xaosflux ^Talk 15:16, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Nosebagbear: Besides IPBE, I'm not aware of any (current) facility to exempt an individual user from the effects of a rangeblock, at least not the account creation part.

@Xaosflux: - thanks, suspect it was one of those merging of facts I got while swinging around the policy pages. Clearly, I'd made a terrible nerd Nosebagbear (talk)

@Xaosflux: Yep, definitely tracking that one, and if they do get around to implementing it, I would be first in line to request IPBE so I can get back to helping in ACC. — AfroThundr ^{(u · t · c)} 18:37, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Could use an abusefilter for this - something along the lines of Special:AbuseFilter/527. Galobtter (pingó mió) 15:33, 15 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Event Coordinator Rights

The idea of granting (permanent) Event Co-ordinator rights to any ACC tool user who didn't possess Account Creator rights was mooted as a compromise. The right waives the account creation limit, and also allows accounts to be made confirmed. Obviously the latter isn't needed, but as I noted above, even if a tool-user went rogue, the maximum potential damage is significantly smaller (than the additional rights of Account Creator). It makes a good halfway house between nothing and Account Creator, and if Option 1 turns out to be inviable, then it might be the only way to significantly help with their task. Nosebagbear (talk) 18:46, 17 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• Oppose The event co-ordinator right will allow the ACC team to grant confirmed right to new users. And the new users will start to create articles in the mainspace, which will cause more damage. Masum Reza^📞 10:20, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]
• Oppose We (ACC tool admins) want new ACCers to be rate limited, so that we can easily monitor adherence to the ACC Guide. — JJMC89 (T·C) 17:29, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Back to 6 per day

So, the prior "temporary" reduction has been lifted and the setting is back to 6 accounts per day for all projects; that being said is anything really needed now? I think that it is reasonable for volunteers working with the ACC team to get account creator access after a short warm-up/training period - and having the team communicate the plan to new members and getting those swiftly processed (say within a fortnight of actively working with ACC) is a good thing. — xaosflux ^Talk 13:16, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I haven't personally noticed any issues with ACC members requesting and getting the bit granted — after they have demonstrated continuous good judgment for a few weeks, that is. I still think it might make sense to raise the limit to 10 for enwiki, being the largest userbase, and with that query and edit filter from above, we can continue to monitor non-ACC users with high creation rates. — AfroThundr ^{(u · t · c)} 15:49, 25 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• Comments: I am new to this, support account creation, and was appalled at the backlog. A note that 2-3 days may be needed, may take weeks or even months, and a backlog of 4 months seems to point to a possible loss of good editors at worse, those legitimately seeking an account to lose interest or maybe just not actively seeking an account. Maybe I am looking at this wrong but a backlog of 4 months seems to indicate "is anything really needed now?" a strange question. I understand the need to limit account creation abuse and possible vandalism, but if what is in place seems to be a horrible failure then why not an increase to maybe the 10 suggested instead of back to the statue-quo? I haven't looked at this, just read over some of the above, but has there been a problem with "trusted user" abuse to cause the decrease in the first place? Otr500 (talk) 08:55, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

  The backlog doesn't have anything to do with the rate limit. Almost everyone working at ACC has noratelimit (from accountcreator or sysop), so the limit doesn't apply to them. The backlog is from a shortage of volunteers willing to devote time to working at ACC. — JJMC89 (T·C) 17:28, 29 June 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

• If it's back up to 6, then I don't think further changes are needed. New volunteers can get the accountcreator bit once they have a bit of experience. The biggest issue is number of volunteers. -- Ajraddatz (talk) 01:11, 1 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

WP:ANI#Unknown attack on me contains some {{IPvandal}} links to individual IPv4s, individual IPv6s, and IPv6 ranges. Here are three of them, plus a totally unrelated IPv4 range:

• 81.152.162.119 (talk · contribs · deleted contribs · filter log · WHOIS · RDNS · RBLs · http · block user · block log)
• 148.20.57.8/29 (talk · contribs · deleted contribs · filter log · WHOIS · RDNS · RBLs · block user · block log)
• 2001:D08:182A:4FB9:1:1:F6CC:4548 (talk · contribs · (/64) · deleted contribs · filter log · WHOIS · RBLs · http · block user · block log)
• 2001:d08:1a03:c3cc::0/64 (talk · contribs · deleted contribs · filter log · WHOIS · RBLs · block user · block log)

You'll see that the template doesn't do well with some of the range code. Is there a way we could fix this, either by instructing the template to drop the "http" link if it's not a simple IP, or by otherwise rearranging something? Nyttend (talk) 20:13, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This will prevent the "http" link from appearing if the input is neither a IPv4 nor IPv6, although it might be a bit kludgey. Nardog (talk) 20:39, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Thank you. Would you advise that I seek to gain consensus before copying your new code into the module, or should I just go ahead and make the change immediately? Nyttend (talk) 21:26, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm not sure either. Let's ask Mr. Stradivarius and Anomie, who are responsible for the module. Also there might be a better way to prevent it than return ''. Nardog (talk) 21:38, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Seems sensible to me. Anomie⚔ 01:07, 7 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Seems that "Global User Contributions" (at => https://tools.wmflabs.org/guc/?by=date&user=Drbogdan , for instance) once gave truly "total contribution results", but now seems limited to "20 results per wiki"? - QUESTION: is there a way to again obtain truly "total contribution results" with this wiki tool (or some other related one) - and *Not* be so limited (to some number of results per wiki)? - in any case - Enjoy! :) Drbogdan (talk) 00:52, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Drbogdan, Hey, at least it's working now (it was down for a while). There is an alternate tool at https://xtools.wmflabs.org/globalcontribs which may work better for you. --AntiCompositeNumber (talk) 01:21, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

AntiCompositeNumber - Thank you for your reply - and suggestion - the newly suggested counter seems limited to english and english-related wikis - and not wikis from other countries as the https://tools.wmflabs.org/guc/?by=date&user=Drbogdan counter seemed to be - at least at one time - hopefully, the old counter will be back up - and work like it seemed to at one time - in any case - Thanks again for your reply - and - Enjoy! :) Drbogdan (talk) 01:39, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Drbogdan: It's not limited to English wikis, rather it's just listing global edits chronologically. If you paginate through you'll find edits you made elsewhere, e.g. here are your edits from before July: https://xtools.wmflabs.org/globalcontribs/Drbogdan/all//2019-07-01.

FYI there is still some database maintenance going on, so both GUC and XTools may experience occasional slowness. — MusikAnimal ^talk 02:26, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

This tool will also give you your total edit count by wiki. bd2412 T 01:40, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Hello. @Drbogdan: the GUC tool was down at the beginning of June, then it has been repaired with Phabricator:T224930, with the limitation that you have seen. But in the Phabricator task, Krinkle said "I'm gonna land the patch now, although it only works for recent changes right now. Not for "All contributions". [...] I'll fix that in a separate change, but closing this for now." so I am convinced that, after the next fix, GUC will show again the "total contributions count" (for all projects) and the "project contributions count" (for each project). Regards --NicoScribe (talk) 21:59, 4 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Drbogdan: The GUC tool has always limited the number of results from a single wiki to 20. This has been the case since the tool's creation by Luxo for Toolserver in 2014. However, there are two things that did change since 2014:

1. In May 2018 (last year), I added the text "20 results per wiki" so as to reduce confusion for users not aware of this previously (phab:T167524).
2. In June 2019 (last month), I switched the default grouping logic from "per wiki" to "per day" (chronological globally, instead of per-wiki). This has not made any change to which results are shown, merely in which way they are grouped. Both grouping options are still available as before, and can be selected in the form, or by url. This was requested by several users (phab:T193896).

As always, if you are interested in seeing more results from a specific wiki, use the "contribs" link next to the user name to continue for more results (which links to Special:Contributions on the relevant wiki).

Regarding the "global edit count" (as a number, not the list of actual edits), this can be better retrieved from Special:CentralAuth.

--Krinkle (talk) 17:57, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Krinkle: Thank you for your reply - and comments - yes - using "https://en.wikipedia.org/wiki/Special:CentralAuth/Drbogdan", my total counts is currently 69,212 - however - for some reason - seems, until somewhat recently, my total counts with "https://tools.wmflabs.org/guc/?user=Drbogdan" were almost always about 1000 counts more (should be, with the earlier program-tool, about 70,200+/?) - an example => based on an old copy (June 2018) of my User:Drbogdan Wiki-Page - at => "https://web.archive.org/web/20180622155402/https://en.wikipedia.org/wiki/User:Drbogdan" - in the right-hand userboxes (down the middle of the page) - the total counts at that time were noted as 59,000 (using "https://en.wikipedia.org/wiki/Special:CentralAuth/Drbogdan") and 60,000 (using "https://tools.wmflabs.org/guc/?user=Drbogdan") - perhaps I was misreading/misunderstanding something in some way? - or perhaps - something changed in the meanwhile? - in any case - Thanks again for your reply - and - Enjoy! :) Drbogdan (talk) 18:51, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Krinkle:

• When writing my message above, I knew about "20 results shown per wiki". That's why I focused my message on something else: the "total contributions count" (for all projects) and the "project contributions count" (for each project). These 2 types of count are necessary (for me) to follow several long-term cross-wiki abusers. When you wrote "I'm gonna land the patch now, although it only works for recent changes right now. Not for "All contributions". [...] I'll fix that in a separate change, but closing this for now." in the Phabricator task, you were not talking about these 2 types of count?
• CentralAuth is great for many uses but is unable to show the "project contributions count" and the list of recent edits side to side (for each project). GUC was able to do that, before. Moreover CentralAuth does not work for IP users.

@Drbogdan: CentralAuth considers the deleted edits and ignores the imported edits, whereas GUC ignores the deleted edits and considers the imported edits. For instance:

• Special:CentralAuth/Drbogdan says that you have 5 edits on it.wikipedia.org, but it:Speciale:Contributi/Drbogdan lists 4 edits → one of your edits has been deleted.
• Special:CentralAuth/Drbogdan says that you have 6 edits on en.wikibooks.org, but b:Special:Contributions/Drbogdan lists 43 edits → 37 of your edits (done in other projects) have been imported here (and GUC shows your 20 recent edits, imported or not).
• Special:CentralAuth/Drbogdan says that you have 31 edits on de.wikipedia.org, but de:Spezial:Beiträge/Drbogdan lists 987 edits → 956 of your edits (done in other projects) have been imported here (and GUC shows your 20 recent edits, imported or not).

37 + 956 = almost 1000: it explains the difference between your old GUC "total contributions count" and your CentralAuth total count. --NicoScribe (talk) 17:39, 7 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

In the mobile view, <small>..</small> has no effect on the size of the displayed font. This appears to be implemented in the different style sheets used in mobile view. I assume this was a deliberate design decision – perhaps it was thought that making already potentially small font on a mobile device even smaller wasn't a good idea.

Up until February 2018, {{small}} was a wrapper for <small>..</small>. It was then changed to be a wrapper for <span style="font-size:85%;">..</span>. This is obeyed in mobile view, so does generate smaller text.

If it was a deliberate decision not to display smaller text in mobile view, then the change to {{small}} should be undone. Comments, please. Peter coxhead (talk) 12:50, 8 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

When I'm looking to see what a user has been up to, looking at their contributions page is usually way to verbose, because it shows every edit. What I usually want is to just see the distinct pages. In pseudo-sql, I want something like, "select distinct page_name from contributions". Is such a thing possible, short of using Quarry?

Even better, a way to do this for both contributions and deleted contributions and fold the results together into a single list of distinct pages. -- RoySmith (talk) 14:29, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Sounds like the same idea as the "Group changes by page in recent changes and watchlist" option in Special:Preferences#mw-prefsection-rc, but that does not seem to affect Special:Contributions lists. DMacks (talk) 14:38, 5 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@RoySmith: It is not sorted chronologically, but maybe XTools' Top Edits would help? For example [9]. This intentionally does not reveal deleted contributions. — MusikAnimal ^talk 17:21, 8 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

20:12, 8 July 2019 (UTC)

Wikipedia:WikiProject Women in Red is looking for someone who'd be prepared to run a bot, the owner of which has recently retired. The bot is described at d:Wikidata:Requests for permissions/Bot/Emijrpbot 6, which points to code here. The function of the bot is to add new wikidata items for new en.wiki biographies and/or to add human and/or gender statements to existing wikidata items, based on articles found on Special:UnconnectedPages. WiR bases all of its metrics (& these) on wikidata records for en.wiki articles, and since end April the project's stats have become increasingly hard to compile. We'd be more than grateful if someone would consider picking up this thankless task; thx. --Tagishsimon (talk) 17:33, 3 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Tagishsimon: if you haven't already, try WP:BOTREQ Headbomb {t · c · p · b} 05:16, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Resolved

--qedk (t 桜 c) 07:05, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I'm not sure what the best venue is to ask this question, but I was at Wikipedia:Welcoming committee/members and in these edits, I purged a bunch of sock operators, some unregistered users, a bunch of redlinked users who hadn't edited in forever, and without looking at the rest of the list, I can only wonder how many people there are actually active. Is there any technical way to purge the list of duds? I also noticed there were tons of green-linked names, which typically represents users who have changed their handles.

Side question: I remember tweaking a setting that turned redirect links green (see above) but I can't remember where it was. I looked through my prefs and common.js file and can't find it. Help? Cyphoidbomb (talk) 02:35, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Cyphoidbomb: Try this: User:Anomie/linkclassifier. To use only the redirect green color, copy User:Anomie/linkclassifier.css to your .css and comment out the ones you don't need. --qedk (t 桜 c) 04:35, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Cyphoidbomb and QEDK: Better yet, install User:BrandonXLF/GreenRedirects. 10/10 user script for that. –MJL ‐Talk‐^☖ 05:41, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@QEDK and MJL: I'll gladly install whatever anybody strongly recommends. Since the redirects already show up as green for me, I was trying to figure out what I already clicked in my prefs/gadgets/whatever, so if anybody has any idea, please let me know. Also, I'm still curious about purging the Welcoming committee members page, although it's a low priority on account of it being an indiscriminate user list. Cyphoidbomb (talk) 06:46, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

[Thank you for the ping] Cyphoidbomb, you're a real treat. lol –MJL ‐Talk‐^☖ 06:51, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@MJL: You are awesome. I can't keep track of the various common files and most of my changes have been to common.js, so I am much appreciative for your sleuthing. I come to the tech board so I don't have to walk in circles aimlessly like an asshole. Thanks, mate. Cyphoidbomb (talk) 06:57, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

...so I don't have to walk in circles aimlessly like an asshole. But that's all I do on Wikipedia! Glad to hear you resolved it. --qedk (t 桜 c) 07:05, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Cyphoidbomb: It was nothing! It was just a quick check of your subpages. As for the pruning, I'm afraid I don't know much that could be of service. Maybe a bot to clerk the list would be of service, but I am not the one to program such machinations. Cheers! (edit conflict) –MJL ‐Talk‐^☖ 07:05, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

User:Cyphoidbomb and User:MJL, you might consider using the Wikipedia:WikiProject X tools, which come with a bot to archive inactive members. User:Harej can probably point you in the right direction if you get stuck. Whatamidoing (WMF) (talk) 21:02, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

I was trying to log out one day but the step was slow. It said, "You are being logged out, please wait". Then it said, "Cannot log out now: http". Eventually I was logged out. Why so long? Does it mean that I must have been using a slow network? If I close my browser while waiting, is that good enough? Nick Levinson (talk) 20:26, 6 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

You say 'one day' and you were eventually logged out, that means the issue may no longer be there. Have you tried logging out again to see if the issue persists up to now?. – Ammarpad (talk) 05:12, 7 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Preventing a logout is a security concern, thus I asked, even if it doesn't repeat for me. I agree the issue may be gone but it may not be, which is why I said "one day" and then posted. It did not recur on another day but that doesn't mean it was resolved. I think I had another well-known site open under my login during the same session; if so, I had no problem logging out from there. I assume the two strings I quoted (minus "http") can be searched for in MediaWiki software or the Wikipedia implementation to find what causes them to display, but I can't do those searches and I don't know how to test for recurrence of the problem, because if the cause was network slowness I don't know how to slow a network that I don't control and most networks I use are likely fairly robust.

Does the problem come from network slowness or something else? If anything was done to resolve it, that's different and please tell us.

Nick Levinson (talk) 23:39, 8 July 2019 (UTC) (Corrections: 23:46, 8 July 2019 (UTC))(discussiontools-replybutton)[(discussiontools-replylink)]

@Nick Levinson: I've filed a task at phab:T227621 for it to be looked at. Thanks for reporting. Quiddity (WMF) (talk) 21:52, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Can someone with the right permissions null edit the fully locked page User:NQ/nqup.css (the user hasn't edited for 2 & 1/2 years) so as to clear the redirect Category:Potentially illegible userboxes? This one is causing strange errors for the redirect bot. Timrollpickering (Talk) 14:24, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Wow that page is a mess, looking at it. — xaosflux ^Talk 14:53, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

 Done @Timrollpickering: should be good now, is using the 'fake css' permission hack to make a protected user page. — xaosflux ^Talk 14:56, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

It's cleared - thanks. Timrollpickering (Talk) 15:03, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Rather than null edit it, it should be nullified - there isn't a single valid CSS rule in the whole thing. --Redrose64 🌹 (talk) 19:44, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Redrose64: it is a self-protection hack used by non-admins (c.f. Wikipedia:User_pages#Protection_of_user_pages). — xaosflux ^Talk 22:16, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Why do we encourage this? --Redrose64 🌹 (talk) 22:34, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

What is the correct syntax to set the inline parameter conditionally in this template? It is embedded in the London Overground article thus: {{Overground RDT|inline=yes}}, which should be able to set the inline to 1 or true. The aim is to hide the top bar of the template when embedded in an infobox but not elsewhere.

I attempted this but it didn't work, so clearly I'm not getting the conditional syntax right:

|<includeonly>|inline={{#if: {{{inline|}}}|1|0}}</includeonly>

What's the correct way of doing it? Thanks. — Preceding unsigned comment added by Cnbrb (talk • contribs) 20:38, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

@Cnbrb: You're overcomplicating it. Just do this that way you can use {{Overground RDT|inline=1}}. BTW the documentation for {{Routemap}} shows |inline=1 but |inline=yes might work, I'm no Lua expert. --Redrose64 🌹 (talk) 22:32, 9 July 2019 (UTC)(discussiontools-replybutton)[(discussiontools-replylink)]

Ah! Someone has stepped in and fixed it. The answer was (of course) obvious: