Wikipedia talk:Linter

Night mode: New lint rule
The Wikimedia Foundation Web team is currently working on a dark theme for Wikimedia projects and soon Wikimedia skins will support two color schemes.

This has implications on user-generated content which in the past has made understandable assumptions about how the content will be displayed. For example in the past, if text was given a yellow background the assumption was made that the text color would be black. In dark mode where the text will now be white, this creates accessibility issues.

While the Web team is aiming to minimize the work required by editors in the short term, this work has flagged a long-term need for lints to help editors locate pages with accessibility issues. Next week, we will add a new linting rule to flag pages which we have identified as problematic. To minimize disruption this will be initially hidden as we iron out any problems. The Web team has provided a set of recommendations to support this work.

In addition to this and to reduce the burden new lint rules can cause to the community workflow, we are working with the Content Transform team on T334527  so that community adoption/acceptance of lint rules in future can be done separately from the creation of them. We are documenting this on mediawiki.org.

Please let us know about any questions or concerns you have by replying here. You can also raise bugs by creating a ticket in https://phabricator.wikimedia.org/project/view/6717/.

Thank you! Jdlrobson (talk) 17:07, 14 March 2024 (UTC)


 * I'm wondering how signatures with colors will work with the dark theme and if they will be flagged by the linter. Gonnym (talk) 17:29, 14 March 2024 (UTC)
 * , thanks for the note, the links, and the process improvements. Are there instructions anywhere explaining how to turn on this new night mode so that we can see if the lint-flagged condition really causes a problem? That might help us determine if the lint condition is flagging any false positives. I also have a question similar to Gonnym's: many signatures use code like  or   to color text, with no specified background color. Will those signatures be flagged by the new linting rule? If so, I foresee a LOT of errors. – Jonesey95 (talk) 18:00, 14 March 2024 (UTC)
 * If they are flagged, how will they interact with the new rule that doesn't allow lint errors in signatures? Gonnym (talk) 18:32, 14 March 2024 (UTC)
 * Those will not be flagged for now. Right now we are only flagging the case where background is defined without a color.
 * Those will be an issue with the night mode feature however.
 * You can test night mode (for time being only working on mobile) by appending ?minervanightmode=1 or ?vectornightmode=1 on any URL. Jdlrobson (talk) 19:54, 14 March 2024 (UTC)
 * , it appears that signatures are indeed being flagged by this new Linter rule. Is this intentional? See this VPT post. – Jonesey95 (talk) 16:41, 22 March 2024 (UTC)
 * Also, the Linter rule appears to have errors detecting nested span tags. See and mw:Talk:Reading/Web/Accessibility_for_reading, two related cases. – Jonesey95 (talk) 16:56, 22 March 2024 (UTC)
 * Was wondering that too. I will say though that I regularly use a dark mode browser addon (Dark Reader), and any black text is displayed as white, so curious if that will be a similar thing with this Wikipedia setting, or if black = black in all cases. The addon I use does make some color combos that look fine in light mode turn hellish in dark though; cyan backgrounds almost always are hell with this as it leaves the cyan background alone, but turns the darker text shades to a lighter (inverse?) color and the combo becomes unreadable. In those cases I've had to turn it off to preview those pages I'm fixing. Zinnober9 (talk) 23:10, 14 March 2024 (UTC)
 * Related discussion at Template talk:Episode list (also by Jdlrobson).
 * Some TV related templates that use colors that should be tested they aren't producing lint errors:
 * Template:Episode table
 * Template:Episode list
 * Template:Infobox television season
 * Template:Series overview
 * Gonnym (talk) 06:45, 15 March 2024 (UTC)
 * Probably most sports navboxes which already violate color will also appear on this list. Gonnym (talk) 17:34, 17 March 2024 (UTC)
 * @Jdlrobson, see mw:Talk:Reading/Web/Accessibility_for_reading.  Sdkb  talk 16:16, 22 March 2024 (UTC)

How much attention should be paid to this new tag?
I am finding it challenging to determine how much attention to pay to this new tag. When I am logged out, the code to force vector night mode results in a bunch of black-on-black and blue-on-black text for me (example: John Dalton), except, ironically, in elements like navboxes and message boxes, many of which trigger this new Linter rule. Those items show in "regular" mode, with white backgrounds, not anything like "night" at all.

I posted a note to Template talk:Navbox with some thoughts about that template's triggering of this new rule. It is unclear to me whether something actually needs to be fixed, because when I force night mode, everything on the page looks terrible except for the element that is supposedly out of conformance. Because of my inability to make night mode function reasonably, I have no way to test whether adding an explicit color declaration does anything useful. I feel like I'm missing something. – Jonesey95 (talk) 05:23, 23 March 2024 (UTC)


 * The night mode for Vector 2022 hasn't been built yet. It will be built over next 4 weeks in an identical fashion to Minerva. We are releasing the lint error so editors get a head start on fixes. ?vectornightmode=1 is therefore not the query string to use. You need to use Minerva for now e.g. https://en.wikipedia.org/wiki/John%20Dalton?minervanightmode=1&useskin=minerva.
 * You can also add the following to Special:MyPage/minerva.js to force night mode on for all pages (e.g. template namespace)

(function {   const c = document.documentElement.classList;   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {     c.remove( 'skin-night-mode-page-disabled' );     c.add( 'skin-theme-clientpref-night' );   } });
 * 🐸 Jdlrobson (talk) 06:00, 23 March 2024 (UTC)
 * Also here's an example of a fix: https://en.m.wikipedia.org/w/index.php?title=Grand_Slam_(TV_series)&diff=1215109361&oldid=1203322851&title=Grand_Slam_%28TV_series%29&diffonly=1
 * From what I can see the lint rule is working as expected. 🐸 Jdlrobson (talk) 06:01, 23 March 2024 (UTC)
 * Thanks for the Minerva tip; I was just applying the instructions you gave above and was confused. That Minerva string works on the John Dalton page, but when I go to https://en.wikipedia.org/wiki/Template:Bolvadin_District?minervanightmode=1&useskin=minerva or https://en.wikipedia.org/wiki/User:Jonesey95?minervanightmode=1&useskin=minerva I see a regular look. What am I missing now? – Jonesey95 (talk) 13:23, 23 March 2024 (UTC)
 * There is rule in Minerva to mitigate breakage: [style*="background"] elements get set to a black color with !important. The hope is to eventually remove this when the lints are fixed. You can disable this rule in developer tools if that is helpful. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)
 * Also see my script above to force it on for other namespaces. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)

