Wikipedia:Village pump (technical)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

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.

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

Eventualities

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 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)

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

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?

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

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

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., 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)

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.— TAnthony^Talk 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 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)

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)

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)

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. Lotje (talk) 16:58, 23 January 2020 (UTC)

Intrusively unpleasant animated advertising banner

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)

Earwig's Copyvio Detector

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) —Preceding undated comment added 02:27, 28 January 2020 (UTC)

Lupin's Spellchecker not working

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?

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

Tracked in Phabricator
Task T243569

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 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)

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

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)

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)

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)

Resolved

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

Resolved

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

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)

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)

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

Interactive map

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)

@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

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

--Ahecht (TALK
PAGE) 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

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)wikimedia.org. — 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

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)

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

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

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)

ZoomOnThumb

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)

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 change — Tonymec (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 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)

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, en.wiki. — 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

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

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

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

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?

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)

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

Disabling the visual editor's find-and-replace

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)

Just a note: before anyone starts ranting about what a piece of **** VE is, the problem of two different programs responding to the same keystroke is not unique to VE. At work I run a KVM program to access servers running Linux on a Windows 10 laptop. When I have a KVM window open to a given server & switch between virtual screens on the server with the F2, F3, F7, etc. keys, whenever I return to my original virtual screen with the F1 key, not only do I return to my original virtual screen inside the KVM window, but I bring up this utility that offers to modify the settings on my monitor. It is annoying, but I don't have the luxury of applying the simplest & best fix -- uninstalling Windows. -- llywrch (talk) 19:37, 29 January 2020 (UTC)

Polluted categories

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)

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?

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 securelist.com. 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 archive.org 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

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

Tracked in Phabricator
Task T243713

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

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. Cullen³²⁸ Let's discuss it 20:37, 26 January 2020 (UTC)

Access has improved for me in recent minutes. Cullen³²⁸ 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. –Davey2010^Talk 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

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)

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)

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 en.wikipedia.org. 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

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 [2] suggests it was an intentional DDoS. But I wouldn't say Bryant's death was unrelated either. If you look at [3] and compare to the editing history of Kobe Bryant [4] 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 [5]. 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 (talk • contribs) 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 [6], 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

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, grafana.wikimedia.org is as hard to grasp as a nuclear plant control room and status.wikimedia.org 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. [7]. 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. [8]. --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

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. GMG^talk 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 (talk • contribs) 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

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)

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

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

​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". GMG^talk 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. 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)

References

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

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. GMG^talk 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. GMG^talk 18:38, 27 January 2020 (UTC)

Tech News: 2020-05

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Problems

• Some mobile diffs have problems. A couple of buttons are not shown. Structured data diffs on Commons are confusing. The developers are working on fixing it. [9][10]
• Administrators on wikis that use Structured Discussions can't move discussion pages. This is a bug. The developers are working on fixing it. [11]

Changes later this week

• There is no new MediaWiki version this week.

Future changes

• There is JavaScript code on Special:Undelete for administrators that makes it possible to automatically select multiple checkboxes by holding the "Shift" key and clicking. This code is also loaded by accident on other special pages and on articles. This makes pages slower to load. This will be fixed. If you know of other special pages where this is useful please tell the developers at phab:T232688.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

18:52, 27 January 2020 (UTC)

Downloading a page's history

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?

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?

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)

