Wikipedia:Village pump (technical): Difference between revisions

Policy

Technical

Proposals

Idea lab

WMF

Miscellaneous

• Table of contents
• First discussion
• End of page
• New post

Shortcuts

• WP:VPT
• WP:VP/T
• WP:TECHPUMP
• WP:PUMPTECH

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.

view · edit Frequently asked questions (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). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their 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 Help: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 Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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 https://www.example.com instead of https://www.example.com. 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)[reply]

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)[reply]

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)[reply]

I was responding to the issues raised in the original post, and following up the message which stated ...so 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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Quick note with a couple of related points:

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

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

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

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

Vector is terrible. It's an ugly canker, showing the absolute best of 1990s web design. The WMF should focus its efforts on Timeless and enter the 20th century.--Jorm (talk) 20:36, 18 January 2020 (UTC)[reply]

@Jorm: Isn't it too late to enter the 20th c.? CiaPan (talk) 23:08, 18 January 2020 (UTC)[reply]

d'oh!--Jorm (talk) 23:19, 18 January 2020 (UTC)[reply]

I want a highly-polished mahogany cabinet with scrollwork, an engraved brass front panel, and carefully-calibrated vernier dials. Some nice warm Nixie tubes would be good. Ivory bars (cracked or otherwise) are optional, but nickel bars must not be exactly one inch too short and there needs to be one more drop of oil on the quartz rod. --Redrose64 🌹 (talk) 11:20, 19 January 2020 (UTC)[reply]

I'm willing to file that feature request, but only if you demonstrate community consensus and have volunteers lined up to keep the scrollwork dusted. Whatamidoing (WMF) (talk) 00:55, 20 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

And it happened when I saved the above. Graham Beards (talk) 22:15, 17 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

Thanks guys. It makes sense now - my mouse has been misbehaving on scrolling. Graham Beards (talk) 22:35, 17 January 2020 (UTC)[reply]

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)[reply]

Thanks talk, Graham Beards (talk) 08:17, 18 January 2020 (UTC)[reply]

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

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)[reply]

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)[reply]

phab:T213515 says the tool needs co-maintainers – Ammarpad (talk) 04:55, 18 January 2020 (UTC)[reply]

Caterpillar84, reFill and the visual editor use the same backend service, mw:citoid. If you open the visual editor (e.g., https://en.wikipedia.org/w/index.php?title=Kim_Fountain&veaction=edit ) 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

I actually pinged Cyberpower678 on the Refill talk page on 16 January 2020 with no response.— TAnthony^Talk 22:04, 19 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Barring that, write good documentation. --AntiCompositeNumber (talk) 01:13, 20 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Still not working, tried several times today...is 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)[reply]

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: https://tools.wmflabs.org/refill/ng/

French uses:

https://tools.wmflabs.org/refill/index.php

https://tools.wmflabs.org/refill/result.php

24.7.104.84 (talk) 01:44, 21 January 2020 (UTC)[reply]

See: https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js&action=history

Broken 06:12, 11 January 2019‎ Reflinks.js

https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js&oldid=18773634

Good Old 00:45, 3 April 2018‎ Reflinks.js

https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js&oldid=17896018

https://en.wikipedia.org/wiki/User:Zhaofeng_Li/reFill says at Toolbox link :

Insert this code into Special:MyPage/common.js:

mw.loader.load( "https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js&action=raw&ctype=text/javascript" );

so I guess a workaround is :

copy over to https://en.wikipedia.org/wiki/User:YOURNAME/ReflinksOLD.js the file:

https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js&oldid=17896018

Insert this code into Special:MyPage/common.js:

mw.loader.load( "https://en.wikipedia.org/w/index.php?title=User:YOURNAME/ReflinksOLD.js&action=raw&ctype=text/javascript" );

Nothing in Refill at 'https://github.com/zhaofengli/refill has changed in 12 months. It seems the only change is at https://meta.wikimedia.org/w/index.php?title=User:Zhaofeng_Li/Reflinks.js and https://tools.wmflabs.org/refill/index.php"

If there is revision history at https://tools.wmflabs.org a https://tools.wmflabs.org/refill1/index.php could be made.

The only other editor is https://github.com/JJMC89

24.7.104.84 (talk) 02:44, 21 January 2020 (UTC)[reply]

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)[reply]

Thank you all very much for looking into this and have it running again. Lotje (talk) 16:58, 23 January 2020 (UTC)[reply]

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

Willbb234, At Wikipedia:Twinkle/Preferences. Find " Keep a log in userspace of all CSD nominations" and " Keep a log in userspace of all pages you tag for PROD" then click on the tick box. After that click on save changes. Now when you nominate something for CSD or Prod it will keep a log of it. ~~ CAPTAIN MEDUSA^talk 13:18, 19 January 2020 (UTC)[reply]