bgcolor
Using bgcolor in a table doesn't trigger the lint rule. It's only seems to be triggered by background in the style attribute. -- WOSlinker (talk) 13:01, 1 April 2024 (UTC)
 * good point. I thought bgcolor was already covered by Special:LintErrors/obsolete-tag but I guess that only applies to HTML4 tags not attributes? 🐸 Jdlrobson (talk) 00:46, 2 April 2024 (UTC)
 * If these attributes are also obsolete they should probably be tracked by the lint. Gonnym (talk) 12:47, 8 April 2024 (UTC)
 * Does anyone know of a BOT that will fix the bgcolor=f2f2f2 into style="background:#f2f2f2;" ? Maybe it's too complex a problem for a bot? Fyunck(click) (talk) 18:50, 30 May 2024 (UTC)
 * I see only seven instances, so a bot is probably not needed. – Jonesey95 (talk) 21:30, 30 May 2024 (UTC)

Milestone!!
As of 2024-05-05 20:16:47, NO error type per namespace exceeds 1 million. "Missing end tags" in "User Talkspace" just fell below 1 million. Still have a ways to go before we can say No error type exceeds 1 million total, but certainly getting there!

And for a second (smaller) milestone that is soon approaching, "Table tag to be deleted" will be pretty much gone from all of Wikipedia in the next few days. 137 at the moment with their days numbered. Zinnober9 (talk) 20:32, 5 May 2024 (UTC)
 * These two milestones show the power of bots (see Bots/Requests for approval/Qwerfjkl (bot) 29, a task that eliminated about 60,000 Linter errors in a couple of days) and the power of diligent, plodding human editors (the "Table tag" error was at 5,479 four months ago, and every edit required a manual fix). Keep it up, team! – Jonesey95 (talk) 03:00, 6 May 2024 (UTC)
 * Do you already have a next target in mind for the bots? Gonnym (talk) 07:27, 6 May 2024 (UTC)
 * There are a significant number of bot-fixable patterns that appear on hundreds or thousands of pages, listed at User:MalnadachBot/Signature submissions. I think going after some of those, especially the higher priority problems, would make sense. It would be helpful if the bot did not have to return to a page multiple times, since that is something people complained about with the previous most-active bot. – Jonesey95 (talk) 13:03, 6 May 2024 (UTC)
 * Yeah, I'm already way past the ignore stage for hearing those cries. No one has shown that they can code a bot to fix errors on a page in one go, so there is really no need to take that unachievable goal into consideration. Gonnym (talk) 16:29, 6 May 2024 (UTC)
 * I'm pretty sure that 's lint-fixing bot had a method of checking to ensure that it was fixing all of the errors that it showed up to fix, FWIW. I don't know how that was done in the code. Unfortunately, that bot, which is still needed, is no longer active. – Jonesey95 (talk) 16:41, 6 May 2024 (UTC)
 * I don't think that bot was active that much to begin with, based on the lint decrease at the time. Gonnym (talk) 16:48, 6 May 2024 (UTC)
 * Legobot fixed a few hundred thousand Linter errors, as far as I know; here are nearly 5,000 edits performing Lint fixes. I think the operator kept a tally somewhere. I know that I was grateful for its work. – Jonesey95 (talk) 17:30, 6 May 2024 (UTC)
 * Jonesey95, I was looking at this earlier, it seems it can be done with Parsoid; see mw:Parsoid/API. I've got it working with some python code. — Qwerfjkl  talk  17:17, 6 May 2024 (UTC)
 * Nice. If you can figure it out, that would be great. I have come across plenty of user signatures that comprise the only Linter error on a given User talk page. This signature, for example, is often the only error on a page; I have fixed a few hundred of them, but it is tedious. – Jonesey95 (talk) 17:30, 6 May 2024 (UTC)
 * Jonesey95, from the first page from that search query, User talk:Jim1138, I get: As far as I can tell dsr[0] and dsr[1] are the start and end indexes, which gives: (There are also around 10 other lint errors on the page that it also returns.) —  Qwerfjkl  talk  17:45, 6 May 2024 (UTC)
 * It's close but not the whole error.
 * The signature is:
 * the fix is several closing span tags there:
 * Gonnym (talk) 18:28, 6 May 2024 (UTC)
 * I have a regex for it in User:Jonesey95/AutoEd/doi.js. – Jonesey95 (talk) 19:15, 6 May 2024 (UTC)
 * More interesting: I think that the above misidentification should be filed as a bug if it has not been already. I thought that this was a problem with LintHint, but if it an API problem, maybe it can be fixed. The problem was reported to the LintHint maintainer about six months ago, and appears to have something to do with non-ASCII characters causing offsets to be wrong. – Jonesey95 (talk) 19:18, 6 May 2024 (UTC)
 * I filed a bug at . – Jonesey95 (talk) 18:24, 17 May 2024 (UTC)
 * Thanks for flagging the regression. The issue should be resolved now. ABreault (WMF) (talk) 23:52, 13 June 2024 (UTC)
 * , thanks for fixing it and coming here to tell us! I love it when bug reports can be addressed quickly. – Jonesey95 (talk) 00:19, 14 June 2024 (UTC)
 * Thank you. It appears to be working correctly again. —Bruce1eetalk 00:49, 14 June 2024 (UTC)
 * ┌──────────────────────────────┘ Jonesey95, from what I can tell it's the byte offsets. When I account for that properly I get  — Qwerfjkl  talk  17:00, 7 May 2024 (UTC)
 * @Jonesey95 A good number of those 5479 Table tags were also triggering a Fostered content error within the same issue, so early on I'd compiled a list of pages containing both errors and hit those pages first to get through more errors quicker. Was exciting how quickly both dropped. Congrats and thanks to @Gonnym for the last Table tag fix, and thanks to Primefac for assisting. Zero remain, leaving "HTML5-incompatible misnesting" as the sole surviving High Priority error type with 9,625 remaining. Zinnober9 (talk) 14:06, 7 May 2024 (UTC)
 * And now (2024-05-27 11:14:47) no page has more than 49 countable errors... Top 1000 pages are 49-36. Zinnober9 (talk) 11:19, 27 May 2024 (UTC)
 * And now (2024-05-27 11:14:47) no page has more than 49 countable errors... Top 1000 pages are 49-36. Zinnober9 (talk) 11:19, 27 May 2024 (UTC)

