Wikipedia talk:Linter

Archives

Archive 1	Archive 2	Archive 3
Archive 4	Archive 5

This page has archives. Sections older than 60 days may be automatically archived by when more than 4 sections are present.

Bot running today (and probably tomorrow)

Qwerfjkl (bot) is running on Linter errors today, if you're wondering why the error count is dropping so fast. If you find straight text find-and-replace patterns that represent more than 100 errors across multiple pages, please add them to the bottom of the relevant table at Wikipedia:Linter/Signature submissions. Follow the existing formatting conventions, like this. I compile new patterns and submit them to the bot periodically.

Note that the bot is not currently able at this time to use regular expressions to find or replace text; such patterns are welcome, but someone else will need to work on them. – Jonesey95 (talk) 19:09, 19 January 2025 (UTC)[reply]

I think we should really clear the current entries from the page instead of finding new patterns as at some point it will become too large too be useful. Gonnym (talk) 10:59, 21 January 2025 (UTC)[reply]

Clearing these frequent errors is a great idea. Anyone is welcome to work on fixing any of the patterns that have been identified. I work on small batches that I find all the time, and sometimes I take on a larger batch. I usually leave pages with no errors except obsolete tags, so that existing bots have a better chance of finishing the work.

I disagree about adding new patterns. I collect them here for editors and bots to work on, and I feed non-regex patterns to the bot every month or two when there is a large enough collection to make a bot run worth the effort. The most recent bot run eliminated about 38 patterns from the page and took large chunks out of a few more. It fixed about 30,000 errors in less than 48 hours. Without collecting new patterns on the page, it will be much more difficult to feed the bot. – Jonesey95 (talk) 15:35, 21 January 2025 (UTC)[reply]

Completed entries are regularly being removed (Jonesey95 removed 30kb from the page size of eliminated patterns yesterday). I do understand you in the way of "the page is getting big", but in my way of thinking, I'd much rather the page be populated and Qwerfjkl have some choices in patterns to go after rather than sitting around waiting for us to find more patterns. I'm sure we'll reach a point later on where patterns won't be as prevalent and will need a little more hunting and the page will shrink in size again, but right now, big page equals big cleanup. Zinnober9 (talk) 15:40, 21 January 2025 (UTC)[reply]

Qwerfjkl does not pick patterns, that's what Jonesey95 does. Gonnym (talk) 19:01, 21 January 2025 (UTC)[reply]

For the past month or so, I moved from lint errors to Category:CS1 errors. I came back to lint errors and saw a big reduction, so, congratulations to all who have been working on them. To clarify this discussion, please confirm that what's happening here is, for linty markup patterns that occur on multiple pages, editors are asked to submit the linty markup and proposed workarounds on Wikipedia:Linter/Signature submissions, and then Jonesey95 or others will carefully verify the proposed fix is correct, and if so, run Qwerfjkl (bot) to fix the error. Is that right? —Anomalocaris (talk) 18:17, 21 February 2025 (UTC)[reply]

I wouldn't say that I'm the gatekeeper, but as far as I know, I'm the only person who has been feeding find/replace patterns to the bot. The rest of your summary looks correct. I would add: Any editors are welcome to work on batches of patterns, especially those using regular expressions, since there is not a currently active bot that processes custom regular-expression patterns. I sometimes grab a batch of 10 to 200 results, create a pattern in my AutoEd script, and process that list of pages. It's a nice way to reduce the overall error count by 100 to 1000 or more, and processing one page at a time means that I can pick off stray missing end tags or other Linter errors that don't fit a common pattern. – Jonesey95 (talk) 21:48, 21 February 2025 (UTC)[reply]

I'm happy to accept replacements from anyone. Ideally I would gather them myself, but I've been pretty busy this year with real life engagements, and I don't think that will change any time in the next few months. — Qwerfjkl talk 11:58, 22 February 2025 (UTC)[reply]

I love how the concern from some editors to create this omni-bot (that has yet to be created) to reduce edits on the same page, has resulted in many edits to the same page and a way less efficient process. Gonnym (talk) 13:30, 23 February 2025 (UTC)[reply]

Broken DISPLAYTITLE

With this edit, Linter broke the page's WP:DISPLAYTITLE. A <center> tag was replaced with a styled <div>, which is not allowed there. Paradoctor (talk) 12:10, 30 January 2025 (UTC)[reply]

Since that was my edit, sorry. Was not aware that div wasn't allowed in displaytitles.