CAPTAIN MEDUSA I have already done that (see User:Willbb234/CSD log). My question is should it being showing CSDs prior to creating the log? Willbb234^Talk (please {{ping}} me in replies) 13:24, 19 January 2020 (UTC)[reply]

Willbb234, you'll have to do that manually. There isn't anything about that... ~~ CAPTAIN MEDUSA^talk 13:27, 19 January 2020 (UTC)[reply]

The CSD log is just a wikipage generated from the time you tick the tickmark. You can go and add the ones from prior, if you can find them, but the tool doesn't know any better than you do which those are, so it doesn't. --Izno (talk) 14:55, 19 January 2020 (UTC)[reply]

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)[reply]

Well, this edit did not add this page to my list, confused. - FlightTime (open channel) 15:38, 19 January 2020 (UTC)[reply]

@FlightTime: If the issue persists, you should report it to Phabricator. --qedk (t 桜 c) 13:33, 20 January 2020 (UTC)[reply]

@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)[reply]

That sounds good yep. (well, hopefully ¯\_(ツ)_/¯) --qedk (t 桜 c) 15:54, 20 January 2020 (UTC)[reply]

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

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

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)[reply]

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)[reply]

Thanks Trialpears, I wonder if the frequency of the cache update has changed recently? Thanks, Britishfinance (talk) 16:00, 20 January 2020 (UTC)[reply]

@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)[reply]

I have no information about this. Whatamidoing (WMF) (talk) 19:23, 20 January 2020 (UTC)[reply]

Resolved

 – message updated. — xaosflux ^Talk 15:37, 21 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

@xaosflux: ≡ → Advanced settings → Display title → circled i (right hand side). --bdijkstra (talk) 15:51, 20 January 2020 (UTC)[reply]

@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)[reply]

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)[reply]

@Gonnym: Couldn't agree more, but I hit a wall at VisualEditor/Feedback#Disambiguation tickbox. --bdijkstra (talk) 15:51, 20 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

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)[reply]

So commenting it out, just like you could do for categories, should work well. — xaosflux ^Talk 16:43, 20 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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)[reply]

19:40, 20 January 2020 (UTC)

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)[reply]

@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)[reply]

I updated the Wikidata entry so now it should work fine. --qedk (t 桜 c) 20:12, 20 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

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)[reply]

Oh - right - duh. Thanks! Sam Walton (talk) 18:13, 21 January 2020 (UTC)[reply]

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)[reply]

 Works for me @CASSIOPEIA: would you try again? — xaosflux '^Talk 02:16, 22 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

Nick Moyes Thanks for the info. Cheers. CASSIOPEIA^(talk) 11:02, 22 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Does selecting "Hide transclusions" in the Filters box produce the results you want? isaacl (talk) 01:23, 23 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@Johnuniq: This is caused by https://gerrit.wikimedia.org/r/plugins/gitiles/mediawiki/core/+/c9c1ebd330fb402e66bbba2b1c5dc7562a07eb27/includes/actions/pagers/HistoryPager.php#565 - setting it to 'oldid' => 'prev', like on line 546 above, should fix it. DannyS712 (talk) 08:47, 23 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

Thanks for the offer. I created phab:T243569. Johnuniq (talk) 02:46, 24 January 2020 (UTC)[reply]

@Johnuniq: Happened to be on phab right now - thanks DannyS712 (talk) 02:49, 24 January 2020 (UTC)[reply]

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|https://www.billboard.com/artist/{{{artistid}}}/{{BillboardEncode|{{{artist}}}}}/chart?f={{{chartnum}}}|https://www.billboard.com/artist/{{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)[reply]

Because the page Template:Single chart itself doesn't transclude {{BillboardID}}. Nardog (talk) 11:07, 23 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

You can follow up at User talk:Writ Keeper. — xaosflux ^Talk 12:55, 23 January 2020 (UTC)[reply]

Resolved

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

Resolved

--qedk (t 桜 c) 15:15, 23 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

Thanks, QEDK Jo-Jo Eumerus (talk) 15:14, 23 January 2020 (UTC)[reply]

Glad to help! --qedk (t 桜 c) 15:15, 23 January 2020 (UTC)[reply]

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 archives –84.46.53.160 (talk) 07:45, 24 January 2020 (UTC)[reply]

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 (talk • contribs) 10:32, 24 January 2020 (UTC)[reply]

Thanks, I hope it is {{tracked}} on Phabricator. –84.46.53.160 (talk) 13:35, 24 January 2020 (UTC)[reply]

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

Take this map as an example:

Lo Wu

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)[reply]

@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)[reply]

I've used the {{Annotated image}} template on your image above.   Jts1882 | talk  14:25, 24 January 2020 (UTC)[reply]

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

