Wikipedia talk:Linter/Archive 3

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Archive 3

Archive 4

Replacing <strike> with <s> vs <del>

Wikipedia:HTML 5#strike says <strike>...</strike> should be replaced with <del>...</del> for text that has been deleted or marked for deletion. However I can't think of any such examples onwiki. Can anyone point out usages where replacement with s and del is clearly distinguishable? It seems to me like everything can be blindly replaced with <s>...</s>. In any case both of them have the same visual output. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:10, 8 June 2022 (UTC)

In discussions, or something like an example of a diff you would use <del> I guess. —TheDJ (talk • contribs) 15:13, 8 June 2022 (UTC)

Every case of <strike>...</strike> I have found has been appropriate for replacement with <s>...</s>. I've probably done a few hundred of them. – Jonesey95 (talk) 16:00, 8 June 2022 (UTC)

Lets say in a discussion someone makes a comment, realises that it is factually incorrect later and strikes it. <s> is correct here to indicate it is no longer accurate. In an RfC, someone !votes support, change their mind, strike it and move to oppose. Their support !vote is no longer relevant and <s> would be the correct tag to use. Like this are there specific situations where <del> would be the correct tag to use? From what I have seen, if users mean to delete something, they remove it from the page entirely. I have done bot replacement of <strike> → <s> for limited sets. For example see items 464 and 465 in User:MalnadachBot/Task 12/451-500. I am looking to see if there are any cases where replacing it with <s> would be inappropriate, especially since Wikipedia:Bots/Requests for approval/DoggoBot 2 was denied for failing WP:CONTEXTBOT. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:20, 8 June 2022 (UTC)

I'm going to ask the dumb question, but... does it matter?

~~this uses strike~~
~~this uses s~~
~~this uses del~~

If the end result is the same, then I think the onus is on the user who originally added it to "fix" it if they don't want <s> used. Primefac (talk) 07:44, 13 June 2022 (UTC)

Perhaps Xaosflux can explain since they denied DoggoBot 2. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:14, 13 June 2022 (UTC)

There are about 22,000 pages using </strike>, according to an insource search. None are left in article space. Of the existing usages, about 7,000 are in Talk space; I can't think of a use for <del>...</del> in that space. I haven't poked through the rest of the namespaces. – Jonesey95 (talk) 13:28, 13 June 2022 (UTC)

@Jonesey95, I noticed you updated this entry: {{Looshpah IVTogneme Userbox}}, congratulations on your progress - keep up the good work! — xaosflux ^Talk 13:32, 13 June 2022 (UTC)

If I would have put <strike> there, would you really be lost and wonder what I meant - thinking I was only styling the text for fun? Seems like the community is getting sick of some of these not-really-important lint cleanup jobs... — xaosflux ^Talk 13:34, 13 June 2022 (UTC)

Honestly, I probably wouldn't look at the tags; the meaning is clear from the rendered text.

On a separate note, there are 578 pages with the word "strike" wrapped in strike tags that could easily be fixed by a bot. There are probably similar unambiguous patterns out there. – Jonesey95 (talk) 14:57, 13 June 2022 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ I did, as it was a blind automated task, if there is a community support for this established first that could override this. That being said, there has recently been some pushback on bot tasks that don't really "do" anything useful for readers, who for the most part are taking strike,del,and s to be context-dependent and never actually reading in to the semantic meaning directly. — xaosflux ^Talk 13:28, 13 June 2022 (UTC)

How to find pages with Linter errors and 5+ transclusions?

I just fixed some newsletter pages that had 5+ Linter errors and about 50 transclusions, reducing the total error count in all namespaces by about 17*5*50=4250 errors with fixes to just 17 pages.

Template space is the obvious place to find Linter errors in transcluded pages, but AFAIK, it is completely fixed; the remaining errors in that space are false positives or otherwise do not show up when the template is actually used.

How do we find pages in other namespaces that have multiple transclusions, maybe 5 or more, and also have Linter errors? Fixing those pages will help us reduce the error count as well as the total number of pages in the Linter error lists. I fixed a few hundred userbox pages way back in 2018, and that helped a lot, but I am sure that there are still many pages out there. Ideas? – Jonesey95 (talk) 22:35, 30 June 2022 (UTC)

After I typed out the above, I figured it would be worth a try to request a query. – Jonesey95 (talk) 22:39, 30 June 2022 (UTC)

This report is at User:Jonesey95/linter transclusions if careful editors want to take a crack at it. I have trimmed it from an initial population of 3,500 down to 2,800 by removing some false positives and fixing a few dozen pages that resulted in thousands of Linter error fixes. Preview carefully before saving, since these pages have many transclusions. There are many pages where the Linter error is inside a <noinclude>...</noinclude> section, so it doesn't affect the transclusions, but we might as well fix them anyway.

One common fix is on Userbox pages: converting  to {{clear}} when there is a missing  end tag. If you are bored and want to use AWB to fix these on a mass scale, there are 800+ pages waiting for you (this may not be the right fix on all of the pages). – Jonesey95 (talk) 15:37, 1 July 2022 (UTC)

Lint error namespace drop down not working

Tracked in Phabricator
Task T311202

If you go to any of the lint error categories at Special:LintErrors, select a namespace from the drop down list and submit, it fails with: "Namespace and/or pagename not found or malformed". Using the namespace number in the url still works (for example). —Bruce1ee ^talk 09:24, 2 July 2022 (UTC)

Looks like that's a known bug, see phab:T311202. Rummskartoffel 10:55, 2 July 2022 (UTC)

Thanks. It appears to have been happening for over a week now, but I only noticed it today. —Bruce1ee ^talk 11:00, 2 July 2022 (UTC)

FYI this is working again. —Bruce1ee ^talk 11:48, 7 July 2022 (UTC)

Comments are NOT lint

A lot of people running de-linting bots apparently think code and article maintenance comments are "lint". I don't know where to begin. Just stop. SamuelRiv (talk) 13:11, 9 July 2022 (UTC)

Please provide examples diffs that appear to be a problem. – Jonesey95 (talk) 14:50, 9 July 2022 (UTC)

Note about center template

I have seen a few edits in which <center>...</center> was replaced with {{center}} when it has ... within it. This is incorrect as it makes the text invisible as you can see here. The correct replacement would be to use style="text-align:center;" with or without merging the span tag in it. This is part of a larger issue where {{center}} does not handle unescaped = and |. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:06, 10 July 2022 (UTC)

I am to blame for a bunch of these, and I have have been fixing them by adding |1= to the center template, which appears to work. I have checked the edits to make sure they are working. Articles with this problem appear to be placed in Category:Pages using center with no arguments. – Jonesey95 (talk) 13:10, 10 July 2022 (UTC)

I became aware of this while running MalnadachBot. This search gives span inside center template. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:38, 10 July 2022 (UTC)

I also became aware of it when a couple of editors (including one editor involved in this discussion!) correctly reverted my erroneous edits convert <center>...</center> to {{center}}. I very much enjoy being reverted when I have made an error, especially when it is done without rancor. It's an unpleasant little quirk of the MediaWiki code, and one of the many problems that unnamed template parameters can cause. – Jonesey95 (talk) 16:38, 10 July 2022 (UTC)

Bold, italic, small markup mask blatant div-span-flip

Please see User:Anomalocaris/sandbox/Lint Test version of 19:28, 15 August 2022, where I show that

''<div something>Foo</div>''

fails to generate a proper div-span-flip lint error, where the italic markup can be replaced with ..., ..., or .... What's going on here? Note: I discovered this as I was trying to diagnose the div-span-flip lint error in Wikipedia talk:New pages patrol/Coordination. —Anomalocaris (talk) 19:36, 15 August 2022 (UTC)

This looks like a variant of T306205. I am on a wikibreak now so can't log in to phabricator, but you could add a comment there. – Jonesey95 (talk) 12:03, 18 August 2022 (UTC)

Jonesey95: Thanks, I've added a comment to your phabricator posting. — Preceding unsigned comment added by Anomalocaris (talk • contribs) 05:07, 19 August 2022 (UTC)

Archived pages?

This project doesn't address what to do with pages that are archived. Archived pages have the banner "This is an archive of past discussions. Do not edit the contents of this page." but tend to have many lint errors (I'd wager that most of the remaining Lint errors are on archive pages). This Project essentially has a mantra that I read as "fix it all carefully", but doesn't mention the archives any. Are the Archive pages touchable with regards to the Lint Project, but using extreme care to take care of all the issues in a minimum number of edit(s)? Or are they outright verboden? Thanks, Zinnober9 (talk) 22:36, 22 August 2022 (UTC)

Definitely fix Linter errors on archived pages. The goal of the edits, as with all Linter-related and other syntax-related edits, should be to fix the errors without changing the appearance of the page (or the intended appearance of the page, if the Linter errors are breaking the appearance of the page). – Jonesey95 (talk) 00:20, 23 August 2022 (UTC)

Thanks, I didn't want to cause any issues, and didn't want to proceed on any if there was a known consensus against editing those. Zinnober9 (talk) 03:12, 23 August 2022 (UTC)

Linter errors increasing?

Over the past few hours I've noticed a sudden increase in linter errors on the firefly report. The majority of the contributions to linter error increase was from linter errors from articles, and in seven hours the article linter error count has increased by ~90 and the total count by ~100.

Does anyone know what's happening here? Sheep (talk) 02:14, 9 September 2022 (UTC)

I do not see an obvious reason why this would be happening, but an increase from 171,800 to 171,900 should not be that surprising, given that nothing prevents editors from adding new Linter errors to pages. If gnomes who watch this page were not actively removing errors every day, the counts would definitely increase at a steady rate.

If someone adds a Linter error to a widely transcluded template that then causes Linter errors to appear on dozens or hundreds of pages, the count will slowly increase as those pages are refreshed. Once the error in the template is fixed, the affected pages will slowly be removed from the firefly report. – Jonesey95 (talk) 05:13, 9 September 2022 (UTC)

I'm seeing a different issue on the Firefly report right now. None of the values appear to have changed for the last few hours. The time last updated is correctly changing every 15 minutes or so, but the values in the table haven't budged, despite known progress. I was using it as my counter as I'm getting close to finishing off the MediaWiki talk section, but Firefly's stuck at 146 for that when I've got under 50 errors left. Zinnober9 (talk) 19:52, 9 September 2022 (UTC)

FYI I've mentioned it on the "Firefly report not updating" section; as Firefly mentioned it's probably because of database lag. Sheep (talk) 21:15, 9 September 2022 (UTC)

This is apparently some sort of database lag. When the big number goes back to zero, the report will be able to fix itself. Until then, keep fixing errors so that when the report refreshes, we will all be amazed and impressed by the big drop in error counts! – Jonesey95 (talk) 22:03, 9 September 2022 (UTC)

style="margin: 1em auto;" in tables does not work

Somehow Wikipedia's appearance in articles has changed; using style="margin: 1em auto;" in tables aligns them to the right.

Is this issue only affecting me or is it affecting pretty much everyone? Sheep (talk) 12:34, 11 October 2022 (UTC)

Works for me looking at a random article 13th TVyNovelas Awards. Can you give link to a page where this is not working for you? ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 12:42, 11 October 2022 (UTC)

It works for me on mobile, but on the web it doesn't...

Maybe it's an issue for just me or something? Sheep (talk) 22:06, 12 October 2022 (UTC)

When reporting a problem, always link to a page where that problem is happening. – Jonesey95 (talk) 22:53, 12 October 2022 (UTC)

This is what my PC browser looks like with style="margin: 1em auto;". Sheep (talk) 12:35, 13 October 2022 (UTC)

That's the article Chen Fu-hai, right? It looks normal to me, with the tables in the center. Perhaps there's a browser extension or something that's messing things up for you? --rchard2scout (talk) 12:46, 13 October 2022 (UTC)

That page looks fine to me too. Have you tried running your browser in safe mode, or testing that page in a different browser? —Bruce1ee ^talk 13:07, 13 October 2022 (UTC)

I looked at Chen Fu-hai in three browsers on my Mac, and it looks fine to me. If you want to troubleshoot this problem on your computer, try logging out of Wikipedia, or looking at it with a different browser, or trying a different skin, or starting your browser in safe mode. – Jonesey95 (talk) 13:24, 13 October 2022 (UTC)

It works on my mobile device, maybe there's a problem with my PC. I dont know what is changing the appearance in my PC :( Sheep (talk) 13:54, 13 October 2022 (UTC)

Invoked bogus file option