Tech News: Headings will be wrapped in div tags
Excerpted from section "Tech News: 2024-21" at User talk:Jonesey95, 20 May 2024 The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that. End of excerpt
 * I won't be surprised if this causes a few new kinds of Linter errors to appear, since there will be a whole bunch of div tags added to rendered pages. But maybe not, because they are applied at the skin level. If a new batch of errors appears in one or more of the categories, this may be something to remember. – Jonesey95 (talk) 23:56, 20 May 2024 (UTC)

Linter reports not updating and count issue
There's an issue with the Linter reports today (the Lint counters through a page's Page Info are all fine, and Firefly is all fine, it's just these three reports that are miscounting). I noticed that they were counting high yesterday, and today they timeout (600 sec) when manually updated. I had checked a few of the top pages and compared the counts to their page information lint counts, and they varied wildly, typically 21 or so higher than the actual. I know for a fact that we have the article space errors down to 2 errors max per article (barring any daily flareup), and all 1000 articles displaying in the report were all claiming 21+, which is thankfully not true.

While I see that there's now a lag on server 1, there wasn't any lag this morning when I found the update timeout issue when I clicked "manually update" and "broke" the Article and All reports, and doesn't obviously account for the miscounting.

I've contacted SD0001 whose bot runs the requests, and Galobtter, who set up the report pages, but they don't know. I'm not aware of a new error type, but realize that is a possible answer. Thanks, Zinnober9 (talk) 21:50, 14 June 2024 (UTC)
 * Does anyone know why the reports are timing out when told to update?
 * Does anyone know why they are counting high?
 * See Village_pump_(technical). It looks like toolforge is running very slowly. – Jonesey95 (talk) 17:35, 15 June 2024 (UTC)
 * Thanks. I updated the Pages by Lint Errors list and it spun and spun for a few minutes, but completed. Seems "mostly" back to working order again. Glad. Zinnober9 (talk) 22:54, 15 June 2024 (UTC)
 * Counts are back to normal now, thanks to WOSlinker's adjustment. Thank you. Zinnober9 (talk) 17:15, 16 June 2024 (UTC)

Moving "Night-mode-unaware-background-color" out of tracking into high
Dark mode is highly likely to be released on web within the next month and has been on the official apps for some time. I think the tracking category is working exactly as it should be, and should be moved from tracking to high (or at least medium) priority.

In many articles, text will become unreadable in dark mode (or is already unreadable in apps), and we should be considering this a high priority to fix.