The reason I heard why Flow was never adopted (besides being tightly integrated with VE, which was received with a marked lack of enthusiasm) was that no one could figure out how to port all of the old discussions into Flow. IMHO, & speaking from my experience with computers, is that the old discussions should have been left alone & everyone used Flow (or whatever) from a given point on. As long as it worked, after the first few weeks of bitching from one & all, it would have been accepted. (Or maybe the response to VE dissuaded those who made the decisions from implementing Flow, because without the first the second wouldn't work.) -- llywrch (talk) 00:34, 29 January 2020 (UTC)

Nope, it just had so many many issues and many people had "showstopper" type issues (and there were many of these) - one of mine is infinite scrolling - YUCK. — xaosflux ^Talk 00:46, 29 January 2020 (UTC)

Second the disdain for infinite scrolling. Also second that Flow had more issues than just how to import old discussions. As I said above, the style was far too "fluffy" and not compact enough. As for old discussions, I think my idea of using subpages easily handles this: old discussions are simply moved to a special subpage called "old". Done and done. Jason Quinn (talk) 01:45, 29 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)

  @Xaosflux: I tried to nudge the current TemplateStyles proposal implementer but it didn't pan out. Want to make a go at it with me and see how many millions of people we can scare with our horrid web design? :) --Izno (talk) 01:48, 29 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)

  +3. MER-C 15:32, 30 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. GMG^talk 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 Special:Random. 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)
  • @RoySmith: What improvements to citation handling do you see needed in VE? Just curious :) Sam Walton (talk) 23:40, 29 January 2020 (UTC)
    • I don't know how much of what I'm going to say here is VE per-se, how much is Citoid, and how much is just the design of the {{cite}} templates. But, it's all part of the overall UX, which is really all that matters.
    1. It too often can't find the metadata it needs in automatic mode. That's not an easy one to solve, since it's usually a case of the website having sucky markup. But, maybe we could log every URL it fails on, keep track of what domains it fails on the most often, and use that as feedback to build smarter (perhaps domain-specific) parsers.
    2. Related to the above, it too often mis-categorizes things as web, when they really should be book, or magazine, or whatever. And when it does that, it's not easy to fix.
    3. It can be hard to find the field you want. Some of the templates have way crazy number of fields (last2, last3, last4, etc) and you have to scroll through all of those to find what you want.
    4. It should insert the reference in a human-friendly form, i.e. with one field per line. That way, if you need to go in and fix something in source editing mode, it's possible to find what you need to fix.
    5. References get renumbered weirdly in preview mode under certain circumstances (T207182 and T52474)
    6. It should be smarter about integrating edit filters. Try citing this book, for example. You don't get the warning until you actually publish the page. And then you get a dialog box with inscrutable "Dismiss" and "Continue" buttons (I have no idea which button does what). I tried clicking "Dismiss", then I realized I had lost the error message, so I figured I'd just click "Publish" again to see it. To my surprise, the second publish actually published it. Anyway, the warning should come up immediately as soon as you try to insert the reference. Yeah, I know, that's a messy fix because the filter architecture doesn't support that, but it's all part of a bad UX.
  • Don't get me wrong, what we've got now is pretty cool. It just can be a whole lot better/easier, and it needs to get there to make this really usable for newbies. -- RoySmith (talk) 01:03, 30 January 2020 (UTC)
• Speaking of the 2019 Talk Page Consultation, would you all please go to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Dog 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
PAGE) 22:07, 28 January 2020 (UTC)

@Whatamidoing (WMF) and Ahecht: I guess we found a bug here, the "Reply" tool doesn't work if the discussion page has any comments before first section heading, and that page now does thanks to @Ancheta Wis:'s edit. I filed phab:T243869 and submitted a patch to fix this. Matma Rex talk 00:19, 29 January 2020 (UTC)