There's one last Lint error left in Modules, and I'd love to clear another category away for good, but it seems to be stumping me and others who've tried things previously. I wanted to bring it some attention and catch the eye of someone who knows the #invoke command better than I to hopefully solve.

From Linter BFO, the first page Module:Syrian Civil War detailed map/sandbox/doc appears, and it invokes the map from the second page Module:Syrian Civil War detailed map/sandbox. The second page has no lint errors at all. But something with the invoking of the second's map to appear on the first is causing a Bogus file option for [[Al-Abbas, Syria|al-Abbas]], but others like [[Al-Ramadi, Deir ez-Zor Governorate|Al-Ramadi]] are written identically, uses hyphens, commas, and the [[pagename|display as]] format, but aren't evoking a BFO flag.

I'm tempted to remove that one marker for a few minutes (restoring it after the test) to see if that clears this issue or if another one appears as the BFO, but since the page is under WP:1RR, I don't want to tick people off for a such a tiny test without a theory or far more confidence of what the issue might be, and I don't have a theory to go on at the moment. Does anyone have any ideas why it seems to be only this one, or what the issue is? Zinnober9 (talk) 00:06, 20 October 2022 (UTC)

I tried syncing the sandbox doc page with the main one but that didn't help. Maybe just remove the map from the sandbox docs instead? -- WOSlinker (talk) 11:51, 20 October 2022 (UTC)

I've tried to disect what on earth it could be complaining about, to no avail. I've tested uing the fully expanded version to look at the file in question, but to no luck (it wouldn't produce linter errors). Somehow, even copying the entirety of the page onto another page seems to not trigger the linter error (tests). I'm mostly convinced the issue isn't with the actual file definition, as I see nothing wrong with it (for reference, its

<div class="od" style="top:52.018%;left:75.685%"><div class="id" style="left:-3px;top:-3px">[[File:Location dot red.svg|5x5px|[[Al-Abbas, Syria|al-Abbas]]|link=Al-Abbas, Syria|class=notpageimage]]</div><div class="l0">[[Al-Abbas, Syria|al-Abbas]]</div></div>

), but perhaps maybe some just weird software bug, since its the only page experiencing it. Aidan9382 _(talk) 12:33, 20 October 2022 (UTC)

Note that I've recently removed and re-added the invocation and this seems to have potentially resolved the issue (somehow??), as I'm not seeing it pop up anymore. Aidan9382 _(talk) 13:31, 20 October 2022 (UTC)

Weird. Thank you so much for fixing it! Zinnober9 (talk) 22:36, 20 October 2022 (UTC)

Firefly Multiline HTML table in list (articles) stuck at 1

The Firefly table of Outstanding linter errors on enwiki has been stuck at 1 for HTML table in list (articles) for some days now, even when there aren't any such errors. —Anomalocaris (talk) 23:02, 25 October 2022 (UTC)

Other counts are also not updating. For example, Missing end tag (Drafts) has been stuck at 394, but it's down to 356 at this moment. —Anomalocaris (talk) 23:46, 25 October 2022 (UTC)

It is because of database lag that started happening about 12h ago. In such a case, the time updated updates as normal, but the number of errors in each category per namespace don't update. When the replag goes back to zero, the report will be able to update itself. Sheep (talk) 01:51, 26 October 2022 (UTC)

Looks like all but Slice 1 are back up and running now, and Firefly's updating again. Zinnober9 (talk) 00:45, 27 October 2022 (UTC)

Need assistance fixing a lint error

FYI

– Originally asked at WP:VPT

Hello! After seeing a former admin (ClockworkSoul) return (because of a personal attacking vandal on their request for admin rights), I've been working on fixing all the lint errors on their user pages and relevant subpages. However, I"ve run into an issue while attempting to fix one of their subpages. On their subpage User:ClockworkSoul/userpage/panel left, there's a line of code which is: width=95% align=center style="background-color: #F3DE94; text-align: left; border: 1px solid #CC9;". The issue comes with align=center, which according to mw:Help:Lint errors/obsolete-tag should be replaced with style="text-align:center", however that causes issues as the text is already aligned to the left side with text-align:left. So does anyone know what I should replace align=center with? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:04, 27 October 2022 (UTC)

I've given this a quick look, and I'm not entirely sure the removal of align= applies here. Reading more into the issue and looking at the wording on the help page closely, this seems to apply specifically to align applied on specific cells, and not the entire table. For an example of why, see the examples in the box below. I think it should be fine as-is.

Test examples on different settings

Original (align=center, text-align=left) - This is fine

No text-align (align=center) - Text align was default left anyways

Swapped (align=left, text-align=center) - Clear difference in the effect of "align" and "text-align"

Cell-specific align (no table align=, text-align=center, cell align=right) - Notice how this is still against the left, but the text is aligned to the right

Both having align (table align=center, text-align=center, cell align=right) - Same as above, but now the table is centered too

Aidan9382 _(talk) 18:45, 27 October 2022 (UTC)

[copied from VPT thread:] Wikipedia talk:Linter is a good place to ask about Linter errors. I do not see any reference to align=center being a Linter problem on that Help page, but I may have missed it. There are no remaining Linter errors on User:ClockworkSoul or its subpages except in one or two pages that have no transclusions. – Jonesey95 (talk) 17:44, 27 October 2022 (UTC)

How to change the number of items shown on Linter reports

I have always thought that there was a default of 200 items shown on each page of the Linter reports, but when I went to do some work at Commons (total errors reduced from 13 million to 6 million in the last three days!), I found that it was showing me only 50 errors per page, which was like looking through a keyhole. I asked, and I was told that when you change the Preferences > Recent changes > Number of edits to show in recent changes, page histories, and in logs, by default preference, it affects not just Contributions and History, but these reports. The more you know.... – Jonesey95 (talk) 17:33, 27 October 2022 (UTC)

Thanks, that's very useful. I increased my "number of edits shown ..." here on enwiki, and the linter report page size has also changed. —Bruce1ee ^talk 21:56, 27 October 2022 (UTC)

Linter errors progression

This is the progression of Linter errors from 8/28/2018 to today. We've been fixing lint for more than four years and cleared over 5/8 of the initial lint back then.

Date	Outstanding linter errors	Source
28 August 2018	24083947	[1]
17 June 2021	22450097	[2]
1 March 2022	15349584	[3]
23 March 2022	13996850	[4]
25 March 2022	13845831	[5]
12 June 2022	11248900	[6]
30 June 2022	11122530	[7]
1 July 2022	11116651	[8]
3 Nov 2022	8890312	[9]
4 Feb 2023	7994445	[10]
13 Feb 2023	6983624	[11]

I'd say that over 11m errors have been fixed by bots, with the majority being from MalnadachBot. Malnadachbot 13 I believe has removed ~2m errors due to blanking old IP talk pages. Sheep (talk) 16:50, 28 October 2022 (UTC)

I have boldly trimmed the table for readability. There are more reports of error counts above and in an earlier thread. Most of the early progress in 2017 and 2018 was made by fixing pages with many (sometimes millions) of transclusions. That is the reason for the quick decrease in error counts in the early days. Over on Commons, where there appears to have been very little de-Linting activity until this week, I reduced the error count from 13 million to under 6 million in about four days, and there are still many pages with errors that are transcluded thousands of times.

Every once in a while now on en.WP, I run into a template or other page that has a few dozen transclusions and that is causing a Linter error that does not manifest on the page being transcluded, but I am pretty sure that 99+% of the edits being made in 2022 are to individual errors on individual pages. Unless bots are involved with that work, progress is slow. – Jonesey95 (talk) 18:15, 28 October 2022 (UTC)

Occasionally I go to different language wikipedias and fix Lint errors there. Some of them are small enough that I could clear the whole wiki in a day. A common thing I noticed is that a large part of their errors come from templates that were imported from here years or decades ago. English wikipedia templates are tried and tested with many active maintainers, so instead of creating them from scratch, other wikis import them from here and mostly forget about them afterwards (many luafied templates of en.wp still use parser functions elsewhere). Its the same thing with articles, so fixing them here will prevent errors from spreading to other wikis in future. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:31, 29 October 2022 (UTC)

I think we should display this table on the subject page to give more visibility to our work. Seeing these number will motivate poeple to continue working on a seemingly endless backlog and give hope to end it one day. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:37, 29 October 2022 (UTC)

Firefly report not updating

Is the Firefly report down? It has not updated since 2022-05-30 21:17:24 (UTC). —Bruce1ee ^talk 23:34, 30 May 2022 (UTC)

It's always a good idea to ping the report's maintainer, Firefly. In the meantime, there are plenty of errors to fix! – Jonesey95 (talk) 23:55, 30 May 2022 (UTC)

It's possible that this is a wider issue. I'm seeing editors saying that various reports and queries are failing to run, e.g. T309570. – Jonesey95 (talk) 00:58, 31 May 2022 (UTC)

Okay, that's now four bots that are affected over the past 2 or 3 hours. And about 6 hours ago, I was receiving error messages about "overflow" when I'd try to look at a page history. Do you think something is overloading the system? Or is this an En.Wikipedia problem only? Liz ^{Read! Talk!} 01:14, 31 May 2022 (UTC)

Yeah, that'd be down to T309570, which seems resolved now :) firefly ( t · c ) 07:10, 31 May 2022 (UTC)

The Firefly report is running again. —Bruce1ee ^talk 06:25, 31 May 2022 (UTC)

The report is not updating again, since 2022-06-02 11:18:15 (UTC). I don't know if this is the same problem as we had before (pinging Firefly). —Bruce1ee ^talk 06:27, 3 June 2022 (UTC)

@Bruce1ee acknowledged - will try to take a look today :) firefly ( t · c ) 10:54, 3 June 2022 (UTC)

Thanks ... —Bruce1ee ^talk 10:56, 3 June 2022 (UTC)

It's running again! Thanks Firefly. —Bruce1ee ^talk 12:47, 8 June 2022 (UTC)

We have a problem; the report is still running, but the numbers aren't updating. Sheep (talk) 03:31, 11 June 2022 (UTC)

There is some sort of database lag that will probably not be resolved until Monday. In the meantime, you can click through to pages from Special:LintErrors as we used to do in our cave-dwelling days. – Jonesey95 (talk) 05:25, 11 June 2022 (UTC)

... and it's working again! —Bruce1ee ^talk 15:13, 12 June 2022 (UTC)

and it stopped working as of 8/11 9:47am UTC. Also congrats for 10m errors on August 7 03:45 UTC. Sheep (talk) 20:52, 12 August 2022 (UTC)

pinging Firefly. Sheep (talk) 13:31, 14 August 2022 (UTC)

It's running again. :) —Bruce1ee ^talk 17:03, 15 August 2022 (UTC)

As of now the report is still updating, it's just the statistics aren't updating (pinging @Firefly:). Sheep (talk) 14:25, 9 September 2022 (UTC)