What is the process to changing priority here...? 🐸 Jdlrobson (talk) 18:03, 15 June 2024 (UTC)
 * If the population of the list of Template-space pages affected by this Linter tracking is an indication that there are display problems with those pages, I would be reluctant about going live with dark mode. If that long list is mostly showing false positives, then the Linter tracking needs to be adjusted before it will be useful.


 * To give a concrete example, this Template page is not "unreadable in dark mode", AFAICT, so why is it being flagged? As I said above, I don't think the rule should be promoted until the template space is largely free of tracked pages and pages affected by transcluded templates have been null-edited to remove them from the lists. Good progress has been made on that list, but having affected templates cause Linter error counts to balloon in pages that transclude them will not help anyone.


 * In any event, I think the first step is to "unhide" this Linter condition, set it to Low or some sort of Tracking-only priority, and list it on the Special:LintErrors page so that tools like LintHint and the links from Page Information can point editors to the specific locations in the page where code needs to be adjusted. We should also get it onto Firefly's tracking table. Simultaneously, and I can't stress this enough, ensure that WMF developer resources are available to troubleshoot false positives and other problems with the Linter detection and with the dark mode itself. If you really want to release dark mode in the next month, a significant amount of programming resources will be needed to ensure that volunteers have adequate tools to clear Template space of dark mode problems. – Jonesey95 (talk) 18:57, 15 June 2024 (UTC)
 * The recently added Missing end tag in heading lint error needs adding to Firefly as well. -- WOSlinker (talk) 19:14, 15 June 2024 (UTC)
 * Yeah, I'd like to see Missing end tag in heading errors added to Firefly too. That said, I was thinking about going after these heading errors (1545 errors on 1027 pages) after I finish off the Fostered content errors next week (well all that I can, I'm skipping some fostered pages right now for various reasons (A-J at the moment)). Zinnober9 (talk) 22:51, 15 June 2024 (UTC)
 * All Missing end tag in heading errors now corrected. Still would like this type to appear in Firefly's report so that we can more quickly see when they popup again, but it's now at "prune back" levels. Zinnober9 (talk) 15:22, 3 July 2024 (UTC)
 * > To give a concrete example, this Template page is not "unreadable in dark mode", AFAICT, so why is it being flagged?
 * I've said this a few times now, but I'm not sure it has registered. Vector 2022 is applying a rule html.skin-theme-clientpref-night .mw-parser-output [style*='background'] {color: #202122;} . This rule is temporary while we roll out dark mode and addresses about 80% of the issues in that lint, but importantly it is temporary. This is what the linter is detecting and why it is important it gets fixed.
 * If you disable that rule, you will see that the template becomes unreadable in dark mode.
 * > In any event, I think the first step is to "unhide" this Linter condition, set it to Low or some sort of Tracking-only priority, and list it on the Special:LintErrors page so that tools like LintHint and the links from Page Information can point editors to the specific locations in the page where code needs to be adjusted. We should also get it onto Firefly's tracking table.
 * Great. What is the process for this?
 * > Simultaneously, and I can't stress this enough, ensure that WMF developer resources are available to troubleshoot false positives and other problems with the Linter detection and with the dark mode itself. If you really want to release dark mode in the next month, a significant amount of programming resources will be needed to ensure that volunteers have adequate tools to clear Template space of dark mode problems
 * Yes. Dark mode is going to be released in July as an opt-in feature. Developer resources are available. and I assure you these lints are accurate. If tools or documentation are needed - just ask and we'll prioritize getting you those. 🐸 Jdlrobson (talk) 21:54, 25 June 2024 (UTC)
 * Thanks. 1. What CSS should I add to my vector-2022.css to disable the rule that hides dark mode problems? 2. A Phabricator ticket will probably be needed to unhide the rule and move it to a tracking or low-priority list and onto the Special:LintErrors page. 3. I have asked Firefly to modify their report to add the "missing end tag in heading" and "background color night mode" tracking. – Jonesey95 (talk) 22:40, 25 June 2024 (UTC)
 * 1. You can add the following to your user CSS:
 * 2. Thanks! Does there need to be any on wiki consensus? Or will that happen later? I can't seem to find any process for changing priorities of lints on mw:Help:Extension:Linter and there probably should be!
 * 3. Thanks! 🐸 Jdlrobson (talk) 05:00, 26 June 2024 (UTC)
 * Re on-wiki consensus, the changes are to the MediaWiki code, so they affect all Wikipedias. Every change I have seen has been made in Phabricator. – Jonesey95 (talk) 15:22, 26 June 2024 (UTC)
 * I turned off the temporary workaround and this Template page was indeed unreadable in dark mode, with white text on a white background. I believe that I have fixed the underlying template, as it looks visually OK to me now, but without an indication on the Page information page, or a link within LintHint, it is tricky to know if the problem is fixed. I see that there are some JavaScript instructions on one of the help pages, but that stuff won't fly with regular folks like me who want to help fix problems. Some developer resources to help us gnomes with the above would be helpful this week before dark mode is rolled out next week (according to the VPT note just posted). – Jonesey95 (talk) 16:00, 26 June 2024 (UTC)
 * @Jdlrobson so I've set my preference to use Dark mode in the beta options. I'm looking at Template:Martial arts medalists for Iran which has completely unreadable text in the group sections. Does the new lint catch pages like this? If it doesn't, is there a way it can? Gonnym (talk) 11:07, 4 July 2024 (UTC)
 * Nope the lint is checking for the opposite - background without a color.
 * We would need to create a new lint for this, but the solution is more complex and there are more likely to be false positives so it would need more thought.
 * For this particular issue, you can fix it with the following change:
 * Jon (WMF) (talk) 18:53, 5 July 2024 (UTC)
 * Jon (WMF) (talk) 18:53, 5 July 2024 (UTC)

Explanation of how dark mode is supposed to work?
This is a bit off-topic, but is there an explanation of the design ideas behind the dark mode? I was looking at this template page and trying to determine how to fix the current Linter errors, and I noticed that top and bottom bars above and below the navbox title were being displayed in gray instead of the intended red and blue. Also, the explicitly applied white background color was being forced to show as black, and in every navbox, there are awkward alternating gray and white thin borders on the rows. At that point, I stopped troubleshooting, because that seems broken to me, and even if I try to apply a fix, I don't know how to know if that change will result in the "right" outcome. – Jonesey95 (talk) 16:51, 26 June 2024 (UTC)


 * I really believe that instead of all these fixes per template that will take forever and might only look "ok", that the dark mode skin should at least at the start disable all colors and use whatever default passes AAA requirements (or at least AA). There is no way that the color contrast will pass AA requirements. Gonnym (talk) 17:49, 26 June 2024 (UTC)
 * I find myself in a situation that feels familiar. The WMF decides to roll out some big new change or new feature, and I try to help them with it. The documentation about the change is minimal, the set of test cases that the developers are working with is minimal, and it seems like the whole thing is going to blow up because it is not thought through very well. The catch for me is that sometimes the change works just fine, and sometimes it blows up, and my predictions in advance about which way it will go do not correlate well with the actual outcome. I just don't know. This one feels like it is not ready, but maybe nobody will depend on it or the people who use it will have a high tolerance for things not working right, so it won't matter. I don't know. I've tried to help, but ironically, it all feels like trying to make visual art in a room with no lights or windows. I think at this point I'm just going to wait until next week to see if anyone caress. – Jonesey95 (talk) 18:36, 26 June 2024 (UTC)
 * I say let it break, maybe that way stuff actually gets fixed correctly. All those colorful navboxes that aren't accessible in lightmode view will be horrible for everyone in darkmode. That might lead to an actual change. Gonnym (talk) 20:40, 26 June 2024 (UTC)
 * And maybe they'd support our delinting efforts more? *Hopeful joy* Zinnober9 (talk) 21:22, 26 June 2024 (UTC)
 * Are you aware of Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis ? 🐸 Jdlrobson (talk) 15:20, 27 June 2024 (UTC)
 * Yes, I've read through that a couple of times. I was unable to find an explanation of why the red and blue borders in the ice hockey navbox are turned to gray or why navbox rows have alternating white and gray borders. – Jonesey95 (talk) 17:06, 27 June 2024 (UTC)
 * Does this update help answer that question? https://www.mediawiki.org/wiki/Recommendations_for_night_mode_compatibility_on_Wikimedia_wikis#The_page_looks_fine_to_me,_despite_not_following_these_rules,_why? Jon (WMF) (talk) 20:34, 27 June 2024 (UTC)
 * Ah, disabling/updating backgrounds and borders in elements with the class .navbox ... tells me that I am probably seeing something deliberate. As has been true ever since we were asked to help, it is not clear whether any of my troubleshooting is working. I am fine to wait for the deployment to see if this blows up or is no big deal. There is plenty of other stuff to work on. – Jonesey95 (talk) 22:30, 27 June 2024 (UTC)

Special:LintErrors
Background color inline style rule exists without a corresponding text color is now showing up as a low priority item at Special:LintErrors. Only 46,386,919 errors to look at. -- WOSlinker (talk) 14:23, 4 July 2024 (UTC)

Puzzling use of
From time to time I come across a puzzling use of, for example:   here, which of course generates a lint error. I don't understand what the purpose of this is. It breaks the bolding markup and messes up the rendered page. —Bruce1eetalk 07:51, 19 June 2024 (UTC)
 * Sometimes people are trying to put an italicized word or phrase in single quotation marks, and this is the way they try to do it. See  in that article, which currently results in Naya Basat due to some quirk of how the rendering engine works. I suppose it is possible that some previous version of the MediaWiki software rendered all of this mismatched/misnested syntax as the editors intended but that subsequent development has changed the rendering so that only some of it displays as intended. – Jonesey95 (talk) 16:26, 19 June 2024 (UTC)
 * Thanks, I see what they were probably trying to do. —Bruce1eetalk 18:00, 19 June 2024 (UTC)
 * It also sometimes happens that later somewhere else in the text, some bolding or italics is added, which now causes the  to be matched up differently by the parser. I prefer using ' (or ` or sometimes 's) instead of nowiki. --rchard2scout (talk) 00:15, 20 June 2024 (UTC)
 * Yes, I've also seen that happen, and I also prefer using the templates to put a space between markup and apostrophes. —Bruce1eetalk 00:43, 20 June 2024 (UTC)

