Wikipedia talk:Linter

Signpost Fostered Content

If anyone is wondering, the sudden explosion of 22k fostered table errors is due to Template:S-s being nominated for deletion. In the nomination, there's talk of these being a fostered issue with the intended redirect (to Template:Signpost/item) so I'm wondering if either that template could adjusted to accommodate these cases, or if not, these pages could be addressed by a bot? @Jonesey95 @Qwerfjkl Do either of you know if this is botable if the template fix isn't feasible? And for a little humor, I'm feeling a bit like Bob Parr in the Incredibles interview after I cleared up the fostered issues earlier this year. :) Zinnober9 (talk) 22:36, 30 September 2024 (UTC)

That's a minor disaster. I have put the TFD notice in noinclude tags for now. Pinging HouseBlaster, who might be able to link to the discussion that motivated them to TFD this template. What is the plan or consensus for replacing it? Was this brought up at Template talk:S-s or Wikipedia talk:Wikipedia Signpost/Technical recently? I don't see anything. – Jonesey95 (talk) 23:22, 30 September 2024 (UTC)

There was no discussion beforehand; the TFD is the discussion. My idea is to gain consensus at the TFD to use a bot to put a pipe before the uses of the template (which eliminates the fostered content issue), before redirecting {{s-s}} to {{signpost/item}}. See example edit, which adds a pipe before the <!-- markup and thus is lint-free. We don't need two templates which do the same thing, so I nominated {{s-s}} for deletion.

I am cleaning up three-letter templates, most of which should be renamed per WP:TPN. However, I am also TFDing the obsolete/redundant/useless ones (such as {{s-s}}). Best, HouseBlaster (talk • he/they) 23:54, 30 September 2024 (UTC)

OK. Sorry for overstating the number of affected pages in my edit summary; it looks like about 2,800 is the right number, not 20,000 (that's the number of Linter errors caused by the TFD tag, since there are apparently an average of 9 transclusions per page, or something). – Jonesey95 (talk) 00:11, 1 October 2024 (UTC)

Eh, as long as it is fixed :) HouseBlaster (talk • he/they) 00:13, 1 October 2024 (UTC)

Future problems detected

I've had a few months off from linting fixes, but when I fixed a missing close italics tag on William Haygarth and clicked on "lintHint" I received a message saying "Future problems detected". I've not seen this before, is it new? What should I be looking to fix - I couldn't see any guidance. LicenceToCrenellate (talk) 17:23, 6 October 2024 (UTC)

It's likely "Duplicate IDs", a new linter category. LintHint normally reports them as "Duplicate IDs", but occasionally they show up as "Future problems detected". When I click lintHint on William Haygarth, it reports three "Duplicate IDs". —Bruce1ee^talk 23:24, 6 October 2024 (UTC)

Thanks, I'm now seeing the duplicate IDs message. LicenceToCrenellate (talk) 08:28, 7 October 2024 (UTC)

Wikipedia:Linter/reports/Protected pages by Lint Errors

Now that we have a bot running, I think temporarily removing the protection from the pages Wikipedia:Linter/reports/Protected pages by Lint Errors will enable the list of be dramatically reduced. Gonnym (talk) 14:44, 17 October 2024 (UTC)

Probably, but I could also see the bot being brought up to access their level as well. I know I've greatly dwindled that list manually with the help of Primefac, especially when I was eliminating the Tidy Fonts, but also in days since when I did some targeted request sets for dropping that list down to 21 or fewer. I hadn't found many protected pages in my more recent errortype eliminations, so hadn't felt the urge to target these pages since my previous set in July. I can hop back onto clearing those pages up. And I don't know about "temporarily removing protection", as temporarily lowering has been very effective and doesn't allow IP/low level vandals any access to these pages. Zinnober9 (talk) 17:46, 17 October 2024 (UTC)

Just 6 of the 54 pages with 21 errors have something other than obsolete tags, and Qwerfjkl (bot) is not fixing those errors without a different error type present at this point. Legobot might be able to fix a few of these pages, but IIRC, it limits its actions to pages on which it can fix every error, which may be unlikely for those pages. With such a low hit rate, I think it might make sense to focus energy elsewhere. That report contains 717 pages with 5,010 counted errors, and we still have over 3,000,000 counted errors left to fix. – Jonesey95 (talk) 18:08, 17 October 2024 (UTC)

