Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia
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)

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?

There a lot of talk pages that have errors that bleed to the end of the page, especially Multiline table in list. There are now over 1,000 such errors, of which probably less than half, but still a lot, cause increased indentation to the end of the page. Unclosed quote in heading generally infects the table of contents and therefore the whole page. Right now there aren't any such errors, but there are new ones every week. Multiple unclosed formatting tags (or even single missing end tags, for that matter) can bleed to the end of the page, especially <big> and <small>. There are now about 800 Multiple unclosed formatting tags, perhaps a third of them <big> and <small>. There are a lot of talk pages where the users fail to escape markup that they are talking about, including nav and other templates, <div> tags, everything. Some of these bleed to the end of the page. I would guess there are tens of thousands of these.
I would assume that most of the world's web pages are written with WYSIWYG editors and I would assume that a lot of people who enter content into websites would feel helpless dealing with the Wikipedia editing interface. If someone has expertise in some area of interest, the inability to deal with the Wikipedia editing interface should not be an obstacle for them to contribute to Wikipedia. And part of contributing to Wikipedia is discussions on talk pages. So, eventually, I think visual editing will be needed for talk pages.
It would be helpful if something happens as suggested at Wikipedia talk:Linter#Make it harder to create new lint errors. There should not be so many new lint errors created every day. —Anomalocaris (talk) 18:53, 27 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)

Deleted pages are stored in the same place as normal pages. Any sort of accident is likely to affect both and is very unlikely (any historical oddities dont really reflect the situation today). The disk storage for deleted pages is not that big in the scheme of things. I think it is extremely unlikely we would intentionally choose to remove them. [Disclaimer: just my personal view. Not official in any way or form] Bawolff (talk) 11:11, 24 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)

I getting this with Chrome + WikEd, seems to be random, my mouse is fine. Mattg82 (talk) 23:47, 23 January 2020 (UTC)

Are you sure? My mouse is reasonably new and in good condition and was working very well when I commented above. However, it started occasionally double-clicking two days after I posted the above! (I had a spare and the replacement has eliminated problems.) Johnuniq (talk) 02:15, 24 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)

Thank you all very much for looking into this and have it running again. Face-smile.svg Lotje (talk) 16:58, 23 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)

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)
Hey all and especially @Steelpillow:, thank you for your feedback and I genuinely mean that. So for a week we were running a number of banners as part of a follow up thank you campaign. That wrapped up on Tuesday. There was no monetary goal attached to that campaign. It's aim was to try and showcase Wikipedia. The banner I think your referring to was one with a mural design as part of it. The decision for the scroll on the mural banner you saw was mainly a practical choice in order to show more of the mural to the user. There were better ways we could have it, like the way it was implemented in the WLM and WLE banners which required user interaction. My genuine apologies for the discomfort caused. Seddon (WMF) (talk) 11:34, 24 January 2020 (UTC)
Thank you for the clarification. I think the key moment came when you assumed that all users who saw it would want to be shown more scrolling images. And my other point also stands: it was self-defeating insofar as its end effect was very far from a "showcase". I look forward to a calmer UX from here on in. — Cheers, Steelpillow (Talk) 14:32, 24 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)
  • @Steelpillow and Andy Dingley: +1 that the animations are problematic. There's an open proposal at WP:VPR#Reclaiming the sitenotice process to have most banners require community approval, and although it wouldn't have helped this particular (fundraising-related) case, it might help prevent things like this from happening on some kinds of banners. --Yair rand (talk) 20:02, 27 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)
@CASSIOPEIA: I've had that, or a very similar message, very occasionally over the last 12 months. I just assumed it was Google telling me to slow down a bit. Usually worked a few minutes later, presumably requiring someone at Google to nip downstairs and let out the head of steam from their server room. Nick Moyes (talk) 10:59, 22 January 2020 (UTC)
Nick Moyes Thanks for the info. Cheers. CASSIOPEIA(talk) 11:02, 22 January 2020 (UTC)
@Nick Moyes and Xaosflux: Earwing's Coyvio Detector has not been working a a few days now. I have raised phabricator:T243736]. Also see - Copyvio Detector not working @The Earwig' talk page. Thank you. CASSIOPEIA(talk)

Lupin's Spellchecker not working[edit]

I posted this request for input on Lupin's talk page on January 1st, but it has had no replies.

I am well aware everyone says this is an old tool (a bit like me, I guess), but it was darned useful, and I've yet to find any live spellchecker that's as good. Any offer to fix this would be most appreciated. Nick Moyes (talk) 11:05, 22 January 2020 (UTC)

What links here, excluding templates?[edit]

Is there any way to find all the incoming links to an article, but ignoring those links that only appear in templates? More specifically, I'm looking for pages that link to Austin transformer. It appears in Template:Electric transformers, which in turn is transcluded into dozens of articles, which are just noise in the Special:WhatLinksHere/Austin_transformer report. -- RoySmith (talk) 23:58, 22 January 2020 (UTC)

PS, I have thought of taking it out of the template, rerunning my query, and then restoring it to the template. It would only take a moment to do that, but it seems excessively invasive. -- RoySmith (talk) 00:41, 23 January 2020 (UTC)
The "what links here" list is very unlikely to update quickly and the template would have to be removed for a significant, yet unknown, period. Fixing this, like fixing Special:LinkSearch, is not as sexy as a new skin or fiddling with mobile so it may never be done. Johnuniq (talk) 01:03, 23 January 2020 (UTC)
Does selecting "Hide transclusions" in the Filters box produce the results you want? isaacl (talk) 01:23, 23 January 2020 (UTC)
No. It hides pages which are transcluding Austin transformer itself but no pages do that (except the article itself which does it via a template). "Hide transclusions" is mainly intended for use on template pages. MediaWiki cannot hide pages which only link via a template they use. It's a frequently requested feature. Wikipedia:Village pump (technical)/Archive 155#What Links Here vs.Templates has links to some of the requests here and at Phabricator. User:PrimeHunter/Source links.js produces Source links on Austin transformer. To use the script, add the below to your common JavaScript. PrimeHunter (talk) 01:29, 23 January 2020 (UTC)
importScript('User:PrimeHunter/Source links.js'); // Linkback: [[User:PrimeHunter/Source links.js]]
Barring the more general solution of a script, the only articles that include the text are these 5; you could trivially tweak the search to find the exact ones which include the square brackets indicating a link. --Izno (talk) 01:44, 23 January 2020 (UTC)
Just to say that the source links tool is phenomenally useful, I for one am very grateful for it. DuncanHill (talk) 01:57, 23 January 2020 (UTC)
See also T14396 (from 2007) and T5241 (from 2005). It would be really great to persuade the WMF to use our donations to give us more help in building an encyclopedia, but they have important branding discussion meetings to attend. Maybe after we are all one with the wikiborg, I won't be so cynical. – Jonesey95 (talk) 02:08, 23 January 2020 (UTC)

Broken prev diffs when apply tag filter to history[edit]

When looking at the history of a user's talk, if you enter "discretionary sanctions alert" for the Tag filter and click Show revisions, an extract from the history is shown. I think that in the past I could copy a "prev" diff from the resulting list to get a diff of the discretionary sanctions notification being added. However, when I do that now, the diff is meaningless because it gives the difference between successive entries in the filtered history. An example of a filtered history is this. The first two entries are dated 5 August 2018 and 6 July 2018 because an alert was added on each of those dates. However, the prev diff on the first line gives the difference from 6 July 2018 to 5 August 2018 which is no use. Has this behavior changed? Is it expected? Johnuniq (talk) 08:40, 23 January 2020 (UTC)

@Johnuniq: This is caused by - setting it to 'oldid' => 'prev', like on line 546 above, should fix it. DannyS712 (talk) 08:47, 23 January 2020 (UTC)
Thanks, although I don't understand the details of that. Is this part of a planned fix, or would a phab report be needed? Johnuniq (talk) 08:53, 23 January 2020 (UTC)
@Johnuniq: If you file a phab task and assign it to me, I should have a chance later this week to do more in depth investigation and see if there is no reason to always use "prev" DannyS712 (talk) 09:01, 23 January 2020 (UTC)
Thanks for the offer. I created phab:T243569. Johnuniq (talk) 02:46, 24 January 2020 (UTC)
@Johnuniq: Happened to be on phab right now - thanks DannyS712 (talk) 02:49, 24 January 2020 (UTC)

Not all template transclusions appearing[edit]

Why does the "Pages that link to x" not show all transclusions? As an example: Pages that link to "Template:BillboardID", it shows 2 transclusions, but that is not correct. Looking at Template:Single chart it uses this at:

|Billboardbrasilhot100={{!}}Brazil ([[Brasil Hot 100 Airplay|Hot 100 Airplay]]){{#tag:ref|{{#if:{{{artist|}}}||{{main other|[[Category:Singlechart used with missing parameters]]}}<span style="color:red;">ERROR: Billboard chart was invoked without providing an artist. Artist is a mandatory field for this call.</span>}}[{{trim|{{#ifeq:{{{forceartist|}}}|true|{{{artistid}}}/{{BillboardEncode|{{{artist}}}}}/chart?f={{{chartnum}}}|{{trim|{{BillboardID|{{{artist}}}}}}}/{{BillboardEncode|{{{artist}}}}}/chart?f=1221}} "{{{artist}}} – Chart history"] [[Brasil Hot 100 Airplay]] for {{{artist}}}. {{#if:{{{publish-date|{{{publishdate|}}}}}}|{{{publish-date|{{{publishdate}}}}}}. }} {{#if:{{{access-date|{{{accessdate|}}}}}}| Retrieved {{{access-date|{{{accessdate}}}}}}.}}{{dead link|date=July 2019}}{{main other|[[Category:Singlechart with dead link]]}}}}|name={{#if:{{{refname|}}}|{{{refname}}}|"sc_{{strip whitespace|{{{1|}}}}}_{{{artist|}}}"}}|group={{#if:{{{refgroup|}}}| "{{{refgroup}}}"}}}} {{Single chart/chartnote|{{{note|}}}}}

The relevant part in there is {{BillboardID|{{{artist}}}}}. Is this working as intended or documented somewhere? --Gonnym (talk) 10:44, 23 January 2020 (UTC)

Because the page Template:Single chart itself doesn't transclude {{BillboardID}}. Nardog (talk) 11:07, 23 January 2020 (UTC)
Gonnym I'll take care of this merger, just waiting for {{BillboardEncode}} so I can do both at the same time. ‑‑Trialpears (talk) 12:11, 23 January 2020 (UTC)
Right, the feature only shows actual transclusions which happen when the page is rendered. The transclusion code in the source is only activated in some of the cases where the template is called with |Billboardbrasilhot100. None of the examples currently displayed on the template page do that. {{Single chart/testcases}} does have such examples so it shows up in WhatLinksHere. Here is as search for templates with {{BillboardID in the source code. It finds Template:Single chart. PrimeHunter (talk) 12:43, 23 January 2020 (UTC)
Thanks everyone. Wish the what links here feature had "usage in source code" in addition to "links to" and "transcludes". --Gonnym (talk) 12:51, 23 January 2020 (UTC)
Searching with "insource:", as in template:insource:"billboardid" usually works fine. If the template name isn't specific enough one can add e.g. insource:/\{\{[Bb]illboardID *?[\|\}]/. Nardog (talk) 12:58, 23 January 2020 (UTC)

Multiple bad edits (one per an article)[edit]

Hello everyone, How can i undo/revert all contributions done by an anonymous user from our Wikipedia? I want to do that with one click. Is there any tool or user script? Thanks! ⇒ AramTalk 11:08, 23 January 2020 (UTC)

@Aram: See User:Writ Keeper/Scripts/massRollback.js. You might want to read WP:MASSROLLBACK before proceeding. --qedk (t c) 12:22, 23 January 2020 (UTC)
Hello @QEDK:, I copy massRollback.js script, but it doesn't work! I can not see any changes after installing it! I need that user script more. Can you help me? Thanks! ⇒ AramTalk 12:35, 23 January 2020 (UTC)
You can follow up at User talk:Writ Keeper. — xaosflux Talk 12:55, 23 January 2020 (UTC)

I discussed about this on User talk:Writ Keeper. Thank you both! ⇒ AramTalk 14:41, 23 January 2020 (UTC)

To-do and talk header boxes[edit]


--qedk (t c) 15:15, 23 January 2020 (UTC)

Is it possible to make the two boxes in the header - the to-do list and the talk header - fit side by side on User talk:Jo-Jo Eumerus? Jo-Jo Eumerus (talk) 15:00, 23 January 2020 (UTC)

@Jo-Jo Eumerus: On a high-resolution screen, the templates should now appear side-by-side, or else the to-do will appear below and to the right. --qedk (t c) 15:13, 23 January 2020 (UTC)
Thanks, QEDK Jo-Jo Eumerus (talk) 15:14, 23 January 2020 (UTC)
Glad to help! --qedk (t c) 15:15, 23 January 2020 (UTC)

Gallery perrow oddity[edit]

On c:File:I Wrote a Full Song in 24_Hours-K7r58jQqK8I00227.png and on 18 other images derived from one video the other versions gallery works as expected, four "Blackery with guitar" in one row for a total of five related images in this subset, with a perrow=4 gallery parameter. On enwiki the perrow=4 fails for File:I Wrote a Full Song in 24_Hours-K7r58jQqK8I00227.png and for me, what is the problem, is it only me, does it work for you?

From WP:TH + HD archives84.46.53.160 (talk) 07:45, 24 January 2020 (UTC)
This is because it only copies the direct html code to the English Wikipedia page, not all the styling. This is a long known issue of "foreign" (meaning from another website) files, it can only handle very specific styling, not everything and anything. (the 'context' of Commons is not available within English Wikipedia). Solving that problem is complex yet most of the time, no one even notices, so it's not a high on the list of things to fix. —TheDJ (talkcontribs) 10:32, 24 January 2020 (UTC)
Thanks, I hope it is {{tracked}} on Phabricator.Face-smile.svg84.46.53.160 (talk) 13:35, 24 January 2020 (UTC)

Interactive map[edit]

Hi. I'd like to learn how to make an interactive map.

Take this map as an example:

Your caption

I'd like to add a wikilink to a station linking to the corresponding page, and have some text displayed on top, e.g. the "Lo Wu" text at the very top should be converted into a link such as Lo Wu. Is there any template facilitating this?

Thanks, and happy 6,000,000 articles and Lunar New Year of the Rat! tLoM (The Lord of Math) (Message; contribs) (Report false positive) 12:11, 24 January 2020 (UTC)

@The Lord of Math: There is the {{Location map}} template series, but that needs the images to be defined somewhere. Alternatively {{Annotated image}} may do what you want.   Jts1882 | talk  14:01, 24 January 2020 (UTC)
I've used the {{Annotated image}} template on your image above.   Jts1882 | talk  14:25, 24 January 2020 (UTC)

Six million article banner[edit]

How do I get rid of the 6,000,000 articles banner, around 'pedia globe? GoodDay (talk) 12:31, 24 January 2020 (UTC)

I guess you could try deleting at least 825 articles? Martinevans123 (talk) 12:36, 24 January 2020 (UTC)
Martinevans123, I did my bit by CSDing 3 pages and commenting on 1 AfD today. What about you ? DBigXray 12:46, 24 January 2020 (UTC)
Ahem. Some of us are doing our duty and cobbling together any old trash, in our patriot march towards 7,000,000! Martinevans123 (talk) 13:15, 24 January 2020 (UTC)
not that I am exclusively a deletionist, but the deletionist also do their part by cleaning up useless trash, making it possible for others to spot useful trash for cobbling together, while on the march. Happy 6M. DBigXray 13:33, 24 January 2020 (UTC)
@GoodDay: this will be removed in about 2 days, you can hide the entire logo by placing: #p-logo {display: none;} in your Special:MyPage/common.css. — xaosflux Talk 12:39, 24 January 2020 (UTC)
If it's got an expiration date, then no problem. GoodDay (talk) 12:41, 24 January 2020 (UTC)

Okay, we get it. But I keep seeing red and thinking it's some kind of notice. It's very distracting.— Vchimpanzee • talk • contributions • 22:27, 24 January 2020 (UTC)

@Vchimpanzee: see above. — xaosflux Talk 22:34, 24 January 2020 (UTC)
@GoodDay and Vchimpanzee: You can revert the old logo by adding the following to your Special:Mypage/common.css:
#p-logo a { background-image: url(//; }
--Ahecht (TALK
) 20:02, 25 January 2020 (UTC)
That's over my head techno stuff. I'll just wait for the banner to expire. GoodDay (talk) 20:04, 25 January 2020 (UTC)
GoodDay: Or you can permanently delete the logo entirely with #p-logo a { background-image: url('') !important; background-size: contain; } If you want someone to do it for you just ask, takes 10 seconds. -- GreenC 22:37, 25 January 2020 (UTC)
How do I keep the globe, but delete the banner? GoodDay (talk) 01:27, 26 January 2020 (UTC)
@GoodDay: you can try Ahecht's suggestion above, but it really isn't a "good idea" - we're pulling the banner down in about 12 hours. — xaosflux Talk 02:13, 26 January 2020 (UTC)
Yeah. Ahecht's suggested move would open my account up to hacking. Too risky. GoodDay (talk) 02:15, 26 January 2020 (UTC)

@GoodDay: Go to Preferences/Gadgets, and check "Suppress display of CentralNotices". While you're there, you might also want to check "Suppress display of fundraiser banners" (which are annoying because they cause page bounce on load, and are especially annoying if you have a monthly PayPal donation set up). Narky Blert (talk) 16:43, 26 January 2020 (UTC)

It's alright. The banner is gone. GoodDay (talk) 16:49, 26 January 2020 (UTC)
@GoodDay: How would Ahecht's suggested move open your account up to hacking? --Redrose64 🌹 (talk) 22:49, 26 January 2020 (UTC)
When I checked my 'preview' with the proposed method, it suggest my account might be open to hacking. GoodDay (talk) 22:51, 26 January 2020 (UTC)
I rather suspect that it didn't. What were the exact words? Were they, by any chance, "Code that you insert on this page could contain malicious content capable of compromising your account. If you import a script from another page with "importScript" or "iusc", take note that this causes you to dynamically load a remote script, which could be changed by others."?
If so, then you should not worry. That is a generic message used on all CSS and JS pages regardless of content, it isn't warning you about anything specifically within the code that you pasted - it's shown for anything, including a completely empty edit window. In particular, Ahecht hasn't used either "importScript" or "iusc" (neither of which are valid in a CSS page). Also, it's difficult for a CSS page to contain malicious content, and even more difficult for it to be capable of compromising your account. If you know what you're doing, you can make a page difficult to use - such as being entirely invisible - but that won't compromise your account.
All that Ahecht's CSS rule does is say "display this image instead of the one that is already there" to your browser. --Redrose64 🌹 (talk) 00:50, 27 January 2020 (UTC)
I'm not a techno type, so this stuff is over my head. Anyways, the banner is gone, so no problem. GoodDay (talk) 01:46, 27 January 2020 (UTC)

IP range blocks[edit]

User:Vituzzu has blocked multiple ranges, and has not been responding to multiple requests at meta:User_talk:Vituzzu for unblocking, despite reminders at itwiki where he is most active.

These blocks are affecting many editors who use VPNs and cloud services. Some of the IP range blocks include English Wikipedia, while other ranges are only blocked on e.g. Commons, Wikidata & other language Wikipedias.

How can we get someone else to review these blocks, please? – Fayenatic London 14:29, 24 January 2020 (UTC)

Only stewards from metawiki can review them. Asking here is useless. Ruslik_Zero 19:10, 24 January 2020 (UTC)
Note that one can override global blocks locally, at Special:GlobalBlockWhitelist. Jo-Jo Eumerus (talk) 19:26, 24 January 2020 (UTC)
Thank you both. I found meta:Steward_requests/Global which is the place to appeal.
Can the blocking message be changed to link to that page, instead of saying "You can contact Vituzzu to discuss the block" since that has proved fruitless and frustrating for many would-be editors? – Fayenatic London 13:03, 27 January 2020 (UTC)
IP's can't place requests there, Globally blocked or locked users should appeal to stewards(at) — xaosflux Talk 14:49, 27 January 2020 (UTC)
@Xaosflux: Thanks; I confirm that that email address is displayed in a different message to blocked IP users. The problem remains for logged-in users who are blocked; we see the message that I pasted at meta:User_talk:Vituzzu#Unblock_Puffin_browser, which only refers us to one steward (who may, as in this case, choose not to respond to talk page requests). The message displayed needs to be changed. – Fayenatic London 21:01, 28 January 2020 (UTC)
@Fayenatic london: can you point to the specific MediaWiki: messages that are being shown? — xaosflux Talk 21:21, 28 January 2020 (UTC)
LIkely one of these. — xaosflux Talk 21:23, 28 January 2020 (UTC)
It was not one of those, but it is now! I checked many on that page, then tried Search, which did not find it; so I tried a Google search, which found a mirror of it, via which I traced this copy: MediaWiki:Globalblocking-ipblocked-range/en. I edited that, but I assume that the original version is the locked one at meta:MediaWiki:Globalblocking-ipblocked-range/en. – Fayenatic London 22:23, 28 January 2020 (UTC)
@Fayenatic london: ok - so your concern is that you don't like the message on meta-wiki, not here. Here is the challenge, meta-wiki is multi-lingual so we don't like to translate those messages directly. I think a good idea may be to request that that message has an additional line, something like {IF X exists: "For additional information see X"} where X is a new message that can point to a page. To request a change like this you can ask at phab by filing a feature request. — xaosflux Talk 23:19, 28 January 2020 (UTC)

Edit notice question[edit]


There's a question about suppressing a group edit notice at Wikipedia talk:Manual of Style/Medicine-related articles/RFC on pharmaceutical drug prices#Group notice. Can someone fix it? WhatamIdoing (talk) 18:56, 24 January 2020 (UTC)

@WhatamIdoing:  Done --qedk (t c) 19:01, 24 January 2020 (UTC)
Face-smile.svg Thank you WhatamIdoing (talk) 23:11, 24 January 2020 (UTC)

Wikipedia:Templates for discussion/Log/2020 January 20#Template:R from meme and related rcat templates are being considered for deletion at TfD[edit]

Nuvola apps edu languages.svg
Hello, Village pump (technical). You have new messages at Wikipedia:Templates for discussion/Log/2020 January 20.
Message added Note that I didn't propose this, but rather, am just notifying the village pump of a TfD discussion that may have wide-ranging impacts, particularly as MJL, the creator of this rcat, would like to have the CfD folks notified. This seemed the best way to do that. --Doug Mehus T·C 19:38, 24 January 2020 (UTC)


The ZoomOnThumb gadget has been available for years on to allow zooming in on images by hovering the mouse over them. I like it so much that I've begun adding it to my other wiki accounts (starting at by means of custom Javascript. Any user can do the same by copying the JS I used but I believe that it would be a worthwhile addition to the set of Gadgets available via checkboxes on the users' Preferences page. See also Wikipedia:User scripts/Requests#ZoomOnThumb gadget where User:BrandonXLF sent me here. — Tonymec (talk) 21:51, 24 January 2020 (UTC)

P.S. The above-mentioned custom JS has been reviewed by User:DannyS712. — Tonymec (talk) 22:06, 24 January 2020 (UTC)

@Tonymec: It was? DannyS712 (talk) 22:18, 24 January 2020 (UTC)
@DannyS712: Yes, see User talk:DannyS712#"Page has been changed" but I see no changeTonymec (talk) 22:54, 24 January 2020 (UTC)
@Tonymec: Sorry, confused about "reviewed". I have "reviewed" it in the sense that the page was valid as part of patrolling new pages (Wikipedia:New pages patrol). I have not reviewed it from a Code review perspective DannyS712 (talk) 23:10, 24 January 2020 (UTC)
@DannyS712: Sorry, I'm a newbie about JS on Wikimedia. I was wondering how to generalize this "French gadget" to my non-French accounts, there was a HowTo about that on, I did what it said (and added a comment or two because I believe in verbose commenting of source code), and it worked. Then I got a web notification saying you had "reviewed" the page and an email saying you has "changed" it (but no change was visible). I supposed, and you confirmed, that both of these were about the same event, called "review" on my User Notifications page. I didn't know there was more than one kind of review, and I thought that if there had been anything obviously untoward in that very short page you would have told me. Qui ne dit mot consent as we say in French (≈ silence is consent). I also thought that the fact that this gadget wasn't "new stuff" but something which had already simmered for quite some time at was a point in its favor. Sorry if I jumped to conclusions at any point.
Now if I can do anything more to help bring that gadget onto the prefs page, tell me what, anybody, and I'll do my best. — Tonymec (talk) 22:44, 25 January 2020 (UTC)
Tonymec, do you have a global.js page at Meta-Wiki? Whatamidoing (WMF) (talk) 21:47, 26 January 2020 (UTC)
@Whatamidoing (WMF): No, or not yet. You mean I should put that JS there, and it would automagically apply to all my accounts? Even so, I still think it would be a valuable addition to the "Gadgets" preferences page at, among others, — Tonymec (talk) 22:40, 26 January 2020 (UTC)
Yes, that's the idea behind a global.js page. It only works for you, but it works for you everywhere. A lot of smaller wikis don't have any gadgets at all, so adding a user script directly to your own account is the only way to use scripts at those wikis. Whatamidoing (WMF) (talk) 20:56, 27 January 2020 (UTC)

Daily page generation and lint errors[edit]

Mathbot, Oleg Alexandrov: Please see discussion at Wikipedia talk:Articles for deletion#Daily page generation and lint errors. Every day, Wikipedia is automatically generating two new lint errors. A workaround has been proposed but not implemented. —Anomalocaris (talk) 22:39, 24 January 2020 (UTC)

Got fixed. Oleg Alexandrov (talk) 04:01, 27 January 2020 (UTC)

Spacing for ungrouped item after subgroups[edit]

FYI: Pointer to relevant discussion elsewhere.

Please see Template talk:Navbox#Spacing for ungrouped item after subgroups. --Redrose64 🌹 (talk) 23:42, 24 January 2020 (UTC)

Forms for completing routine tasks[edit]

I went to nominate an article for deletion, but the process is onerous and decided to forget it. It's been a long time since I hacked on MW code but if there any support for doing a modal dialog to collect user input that could then complete all these tasks as a single action? If not, can you log this as a feature request? Cheers --LaserLegs (talk) 00:47, 25 January 2020 (UTC)

See WP:Twinkle which I think is what you are looking for. Mattg82 (talk) 00:59, 25 January 2020 (UTC)

Admins by language spoken[edit]

I am frequently looking for admins who speak Spanish, to help deal with difficult editors who are less than fluent in English. Do we have a way of syncing/searching the admin category with the categories of users who speak certain languages? If not, could such a thing be developed? I used to call on Titoxd, but they are fairly inactive these days, and want to find another. SandyGeorgia (Talk) 14:47, 25 January 2020 (UTC)

You can use petscan to search for users in both Category:Wikipedia administrators and Category:User es. SD0001 (talk) 15:11, 25 January 2020 (UTC)
Awesome, thanks! SandyGeorgia (Talk) 16:39, 25 January 2020 (UTC)
@SD0001: I can't make it work, and can't find instructions :( SandyGeorgia (Talk) 16:46, 25 January 2020 (UTC)
@SandyGeorgia: I see 7 users Basically just put each category name on a new line, and check the user namespace from "Page properties" tab. SD0001 (talk) 17:16, 25 January 2020 (UTC)
@SD0001: got it, thanks (I had failed to check the user namespace). SandyGeorgia (Talk) 18:29, 25 January 2020 (UTC)
SandyGeorgia, You'd want to make sure to increase the depth from 0, otherwise you'd find no results from subcategories like User es-5 Galobtter (pingó mió) 19:10, 25 January 2020 (UTC)
@Galobtter: thanks; I see you show up there, but your user page says Spanish level 1. I speak fluent Spanish, but need a sysop probably at level 3 or better to help. Are you able? If so, I'll ping you in. SandyGeorgia (Talk) 19:15, 25 January 2020 (UTC)
@SandyGeorgia and Galobtter: if you increase the depth level search of petscan you will find a better result. — xaosflux Talk 16:57, 26 January 2020 (UTC)
Yep, thanks, Xaosflux-- Galobtter put that same on my talk page. What I really needed was an admin who is more fluent than level 1 or 2, which is what most of those 107 are. I had to go through them one by one to sort out those at 3 or above. I eventually got someone to help out, but it would be really awesome if the tool could return only those at Level 3, 4, 5 or native. Best, SandyGeorgia (Talk) 17:01, 26 January 2020 (UTC)
@SandyGeorgia: does this do what you want? — xaosflux Talk 17:27, 26 January 2020 (UTC)
@Xaosflux: brilliant, thanks! SandyGeorgia (Talk) |

Any template gurus?[edit]

I was wondering if someone might take a look at the radar template and implement them? They're simple additions, I think. Maury Markowitz (talk) 17:45, 25 January 2020 (UTC)

 DoneJonesey95 (talk) 18:00, 25 January 2020 (UTC)

Disabling the visual editor's find-and-replace[edit]

This hot mess drives me nuts. While editing an article, I reflexively type cmd-F (on a Mac) in my web browser to find something on the page. But the visual editor's find-and-replace traps the keystroke. My system-wide find text is not in its field. My system's cmd-E "Use selection for find" command sort of works, but only with cmd-G, find again. Once I use that, then hitting cmd-F opens the browser's find command while the visual editors find-and-replace remains visible but semi-inert.

How do I disable the visual editor's Find command? Michael Z. 2020-01-25 17:50 z

Visual Editor is still very much in beta. You might have better luck with a different page editor. This search in Phabricator, Mediawiki's bug-tracking site, turns up a couple of bug reports that may describe the behavior you are seeing. I didn't see any feedback from developers about disabling VE's Find command. – Jonesey95 (talk) 18:07, 25 January 2020 (UTC)
Can we just have VE disabled? :-] ♦ J. Johnson (JJ) (talk) 23:58, 25 January 2020 (UTC)
Good question. I forgot to mention that option. To disable VE, individual editors can go to Special:Preferences#mw-prefsection-editing and select "Temporarily disable the visual editor while it is in beta". – Jonesey95 (talk) 03:11, 26 January 2020 (UTC)
The visual editor hasn't been in Beta Features on this wiki for a couple of years now.
Michael, I have the same problem. Unfortunately, I don't know of a good solution. I've learned to pay attention to which field is active, and to hit the Undo button when I don't. (I don't consider that to be a good solution.) Whatamidoing (WMF) (talk) 21:53, 26 January 2020 (UTC)
@Whatamidoing (WMF): As Jonesey referenced above, Special:Preferences refers to the VE as being in Beta, even if it's not specifically listed under the "Beta features" tab. --Yair rand (talk) 01:07, 28 January 2020 (UTC)
Changing that means that 300 translators would re-translate that line. The whole section needs to be re-organized (so you can just pick the editing environment you want, and not guess whether this pref secretly overrides that other pref...). I'd rather go straight from "old" to "new" without a temporary re-translation step in the middle. VisualEditor is not Beta software, no matter what that line says. Whatamidoing (WMF) (talk) 19:20, 28 January 2020 (UTC)

Polluted categories[edit]

Can I ask if anybody knows why Wikipedia:Database reports/Polluted categories hasn't been updated since December 15? It's an important maintenance list, because draft and userspace pages aren't supposed to be filed in article categories at all (and conversely, articles aren't supposed to be filed in projectspace categories either), but it's much harder to stay on top of cleaning up dirty categories if the tool hasn't updated in a month to either drop already-cleaned categories or pick up newly-polluted ones. Thanks. Bearcat (talk) 23:40, 25 January 2020 (UTC)

The bot has recently been active, so I suppose that the operator would be the first stop of interest. --Izno (talk) 00:22, 26 January 2020 (UTC)
Yes Sent a notification to MZMcBride, the maintainer, via the BernsteinBot's talkpage of this discussion, so hopefully they or a (talk page stalker) will reply here. Doug Mehus T·C 00:47, 26 January 2020 (UTC)
@MZMcBride: I stopped the queued instance and run it manually multiple times, but it didn't actually make an edts DannyS712 (talk) 02:53, 26 January 2020 (UTC)
Hi. There are logs stored in tools-sgebastion-07:/data/project/dbreps/var/log. A quick glance at the logs for this report indicate that it's running daily instead of weekly now (a change made sometime between April 2019 and October 2019 I guess) and it errors on almost every run due to the MySQL connection going away. This very likely means that the report is architected in such a way that it has become prohibitively expensive to generate. Are you interested in fixing the report? --MZMcBride (talk) 07:37, 27 January 2020 (UTC)

Should we be checking for links to the Shlayer trojan horse?[edit]

There is an article out today in Wired – The Sneaky Simple Malware That Hits Millions of Macs – about the Shlayer trojan horse that I find disturbing. It says that "The operators behind the trojan reportedly offer website owners, YouTubers, and Wikipedia editors a cut if they push visitors toward a malicious download", with a suggestion this could be done with a "masked link" in a Wikipedia footnote.

Do we have any indications of such links here? Should this be looked into? ♦ J. Johnson (JJ) (talk) 23:56, 25 January 2020 (UTC)

If we had examples we could look into users that insert them, or we could check external links that go to flash download pages or site level redirects. All the best: Rich Farmbrough (the apparently calm and reasonable) 17:13, 26 January 2020 (UTC).
What I am wondering about is: should we be proactively looking for instances of this sort? If there were such cases, and someone got tripped up, I don't know that they ("some random reader") would know that it is something we would want to know about. But then, perhaps this isn't something we need (yet?) be concerned about? ♦ J. Johnson (JJ) (talk) 21:38, 27 January 2020 (UTC)
Wikipedia:Wikipedia Signpost/2020-01-27/In the media has a blurb titled "Beware of malware" in the "In brief" section. That in turn links to a full report on Near the bottom of that report is an old screen capture of the references section of ru:Kodak Black with a link to a taken-over-an-allegedly-poisoned web site kodak-worldDOTcom. I've already fixed the Russian version, the Ukrainian version, and the French version to point to versions of the page or to the artist's current official web site instead. Someone with the expertise needs to go through all Wikipedias and search for web sites that are known to be poisoned. Of course, this is a game of whack-a-mole: What is a valid reference today may become a "for sale" domain tomorrow then an infected domain the day after. This means as new domains are compromised, new scans will have to be run. davidwr/(talk)/(contribs) 22:54, 27 January 2020 (UTC)
I gather the broader problem is where an existing, legitimate reference links to a domain that has been compromised, not the malicious addition of fraudulent references. Thanks for the information. ♦ J. Johnson (JJ) (talk) 22:50, 28 January 2020 (UTC)

Deleting the Help namespace in another Wikipedia[edit]

Hello. In Russian Wikipedia all pages in the Help namespace have been moved to the Wikipedia namespace and now there are only a couple dozen redirects in the Help namespace. Now there is a proposal to delete the Help namespace altogether and create new help pages in the Wikipedia namespace. Some users have pointed out that deleting it would be technologically complex if possible at all. Sorry if I'm posting this in the wrong place, but could anyone tell me if any Wikipedia or another Wikimedia project has successfully deleted an existing namespace? --Синкретик (talk) 10:19, 26 January 2020 (UTC)

@Синкретик: The help namespace is part of the mediawiki core - see, eg, here DannyS712 (talk) 10:42, 26 January 2020 (UTC)
Синкретик, it would be trivial to prevent editing of help pages by adding it to the title blacklist which is what happens to the unused Gadget: namespace here. ‑‑Trialpears (talk) 10:45, 26 January 2020 (UTC)
You might want to consider leaving redirects, per Cool URIs don't change. All the best: Rich Farmbrough (the apparently calm and reasonable) 17:22, 26 January 2020 (UTC).
I can understand a wish to remove an unused namespace so it doesn't appear in namespace selection lists on various special pages like Search, Contributions and WhatLinksHere. It doesn't seem possible to remove the namespaces at mw:Manual:Namespace#Built-in namespaces. PrimeHunter (talk) 17:39, 26 January 2020 (UTC)

Connection Problems - January 26 2020[edit]

Intermittent site unavailable in Western Europe[edit]

See this map for a rough distribution. This is making accessing Wikipedia a very hit-and-miss affair. Anyone now why this is?

All the best: Rich Farmbrough (the apparently calm and reasonable) 16:33, 26 January 2020 (UTC).

Appears to be what is being tracked in phab:T243713. — xaosflux Talk 16:45, 26 January 2020 (UTC)

I noticed this but it's back now for me. The app did not seem to be affected. Andrew🐉(talk) 19:20, 26 January 2020 (UTC)

Didn't they already have problems with esams a while ago? Jo-Jo Eumerus (talk) 19:26, 26 January 2020 (UTC)

I'm having trouble here in California too. 5034 gateway timeout, or just plain hung or very slow. 2601:648:8202:96B0:0:0:0:4FFF (talk) 20:13, 26 January 2020 (UTC) (Update 21:12, 26 January 2020 (UTC): better now).

I am in Northern California and I have been experiencing very slow access and 504 timeouts for about an hour. Cullen328 Let's discuss it 20:37, 26 January 2020 (UTC)
Access has improved for me in recent minutes. Cullen328 Let's discuss it 21:03, 26 January 2020 (UTC)
Was having issues previously and i'm in Texas. Seems to be over now? --moonythedwarf (Braden N.) 21:06, 26 January 2020 (UTC)
Had problems all day however it seems to have been resolved within the last few minutes, In the UK & added cmnt to ticket, Cheers. –Davey2010Talk 21:10, 26 January 2020 (UTC)
I came here to see if anyone else was having an issue. I too just had a 504 issue and its been sluggish to load pages. Im from Minnesota, so this isnt something regionally based. I could be wrong, just a guess. Hopefully this can be fixed, and promptly. SageSolomon (talk) 21:15, 26 January 2020 (UTC)

Server problems[edit]

I'm assuming this is a Wiki-wide problem, today. The servers have been quite sluggish, these last few hours. GoodDay (talk) 20:22, 26 January 2020 (UTC)

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.
If you report this error to the Wikimedia System Administrators, please include the details below.
Request from via cp1083.eqiad.wmnet, ATS/8.0.5
Error: 504, Connection Timed Out at 2020-01-26 20:34:02 GMT
Vchimpanzee • talk • contributions • 21:02, 26 January 2020 (UTC)
It's not just Wikipedia. All WMF wikis that I've tried (Wikipedia, Wiktionary, Commons and Wikivoyage) are either working fine or timing out and what one is doing at any given moment the others are doing the same. Thryduulf (talk) 21:14, 26 January 2020 (UTC)
Appears they've worked out the bugs, now :) GoodDay (talk) 21:20, 26 January 2020 (UTC)
For whatever it may be worth: late yesterday I didn't see any significant problems accessing Perhaps I just missed the difficulties. Or could it be I'm on the west coast, and presumably going through the S.F. servers? ♦ J. Johnson (JJ) (talk) 21:46, 27 January 2020 (UTC)

Serious Connection Issues[edit]

There are major connectivity problems right now all over the site. FYI. -- Veggies (talk) 20:23, 26 January 2020 (UTC)

DDoS in progress? Sometimes I get a timeout, sometimes the page loads but with no skin… Waiting a few minutes then reloading usually does it for me, but of course the reload interval shouldn't be too short, or the reloading attempts will compound the problem. (I'm in Belgium.) — Tonymec (talk) 20:59, 26 January 2020 (UTC)

Maybe it was a traffic spike following the breaking news of Kobe's death. When Michael Jackson died, WP was off for a few hours. Lugnuts Fire Walk with Me 22:40, 26 January 2020 (UTC)
This has been going on since before that event - getting on for 24 hours now. Thryduulf (talk) 00:16, 27 January 2020 (UTC)
Correct and the Tweet below [4] suggests it was an intentional DDoS. But I wouldn't say Bryant's death was unrelated either. If you look at [5] and compare to the editing history of Kobe Bryant [6] there was a spike around the time when our article was getting a lot of edits suggesting this was when news of his passing was starting to spread. If the servers were already under strain from an intentional DDoS, perhaps partly migated by adjusting traffic end points, then the sudden strain of a spike from genuine users trying to read about Bryant may have pushed them over the edge again. Nil Einne (talk) 03:18, 27 January 2020 (UTC)
If you look at the actual data, any spike from Bryant is insignificant on a global scale compared to things like the movement of the sun and Monday mornings. Correlation does not imply causation. --AntiCompositeNumber (talk) 04:07, 27 January 2020 (UTC)
I wouldn't be so sure. Michael Jackson's death definitely caused a massive traffic spike which caused many problems [7]. While it's true the internet has moved on since 2009, although as the Tweet illustrates we still don't really have any proper DDoS protection given our reluctance to use third party services and the reach of Kobe Bryant is far less than Michael Jackson (although the BBC News app seems to have turned into Kobe Bryant died app), an impact can't be ruled out from the data I've seen. Note I explicitly never said that it did cause a problems, rather I've seen no strong evidence it did not cause problems either. Remember also that the problem is in timing as much as anything. A spike of 10 million page views over a day may be irrelevant. A spike of 10 million page views over 10 minutes, not so much..... Also, any data when the servers are having problem is likely to be circumspect, unless the people in charge say otherwise. (And for the WMF, given the way they seem to operate things, I would consider any data which could be vastly different from their normal data to be circumspect unless they say otherwise, even if there were no recorded problem.) Nil Einne (talk) 12:27, 27 January 2020 (UTC)
Nil Einne, the micheal jackson problem should no longer exist. Tim Starling wrote explicit protections to make sure that when something like that happens again, only the one page is affected, instead of everything. —TheDJ (talkcontribs) 12:31, 27 January 2020 (UTC)
@TheDJ: I think there is some confusion here. I explicitly did not mention Wikipedia being affected by Michael Jackson for a reason. That was, as I understand it, caused by a specific set of circumstances relating to how things worked at the time [8], which was indeed largely fixed by the mw:Extension:PoolCounter. But the Michael Jackson case (and other cases since) illustrate the problem of unintentional DDoS caused by a sudden surge of genuine traffic due to some news in the world. (I've never run anything close to a significant webserver so I don't have any personal experience on how big such spikes are. But the reports I've seen suggest they can be massive. And as I said, if your site is actually having problems, or you simply never designed it with such loads in mind, you may not even really know precisely how big the spike even is. There is a reason why so much of the world, even fairly major sites, often rely on Cloudflare.) In this case, we know en.wikipedia, and other Wikimedia sites were already having problems before Kobe Bryant died. (Tweets from the CEO suggest it may have been an intentional DDoS although I haven't seen anyone on the technical side actually say that yet.) There is a good chance this problem was not completely resolved before Kobe Bryant died. If the servers were already under significant strain before his death, maybe close to and occasionally already occasionally going down because of this, a spike from his death could have pushed things over the edge for a lot of people, for a time. Again, I'm explicitly saying 'could' here. I have seen no data to suggest this happened. However I have also seen no data to suggest it did not happen, and the reasons people are giving for how we know it didn't happen, have not been convincing to me (which is my main point). Note also that it isn't really possible to design a website so that one specific page is completely isolated from the rest of the website, it's simply not how things work. Nil Einne (talk) 12:53, 27 January 2020 (UTC)

WMF is "mitigating the current DDoS using a service from Cloudflare" — CEO[edit]

As we could find out from the previous DDoS attack in September (see Wikipedia:Village pump (technical)/Archive 176#Should Wikipedia use Cloudflare?), the best way to get at least some comment from WMF is asking Katherine (WMF) in Twitter. I did just that, and got this response: We are mitigating the current DDOS using a service from Cloudflare. We have been working on new DDOS resiliency but it isn’t up and running yet.

That's reassuring, Cloudlare is well-known for their powerful DDoS mitigation tools. Note that a DDoS mitigation tool is not the same as a CDN, so it doesn't contradict the previous statement on this topic.

However I'm worried there has been no official comment for the media, the promise "We’ll keep you posted" in the WMF blog post on September 7th was not kept, and there has been no incident report on the previous DDoS at wikitech:Incident documentation. Also if one tries to get some data himself, is as hard to grasp as a nuclear plant control room and is deprecated. Ain92 (talk) 23:31, 26 January 2020 (UTC)

If you're looking for information from grafana, let me know what you're looking for and I'll see what I can find. --AntiCompositeNumber (talk) 03:54, 27 January 2020 (UTC)
  • @AntiCompositeNumber: I would like to find out when did the attack actually began and what was the traffic (in GB/s) on other server clusters besides the main one (eqiad). Perhaps there is some other info I can't think of, if you find anything interesting for the Wikinews readers, let me know about it. Ain92 (talk) 20:00, 27 January 2020 (UTC)
    Frontend traffic is the best place to look for timing, as that shows the caching layer you hit when you load a page. [9]. You can filter between clusters at the top left and in each panel. The other useful metric is from the application servers, which shows response timing for requests that don't hit the cache. [10]. --AntiCompositeNumber (talk) 20:11, 27 January 2020 (UTC)
WP:BEANS, perhaps? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 28 January 2020 (UTC)

WMF embracing security through obscurity 😒[edit]

There was another comment from Katherine which I think is reasonable to quote in full:

We decided against posting further information as doing so shares information that could increase exposure for a similar attack. We have been evaluating third party DDOS support services since the last outage, but weren’t going to share more until they go into deployment.

I'm no IT security expert, but IMHO a cloak of secrecy is a poor way to handle the situation considering the mistrust between WMF and community. Especially considering the WMF hadn't even told us about the new policy before my question. Ain92 (talk) 20:00, 27 January 2020 (UTC)

  • I don't know that it's especially odd to not want to reveal the intricate details of the steps you're taking to enhance your security. GMGtalk 20:04, 27 January 2020 (UTC)
  • Relying on secrets of your process to provide security is security through obscurity - not assisting with attackers future discovery processes is normal. — xaosflux Talk 20:10, 27 January 2020 (UTC)
  • WP:BEANS but for an active network problem instead of wikicontent. Let the pros deal with this. they have done this at least several more times than u ever did. —TheDJ (talkcontribs) 21:47, 27 January 2020 (UTC)
  • I came here to say exactly what TheDJ had to say.--Jorm (talk) 22:13, 27 January 2020 (UTC)
  • There's a difference between saying "Hit" and "Hit, battleship, 3rd grid, facing east-west". --AntiCompositeNumber (talk) 23:14, 27 January 2020 (UTC)

Earwig Copyright Issues[edit]


My attempts to use Earwig in the last couple of hours have been unsuccessful - tested on a couple of pages, starting with Draft:DBL Ceramics. I get the following error message when I try:

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.

Anyone else getting the same? Or a basic error being made on my side? For what it's worth, I get the same error message if I click on the CSD link or type it in manually. Nosebagbear (talk) 18:11, 26 January 2020 (UTC)

Google only allows so many tries per day, the are used up today. You can follow up at User talk:The Earwig. — xaosflux Talk 21:05, 26 January 2020 (UTC)
It's been the same way for a number of days now, continuously so I think. Has the Foundation forgotten to pay the bill or something? If we've really used our 50000 searches per day every day for the last 4–5 days, maybe we should see if the subscription can be doubled or increased in some way? Justlettersandnumbers (talk) 21:25, 26 January 2020 (UTC)
User_talk:The_Earwig#Copyvio_Detector_not_working suggests that this needs a fix from the tool operators. — xaosflux Talk 22:18, 26 January 2020 (UTC)
Nosebagbear I have raised phabricator:T243736]. CASSIOPEIA(talk) 03:29, 28 January 2020 (UTC)

Problem with insource searches[edit]

For the last few days, when I've attempted to perform insource searches (e.g. insource:/\[\[Golden Age\]\]/), I receive a Wikimedia Error like this:

"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.

If you report this error to the Wikimedia System Administrators, please include the details below.

Request from 2601:49:8402:5f90:985e:b33e:2406:68c1 via cp1081.eqiad.wmnet, ATS/8.0.5 Error: 504, Connection Timed Out at 2020-01-27 04:15:06 GMT"

Could someone please look into this? Thanks! GoingBatty (talk) 04:18, 27 January 2020 (UTC)

The last day or two we've been having hardware issues elsewhere (see above threads) which may have been impacting search. In general, make sure you trim down the possible sets of search terms before running a regex search with e.g. insource:"Golden Age" insource:/\[\[Golden Age\]\]/. --Izno (talk) 04:59, 27 January 2020 (UTC)
@Izno: That works a lot better - thank you! You inspired me to go to Help:Insource, which directed me to mw:Help:CirrusSearch#Regular expression searches, which I hadn't read before, but explains your recommendation. Thanks! GoingBatty (talk) 05:32, 27 January 2020 (UTC)
You can use User:PrimeHunter/Source links.js for your purpose. On Golden Age it says Source links. It's efficient and searches for both piped links and upper and lower case first letter. PrimeHunter (talk) 10:56, 27 January 2020 (UTC)

Citoid inordinately slow[edit]

While trying to expand Mount Rittmann, I've noticed that some sources like this one are not being processed anymore, or only extremely slowly. Jo-Jo Eumerus (talk) 16:30, 27 January 2020 (UTC)

@Jo-Jo Eumerus: It's not totally clear what you mean by "not being processed". GMGtalk 18:12, 27 January 2020 (UTC)
It means that Citoid used to work on that source and now no longer does. Jo-Jo Eumerus (talk) 19:23, 27 January 2020 (UTC)
Maybe some transient problem? It's working fine for me, in a second or two.[1] If you're using Chrome (maybe other browsers have something similar?), you might try View/Developer/JavaScript Console if this persists for you. Under the Network tab, you should be able to see the URL being fetched, and any errors that happen. You need to be a bit tech-savvy to interpret the output, however. -- RoySmith (talk) 02:55, 28 January 2020 (UTC)


  1. ^ Bargagli, R.; Broady, P. A.; Walton, D. W. H. (1996/06). "Preliminary investigation of the thermal biosystem of Mount Rittmann fumaroles (northern Victoria Land, Antarctica)". Antarctic Science. 8 (2): 121–126. doi:10.1017/S0954102096000181. ISSN 1365-2079. Check date values in: |date= (help)

Can you see a diff if numerous edits have a line through them?[edit]

At some point there was oversight but this involved many diffs. Is there a way for the software to show diffs that don't involve what was oversighted, should someone want to know the diff?— Vchimpanzee • talk • contributions • 18:02, 27 January 2020 (UTC)

Hey @Vchimpanzee:. It looks like the edits were redacted (an administrator ability) rather than oversighted (only available to Overighters and Stewards). But in a nutshell, no. The only way to access the content is to contact someone who does have the ability to view it and ask them to provide information about it. GMGtalk 18:11, 27 January 2020 (UTC)
So a person would have to really want it. I knew oversight might not be the correct term.— Vchimpanzee • talk • contributions • 18:22, 27 January 2020 (UTC)
Vchimpanzee, That information was removed using a process called revision deletion. It was hidden because it was a copyright violation. One annoying fact is that if you detect a copyright violation in one revision, you have to revision delete that version and all subsequent versions up to the point of the removal, so one should not conclude that every one of those edits are themselves problematic. If you have a decent reason for asking, other than just casual curiosity, I am sure just about any admin, including myself, would be happy to give you more information. S Philbrick(Talk) 18:32, 27 January 2020 (UTC)
Right. I knew most of those edits were not a problem but for the first time I realized there might be an important reason for knowing one of those diffs, but I don't have one in this case.— Vchimpanzee • talk • contributions • 18:34, 27 January 2020 (UTC)
Yes, WP:Revision deletion is the correct term. I just got used to saying "redaction" to avoid jargon with new users. GMGtalk 18:38, 27 January 2020 (UTC)

Tech News: 2020-05[edit]

18:52, 27 January 2020 (UTC)

Downloading a page's history[edit]

I want to download the history of Wikipedia:April Fools/April Fools' Day 2019, to make a fun little thing. How would I go about downloading it? --moonythedwarf (Braden N.) 20:26, 27 January 2020 (UTC)

@Moonythedwarf: if you go to Special:Export you can download the complete history of the page. — xaosflux Talk 20:34, 27 January 2020 (UTC)
@Xaosflux:: Can't, Wikipedia:April Fools/April Fools' Day 2019 has more than 1000 revisions (roughly 1500 need exported) --moonythedwarf (Braden N.) 20:38, 27 January 2020 (UTC)
@Moonythedwarf: then you would need to go to a dump. Do you only need the list of contributors, or actually every revision? — xaosflux Talk 20:40, 27 January 2020 (UTC)
Xaosflux, Genuinely need every revision. I'm trying to make a history that exclusively shows the changes to "The section title of the article that people kept edit warring over" moonythedwarf (Braden N.) 20:44, 27 January 2020 (UTC)
Ah foo, I do not have the storage space to store a revision dump :< moonythedwarf (Braden N.) 20:45, 27 January 2020 (UTC)
Is this 10 year old suggestion still working? —Kusma (t·c) 20:49, 27 January 2020 (UTC)
Kusma, Possibly. I'll check in a little moonythedwarf (Braden N.) 20:54, 27 January 2020 (UTC)
Moonythedwarf, I guess this makes you the Lone Ranger...because you're going to-the-dump, to-the-dump, to-the-dump-dump-dump! creffpublic a creffett franchise (talk to the boss) 20:55, 27 January 2020 (UTC)
Creffett, The fact I genuinely live in texas makes this joke even worse. moonythedwarf (Braden N.) 20:57, 27 January 2020 (UTC)
@Kusma: that link can be hit-or-miss, with this one only being 1138 revisions it may work. — xaosflux Talk 20:59, 27 January 2020 (UTC)

Should we have a "retroactive URL blacklist" for poisoned domains?[edit]

The Shlayer trojan horse thread above (permanlink) got me thinking:

If we know a URL or domain had become compromised either temporarily or permanently and is serving up malware, we should be able to reformat pages that include this URL so the link cannot be clicked on by a user. URLs can be added to the blacklist as needed and removed when they are no longer toxic.

This would require a code change which is why I am proposing it here. davidwr/(talk)/(contribs) 23:06, 27 January 2020 (UTC)

@Davidwr: that wouldn't be a code-change here on the English Wikipedia, it would require a mediawiki code change. You can request that here: Wikipedia:Bug reports and feature requests. — xaosflux Talk 23:59, 27 January 2020 (UTC)
True, but seeing how the English Wikipedia is the largest one, I wanted to get a sense of "is this a good idea" from editors here first. davidwr/(talk)/(contribs) 00:05, 28 January 2020 (UTC)
I think it sounds like a good idea in principal, but think that any technical implementation would be a huge problem (as those text links are on every cached page for readers). — xaosflux Talk 00:10, 28 January 2020 (UTC)
The blacklist is implemented by mw:Extension:SpamBlacklist. The closest request I found is phab:T18326 from 2008: "spam blacklist should replace blacklisted links with a safe special page". It suggests to disable all blacklisted links and not to make an option for individual links. PrimeHunter (talk) 00:16, 28 January 2020 (UTC)
At this point I am skating on a thin layer of knowledge over a deep abyss of ignorance. But proceeding on: how would such blacklisting work at the level of the article? Perhaps revise the url to go to internal link that explains the situation? Or? ♦ J. Johnson (JJ) (talk) 23:07, 28 January 2020 (UTC)

Post 6 million article reflections: What does Wikipedia do "wrong" technically?[edit]

Having just passed the 6 million article mark, it's clear that Wikipedia is going to be around for a long time. Maybe it's time for some introspection. What do you think are major technical decisions in the design of Mediawiki, that were mistakes in hindsight? I will mention the two that I think were particular bad:

  • Wikitext itself is not defined by a grammar. As for the markup itself, the use of the same character to markup bold and italics, in particular, seems like a mistake.
  • Talk pages and the way we use them are a disaster.

With the wikitext, I don't know what the current status is but there have been efforts to define Wikitext. Those should be high-priority efforts by the WMF. As our article count grows, so too does the need for automated parsing. This is an issue where the technical debt will get worse with time and make the encyclopedia harder to maintain. (If my understanding about the current status is out-of-date, please point me to updates.)

As for threads, some sort of threaded implementation is needed. mw:Structured Discussions is our attempt but so far the first implementation, Flow, has been unacceptable. Something more compact and minimal in style like reddit's comment system would have been leaps and bounds better. One of the major complaints I have is that the entire concept of "archiving" or closing discussions, where we tell users to not to add to an older discussion, is a big mistake. One should ALWAYS feel free to add to a discussion even if you are years late to the action. Why? Because people still read those discussions years late too. It doesn't make sense to leave questions unanswered just because nobody arrived in time to answer them or not to post a winning idea because you as a late arrival were the first to have it. Even when the user is still motivated enough to start a new discussion (and not all will be), it often doesn't make sense to fragment the discussion this way because it often leads to pragmatic issues because the new thread doesn't link to the original discussion. Plus too, the rate of discussion is dramatically different depending on the article so it's hard to even define what "late" to a discussion even means. It is normal to wait years for a question to be answered on a very obscure or highly technical article.

I've always felt like our subpage system could be modified to handle talk discussions. (I've been under the impression for a long time that this was one of our Wikipedia:Perennial proposals but maybe not.) Picture this: a new threaded discussion could be started as a subpage of the talk page, replies as sub-subpages to that subpage, replies to replies as sub-sub-pages, and so on. The talk page itself would be generated by Mediawiki to show threads (subpages) with most recent activity. I think this idea could work brilliantly. 1) Threaded discussion (as a tree) is enforced by the storage of the data itself. 2) It would discourage the accidental editing of other's comments while still allowing for it when needed (with isolation of the history of modification to just that particular comment). Subpages NOT intended to be discussions could be marked so they are excluded from auto-generation of the talk page. I think this has HUGE potential for revolutionizing the way we handle discussions. It would also eliminate the need for our clumsy archiving process.