In the meantime, I've added a section heading, so the 'Reply' buttons are visible again, and any interested person can try out https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Dog . Whatamidoing (WMF) (talk) 23:26, 29 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)

  Pigsonthewing, Sigh. WD has, on a massive scale, imported data without any control. Their anti-vandalism (in the broadest sense of the word) is practically non-existing. We need eons to check all the data and get it up to par, including having proper ways of protecting it. At the moment it is a blessing that some of our featured articles are not using the WikiData data as it has been vandalised without anyone noticing. Tell me, what is the use of a massive amount of data if you have no clue what is blatantly and scarily wrong? Dirk Beetstra ^{T C} 11:46, 29 January 2020 (UTC)

  More hyperbolic criticism of Wikidata not rooted in facts: "without any control" and "practically non-existing" are the scary words folks keep repeating to spread FUD. Wikidata's quality is ever-increasing, with more and more Wikipedia editions using Wikidata-driven infoboxes, bringing more eyeballs and quality checks. Wikidata does need more technical features to help out, like signed statements, but the future is inevitably going to include massive use of Wikidata. The sooner English Wikipedia wakes up to this, the better. Otherwise it's the same old saw: editors are quick to brush off Wikipedia's significant failures while deeming any problems with Wikidata as fatal. As to what Pigsonthewing said above: if we would only consolidate our citations into a structured database via Wikidata or some other system, that would bring orders of magnitude more efficiency to our references, and provide powerful new capabilities around quality, reliability and fact-checking. Rather than English Wikipedia trying to wing it with manual infoboxes, manual citations and manual short descriptions, it should attempt to join the 21st century and start unifying and collaborating. -- Fuzheado | Talk 02:19, 30 January 2020 (UTC)

  Fuzheado, OK, one of the WikiData items connected to one of our Featured Articles here is heavily vandalised, noted by ORES, no-one is doing anything about it (and the infobox on the only project (not a small one) that is using it is hence .. utterly incorrect .. an no-one eyeballs it). There are spamlinks all around (some more than a 1 year old), no-one does anything about it. Some items get spam-links added over and over, and instead of protecting all wikis from that rubbish only after 5 or so attempts of spamming someone protects it (if it even gets detected). And there are continuous attempts to vandalise up to hundreds of pages on all Wikimedia projects that use the data (of which above Featured article is a successful attempt), and that attempt is related to requests like this (if we would grant more sites like that for sites discussed in that thread the vandalism of the Featured article would have succeeded on an earlier attempt by the same user).

  I totally, completely, utterly agree with user:Pigsonthewing that that would be a major improvement, but you really have to get your data correct, protected. There is absolutely no reason that the 'immutable' data is freely editable (read: vandalisable, because that is the only reason to change it), and that is likely even true for a good portion of the other data. You may very well be right that the reliability of WikiData is improving continuously, but you have no clue if you are currently at 10% mistakes, 1% mistakes or at 1-in-a-million mistakes. That you can confidently say that you are improving however suggests that we are more in the percentages than in the parts per million. (and no, WIkiData is NOT a reliable source, it is just as volatile as any wiki). Dirk Beetstra ^{T C} 05:39, 30 January 2020 (UTC)

  I should have added here: now, if WMF had it's antivandalism tools up to date and controlled, then that vandalism would possibly have been detected and reverted (well, ORES did detect it ..). If WikiData had a way to protect correct and immutable data then you at least know that that is good data. At the moment, here on en.wikipedia, and also on WikiData and anywhere else, it is an utter mess. Protect your correct and immutable WikiData data, and you can fully automatically detect that data on en.wikipedia is wrong, and people will trust that data and just re-use the WikiData data. Now, WikiData is just a tool to vandalise up to a couple of hundred of pages across the same number of wikis in one go. --Dirk Beetstra ^{T C} 11:55, 29 January 2020 (UTC)

• It was written in PHP [12][13]. This is one of the underlying reasons why WMF software is so crap. There are other, more competently designed programming languages that are better able to handle the level of complexity of MediaWiki currently, and even more. Ducks and runs. MER-C 15:45, 30 January 2020 (UTC)
  • I feel you. I've done a little PHP work (inherited a project). In the few months I was working with it, I developed a deep loathing for the language. But, I've always looked at Wikipedia and said, "On the other hand, if it was possible to write one of the world's largest websites in PHP, that's obviously evidence that it can be a productive tool". Isn't FaceBook also a PHP shop? Same observation there. For that matter, English is a disaster of a language. The grammar, vocabulary, and spelling are all bizarre. I didn't even know that conjugating verbs was a concept until I learned Spanish in junior high school. Yet, we've managed to make effective use of English in transportation, literature, and information retrieval. There's certainly lots of problems with WikiMedia, but I'd be hard pressed to trace them back to the language it's implemented in. -- RoySmith (talk) 16:20, 30 January 2020 (UTC)
    • True, but it takes more effort, stricter discipline and better software engineers in order to do so. Facebook can afford to pay billions to make that happen. The WMF? Not so much. MER-C 17:12, 30 January 2020 (UTC)