I guess you could try deleting at least 825 articles? Martinevans123 (talk) 12:36, 24 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

If it's got an expiration date, then no problem. GoodDay (talk) 12:41, 24 January 2020 (UTC)[reply]

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)[reply]

@Vchimpanzee: see above. — xaosflux ^Talk 22:34, 24 January 2020 (UTC)[reply]

@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(//upload.wikimedia.org/wikipedia/commons/d/d6/Wikipedia-logo-v2-en.png); }

--Ahecht (TALK
PAGE) 20:02, 25 January 2020 (UTC)[reply]

That's over my head techno stuff. I'll just wait for the banner to expire. GoodDay (talk) 20:04, 25 January 2020 (UTC)[reply]

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)[reply]

How do I keep the globe, but delete the banner? GoodDay (talk) 01:27, 26 January 2020 (UTC)[reply]

@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)[reply]

Yeah. Ahecht's suggested move would open my account up to hacking. Too risky. GoodDay (talk) 02:15, 26 January 2020 (UTC)[reply]

@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)[reply]

It's alright. The banner is gone. GoodDay (talk) 16:49, 26 January 2020 (UTC)[reply]

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)[reply]

Only stewards from metawiki can review them. Asking here is useless. Ruslik_Zero 19:10, 24 January 2020 (UTC)[reply]

Note that one can override global blocks locally, at Special:GlobalBlockWhitelist. Jo-Jo Eumerus (talk) 19:26, 24 January 2020 (UTC)[reply]

Resolved

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)[reply]

@WhatamIdoing:  Done --qedk (t 桜 c) 19:01, 24 January 2020 (UTC)[reply]

Thank you WhatamIdoing (talk) 23:11, 24 January 2020 (UTC)[reply]

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)[reply]

The ZoomOnThumb gadget has been available for years on fr.wiki 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 en.wiki) 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 en.wiki 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)[reply]

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

@Tonymec: It was? DannyS712 (talk) 22:18, 24 January 2020 (UTC)[reply]

@DannyS712: Yes, see User talk:DannyS712#"Page has been changed" but I see no change — Tonymec (talk) 22:54, 24 January 2020 (UTC)[reply]

@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)[reply]

@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 fr.wiki, 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 fr.wiki 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 en.wiki prefs page, tell me what, anybody, and I'll do my best. — Tonymec (talk) 22:44, 25 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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

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)[reply]

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)[reply]

Awesome, thanks! SandyGeorgia (Talk) 16:39, 25 January 2020 (UTC)[reply]

@SD0001: I can't make it work, and can't find instructions :( SandyGeorgia (Talk) 16:46, 25 January 2020 (UTC)[reply]

@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)[reply]

@SD0001: got it, thanks (I had failed to check the user namespace). SandyGeorgia (Talk) 18:29, 25 January 2020 (UTC)[reply]

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)[reply]

@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)[reply]

@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)[reply]

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)[reply]

@SandyGeorgia: does this do what you want? — xaosflux ^Talk 17:27, 26 January 2020 (UTC)[reply]

@Xaosflux: brilliant, thanks! SandyGeorgia (Talk) |

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)[reply]

 Done – Jonesey95 (talk) 18:00, 25 January 2020 (UTC)[reply]

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)[reply]

Can we just have VE disabled? :-] ♦ J. Johnson (JJ) (talk) 23:58, 25 January 2020 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

@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)[reply]

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)[reply]

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).[reply]

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)[reply]

@Синкретик: The help namespace is part of the mediawiki core - see, eg, here DannyS712 (talk) 10:42, 26 January 2020 (UTC)[reply]

Синкретик, 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)[reply]

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).[reply]

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)[reply]

Intermittent site unavailable in Western Europe

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).[reply]

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

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)[reply]

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

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).[reply]

I am in Northern California and I have been experiencing very slow access and 504 timeouts for about an hour. Cullen³²⁸ Let's discuss it 20:37, 26 January 2020 (UTC)[reply]

Access has improved for me in recent minutes. Cullen³²⁸ Let's discuss it 21:03, 26 January 2020 (UTC)[reply]

Was having issues previously and i'm in Texas. Seems to be over now? --moonythedwarf (Braden N.) 21:06, 26 January 2020 (UTC)[reply]

Had problems all day however it seems to have been resolved within the last few minutes, In the UK & added cmnt to ticket, Cheers. –Davey2010^Talk 21:10, 26 January 2020 (UTC)[reply]

Server problems

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)[reply]

Error

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

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

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

Request from 98.21.227.217 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)[reply]

Serious Connection Issues

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

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)[reply]

Hi,

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)[reply]

Google only allows so many tries per day, the are used up today. You can follow up at User talk:Earwig. — xaosflux ^Talk 21:05, 26 January 2020 (UTC)[reply]