It previewed fine (well, centered and usertalk + name overlapping as they had had it) and I thought it displayed as expected after, but I see it isn't displaying correctly in my version in the page history. That said, "span" is not centering it at all as was the user's intent, so that isn't the fix either since it's on the left side of the page. I looked at the possibility of swapping it to {{center}} with a test edit in my sandbox, but that also breaks/reports a broken WP:DISPLAYTITLE, and I don't see any centering options from the Template:DISPLAYTITLE, so I'm at a loss at the moment for a better solution. Zinnober9 (talk) 16:35, 30 January 2025 (UTC)[reply]

I played around with various things in my sandbox and was unable to find a replacement for <center>...</center>. I have posted a help request at mw:Help_talk:Lint_errors/obsolete-tag, but I do not expect help any time soon, based on that page's traffic. – Jonesey95 (talk) 17:17, 30 January 2025 (UTC)[reply]

The only wiki-side solution I see is to add #firstHeading { text-align:center } to the page's CSS, but Linter can't do that, so the user needs to do it.

I'm well aware that the <span> won't work. I used it only to preserve the intent while making the argument safe for consumption, as I didn't want to just remove the tag. Paradoctor (talk) 17:41, 30 January 2025 (UTC)[reply]

P.S.: Just realized that the #firstHeading style would apply to any and all pages, so no joy there either, unless one is good with that. Paradoctor (talk) 19:43, 30 January 2025 (UTC)[reply]

HTML5 misnesting all fixed (except for a couple of protected pages and error examples)

Whew! A few thousand pages of mostly one-by-one fixes later, Special:LintErrors/html5-misnesting is cleared out, except for a couple of protected pages and error examples. Great work, everyone! That's our last high-priority group (I don't count "Duplicate IDs" as high-priority). Just 142,620 misnested tags, thousands of which are bot-fixable, and we'll be left with just low-priority issues. – Jonesey95 (talk) 21:22, 18 February 2025 (UTC)[reply]

Nice, congrats us! There's now only one full protected HTML5 misnest, the rest being error examples. There's also are a few "delete table" issues that have popped up recently, but those won't likely last either. One is a testcase and the other six are currently stumping me.

Looking forward to the misnested errors dropping at a good rate next. Zinnober9 (talk) 03:23, 19 February 2025 (UTC)[reply]

Template:Asbox

Something on Template:Asbox (Template:Article stub box) is triggering 6k+ (and still growing) "misnested code tag" errors. I believe the error started Thursday or Friday, but not seeing any changes to the template in that timeframe or any recent edits using code tags. Anyone know? Zinnober9 (talk) 16:04, 2 March 2025 (UTC)[reply]

This problem could have been triggered by patch Thursday, Wikimedia's weekly sofware updates. —Bruce1ee ^talk 17:19, 2 March 2025 (UTC)[reply]

See this thread. I'm assuming a MediaWiki change caused this. I believe that the count will top out below 7,000 pages if my searches in that discussion were good ones. – Jonesey95 (talk) 17:56, 2 March 2025 (UTC)[reply]

Yup, that's it. Thank you. Was hoping it was a quick and simple error in a recent edit from the "offending" template instead of a quirky byproduct of a MediaWiki change, but it sounds like a bot can handle this issue in the coming days. Thank you both! Zinnober9 (talk) 18:56, 2 March 2025 (UTC)[reply]

sic stripper

So this was a weird one. Found a wiki italics surrounding a tq template containing a sic template. These combinations as pairs were fine, but when you have a perfect storm of all three together, then the italics makes the sic template strip the tq template. I found swapping to <i>...</i> cleared it. Is this a known issue and there's a Phab ticket on this? Or is there some extra parameter (say on sic) that I've overlooked? Zinnober9 (talk) 19:38, 6 March 2025 (UTC)[reply]

This is not a bug, it's just invalid syntax. The markup opened an italic tag, then opened a q tag, then closed the italic tag. That is misnesting. I usually fix cases like this by "unnesting" the italic markup, like this: You stated cambie un poco la historia porqur [sic] algunas something. – Jonesey95 (talk) 21:19, 6 March 2025 (UTC)[reply]

That had been my first thought, but then when I tested the original with an inactive sic, ''You stated {{tq|cambie un poco la historia porqur sic algunas something}}...'', it was clean, so lost confidence that was what was happening. Zinnober9 (talk) 02:18, 7 March 2025 (UTC)[reply]