@Sheep8144402 usually when this happens (timestamps update but the numbers don't change) it's down to database replication lag between "live" and the toolforge replicas. I'll see if there's anything obviously wrong though. firefly ( t · c ) 15:14, 9 September 2022 (UTC)

OK, as of 2022-09-30 05:16 the report stopped updating. I don't know what's going on with the report.

(pinging Firefly.) Sorry, that was a lie, acknowledged, thought it didn't update the first place. Sheep (talk) 05:28, 30 September 2022 (UTC)

I'm seeing it updated at 2022-09-30 05:31:47. Maybe wait an hour or two before pinging, and also check replag. If there are non-zero numbers on replag, the report won't be able to update. The actual Linter lists stay up to date, and there are plenty of pages to work on. – Jonesey95 (talk) 05:37, 30 September 2022 (UTC)

The report just stopped updating, and the last time I checked, the updated time was 2022-11-03 17:17:25 UTC. And when I checked replag the seconds are at the 64-bit limit. Is there anything wrong to the system? Because the timestamp isn't updating. (pinging @Firefly: just in case something was actually wrong). Sheep (talk) 17:47, 3 November 2022 (UTC)

Seems to be working as far as I can see, and the few data points I checked matched what Special:LintErrors shows. firefly ( t · c ) 17:53, 3 November 2022 (UTC)

I don't understand the obsession some have with the report not updating for a short time. There are millions of Linter errors lying about and it is better use of everyone's time to fix them instead of getting worked up about a small delay. If users want accurate stats, they should ask the W?F to spend some of their excess millions to fix the horrible official counter instead of bothering Firefly after every small delay. 2409:4071:4E07:E71E:0:0:4348:8402 (talk) 18:23, 3 November 2022 (UTC)

I agree 100%. When the Firefly report is down for a few minutes or even hours, it will probably come back on its own. Click on one of the links and work on fixing some errors instead of pulling the big red alarm handle and waking us all up over something that will fix itself. There is usually a back-end problem that Firefly can't do anything about, so posting here is pointless. I recommend waiting for 12 or even 24 hours before posting a query about the status of the report. – Jonesey95 (talk) 23:05, 3 November 2022 (UTC)

Ig from now on unless it has to do with database lag, we shouldn't ping Firefly...

When the report doesn't update values (not the time updated) it's usually due to database lag so no need to post such a thing here. Sheep (talk) 23:35, 3 November 2022 (UTC)

Another milestone: no articles with 3 or more lint errors

As of right now, there's no more articles with more than 2 errors!^{(except obsolete tags, of course)} Huge thanks to Jonesey95 and WOSlinker, who I've regularly seen fix errors from this list. And of course to everyone else working on this! --rchard2scout (talk) 12:44, 31 May 2022 (UTC)

Also thanks to Bruce1ee, and to gnomes who prefer to keep their heads down, and to Galobtter for setting up the report way back in October 2018, when there were thousands of articles with dozens of Linter errors each. We have come a long way. – Jonesey95 (talk) 14:22, 31 May 2022 (UTC)

... and Anomalocaris, who I often see doing general fixes besides just lint repairs on pages. —Bruce1ee ^talk 14:53, 31 May 2022 (UTC)

Another milestone we recently achieved is in reducing the number of pages with high priority errors to below 100k (currently at 74.7k). Nearly all of the remaining deletable table tags and html5 misnesting will have to be cleared manually. Also enwiki no longer has the highest number of errors among all WMF wikis. That goes to commons now with 12.88 million errors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:27, 31 May 2022 (UTC)

Here's today's milestone: User:Galobot/report/Articles by Obsolete Tags is showing a few articles with just 20 obsolete tag errors! That means that for articles where the Linter error counting is working correctly (it often undercounts inside of complex templates), there are fewer than 1,000 articles with more than 20 obsolete tags (the Linter counter maxes out at 21 of any one error type for a given page). Good job, gnomes. – Jonesey95 (talk) 17:26, 13 June 2022 (UTC)

High-priority errors are below 50,000 at this writing, and the obsolete tag report is showing only 14 articles with more than 6 errors. Thanks to the bots and gnomes who continue to chip away at these counts. – Jonesey95 (talk) 22:28, 30 June 2022 (UTC)

Note: the highest number of linter errors on one project is actually viwiki at 30.85m errors; see here for more info. Sheep (talk) 10:42, 6 July 2022 (UTC)

It's also interesting to note that the English Wikipedia's average errors per article is ~1.7 (11m errors / 6.5m articles), whereas the Vietnamese Wikipedia's average errors per article is ~25 (30m errors / 1.2m articles). See here and here. —Bruce1ee ^talk 11:32, 6 July 2022 (UTC)

Milestone of 10/3: We're now starting to see a bunch of articles with only 2 obsolete HTML tags. Months from now we may see articles with just one. Keep fixing gnomes. Sheep (talk) 12:43, 3 October 2022 (UTC)

(Update as of 10/24) And now there are no more articles with at least 3 obsolete HTML errors. Sheep (talk) 21:00, 24 October 2022 (UTC)

(Update as of 10/28) In just under a month (which was my prediction) we've made it to seeing a few articles with just one obsolete tag. I can't believe we've made it this fast, but thanks to the other gnomes that fix obsolete center tags mostly. Sheep (talk) 13:06, 28 October 2022 (UTC)

I remember when we had 250k obsolete tag errors in mainspace, they were spread across ~26k pages. Now we have 9k errors spread across 8.4k pages. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:55, 29 October 2022 (UTC)

(Update as of 11/23) Notice that there is an unusual decrease in size when looking at the page history; there are now fewer than a thousand articles with obsolete tags. I expect that within seven days from this post, we clear that entire list and start working on articles with other linter errors. Sheep (talk) 13:05, 23 November 2022 (UTC)

As of this timestamp, obsolete html tag count in mainspace is down to zero. Thanks to everyone who worked to eliminate the backlog. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:29, 25 November 2022 (UTC)

Vietnamese WP follow-up

I did some poking around on vi.WP, and according to the Firefly report, 29,863,494 of the 30,851,770 total errors are Misnested tags in User talk space. I believe that many or even most of these have been caused by substitution of vi:Bản mẫu:Welcome8 and vi:Bản mẫu:Welcome8IP, two welcome templates. I have submitted talk page edit requests on those pages, and someone will need to a run a bot through a bunch of pages to fix the substituted errors.

There are also many Linter errors in templates on vi.WP. When those templates are transcluded, they can cause Linter errors on each page with a transclusion. I have fixed a few, but there are 8,000 errors listed. Here on en.WP, we took care of 98% of the template problems by early 2019. If you decide to dive in over there, be aware that some of their underlying templates do not work the same as ours. – Jonesey95 (talk) 22:11, 24 October 2022 (UTC)

lintHint not reporting center tags

The "Singles" section in Maon Kurosaki has two <center>...</center> tags, but lintHint is not reporting them. The "Music videos" section has been commented out, but not the "Singles" section. —Bruce1ee ^talk 22:53, 20 November 2022 (UTC)

If you use Special:ExpandTemplates and try with the following:

{| class="wikitable"
| <center>{{N/A|Non-album single}}</center>
|}

After expansion, you end up with:

{| class="wikitable"
| <center>data-sort-value="" style="background: #ececec; color: #2C2C2C; vertical-align: middle; text-align: center; " class="table-na" | Non-album single</center>
|}

So the opening center tag is in the style area of the table syntax and doesn't end up getting applied. The closing center tag is still in the table cell so should probably be shown as a stripped tag error but that doesn't happen either. -- WOSlinker (talk) 23:26, 20 November 2022 (UTC)

Thanks, I see what is happening. I've removed the <center>...</center> tags as they aren't doing anything, and {{N/A}} already centers the text. Also, besides the stripped tag not being reported, there are missing close-italics in that cell that are not being reported. —Bruce1ee ^talk 06:09, 21 November 2022 (UTC)

The nature of this bug appears to have changed, at least for me, since last week. (I also noticed a bunch of new articles with Linter errors in User:Galobot/report/Articles by Lint Errors, some of which have not been modified in months (example here), so it is possible that the Linter code may have been updated to detect errors that it had previously missed.) I now see a stripped center tag with the expanded code, but not with the original template example. I have submitted T323869. – Jonesey95 (talk) 16:18, 27 November 2022 (UTC)

Lint problems not updating, delay in pages?

I've cleared some pages of lint in the last few minutes, but their info pages are not updating and are still displaying the original counts. They are not being cleared from pages like this: misnested (the Iris × hollandica issue was cleared 30+ minutes ago, but still appearing there). Is there a database lag somewhere? I see https://replag.toolforge.org/ is clear right now.

Also pages like misnested or link in link are taking a long time to load (been that way for a day or three), but article pages loading normally and quickly. Zinnober9 (talk) 21:13, 8 December 2022 (UTC)

This is T246403, but I haven't seen it for a while. I added a note to the bug report. In the meantime, the WMF is using banner ads to raise millions of dollars to support Wikipedia, so I'm sure that these three-year-old bugs will be fixed real soon now. /s – Jonesey95 (talk) 21:36, 8 December 2022 (UTC)

Jonesey95: This may be more than T246403. Page information is not updating lint errors after lint fix (which seems to be part of the Phabricator maniphest), but also, the edit lintid function isn't updating. This is true with respect to at least Iris × hollandica, French Louisianians, Draft:Elisabeth Niggemeyer. —Anomalocaris (talk) 21:57, 8 December 2022 (UTC)

@Jonesey95 @Anomalocaris Thanks, for a few moments I thought I was losing my mind and was wondering if my laptop was acting up.

Looks like this is working and updating again, but any lint issues that were fixed during the ~~mess~~ down period weren't automatically cleared from the lists (at least haven't so far) and will need a purge. I don't know if that will take care of itself across the board after a few hours/a day or not, but keep an eye out for pages that might already be cleared. Zinnober9 (talk) 05:41, 9 December 2022 (UTC)

The problem returns. I fixed bogus image options in Talk:Exception management, Talk:Frederick the Great, Talk:New Spain, and Talk:Mary, mother of Jesus. They remain in Bogus image options in Talk space, their page info pages still show lint errors, and the editor lintid isn't updating. —Anomalocaris (talk) 21:07, 9 December 2022 (UTC)

I fixed linter errors in D. Daly, and the page information still reports 2 missing end tags. I purged the page; nothing works. Firefly is responsible for the Firefly report, which is working right now. What do we do right now, contact WMF or something? Sheep (talk) 14:47, 10 December 2022 (UTC)

I don't know, but the issue is certainly on Wikipedia's end and hopefully can be addressed/corrected soon.

While it's down, I don't feel comfortable proceeding to cut down specific groups of errors I've taken interests in fixing, since there's no safety net updating to verify I didn't quack things up, or to prove to others the issues are cleared. I might nibble on some of the smaller pages with only one or two errors if this becomes an extended thing, but I hope it's a quick fix. No way in hell I'm touching user/user talk pages with it down. Zinnober9 (talk) 05:48, 11 December 2022 (UTC)

Zinnober9: lintHint is your friend. If lintHint doesn't find lint errors, there probably aren't any. Remember that lintHint doesn't expand relative links. For example, in Portal:Science, {{/Header}} really means {{Portal:Science/Header}}, but lintHint does not do this expansion, so use Expand templates for pages with relative links. —Anomalocaris (talk) 02:30, 12 December 2022 (UTC)

Just to further confirm this timeline, there was brief period where the patch that broke this was reverted for another reason, in https://phabricator.wikimedia.org/T324801, before the breaking was restored again. Which is why it may have looked like it was fixed for a bit on the 9th.

Again, sorry for all the disruption. Arlolra (talk) 17:07, 13 December 2022 (UTC)

A fix was deployed this morning and the problem should be resolved now. It was result of a refactoring that went out in last week's train,

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/864723/2/includes/Rest/Handler/ParsoidHandler.php#b733

Linting was effectively disabled for a few days.

Some pages may need purging / null edits to force a reparse to see the lints cleared away. Or, you can wait until the next time the page is edited for that to happen on its own.

Sorry for the disruption everyone, Arlolra (talk) 15:56, 13 December 2022 (UTC)

That seems to fit with what I'm seeing, the older entries aren't dropping off the list but pages I fix now, are. Thanks for the update. LicenceToCrenellate (talk) 16:22, 13 December 2022 (UTC)

The older entries will drop off if you null edit them (click Edit and then Publish without making any changes). The system (and a bot, because the system is buggy) eventually null-edits articles automatically, but it can take weeks or months. – Jonesey95 (talk) 18:56, 13 December 2022 (UTC)

I've been null editting the pages on the list to refresh it, with some success. However, despite several attemps, I can't get this page to drop off the list: https://en.wikipedia.org/wiki/Negev_Foundation

Is there something I'm missing? LicenceToCrenellate (talk) 13:23, 15 December 2022 (UTC)

I'm not seeing it in any lint error list. Even when I search for Negev Foundation in the "Search for pages with lint errors" at the bottom of Special:LintErrors, it doesn't show up. (When I search for HAT-P-30, for example, it shows up as having links-in-links errors.) —Bruce1ee ^talk 13:51, 15 December 2022 (UTC)

I must have tried several times over the course of few hours, posted about it and then it drops off the list by itself! I need to be more patient, I suppose! Thanks for looking. LicenceToCrenellate (talk) 14:08, 15 December 2022 (UTC)

Linter errors false positive

I fixed linter errors in Talk:Little Shop of Horrors (musical) and it appears that there are two false positives. Here are the extra lint I couldn't find:

Stripped tag
Missing end tag b