Dreadful watchlist changes

Resolved

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. 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 https://en.wikipedia.org/w/index.php?hidebots=1&hidecategorization=1&hideWikibase=1&hidelog=1&tagfilter=adding+email+address&limit=500&days=30&title=Special:RecentChanges&urlversion=2 (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

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)

I was going to suggest trying bambots at wmflabs but that page shows "The bambots tools have been moved to a new server" with a link to non-WMF site. I thought wmflabs tools were kept with source available for others and I would not feel comfortable using a non-WMF site. Johnuniq (talk) 23:45, 28 January 2020 (UTC)

@Sunrise: Using the search box, you can search for hastemplate:"Expert needed" and you get 4867 total results, or just 4492 in mainspace. So at least you know the size of the job you're looking at. If you can manage with just identifying those with a particular value, such as 'Physics' for example, then the search hastemplate:"Expert needed" insource:/expert[^|]*\| *Physics/ finds all 31 of them. I assume, though, that you'd prefer all 4492 articles broken down by parameter value. That's the sort of job that a bot would do easily enough, and your best bet might be to ask at Wikipedia:Bot requests, although it is backlogged. Perhaps a bot operator who watches this page might be happy to do a run for you. HTH --RexxS (talk) 01:31, 29 January 2020 (UTC)

User:Sunrise, are you looking for Category:Medicine articles needing expert attention or one of the other Category:All expert subject categories? WhatamIdoing (talk) 23:11, 29 January 2020 (UTC)

Yes, actually! Not sure how I missed that. :-) (Also, @RexxS: if you're interested, Category:Physics articles needing expert attention seems to have quite a few additional entries.) Sunrise (talk) 00:24, 30 January 2020 (UTC)

@Sunrise: you're right. My suggested search only finds the articles that ask for a subject expert in Physics as the first topic. I realise now that the parameters |ex2=, |ex3=, etc. need to be taken account of as well. Cheers --RexxS (talk) 01:04, 30 January 2020 (UTC)

External link categories, again

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)

|subscription=yes|

Resolved

Apologies, as I think I've missed something, but has this been deprecated for something else? Thanks all pumpers  :) ——SN54129 10:47, 29 January 2020 (UTC)

I think that nowadays we use other parameters. Jo-Jo Eumerus (talk) 11:34, 29 January 2020 (UTC)

Excellent, thanks very much for your help, Jo-Jo Eumerus! ——SN54129 12:10, 29 January 2020 (UTC)

Is there a list of Mediawiki extensions which Wikipedia uses somewhere

Hi all

I think there is probably a special page somewhere that lists all the extensions the English Wikipedia Mediawiki installation uses , but can't find it anywhere... Any ideas?

Thanks

John Cummings (talk) 11:45, 29 January 2020 (UTC)

Special:Version. PrimeHunter (talk) 11:50, 29 January 2020 (UTC)

Determining what level was edited?

Resolved

Is there any technical way, either available to standard users or not, to tell whether an edit was performed by editing the an entire article, or a section? I'm presuming the actual change is the same, so let's say at article just consisted of

abc
==FOO==
def

and was changed to

abc
==FOO==
ghi

In case 1, the entire article was edited to change def to ghi, in case 2, the section for FOO was edited changing def to ghi.

This is just curiousity given that edits of sections are turned into edits of entire articles in the case of edit conflicts , and my guess is that the information as to what level an edit was performed at simply isn't part of the database and thus it is impossible. Still, I figured the people who would know would hang out here.Naraht (talk) 14:16, 29 January 2020 (UTC)