Latent obsolete HTML in module namespace

There was obsolete HTML in List of mountains in the Canadian Rockies coming from Module:Mountains Prism, which had this markup:

return "<font color=red>" .. value .. "</font>"<code>

which I modified to

return "<span style=\"color:red\">" .. value .. "</span>"

There could be other modules that could output font, center, strike, or tt tags, and we don't know about them because they happen in error messages that aren't occurring. Someone who knows more about this than me could write a search for such markup. —Anomalocaris (talk) 07:00, 9 March 2025 (UTC)[reply]

Insource search results for the above: font, center, tt. Gonnym (talk) 10:43, 9 March 2025 (UTC)[reply]

I think that I have fixed all of the problem cases in those search results. – Jonesey95 (talk) 15:09, 9 March 2025 (UTC)[reply]

Hmm, I fixed only one of four latent font tags in Module:Mountains Prism and Jonesey95 fixed the other three, good work! Insource search results for strike: There were no results matching the query. —Anomalocaris (talk) 04:24, 10 March 2025 (UTC)[reply]

New bogus file options error

A new bogus file options error is being reported: {{!}} in file captions, for example in Pentagon Renovation Program. The caption contains a pipe, and {{!}} is used to prevent the pipe being interpreted as a file option separator. But this is no longer working, and only the portion of the caption after {{!}} is displaying.

Replacing {{!}} with | doesn't help. The only solution I've found is to replace {{!}} with <nowiki>|</nowiki>, for example here. Does anyone have a better solution. —Bruce1ee ^talk 08:35, 9 March 2025 (UTC)[reply]

In that specific example, what does the pipe add to the caption? Gonnym (talk) 10:53, 9 March 2025 (UTC)[reply]

I don't see the point of a pipe in that caption. Another example I don't see the point of is Soon and Baliunas controversy with this caption: "Center for Astrophysics | Harvard & Smithsonian". But clearly that is what the editors want, and strictly speaking, we shouldn't be changing how the page renders after our repairs. —Bruce1ee ^talk 11:17, 9 March 2025 (UTC)[reply]

Well, we aren't automatons either. If you see an error, don't hack a way to make that error work. A pipe isn't a substitute for any valid punctuation en.wiki uses. Not sure if this was really their intention when they added these new errors, but they do highlight actual errors that should be fixed. Gonnym (talk) 11:49, 9 March 2025 (UTC)[reply]

I think these pipes are what the editors intended. But I agree that pipes are not correct punctuation, and perhaps the solution is to replace them with something more appropriate, for example a comma. —Bruce1ee ^talk 12:38, 9 March 2025 (UTC)[reply]

New batch

We have a new batch of these: WP:ITSTHURSDAY. I have reported these as false positives, probably caused by a code change, at T389555. I recommend that we do not try to "fix" these pages until we get a response from the developers, since the pages were not reporting as "broken" yesterday. I don't see anything wrong with the syntax in these pages, and I think this is a bug. – Jonesey95 (talk) 21:36, 20 March 2025 (UTC)[reply]

I figured it was in a template that I hadn't found the culprit of yet or that something had borked, so good to know. Thanks. Zinnober9 (talk) 21:39, 20 March 2025 (UTC)[reply]

I did a quick scan through the list, and it looks like they are all(?) caused by table markup within the image caption. The tables render fine, and I'm guessing we have hundreds (thousands?) of pages that use such markup. I don't think they should be flagged. – Jonesey95 (talk) 22:01, 20 March 2025 (UTC)[reply]

Looks like the paragraph wraparound error on Antonio Juliano is related, or is related by ITSTHUSRDAY. No changes to that page/templates today (that I can find). Zinnober9 (talk) 23:22, 20 March 2025 (UTC)[reply]

This problem also appears to be generating stripped div tag errors on some pages that use map templates with legends, for example {{World geologic provinces}} in Igneous rock. —Bruce1ee ^talk 00:05, 21 March 2025 (UTC)[reply]

I agree that this looks like the same bug. I added some links to the bug report. – Jonesey95 (talk) 00:16, 21 March 2025 (UTC)[reply]

Wikimedia's new update today appears to have solved this issue. All those troublesome errors in Bogus image options should start to drop off once the pages are updated, or the page's server cache is cleared, or a null edit is performed. —Bruce1ee ^talk 11:10, 27 March 2025 (UTC)[reply]

