Wikipedia:Village pump (technical)

Jump to navigation Jump to search
 Policy Technical Proposals Idea lab Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bug reports and feature requests should be made in Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Frequently asked questions (FAQ) (see also: Wikipedia:FAQ/Technical)
Click "[show]" next to each point to see more details.
If something looks wrong, purge the server's cache, then bypass your browser's cache.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English), and for logged in users there is a gadget available in your preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you have problems making your fancy signature work, check Wikipedia:How to fix your signature.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
For server or network status, please see Wikimedia Metrics.
« Archives, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178


I'm looking for some advice, or maybe a sanity-check, and I pick you all. :-)

Editors have asked the Editing team, for multiple years and specifically during the big consultation about talk pages last year, to enable visual editing on talk pages. Here at the English Wikipedia, there's Template:VEFriendly, which lets people use it. You can also edit the URL to achieve the same goal, at least if your prefs are set to show two editing tabs in the mainspace. (I'm not sure it works under all the prefs options.) But you can't use it "officially".

The Editing team has never been very enthusiastic about the idea. There are a variety of reasons for this, and the one that is most relevant to my question for you is parsing.

Right now, generally speaking, if I screw up the wikitext in one section, then the next section has a chance of being okay. For example, imagine that I add a table in one section, but I forget to close the table. You edit the next section. While pages with these kinds of problems would end up at Special:LintErrors, and (in this case) it will look strange, you can click the [Edit section] button in any subsequent section and add your comment without being affected by my errors (although everything else on the page might still display strangely after you edit the page).

If you edit the page in the visual mode, however, it'll try to repair the damage my incorrect wikitext caused (in this case, by automagically adding the wikitext code to close the table at the very end of the entire page,[1] which is where the parsers [now] say the table actually ends). That's not too bad, but in other cases, you might not like the results. I think that in the worst-case scenario, it could reprocess the entire page as a single string. The only practical solution would be undoing your edit and trying again from your favorite wikitext editor, and maybe cleaning up the wikitext error while you're at it.

What I'd like to know from you all is:

  • In your experience, how often do you suppose serious wikitext errors appear on talk pages? Accidentally unescaped wikitext or template fragments turns up on this page at least occasionally. What about other talk pages?
  • Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? Is it more like a minor thing, or more like a serious problem?

Two further points for context:

  1. Even if you all agreed that this was only a tiny annoyance and would almost never happen, the Editing team still might think that full-on visual editing of talk pages is a bad idea. The parsing problem has never been their primary reason for refusing these repeated requests. Telling me that it's fine doesn't mean that anything will change.
  2. The old parser will probably be removed next year. In about a year, Parsoid (which is what the visual editor depends upon) will be used for parsing all edits, no matter what editing system you're using. I understand that this means that the problem of unescaped invalid/unbalanced wikitext is going to affect talk pages anyway. Sometimes I think that maybe a little visual editing would get some these problems identified and cleaned up bit by bit before the switch, and other times I think that I'd rather postpone the inevitable as long as possible.

(Pinging User:Izno, who put a lot of hours into solving problems during the previous round of parser changes.) Whatamidoing (WMF) (talk) 02:04, 10 January 2020 (UTC)

I am not up to date on what VE does at the moment but in the past I have seen it refactor text that presumably was not the target of the edit, say by normalizing template parameters. If there is any chance of that happening, enabling VE on talk would not be desirable. Some people are very sensitive about their comments and certainly would not want them changed as a side effect of another person adding a comment. Johnuniq (talk) 02:37, 10 January 2020 (UTC)
As someone who frequently cleans up article-space problems caused by the beta Visual Editor, my primary concern about enabling it in more spaces is that WMF's developers have not been as responsive as I would hope to bug reports about VE. See, for example, T133874, T162291 (almost three years old), T174303 (2.5 years old), T219627 (almost one year old), T209493 (over a year old, possibly fixed soon), T113717 (over 4 years old), and T143453 (3.5 years old). And those are just from the list of phabricator tasks I am following. I know that the developers are always working on all sorts of stuff, but I find it hard to understand why a beta editing tool that has had some very basic bugs in a stale state for many years would be expanded to a namespace where it will likely cause significant trouble.
I am not enough of a Wikimedia insider to understand the difference between VE and Parsoid, but with respect to "In about a year, Parsoid ... will be used for parsing all edits", if that means that some of the above bugs will spread to all edits, not just to VE edits, I think that there may have to be some serious bug-squashing between now and then if you want to avoid a big blow-up. – Jonesey95 (talk) 03:24, 10 January 2020 (UTC)
VE style doesn't match with wikitext styling, and this can be confusing. For example fire up this page in ve now (link here) and go look at the "How to challenge the decision to remove support for insecure browsers?" section. VE is very unforgiving about mixed list styles that we use for indents and it makes it look like a mess with huge chunks of whitespace. If I was editing there, what should I do there - try to clean it up and it just gets even worse. — xaosflux Talk 03:27, 10 January 2020 (UTC)
Even this section has tons of extra white space in the VE viewing mode, or whatever that link is, and I don't think our indenting is out of the ordinary. If that is what talk pages look like in VE, that seems like a show-stopper. – Jonesey95 (talk) 03:53, 10 January 2020 (UTC)
The extra whitespace is partly caused by the single stray : in the middle of your ::-level previous comment. If the aesthetic experience were the main concern, the people who didn't like it just wouldn't use it. Whatamidoing (WMF) (talk) 20:22, 10 January 2020 (UTC)