I use the find extension in my browser, typed and , and got twelve of both, and ''', and got 20 (an odd number of missing end tags of b or i should result in an odd number of what I can find normally). I used Special:ExpandTemplates, and got 24 of both and 38, respectively.

It appears that the lint comes from InternetArchiveBot's signature, as I used lintHint and the lint comes from that signature. Is there any way to fix these lint? Because these lint appear in the page information. Sheep (talk) 20:03, 19 December 2022 (UTC)

It's due to the broke ref tags in the section above it. I've encountered this ghost issue before in a similar way, but it's typically with miswritten tags like the incorrect when I find them (both the broken ref and br don't appear in lint, but appear red with the syntax highlighter). Since I don't know if I want to activate those refs, rewrite them as /ref>, or <nowiki> the offending closers, I'll leave the change up to you, but that's where the issue is. Zinnober9 (talk) 20:28, 19 December 2022 (UTC)

This was the fix. As Zinnober9 says, sometimes syntax unrelated to Lint errors is so broken that it confuses the Linter. – Jonesey95 (talk) 17:14, 21 December 2022 (UTC)

Help with Wikicite issue

Hi, I've gotten myself into a pickle. Another editor changed all citations on Green Party of California from citeweb to Wikicite, and in doing so, introduced the lint issue of "Misnested tag with different rendering in HTML5 and HTML4" on all? most? with this change. I reverted the two edits due to the introduction of the error, and since both (to me) display the references in read view as the same. The editor shortly after contacted me on my talk page asking for me to explain how their version is broken, and how to fix it. But Wikicite is not something I've used, and in looking at the Wikicite Template, is almost discouraged from being used. My sandbox tests of attempted fixes all failed since the template examples don't match the format of the more familiar cite web, and none of the articles I found that currently use Wikicite seem to use web addresses in the citation, so I'm unable to figure out a solution. I have zero issues with their content, I only object to the introduction of the lint errors. But since I've slept on it, I'm starting to wondering why they wanted to rewrite the citations another way when both (to me) appear identical.

Was I in the wrong for reverting, and how do I proceed in resolving this issue? Thank you for your wisdom, Zinnober9 (talk) 19:50, 24 December 2022 (UTC)

Those edits were a massive WP:CITEVAR violation, apparently undiscussed, so you were right to revert them. I think that the Linter problem arose from <cite>...</cite> tags, generated by {{Wikicite}}, with line breaks before the closing </cite> tags. That could probably be fixed with insertion of {{trim}} around parameter |1= in {{Wikicite}}. Given that Wikicite is used in only 2,000 articles and does not appear to be generating Linter errors, it may not be worth adding more complexity to that template. – Jonesey95 (talk) 21:15, 24 December 2022 (UTC)

Thank you. I knew cite played a factor in that template's limitations, but that was the extent of it. I appreciate your assistance and the info. Happy holidays! Zinnober9 (talk) 01:16, 25 December 2022 (UTC)

Template Large?

Something broke... An hour ago, a few hundred pages started appearing in Category, all claiming to be missing bold tags. Mostly "Category:Orphaned articles from [date]" pages, that contain the line: {{align|center|{{resbox|'''{{large|{{Random page in category}}}}'''}}}}. I don't see any one page that seems to be the linking culprit, and both large and {{Random page in category}} (without large??) won't allow bolding from the outside of the {{ }}.

And now I see things containing {{large|whatever}} like {{nowrap|{{large|{{lang|zh-cn|模式口}}}}}} (for one example) are starting to popup in Paragraph wrapping workaround lint category; 72 some errors there.

Anyone know what happened? Both "Paragraph wrapping workaround" and anything in Category: were clean according to the Firefly/Lint reports two hours ago. @Jonesey95 Pinging you since I see there's a merger proposition with Large and Larger and you've been a part of that discussion. Anything get changed this evening to cause these fallouts? Zinnober9 (talk) 04:23, 7 January 2023 (UTC)

The TFD notice had pushed the template markup to second line. I have moved it back to first line, should be fixed now. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:45, 7 January 2023 (UTC)

Ah, thank you, @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ! I knew template pages were temperamental, but I didn't realize that was the error. All issues relating to this appear to be resolved. Happy new year to you! Zinnober9 (talk) 05:00, 7 January 2023 (UTC)

Non-Replicatable

I'm at a complete loss on this one... The fostered content issue on Talk:Resident Evil Gaiden I can't replicate in my sandbox to fix. I've copied just the highlighted error section, I've copied the whole dang talk page, no errors when copied to my sandbox. The Article C class template appears to be written correctly, and I've purged the page as well as did a dummy edit (adding a space). Nothing has cleared it yet. Any thoughts on what I'm missing? Thanks, Zinnober9 (talk) 01:06, 19 November 2022 (UTC)

Strange. FWIW, this problem appears to show up only on the Talk pages that transclude that gradin scheme/row template. – Jonesey95 (talk) 05:51, 19 November 2022 (UTC)

There's also this other one (unrelated)... The table on Talk:Paris/Archive 16 claims fostered content, but the table's clean in sandbox. Thought I cleared it the other day, but I apparently didn't. Same with the purging, and such. Zinnober9 (talk) 06:03, 19 November 2022 (UTC)

I've done some testing on my own sandboxes, and it seems this linter error is one that, for whatever reason, insists it should only exist on talk pages. Using Talk:Resident Evil Gaiden as my test content, I've compared the results of expansion of it on a talk and non-talk - no differences. I've also tried putting the same expanded version on a user talk page and a user page, and still only the user talk page earns the linter error. Even comparing the raw html shows no (or at least no relevant to linter) differences between the two.

The example from Talk:Paris/Archive 16 seems to be displaying the same behaviour too (only complains on talk pages). Aidan9382 _(talk) 10:46, 19 November 2022 (UTC)

Not sure why it only occurs on the talk page but updating Template:Collapsed infobox section begin to move the templatestyle within the td tag fixes the issue on Talk:Paris/Archive 16. I think the other might be fixed with a similar fix, maybe to Module:Class to move the templatestyle in that. -- WOSlinker (talk) 12:32, 19 November 2022 (UTC)

I've done some testing and yes, moving the templatestyles for class into the td should fix it. Weird that thats how it seems to work (and only on talk pages no less), but oh well. Aidan9382 _(talk) 12:56, 19 November 2022 (UTC)

Pinging Nihiltres, who updated Module:Class. We don't fully understand this Linter error, but it appears that moving the templatestyles either outside the table or inside the td tag will resolve it. Is something like that possible without breaking anything? – Jonesey95 (talk) 14:07, 19 November 2022 (UTC)

I've made a change in Module:Class/sandbox for this if anyone want to check it and see that it's ok. -- WOSlinker (talk) 15:09, 19 November 2022 (UTC)

It looks OK on Template:Class/testcases (the template sandbox is pointed at the module sandbox) and, just in case the CSS was carrying over from the non-sandbox template, I also tested it alone on my personal sandbox. If it solves the linter error and doesn't seem to break anything else, which it seems to, I think WOSLinker should just implement it in the main module. :) {{Nihiltres |talk |edits}} 17:12, 19 November 2022 (UTC)

Thanks for checking. I've updated the module now. -- WOSlinker (talk) 17:45, 19 November 2022 (UTC)

Thank you both for checking and finding the same results. I thought I was missing something really stupid and just not finding the culprit. I've gotten mostly stuck on the last remaining 19 in Talk, so hopefully any fix by @Nihiltres: will clear up more of those (and knock down the User Talk ones too before I go after them) Cheers to all, Zinnober9 (talk) 14:57, 19 November 2022 (UTC)

part two

Found another one that's clean in my sandbox, but linty on the original. Template talk:Infobox officeholder/Archive 6 My Nov 9 edit (equal to my 23:42, Nov 20 revert) is sandbox clean and I can't clear this one (purged and whatnot). Any thoughts, @Nihiltres: @Aidan9382: @WOSlinker: ? (pinging you three since you all helped/had ideas on the previous one). Zinnober9 (talk) 23:38, 2 December 2022 (UTC)

Zinnober9: Ditto the sandbox thing: User:Anomalocaris/sandbox/Lint Test is an exact copy of Template talk:Infobox officeholder/Archive 6 and the information page shows no lint errors. Perhaps there is a template on this page that behaves differently in the Template talk namespace. But, I was unable to find the error using Expand Templates and lintHint. —Anomalocaris (talk) 21:56, 22 December 2022 (UTC)

@Zinnober9: Same thing as the above conversation seems to be happening. For some reason, <templatestyles>...</templatestyles> behaves weirdly on talk pages compared to non-talk pages. For example, these 2 pages (User talk:Aidan9382/sandbox and User:Aidan9382/sandbox3) have the same content (its the expanded version of Template talk:Infobox officeholder/Archive 6), but only the talk page one produces linter errors. The fix is to move the templatestyles inside a row, so it isnt considered fostered (E.g. like this), but for the page you mentioned that would likely require changing the template itself, which I'm not sure is simple to do. As for why this happens, ¯\_(ツ)_/¯, I don't think it's intentional though. Aidan9382 _(talk) 22:52, 22 December 2022 (UTC)

@Aidan9382: @Anomalocaris: At this point I'm considering just rewriting it using the more expected syntax of

{{Infobox officeholder
| image   = Abraham Lincoln O-77 matte collodion print.jpg
| caption = Portrait by [[Alexander Gardner (photographer)|Alexander Gardner]], 1863
| alt     = A bearded Abraham Lincoln showing his head and shoulders
}}

and dropping the class="infobox vcard" and switch syntax, but I'm not sure if the caption conversation limits or prevents such a change with the Lint changing guidelines. Open to thoughts. Zinnober9 (talk) 23:27, 22 December 2022 (UTC)

Since no objections have been stated, I've gone ahead and cleared this error by rewriting that part of the infobox to the more usual syntax for the same visual read without the ghost error. It's an exact copy of the top section of Abe's infobox. Removed the duplicate parameter info in the lower section (so they don't display twice), since this upper section can't seem to work without the Order, Office, VP, parameters. Zinnober9 (talk) 10:06, 9 January 2023 (UTC)

Error in Linter syntax

The familycolor code 'unclassified' in the infobox at Ndrangith language is generating a Linter error. No idea why that article specifically; these color codes have been used for over a decade. — kwami (talk) 12:08, 10 January 2023 (UTC)

I saw that on an article about a month ago, I just removed 'unclassified' to fix it. LicenceToCrenellate (talk) 12:57, 10 January 2023 (UTC)

That broke it, actually, and it needed to be restored. All language infoboxes have a color code; if they don't, they generate a tracking error so they can be fixed. — kwami (talk) 12:59, 10 January 2023 (UTC)

@Kwamikagami and LicenceToCrenellate there were misnested li and ul tags that came into play only when familycolor "unclassified" and "isolate" were specified. This should fix it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:15, 10 January 2023 (UTC)

Thanks! — kwami (talk) 13:17, 10 January 2023 (UTC)

Missing end tag not reported in template

The 11 April 2022 revision of {{Infobox Olympic sport}} is not reporting a missing end tag in this line:

* [[Ice hockey at the 1920 Summer Olympics|1920]] ''(at the Summer Olympics)

The template was generating a missing end tag error in Ice hockey at the Olympic Games. I have fixed the template (after testing it in the template's sandbox), but am puzzled why no lint error was reported. —Bruce1ee ^talk 09:29, 15 January 2023 (UTC)

The line with that error is contained within a switch statement. That section of the switch statement is not rendered on the template page because there is no value for |sport=. This is normal. The line is rendered only when the template is transcluded and |sport=ice hockey. Good job figuring out the problem! – Jonesey95 (talk) 15:26, 15 January 2023 (UTC)

Thanks, that explains it. —Bruce1ee ^talk 15:56, 15 January 2023 (UTC)

Stubs and Templates "Bogus" Images

Something was ~~broken~~ changed today and hundreds of Stubs and Templates are complaining of bogus image errors "30pxpx". (number varies, but all are "pxpx") I haven't identified a common page yet. Thoughts? Zinnober9 (talk) 21:00, 12 January 2023 (UTC)

Removing "px" from "pix = 30px" in the template, for example here in {{Albania-bio-stub}}, removes the bogus lint error from the pages calling the template, although I don't know why this would only show up now, considering that {{Albania-bio-stub}} was last changed in January 2019. —Bruce1ee ^talk 21:48, 12 January 2023 (UTC)

Some of the pages, like 2013 Rome municipal election, need to have "px" removed from {{tick|15px}} here. —Bruce1ee ^talk 22:09, 12 January 2023 (UTC)

This change was due to a bug fix being deployed. See T207032. "30pxpx" is not valid, but it was supported for a long time. Support for it was removed in 2008 and 2013, and both times people freaked out instead of fixing the affected pages, and the workaround was restored. The correct action here is to fix these long-standing instances of invalid syntax before editors show up with pitchforks and torches, demanding that the invalid syntax continue to be supported. – Jonesey95 (talk) 23:24, 12 January 2023 (UTC)

Adding {{Str number/trim|(existing parameter)}} has been useful in some templates and template-like pages to allow for both numerical and number+px input. Here's a sample diff. It is not always needed, but when a template has hundreds or thousands of transclusions and you don't want to fix every one, it comes in handy.

We should expect errors to trickle into the Linter bogus image options pages over the next few months. The job queue can take many months, sometimes longer, to refresh pages when MediaWiki code changes. – Jonesey95 (talk) 01:13, 13 January 2023 (UTC)

Looking like a preemptive strike against Template:Rint and Template:Infobox rail line might be good ones to run {{Str number/trim|(existing parameter)}} on. Frequent appearers so far (more so for Rint). I'm not able to edit either these templates, and probably a good reason, since I don't at this time see the exact spot(s) to stick it. Zinnober9 (talk) 06:33, 13 January 2023 (UTC)

I looked at {{rint}}, but it has too many instances of |size= to wrap elegantly. I think fixing the articles where the parameter contains px will be better. Here's a sample fix. It looks like there are only about 100 to 150 affected articles and templates (I just null-edited all of the ones that I could find, so their sudden appearance in the category should not continue). – Jonesey95 (talk) 06:55, 13 January 2023 (UTC)

Template:League icon is a popular one I keep seeing (both just now and past few days). Looks like size (and px) only appears in the template once there at the bottom. Would this be a good one to trim? Zinnober9 (talk) 21:37, 15 January 2023 (UTC)

I thought that we had fixed all of the leagueicon instances, but a bunch more popped up today, so I have added a trim template to it. – Jonesey95 (talk) 01:24, 16 January 2023 (UTC)

Thank you for the info, glad to know that it was an intended change and just needs some cleanup. I was wasn't raising a pitchfork, just knew things were suddenly changing and I couldn't identify what happened and where the source was. I'd fixed a missing tag on a navbox template the other day that had 400+ pages crying, so had thought I'd found something similar here. Good to know that it'll take a while to all filter through. If you hadn't mentioned, I'm sure I'd be wondering after a few days why they were still coming in. I hope not to need to use string trim, but if I do, thank you for showing an example of how to use it. Zinnober9 (talk) 01:49, 13 January 2023 (UTC)

Unusual font attributes

There are two unusual attributes in font tags:

font colour: 1,324 pages
font family: 611+ pages (Maximum number of pages I can search. Actual count is higher, as the regex search can't get complete results)

Any replacements? Sheep (talk • he/him) 14:18, 16 January 2023 (UTC)

Using [^>]*? instead of .*? would be a more accurate search (colour at 335+, family at 576+). Using .*? causes some false positives (E.g. Talk:Control of cities during the Syrian civil war/Archive 65, where the font tag doesn't contain "colour" and it's actually picking up the word colour much further down). Aidan9382 _(talk) 14:35, 16 January 2023 (UTC)

The max I can find for font color is 355; results are undercounts as the regex searches can't get all results. Sheep (talk • he/him) 17:55, 16 January 2023 (UTC)

I am unable to find a definitive source stating that "colour" is invalid, but I am pretty sure that it has never worked, unless the MediaWiki software had some workaround to make it valid. When fixing Linter errors, I look at two things: (1) How the text displayed originally, before the rendering engine was changed (or will change, when all of the Linter-related workarounds are removed), and (2) The editor's original intent (i.e. they wanted the text to be brown). For signatures, I try to preserve #1 almost always, but sometimes I "fix" the syntax to match what appears to be the editor's original intent. In the case of "font colour" and "font family", it is pretty clear that the editor wanted the text to display in a certain color or font, so I would preserve the color and family markup and convert to span tags that actually work. – Jonesey95 (talk) 17:12, 17 January 2023 (UTC)

P.S. Don't worry about the search timing out. There are only six million obsolete tag errors, so once they are all fixed, we will know that there are no more "font colour" tags out there.

– Jonesey95 (talk) 17:14, 17 January 2023 (UTC)

Weight attribute in signature

What could be a replacement for [[User:wizzard2k|-wizzard2k]] ([[Special:Contributions/wizzard2k|C]]•[[User_talk:wizzard2k|T]]•[[User:wizzard2k/desk|D]])? Sheep (talk • he/him) 18:34, 20 January 2023 (UTC)

For the weight="bold" in the middle and end part?

I'd do [[User:wizzard2k|-wizzard2k]] ([[Special:Contributions/wizzard2k|C]]•[[User_talk:wizzard2k|T]]•[[User:wizzard2k/desk|D]])

since font-weight:bold; is already used by this user in the first part. If it's throwing an error I don't know of, then I'd consider removing the weights, and just bolding the text with ''' ''' or , but that would be a fallback plan. Zinnober9 (talk) 19:19, 20 January 2023 (UTC)

Difference between your replacement:

produces plain text.
produces bold text.

I don't believe weight is a valid attribute for font... Sheep (talk • he/him) 19:58, 20 January 2023 (UTC)

Oh... I see. Yeah,  doesn't work. It being a dot I didn't see that difference until I put them next to each other. Based on user intent, I'd still go ahead and change it to font-weight:bold; within span style since it reads as though the user intended it to be bold. I also see on their most "recent" comment on an article talk page, they were using bolded dashes - so that supports the user's intent of bold between the links. Zinnober9 (talk) 20:36, 20 January 2023 (UTC)

{{Infobox settlement}} generating false positives?

A few days ago, over 1,000 articles calling {{Infobox settlement}} were added to Missing end tags here (you may have to page back or forward to see them). LintHint reports a div missing end tag for each article, but only in display mode, not in edit mode. The template reports no errors. I've tried a null-edit on some of the articles, and even an actual edit, for example to Dipaculao here, but they won't drop off the list. I was hoping that by now they would have cleared, but no such luck. Are these real errors, or false positives? —Bruce1ee ^talk 09:57, 16 January 2023 (UTC)

Fixed. -- WOSlinker (talk) 10:26, 16 January 2023 (UTC)

Thanks for that. The problem was template calls within {{Infobox settlement}}. I was looking in the wrong place! —Bruce1ee ^talk 10:38, 16 January 2023 (UTC)

Just a heads-up, over 1,000 new missing end tags in articles using {{Infobox settlement}} popped up again earlier today. I saw that the fix WOSlinker did to {{PH composition bar}}, which solved the problem, and another fix by Jonesey95, were undone. I restored the fixes and the missing end tag problem has once again disappeared. I'm not sure why the fixes were undone. —Bruce1ee ^talk 12:09, 21 January 2023 (UTC)

LintHint box is in the wrong place in Vector 2022

Some new code was deployed today that (at least for me) puts the LintHint output in a box in the upper right corner of the screen. I added a note to T327715, a bug report about a similar problem with the translation tool. I have gone to Preferences -> Appearance and changed my skin back to Vector 2010 until this problem is fixed. I expect it will be fixed soon (i.e. in a few days). – Jonesey95 (talk) 22:03, 23 January 2023 (UTC)

Portal div?

A little div help? On Portal:Victoria the first <div style="... was missing a closing tag. I added a </div> where I thought it belonged, submitted my edit, but it still claims it's missing a div closer. There are four div openers and four closers on the page since my edit, so it's more of a stripped tag than a missing tag, but that doesn't help me figure out where it wants the tag to be placed. What am I not seeing that is preventing it from being lintfree?

I did a similar addition on Portal:Bavaria, but that page is clean since my edit. Zinnober9 (talk) 04:20, 25 January 2023 (UTC)

I recommend moving on to other, easier namespaces. I cleaned out Portal space as well as I could about a month ago, getting it down to about 25–30 total errors. Because they transclude random content, Portal pages come and go from the Linter error pages, so the only way to get it completely empty is to fix all of the other errors in pages that those Portal pages transclude. We are only 123,000 errors away from cleaning up article space completely (if temporarily). Can we make it happen, at least for a moment? – Jonesey95 (talk) 04:30, 25 January 2023 (UTC)

That said, I think I have fixed Portal:Victoria. It shows a green LintHint button at the moment (after saving), but I won't be surprised to see it pop back into the list at some point, even with no edits to the page. [edited to add: Never mind, it looks like you or someone else were/was persistent and fixed all of the current div errors! Nice. The missing end tags coming through Template:Flex columns are, I'm pretty sure, being pulled in from articles, hence my note above about article space.] – Jonesey95 (talk) 04:41, 25 January 2023 (UTC)

Thank you! And thank you for bringing portals down to nearly none! I've seen their small numbers fluctuate regularly, and I knew portal issues were mainly from transclusions, so I haven't bothered with portals much. Occasionally I look to see if there's any easy ones like an onpage missing tag, and these two issues looked like simple missing divs onpage, so I thought I'd give these two a try. So close...

Flex columns (often see in portals) send me running away screaming, so I don't plan on making a habit of touching portals.

I haven't been focused on mainspace much this week, so likely was someone else for those div errors. I've been mostly chewing Template Talk issues down for the last few weeks with an occasional mainspace error for a little break when I see there's new errors in a previously empty mainspace error type. I look forward to seeing mainspace cleared! Zinnober9 (talk) 06:57, 25 January 2023 (UTC)

For missing end tags for mainspace, that probably won't be cleared until about April 2025 at this rate. We're fixing these errors at a rate of about 150 per day, so that's an estimated 783 days until they are all gone. Sheep (talk • he/him) 18:55, 28 January 2023 (UTC)

New report listing pages with the most Linter errors

User:Galobot/report/Pages by Lint Errors is a new report that covers pages in all namespaces. Note that the Linter error system tracks a maximum of 21 errors of any single type, so pages on this list may have more total errors than are shown in the report.^[a] I have worked on a few pages on the list, and so far, I have noticed that many pages are on the list because of repeated errors in a single editor's signature. If you do a find-and-replace to fix that signature, it can bring the page's error count down significantly.

I have been focusing on fixing errors that are not obsolete font tag errors, leaving those to be fixed by the multiple bots that do a better job than me on those tedious replacements. – Jonesey95 (talk) 05:33, 12 February 2023 (UTC)

Notes

^ Example: currently, Wikipedia talk:WikiProject Professional wrestling/Archive 35 shows a count of 55 errors, but LintHint shows 855 errors in its list.

Firefly report

I was looking at the Firefly report and I noticed that some namespaces aren't there such as draft talk, category and its talk, file and its talk. Do those pages not have lint errors or are they just missing from the table? Gonnym (talk) 12:43, 14 February 2023 (UTC)

@Gonnym those namespaces don't have lint errors :) firefly ( t · c ) 12:57, 14 February 2023 (UTC)

Ah! That's good to know! Gonnym (talk) 12:58, 14 February 2023 (UTC)

Yes, those are empty. I personally cleaned out Category and Category Talk (less than 100 issues) and File and File Talk (around 700 pages total) last September since they were small (comparatively) error sections with generally simple and commonly repeating issues. Draft Talk tends not to create too many issues, and are usually cleared quickly, so they just don't tend to accumulate. Zinnober9 (talk) 21:27, 14 February 2023 (UTC)

Missing end tags in templates that I couldn't fix

I have stumbled across three articles where there are missing end tags in a template ({{LepIndex}}) that I couldn't fix.

Example: Somabrachys infuscata template code: {{LepIndex |id=75826 |name=Somabrachys infuscata'' with ''ragmata'' as junior subjective synonym |accessdate=May 14, 2018}} which when expanded without comments, returns <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles><cite id="{{{ref}}}" class="citation web cs1">Beccaloni, G.; Scoble, M.; Kitching, I.; Simonsen, T.; Robinson, G.; Pitkin, B.; Hine, A.; Lyal, C., eds. (2003). [https://www.nhm.ac.uk/our-science/data/lepindex/detail/?taxonno=75826 "''Somabrachys infuscata'' with ''ragmata'' as junior subjective synonym''"]. ''[[The Global Lepidoptera Names Index]]''. [[Natural History Museum, London|Natural History Museum]]. Retrieved May 14, 2018.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=The+Global+Lepidoptera+Names+Index&rft.atitle=Somabrachys+infuscata+with+ragmata+as+junior+subjective+synonym&rft.date=2003&rft_id=https%3A%2F%2Fwww.nhm.ac.uk%2Four-science%2Fdata%2Flepindex%2Fdetail%2F%3Ftaxonno%3D75826&rfr_id=info%3Asid%2Fen.wikipedia.org%3ASpecial%3AExpandTemplates" class="Z3988">.

Usually I would add italics at the end to fix the i missing end tag, but unfortunately it resulted in a b missing end tag instead. The result from {{LepIndex |id=75826 |name=Somabrachys infuscata'' with ''ragmata'' as junior subjective synonym'' |accessdate=May 14, 2018}} would instead be <templatestyles src="Module:Citation/CS1/styles.css"></templatestyles><cite id="{{{ref}}}" class="citation web cs1">Beccaloni, G.; Scoble, M.; Kitching, I.; Simonsen, T.; Robinson, G.; Pitkin, B.; Hine, A.; Lyal, C., eds. (2003). [https://www.nhm.ac.uk/our-science/data/lepindex/detail/?taxonno=75826 "''Somabrachys infuscata'' with ''ragmata'' as junior subjective synonym''''"]. ''[[The Global Lepidoptera Names Index]]''. [[Natural History Museum, London|Natural History Museum]]. Retrieved May 14, 2018.</cite><span title="ctx_ver=Z39.88-2004&rft_val_fmt=info%3Aofi%2Ffmt%3Akev%3Amtx%3Ajournal&rft.genre=unknown&rft.jtitle=The+Global+Lepidoptera+Names+Index&rft.atitle=Somabrachys+infuscata+with+ragmata+as+junior+subjective+synonym&rft.date=2003&rft_id=https%3A%2F%2Fwww.nhm.ac.uk%2Four-science%2Fdata%2Flepindex%2Fdetail%2F%3Ftaxonno%3D75826&rfr_id=info%3Asid%2Fen.wikipedia.org%3ASpecial%3AExpandTemplates" class="Z3988">.