Nice! All pages have now been purged. We've got three stragglers in article space that won't go away and not spotting the issues at this moment. I don't know what the heck is up with the user page Vrysxy/Jct/file, but it's switch/logic related. and the portals are the same old error of portal features images that will need hunting down. Zinnober9 (talk) 15:14, 27 March 2025 (UTC)[reply]

Days ago, I fixed the paragraph wraparound error in Antonio Juliano by removing a pipe, and if you revert, the error is still there. —Anomalocaris (talk) 07:52, 28 March 2025 (UTC)[reply]

From a fast look, doesn't seem like {{Medal}} is written correctly with how it handles |2=. Gonnym (talk) 08:23, 28 March 2025 (UTC)[reply]

I fixed {{Medal}} to allow line breaks in the parameters. I also fixed the portal gallery issue. – Jonesey95 (talk) 13:30, 28 March 2025 (UTC)[reply]

Film date template

{{film date}} is also acting broken with div errors. (see Draft:Katherine Adams). Zinnober9 (talk) 00:56, 21 March 2025 (UTC)[reply]

This is not related to the above. {{Film date}} is being misused here. See Template:Film date#Technical notes. – Jonesey95 (talk) 01:37, 21 March 2025 (UTC)[reply]

Timing was too similar, so since it said Error: Year value is required on Template:Film date, I assumed wrong. Thanks. This template can't be on a bulleted line it seems. Zinnober9 (talk) 02:25, 21 March 2025 (UTC)[reply]

Executing markup intended to be displayed

Two related issues here. First, Special:ExpandTemplates can reprocess display markup. Here are two sets of markup that display identically, but Expand templates messes one of them up:

Markup	Display	Expand templates
`<nowiki>{{Done}}</nowiki>`	{{Done}}	{{Done}}
`{{braces\|Done}}`	{{Done}}	Done

Second, it's not just Expand templates; {{Documentation}} also does this. {{Template:Testcases notice/sandbox}} was reporting missing end tag and stripped tag for <div>...</div> coming from the markup {{Documentation}}. I editing {{Template:Testcases notice/doc}}, changing {{braces|Documentation}} to <nowiki>{{Documentation}}</nowiki>, and that removed the two lint errors. I've fixed other similar errors in the past few days. —Anomalocaris (talk) 18:06, 7 April 2025 (UTC)[reply]

If the issue isn't found also with {{tlx|template|_show_result=y}}, then just replace {{braces}}. Gonnym (talk) 18:16, 7 April 2025 (UTC)[reply]

Interesting is {{ExpandTemplates |{{braces|Done}}|nowiki=no}} → {{Done}} vs {{Expand wikitext |{{braces|Done}}}} →

Done— Qwerfjkl talk 18:18, 7 April 2025 (UTC)[reply]

Usurped? More like berserked

Template:Usurped has gone berserk. Causing 46k+ stripped errors (in mainspace alone), 2 Tidy whitespace bugs, and who knows what else in the other namespaces. None of today's changes to the template would have caused this. Yesterday's edit might have, but the timing of taking a full day before appearing en mass seems doubtful. Zinnober9 (talk) 22:39, 7 April 2025 (UTC)[reply]

Disregard. Was today's {{!}} addition that normally behaves in situations (vertical bar) does not. Zinnober9 (talk) 00:22, 8 April 2025 (UTC)[reply]

Your fixed to the template was correct though. English words are always more correct. Gonnym (talk) 05:46, 8 April 2025 (UTC)[reply]

New lint category for empty headings

Soliciting feedback on a new lint category for empty headings, as suggested in T368722.

For example, ===  === will render as an empty <h3></h3> and place a blank entry in the TOC.

It would be considered low priority.

Thanks for you help. ABreault (WMF) (talk) 00:27, 10 April 2025 (UTC)[reply]

I'm seeing roughly 7,000 pages potentially affected. There are definitely false positives on this list. I'll put a note on a couple of pages to ask whether there are valid uses for this sort of markup. – Jonesey95 (talk) 00:50, 10 April 2025 (UTC)[reply]