We could wait, for example, until the bot operator returns to us with a list of pages that could not be edited by the bot because of protection, or we have fixed all of the unprotected pages with high-priority "HTML5-incompatible misnesting" errors, then request lower protection for that set of pages. – Jonesey95 (talk) 19:06, 17 October 2024 (UTC)

There were only I handful I saw from the logs, fewer than ten of 15-20 thousand. Qwerfjkltalk 20:21, 17 October 2024 (UTC)

Temporary Intentional Case of Bogus Images, leave be

Just a heads up that the four Bogus Image Option issues on User:Thryduulf/sandbox right now are intentional, and part of the discussion Wikipedia:Village pump (proposals)#Warn on inline image usage. Please ignore these four per discussion with user, and contribute to the Pump discussion if you have any input. Thanks. Zinnober9 (talk) 20:10, 27 October 2024 (UTC)

It's "very evil" day!

800+ pages are showing a bogus image options error that shows only on 31 October.

The fix is to change the middle "px" to "x". Let's go, team! – Jonesey95 (talk) 00:06, 31 October 2024 (UTC)

I was just coming to mention that this had just gone live and was also on the Wikipedia:Linter/Signature submissions page. While I had hoped they'd be nabbed by bot before today, they won't lasting too long. Zinnober9 (talk) 00:29, 31 October 2024 (UTC)

104 remain, all one per page. I'm tapping out for the evening, will hit any that remain (if any) when I'm free again later tonight. Great work everyone!! Zinnober9 (talk) 22:11, 31 October 2024 (UTC)

All done, with 25 minutes before Halloween is over! Nice work, everyone. – Jonesey95 (talk) 23:35, 31 October 2024 (UTC)

Nearly there (3 million)!

Depending on the rate of edits for Qwerfjkl(bot) Task 31 all our delinting efforts, we'll be under 3 million Lint errors in the next day or few. 3,008,823 errors from previous Firefly update. Let's go! Zinnober9 (talk) 05:27, 3 November 2024 (UTC)

The bot hasn't been editing for a couple of weeks, probably because I haven't provided another batch of find-and-replace strings for its operator. Instead of doing that useful task, I've been plugging away at easy edits on AFD pages, which are each transcluded at least once, which means that every batch of 100 edits with five or so fixes in each edit has netted at least 1,000 fewer Linter errors on the Firefly page. We are getting close to a nice milestone. I've also been slowly working on the high-priority misnesting errors, which are one-by-one edits that are typically not in any sort of pattern. – Jonesey95 (talk) 05:31, 3 November 2024 (UTC)

Ah, I hadn't looked at the bot's recent contributions, and had just been seeing that the total had been steadily dropping by a decent rate daily and had incorrectly assumed. Nonetheless, still very impressive and exciting. I've been hitting some of the misnested ones too, but since they widely vary in execution, it's been harder to settle into nice edit session focused on those. Zinnober9 (talk) 06:19, 3 November 2024 (UTC)

Sorry about that, I'm a bit too busy to do much right now. I'll try to get another batch running sometime soon. — Qwerfjkltalk 11:15, 3 November 2024 (UTC)

We made it under 3 million. Whew! I need a break. – Jonesey95 (talk) 00:49, 5 November 2024 (UTC)

Good job! Gonnym (talk) 08:31, 5 November 2024 (UTC)

We are (in the past hour) holding steady at/just under 50k articles (each with a single error, and ignoring any 2+ popups) remaining in mainspace! Woohoo team!! Zinnober9 (talk) 01:59, 13 November 2024 (UTC)

Unclosed templates

I wish broken templates would be tracked as lints. The edit previous to my fix here made the whole editing window colored with syntax highlighting. Gonnym (talk) 07:48, 8 November 2024 (UTC)

It looks like that is Error 43 at Wikipedia:WikiProject Check Wikipedia/List of errors, although the list that shows when I click through shows only articles (1,700 of them!). I don't think that Linter was designed to catch every type of error; the Check Wikipedia project has existed for a long time. We need a much larger army of gnomes just to keep up with CW errors in article space, let alone in the 90% of pages that are outside of article space. – Jonesey95 (talk) 14:03, 8 November 2024 (UTC)

Hopefully not related to this, can you see any text when trying to edit 15min? I get a blanked uneditable window. Gonnym (talk) 14:07, 8 November 2024 (UTC)