So is there any way to fix these three missing end tags without changing the appearance of the articles? Sheep (talk • he/him) 20:53, 17 February 2023 (UTC)

Fixed with this hack. Usually a space before the terminal italics in the template works best, but if there is another character following, like a quotation mark or a full stop, a {{zwsp}} works in a pinch. – Jonesey95 (talk) 21:29, 17 February 2023 (UTC)

I see your hack and raise you a better one(?) which removes ambiguity and the need for a zws in the first place. Primefac (talk) 21:49, 17 February 2023 (UTC)

You should have folded. (Or, as I say when I am criticizing myself, "clever but not smart".) Now nearly all of the 1,900 transclusions that use |name= are showing without italics, like the one at Pine beauty#External links, or worse, like this one. – Jonesey95 (talk) 21:56, 17 February 2023 (UTC)

I'm on mobile right now, so apologies for the formatting. When I come across cases like this (there's an IMDB template that does something similar), I either make sure the quotes are balanced within the template and add a <nowiki />, or I use {{noitalic}}. --rchard2scout (talk) 22:21, 17 February 2023 (UTC)

Using <nowiki /> is functional, but there are various gnomes (our cousins) who will remove nowiki tags from article space, usually for good reason. I worry that they won't understand why it is there unless there is also a hidden comment. – Jonesey95 (talk) 00:12, 18 February 2023 (UTC)