I realize this would vary a bit based on the situation, but would the general idea on these be to either remove outright if no following content, or, if content follows (that doesn't already have a header), add a reasonable section title?

Hopefully most of those 7k pages are of massmailer content and can be botfix targets. Zinnober9 (talk) 04:01, 10 April 2025 (UTC)[reply]

Add a title. When a header is missing in AWB, the program adds Untitled. That should be what we add here also. Gonnym (talk) 08:12, 10 April 2025 (UTC)[reply]

After scrolling through most of the 7,000 pages in the search results above, I generally agree that "Untitled" should be added to nearly all of the empty section headers. If AWB does this semi-automatically, affected pages should not be a big deal to fix. Also: while scrolling, I noticed that maybe 1/5 to 1/3 of the search results were false positives of some kind, since my search was rudimentary. – Jonesey95 (talk) 12:43, 10 April 2025 (UTC)[reply]

@ABreault (WMF) this shouldn't be low priority as it has affects the page visually and functionally. At Talk:Judith Slaying Holofernes (Artemisia Gentileschi, Naples), the ToC entry for the second header (the one with the issue) is completely messed up it isn't clickable. This is the definition of a high priority error. Gonnym (talk) 08:09, 10 April 2025 (UTC)[reply]

The linter extension was introduced during the tidy migration with a goal of trying to minimize the damage of switching from Tidy to Remex, an HTML5 parser, which is why a lot of the high priority categories are about HTML4 vs HTML5 semantics.

I mention this because I don't have a good working definition of what should be considered high priority. Historically, it's been errors that are blocking work on the wikitext parsers.

If there's consensus that it should be high priority, let's do that. ABreault (WMF) (talk) 18:25, 10 April 2025 (UTC)[reply]

The way I see it high priority is if parsoid is not going to support said linter. Parsoid de-duplicating ids is one of the things that keeps it working. Having empty headings is probably unwanted. The priority should not be any higher than medium.

On the community front, if empty headings are going to be kept, they do need to be documented on english wikipedia, including that linking to them requires an #untitled_no link. Snævar (talk) 09:13, 11 April 2025 (UTC)[reply]

They are not going to be kept. Gonnym (talk) 09:51, 11 April 2025 (UTC)[reply]

Should pages like User:EranBot/Copyright/rc/57, where NOTOC is used, be flagged? The empty headers do not seem to cause any problems on such pages. There are no mysterious "edit" links and no blank TOC sections. – Jonesey95 (talk) 12:35, 10 April 2025 (UTC)[reply]

Yes. If I want to reference this bot's findings of a specific section, how can I link to it without real headers? Gonnym (talk) 13:06, 10 April 2025 (UTC)[reply]

It does not appear that section linking was intended there. The page is structured more like a table with rows than like a page with sections. What would you recommend as a fix for that sort of page, where there are multiple blank headers? Replacing all of the empty headers with "Untitled" won't help with linking, since all of the links will point to just one anchor. – Jonesey95 (talk) 13:11, 10 April 2025 (UTC)[reply]

Well in that specific page, I'd do what pages like Wikipedia:Contributor_copyright_investigations#Requests do and use the "thing" in question as the title. Here, it would be the article names (the value of |article=). Gonnym (talk) 13:56, 10 April 2025 (UTC)[reply]

Maybe replace it with a horizontal rule? ----

Not that, with mw:Parsoid, heading anchors are deduplicated, so they would end up as untitled, untitled_1, untitled_2, etc. ABreault (WMF) (talk) 18:13, 10 April 2025 (UTC)[reply]

A similar idea with this is cases where the header only contains markup and no displaying text. Case in point, <h1><center></center></h1> (Markup could be center, font, span, etc. Center was just the case I ran across). Would it even be possible to search for cases like this? Zinnober9 (talk) 17:48, 10 April 2025 (UTC)[reply]

Do you have a diff for that one? I can link to it from the phab ticket. – Jonesey95 (talk) 17:58, 10 April 2025 (UTC)[reply]

This exact case of h1 center is only on two pages as far as I can tell, I just was using this as an example for all possible cases of markup only statements within a header (h-style or = style). User talk:Mohd wara has it still, and I've addressed it on User:Mohd wara/Wara's Autograph Book (diff). Seeing that case after reading discussion here just got me thinking about this type of scenario since it wasn't explicitly stated above, and since we often find pointless empty markup in our other corrections that we (generally) remove when it serves no purpose and doesn't display. Zinnober9 (talk) 20:10, 10 April 2025 (UTC)[reply]

Mohd wara's talk page was full of errors, policy and accessibility. It is never surprising when it's all together. Also, h1 should never be used per the MoS. Gonnym (talk) 06:47, 11 April 2025 (UTC)[reply]

The linting code would detect this case. It will flag any instance where the heading content normalizes to the empty string "" as the anchor. ABreault (WMF) (talk) 18:08, 10 April 2025 (UTC)[reply]