Managed to edit the page with a section edit and after fixing the page loads. So seems some of these are pretty serious errors. Gonnym (talk) 14:30, 8 November 2024 (UTC)

Yes, error 43 is listed as "High" priority (the highest priority on that page) with the symptom of "Display problem". So many gnomes are needed (or edit checks when saving, or something else). – Jonesey95 (talk) 15:54, 8 November 2024 (UTC)

That would be nice for sure, or at the very least they could do extension tags in addition to HTML. Gamapamani (talk) 04:34, 10 November 2024 (UTC)

Edit checks when saving & openly displayed Linter error banners

Since @Jonesey95 mentioned edit checks when saving, I was wondering what the rationale might be for not doing them, at least for Linter errors. I'm guessing it has something to do with linting every preview being too expensive; and then, even though the page gets linted upon saving anyway, it would feel weird to users to suddenly get a linter error notification if they didn't get it for preview.

It would definitely be helpful to have this, especially since the section editor mode gives people the misleading appearance that everything is fine with their edit even when they have an unclosed table or {{div col}}, which then messes up the stuff following the faulty section. I used to think the people making these errors very incredibly sloppy, but now I think in a great many cases they simply get misled by the section editor where everything looks OK, and aren't aware they should also double-check the full page after saving. Most people would likely be interested in fixing an issue they've introduced if they got notified about it, it's not like they want to mess things up and leave it to the gnomes to clean up. Gamapamani (talk) 05:34, 10 November 2024 (UTC)

Also along these lines: is there a reason why a "This page has Linter errors. You can help by fixing them." message with a Special:LintErrors titlesearch link can't be placed on relevant pages the same way all kinds of other notification banners are? I'm sure the presence of a linter error can be stored/cached with the rest of the page metadata so an extra DB lookup wouldn't be needed. I mean, sure, what would we do with our lives if this were fully crowdsourced instead of hiding it in Page information and Special pages and having a dedicated gnome force for it, but seriously, what would be the downside of this? Gamapamani (talk) 06:22, 10 November 2024 (UTC)

I think that we need to get the lint errors down to zero before we can ask for this feature. It would be very annoying to get this message when the lint error was already on the page and added by someone else. I've edited some old template documentation pages that used TemplateData and had a bad JSON syntax which was apparently saved before saving bad JSON was disallowed and when I tried saving changes I had to fix someone else's errors. That isn't fun. But when it does reach zero, I'm all in favor of such a feature. Gonnym (talk) 11:27, 10 November 2024 (UTC)

@Gonnym Just to be clear, I'm not suggesting blocking the save on this, just letting people know that the problem is there instead of hiding it under the rug (maybe even in view mode as well, not just when editing). I mean there are already all kinds of this-or-that-needs-fixing-on-this-page messages all over, adding the lint error information into the mix as well wouldn't be a big deal, I think. Gamapamani (talk) 11:58, 10 November 2024 (UTC)

It's still might be a message that was meant for someone else's errors, not the user saving the edit, which I find in bad taste. If someone wants to gnome, that's fine, but we shouldn't force it upon them. We should however force it upon the user creating the errors. Gonnym (talk) 12:03, 10 November 2024 (UTC)

I'm not sure it should be forced on anyone, as that could end up with less experienced users abandoning otherwise good edits. As for being in bad taste, well, I sort of get you, but would it be more in bad taste than the red cite errors, etc.? Maintenance templates are usually about someone else's problems, it would be a similar suggestion to help out if you can and feel like it. And the wording could be different for pre-existing errors and those introduced in the current edit. Gamapamani (talk) 12:24, 10 November 2024 (UTC)

Yes it would be worse than red cite errors. Gonnym (talk) 12:42, 10 November 2024 (UTC)

Perhaps we could have warnings in preview only, similar to what a lot of templates do using Module:Check for unknown parameters. You don't see anything when reading, but you do see a warning when you preview the page. Those warnings are also "someone else's error" (usually a parameter that was removed from a template at some point), and you're free to ignore them, but at least they're more visible to regular editors. --rchard2scout (talk) 12:38, 11 November 2024 (UTC)

@rchard2scout For my purposes, something like this when previewing, something like an editnotice when editing, or something like a maintenance template when reading are all valid possibilities, as long as the errors (their presence, not necessarily the details) are shown somewhere without having to take additional action to see them. Prefs could have an option to disable this display if it's an annoyance. Gamapamani (talk) 13:10, 11 November 2024 (UTC)