@Naraht: you can use the non-authoritative automatic edit summary as a hint, it may include the section name. This is not stored on the back-end, however there is a similar request to add a tag to "new" sections (phab:T226563) - you could make a similar request to tag "section edits". — xaosflux ^Talk 15:02, 29 January 2020 (UTC)

@Xaosflux: Yes, but that can be easily spoofed, as in my edit. That happens albo when someone changes the section header and the summary retains its previous contents. --CiaPan (talk) 15:41, 29 January 2020 (UTC)

@CiaPan: indeed that is why I called it out as only a "hint". — xaosflux ^Talk 15:50, 29 January 2020 (UTC)

Thanx to all, that answered my question. (and thanx for the change to the pre tag)!Naraht (talk) 15:57, 29 January 2020 (UTC)

On discussion pages I often spoof a section edit summary when making a page edit to move a new section to the bottom or combine two sections about the same. It seems helpful to give the section name in such edits and enable a section link in the edit summary. And when I change a heading in a section edit, I often make the same change in the edit summary. In September I added an API method to see the source text of an edit summary to Help:Edit summary#Places where the edit summary appears, but it does not reveal whether spoofing was used. PrimeHunter (talk) 19:56, 29 January 2020 (UTC)

Yes, we should automate what User:PrimeHunter already does. If we had very intelligent software, perhaps it could notice that an edit was trying to change the section header, and then place a section link updated with the new name into the draft edit summary. This would help at WP:AN3 where the status of a report goes into the section header (words such as 'Blocked', 'No violation' etc.). This means that in practice, each closed report usually has an out-of-date edit summary. The only way to get a correct edit summary is, if a very picky admin who is in the process of entering the status (whether it is blocked, NV etc) will preview the post before saving, find the new section header in the text of the preview and manually put it into the edit summary field. EdJohnston (talk) 20:20, 29 January 2020 (UTC)

Main page technical update proposed

Hello, a technical update for Main Page is being discussed at Talk:Main_Page#Main_Page_January_2020_technical_update, please join in that discussion if you are interested. Thank you, — xaosflux ^Talk 14:53, 29 January 2020 (UTC)

Group notices?

I want to create a page notice that appears every time you create a new WP:DRV. Each day gets a new page, something like Wikipedia:Deletion review/Log/2020 January 23. My first thought was to go to Wikipedia:Deletion review/Log, and edit the Group notice for that. But, when I click the Group notice link, I get to "Creating Template:Editnotices/Group/Wikipedia:Deletion review", not "Creating Template:Editnotices/Group/Wikipedia:Deletion review/Log". Is this intentional? If I manually edit the URL to include the trailing "/Log", will Bad Things happen? -- RoySmith (talk) 18:16, 29 January 2020 (UTC)

@RoySmith: This unfortunately won't work. For group notices, the editnotice loader only checks Template:Editnotices/Group/{{FULLROOTPAGENAME}} for a group notice, so a notice placed at "Template:Editnotices/Group/Wikipedia:Deletion review/Log" will not have any effect. ST47 (talk) 18:24, 29 January 2020 (UTC)

Hmmm, well, so not Bad Things, but certainly not Useful Things :-) I guess I need to fall back to my zeroth thought, which is that when the empty dailly pages are created by DRVClerk, it should also create a page notice for each one. I'll continue that at WT:DRV. -- RoySmith (talk) 18:32, 29 January 2020 (UTC)

@RoySmith and ST47: While that's true, you could put {{Editnotice subpages|Log|on base=no}} on Template:Editnotices/Group/Wikipedia:Deletion review, which will load Template:Editnotices/Group/Wikipedia:Deletion review/Log on subpages of Wikipedia:Deletion review/Log. Anomie⚔ 05:45, 30 January 2020 (UTC)

Global watchlist - Update 5

Updates associated with DannyS712's Global watchlist script:

Future development