My best guesses about the effects of some known bugs:

  • phab:T133874 would only apply if you edited (probably including cut-and-paste rearranging) a template that had previously been added in the non-standard order. That shouldn't be a typical activity on the talk page, and the usual reason to care about the order of the parameters (aside from dirty diffing) is to talk about it, in which case it'd be escaped (and therefore left alone) anyway.
  • phab:T162291 prevents a few links; if you paste content that triggers this bug, you'd see instead of phab:T219627, about getting unnecessary nowiki tags on ISBNs, is similar in its end effect.
  • phab:T174303 doesn't feel important for talk pages, even though it's annoying in articles. Also, the Parsoid-everywhere thing might magically solve that (also phab:T113717 and the old one about people actually copying little blue clicky numbers and thinking that they're copying the whole citation template).
  • phab:T143453 is about people using citoid to generate citation templates (which doesn't happen much on talk pages) and then not checking the content, even though VisualEditor automatically previews the citation before letting the editor move on. But it doesn't corrupt the rest of the page (at least no more than would happen if someone typed that in wikitext now), and as a technical matter, it's not clear to me whether the citoid service ought to be sanitizing input that might look like templates or character formatting, or if the CS1 modules ought to do that.
  • phab:T209493 should be solved soon, and might be another one problem that magically goes away with phab:T54091.

My overall impression is that while some of these are annoying, none of them destroy the whole page. The occasional weird list construction sounds riskier to me. It's one thing to have your own edit go awry; that's what the edit source button is for. It's another thing if your quick comment corrupts the whole page. So I'm putting better support for definition lists on my list, but so far, nobody seems concerned about a high volume of the whole-page disasters that we saw back in the day. Whatamidoing (WMF) (talk) 21:17, 10 January 2020 (UTC)

I am concerned about making a change through VisualEditor that can trigger a change to be made to other sections. An obvious disaster will hopefully be noticed, though a surprising number of editors seem not to look at the results of their edits, based on errors that get left behind. Anything other than an obvious total page breakdown can be easily missed as editors won't be reviewing the entire page for changes. Reverting and trying again is pretty annoying given there is no guarantee that it won't happen again. An experienced editor might realize that a wikitext error has to be fixed, but even so, tracking a bug down is a huge pain. isaacl (talk) 22:14, 10 January 2020 (UTC)
I don't think the bugs I listed above will break whole pages; my words were in response to Whatamidoing (WMF)'s question: Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? My point was (supposed to be) that volunteer WP editors have reported many bugs in VE that cause annoyance and work (many more hours of work than it will take to fix the bugs), and that should not be hard for developers to fix, but those bugs have languished. I worry that similar annoying talk-page VE bugs (not at the page-breaking level, but at the annoying gnome-work level), will similarly languish because they are "minor" or because editors should check their edits before saving, or some other fairy tale. – Jonesey95 (talk) 00:24, 11 January 2020 (UTC)
I was responding to the issues raised in the original post, and following up the message which stated far, nobody seems concerned about a high volume of whole-page disasters that we saw back in the day.. isaacl (talk) 07:00, 11 January 2020 (UTC)
Some changes to the rest of the page are trivial enough that they won't be worth reverting, and some might be helpful, but I'd rather not see any page completely broken. Whatamidoing (WMF) (talk) 00:17, 14 January 2020 (UTC)
Oof, too much credit to me. Anomalocaris probably has spent much more time than I have on linting and probably has a better handle on the first question. I will answer some of the request from what I have observed. (Aside, I will be along to the couple fun Phabricator discussions occurring about a related topic... sometime in the next few days.)

In your experience, how often do you suppose serious wikitext errors appear on talk pages? Accidentally unescaped wikitext or template fragments turns up on this page at least occasionally. What about other talk pages?

Besides misnested font/styled span HTML elements? Rarely.

Where does having to revert and try again (or cleaning up someone else's mess) fall on the annoyance scale? Is it more like a minor thing, or more like a serious problem?

If the problem is systemic (i.e. a script, or bot, or MediaWiki, WP:LISTGAP and related, [or someone's signature]), the most annoying. The occasional typo or missing end tag, not a big deal. If the error is massive, it may prevent users from leaving comments on talk pages, which would be the worst end of the deal, or lead to biting.

The old parser will probably be removed next year.

Parsoid's not ready to handle talk pages or complicated (template) wikitext. (Read mode is okay, but I've seen enough edit mode problems that would prevent saving otherwise-fine wikitext.) Talk pages might get there with the talk project, but I am skeptical about that schedule being valid for all other pages within a year.
--Izno (talk) 01:10, 13 January 2020 (UTC)
So I think I'm going to file the overall response under "lukewarm": we'd expect the occasional breakage, but it's probably not a disaster. I think the team's overall feeling is lukewarm-ish, too, so absent a real push from other wikis, I'm not expecting this to be prioritized. Whatamidoing (WMF) (talk) 00:17, 14 January 2020 (UTC)

@Whatamidoing (WMF): Back in November I ran a Bot run over about 2,400 pages for the MilHist Project. For each page both the article page and talk page had to be parsed. The Bot reported failures whenever it struck a syntax error on a page. These were almost always an unclosed link or template. Some 11 errors were reported on article pages (0.4% error rate) and 46 (1.9%) on talk pages. Thus talk pages were five times as likely to have syntax errors on them despite being much smaller in general. The annoyance level was high because the errors can be really hard to spot, even with Bot assistance. Hawkeye7 (discuss) 01:14, 14 January 2020 (UTC)

Hawkeye7, we're off on a bit of a tangent, but those percentages are not surprising, since articles are watched much more closely and fixed by projects like CheckWiki and various reports, and we have rules against messing with other people's contributions to talk pages. Also, talk pages are not the face of Wikipedia to the world, so errors are less of a problem. – Jonesey95 (talk) 03:24, 14 January 2020 (UTC)
Now I really want to know more about your project. I can't imagine why someone would need a bot to parse a couple thousand pages.
If there's approximately a 2% error rate, presumably declining over time (as fiddly bits are found and fixed), then that's not too common (a new editor has a 98% chance of being okay), but still common enough to trip me up about once or twice a week (because I spent a lot more time on talk pages than the typical newbie. The median number of talk page edits during the first week after the first edit appears to be zero).
I think I'd live with this error rate to get, say, better odds that the Reply tool could auto-resolve edit conflicts on fast-moving pages. (I have very much been wishing for that over at MEDMOS these last few weeks. At one point, WT:MEDMOS was longer than AN and ANI combined, and at least the WikEd users were complaining that it was difficult to edit the page.) I don't think that getting the visual editor itself up on a page would be worth a 2% error rate – to me. Others might disagree. As usual, if you disagree with me, or if you can think of a group of users whose experience differs from mine, then I do appreciate hearing what you're thinking. Whatamidoing (WMF) (talk) 00:38, 15 January 2020 (UTC)
The MilHist Project was cleaning up the pages with incomplete MilHist Project checklists. Over time, this backlog had accumulated into one too large to process manually, so the task was assigned to our MilHist Bot. To Bot assess the articles required parsing them. See Wikipedia:Bots/Requests for approval/MilHistBot 5. Hawkeye7 (discuss) 00:52, 15 January 2020 (UTC)

@Whatamidoing (WMF): Is the Editing team actually considering introducing the full VisualEditor on talk pages? Or are these questions being asked because of the use of Parsoid in the inline comment editor, or for some other reason? Jc86035 (talk) 05:22, 19 January 2020 (UTC)

As I said above, they are getting requests, but the team is not enthusiastic about it. I don't think it will happen this calendar year. I make no predictions about what might happen several years from now.
Off the top of my head, some of the same considerations could apply to the Reply tool (play here; testing script here; ping me wherever you post your feedback), at least one upcoming MediaWiki technical RFC, some accessibility work (imagine a world with native MediaWiki support for line breaks inside bullet items), and how much trouble we'll encounter outside the article space when they decommission the old parser next year. Whatamidoing (WMF) (talk) 00:52, 20 January 2020 (UTC)

Article watchlist bouncing in Safari on iPad, but not user watchlist[edit]

Which seems pretty odd. Doug Weller talk 06:07, 10 January 2020 (UTC)

Stopped. Started last night, stopped after 18 hours. Doug Weller talk 21:23, 10 January 2020 (UTC)
Doug, was that on a page with a "Live updates" option? Whatamidoing (WMF) (talk) 00:40, 15 January 2020 (UTC)
@Whatamidoing (WMF): yes, this is The second time it has happened to me and both times it went away after a few hours. I also had a watchlist with just user and talk pages open which was fine. Doug Weller talk 06:14, 15 January 2020 (UTC)
Have you tried toggling the "Live updates" button, to see if that stops the bouncing? Whatamidoing (WMF) (talk) 16:49, 15 January 2020 (UTC)
@Hatamidoing (WMF): I think I did but I'm not sure - it was hard to do anything with all the bouncing. I'll remember that if it happens again. Thanks for your help. Doug Weller talk 16:52, 15 January 2020 (UTC)

What I am doing wrong, technically.[edit]

I use this kind of reference:


  • In Conjectures and Refutations: The Growth of Scientific Knowledge, 1963, by Karl Popper.

    De mortuis nil nisi bene: once a theory is refuted, its empirical character is secure and shines without blemish.[1]


  1. ^ Popper, Karl (1963). Conjectures and Refutations: The Growth of Scientific Knowledge (2002 ed.). London: Routledge. ISBN 978-0-415-28594-0.

I cannot preview the Notes anymore. I can save it, but cannot preview. I can preview and save if I edit the whole article, but if I edit the Notes only, I cannot preview, only save. The same thing happened in another article. I like to not put notes inline. I feel that it clutters the text and it's less easy for others to edit.

Dominic Mayers (talk) 20:02, 12 January 2020 (UTC)

Sounds similar to Wikipedia:Village_pump_(technical)/Archive_177#fatal error, which was supposedly fixed in phab:T240248. Suffusion of Yellow (talk) 20:22, 12 January 2020 (UTC)
Thanks. It's funny: one can even check the bug here by editing Notes above and trying to preview it. It has to be Notes. If you edit the whole subject, there is no issue. Dominic Mayers (talk) 22:14, 12 January 2020 (UTC)
Should I submit this as a bug somewhere? Dominic Mayers (talk) 22:27, 12 January 2020 (UTC)
@Dominic Mayers: I'm doing that right now. Suffusion of Yellow (talk) 22:47, 12 January 2020 (UTC)
@Dominic Mayers: Done, see phab:T242558. Suffusion of Yellow (talk) 23:21, 12 January 2020 (UTC)

Problems opening references sections[edit]

Anyone else been having difficulty opening a ==References== section for source edit? Getting: Error

Our servers are currently under maintenance or experiencing a technical problem. Please try again in a few minutes.

See the error message at the bottom of this page for more information.

Request from via cp3052 frontend, Varnish XID 108358835 Error: 503, Backend fetch failed at Tue, 14 Jan 2020 14:45:59 GMT

Been happening for some hours. Other sections opening OK, can work around by opening whole page. Saves fine.

Cheers, · · · Peter Southwood (talk): 14:49, 14 January 2020 (UTC)

This is T242558, see section above. – Jonesey95 (talk) 16:04, 14 January 2020 (UTC)
But is it getting resolved? Doesn't look like the ticket has been addressed in two days and reFill 2 is still failing. Walter Görlitz (talk) 20:15, 15 January 2020 (UTC)

A single page which won't load[edit]

For some odd reason I can't go to the page Polistes versicolor -it won't load. The history, the talk page, as well as the article in other languages, load fine. If I go to history & click on the latest version, these load and I can edit that, but when I save, the page again will not load. But whatever I've done does show up in the history. Very odd. This is the first time I've experienced this, and I only have this problem on that page. Do others have the same? Eh, maybe someone technical should look at it? — Preceding unsigned comment added by Leo Breman (talkcontribs) 2020-01-13T18:05:11 (UTC)

 Works for me @Leo Breman: I just made an edit to the page to refresh it, and it seems fine to me. Try bypassing your cache and reloading. — xaosflux Talk 18:18, 13 January 2020 (UTC)
Nope, it still bizarrely won't load ... on Firefox, it works on Chrome. Bypassing cache doesn't seem to help, nor deleting what is in my browser history. The Firefox version is old, but why would only this page not load out of hundreds, if that is the case? Thanks anyway, xaosflux. Leo Breman (talk) 19:31, 13 January 2020 (UTC)
 Works for me. Firefox 72.0.1 64-bit version on Windows 7 (yes, I have to upgrade at some point) with a fair bit of RAM and a spindle disk. Walter Görlitz (talk) 17:58, 16 January 2020 (UTC)

IPv6 individual and /64 block logs[edit]

Issue: difficultly determining blocks in /64 range for IPv6

Description: I was poking around WP:ADMINTOOLS and WP:TOOLS and was wondering if there were any gadgets or features to allow admins or anyone to view block logs of all IPv6s in a /64 range. Currently, you can view the block log for a single IPv6 or the block log for the whole range. The difficulty is that sometimes individual IPs get blocked, but they quickly hop up a new IP in the /64 range and it can appear the IP has no record of troublemaking.

I'd love to see some treasure that lets me quickly see all blocks in a range and even all warnings on talk pages to better assist with the wackamole. Any current tools do this? EvergreenFir (talk) 06:22, 14 January 2020 (UTC)

Hmm. I have two /64 nets for my home (actually a /60 delegated from Comcast). So yes, if I had a blocked IP, I could go to a different computer at home and use that. But also ISPs like Comcast will delegate addresses from their own /64 among unrelated customers. It might be that there is a range of addresses for delegating subnets and a range for internal use. You might find two unrelated blocked IPs from the same /64. Gah4 (talk) 06:35, 14 January 2020 (UTC)
Definitely possible and it would take inspection to determine if the blocks and edits are related. Still can be worth it. EvergreenFir (talk) 06:46, 14 January 2020 (UTC)
You could look at the range contributions and look at the block logs of each IP (reasonably quick with popups). I know that's kinda hacky but most residential /64's are sparsely used.--Jasper Deng (talk) 06:40, 14 January 2020 (UTC)
I haven't tried popups. I use the range contribs but sometimes there's too many to glance through. EvergreenFir (talk) 06:46, 14 January 2020 (UTC)
I don't know how ISPs do it, but I suspect so. On the other hand, if I really use all 16 of the /64s delegated to me, you will have a harder time finding me. But also, I don't know the distribution of WP users. What fraction of people ever edit a page? Gah4 (talk) 06:53, 14 January 2020 (UTC)
If you view contributions for the range with the mark blocked users gadget enabled, wouldn't any individually blocked IPs in the range show up as blocked? I might be misunderstanding what you're asking for, but for a purely visual cue I think that'd do it. ~ Amory (utc) 10:57, 14 January 2020 (UTC)
Yes, that works, it's what I use the gadget for. Black Kite (talk) 11:17, 14 January 2020 (UTC)
It won't reveal any previous blocks that have expired, though, and it won't reveal the parameters of existing blocks.--Jasper Deng (talk) 12:00, 14 January 2020 (UTC)
Like Black Kite, I use that gadget as well but as Jasper says I'm interested in past blocks as well. Also for cases with hundreds of edits on a range, the gadget only works as much as you're willing to dig through. EvergreenFir (talk) 12:16, 14 January 2020 (UTC)

I just dropped a similar question at MusikAnimal's talk page about being able to see the contributions made to a /64 range's (collective) talk pages. --Izno (talk) 16:06, 14 January 2020 (UTC)

One approach for anyone wanting to write a script/tool for this would be to use API:Usercontribs to first get the range contributions. Then for every distinct IP address in the result, use API:Logevents to get its block log, and API:Parse to get the content of its talk page. Present all the output on a single page. SD0001 (talk) 07:20, 15 January 2020 (UTC)
MusikAnimal pointed me to using Special:Prefixindex to get a list of all the talk pages of a particular /64, which seems reasonable to me. --Izno (talk) 16:00, 15 January 2020 (UTC)

This is perhaps a little off-topic, but has there ever been a discussion to add a simple function to the User Contributions page to show all edits made on the /64 range? It seems such a logical tool to offer, and I'm surprised by its absence. Fiddling  with urls on a tiny mobile in order to do this is not easy.Nick Moyes (talk) 10:05, 15 January 2020 (UTC)

@Nick Moyes: When you plug in the IPv6 IP address of interest into Special:Contribs, just add /64 to the end. This has been a feature for a year or two now. (You can do any range you please.) --Izno (talk) 16:00, 15 January 2020 (UTC)
Thanks, Izno. I do know how to do that, having learnt the trick recently, but it's hardly elegant and darned near impossible to add /64 onto the end of a url whilst on a mobile. You try monitoring Recent Changes for a couple of hours and wanting to check the /64 range contributions of all those IPv6 vandals you've been reverting. Now, if only there were a little obvious button on that page I could tap or click..! I can't be the only one who can see the value of that, surely? Nick Moyes (talk) 17:00, 15 January 2020 (UTC)
Nick Moyes, in my experience the guys at WP:SCRIPTREQ would fix that real quick. ‑‑Trialpears (talk) 17:19, 15 January 2020 (UTC)

Twinkle & Partial Blocks[edit]

With partial blocks now in place on en-wiki, though some of the less clear use-cases are still having the formal policy written up, does anyone know if Twinkle is being updated to be able to place them? Nosebagbear (talk) 12:13, 14 January 2020 (UTC)

I suspect that WT:TW is the right page for that question. :) (which is an awfully fun shortcut!) --Izno (talk) 16:08, 14 January 2020 (UTC)
Amory already put it on the feature request list, see [2]. Regards SoWhy 10:55, 15 January 2020 (UTC)
I'm hoping to dive into a simple structure soon this week or next, depending on how busy life gets. In the mean time, little things like "what templates should be used?" are important questions that would be helpful to know. ;) ~ Amory (utc) 17:42, 15 January 2020 (UTC)

Is "ScienceNews template" useful - or not?[edit]

FWIW - a draft "ScienceNews template" (see copy below) has been created - a recent suggestion (see comments at "Wikipedia:Reference desk/Science#Is "ScienceNews template" useful - or not?") has been made that the better place to post my concern is on "WP:Village Pump" - the "Technical" section seems the best section to me at the moment (simply because I'm most familiar with this section over the years) - but other VP sections may be even better - QUESTION: Is such a template (or equivalent) useful anywhere on Wikipedia? - Comments Welcome - in any case - Enjoy! :) Drbogdan (talk) 20:05, 14 January 2020 (UTC)

"User:Drbogdan/ScienceNews" (transclusion converted to link after discussion was moved)

This blog-like thing seems like something that, at best, should be an occasional opt-in newsletter for those interested in receiving it. Its use of external links does not match our usual practice, which could be jarring for some readers. Also, the CAPITAL LETTERS should be toned down to match MOS. I think that Wikipedia:Village pump (idea lab) might be a better home for this discussion, since it doesn't seem that you have a technical question. – Jonesey95 (talk) 21:59, 14 January 2020 (UTC)
@Jonesey95: Thank you for your comments - and suggestion to post to the "WP:Village pump (idea lab)" - if interested, the post can be viewed here => "VP-IdeaLab" - iac - Thanks again - and - Enjoy! :) Drbogdan (talk) 22:17, 14 January 2020 (UTC)

NOTE: a new version (hopefully improved to the better Wikipedia standards) of the template has now been created - and, if interested, may be viewed below and/or here => "User:Drbogdan/ScienceFacts" - Thanks again for all the earlier comments - newer Comments Welcome - Enjoy! :) Drbogdan (talk) 16:29, 17 January 2020 (UTC)

New updated template version

This template contains clickable links

TOP TEN SCIENCE FACTS (see => original version)


  1. ^ Staff (2020). "How many stars are there in the Universe?". European Space Agency. Retrieved 17 January 2020.
  2. ^ Mackie, Glen (1 February 2002). "To see the Universe in a Grain of Taranaki Sand". Swinburne University of Technology. Retrieved 17 January 2020.
  3. ^ Staff (2020). "The Extrasolar Planets Encyclopaedia - Catalog". The Extrasolar Planets Encyclopaedia. Retrieved 17 January 2020.
  4. ^ Staff (2020). "Rover Environmental Monitoring Station - Mars Science Laboratory (NASA)". Spanish Astrobiology Center. Retrieved 17 January 2020.
  5. ^ Staff (2020). "Mars InSight Mission - Latest Weather at Elysium Planitia". NASA. Retrieved 17 January 2020.
  6. ^ Staff (2020). "Martians on Mars found by the Curiosity rover". Retrieved 17 January 2020.
  7. ^ a b Cofield, Calla (24 August 2016). "How We Could Visit the Possibly Earth-Like Planet Proxima b". Retrieved 17 January 2020.
  8. ^ Bogdan, Dr. Dennis (2020). "Calculation - Time to nearest star". LiveJournal. Retrieved 17 January 2020.
  9. ^ Fraknoi, Andrew (2007). "How Fast Are You Moving When You Are Sitting Still?" (PDF). NASA. Retrieved 17 January 2020.
  10. ^ Kolata, Gina (14 June 2012). "In Good Health? Thank Your 100 Trillion Bacteria". The New York Times. Retrieved 17 January 2020.
  11. ^ Novacek, Michael J. (8 November 2014). "Prehistory's Brilliant Future". The New York Times. Retrieved 8 November 2014.
  12. ^ Sundermier, Ali (23 September 2016). "99.9999999% of Your Body Is Empty Space". Retrieved 17 January 2020.

Extra coords[edit]

Does anybody know why Kew Gardens station (London) has two sets of title coords? They are clearly different. --Redrose64 🌹 (talk) 21:09, 14 January 2020 (UTC)

Fixed see fix - there were multiple coordinates with the same display configured. — xaosflux Talk 21:23, 14 January 2020 (UTC)
(edit conflict)This just came up at Template talk:Infobox bridge. That template imports coordinates from wikidata without checking whether the article already has coordinates (I don't know if it can), and somehow, the article did not appear in an error category for articles with duplicate coordinates (I don't know if there is one). The workaround is to insert coords into Infobox bridge with display=inline. – Jonesey95 (talk) 21:52, 14 January 2020 (UTC)
Face-smile.svg Thank you --Redrose64 🌹 (talk) 02:05, 15 January 2020 (UTC)

Next question: why did the problem version not throw the error {{#coordinates:}}: cannot have more than one primary tag per page? Compare this page. --Redrose64 🌹 (talk) 20:38, 16 January 2020 (UTC)

Warning: Use of !important[edit]

The in-built annotation for CSS pages is throwing four Warning: Use of !important cautions on User:Jo-Jo Eumerus/common.css. Is that a problem? Jo-Jo Eumerus (talk) 10:22, 15 January 2020 (UTC)

From what I understand, the warning is thrown to alert editors that their code will supersede more specific CSS declarations used which normally is not advisable (since the "correct" way to handle it would be to modify the more specific CSS declarations directly). This is especially important when editing the page-wide theme css file because it can potentially destroy the site for everyone. However, for user-specific stylesheets !important is in most cases needed because the point is to modify the interface despite the more specific declarations, so it shouldn't be a problem (unless you add something like body { display:none !important; }that hides everything Face-wink.svg). Regards SoWhy 10:53, 15 January 2020 (UTC)
The !important annotation is a cop-out: once it's been used for a particular property, it's then very difficult to override that declaration with another rule unless the declaration in that other rule also uses !important. There are no levels of importance. It's normally better to forget about !important and instead increase the specificity of the selector. --Redrose64 🌹 (talk) 11:49, 15 January 2020 (UTC)
Possibly but there are cases in which increasing the specificity of the selector is not possible or feasible. For example, I find text-shadows extremely annoying, no matter where they are used but I cannot know where they might be used, so I included a blanket hiding element in my css to handle that. Which needs !important to work. Regards SoWhy 12:06, 15 January 2020 (UTC)
You have two copies of the .citation-comment {display: inline !important;}. Because there are no hidden cs1|2 error messages, both of those can go away. If you wish to hide all cs1|2 error message or wish to see the maintenance messages, see Help:CS1 errors § Controlling error message display.
Trappist the monk (talk) 12:10, 15 January 2020 (UTC)
citation-comment is output for cs1-maintenance messages as well. --Izno (talk) 16:03, 15 January 2020 (UTC)
@Jo-Jo Eumerus: so short answer: no its not a problem. Long answer see above, if you were writing scripts designed to be used by others this is something worth looking to avoid, for something that is only ever for yourself just keep in mind that "!important" means just that - this rule is more important then what anyone else thinks! — xaosflux Talk 12:12, 15 January 2020 (UTC)

Interview template, more than one interviewer?[edit]

I'm trying to properly cite this inverview. It has two interviewers, but the cite template has only one slot for an interviewer name. Suggestions? Just comma it out? Maury Markowitz (talk) 15:20, 15 January 2020 (UTC)

I presume that you are referring to {{cite interview}}. Pretty sure that you are mistaken:
{{cite interview |interviewer-last=Fairbairn |interviewer-first=Doug |interviewer-last2=Diamond |interviewer-first2=Sephen L |last=Peddle |first=Chuck |title=Chuck Peddle Oral History |work=Computer History Museum |via=YouTube |date=12 June 2014 |url=}}
Peddle, Chuck (12 June 2014). "Chuck Peddle Oral History". Computer History Museum (Interview). Interviewed by Fairbairn, Doug; Diamond, Sephen L – via YouTube.
When you are having problems with the cs1|2 templates, the best place to discuss those problems is at the link you provided above: Help talk:Citation Style 1.
Trappist the monk (talk) 15:38, 15 January 2020 (UTC)
(edit conflict) The documentation at {{Cite interview}} says "interviewer: Full name of interviewer(s); separate interviewers with a semicolon (;); wikilink as desired." – Jonesey95 (talk) 15:46, 15 January 2020 (UTC)
The documentation needs to be updated. |interviewer-last=, |interviewer-first=, and their numbered forms, as well as the numbered forms of |interviewer=, are supported. --Izno (talk) 16:05, 15 January 2020 (UTC)
I have updated the documentation based on the documentation for the |author= parameters. Error corrections are welcome. – Jonesey95 (talk) 22:18, 15 January 2020 (UTC)

Autoblocks and admin accounts[edit]

Hi all, I've filed T242902, though feel free to call me a dummy if I've misunderstood how this works. The nutshell seems to be that admin accounts can be affected by IP autoblocks, despite that theyre supposed to have IP block exemption. Writ Keeper  19:04, 15 January 2020 (UTC)

It's been merged to phab:T233441 which was filed last year. In the meantime one can disable the block by just deleting the set cookie. – Ammarpad (talk) 02:28, 16 January 2020 (UTC)

RFD templates[edit]

Some time ago, I raised the issue that Wikipedia's detection tools for uncategorized pages were erroneously and unnecessarily picking up and listing redirects that had been nominated for deletion, because the nomination template was breaking the page's function as a redirect and causing it to register as an uncategorized article — so to resolve the problem, the regular RFD template was coded to automatically include the nominated redirects in Category:Temporary maintenance holdings so that they would be "categorized" and thereby ignored by the categorization tools. However, I'm now starting to encounter unnecessary redirects on the uncategorized pages tools again — the difference being that instead of the regular {{RfD}} template, these pages are tagged for deletion using {{Rfd-NPF}}.

I've manually added a couple of them to the temporary maintenance category to get them off the list again, but it's still unhelpful and unnecessary kludge that preferably shouldn't even show up in the first place — so I wanted to ask if somebody here who's more knowledgeable about template coding than I am could make sure that the Rfd-NPF template categorizes the pages in Category:Temporary maintenance holdings the same as the regular RFD template does, so that the tagged redirects don't clutter up the categorization tools. Thanks. Bearcat (talk) 22:21, 15 January 2020 (UTC)

{{Rfd-NPF}} is a hack that shouldn't exist, just like the rest of the rest of its ilk. * Pppery * it has begun... 22:29, 15 January 2020 (UTC)
Then nominate it for deletion. In the meantime, however, as long as it still exists, it still needs to ensure that it isn't causing RFD-nominated redirects to be erroneously detected as uncategorized articles. Bearcat (talk) 22:46, 15 January 2020 (UTC)
Bearcat, I've added the category to {{Rfd-NPF}}. Regarding Pppery's comments I would totaly agree that these should be merged with the normal version of the template. The code for {{Rfd-NPF}} is completly different from {{RfD}} and is bound to cause more issues in the future. ‑‑Trialpears (talk) 23:44, 15 January 2020 (UTC)
Thanks. Just to be clear, I agree that they should probably just be merged with the regular templates — I'm not an expert in NPP process, but I find it hard to imagine a plausible reason why they would need their own separate templates to do the same things that non-NPP templates already do — my only concern was with the notion that their mergeability or deletability would constitute a reason not to actually address the immediate problem. Bearcat (talk) 18:08, 16 January 2020 (UTC)

Rangeblocked IP not showing up as blocked in edit history[edit]

Hi all, I have the Preferences > Gadgets > Appearance > "Strike out usernames that have been blocked" tool turned on. I'm looking at this edit history, and the top couple of IPv6s, 2409:4060:393:6db1::18a:b0, and 2402:3a80:a84:a3cc:0:59:f313:2801 (and maybe more as the sock keeps editing) are not showing up as blocked for me, while the other one right under DMacks' edit is. I applied a /64 rangeblock to those IPs, so maybe that's the cause, but it seems like they should still be marked, in an ideal world. Any thoughts? Thanks, you hard-working people! Cyphoidbomb (talk) 02:47, 16 January 2020 (UTC)

The list at Special:Contributions/2409:4060:393:6db1::18a:b0 shows the block, even though it's actually a rangeblock of the /64. I think the mark-blocked gadget only strikes out the IPs under a single-IP block, not a rangeblock. The script at MediaWiki:Gadget-markblocked.js might be the one that does the strikeouts. The history of that script shows a recent change by User:Amorymeltzer. Perhaps he can say if it could be enhanced to strike out IPs covered by a rangeblock. EdJohnston (talk) 03:27, 16 January 2020 (UTC)
Is there any way to upgrade the gadget? The strikeouts are so crucial to my ability to gnome sockpuppetry. Cyphoidbomb (talk) 16:07, 16 January 2020 (UTC)

syntax highlighting and user interaction[edit]

Is it just me? Win 10, Chrome latest release, pages that MediaWiki renders with syntax highlighting.

Module:Citation/CS1 does not render with syntax highlighting because there is 100k-byte limit (I think). When I click and drag to highlight some code in that rendering, no problem.

Shift to Module:Citation/CS1/Configuration where syntax highlighting is not disabled. Move the mouse cursor over the various elements in the documentation portion of that page and the cursor changes almost instantly as it floats over the plain-text, links, blank space as would be expected. Move over the code, the cursor becomes lethargic, click and drag to highlight some bit of code or text and it takes several seconds for the highlight to appear; mouse cursor is stuck at text-select form until the selection highlights.

Is this just me? Is it some new change to MediaWiki's handling of syntax highlighting? Is it a Chrome problem?

Trappist the monk (talk) 15:57, 16 January 2020 (UTC)

Works fine for me on Linux with Firefox 72. It also worked with Chromium 78, but Chromium 79 has the problem you describe. Anomie 12:35, 17 January 2020 (UTC)
No problem for me on Chromium 79 / Ubuntu. Module:Citation/CS1 has syntax highlighting as well. MusikAnimal talk 16:14, 17 January 2020 (UTC)
Chrome just updated to 79.0.3945.130. With that update, the problem appears to have gone away.
Trappist the monk (talk) 16:16, 17 January 2020 (UTC)

Addition to Special:Import[edit]

Hello! I have started an RfC over at VPP regarding adding commons as a wiki source to Special:Import. Feel free to comment over there! --TheSandDoctor Talk 17:00, 16 January 2020 (UTC)

Will the deleted pages all disappear one day?[edit]

One of the stranger parts of the deletion policy is WP:PERMADEL:

Deletion should not be used for archiving a page. The developers have indicated that the deleted pages can be cleared or removed from the database at any time.

The first sentence is obvious enough, but I'm not quite sure what to make of the second one. The link goes to this statement made by Brion VIBBER in 2007: Deletion means deletion. The deleted page archives ARE TEMPORARY TO FACILITATE UNDELETION OF PAGES WHICH SHOULD NOT HAVE BEEN DELETED and are subject to being cleared or removed AT ANY TIME WITHOUT WARNING. I'm finding this surprising. Is it really the case that at some point in the future, the contents of deleted pages will permanently disappear so that not even admins will be able to view them? Or is this only a reference to a some mysterious feature of the early days of wikipedia that's not relevant anymore? – Uanfala (talk) 22:31, 16 January 2020 (UTC)

I've just stumbled upon Wikipedia:Viewing and restoring deleted pages, which does have some technical/historical background, but I'm still completely in the dark. – Uanfala (talk) 22:34, 16 January 2020 (UTC)

It's not very likely, but we could theoretically lose access to deleted edits again. The text of deleted pages/revisions isn't available in database dumps, etc., so if all the copies of Wikipedia's database became unavailable and all we could access was database dumps, we would lose all the deleted edits up until this highly calamitous event. Graham87 07:30, 17 January 2020 (UTC)
My user subpage at User:Graham87/Page history observations contains some examples of the kind of things that can be lost when deleted edits are cleared/nonexistent. Graham87 07:34, 17 January 2020 (UTC)

Desktop refresh[edit]

Quick note with a couple of related points:

Some of you might be interested in watching the mw:Reading/Web/Desktop Improvements. I heard in a meeting today that their main goals for the next few months are to make the sidebar collapsible, and to do something about the "header" (I think they mean the top of the page). I think that this will only affect people using Vector.

If the usual patterns hold (who else remembers the 2014 Typography refresh project?), whenever this happens, there'll be complaints for a week or two, especially if someone's favorite user script stops working, and then people will have fixed their scripts and adapted, and after a year or two, few of us will be able to accurately describe the changes that were made.[1] I think that people who use the desktop site on a mobile device will be happy about the collapsible sidebar. I have the impression that the header change is meant to be more compact.

My request for you technically minded folks is to keep an eye out for this, because I do expect that any change, no matter how small, will break at least one user script, and they'll ask for help here. It'll be announced in Tech News beforehand, but I don't have the release dates myself.

Also, our community historians might want to take a look at mw:Reading/Web/Desktop Improvements/A History of Wiki Skins. There's an [Edit] button right there at the top, if you see anything that's missing/wrong/unclear/in need of links. Whatamidoing (WMF) (talk) 07:01, 17 January 2020 (UTC)


  1. ^ If you're struggling to remember this right now, the 2014 project changed the ==Section headings== to a serif font, changed the font color from true black to extremely dark gray, and added just a little extra leading to Vector. I remembered the switch to serif section headings, but I had to look up the rest. What I will never need to look up is that they briefly broke a whole language with a font-based accident; as a result, I never want anyone to change any fonts again. AFAICT no font changes are planned.
Vector is terrible. It's an ugly canker, showing the absolute best of 1990s web design. The WMF should focus its efforts on Timeless and enter the 20th century.--Jorm (talk) 20:36, 18 January 2020 (UTC)
@Jorm: Isn't it too late to enter the 20th c.? Face-wink.svg CiaPan (talk) 23:08, 18 January 2020 (UTC)
d'oh!--Jorm (talk) 23:19, 18 January 2020 (UTC)
I want a highly-polished mahogany cabinet with scrollwork, an engraved brass front panel, and carefully-calibrated vernier dials. Some nice warm Nixie tubes would be good. Ivory bars (cracked or otherwise) are optional, but nickel bars must not be exactly one inch too short and there needs to be one more drop of oil on the quartz rod. --Redrose64 🌹 (talk) 11:20, 19 January 2020 (UTC)
I'm willing to file that feature request, but only if you demonstrate community consensus and have volunteers lined up to keep the scrollwork dusted. Whatamidoing (WMF) (talk) 00:55, 20 January 2020 (UTC)

Pop-ups and italics[edit]

I just changed the article on Tim Tolkien to put the italic markup for The Sentinel outside the piped wiki-link, instead of inside. This fixed an issue where the pop-up showed <em> tags around the link. Is this a known bug? All the best: Rich Farmbrough , the apparently calm and reasonable, 13:45, 17 January 2020 (UTC).

I reported it at Wikipedia talk:Tools/Navigation popups/Archive 9#em tags in piped links in 2014 with no reply. PrimeHunter (talk) 15:46, 17 January 2020 (UTC)
The function of interest is parse_inline_formatting(str). With the popup, was the page italicized correctly before your change? --Izno (talk) 16:06, 17 January 2020 (UTC)
It was not. You can use popups on links to old revisions. Compare before and after in the diff [3]. Before it displayed <em>Sentinel</em> without italics. My examples at Wikipedia talk:Tools/Navigation popups/Archive 9#em tags in piped links are still live. PrimeHunter (talk) 17:46, 17 January 2020 (UTC)
Thanks, is this part of the Mediawiki distribution now? All the best: Rich Farmbrough , the apparently calm and reasonable, 20:56, 17 January 2020 (UTC).
No, that was from the gadget Javascript page. (On that point, there is a separate preview tooltip implemented in MediaWiki Javascript that would render the page in question correctly. It has none of the functionality of Navpops though besides as a preview, and other differences besides.) --Izno (talk) 21:59, 17 January 2020 (UTC)

Edit Conflicts[edit]

Hi, I'm getting false "edit conflicts" on most "saves". I'm using Chrome. Any advice please. Graham Beards (talk) 14:49, 17 January 2020 (UTC)

Graham Beards, is anyone editing (other parts of) the page while you are?
Which mw:editor are you using? Whatamidoing (WMF) (talk) 19:58, 17 January 2020 (UTC)
Hi Whatamidoing (WMF), I'm using WikEd. No, there are no other editors around. They are all false conflicts. It's mysterious. Graham Beards (talk) 22:14, 17 January 2020 (UTC)
And it happened when I saved the above. Graham Beards (talk) 22:15, 17 January 2020 (UTC)
How did you save that comment? Did you use a mouse to click "Publish"? If so, the mouse could be doing weird double clicks. Instead, click in the edit summary box and press Enter to Publish. Try that for a while to see if there is a difference. Johnuniq (talk) 22:28, 17 January 2020 (UTC)
I'll try that 22:33, 17 January 2020 (UTC)
Seems to solve the problem. Thanks. Graham Beards (talk) 22:34, 17 January 2020 (UTC)
Thanks guys. It makes sense now - my mouse has been misbehaving on scrolling. Graham Beards (talk) 22:35, 17 January 2020 (UTC)
Pressing ↵ Enter works to publish when any of these have the focus: the "Subject/headline" box (when creating a new section); the "Edit summary" box (when editing an existing section); the "This is a minor edit" and "Watch this page" checkboxes; the Publish changes button. For this last one, pressing Space also works. At any time (even when typing in the main edit box), Alt+⇧ Shift+S will save your changes straight away. --Redrose64 🌹 (talk) 08:06, 18 January 2020 (UTC)
Thanks talk, Graham Beards (talk) 08:17, 18 January 2020 (UTC)

Refill not working[edit]

Does anyone know when reFill will be back up and working again? I as well as other users have noticed it is completely inoperable and has been so for days. It's the only reFill tool I know how to use and am hoping to be able to use it again so other wikipedians don't get upset at me for bare references. If no one knows what the deal is with reFill, are there identical tools where we can just plug in the page name and let it do its work filling in the references? Many thanks, --Caterpillar84 (talk) 01:20, 18 January 2020 (UTC)

phab:T213515 says the tool needs co-maintainers – Ammarpad (talk) 04:55, 18 January 2020 (UTC)
Caterpillar84, reFill and the visual editor use the same backend service, mw:citoid. If you open the visual editor (e.g., ) and click on the number for a ref containing a bare URL, you'll get a "Convert" button. Click that, and it'll fill in the ref. After you "Insert" it, , you can "Edit" the ref's contents to fix missing things before saving, or use the pencil icon in the top to switch to wikitext afterwards if you want. You can see one that I filled for you. Whatamidoing (WMF) (talk) 19:42, 18 January 2020 (UTC)
That is nice to know Whatamidoing (WMF) but filling them one at a time is incredibly laborious when Refill 2 could work on the whole article at once - indeed I have seen it fix over 100 refs in one article. Can anyone explain why Refill 2 - which has been working fine (well except for an occasional glitch that was sorted out fairly quickly) has to be stopped completely while waiting for a co-maintainer? While Reflinks is still available it isn't perfect and I have just finished a 5 day job fixing the refs that Reflinks could not handle and I have another one to struggle with. I am fairly sure that Refill 2 would have gotten some to most of them, Indeed the using two programs together take care of most bare urls. Anything to ease the work load would be most appreciated. MarnetteD|Talk 19:41, 19 January 2020 (UTC)
Heartily seconded! The manual substitutes are painful, when reFill could do a whole new article in one swoop. Anything that can be done to restore it would be greatly appreciated. KJP1 (talk) 21:27, 19 January 2020 (UTC)
It's not shut down, it's just broken. Cyberpower678 is the current maintainer now that Zhaofeng Li is inactive, but nobody seems to have contacted Cyberpower678. --AntiCompositeNumber (talk) 21:34, 19 January 2020 (UTC)
Thanks for clearing that up AntiCompositeNumber. Ammarapad's post and my reading of the phab caused my confusion. It is also nice to know that C678 has taken over the job. Previous posts about this had not been answered completely. Thanks again. MarnetteD|Talk 21:41, 19 January 2020 (UTC)
I actually pinged Cyberpower678 on the Refill talk page on 16 January 2020 with no response.— TAnthonyTalk 22:04, 19 January 2020 (UTC)
Yes. I got a couple of requests actually. I just have not had a moment to look into why. Not to mention that I'm a brand new maintainer and need to learn the internals. My goal is to merge InternetArchiveBot and ReFill.—CYBERPOWER (Chat) 22:55, 19 January 2020 (UTC)
For the non-technical folks: When you're working on code that you care about (e.g., reFill), it's considered best practice to have at least two people working on it. That way, Alice can write some code, and Bob can check for mistakes before it gets deployed, and vice versa. Fewer problems affect the wikis when people follow that system. The buddy system also helps solve the so-called "bus test" problem (i.e., what happens to your product if someone gets hit by a bus). In an ideal world, every tool that we care about would have at least two maintainers. Whatamidoing (WMF) (talk) 01:04, 20 January 2020 (UTC)
Unfortunately not realistic when dealing with a massively diverse community such as Wikipedia. There are as many different roles for the volunteers as are strands of hair on your head/face.—CYBERPOWER (Around) 01:11, 20 January 2020 (UTC)
In any event, I’ve given it a bit of a kick. Can someone please test it?—CYBERPOWER (Around) 01:12, 20 January 2020 (UTC)
Barring that, write good documentation. --AntiCompositeNumber (talk) 01:13, 20 January 2020 (UTC)
Cyberpower678, I just tried to run reFill 2 (refill/ng) on Malabuyoc, and I got the same Internal server error. – Jonesey95 (talk) 05:58, 20 January 2020 (UTC)
Cyberpower678, Many thanks for picking up the reFill work and appreciate that we're all volunteers. Just wanted to emphasise how really useful the tool is. Anything you can do to get it up and running again would be wonderful. All the best. KJP1 (talk) 07:41, 20 January 2020 (UTC)
Cyberpower678, I have tried using reFill for the last 20 minutes, but like other users, all I'm getting is this pop-up message, "Submitting your task... Internal Server Error". Woodlot (talk) 15:21, 20 January 2020 (UTC)
Cyberpower678 et al - I have tried both Refill and Refill2 several times today and I also keep on getting the dreaded Internal Server Error. Anyone have any updates on when these tools might be back up? (I even tried Reflinks but that's outside WP's purview...) Shearonink (talk) 22:57, 20 January 2020 (UTC)
Still not working, tried several times a viable workaround posted somewhere in this section? If so, for those of us who aren't coders(at ALL), could a ReFill workaround section be posted please? Thx, Shearonink (talk) 19:23, 21 January 2020 (UTC)
Can a revert to old be written to the source of the input page or can a temporary fork be made ? A bug has been filed at Github :
"I've tried a few times to use this tool in the last couple days. Now, I get a "Failed An error has occurred." when using." Chris-troutman Dec 25, 2019, 7:53 AM PST
English uses:
French uses: (talk) 01:44, 21 January 2020 (UTC)
Broken 06:12, 11 January 2019‎ Reflinks.js
Good Old 00:45, 3 April 2018‎ Reflinks.js says at Toolbox link :
Insert this code into Special:MyPage/common.js:
mw.loader.load( "" );
so I guess a workaround is :
copy over to the file:
Insert this code into Special:MyPage/common.js:
mw.loader.load( "" );
Nothing in Refill at ' has changed in 12 months. It seems the only change is at and"
If there is revision history at a could be made.
The only other editor is (talk) 02:44, 21 January 2020 (UTC)

After a bit of turning-it-off-and-back-on-again, reFill appears to be working now. The IP editor is correct that nothing has changed code-wise for a while. The frontend is sitting at this commit from Jan 13, 2018 and the backend is sitting at this commit from Jan 24, 2019. The reFill documentation doesn't really contain much operations information, so there were difficulties figuring out what needed to be checked and restarted. --AntiCompositeNumber (talk) 22:01, 21 January 2020 (UTC)

CSD log[edit]

CASSIOPEIA directed me here. I am asking about the CSD log. It isn't showing the CSDs prior to when I created the log. Is this correct? If so, is there anywhere or anyway to see my CSDs without picking through my contributions? Thanks in advance, Willbb234Talk (please {{ping}} me in replies) 13:09, 19 January 2020 (UTC)

Willbb234, At Wikipedia:Twinkle/Preferences. Find " Keep a log in userspace of all CSD nominations" and " Keep a log in userspace of all pages you tag for PROD" then click on the tick box. After that click on save changes. Now when you nominate something for CSD or Prod it will keep a log of it. ~~ CAPTAIN MEDUSAtalk 13:18, 19 January 2020 (UTC)
CAPTAIN MEDUSA I have already done that (see User:Willbb234/CSD log). My question is should it being showing CSDs prior to creating the log? Willbb234Talk (please {{ping}} me in replies) 13:24, 19 January 2020 (UTC)
Willbb234, you'll have to do that manually. There isn't anything about that... ~~ CAPTAIN MEDUSAtalk 13:27, 19 January 2020 (UTC)
The CSD log is just a wikipage generated from the time you tick the tickmark. You can go and add the ones from prior, if you can find them, but the tool doesn't know any better than you do which those are, so it doesn't. --Izno (talk) 14:55, 19 January 2020 (UTC)

Watchlist issues[edit]

Today, all pages I edit are being added to my list, and no I do not have that box checked in pref's. - FlightTime (open channel) 15:36, 19 January 2020 (UTC)

Well, this edit did not add this page to my list, confused. - FlightTime (open channel) 15:38, 19 January 2020 (UTC)
@FlightTime: If the issue persists, you should report it to Phabricator. --qedk (t c) 13:33, 20 January 2020 (UTC)
@QEDK: Everything seems fine after starting this thread, wierd IDK, but yes if it pops back I'll do just that. Thanx (soon to be mop :P) - FlightTime Phone (open channel) 15:42, 20 January 2020 (UTC)
That sounds good yep. (well, hopefully ¯\_(ツ)_/¯) --qedk (t c) 15:54, 20 January 2020 (UTC)

Filters and reusing existing filtering for libavtools.js[edit]

I'm working on my own Antivandalism toolset, and as part of it, I've been working on libavtools, which, currently, exclusively contains a bunch of code for filtering. I was wondering what I should look into replicating for its filters (username_filters.json, content_filters.json, and summary_filters.json), and alongside that, what existing datasets exist that I could possibly make use of. --MoonyTheDwarf (Braden N.) (talk) 20:41, 19 January 2020 (UTC)

Sidenote: If you're willing to help me create filters, and test the thing, please see User:Moonythedwarf/HandymanFilterInterface, which is what I use to test new filters. (You'll have to clear your config cache at User:Moonythedwarf/HandymanConfigInterface whenever you make an edit to your personal filters) MoonyTheDwarf (Braden N.) (talk) 20:48, 19 January 2020 (UTC)

Google search linking to older versions of WP pages[edit]

I have been noticing over the past few days that, when logged out, google search links to older versions of articles, by several hours. For example, at 13.06 UTC now, google search is linking to the Emily Hale article (and edit history), from 5.53 UTC, over 7 hours ago. However, if I log in, google search links to the most recent version (and edit history) of the article. Is that a fault on our side – E.g. have we stopped giving google the update data in real-time? Britishfinance (talk) 14:04, 20 January 2020 (UTC)

Britishfinance, page view caching is used for non logged in users but not for logged in users as documented at mw:Manual:Performance tuning#Page view caching. This can result in logged out users not seeing the latest version. ‑‑Trialpears (talk) 15:41, 20 January 2020 (UTC)
Thanks Trialpears, I wonder if the frequency of the cache update has changed recently? Thanks, Britishfinance (talk) 16:00, 20 January 2020 (UTC)
@Whatamidoing (WMF) and Anomie: It's hard for us to know, maybe either of them can answer your question (if available). --qedk (t c) 16:03, 20 January 2020 (UTC)
I have no information about this. Whatamidoing (WMF) (talk) 19:23, 20 January 2020 (UTC)

VisualEditor and DISPLAYTITLE Tool Tip[edit]

Resolved: message updated. — xaosflux Talk 15:37, 21 January 2020 (UTC)

Currently the message at MediaWiki:Visualeditor-dialog-meta-settings-displaytitle-help reads: "You can override how this page's title is displayed by setting a different label to show instead." However, on this wiki only the markup of a page title can be changed (and the case of the first character, if it is a letter), so it is slightly misleading. Also, judging by Category:Pages with disallowed DISPLAYTITLE modifications at least some VE editors seem to think they can change the title this way. I suggest the following text instead: "You can enter wikicode here to change the markup of the page title." --bdijkstra (talk) 15:31, 20 January 2020 (UTC)

@Bdijkstra: seems reasonable but I'm getting a bit lost trying to invoke that message from the editor, what are the steps you are using to get to where that message displays? — xaosflux Talk 15:36, 20 January 2020 (UTC)
@xaosflux: ≡ → Advanced settings → Display title → circled i (right hand side). --bdijkstra (talk) 15:51, 20 January 2020 (UTC)
@Bdijkstra: ok thank you, yes we certainly can expand on that to make it say anything useful. Lets follow up at MediaWiki talk:Visualeditor-dialog-meta-settings-displaytitle-help. — xaosflux Talk 16:17, 20 January 2020 (UTC)

DISPLAYTITLE Category discussion[edit]

Looking at Category:Pages with disallowed DISPLAYTITLE modifications it seems that most of the pages in the category are userpages, either leftover when copying an article or people thinking this is geocities. There is really no real reason that this should be used as a "toy" and even be enabled in userspaces. --Gonnym (talk) 15:43, 20 January 2020 (UTC)
@Gonnym: Couldn't agree more, but I hit a wall at VisualEditor/Feedback#Disambiguation tickbox. --bdijkstra (talk) 15:51, 20 January 2020 (UTC)
Categorization really should be disabled in user space. I guess we have to file a phab ticket to change it since it's a magic word? ‑‑Trialpears (talk) 15:55, 20 January 2020 (UTC)
@Trialpears: Wouldn't it be more useful to remove the magic word from the userpages using a bot (since there's no reason to use the modification in the first place)? We could also do both. --qedk (t c) 15:57, 20 January 2020 (UTC)
There's probably reasonable consensus for bot-removing bad DISPLAYTITLEs in user space, but I doubt there's consensus for disabling the keyword entirely. --Izno (talk) 16:23, 20 January 2020 (UTC)
Userspace may be drafting pages prior to moving to main, and using approriate display titles there (that don't include USER:xxx/). I can't see how these are actually hurting anything, at the very most perhaps commenting out the directive should suffice. — xaosflux Talk 16:26, 20 January 2020 (UTC)
In this current setup, the tracking category is useless as the massive amount of userspace categories are clogging it up. So that's one way it's hurting. I personally see no point in the display title even for valid draft pages in userspace. When ready for the mainspace, just add it later, same as how categories are done in draftspace. --Gonnym (talk) 16:37, 20 January 2020 (UTC)
So commenting it out, just like you could do for categories, should work well. — xaosflux Talk 16:43, 20 January 2020 (UTC)
On aside, the "polluted tracking category" could probably be easily dealt with here if phab:T197489 were to get done - subscribing to and commenting support there may be useful to attract developers. — xaosflux Talk 16:45, 20 January 2020 (UTC)
Done that, thanks for the ticket! I still think removing categorization in user space for that specific category would be appropriate though since that would likely be so much faster way to solve the pollution problem. ‑‑Trialpears (talk) 17:25, 20 January 2020 (UTC)
@Trialpears: seems reasonable, perhaps a WP:BOTREQ to "Comment out DISPLAYTITLE in User: namespace, when the display title does not contain "User:%BASEPAGENAME%" after getting a little more discussion time in? — xaosflux Talk 17:30, 20 January 2020 (UTC)
Bad DISPLAYTITLEs can also be generated by infoboxes; not sure if that currently occurs but in those cases the template should be modified to exclude certain namespaces or to work in a smart way with the title parts (like nl:Module:Titelweergave does). --bdijkstra (talk) 17:58, 20 January 2020 (UTC)
Note that Category:Pages with disallowed DISPLAYTITLE modifications says: "This search only displays articles in the category." I added it shortly after creating the category and have used it to find and fix more than 1000 articles. It works perfectly so pollution doesn't matter to me here. I have thought about making a general template for category pages to search for articles or other selected namespaces. PrimeHunter (talk) 22:42, 20 January 2020 (UTC)

Tech News: 2020-04[edit]

19:40, 20 January 2020 (UTC)

Curious infobox problem[edit]

This is what I did, after clicking on an external link that led nowhere. However, I don't know why this version immediately before my edits has the wrong external link because the diff doesn't show that link being removed. — Vchimpanzee • talk • contributions • 20:02, 20 January 2020 (UTC)

@Vchimpanzee: By default, the template fetches {{#property:P856}} for |website= from the Wikidata entry of Will & Grace. When you added |production_website=, it also added that URL as production website. When you removed that and added |website=, it overrode the default Wikidata property and used your explicitly defined URL instead. --qedk (t c) 20:08, 20 January 2020 (UTC)
I updated the Wikidata entry so now it should work fine. --qedk (t c) 20:12, 20 January 2020 (UTC)
Thanks. For some reason "production website" was in the infobox and I thought that's what was supposed to be there, but when it didn't work I added "website" to see if that would work.— Vchimpanzee • talk • contributions • 20:17, 20 January 2020 (UTC)
I've faced this a lot of times, so no worries, and fwiw, I'm very much against automatic inclusion of Wikidata properties. Interestingly, Apple Inc., used to display it was "Owned by" two hedge funds which altogether own <1% of Apple, due to the Wikidata entry, until it was ultimately removed from the infobox template. --qedk (t c) 20:21, 20 January 2020 (UTC)

Do not use {{DATE}} as an autovalue for date= parameters[edit]

Template:Technical was using {{DATE}} as the autovalue for the "date= parameter, but that produces a string starting "date=" leading to e.g. Category:Wikipedia articles that are too technical from date=January 2020 when the template is added using VisualEditor (See Special:Diff/936762441). I fixed that template by using {{CURRENTMONTH}} {{CURRENTYEAR}} instead. I don't know how to find if there are other templates with the same issue, or any pages in misnamed categories similar to the one above. Thryduulf (talk) 21:31, 20 January 2020 (UTC)

Here's a search for subst:DATE in template space. Some of the recommended uses are fine, but it looks like there might be a couple of problems there.
The recommended substing also does not work inside ref tags, IIRC. A friendly AWB editor might be able to help these articles (unsubsted substed dates). Also a similar search. – Jonesey95 (talk) 01:45, 21 January 2020 (UTC)

Intrusively unpleasant animated advertising banner[edit]

Just visited Wikipedia (not yet logged in) and got a large coloured graphical advertising banner scrolling across my eyes. Four your information, certain people such as myself are badly distracted by such animations, to the point of suffering some loss of mental focus, even physical dizziness, and hence experiencing significant distress, when attempting to read any nearby text. I can assure you that the burst of unpleasantness your banner engendered has ensured that it will be many years before I would ever, ever consider a financial donation (which I assume was the purpose of the offensive creation, though I was unable to stop and see), so your banner was entirely self-defeating. Please, please ensure that you respect WP:ACCESSIBILITY in a comprehensive, open-minded and above all sympathetic way before pushing out intrusively distressing and unreadable advertising to the unfortunate. Any kneejerk self-justification in reply to this plea (e.g. "we pull in more cash that way so you will just have to swallow it" or "here's how to turn it off [after you got hit between the eyes]" type shit) will only go to prove the point. Thank you for listening. — Cheers, Steelpillow (Talk) 10:06, 21 January 2020 (UTC)

Hum. I've accessed Wikipedia in not logged in mode and didn't see any banner. Jo-Jo Eumerus (talk) 10:41, 21 January 2020 (UTC)
I just viewed while logged out and got a scrolling banner ad for Wiki Loves Monuments (its stops scrolling when it looses focus, but I only found that out by accident) with a link to a post hosted on Medium, and the notice "The linked blog content above is hosted by a third party and is subject to their terms of service". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:00, 21 January 2020 (UTC)
This is the central sitenotice. Pinging User:Seddon (WMF), who created meta:MediaWiki:Centralnotice-template-B1920 011618 en6C dsk wlm cnt. DMacks (talk) 13:02, 21 January 2020 (UTC)
  • certain people are badly distracted by such animations,
Amen to that!
Don't get into a spat with Giano then, as he's developed a nasty habit lately of posting a super-fast animated hummingbird whenever something or someone annoys him. TBH, I'd prefer a goatse... Andy Dingley (talk) 13:56, 21 January 2020 (UTC)
I'd always wanted something like that on the mainpage. I guess here's our opening, as it were. DMacks (talk) 14:01, 21 January 2020 (UTC)

Wrong content shown for diff?[edit]

This diff doesn't appear to line up with the subsequent revert, showing just one byte of text removal. Is this a known bug? Sam Walton (talk) 16:47, 21 January 2020 (UTC)

The edit summary indicates it reverted to Special:PermaLink/936873146 (e.g. not using rollback), and those two versions are the same. MusikAnimal talk 17:30, 21 January 2020 (UTC)
Oh - right - duh. Thanks! Sam Walton (talk) 18:13, 21 January 2020 (UTC)

Earwig's Copyvio Detector[edit]

I use Chorme and Edge and both showed "502 bad gateway" when searching Earwig's Copyvio Detector. Could anyone help? CASSIOPEIA(talk) 02:10, 22 January 2020 (UTC)

 Works for me @CASSIOPEIA: would you try again? — xaosflux 'Talk 02:16, 22 January 2020 (UTC)
Xaosflux Tried and now I could access but when I pasted an article name to check copyvio, the system show this message - "An error occurred while using the search engine (Google Error: HTTP Error 403: Forbidden). Note: there is a daily limit on the number of search queries the tool is allowed to make. You may repeat the check without using the search engine." So I guess I need to go back later and see I would do the copyvio check. Thank you Zaosflux for the reply. Cheers. CASSIOPEIA(talk) 02:50, 22 January 2020 (UTC)