Possible bot task?
Just posing a question here at this point to gauge its possibility. I've been seeing a repeating circumstance that probably be defined by an existing bot and run to reduce a sizable number of lint errors in a one time purge. The main issue I'm pausing at is the possible social aspect.

Could it be socially possible to have one time task where one of the bots go through the remaining linty Userspace pages, and replace any sandbox* denoted pages' content with Userpage blanked IF and only IF the user's last edit on any page was some reasonably long time ago (let's say 4+ years)?

The "IF user's last edit 4+ years" clause is important in this idea, as while Userpage blanked (via WP:stale), states that any page that hasn't been edited in twelve months or more could be blanked, I think we'd be in hell if we started blanking all forgotten pages of any user, active or not.

* I say "sandbox" to mean any page that isn't a page of the barnstar/userbox/template/stat... or any "profile adjacent" page... those should remain intact and delinted normally. As I'm not sure how intelligent a bot could be determining what a page is, or if it could determine between a profile adjacent page and a draft (eg Username/barnstars vs Username/draft title), I'm currently framing this idea for just pages with sandbox in the title (eg User/sandbox or User/sandbox/draftname) for all the linty sandbox tests and sandbox drafts. If the bot can determine a page is "User/draftname" and not "User/profileAdjacent" then great.

Currently though, I've been manually blanking and adding the Userpage blanked template to users' draft/test pages that I've found that are completely abandoned, using the typical judgement of "Blank the linty sandbox/draft page if and when the user hasn't edited anything in 4+ years." and then delinting as normal any forgotten pages of any editor with a recent (0-4yo) edit anywhere, or delinting as normal if the page is "profile adjacent".

Is this a bot logically possible task that could be run? Is this a socially possible task to run without any major backlash? Is any bot operator interested in this idea, assuming the social aspect is addressable and permissible? Zinnober9 (talk) 16:23, 3 July 2024 (UTC)
 * Zinnober9, the technical aspect of this is pretty easy (assuming there's some programmatic way to detect draft/sandbox/test pages). Finding consensus will probably be much harder - in general the community doesn't like editing users' pages without their permission. — Qwerfjkl  talk  19:20, 3 July 2024 (UTC)
 * That's mainly why I am suggesting limiting the scope to draft/test pages of accounts that are long inactive and presumed gone, and suggesting an inactivity requirement far greater, and far more restrictive than that of the requirements of Userpage blanked so that we are a bit conservative and don't ruffle many feathers. If 4 years is too recent for the community, no objections to increasing it. 4 years is just the determining rule of thumb I've been using when I come across these specific pages. Hell, limiting it to a user's inactivity of 10+ years would still give a coverage range of 2001-2013, and would likely still clear plenty of errors on pages that are very unlikely to ever be looked at or returned to again by that user, or any other user.
 * The main thing that I think would be in our (delinters') favor is it would be a one and done task where no page would need to be revisited by this task, or by anyone else, bot or human. And if the user of the page did return, the template would clearly indicate that the action may be easily reversed by them without issue. I know people aren't too crazy about big tasks or repeating tasks, or edits on pages heavily watched pages, so that's why I thought it was possible that this might satisfy people for a nonrepeat task on forgotten/unwatched pages.
 * The only way I could see the task being rerun would be if we were permitted a 10+ years ago range to start with, and then later on being permitted to cover a newer like 4+ years ago (in which it would only run for the pages 4-10 years ago, no page revisits).
 * I think that WP:Lint gives a reliably long precedence for allowing specific edits on other's user pages, and that the Userpage blanked template, gives clear precedence for allowing the blanking of abandoned User's sandbox/draft pages. Combining these two rules and limiting this task to only the abandoned sandboxes/test pages that no one's looked at in years and almost certainly won't be returning to shouldn't cause any watchlist bombs, or cause any grief that doesn't already exist with Delinting. I do realize there will probably be some hesitation from the community suggesting another task or a new approach for some Lint clearing by this method. Zinnober9 (talk) 16:14, 4 July 2024 (UTC)

A minor milestone
I don't know if per tag statistics are shown anywhere, so in case they aren't: as of 13:47 (UTC) today, there were no more listed missing end tag errors for &lt;table&gt; or &lt;div&gt; left in article space (a couple have appeared since). There were ~4000 left about a month ago and I've been focusing on these, ~100 per day. I know missing end tags are supposed to be "low priority", but these two tags have plenty of potential for layout disruption when unclosed, so since i had some extra time...

I emphasized "listed" because of course more of these could easily be hidden behind italics/bold errors, just like plenty of &lt;table&gt; errors that weren't in the report were readily shown on the pages with &lt;div&gt; errors (I mean even before fixing the latter). Gamapamani (talk) 14:31, 4 July 2024 (UTC)


 * That's great. Here's some stats on other missing tags on article pages. -- WOSlinker (talk) 15:28, 4 July 2024 (UTC)
 * {| class="wikitable"

!Tag!!LintCount!!PageCount
 * b||8820||8603
 * big||2||2
 * blockquote||15||14
 * caption||3||3
 * dl||5||5
 * i||60525||58411
 * p||561||546
 * s||1||1
 * small||31||31
 * span||111||108
 * sub||1||1
 * sup||5||4
 * u||1||1
 * ul||41||41
 * }
 * Nice! I knew I'd seen a little rash of those when I looked at the breakdown of the remaining errors in mainspace the other week and had been surprised they weren't triggering the "Table tag to be deleted" error.
 * Was also pleasantly surprised, (but it seems a majority of this was you efforts!) we got rid of 6000 missing end tags in Main this month, double the typical monthly rate of ~3000. I was just about to add a breakdown table of the current remaining errors in main, but I see WOSlinker just added that... lol. Nice. The one remaining detail that I'll add to that is that we have 65176 Articles with a single error, and 2476 Articles with two errors, so won't be too long before this report starts showing ones, or is all ones. Thank you (and everyone else!) for your great delinting efforts. Zinnober9 (talk) 15:59, 4 July 2024 (UTC)
 * That's awesome! Congratulations everyone for your work here! 🐸 Jdlrobson (talk) 01:19, 5 July 2024 (UTC)
 * surprised they weren't triggering the "Table tag to be deleted" error
 * Depends on the context, most deletable tag errors I've seen have semantically been missing end tag errors. The last table on a page would never get a deletable tag error when unclosed, but it can still mess with layout by subsuming the content after it (case 3). Which is why IMHO it might even make sense to lift missing end tags for tables to medium priority. And maybe divs too, since stuff like unwanted columnization of following content with unclosed div col) and scrolling with unclosed style="overflow: auto;" is pretty frequent.
 * {| class="wikitable"
 * sub||1||1
 * sup||5||4
 * u||1||1
 * ul||41||41
 * }
 * Nice! I knew I'd seen a little rash of those when I looked at the breakdown of the remaining errors in mainspace the other week and had been surprised they weren't triggering the "Table tag to be deleted" error.
 * Was also pleasantly surprised, (but it seems a majority of this was you efforts!) we got rid of 6000 missing end tags in Main this month, double the typical monthly rate of ~3000. I was just about to add a breakdown table of the current remaining errors in main, but I see WOSlinker just added that... lol. Nice. The one remaining detail that I'll add to that is that we have 65176 Articles with a single error, and 2476 Articles with two errors, so won't be too long before this report starts showing ones, or is all ones. Thank you (and everyone else!) for your great delinting efforts. Zinnober9 (talk) 15:59, 4 July 2024 (UTC)
 * That's awesome! Congratulations everyone for your work here! 🐸 Jdlrobson (talk) 01:19, 5 July 2024 (UTC)
 * surprised they weren't triggering the "Table tag to be deleted" error
 * Depends on the context, most deletable tag errors I've seen have semantically been missing end tag errors. The last table on a page would never get a deletable tag error when unclosed, but it can still mess with layout by subsuming the content after it (case 3). Which is why IMHO it might even make sense to lift missing end tags for tables to medium priority. And maybe divs too, since stuff like unwanted columnization of following content with unclosed div col) and scrolling with unclosed style="overflow: auto;" is pretty frequent.
 * {| class="wikitable"
 * surprised they weren't triggering the "Table tag to be deleted" error
 * Depends on the context, most deletable tag errors I've seen have semantically been missing end tag errors. The last table on a page would never get a deletable tag error when unclosed, but it can still mess with layout by subsuming the content after it (case 3). Which is why IMHO it might even make sense to lift missing end tags for tables to medium priority. And maybe divs too, since stuff like unwanted columnization of following content with unclosed div col) and scrolling with unclosed style="overflow: auto;" is pretty frequent.
 * {| class="wikitable"

! 1 !! 2 !! 3 !! 4 !! 5
 * - style="text-align: center;"
 * - style="text-align: center; background-color: #ffe4ff;"
 * Missing end tag
 * Missing end tag
 * Fostered content
 * Missing end tag
 * (Following content subsumed; the more cols Table 2 has, the "better" the result)
 * Fostered content
 * Table tag that should be deleted (bogus)
 * Missing end tag
 * (Following content subsumed, incl. Table 2)
 * - style="vertical-align: top;"
 * Table tag that should be deleted (bogus)
 * Missing end tag
 * (Following content subsumed, incl. Table 2)
 * - style="vertical-align: top;"
 * - style="vertical-align: top;"
 * }
 * Gamapamani (talk) 05:29, 5 July 2024 (UTC)

Dark mode tracking thread
I propose to use this thread to track individual questions about, and problems with, the new dark mode Linter tracking. Please report questions, problems, false positives, false negatives, and other issues here.

Possible false negatives in Template:Infobox royalty
I'm seeing what looks like a false negative in infobox royalty. In this version of the sandbox, we have this formatting for succession:. I see a background-color defined without a corresponding color, which I think should cause a Linter error when the infobox is rendered. In this forced dark mode view of the testcases page, the value of succession, "Queen consort of England", shows as black text on a black background, which is an error. The testcases page reports no Linter errors.

I'm also getting a report that "from desktop, the above (name) text in black however, in mobile app it is white and does not match with the background color." On the mobile view, I'm seeing the "above" text (e.g. "King Ahab") as black text on a sort of purple background. On the dark mode mobile view of the testcases page, I'm seeing the "above" text (e.g. "King Ahab") in white on black. What could be causing the person reporting this problem to see something different? – Jonesey95 (talk) 18:00, 4 July 2024 (UTC)


 * Hmm odd 🤔. I am seeing this in Special:LintErrors here: https://phabricator.wikimedia.org/F56229922 so am not sure why the testcases page is not reporting an issue? Maybe worth a bug?
 * https://en.wikipedia.org/wiki/Special:LintErrors/night-mode-unaware-background-color?wpNamespaceRestrictions=0&titlecategorysearch=Alexander+the+Great&exactmatch=1&tag=all&template=all
 * The headerstyle needs to be updated to have "color:inherit;" to fix this issue.
 * Regarding apps, I chatted with a developer about that yesterday and it seems apps are doing a few things that need adjusting now web has dark mode. I wouldn't worry about that for now - but do feel free to get a bug on Phabricator tagged with #dark-mode and someone in apps can look into it. 🐸 Jdlrobson (talk) 02:34, 5 July 2024 (UTC)
 * Alexander the Great turned out to be an unlucky example. It transcluded about ten templates that all needed to be updated. The article itself, and Infobox royalty, did not need to be changed to remove the dark mode tracking lint from Alexander.
 * Re the header style above needing to be updated, that is the bug I am reporting. It needs to be updated, it results in invalid dark mode output, but it is not throwing a Linter error. It should. – Jonesey95 (talk) 04:37, 5 July 2024 (UTC)
 * DId you report this on Phabricator already? It looks like an issue with mediawiki-extensions-Linter. Jon (WMF) (talk) 18:54, 5 July 2024 (UTC)
 * I was being lazy or hoping someone would explain why I was wrong. . – Jonesey95 (talk) 21:06, 5 July 2024 (UTC)
 * I was being lazy or hoping someone would explain why I was wrong. . – Jonesey95 (talk) 21:06, 5 July 2024 (UTC)

includeonly / noinclude Fostered Content
Unsure if related or not, but the timing is peculiar. Today has brought on a new batch of 300some pages (most transcluded) claiming fostered content errors, due to the inclusion of includeonly and noinclude tags around startings and closings of tables. This behavior is typically not a lint error and is commonly used in the cases of transclusions. Why they are claiming errors I do not know. Anyone know what occurred? This isn't the only time I've seen this issue popup for select pages, but it's always cleared up before I get bothered enough to ask about it. Many of the pages are linked to the noinclude of the Ranks and Insignia of Non NATO Air Forces/OR/Blank template's opening bracket/parameters, and that page (really most of these pages) haven't been edited in awhile, and were not problematic when the fostered content errors were finished off to a remaining 10 or so pages two weeks ago. Zinnober9 (talk) 19:22, 4 July 2024 (UTC)
 * I think there was a bug report in Phabricator for this, but I am unable to find it via a Phab search. Pages like Line 4 (Shanghai Metro) appear to be affected; I remember that page and its siblings being affected by a similar problem a while ago. Since I could not find a bug, I filed a new one. . – Jonesey95 (talk) 20:08, 4 July 2024 (UTC)

Possible false negative in Template:DYK tools when used on a DYK page with light green background
Please see Template:Did you know nominations/St. Anne's Church, Moxi, which was showing a dark mode error. The page has a div tag that assigns a light green background. I tried added "color:inherit", but that turned the text white or light gray in dark mode. I changed that to "color:black", which displays the page properly in dark mode. The problem is that in both light and dark mode, the DYK tools box header shows black text; in the dark mode, that black text is on a black background. The page shows no Linter errors, but there is a display error. The DYK tools box header was also showing black-on-black in dark mode before I fixed the surrounding div tag. When I put DYK tools by itself in my sandbox, it shows the box header in white text on a black background. – Jonesey95 (talk) 20:32, 4 July 2024 (UTC)
 * I think this edit has fixed that. -- WOSlinker (talk) 21:33, 4 July 2024 (UTC)
 * Could really do with a full list of all those css variables and what the color values they are for both dark and light modes. Anyone know where these are? -- WOSlinker (talk) 21:35, 4 July 2024 (UTC)
 * What the heck is ? I don't see that anywhere on the Help page for this tracking category., do you know anyone who could improve the help page to add this useful tidbit and explain when to use it? So far, I'm limited to trial and error with color:inherit and color:black, which is not very sophisticated. – Jonesey95 (talk) 04:40, 5 July 2024 (UTC)
 * I've found a few of those CSS variables and have listed them at User:WOSlinker/CSSvars. -- WOSlinker (talk) 07:32, 5 July 2024 (UTC)
 * I updated https://www.mediawiki.org/wiki/Help:Lint_errors/night-mode-unaware-background-color#Quick_start. Hopefully that's the improvement you needed? Jon (WMF) (talk) 19:49, 5 July 2024 (UTC)

How to bypass a false result
There is a false result, which. The limited access symbol needs to go next to the URL link that has limited access, in this case the link to the Internet Archive item within the Internet Archive template. This is the case with cite web when the  parameter is used. However, by "fixing the lint error", the limited access template is instead placed outside to the right of the Internet Archive template, which results in the symbol being place next to the Internet Archive wikilink.

This is clearly fixing a problem that does not exist. How can we bypass this? Peaceray (talk) 23:35, 6 July 2024 (UTC)


 * Placing Limited access in the name parameter in Internet Archive appends File:Lock-gray-alt-2.svg to the name, which generates an internal link inside an external link lint error:
 * History of Ancient Egypt [[File:Lock-gray-alt-2.svg] ] at the Internet Archive
 * The problem is that Internet Archive does not have a  parameter, and because moving Limited access outside Internet Archive is not producing the desired result, the only solution I can see is to use cite book instead. —Bruce1eetalk 00:33, 7 July 2024 (UTC)
 * Seconding cite book. Lint issues aside, it looks cleaner and doesn't have the rather clumsy arrow+indicator combo obscuring the indicator:
 * EDIT: The original comparison containing a lint error can be seen. Gamapamani (talk) 04:14, 7 July 2024 (UTC)
 * I used cite book; sorry if I included too many details and I also omitted Internet Archive, feel free to fix. —Anomalocaris (talk) 04:58, 7 July 2024 (UTC)
 * Update: a  parameter has been added to Internet Archive. ( FYI). —Bruce1eetalk 07:02, 15 July 2024 (UTC)
 * Thanks! Peaceray (talk) 15:07, 15 July 2024 (UTC)

Template Action lint
Really wish that "template is up for Merge/delete/some action requiring discussion" messages didn't trigger Lint when displaying along each use of the template. The sudden, large increase in some sections and namespaces tonight are due to this and almost certainly won't need individual addressing. At least they only last a week (or until discussion closed). Zinnober9 (talk) 02:57, 7 July 2024 (UTC)


 * I seem to recall that this can be fixed by moving the merge/delete tag in the template, but I don't remember what it was. Pinging Jonesey95. —Bruce1eetalk 08:27, 7 July 2024 (UTC)
 * I've done this edit which I think has fixed it. -- WOSlinker (talk) 10:40, 7 July 2024 (UTC)
 * Thanks, that should help. —Bruce1eetalk 11:23, 7 July 2024 (UTC)

User home pages
Hi, my user page was recently edited for Lint errors. I was fine with the edit, but on reading the editor's talk page I found many complaints from other editors about unwarranted interference with their user pages, both home and talk pages. I started wondering whether user pages were somehow special or sacrosanct, and started a thread at WP:HD. Looking more closely at the main page in the 'How you can help' section, there is guidance about editing User Talk pages, but there is nothing on User Pages (home pages) at all. Should this be remedied?

WP:TALK states that "It is not necessary to bring talk pages to publishing standards, so there is no need to copy edit others' posts. Doing so can be irritating. The basic rule, with exceptions outlined below, is to not edit or delete others' posts without their permission." Furthermore, WP:UOWN states that "Bots and other users may edit pages in your user space or leave messages for you, though by convention others will not usually edit your user page itself, other than (rarely) to address significant concerns or place project-related tags."

I was wondering how the above statements sit with the general advice to Linter-Gnomes on user pages? Should they perhaps be discouraged from making edits on such pages, especially unannounced and unexplained? Cheers, >MinorProphet (talk) 11:19, 17 July 2024 (UTC)


 * No one owns any page on Wikipedia, not even your own user page. This isn't your web page, "home page", or social network page. Errors, however small and insignificant it might, can and should be fixed. Ideally, you should be fixing them, but as history shows, most of the users who introduce errors, don't care to fix them. Zinnober9 was correct in both fixing your errors, how they've fixed them, and even left a good edit comment describing the issue. If after all this you still have an issue, then that's one problem we can't fix. Gonnym (talk) 11:29, 17 July 2024 (UTC)


 * Thanks for your helpful and incisive comments, with which I tend to agree - you press 'Publish' at your peril. I am not taking sides, or complaining at all about anyone or anything. As I said I was fine with the edit, for which I thanked the editor. But others are not so happy, as you can see by the editor's talk page. I'm merely hoping to find out exactly where any consensus ("by convention") has been reached about user pages, about which many people feel quite strongly proprietorial. Maybe they shouldn't. Other guidelines about User and Talk pages include: WP:USERTALKSTOP says: ""In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask."" WP:AVOIDABUSE says "Editing another editor's signed talk page comments is generally frowned upon, even if the edit merely corrects spelling or grammar." WP:OWN#User pages states: "Usually others will not edit your primary user page, other than to address significant concerns (rarely); or to do routine housekeeping, such as handling project-related tags, disambiguating links to pages that have been moved, removing the page from categories meant for articles, replacing non-free content by linking to it, or removing obvious vandalism or BLP violations."" These latter seem very trivial tasks: but is everything else on user pages, e.g. in the Linter 'High Priority' list, deemed a "substantial edit"? I'm not criticizing, merely curious. Cheers, >MinorProphet (talk) 13:26, 17 July 2024 (UTC)
 * Fixing Linter errors fits in with "routine housekeeping". All pages are fair game for fixing errors, replacing deleted templates, adjusting wikitext to conform to MediaWiki code changes, and other maintenance that keeps Wikipedia pages rendering correctly. – Jonesey95 (talk) 13:37, 17 July 2024 (UTC)
 * Many thanks for a clear and concise answer which also clearly states Linter's admirable purpose. I haven't come across anything as clear is this. Does this statement (or similar) appear anywhere else, e.g. WP:Linter WP:User pages, WP:Etiquette, and the others I quoted? I think it could be more widely understood that the way a user page renders is important, and that all articles and pages on WP fall under that remit of "routine housekeeping": and that includes "your" user page, however proprietorial you may feel about it. Thanks again,  >MinorProphet (talk) 16:08, 17 July 2024 (UTC)
 * Great discussion. You are correct that not everyone likes or is thrilled when their userspace is edited, and since I've been targeting some LINT error types that weren't as numerous and had the chance at being completely eliminated, that's meant editing mostly in userspaces to eliminate them since 72% of the remaining errors are in userspace/user talkspace. Getting some grumpy feedback just comes with this territory. Most of the time though, I've get no feedback/response at all, or I get the occasional positive thank you notification. People tend to comment more when bothered, so that's what mostly ends up on my talk page. I'm sorry if my talk page came across as a red flag due to this. I do hope you saw, however, that I responded to each and every grumpy comment about my delinting, and attempted to find neutral ground for a solution that made both parties happy.
 * As to discouraged from making edits on such pages, especially unannounced and unexplained, I've found it's easier to ask for forgiveness afterwards from a few people then to ask and explain the edits prior to making them for every user needing pages fixed, and I'm less likely to have my edits rejected after the fact than upfront. Also in my way of thinking, it bothers people less to go ahead and do it, take care of all known syntax errors in one edit, and be done with it all with no need for subsequent delinting or bother, than it is to ask and explain and then do the corrections, but there is no perfect way and each method has some advantages and disadvantages. One and done tends to mean fewer but bigger edits, where Errortype focused edits means smaller, clearer edits, but more subsequent edits/notifications for the remaining errortypes.
 * You are also correct that these issues we are fixing seem more minor, but we've also cleared up most of the more major and problematic errors in the last few years, and the remaining 3.19 million errors are mostly Misnested, Missing, Stripped, or Obsolete tags of lower, but still important, priorities. I'm still seeing pages where someone's signature is missing a closing tag and the color, font style, and/or size "leaks" onto everything that follows after it, creating some crazy and unreadable messes. I've also seen cases where people had issues with their table structuring and it mixed with other code/tables to form a distorted layout messes when read.
 * I do need to make clear that there is a clear and distinct line between fixing syntax errors, and correcting someone's grammar.
 * Fixing grammar is rarely needed, not permitted by lint or other policies, and ticks people off with no real net gain.
 * Correcting various syntax errors on the other hand, clears up any issues the page has of displaying content as intended and helps prevent any current issues from becoming major issues as HTML and various code improves or is updated. It also reduces the likelihood of people seeing and copying another's HTML error(s), since most people's code knowledge is "I saw this, it looked cool, so I copied it for my own use", which has caused a fair amount of replicated errors. Zinnober9 (talk) 17:04, 17 July 2024 (UTC)
 * @ Gonnym "most of the users who introduce errors, don't care to fix them" That, and many people don't know the errors exist, or can't figure out what's wrong or how to fix them. Thanks for replying while I was offline. Zinnober9 (talk) 17:07, 17 July 2024 (UTC)
 * I absolutely concur. MinorProphet (talk) 21:25, 17 July 2024 (UTC)
 * That's great Z9, many thanks for showing me your understanding of how it all works (or ought to). MinorProphet (talk) 21:25, 17 July 2024 (UTC)

Three errors to go; feedback requested
This month I've finished off 975 of 978 (or so) Link in Link errors, and we have three remaining due to these errors being discussed in their conversations: User talk:Beatboy16, User talk:Cyberpower678/Archive 76, and Talk:NeuroQuantology. The first two @Anomalocaris has left comments on as errors to skip, and the third is a near identical conversation of the second's error between different users (no comment currently).

While I agree that we shouldn't refactor the conversations that occurred, I'm also not of the mind to keep errors indefinitely when possible. And I realize in some cases, we just won't be able to do both. I'd like to open up the discussion about the possibility of addressing these in some agreeable way to keep the intent while addressing the error, or if these should be left alone for a better solution.

My initial thoughts are for encircling the error line(s) of each the conversations in either  or   tags, and likely adding a reply to the conversation stating the adjustment and reasoning, explaining that the reader may copy the error statement and either preview or temporarily use in their sandbox/userspace to fully understand the error, but that there isn't a need to keep the error in an active state indefinitely.

Would this be a reasonable way of handling these three errors, or is this idea getting a little too aggressive/bold on the delinting? Zinnober9 (talk) 03:20, 22 July 2024 (UTC)
 * Also, an additional thanks to the user(s) who in the previous few months have dropped these Link in Link errors from 3124 in March to under 1k by July. The low number was very tempting and was a refreshingly quick set to deal with after some of the more involved errors I've dealt with the past year. Grateful to you all and your efforts! Zinnober9 (talk) 03:20, 22 July 2024 (UTC)