• I have requested a grant to fund conversion of this script into an extension, as well as further development. Please see m:Grants:Project/Create a global watchlist extension.
• If anyone is interested in reviewing the code and making suggestions regarding coding style, techniques, or something else, please let me know. See phab:T234507 for more.

Recent additions

• I have added basic tests for the script, so bugs should be less likely to make their way to the deployed versions of the script (both the unstable development version, and the stable release version).
• If there is an error with the script, the user will be notified and and the console will include a stack trace of the issue.

Translations

• Many thanks to those that have contributed translations for the script's messages. Translation takes place at m:User:DannyS712/Global watchlist/Translate, and help is appreciated.
• Newly translated messages are added to the script when I notice them; if you have translated messages that aren't showing up, please let me know at m:User talk:DannyS712.

Next release

• Version 8.0 was just finalized for the development and stable branches of the script.

To subscribe or unsubscribe from future updates, see the distribution list.

Thanks, --DannyS712 (talk) 18:25, 29 January 2020 (UTC)

---

Global watchlist user script: About • Updates • Code

Deleting and reordering parameters using AWB

Is it possible to delete and reorder template parameters using AWB? I can't seem to find that option anywhere. If not, does anyone have any regexes for deleting the content of entire parameters within a template or for reordering existing ones? Thanks, – Srdjan m (talk) 19:47, 29 January 2020 (UTC)

Map not working properly

Can someone tell me why the map widget on Leigh Mall isn't working properly? It's showing an address in Columbus, Mississippi as being out in the ocean by Colombia. Ten Pound Hammer • ^{(What did I screw up now?)} 22:24, 29 January 2020 (UTC)

TenPoundHammer because 3 degrees is very close to the equator. I guess a digit got dropped. —TheDJ (talk • contribs) 22:38, 29 January 2020 (UTC)

Dark mode/skin

Is there an official dark mode or skin in Wikipedia?.--SharʿabSalam▼ (talk) 02:30, 30 January 2020 (UTC)

It's in development I think. But you can enable the script User:Volker E. (WMF)/dark-mode in the meantime. – Ammarpad (talk) 04:13, 30 January 2020 (UTC)

I have it but it's not working well. When I open a page in Wikipedia, it starts with no dark mode then after 2 seconds it changes to dark mode. That's more stressful for my eyes. I hope they develop the dark mode quickly. It sounds very easy to create a dark skin, I don't know why Wikipedia still has not developed a dark skin. It should be available for both readers and editors. People spend a lot of time reading in Wikipedia.--SharʿabSalam▼ (talk) 06:38, 30 January 2020 (UTC)

I found this. It's working, although the colours are not as good as User:Volker E. (WMF)/dark-mode but thats okay. Better than nothing.--SharʿabSalam▼ (talk) 06:51, 30 January 2020 (UTC)

There is the "Use a black background with green text" option (see gadgets tab of preferences). This might do.   Jts1882 | talk  12:05, 30 January 2020 (UTC)

Jts1882 thanks. This one looks good.--SharʿabSalam▼ (talk) 16:28, 30 January 2020 (UTC)

Help with taking an existing Barnstar and customizing it for my own current needs?

Hello, Never been here before, and I am not sure if the support people here would do that. Would you? Thanks, warshy ^(¥¥) 03:52, 30 January 2020 (UTC)

@Warshy: Wikipedia:Barnstars would be a good place to start, it also has a collection of lots of barnstars you may use. Wikipedia talk:Barnstars would be a good place to ask general barnstar questions if you don't have a specific technical question. — xaosflux ^Talk 14:20, 30 January 2020 (UTC)

@Xaosflux: Thank you very much. This should do it for me here for the time being. I'll take it up from there! Thanks, warshy ^(¥¥) 17:08, 30 January 2020 (UTC)

How to using unstripNowiki in subst: ?

Why {{unstripNoWiki}} notwork in {{subst:}}?