Anyway, those are the top two problems that I'd like to see be fixed so future generations of editors aren't saddled by poor decisions forever. Fixing each of these would require some work but I think the WMF and the community could tackle these. What do you think? What about your own pet peeves? Jason Quinn (talk) 04:36, 28 January 2020 (UTC)

Without comment on the general concept of modifying talk pages, you have pretty much described Flow, which worked on the tree discussion model and each thread as a subpage. Risker (talk) 06:08, 28 January 2020 (UTC)
We did just hold an immensely detailed cross-project talk page consultation on this issue, which seems to have given preference for an improved version of the current setup, designed to be more user-friendly, rather than any whole-hearted shift. Nosebagbear (talk) 09:50, 28 January 2020 (UTC)

@Jason Quinn: Also, the parsing of Wikitext has been made much more rigorous with the creation of Parsoid, which is now the definitive parser for Wikitext, and therefore also acts as the de-facto specification for that notation. It has a much cleaner internal architecture than the previous software, and in particular, the low-level tokenizer is now defined rigorously in terms of a Parsing Expression Grammar, making things like the apostrophe ambiguity at least well-defined, if not sensible. -- The Anome (talk) 12:07, 28 January 2020 (UTC)

@Jason Quinn, @The Anome 'pings' notify when the addressee, the text, and the signer are edited in one, unitary message. --Ancheta Wis   (talk | contribs) 12:25, 28 January 2020 (UTC)
Alright, add that to the list: forgetting a ping is so user-unfriendly that people mess it up in a discussion about wikitext parsing. (Edit summary pings have helped in this area though.) --AntiCompositeNumber (talk) 12:41, 28 January 2020 (UTC)
Absolutely. If "belated ping" happens this often, it's no longer a user mistake, it's a use case. Just check if the editing user account name matches the account name in the signature (even if it's already there on the page), and if so, trigger the ping event. -- The Anome (talk) 18:12, 28 January 2020 (UTC)
The Anome, A {{#ping:The Anome}} parser function might be a better idea, to explicitly say "Yes, I want to ping this person". If it gets evaluated in the expanded wikitext, send a notification. --AntiCompositeNumber (talk) 18:36, 28 January 2020 (UTC)
The main reason to require a signed edit is to avoid unwanted pings when you refactor or archive a talk page or copy existing posts, and the diff engine detects a userpage link in your edit. A parser function wouldn't change that problem unless it saved something else (or nothing) to indicate the ping is old and should not be repeated if the saved code is copied later. PrimeHunter (talk) 22:37, 28 January 2020 (UTC)
  • Our Main page is in need of some technical upgrades, especially so we can take back control of how it appears to mobile users. This has been challenging to deal with in the past, as efforts to improve technical components often creep in to "content" management - even when they don't have to. — xaosflux Talk 12:17, 28 January 2020 (UTC)
  • I don't care too much about the talkpages and wikitext - yes, it could be improved but both do properly serve their purpose and do not really pose a problem. I am much more worried by the total neglect of bugs and maintenance on some very old extensions. My pet peeve is there the spam-blacklist extension, but also our AbuseFilter and CheckUser and similar are in a very bad shape (the latter now does get some attention). There are bug reports of more than 10 year old that nonetheless are still utterly ignored. --Dirk Beetstra T C 12:27, 28 January 2020 (UTC)
    • Yes, considering the scale of the WMF's budget, it would be good to see some more of it spent on software maintenance, rather than just developing new features. -- The Anome (talk) 12:34, 28 January 2020 (UTC)
    +1 to that. It seems that once a WMF team declares a project "good enough for production", all development effort stops. I have noticed that WMF development teams have been starting to be more explicit about their development priorities (or lack thereof). This is a good start, but doesn't actually help anything get fixed. --AntiCompositeNumber (talk) 12:47, 28 January 2020 (UTC)
    +2. I would much rather see a massive bug-fixing effort than yet another new approach that is then essentially abandoned at the late beta / 1.0 stage with hundreds of unpleasant bugs outstanding. – Jonesey95 (talk) 15:16, 28 January 2020 (UTC)
    If we're in the business of spit-balling crazy ideas, I personally don't care for visual editor, and I don't understand edit filters, but it would be super helpful to have a visual editor for edit filters. GMGtalk 15:19, 28 January 2020 (UTC)
    • Yes, and this applies to other tools too. For example, I have a five year old request for a simple feature addition to navigation popups, to make them show Wikidata IDs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:53, 28 January 2020 (UTC)
  • The biggest thing in my mind is how we edit articles. Visual Editor is a great step forward, but it's not done yet. Improving VE, and especially citation handling, should be one of the highest priorities. We need to get it to the point where it's the default editor. -- RoySmith (talk) 17:16, 28 January 2020 (UTC)
    • RoySmith, before we could do that, we'd have to have a long discussion about what it means for any piece of software to be "the default editor". There are many Wikipedias at which a majority of editors use the visual editor (i.e., the visual mode, showing rich text, not mw:Extension:VisualEditor's wikitext mode, which we usually call the 2017 wikitext editor) for at least some edits. There are many editors who use it exclusively. Some editors care about what's popular, rather than what's good for a particular purpose. One of the problems we've had in deciding which is more popular is that we don't tag all the editing environments that are used on wiki. Looking at the 500 most recent non-bot changes to articles here, I can tell you that 7 happened in Twinkle, 8 used STiki, 5 used HotCat, 1 used AutoEd, and that at least 40 used AWB ("at least", because only some AWB users tag their edits with that tool). 22 used the visual editor on desktop, 12 used the visual editor on mobile, and 10 the 2017WTE, which is part of VisualEditor. 57 used the wikitext mobile web editor. But how many of the other ~350 edits used the 2010 wikitext editor? Or WikEd? Or the 2003 editor? Or another editing environment? Or didn't really use any editing environment? Nobody really knows. I've heard estimates that around half of edits on this wiki are bots or use scripts (like Twinkle), but we don't know whether, say, WikEd is used for more edits than the 2003 wikitext editor. Whatamidoing (WMF) (talk) 19:58, 28 January 2020 (UTC)
      • I'm talking about what a brand-new desktop user sees for the first time. Not bots. Not power-users with AWB, Twinkle, etc. Open an incognito window in your browser. Go to Click the edit tab. Right now, you get taken to a "Welcome to Wikipedia" screen, with two buttons: "Switch to the visual editor", and "Start editing". The very first thing a new user is confronted with is the requirement to make a choice that they can't possibly understand the implications of. That's a problem. They should just be immediately dropped into the Visual Editor, but along with that, VE also has to improve. And, yeah, it has to work on talk pages too. -- RoySmith (talk) 20:33, 28 January 2020 (UTC)
        • We could probably get the devs to make that change (newbies at enwiki start in the visual mode, just like they do at many other wikis), but it'd probably take a local RFC, because of the history of individuals making contradictory pronouncements about what The Community™ wants. As for using it on talk pages, see #Eventualities. Whatamidoing (WMF) (talk) 20:53, 28 January 2020 (UTC)
  • Speaking of the 2019 Talk Page Consultation, would you all please go to and log in (unless you want your IP address exposed) and try out the "Reply" tool. mw:Talk pages project/replying/prototype testing suggests a testing script to follow. Feedback can go on the talk page, or ping me, and I'll pass it along. Whatamidoing (WMF) (talk) 20:06, 28 January 2020 (UTC)
@Whatamidoing (WMF) I can post my just-now experience on the beta.wmflabs with a blow-by-blow set of hints for just getting to respond on Talk:Dog. Would you like this? I can put these hints on your talk page for now. --Ancheta Wis   (talk | contribs) 21:07, 28 January 2020 (UTC)
@Whatamidoing (WMF):, am I supposed to see something different on the beta Dog talk page? I don't see any options other than the normal "edit" links next to each section. --Ahecht (TALK
) 22:07, 28 January 2020 (UTC)
  • We breach the principles of DRY ("Don't repeat yourself"), on a massive scale. For example, by storing citation metadata dozens - sometimes thousands - of times in individual articles rather than one, centrally. And we're currently importing six million subject descriptions from Wikidata, rather than working with the Wikidata community - our colleagues and friends, and in some cases ourselves - to develop common standards, and then transclude them. For a volunteer project with a surfeit of outstanding tasks, such behaviour is self-harming. A professional organisation would prohibit such nonsense. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:48, 28 January 2020 (UTC)

Dreadful watchlist changes[edit]


Is anyone able to help me out with this problem? SandyGeorgia (Talk) 18:50, 28 January 2020 (UTC)

Following the breadcrumbs, I can confirm my eswiki watchlist looks the same as my enwiki watchlist. The new watchlist is now fairly old, and the notification (dialog box) in eswiki watchlist you're talking about is about the new filtering system, which you also received on enwiki, you probably just don't recall clicking on it. The normal settings would be to have subtle markers and green collapsible arrows unchecked and the rest of the boxes checked in your preferences under "Watchlist". Do that, clear the cache and reload your watchlist. What's the browser and device you're using? --qedk (t c) 18:58, 28 January 2020 (UTC)
@QEDK: thanks for the help. I have looked at this on three different computers, with four different browsers, (PC, MacBook and IPad), and the problem is the same on all three, so I don't think that's it. I can't find the settings you mention under Preferences --> Watchlist ... could you walk me through it? Sheesh, I need to get a cot in here. SandyGeorgia (Talk) 19:11, 28 January 2020 (UTC)
By all means, why not, we also have bellinis or jack on the rocks, if that's more your style. Face-wink.svg Good to hear it's all resolved now. --qedk (t c) 20:13, 28 January 2020 (UTC)
SandyGeorgia, I've had a similar problem recently. If you turn on "Group results by page" anywhere (like Special:RecentChanges), it adds a ton of extra space at the beginning of watchlist lines. Go to Special:RecentChanges, click on the gear dropdown, then make sure the checkbox is unchecked. --AntiCompositeNumber (talk) 19:29, 28 January 2020 (UTC)
Thanks AntiCompositeNumber; that did the trick. Sheesh, what a MISERABLE idea that was! SandyGeorgia (Talk) 19:35, 28 January 2020 (UTC)
User:SandyGeorgia, did you by any chance click on a URL from someone else to RecentChanges? If so, then you might have gotten bit by phab:T202916 (which see if anyone wants a script to automatically un-uglify that mess). Whatamidoing (WMF) (talk) 20:13, 28 January 2020 (UTC)
@Whatamidoing (WMF): No idea ??? I think this happened when I was trying to edit that video ?? Really don't know ... how could I get to someone else's recent changes? (Don't tell me !) SandyGeorgia (Talk) 20:18, 28 January 2020 (UTC)
It's not anyone in particular's edits; it's Special:RecentChanges. We sometimes pass around URLs like (if you click that, you'll find RecentChanges filtered only to show people posting e-mail addresses). I think the "urlversion" bit is the one that tries to change your prefs ...but only in one direction. Whatamidoing (WMF) (talk) 20:26, 28 January 2020 (UTC)

Searching template parameter usage[edit]

Is there any way to identify pages based on the value of a specific parameter within a template? Ideally, I'd like to get a breakdown by category (results being grouped based on each possible value of the parameter), but being able to search for any page where the template has a specific value for the parameter would also work. A way to design a search string that does this would be fine, though I assume that accounting for all of the template redirects would complicate things.

In this particular case, I'm interested in Template:Expert, so the ideal is being able to identify all uses of the template based on parameter value (in other words, Category:All articles needing expert attention grouped by the type of expert requested). In contrast, the minimum result I'm hoping for is to identify all uses of the template that request a particular type of expert. Thanks! Sunrise (talk) 22:45, 28 January 2020 (UTC)

External link categories, again[edit]

Hello, all,

Three weeks ago I started a thread about all of these empty categories featuring foreign language external links (see Wikipedia:Village_pump_(technical)/Archive_178#Foreign_language_external_link_categories for the discussion) and a lot of technical information was provided that I did not understand.

To update you all, some of these empty categories were deleted weeks ago, with seemingly no issue (I was never asked to restore them) but there are still quite a lot that appear on Wikipedia:Database reports/Empty categories, our empty categories list. I asked our most active empty category tagger to hold off on tagging them for deletion but from what I could understand reviewing the previous discussion (which truthfully wasn't a lot), these suddenly empty categories are due to a change in some template. Since these categories have not been repopulated in three weeks, is it safe to delete them? Or does some edit have to be made somewhere and, poof!, these categories will be filled? Your nontechnical advice would be most welcome! Liz Read! Talk! 23:32, 28 January 2020 (UTC)