Fair enough, but maybe people shouldn't code templates like this; this is just GIGO waiting to happen every third day. We should most definitely not be encouraging trailing '' in parameters to hack/fix the display of a template. I would argue that "the title isn't in italics" is an easy problem to fix on the article itself and I'm happy to undertake that if only to get rid of this bodge. Primefac (talk) 07:34, 18 February 2023 (UTC)

For this template, where 99% of the usages of name/pagename should be fully italicized, it might be better to have a |customname= (a bad parameter name, but you get the idea) parameter for titles with odd formatting. This sort of thing happens all over the place, though, where a template, typically an infobox, automatically italicizes a parameter. There are 1% or 2% of parameter values that are customized strangely. I don't know if that is worth a separate parameter every time. – Jonesey95 (talk) 11:46, 18 February 2023 (UTC)

Welcome message issue

I've noticed a welcome message at User talk:Epecho which has '''Welcome to Wikipedia''' instead of an actual header (and unrelated but also no sign date). Not sure how many pages have this issue. Gonnym (talk) 08:04, 21 February 2023 (UTC)

2901 with  and 2240 with . Primefac (talk) 08:58, 21 February 2023 (UTC)

But apparently only one of those non-header headings. – Jonesey95 (talk) 14:27, 21 February 2023 (UTC)

Why is LintHint only in Article namespace?

Sometimes I fix lint errors, and LintHint helps me be sure that there are no more lint errors on that page. However, for some reason it doesn't work on non-article pages. Why is this? 🐔 Chicdat ^{Bawk to me!} 11:35, 25 February 2023 (UTC)

Have a look at User:PerfektesChaos/js/lintHint#Configuration by JavaScript. Add the four lines of js code shown to your common.js (in that order), but set "myLintHints.rooms" to "*" (star) – that enables LintHint for all namespaces. —Bruce1ee ^talk 12:07, 25 February 2023 (UTC)

You can see an example at User:Jonesey95/vector.js, lines 61 through 69, beginning with "Live linting". – Jonesey95 (talk) 15:26, 25 February 2023 (UTC)

Thanks. 🐔 Chicdat ^{Bawk to me!} 11:23, 27 February 2023 (UTC)

Tab header error?

I noticed that Wikipedia:WikiProject Cats/Tab header is causing Lint errors (two missing end tags) on each page where it is transcluded. The fix applied by another editor, </div></div> at the bottom of each page, works on each of those pages, but I was wondering why the tab header was causing an error in the first place? SilverTiger12 (talk) 19:04, 28 February 2023 (UTC)

The lint appears to come from the template {{Start tab}} where there are two opening but no closing div tags. There is also an inverse template, {{End tab}}, where it's the opposite: two closing but no opening div tags. Therefore, the reason the page has lint is that there is no {{End tab}} template. So maybe you can substitute the two closing div tags with the template. Sheep (talk • he/him) 19:12, 28 February 2023 (UTC)

Huh, interesting. I don't think End Tab is necessary, but it's nice to know what the root issue is when I'm trying to fix a few lint errors here and there. SilverTiger12 (talk) 19:16, 28 February 2023 (UTC)

Regarding Wikipedia:WikiProject Cats/Tab header, the way to fix a page like that is to insert two closing div tags (or {End tab}) inside noinclude tags on the page itself, and then to do the same thing on each page that transcludes it, but without the noinclude tags. Note that if the header page is used on an active User talk page that might be modified with the addition of more sections, the formatting will probably break if you add closing div tags. I leave those pages alone, hoping that someday there might be a way to add a "footer" element at the bottom of a page that will stay below any new sections that are added. – Jonesey95 (talk) 19:35, 28 February 2023 (UTC)

I haven't tested, but maybe a template like this which wraps a full page, can be modified to have a |content= parameter then it will always work, regardless of any additional sections added. Gonnym (talk) 19:53, 28 February 2023 (UTC)

Any pipe (|) character on the page (i.e. inside |content=) will break that sort of template. – Jonesey95 (talk) 21:13, 28 February 2023 (UTC)

Bizarre error from transcluding sortable table

I was trying to fix the stripped tag lint errors in List of Pixar awards and nominations (feature films). It boils down to this minimal example. User:Anomalocaris/sandbox/Lint Test consists of just this:

{| class="wikitable sortable plainrowheaders" style="width: 10%;"
| {{sort|1|{{won}}}}
|}

The page is lint-free. However, when I transclude it here, there's a stripped . Behold! User:Anomalocaris/sandbox/Lint Test Perhaps the hive mind can help figure out how to fix this. —Anomalocaris (talk) 03:49, 1 March 2023 (UTC)

You can't do that. The output of {{Won}} is:

style="background: #9EFF9E; color: #000; vertical-align: middle; text-align: center; " class="yes table-yes2 notheme"|Won

Putting it inside of {{sort}} results in garbage code:

<span data-sort-value="1 !">style="background: #9EFF9E; color: #000; vertical-align: middle; text-align: center; " class="yes table-yes2 notheme"|Won</span>

It is a bit surprising that Linter does not detect an error in your sandbox page, but there are a variety of errors that Linter does not detect, like stripped /p tags, and font link errors when there are nested sup tags inside the font tags (see T294720), and tables that do not end (see T295197). This particular error may be a variety of T323869. But that's just how Linter is right now, and probably how it will stay unless something significant changes in the WMF development community. The WMF developers like to work on a project for a while, deploy it in beta, fix a few bugs, and then move on to the next thing. It's not just Linter; see also Visual Editor, Vector 2022, many other past projects, and now Discussion Tools. – Jonesey95 (talk) 05:53, 1 March 2023 (UTC)

Jonesey95: I agree, it is a variety of T323869. The markup there doesn't officially generate a lint error on its own, but it does when expanded in ExpandTemplates, which is the same behavior as the markup I noted above. I removed the sort templates in List of accolades received by Toy Story 3 and List of accolades received by Inside Out, and that fixed the lint error in List of Pixar awards and nominations (feature films). The downside is that the two articles I edited don't sort well on the RESULT column, but as Walter Cronkite used to say, "That's the way it is." —Anomalocaris (talk) 08:28, 1 March 2023 (UTC)

Platform (European politics) and Template:Db

Can someone check Platform (European politics) and Template:Db? I can't figure out where the issue is with the errors. Gonnym (talk) 12:50, 1 March 2023 (UTC)

Apparently it's coming from the "please consider placing the template" thing on the template. Since the template was removed, looks like the errors are removed :) Sheep (talk • he/him) 12:58, 1 March 2023 (UTC)

Having a quick look, it seems the italics in the provided rationale break it. The expanded problematic line goes as follows:

:''<small><code><nowiki>{{subst:</nowiki>[[Template:db-reason-notice|db-reason-notice]]<nowiki>|</nowiki>Platform (European politics)<nowiki>|header=1</nowiki>|no references are given; the content is covered in the ''[[political faction]]'' article.<nowiki>}} </nowiki><nowiki>~~~~</nowiki></code></small>''

(from Template:Db-meta line 47) Aidan9382 _(talk) 12:58, 1 March 2023 (UTC)

The italics may need to be placed inside the <code>...</code> tags. I don't have time to look at it right now. – Jonesey95 (talk) 14:54, 1 March 2023 (UTC)

I moved the italics inside the <code>...</code> tags. That appears to work in the old version of that article with the speedy deletion template on it. – Jonesey95 (talk) 15:53, 1 March 2023 (UTC)

del and ins tag errors

At Wikipedia talk:No legal threats#Clarify this is a no-drama clause there are a few issues (Misnested tag with different rendering in HTML5 and HTML4, Stripped tags, Missing end tag) with the <del>...</del> and <ins>...</ins> tags which are created by {{TextDiff}} via Module:Diff. Not sure how to fix this. Gonnym (talk) 17:11, 1 March 2023 (UTC)

You'll notice that the entire Project Talk space is cleared out except for that one page. It was the only one I couldn't figure out. I left it as a nasty problem for the future; there are plenty of fish in the sea. – Jonesey95 (talk) 18:07, 1 March 2023 (UTC)

The module seems to be trying to suggest that one of the newlines is part of the difference between the 2 texts. When it attempts to format this in the html, it writes the following (extremely simplified excerpt but you get the idea):

<div>same words
with newline<ins>new words
with newline</ins>same words or end of text, no newline</div>

This is what's triggering the html4/5 rendering difference error. I'm not confident with screwing with html code like how it is here, so I've got no solution ideas myself. If you need a simple testcase, use the following (see source):

{{TextDiff|A

B

C|A

C


B}}

Aidan9382 _(talk) 19:16, 1 March 2023 (UTC)

I have reformatted it using separate {{TextDiff}} for each paragraph, which has fixed the errors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:59, 2 March 2023 (UTC)

Milestone!

Obsolete tags are now under 6 million! Zinnober9 (talk) 21:31, 15 January 2023 (UTC)

Decreased to under 5 million yesterday. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:33, 7 February 2023 (UTC)

Wooo!! Under 4 million obsoletes as of today! Zinnober9 (talk) 07:16, 16 February 2023 (UTC)

Under 3 million obsoletes as of yesterday! Already down to 2.94 million, so might be another 10 day blitz at this rate. Zinnober9 (talk) 17:53, 25 February 2023 (UTC)

Under 2 million as of this timestamp. We now have more missing end tags than obsolete tags. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:31, 8 March 2023 (UTC)

Bots to fix Lint erorrs

Legobot 41 and SheepLinterBot are currently at bot trial and awaiting approval for Lint fixing tasks. Following 6 months of hiatus while it was busy with Task 13, I have put MalnadachBot back to fixing Lint errors with a substantially improved code. You can expect to see large drops in error count in the coming days, more so after the other 2 bots are approved. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:14, 28 January 2023 (UTC)

Thank you! Have you ensured that the bot will skip pages when it is unable to fix all of the Linter errors? My recollection is that multiple visits to a page was the primary objection to MalnadachBot's edits. – Jonesey95 (talk) 14:38, 28 January 2023 (UTC)

Yes, it skips pages if it can't replace all font tags now. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:05, 28 January 2023 (UTC)

Good to see MalnadachBot is back fixing lint errors again. Is there still a moratorium on submitting obsolete font tag patterns to User:MalnadachBot/Signature submissions? —Bruce1ee ^talk 17:39, 28 January 2023 (UTC)

That was of more of a self imposed moratorium to placate complainers and focus on more important fixes before. I believe its not really necessary to submit individual font signatures now. Mine and SheepLinterBot can now handle most common font replacements, with others handled by Legobot. I might have to manually run it for some of the more complex ones that Legobot could not fix, but that will be a few months later. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:05, 28 January 2023 (UTC)

It is so nice to have the bot back. The error count is going down by about 10,000 errors per hour! – Jonesey95 (talk) 16:12, 29 January 2023 (UTC)

That is about two days until we reach 8 mill errors (we are at 8.51m right now). Sheep (talk • he/him) 16:21, 29 January 2023 (UTC)

I'm running it on pages with most font tags. The more the number of font tags, the more is the probability that it can't replace everything and skips the pages. Even with that, the count is dropping in a pace not seen before. It will slowdown in a couple of days after this initial large drop. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:00, 29 January 2023 (UTC)

FYI – my bot task is now approved. To get this bot to run, you can submit any signature with font tags to this page. Then they will be processed and the bot can run with these signatures. The sample will be worked on after the bot gets moved to the enabledbots section of the AWB check page. Sheep (talk • he/him) 12:42, 31 January 2023 (UTC)

I'm pretty sure it will work as long as the bot is on that page. Primefac (talk) 12:48, 31 January 2023 (UTC)

Inquiry: since the bots seem to be doing find-and-replace patterns, as patterns of errors are added for them to fix (new signatures, etc), will they go back over pages they already checked but skipped? SilverTiger12 (talk) 16:35, 2 March 2023 (UTC)

Yes. That is already happening. Ideally, new signatures will not contain Linter errors, except for obsolete tags. Editors with obsolete tags in their signatures are being contacted by human editors to recommend updates. – Jonesey95 (talk) 19:10, 2 March 2023 (UTC)

After 960k edits clearing ~3.9 million errors, MalnadachBot has reached the end of its huge font tag replacement run. There are still at least 1 million font tags that I can have it replace in a slower pace in smaller batches. On another note Wikipedia:Bots/Requests for approval/Legobot 41 was just approved. This bot is technically stronger than all others that have worked on Lint errors, so we may still see large drops in error count. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:39, 8 March 2023 (UTC)

At some point, especially the weekends, I will use my regexes to try to get rid of all the remaining font tags in some pages whenever possible. I am quite busy in my IRL stuff so I will have less time to run my bot. Sheep (talk • he/him) 14:12, 8 March 2023 (UTC)

Username breaking templates

Tracked in Phabricator
Task T14974

Is there a way to "turn off" the bulleting of a username that begins with * and still have the username linking work? Or does a template need to be updated to accommodate such? (If such is even possible that is) There is a user that I'll call *username whose name is causing a misnested lint error whenever they were the last to edit a page and the bulleting is causing the user name to appear within the template as such:

Last edited by [[User:

username
username]] 3 seconds ago.

If there isn't such a way, is there any precedent for asking them to adjust their username? or is this just an unfortunate minor thing that is just going to happen and I should ignore it?

Zinnober9 (talk) 02:35, 7 March 2023 (UTC)

Yes, this a longtime bug tracked at phab:T14974. It used to cause Lint errors with User:*Treker. They were kind enough to get renamed to User:StarTrekker, so perhaps others might agree to be renamed if asked. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 03:57, 7 March 2023 (UTC)

This can be solved by adding {{Encodefirst}} to REVISIONUSER of AFC submission templates as in Template:AfC submission/declined/sandbox. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:40, 7 March 2023 (UTC)

Jonesey95 or Primefac, can you implement the above change to Template:AfC submission/rejected and Template:AfC submission/declined? This solves recurring errors with these templates, a current example is in Draft:Enrique Acosta (actor). A working example of this bug with encoded REVISIONUSER can be seen at Special:PermanentLink/1143565761. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 15:04, 8 March 2023 (UTC)

Sure. Primefac (talk) 15:14, 8 March 2023 (UTC)

Thank you both! Draft:Enrique Acosta (actor) was indeed the case I was seeing it at. Zinnober9 (talk) 22:32, 8 March 2023 (UTC)

Discussion at Wikipedia:Village pump (policy) § RFC: Clarifications to WP:COSMETICBOT for fixing deprecated HTML tags

You are invited to join the discussion at Wikipedia:Village pump (policy) § RFC: Clarifications to WP:COSMETICBOT for fixing deprecated HTML tags. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:36, 7 February 2023 (UTC)

RFC closed in support of MalnadachBot (and by extension other bots) continuing to fix all types of Lint errors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 04:57, 11 March 2023 (UTC)

Watchlist noise of lint fixes

It’s really annoying all the “fixed lint errors” that are continually polluting my watchlist. It’s always new lint fixers, violating WP:BOTLIKE policy, on ancient pages.

Whatever the fix you think is needed, if you are competent to do it relaibly repeatedly and without needing to be watched, get a bot with a bot flag to do it.

If you want to say “a bot can’t do this”, then I don’t believe you are qualified to do these fixes.

A question on a different level: Why can’t current browsers be asked to be backwards compatible? This lint fixes you are doing, they don’t fix revisions in the history. I now many pages have broken-looking old revisions. For the wikiarcheologist, old page revisions are more likely to be reviewed than current versions of old archives. Especially if there is a string of so-called gnoming edits in recent times to these pages.

- SmokeyJoe (talk) 11:19, 9 March 2023 (UTC)

How does that violate WP:BOTLIKE?

"However, merely editing quickly, particularly for a short time, is not by itself disruptive." LicenceToCrenellate (talk) 13:56, 9 March 2023 (UTC)

SmokeyJoe, your primary question has already been answered. In that discussion, I said If you have some foolproof code that would be able to determine how to fix misnested tags without false positives, please post a note about it at Wikipedia talk:Linter. If the code is viable, someone will probably be able to use it to deploy a bot, saving me and other human editors a lot of trouble. You are still welcome to do so here. You can also see a partial list of human-submitted suggestions for one of the Linter bots at User:MalnadachBot/Signature submissions. If you can find other text patterns that can reliably be fixed by a bot without false positives, that is a good place to submit them. MalnadachBot has performed about one million edits in the last month and stands ready to do more.

With respect to your second question, it is not usually the browsers that are causing old revisions to look broken. It is changes to the MediaWiki software. You would have to address your questions to the MediaWiki developers, who continue to modernize and update the parser that renders pages on MediaWiki sites. – Jonesey95 (talk) 17:34, 9 March 2023 (UTC)

There’s been a series of editors doing manual linter fixes, for a few years I guess. They are most certainly BOTLIKE edits. They are all the same edits, without speaking to background issues of not doing false positives. Having established that the fix is right to do, the edit is BOTLIKE. The editor seems to think that they evade BOTLIKE by doing it slowly, but they are still polluting watchlists and recentchanges with BOTLIKE edits, by editors I don’t know, that need reviewing. On mentioning this to the editor, they stop it, but later, some other editor restarts. Never has it been a bot editor that I know. You, Jonesey95, are unusual in being an old account, more typically they are recent years new accounts.

If you know the edit is right to do, you could put it on a list, for a bot to do. There is no rush. These are pages with negligible pageviews. What pageviews there are are probably searches for these errors.

So, it is MediaWiki that is making old pages “broken”, not modern browser standards? Well, that makes this worse. If you care about linter errors, you should tell these mysterious MediaWiki developers. In the meantime, I suggest more consideration of NOT fixing things that reveal MediaWiki errors on old never-viewed pages. Archives and old project pages are import for their records, and having them fiddled unnecessarily by people who don’t respect BOT policy is not good. SmokeyJoe (talk) 21:18, 9 March 2023 (UTC)

In the previous discussion (linked above), I provided at least one link to a diff of a manual edit (made by me) that a bot would have been unable to perform. In this discussion, I provided a link to edits that we have placed on a list, for a bot to do, and then SmokeyJoe subsequently suggested that editors use such a list. If there is a problem with a specific editor making a large-scale series of identical, specific edits that could have been performed by a bot without false positives, please link to those edits. – Jonesey95 (talk) 21:50, 9 March 2023 (UTC)

A manual fix that “a bit would have been unable to perform” tells me that you are the wrong person to be talking to about bots. I complained to you about your BOTLIKE violations polluting my watchlist, and you stopped, thank you.

The currently author of watchlist pollution is Zinnober9 (talk · contribs). After posting here, he performed this edit to my talk page that feels very much like a poke in the eye. That edit is completely unwanted. I’m guessing that linter errors are attracting newbie gnomes, and I think they should be discouraged.

- SmokeyJoe (talk) 09:34, 11 March 2023 (UTC)

I addressed all the lint errors on your talk pages in a minimal, one and done manner so that you and your pages would be no longer be bothered. I did each archive page (pages 2-6) in one edit each, with minimal interruption and per the rules stated here at WP:Lint. Your pages are completely clean, display identically as they had, and won't need any further forseeable adjustments, bot or gnomewise. I've been Gnoming for multiple years in various ways; I'm not new at this. I'm sorry that my well-meaning actions bothered you, I will not bother your pages further and I wish you the very best. Zinnober9 (talk) 01:34, 12 March 2023 (UTC)

This page history is an example of where you both have done more harm than good. Archives are meant to be stable, not edited and this fiddling, attempted bandaid fixes of MediaWiki underlying problems, are not real fixes and are damaging to the integrity of old pages. SmokeyJoe (talk) 09:52, 11 March 2023 (UTC)

This thread is pointless. Please feel free to start yet another RfC on the topic. Gonnym (talk) 09:57, 11 March 2023 (UTC)

Prior to my final edit on Template talk:Infobox officeholder/Archive 6, the infobox was a code mess. The infobox code was tested in multiple user's sandboxes only to find it had no errors in userspace, and the errors only appeared in Template space and main space, which made addressing and clearing the issue much harder. Some calculated adjustments were tried, only to find they were unsuccessful in clearing the issue, so were self reverted. In keeping with the rules stated here on WP:Lint, specifically with the rules Try to preserve the appearance and It is OK to change the appearance in some cases if it preserves the original intent, I decided it was simpler to just rewrite that portion of the infobox to a more commonly used, userfriendly way that displays the content in a near identical way than it was to further troubleshoot the complicated if statement code that was stumping the best of us. I posted here Dec 22nd (conversation now archived, but viewable in archive 3 here) about the issue, and suggested the idea of rewriting it in a different way I knew to be lint-free, and posted the proposed code I intended to swap it to. The notice was up for two weeks with no objections, so I followed through with the proposed change. There have been no other objections since the change, and the page has not needed any further edits.

Most importantly there was no damage to the integrity of the content displaying on Template talk:Infobox officeholder/Archive 6 with my rewrite. It displays near identicaly before and after, has clean code that is strong and error free. My rewrite follows all rules (to the best of my knowledge) listed here and I stand by my edits on that page and elsewhere.

If you wish to discuss your issues with MediaWiki's problems and their support plans with the eventual drop of outdated, obsolete code, you need to discuss your issues with them, NOT us. I don't believe can help you further other than to say we followed the permitted lint clearing actions stated at WP:Lint and that follow the rules of the site. These delinting actions have been repeatedly permitted through multiple discussions, and have most recently been discussed at RFC_Clarifications_to_WP:COSMETICBOT that closed earlier this week. Best wishes, Zinnober9 (talk) 01:34, 12 March 2023 (UTC)

Links in links false positive?

lintHint reports one links in links error in several cricket club articles, for example Hong Kong Cricket Club. Yet in edit mode lintHint reports no errors. Is this a false positive? I don't know if the placing of {{Infobox mapframe}} within the "source" parameter in {{Infobox cricket ground}} has anything to do with this, but it doesn't look right. —Bruce1ee ^talk 15:51, 17 March 2023 (UTC)

Good troubleshooting. The |source= parameter was being misused and was generating this weird error. I added a |map= parameter to the template and fixed about 16 articles that were affected. There may be more. – Jonesey95 (talk) 16:27, 17 March 2023 (UTC)

Thanks for that. I also counted 16 articles. —Bruce1ee ^talk 17:07, 17 March 2023 (UTC)

Links in links embedded in {efn} not being reported

Linter is not reporting links in links errors if they are embedded in the {{efn}} footnote template. For example

Article text.{{efn|Footnote text.<ref>[https://example.com Footnote source with [[internal link]] in it.]</ref>}}

It's probably because linter isn't expanding the efn template. If I copy the above example into Special:ExpandTemplates, lintHint does find the links in links error. Does this happen with all templates? —Bruce1ee ^talk 09:42, 27 March 2023 (UTC)

I have created T333162. – Jonesey95 (talk) 13:30, 27 March 2023 (UTC)

Thanks for that. Does this happen with all templates? It happens with {{tq}}:

{{tq|Quote [https://example.com text with [[internal link]] in it]}}

—Bruce1ee ^talk 13:50, 27 March 2023 (UTC)

This version of my sandbox contains the tq code above, and it shows a link-in-link error on the rendered page. LintHint does not work in Preview for some errors within {{tq}}, for some reason. – Jonesey95 (talk) 15:01, 27 March 2023 (UTC)

You're right, the saved sandbox version reports an error, but finds no error (with my example) in preview. I had only checked it in preview. So perhaps this problem only happens with {{efn}}. —Bruce1ee ^talk 15:12, 27 March 2023 (UTC)

False Fostered content

Wikipedia talk:WikiProject Olympics/Archive 20 is listed as having a Fostered content lint error, and the error is also listed on the page information page, but lintHint doesn't see the error in the editor or in ExpandTemplates. The error is also not there when the entire page is copied into my sandbox. The error does not go away with a null edit, or an edit changing a double blank to a single blank. —Anomalocaris (talk) 01:47, 28 March 2023 (UTC)

This looks like the same cause as the previous time this came up. It looks to me like the templatestyles in {{JudoNOC}} and other templates used in one of the tables are causing Fostered content errors. Take a look at the previous section somewhere on this talk page or its archives to find out what we did with it. – Jonesey95 (talk) 02:14, 28 March 2023 (UTC)

Jonesey95: The discussion you remembered is at Wikipedia talk:Linter/Archive 3#Non-Replicatable, and I participated in that discussion. In that discussion, the decision was to remove a lint error on a talk page by using {{Infobox officeholder}} in a more standard way, preserving the talk page appearance. Wikipedia talk:WikiProject Olympics/Archive 20 includes markup

{{JudoNOC|nation=AUT|year=2024|accessdate=6 January 2023|timestamp=20230105153648|archivedate=5 January 2023|M81=Q|W48=Q|W70=Q}}

, and you seem to be suggesting that this line is triggering the fostered content lint error. I copied this line into ExpandTemplates, and it was interesting that with a context title of Water, the code expands to 1665 bytes, but with a context title of Wikipedia talk:WikiProject Olympics/Archive 20, the code expands to 1710 bytes. I am willing to believe that this is the markup that brings in the lint error, but I don't know how to replace it with other markup that displays the same and doesn't have the lint error. —Anomalocaris (talk) 05:58, 29 March 2023 (UTC)

I've fixed it with the following 3 edits which move the template style within a table cell. -- WOSlinker (talk) 07:55, 29 March 2023 (UTC)

WOSlinker: Thank you for fixing this! —Anomalocaris (talk) 19:26, 29 March 2023 (UTC)

"Template talk:WikiProject" tables

Resolved

Anyone know what is up with the slow increase of Template talk:WikiProject XXXX pages since yesterday claiming there's the trio of a Table tag to be deleted, Missing end tag, and a stripped tag error? The full contents of most of these pages' contents are essentially {{WikiProject XXXX|class=template}}. Specifically confusing is Template talk:WikiProject Dance/class with only {{WikiProject Dance}} as the entire page's contents. I suspect a page connecting these various templates was changed, and I haven't found the connection. Zinnober9 (talk) 22:12, 29 March 2023 (UTC)

Ah... perhaps Template:WikiProjectBannerMeta has been changed? I know there's been some changes to WikiProject banners as they move to project-independent class assessment. SilverTiger12 (talk) 23:20, 29 March 2023 (UTC)

On those pages, you can see that the output has unfinished links and other bad output, so there is no point in trying to fix Linter errors on the pages themselves. I posted at Template talk:WikiProject banner shell. There are some clever coders over there who should be able to fix the problem. – Jonesey95 (talk) 02:13, 30 March 2023 (UTC)

This problem appears to have been resolved. – Jonesey95 (talk) 12:20, 30 March 2023 (UTC)

Some Firefly tools counts are stuck

Firefly: For at least several hours if not much longer, the Firefly Tools lint errors by namespace has been stuck at 1 for Misnested tags and missing end tag in Draft space, even though both of these are empty. —Anomalocaris (talk) 03:47, 10 April 2023 (UTC)

The missing end tag in draft space has been there for about a week. I noticed the Misnested tag entered stuck ghostdom Saturday. I'm not seeing other namespaces getting stuck, since the sections I've been chewing this week on are going down. Zinnober9 (talk) 04:08, 10 April 2023 (UTC)

@Anomalocaris + Zinnober9 - it seems that this is related to toolforge DB replica replication delay. Sometimes things take a little while to come over to the replicas, and unfortunately there's nothing that the Firefly tools setup can do about that. If you run the relevant queries on toolforge (e.g.

select count(*) from linter inner join page on page.page_id=linter.linter_page where linter_cat=8 and page.page_namespace=119;

) you'll get a result showing one error remaining. firefly ( t · c ) 12:33, 10 April 2023 (UTC)

Intentional lint (bot question)

How do we flag intentional lint errors/lint sections for bots to ignore? and I assume we should revert the bot when the bot "corrects" the lint in these instances?

Specifically I'm talking about this and this which MalnadachBot corrected today. Jonesey95 and I had made source comments explaining for humans not to fix on each page. Each were obsolete tags and were the focus of discussion. I'm sure adding {{nobots}} to these pages would be drastic overkill for this minor issue, but is there something that can be sectionally placed around the linty section (think like how collapse top/bottom works)?
Pinging relevant users: @ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: @Jonesey95: Zinnober9 (talk) 18:47, 3 April 2023 (UTC)

Probably best to use nowiki around obsolete example code and not actually use obsolete tags. Gonnym (talk) 18:50, 3 April 2023 (UTC)

Better to wrap them in nowiki or syntaxhighlight tags. If someone really wants to see visually, they can temporarily put it in a sandbox. I see no use in rendering them live and clutter Lint error lists indefinitely. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 19:27, 3 April 2023 (UTC)

Sounds fine to me, I'll proceed with that on these two pages and add a source note referencing this conversation. Zinnober9 (talk) 00:35, 7 April 2023 (UTC)

@MalnadachBot, ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, Jonesey95, and Zinnober9: Whoa! Over the years I've marked numerous talk page lint errors not to fix, or just not fixed them, because the someone's saying, in effect, why does this markup cause this strange result? We really don't want to fix those. Also, lint fixing should usually preserve appearance, and if someone made a talk page comment with <tt>...</tt>, we should replace it with {{mono|1=...}}, not <code>...</code>, because we shouldn't change the appearance unnecessarily. —Anomalocaris (talk) 03:41, 10 April 2023 (UTC)}}

That's why I've only done this on these two pages so far, and haven't rendered other known intentionals inert with explanation, since I know there isn't a uniform view at the moment on to keep/to render "inert" with explanation for "intentional" errors at the moment. The bot forced the issue on these two pages. I have no objection to a change in action for these, so long as there is a census reached before any undos/changes are made. Zinnober9 (talk) 22:19, 10 April 2023 (UTC)

TFD notices causing Linter errors

Just an FYI: In case you haven't stumbled across this quirk, sometimes TFD notices cause Linter errors, such as the ones at User talk:Athaenara/Archive 9. TFDs are typically closed after seven calendar days, so the easiest thing to do, if the templates are not causing formatting problems, is to leave the pages alone and wait for the TFD to be closed. If the template is causing formatting problems, it can be set to not appear in transclusions; the trade-off for doing this is that notification of interested editors may be diminished. – Jonesey95 (talk) 16:31, 11 April 2023 (UTC)

An update: 14 million errors, and still headed down

(This is a continuation of the earlier thread, in a new thread so we don't necessarily keep the old discussion alive)

Last september, we were at 21 million errors. Just over two weeks ago, we got below 15 million. And now, we're below 14 million linter errors! Hurray! Comparing Firefly's table from 1 March and from today, and doing some quick maths, we can see that about 75% of fixed errors were fixed in the User talk namespace, 15% in Project, and almost 6% in Talk. Breaking the difference down by lint error instead of by namespace, about 90% were Obsolete HTML, almost 7% were Missing end tag, and almost 2% were Misnested tags. I'm going to assume that most of this is the work of MalnadachBot, so huge thanks to User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ! Also huge thanks of course to everyone else who's been fixing these errors! --rchard2scout (talk) 10:19, 23 March 2022 (UTC)

To add, there are 300k in mainspace, down by 28k in 15 days. This is largely due to the recent efforts by gnomes to replace center tags. I have been pushing MalnadachBot hard, a million errors in 15 days is as much as it can fix. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:00, 23 March 2022 (UTC)

A Rogues' gallery of errors fixed by MalnadachBot can be seen here. 350 so far in task 12. There are 1,500 more from the earlier task 2 which dealt with high priority errors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:13, 23 March 2022 (UTC)

The bot got us under 13 million errors sometime in the last 12 hours. Keep going, bots and gnomes! – Jonesey95 (talk) 15:40, 18 April 2022 (UTC)

So the bot fixes ~44k+ lint errors on Task 12 and we're at 12.28m lint errors, meaning at this rate we would have

~7 days until we reach 12m errors (that would be on May 14),

~29 days until we reach 11m errors (that would be on June 5), and

~52 days until we reach 10m errors (that would be on June 28).

If we can fix more errors, hopefully we can reach the next million earlier. Sheep (talk) 12:35, 7 May 2022 (UTC)

The rate of errors fixed by the bot varies depending on the patterns as can be seen in the table in User:MalnadachBot/Task 12. Generally as the total number of errors decreases, the time taken to reach the next million increases, assuming I'm devoting the same amount of time. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:29, 7 May 2022 (UTC)

We are just under 12 million as of this time stamp. – Jonesey95 (talk) 02:46, 18 May 2022 (UTC)

It took a while, since the MalnadachBot font removals have been stopped for now, but we reached 11 million errors today. We are down to 45,000 total high-priority errors, and under 175,000 errors in article space. – Jonesey95 (talk) 23:47, 17 July 2022 (UTC)

It's probably because the bot is replacing old IP talk pages with {{Blanked IP talk}} so it's probably why it got us down to <11m errors, since some of the affected talk pages have Linter errors. Sheep (talk) 14:31, 19 July 2022 (UTC)

As of September 3, we are just under 9 million errors on the firefly report. We have 40,500 high-priority errors. We have 172,000 errors in article space, which is a 50% decrease since March 2022 but not much change since mid-July. – Jonesey95 (talk) 22:54, 3 September 2022 (UTC)

And as of the most recent refresh of Firefly (within moments of this comment's timestamp), we are under 8 million!!!

We have roughly 37,700 high priority issues remaining. We also have 122,000 issues in article space (95.6% of which are missing end tags and 4.4% are wikilinks in external links). Here's to another million down, and may the upcoming under 7 million celebration quickly approach us! Zinnober9 (talk) 04:17, 4 February 2023 (UTC)

Also a note that my BRFA for font tags is approved. Submit whatever signature to this page and the bot will fix them. This was originally planned to take over MalnadachBot for font tags. Anyone is welcome to do so. Sheep (talk • he/him) 12:06, 4 February 2023 (UTC)

We are at the seven million mark since 2023-02-13 19:46:36. That count is going down much faster now due to Linter bots. Sheep (talk • he/him) 21:25, 13 February 2023 (UTC)

Also, 100,000+ errors a day is impressive. 1 mill errors in 9 1/2 days. The fastest rate is about 240,000/day. Sheep (talk • he/him) 21:27, 13 February 2023 (UTC)

6 million as of 14:46:22, 23 February 2023. Sheep (talk • he/him) 15:11, 23 February 2023 (UTC)

Just under 5 million as of today. SilverTiger12 (talk) 17:26, 5 March 2023 (UTC)

Under 4 million as of probably a few days ago. SilverTiger12 (talk) 17:48, 11 April 2023 (UTC)

Was on 26 March 2023 Zinnober9 (talk) 17:55, 11 April 2023 (UTC)

[1] Example: currently, Wikipedia talk:WikiProject Professional wrestling/Archive 35 shows a count of 55 errors, but LintHint shows 855 errors in its list.

[a]