I think most of the performance issues will go away once we have Parsoid read views. It would probably be doable to trigger only when new lint errors are detected, whatever the action ends up being. I agree that the risk is showing errors to users who don't understand what they did wrong.

But I'll posit a different way of solving your problem: we should get rid of templates like div col; editors shouldn't need to manually balance templates together and they don't work with the visual editor, etc. Legoktm (talk) 18:52, 11 November 2024 (UTC)

@Legoktm From what I've seen, it actually happens a lot more with tables, and you probably aren't going to get rid of those. :) It's quite easy to miss the deletion/replacement of |} because it's so short and only has a single character difference from other table syntax.

As for eliminating {{div col}}, I have nothing against the idea, but since it's basically just a <div> + attributes, how are you going to eliminate the need to close HTML tags? A plain </div> can get lost just as easily. I don't think you'll be able to get everyone to go VE-only (and AFAIK it still doesn't support multi-column lists – could be wrong since I don't use it much). Or are you talking about mass-converting to {{columns-list}} or always using |content=? This sort of thing would indeed make it obvious for the editor when the template hasn't been closed, but my understanding is that it can't be used with table code, and most begin/end pair templates seem to be table-based. (I'm obviously not as experieced with all this as you and the regulars here, so please do let me know if I'm mistaken in my reasoning.) Gamapamani (talk) 01:42, 12 November 2024 (UTC)

Index namespace lint question

I've run into an oddity over on Wikisource that has puzzled me, and asking here since you all are rather knowledgeable about a lot of things and have dabbled elsewhere and seen some things. ShakespeareFan00 and I have cleared all Obsolete tags from the Index namespace, but for some reason, the 76 pages that were affected are all still listed on their Special:Lint report. LintHint's clean after the edits, and I've tried purging, hard purging, and null editing, but they remain listed. Wondered if I was overlooking something, or if it was just a wait it out situation. Do any of you happen to know? Thanks, Zinnober9 (talk) 16:01, 17 November 2024 (UTC)

@Zinnober9 I made some test edits to one of those index pages (removed the entire TOC the error had been in, introduced a different error) and they had no effect on its lint error status. It seems unlikely to be a wait it out situation, since it's been more than a month since the original fixing edit there. Introducing an error to an index that previously had none didn't register either. A wild goose chase of purging not just the Index but also the corresponding File and the template (and its module) that indexes go through also failed to trigger the Linter.

So, maybe the Index namespace there just isn't being linted at this time for whatever reason? Gamapamani (talk) 21:30, 18 November 2024 (UTC)

Possible MediaWiki parsing change surfacing new Linter errors

Tracked in Phabricator
Task T380638

I'm seeing a few new pages in our Linter error lists today, including Template:Arbitration case implementation notes (fostered content), Template:List of oxidation states of the elements/sandbox (fostered content), and Template:Tick (bogus image option).

I do not see any recent changes to these pages or to pages that they transclude. This usually means either that a stale page with an error has been null-edited by the job queue and finally brought to the surface (highly unlikely, given how long these pages have been error-free and how recently they have been edited), or something has changed in the MediaWiki code. I'm suspecting the latter. I know for certain that Template:Tick had no Linter errors, because I fixed a bogus image error there on 26 June 2023.

To my eye, these all appear to be false positives, but I could be wrong. When I expand them at Special:ExpandTemplates, they appear to be fine. Does anyone have any insight on these new errors? If we can't figure it out, I'll file a bug and ask the developers to investigate. – Jonesey95 (talk) 16:55, 22 November 2024 (UTC)

I was seeing similar (stripped tr/td with {{bar percent}} for "[year] New South Wales state election" articles). I have no insight, and none (page/template) were edited recently. Zinnober9 (talk) 17:34, 22 November 2024 (UTC)

Thanks for that additional data point. I have reported T380638. – Jonesey95 (talk) 19:00, 22 November 2024 (UTC)

This situation has been acknowledged as a bug and has a fix on the way (maybe next Thursday). No action is needed on these pages until then. – Jonesey95 (talk) 21:35, 22 November 2024 (UTC)

Nice. Thanks! Zinnober9 (talk) 04:09, 23 November 2024 (UTC)

Looks like the fix has gone through. Noted pages (and a few others I spotted after we talked) are all clear. Happy Thanksgiving. Zinnober9 (talk) 15:02, 28 November 2024 (UTC)