• See Special:Diff/938286178
• In lua console, I try to print the return value returned from mw.text.unstripNowiki, then I got a string like ?UNIQ...-nowiki-00000000-QINU?, so I think mw.text.unstripNowiki notwork in {{subst:}}.

BUT WHY? And How to fix it?--Yu-Fan 宇帆 (talk) 07:42, 30 January 2020 (UTC)

Tested it and it does seem to work, the substitution simply places the template parameter in the Unstrip module invocation, so it will look the same but it is actually displayed from the function invocation. --qedk (t 桜 c) 15:29, 30 January 2020 (UTC)

Discussion about a new selection method for featured articles

There is currently a discussion at Wikipedia talk:Today's featured article#the calais entry... um.... about whether future featured articles should be randomized on the Main Page which needs input by people who understand the technical implications of e.g using randomizer scripts on very widely read pages. Jo-Jo Eumerus (talk) 09:48, 30 January 2020 (UTC)

Creating a sanitized CSS page

I would like to know how I can generate a page with the content model sanitized CSS. Even if I cannot generate it, please specify a link about how it can be done. Adithyak1997 (talk) 12:26, 30 January 2020 (UTC)

@Adithyak1997: if you create a subpage of a Template: it will do that automatically. If you need one somewhere else (like a usersandbox) you can create a normal CSS page, then leave an edit request to have an Interface Admin adjust the content model for you. If you have a single page you want made, you can ping me and I'll probably make it for you as well. — xaosflux ^Talk 12:44, 30 January 2020 (UTC)

@Xaosflux: Any administrator can change the model (CSS/JS/JSON) but not in someone else's userspace/MW-space, I presume? --qedk (t 桜 c) 12:51, 30 January 2020 (UTC)

Right, it requires an interface administrator there as xaosflux said (at least for .js and .css pages). PrimeHunter (talk) 13:30, 30 January 2020 (UTC)

@QEDK: I'd have to check over all the use cases, but any admin should be able to change pages from wikitext to SCSS - however the page may fail to convert if it is not actually marked up in SCSS. — xaosflux ^Talk 14:17, 30 January 2020 (UTC)

Thank you all for your valuable replies. Adithyak1997 (talk) 15:30, 30 January 2020 (UTC)

Very erroneous diffs on category edits

When a category page is changed, the diff link given in Watchlist often uses the wrong page for comparison, and makes it look like the text of the category page has been completely replaced with the text of one of the member articles! Compare:

From watchlist: https://en.wikipedia.org/w/index.php?title=Category:Linguists_of_indigenous_languages_of_North_America&diff=938320566&oldid=836320439

From history: https://en.wikipedia.org/w/index.php?title=Category:Linguists_of_indigenous_languages_of_North_America&diff=938318938&oldid=836320439

Note the different "diff" values in the URLs. Is this a known bug? Is there a Phabricator ticket for it yet? —swpb^{T • go beyond • bad idea} 16:53, 30 January 2020 (UTC)

Maybe it depends of what kind of settings you have for your watchlist. Do you have "Expand watchlist to show all changes, not just the most recent" enabled on your preferences? Stryn (talk) 16:59, 30 January 2020 (UTC)

FYI: I can only reproduce this when both "Category changes" are shown and "Group results by page" is active, then the summary "9 changes" link is as described. It seems it groups all the category membership change entries together with the edit to the category page itself, and winds up diffing between the category page and one of the pages that resulted in a membership change. Anomie⚔ 17:13, 30 January 2020 (UTC)

Yeah, I think it only occurs with those settings. Still an error though, right? Even when grouping by page, I would expect to see one entry for the changes to the cat page itself, and one for the new members, e.g. "8 pages added to category". —swpb^{T • go beyond • bad idea} 17:46, 30 January 2020 (UTC)

I created a Phabricator ticket. —swpb^{T • go beyond • bad idea} 18:13, 30 January 2020 (UTC)

Yes it is still an error. Thanks for filing the task! Anomie⚔ 18:17, 30 January 2020 (UTC)

Interrupting parsing at beginning of parameter so wikimarkup at very start of its content is not misparsed

Template:Quote and some other block-level templates have an issue such that when a content parameter's value begins with wikimarkup, that markup is often not interpreted correctly. In an article, the fix is to do something like this, with <nowiki />:

{{quote|<nowiki />
'''Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua.''' Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
}}

To correctly produce:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

With this example, the output of the parameter – if you leave out <nowiki /> – will incorrectly appear as:

' Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

because the start of the parameter is mis-interpreted as a lone, plain-text ' followed by '' italics markup, then later a mis-matching ''' boldfacing start (not end).

This is a fairly serious issue, since we cannot depend on editors to know that they have to manually prefix <nowiki /> in the local template content. This problem affects things like italics and boldface, as well as parameter content beginning with a "*" or "#" list item. It is not repaired by soft-linewrap changes, like {{quote|'''Lorem ipsum dolor...'''}}; the <nowiki /> is needed regardless of horizontal versus vertical template usage. It also is not fixed by naming the parameter, e.g. with {{quote|1='''Lorem ipsum dolor...'''}} The problem does not affect display: inline elements only block ones (and probably inline-block ones).

Attempting to pre-seed the template with <nowiki /> at the beginning of the parameter output has no effect. Nor does wrapping that <nowiki /> in <includeonly>...</includeonly>. Attempting to break up the <nowiki />, e.g. with <includeonly><no</includeonly><includeonly>wiki /></includeonly> fails even more dismally, just passing the literal ASCII characters and causing the string "<nowiki />" to appear in the visible article text.

Has anyone figured out a way to stop this mis-parsing of the first character of the parameter output? I know this is an old issue, and I figure someone must have nailed it while I was off one one of my extended wikibreaks.  — SMcCandlish ☏ ¢ 😼  18:34, 30 January 2020 (UTC)

@SMcCandlish:: Testing {{quote}} with unnamed parameter:

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

and again with 1= parameter

Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

It seems to work fine for me. "Lorem ... aligua." is in bold, the rest is not. davidwr/(talk)/(contribs) 18:47, 30 January 2020 (UTC)

Hmm. Maybe it requires something in particular about the surrounding material to trigger? I had not seen the problem arise much lately, but ran across it again here: Mutant (Marvel Comics)#Omega-level mutants. If you change the block quotation there to remove the nowiki, the problem triggers (or at least it does for me in Chrome on macOS). I just tested it again and did get the problem (just tested with Preview; I didn't save the change into the live article).  — SMcCandlish ☏ ¢ 😼  19:09, 30 January 2020 (UTC)

This is because {{quote}} wraps |1= in {{Trim quotes}}, which trims matched pairs of leading and trailing single (') and double (") quotes and whitespace from a string, per that template's documentation. Stripping matching single quotes appears to be causing the problem. – Jonesey95 (talk) 19:26, 30 January 2020 (UTC)

Yup, that is it: {{quote|'''Omega Level Mutant:''' A mutant ... ''While Jean Grey... telepath.''}} renders as

Omega Level Mutant: A mutant ... While Jean Grey... telepath.

Adding <nowiki /> to the beginning or end of the first parameter will fix the problem and render it as

Omega Level Mutant: A mutant ... While Jean Grey... telepath.

davidwr/(talk)/(contribs) 19:40, 30 January 2020 (UTC)

Is this related to parser bug T18700? It either produces unwanted new lines or errors when newlines are unexpected. I've really no idea as its completely baffling, but it does require <nowiki /> fixes.   Jts1882 | talk  20:31, 30 January 2020 (UTC)

I have submitted a change for Template:Quote to add a new parameter, {{notrim=1}}, which will insert the <nowiki /> at the beginning of the quote automatically. It is awaiting review and approval by someone with template-editor user-rights. davidwr/(talk)/(contribs) 20:55, 30 January 2020 (UTC)