Wikipedia talk:Linter/Archive 2

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

Wikitext linting database updates temporarily disabled

See https://phabricator.wikimedia.org/T240057 for more details. — Preceding unsigned comment added by SSastry (WMF) (talk • contribs) 23:54, 6 December 2019 (UTC)

@SSastry (WMF): Someone made it a security task. --Izno (talk) 00:55, 7 December 2019 (UTC)

Fixed. SSastry (WMF) (talk) 13:12, 7 December 2019 (UTC)

Looks like linting database updates are enabled again. —Anomalocaris (talk) 08:45, 12 December 2019 (UTC)

No, not yet. But, it will very likely be enabled tomorrow. SSastry (WMF) (talk) 09:16, 12 December 2019 (UTC)

I edited Draft:Kwesi Wilson and a bunch of lint errors updated away. But then I edited Draft:EIP (law firm) and Draft:KK Crvena zvezda in EuroLeague and the lint errors didn't update away. —Anomalocaris (talk) 09:20, 12 December 2019 (UTC)

A related issue, related at least minimally because until the linting database updates are re-enabled, lint errors aren't updating:

I have long noticed that, if I edit an article that formerly transcluded lint errors, but the transcluded lint errors were fixed, after a null edit and weeks of waiting, the lint errors often don't get erased from Page information, but a trivial edit that adjusts white space results in erasing the lint errors from Page information within seconds. Isn't a null edit supposed to trigger an immediate entry of the article into the queue of articles to be scanned for lint errors, just like a non-null edit? —Anomalocaris (talk) 23:28, 10 December 2019 (UTC)

We didn't know this till now, but I bet null edits don't show up in Parsoid's parse queue (likely a performance optimization higher up in the software stack to avoid useless parse requests to Parsoid). I don't have an immediate solution for that problem now, but perhaps worth a Phab task to see how null edits are handled and what else it should enable (like in this case). SSastry (WMF) (talk) 07:20, 11 December 2019 (UTC)

Error message: "error -- Error: Unsupported Media Type" with LintHint on all pages

I am getting "error -- Error: Unsupported Media Type" on all pages in "view" mode, for a couple of weeks now. Normally, it loads a list of errors.

It is working fine in Preview mode, although at about the same time, the down arrow that jumps to the error and highlights the erroneous block of text started highlighting text below the actual error.

Is anyone else experiencing these two errors with LintHint? – Jonesey95 (talk) 22:42, 31 December 2019 (UTC)

@PerfektesChaos: --Izno (talk) 22:15, 1 January 2020 (UTC)

HNY.

The first issue is a temporary decoupling from Wiki server due to overload problems. Should be resolved within January.
I have observed the second issue already.
- Beginning with December 2019 the parsing software has been changed from Parsoid/JS to Parsoid/PHP.
- I guess that computation of target coordinates is less exact now.
- That might be reviewed, but since the parsing software is not ultimately ready I do not take any action here. Might be influenced by browser issues as well.
- Does the same behaviour occur if you follow regular links from special page? Then the positions are miscalculated with new parsing software.

Please direct issues regarding LintHint towards LintHint global feedback page, de:BD:PerfektesChaos/js/lintHint.

There you might have found the answer on the first point already.

Greetings --PerfektesChaos (talk) 11:40, 2 January 2020 (UTC)

Re following the links from the Special Linter pages, I tried a few "edit" links, and they highlighted the correct locations. I don't know if it works for every article. – Jonesey95 (talk) 16:03, 2 January 2020 (UTC)

For me, sometimes the linter page edit links don't highlight anything at all. When they do highlight, they highlight the exact location of the lint error. However, lintHint highlighting is often below the actual error, and it tends to get farther away the deeper you get into an article. There is a discussion of this topic at de:BD:PerfektesChaos/js/lintHint#Pointers are pointing to the wrong place. —Anomalocaris (talk) 21:32, 3 January 2020 (UTC)

I think the incorrect location for highlighting the error is a Parsoid bug. Can you point me to a page on which this happens? That will help us investigate this. SSastry (WMF) (talk) 04:56, 4 January 2020 (UTC)

Here's one that shows the problem for me: go to Georgian scripts. Click the yellow LintHint box. When the error list appears, scroll to the last "missing end tag" error and click the down arrow. When I do it, "n equal number " is highlighted instead of "''labial sign", which is approximately 2,745 characters before the highlighted section. – Jonesey95 (talk) 05:09, 4 January 2020 (UTC)

So, first of all, when I loaded LintHint and clicked on it, I got the "Error: Unsupported Media Type" error. That error comes from these lines which indicates that LintHint is probably passing an incorrect Content-Type or is not sending in a content-type. For the missing case, we could probably default to application/json but that will take a few days since we need to discuss what is a reasonable default. But, User:PerfektesChaos, maybe you can look at your script and see if you are passing this header correctly. Parsoid/PHP might be behaving stricter compared to Parsoid/JS here. SSastry (WMF) (talk) 06:32, 4 January 2020 (UTC)

As for the second problem (incorrect highlights), I think I know what the issue could be. Parsoid/PHP computes offsets in terms of bytes whereas Parsoid/JS computes offsets in terms of characters. While storing lints in the database, we convert the offsets from bytes to characters. But, when tools requests these offsets via the linter API (like LintHint does), we have probably forgotten to add the offset conversion. This affects any page that has non-ASCII characters (which is probably most pages). Anyway, we'll fix that and deploy a fix this week. SSastry (WMF) (talk) 06:32, 4 January 2020 (UTC)

SSastry (WMF), thank you for the speedy debugging! – Jonesey95 (talk) 15:24, 4 January 2020 (UTC)

I will do my very best.

Please note that doc says to use GET/page/lint/{title}.

Therefore, lintHint is using GET on executing page name (revision) queries.

I wonder how that getParsedBody() will be ever reached on GET method.

Current L190 does assign [] to $body immediately.
In lintHint offline development mode I tried it anyway and provided application/json on GET. The error message was kept.
I guess the error message was issued from anywhere else in .org/api/rest_v1/ path, or it is not this rGPAR/extension/src/Rest/Handler/ParsoidHandler being executed.

Please note that it is not very common to ask for any particular Content-Type on a GET query since the message is the URL, and there is no body nor content to be encoded, even more not as JSON. Everything is in the header fields.

The doc tells explicitly that application/json is the format of the answer to a GET query, but does not make any restrictions on the query before.

There is a sandbox form on doc page. Just fill in Wikipedia_talk:Linter and watch the answer.

Greetings --PerfektesChaos (talk) 21:17, 4 January 2020 (UTC)

Okay, we'll look a bit more closely during the week and see what is going on. SSastry (WMF) (talk) 03:17, 5 January 2020 (UTC)

This might be a RESTBase issue that forwards linter request to Parsoid. Parsoid's lint API endpoint is a POST request (Parsoid supports posting wikitext to get linted). We'll dig into that. As for the offsets problem, https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/562094 should fix that once reviewed, merged, and deployed SSastry (WMF) (talk) 08:08, 6 January 2020 (UTC)

The gerrit patch was deployed about 7 hours back, and the offsets problem should now be fixed. We haven't yet looked at the HTTP 415 problem. SSastry (WMF) (talk) 04:52, 9 January 2020 (UTC)

I have only had time to look at two articles, but the highlight targets were perfect, and the "Error: Unsupported Media Type" is gone as well. At least for me, things are working again. Thanks for the quick turnaround! – Jonesey95 (talk) 06:19, 9 January 2020 (UTC)

Cleanup question/ideas/request for lint errors

First question does the bots for this do any auto work on the user talk pages or are they ignored for these purposes? The above will probably modify my further questions and ideas. Thanks121.99.108.78 (talk) 17:26, 7 January 2020 (UTC)

Yes, there is at least one bot approved to fix Linter errors in editor signatures, some of which appear on user talk pages. – Jonesey95 (talk) 19:04, 7 January 2020 (UTC)

Hi Jonesey95, thanks for that, however, I was looking more at the lint table of table errors that appear to be not related to signatures, and note that there are 1,000's of various errors on user talk pages, if the bots skip those then I may try to go in a different direction to try to reduce both the overhead and error reports to focus the workload and effort. Such as archiving user talk pages that have no activity/edits in the last say 6 months and or sending a message to active uses to delete the table in a uniform and trackable way, or asking them to request help to fix if the table is still valid and needed.... more to follow. Can-o-worms afoot?121.99.108.78 (talk) 19:28, 7 January 2020 (UTC)

I don't know whether you are being deliberately vague, but some specific examples, with links, would help clarify what you are asking. Since you specifically mentioned archiving user talk pages, that is generally left up to the user, and archiving would not get rid of the Linter error, it would just move it to the archive page. – Jonesey95 (talk) 22:14, 7 January 2020 (UTC)

Hi Jonesey95, certainly not trying to be vague or ambiguous, however, detailing one or two would not be that beneficial to the bigger picture, hence I asked if "the bots skip" user talk pages, essentially I was looking to drive a more focused report that Lint fixing editors see and only required work appears on each report and not have them clogged up with, in some cases, millions of signature errors, e.g. Tidy bug affecting font tags wrapping links (3,591,242 errors) (as at today). Driving that report can be somewhat time and resource heavy, I note your archive comment above, can we then set-up a bot to replace all error tagged signatures, say with a plain text version, across the project and advise or correct any current editors signature going forward, this will also solve some other lint errors. I know this is not an easy or quick fix, however, I do not want a quick fix, future proofing and targeted resources is the goal.121.99.108.78 (talk) 02:56, 27 January 2020 (UTC)

Moved to Wikipedia:Bot_requests#Bot_for_lint_errors for now, more may follow121.99.108.78 (talk) 10:09, 28 January 2020 (UTC)

How to reliably replace center tags

I can sometimes replace center tags with div tags set to style="text-align:center;" or style="margin:auto;", but it doesn't work reliably for things that are not text. I am looking at {{TOC001}}, and no matter what I try with div tags, I have been unable to get the TOC to sit in the middle of the page. Web searches have proved less helpful than I thought they would be. Does anyone have a reliable way to replace center tags with div tags when they wrap a big block of stuff? – Jonesey95 (talk) 22:45, 7 February 2020 (UTC)

Jonesey95 Usually issues like this are due to the child elements having an opinionated alignment, and because there was not a width on the parent element (0 auto is not pure magic), the div just says "okay, I'll lay out like the child" (I think that's what the auto actually means :D). I believe I've corrected it in Template:TOC001/sandbox. --Izno (talk) 23:40, 7 February 2020 (UTC)

Hmm, I see what you did, but I do not see how to turn that into generalizable advice to put on a page like the MW Linter obsolete tag page. – Jonesey95 (talk) 23:56, 7 February 2020 (UTC)

I don't really know how to do that either. I think just working with the two and then telling people to ask for help if one or the other two solutions doesn't work is probably preferable here. --Izno (talk) 00:07, 8 February 2020 (UTC)

Just putting this here in case someone else is looking for it: to center a whole table instead of wrapping it in center tags, this may work:

{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;" – Jonesey95 (talk) 18:46, 14 February 2020 (UTC)

The margin left/right declarations are almost equivalent to margin: 0 auto (difference of course is setting top/bottom borders to 0). Border none shouldn't be of interest and I expect that would be more likely to cause the border to disappear entirely... which is obviously suboptimal. --Izno (talk) 20:38, 14 February 2020 (UTC)

I just copied it from HELP:TABLECENTER. For some reason, I tried it on one table, and it added a border, which was weird. I've been leaving it out ever since. I don't think I will ever understand CSS. Anyway, I was able to use the left/right stuff to center a bunch of tables in templates, fixing a nice pile of Linter errors via transclusions. – Jonesey95 (talk) 02:02, 15 February 2020 (UTC)

"Page information" sometimes does not match actual Linter error count

Watchers of this page may be interested in T246403, which describes a problem I recently encountered. On a significant number of pages (I encountered at least a dozen while flipping through about 600 pages), the count of Lint errors on the "Page information" page is much lower than the actual count of errors on the page (visible via LintHint and manual inspection of the wikitext). This prevents the pages from appearing in User:Galobot/report/Articles by Lint Errors, a report that is supposed to show the 1,000 articles with the most Linter errors. A purge and a null edit did not fix the discrepancy. – Jonesey95 (talk) 01:10, 28 February 2020 (UTC)

Limits on custom signatures

(reposting text verbatim from a post by Whatamidoing (WMF) at Wikipedia:Bots/Noticeboard:) Please see mw:New requirements for user signatures. One of the goals is to make it easier for bots/scripts/tools to recognize custom signatures (e.g., by requiring that they all contain a link). Please share information or examples over there. – Jonesey95 (talk) 20:15, 4 March 2020 (UTC)

Note that one of the proposed requirements is that new or modified custom signatures with Linter errors will not be permitted to be saved by editors. They will need to fix Linter errors, including obsolete tag errors (e.g. font tags), before their new/modified custom signature can be saved and used. – Jonesey95 (talk) 20:15, 4 March 2020 (UTC)

Templates with noinclude markup surrounding table opening markup

There are now 52 fostered content lint errors for templates. Many of these are caused by markup along these lines:

<noinclude>{| </noinclude>

The fostered content lint error typically goes away when reduced to

{|

and these templates are not causing fostered lint errors where they are transcluded. Can the linter be revised to treat noinclude markup better, to make these lint errors go away? —Anomalocaris (talk) 02:23, 15 April 2020 (UTC)

Linter should probably just ignore noinclude tags, though there might be some side effects. When you put the template into Special:ExpandTemplates and expand it, there are no Linter errors. This feature request is already in Phabricator at T222643, created almost a year ago. My understanding is that the relevant developer resources are focused on Parsoid right now, and Linter will get some attention later in 2020. – Jonesey95 (talk) 04:54, 15 April 2020 (UTC)

Null edit now causes quick recalculation of lint errors

For a long time, I used to "adjust white space to force recalculation of lint errors", but this is no longer necessary. Thank you to whoever worked on making a null edit cause a quick recalculation of lint errors! —Anomalocaris (talk) 19:21, 1 June 2020 (UTC)

Where are you seeing this updated count appear? A while ago, I submitted a bug report related to what I think you are talking about, at T246403, but I am unable to make a null edit change the error count on Page Information for User:Jonesey95/sandbox21. – Jonesey95 (talk) 20:56, 1 June 2020 (UTC)

Here's another one, if it helps: Cuisine of Pembrokeshire. There are 35 missing end tag errors on this page, but Page information shows only 14. – Jonesey95 (talk) 21:08, 1 June 2020 (UTC)

Jonesey95: I tried a null edit of User:Jonesey95/sandbox21 and it didn't update the lint errors from 1 missing end tag. I made a copy of it at User:Anomalocaris/sandbox/Lint Test and there the information page shows 4 missing end tags. Um, well I thought it did, but now it shows 1. So the problem is not with the updating of the lint counter, but that the lint counter doesn't count very well. As for Cuisine of Pembrokeshire, lintHint shows 14, not 35 lint errors, so page information is correct.

My observation of making null edits to update error counts was in the portal space. I didn't keep track of things, but looking back, I see I edited Portal:Tajikistan/Things you can do and fixed a misnested tag, and then I suppose I did a null edit of Portal:Tajikistan, and it doesn't have a misnested tags lint error, so the null edit updated the count. Similarly, I edited Portal:Gibraltar/Selected picture/1...Portal:Gibraltar/Selected picture/10 and Portal:Gibraltar/Categories, fixing obsolete center tags, and then I suppose I did a null edit of Portal:Gibraltar, and this zeroed the Information page count of obsolete HTML tags. Also, I edited Portal:North America/To Do and Portal:North America/Projects and did a null edit of Portal:North America. —Anomalocaris (talk) 10:27, 4 June 2020 (UTC)

The change to Cuisine of Pembrokeshire's count was due to a partial fix of the Linter errors by WOSlinker. As you can see, they fixed a bunch of errors, and the count is still at 14 (perhaps coincidentally, the number of errors that WOSlinker left behind).

I find that sometimes a minor edit will cause the Page Information's Linter error count to be updated, but the reason I submitted the bug is that usually, in my experience, the count stays the same unless all of the errors are fixed. I haven't done a ton of experimenting with it, since I think the WMF developers should fix the problem so that null edits update the Linter error count (to an accurate value) in the same way that they update category memberships and renderings of transclusions. The big implication of the bug is that there are many articles and other pages lurking out there with high error counts, but we don't see them on reports like User:Galobot/report/Articles by Lint Errors. – Jonesey95 (talk) 14:32, 4 June 2020 (UTC)

You can reset the lint counts with a purge action. -- WOSlinker (talk) 15:53, 4 June 2020 (UTC)

That doesn't work for me at User:Jonesey95/sandbox21. Both purge and null edit appear to work occasionally, but not at all reliably. – Jonesey95 (talk) 18:20, 4 June 2020 (UTC)

Just now I edited Category:Satanist Wikipedians. lintHint showed a missing end tag for localized in User:Phunting/Userboxes/LaVey. Leaving that edit session open, I edited User:Phunting/Userboxes/LaVey to remove a missing end tag error for . Then I opened the information page for Category:Satanist Wikipedians and the missing end tag was still there. Then I saved without changing anything (null edit) and within two seconds, the information page updated to show zero lint errors. I have had similar experiences many times since I opened this thread June 1. A null edit really does cause a recalculation of lint errors. —Anomalocaris (talk) 01:52, 11 June 2020 (UTC)

Yes, but only sometimes, as I said above. When I null-edit User:Jonesey95/sandbox21, the Page information is stuck at 1 missing end tag error, even though there are 49 actual errors on that page. – Jonesey95 (talk) 13:33, 11 June 2020 (UTC)

Jonesey95: I edited User:Jonesey95/sandbox21 inserting <strike></strike>, and this updated the information page to show Missing end tag: 1, Obsolete HTML tags: 1. The problem is not that the count doesn't update. The problem is that sometimes, it counts only one out of several instances of an error. —Anomalocaris (talk) 18:25, 15 June 2020 (UTC)

Fair enough. My bug report describes that situation accurately. The developers might work on it someday. I have submitted a bunch of little Linter-related bug reports. – Jonesey95 (talk) 18:54, 15 June 2020 (UTC)

Removing /right/ option in image syntax

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I'm getting a little sick of my watchlist getting cluttered with obsessive-compulsive removal of |right in image invocations, as if that's some sort of error [1]. It's not. There are valid reasons we might want to give |right explicitly, and going around removing it is just plain silly. Izno, you've got a good head on your shoulders -- maybe you can look into this. Fixing errors is good; fixing non-errors is evil. E Eng 20:26, 20 October 2020 (UTC)

Well fuck, here I get all up in arms and it turns out I'm being an idiot asshole. I apologize. In mitigation, in the past a lot of truly annoying, useless gnoming used to go on, and with the retirement of certain editors that seemed to have stopped, which was a great relief. So when I saw this, it's like when someone has a ~~prophylactic~~ ~~Anabaptist~~ anaphylactic reaction to something because you immune system has been hypersensitized by previous exposure. So again I apologize, but please let's not go back to the old days. E Eng 21:16, 20 October 2020 (UTC) And the edit summary could have been more explicit.

Did I mention that I deeply, truly, humbly and contritely apologize for flying off the handle? E Eng 21:19, 20 October 2020 (UTC)

I think you might have mentioned something about it ;-) Primefac (talk) 21:27, 20 October 2020 (UTC)

EEng, I demand that you apologize some more, and add another image or two that shows the depth of your regret and shame. Sheesh. In less sarcsastic news, if you miss that itchy feeling, you are welcome to look through my contributions, where you will find a lot of utterly, completely useless gnoming, and excoriate me on my talk page for anything egregious that you find there. I prefer to be entertained on my home turf rather than having a bunch of page voyeurs observe us doing our thing. – Jonesey95 (talk) 22:30, 20 October 2020 (UTC)

Yeah, totally... we're definitely not watching you anywhere else... Primefac (talk) 23:04, 20 October 2020 (UTC)

For the record, it's this [2] that had me itching for a fight. E Eng 23:38, 20 October 2020 (UTC) P.S. If anything happens to me, uncollapse the following:

UNCOLLAPSE ONLY IF SOMETHING HAPPENS TO EENG! OTHERWISE DO NOT UNCOLLAPSE!

You know the saying, "Curiosity killed the cat"?
Levivich did it!

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Center" caption being shown as a bogus file option lint error.

Results_of_the_2018_Swedish_general_election#Results_by_municipality has gallery images of election results with captions "Left", "Center" etc,. Here they are captions that refer to political parties and are not file options. But they are being shown as bogus file option lint errors.
AVSmalnad77 (talk) 17:15, 19 November 2020 (UTC)

Yes, this is a known bug with no known workaround. I documented it at mw:Help:Images and submitted it as T266406. I also submitted a Community Survey proposal to ask the MediaWiki developers to fix a whole bunch of image syntax bugs, including this one. – Jonesey95 (talk) 18:36, 19 November 2020 (UTC)

I tried a workaround and it was successfully. I changed the captions to "Center Party" and "Left Party". These terms were used elsewhere in the page and doesn't change the meaning of caption. Afterwards I refreshed the linter page and they we gone. So the workaround is to change the caption of image. AVSmalnad77 (talk) 02:24, 20 November 2020 (UTC)

Help requested for lint errors in collapsed infobox sections

You are invited to join the discussion at Template talk:Collapsed infobox section begin § LintHint errors. {{u|Sdkb}} ^talk 18:07, 25 November 2020 (UTC)

Yeah, I haven't found a perfect fix for collapsed infobox sections. If I think that the content should simply be shown, per MOS, I show it, which "fixes" the Linter errors. I haven't touched the many, many Linter errors in Covid-related pages, though, because the articles and templates are huge and often a mess. – Jonesey95 (talk) 19:36, 25 November 2020 (UTC)

I managed to remove every linter error from COVID-19 pandemic and yes, it was a pain in the [insert name of politician here]. Alas, I could not do it and retain the exact formatting that was there already -- which was my goal -- because Template:Collapsed infobox section begin has linter errors, it is protected so that I can't fix the errors, and I can't figure out any alternative way to do the collapsing. Perhaps someone else can find a workaround, but the Right Way To Fix This is to not have Template:Collapsed infobox section begin contains HTML errors. Sdkb has a good point is saying that fixing HTML errors should not change the way the page displays. I mean, how hard can it be to either remove the <div> or add a </div> to match the <div>? --Guy Macon (talk) 22:36, 25 November 2020 (UTC)

Let me know what needs changing and I'll do it. Primefac (talk) 12:24, 26 November 2020 (UTC)

At the risk of telling you things you already know (one never knows who will read and try to follow these kinds of comments), here is an example of a standard HTML table, properly indented.

 <!DOCTYPE html>
 <html>
     <head>
         <title>
            Page title
         </title>
     </head>
     <body>
         <table>
             <tr>
                 <th>
                     Table heading 1
                 </th> 
                 <th>
                     Table heading 2
                 </th>
             </tr>
             <tr>
                 <td>
                     Table data 1
                 </td>
                 <td>
                     Table data 2
                 </td>
             </tr>
         </table>
      </body>
 </html>

Which gives you:

Table heading 1	Table heading 2
Table data 1	Table data 2

As you can see, if you look at, say, a <tr> and move down, you see the matching </tr> at the same indentation level.

If you can't line them up you most likely have an extra start tag or an extra end tag.

OK, so the Wikisource for Template:Collapsed infobox section begin looks like this:

<includeonly></td></tr><tr><td colspan=2><table class="mw-collapsible {{#ifeq:yes|{{yesno|def=|{{{expanded|}}}}}||mw-collapsed}}" style="width:100%;{{#ifeq:yes|{{yesno|def=|{{{cont|}}}}}|margin-top:-0.65em;|}}{{{style|}}}"><tr><th colspan=2 style="text-align:center;line-height:normal;padding:0.2em 0.2em;{{{titlestyle|}}}"><div style="margin:0 3.5em">{{{1|Further information}}}</div></th></tr></includeonly><noinclude>{{documentation}}</noinclude>

Pretty confusing, (Rant: if people indented their code the problem would have been obvious to them) but I will add some line numbers, try to indent it, and add comments:

 00 <includeonly>
 01     </td>
        <!-- WHY IS A CLOSING /TD HERE? WHERE IS THE OPENING TD? WHERE IS THE DATA? -->
 02     </tr> 
        <!-- WHY IS A CLOSING /TR HERE? WHERE IS THE OPENING TR? -->
 03     <tr>
        <!-- WHERE IS THE CLOSING /TR FOR THIS TR? -->
 04         <td colspan=2> 
            <!-- WHERE IS THE CLOSING /TD FOR THIS TD? -->
 05             <table 
                    class=
                        "
                            mw-collapsible 
                            {{#ifeq:yes|{{yesno|def=|{{{expanded|}}}}}||mw-collapsed}}
                            <!-- IGNORING THIS. FIX THE HTML TAGS FIRST -->
                        "
                    style=
                        "
                            width:100%;
                            {{#ifeq:yes|{{yesno|def=|{{{cont|}}}}}|margin-top:-0.65em;|}}
                            <!-- IGNORING THIS. FIX THE HTML TAGS FIRST. -->
                            <!-- BUT WHY IS IT EMPTY? -->
                            {{{style|}}}
                            <!-- IGNORING THIS. FIX THE HTML TAGS FIRST. -->
                            <!-- BUT WHY IS IT EMPTY? -->
                        "
                >
            <!-- SHOULDN'T THERE BE A CLOSING /TD HERE? -->
        <!-- SHOULDN'T THERE BE A CLOSING /TR HERE? -->
 06     <tr>
 07         <th 
                colspan=2 
                style= 
                    "
                        text-align:center;line-height:normal;padding:0.2em 0.2em;
                        {{{titlestyle|}}}
                        <!-- IGNORING THIS. FIX THE HTML TAGS FIRST. -->
                        <!-- BUT WHY IS IT EMPTY? -->
                    "
            >
 08             <div style="margin:0 3.5em">
                    {{{1|Further information}}}
                    <!-- IGNORING THIS. FIX THE HTML TAGS FIRST. -->
 09             </div>
 10         </th>
 11     </tr>
 12 </includeonly>
 13 <noinclude>
 14     {{documentation}}
        <!-- IGNORING THIS. FIX THE HTML TAGS FIRST. -->
 15     <!-- Add categories to the /doc subpage, interwikis to Wikidata, not here -->
        <!-- THAT'S A COMMENT IN THE SOURCE. MY ADDED COMMENTS ARE ALL CAPS -->
 16 </noinclude>

Hmmm. An extra /td and /tr at the start, a missing /td and /tr farther down. Could that be it? The first thing I would do is try moving lines 01 and 02 to be right before line 06, test the result with LintHint. and then test to see that the template still works properly. --Guy Macon (talk) 16:21, 26 November 2020 (UTC)

Template:Tooltip, Template:Hover_title, and Template:Abbr

FYI

– Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Templates for discussion/Log/2020 December 3#Template:Hover title and Template:Tooltip

Summary:

{{Abbr}} (a wrapper for <abbr>...</abbr>) has long been abused for non-abbreviation markup (against the HTML specs).
We had a template, {{Tooltip}}, with ... for non-abbreviation use, but it was "merged" (not really) and redirected to {{Abbr}}.
The redir was then deprecated (for the reason mentioned above), but the community ignored the deprecation.
In the interim, {{Hover title}} was created to do the same thing, but with backwards parameters (and some additional features).
Both the {{Tooltip}} then-redirect and {{Hover title}} template have been transcluded in tens of thousands of articles, mainly via infoboxes and other templates.
I created a new {{Tooltip}} template, with all the features of {{Hover title}} but preserving the {{Abbr}} parameter order (to not break deployed translcusions).
The TfM linked above would merge away {{Hover title}}, but it's going to require flipping the |1= and |2= parameters of its extant instances.
Oh, and the documentation would need updating after merger, of course.

— SMcCandlish ☏ ¢ 😼 23:55, 3 December 2020 (UTC)

Community Wishlist proposal to fix multiple File:-related Linter syntax problems

I have submitted a proposal for the Community Wishlist survey, asking developers to fix many Linter-related bugs in the File: syntax. See m:Community Wishlist Survey 2021/Multimedia and Commons/Make File syntax processing match the specification and documentation. Voting is open for the next week or so. – Jonesey95 (talk) 23:18, 8 December 2020 (UTC)

Is that link right? "There is currently no text in this page. You can search for this page title in other pages, search the related logs, or create this page." pauli133 (talk) 16:53, 9 December 2020 (UTC)

@Pauli133: I've fixed the link; it's run on meta, not the more obvious MediaWiki.org to which Jonesey95 had understandably linked. Jdforrester (WMF) (talk) 17:12, 9 December 2020 (UTC)

Unclosed quote in heading has additional variations

There are additional variations to the Unclosed quote in heading lint error. There are at least 4 HTML tags that, if unclosed in a heading, will leak via the table of contents to the entire article: , , <s>, and its obsolete variant <strike>. The good news is that other unclosed tags that don't leak via the table of contents include , , , <tt>, <samp>, <kbd>, <var>, , , , , <big>, , <del>, <ins>. Some of these unclosed tags in headings do leak to the end of the article, but not via the table of contents. —Anomalocaris (talk) 21:36, 27 December 2020 (UTC)

Those are "missing end tag" errors. LintHint finds them just fine, at least in a simple test in my sandbox. – Jonesey95 (talk) 23:44, 27 December 2020 (UTC)

As missing end tag errors, they are low priority, but as errors-in-heading-that-leak-to-entire-page-above-and-below, they are as serious as unclosed quote in heading, and therefore they are high priority. —Anomalocaris (talk) 10:43, 28 December 2020 (UTC)

Center html tag binding the gallery parser tag

WP:MULTI of WT:HTML 5#Centered gallery parser tag. --Izno (talk) 13:42, 1 January 2021 (UTC)

Signature replacement

I would like to know how the following signature can be replaced by removing the lint error:

Vēnī‧vīdī‧scrīpsī

Adithyak1997 (talk) 19:23, 1 July 2020 (UTC)

Convert to span tags, like this:

Vēnī‧vīdī‧scrīpsī

Note that there are minor changes to the punctuation required. – Jonesey95 (talk) 20:14, 1 July 2020 (UTC)

If there is no link,

<span style="font-variant: small-caps; color: darkblue; font-size: 3px">Vēnī‧vīdī‧scrīpsī</span>

. If this is to be used in/around a single link,

[[Veni vidi vici|<span style="font-variant: small-caps; color: darkblue; font-size: 3px">Vēnī‧vīdī‧scrīpsī</span>]]

. If multiple links, we can provide an answer for that too, but it is a slightly different look at that point. --Izno (talk) 20:17, 1 July 2020 (UTC)

Adithyak1997: please note that WP:SIGAPP says avoid signature markup that enlarges text, so please don't use this markup in a signature string. Note that Jonesey95's markup attempts and fails in two ways to convert font size markup, only one of which is corrected in Izno's markup.  is treated as , which converts to , so the whole signature (with non–WP:SIGAPP-compliant markup) would be

Vēnī‧vīdī‧scrīpsī : Vēnī‧vīdī‧scrīpsī

Cheers! –Anomalocaris (talk) 01:34, 10 March 2021 (UTC)

AN discussion related to Lint errors

I have started a Lint error cleanup related discussion at that will be of interest to those watching this page - Wikipedia:Administrators' noticeboard#Removing full protection of old TFA pages. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:45, 31 March 2021 (UTC)

Lint error grid not found

Tracked in Phabricator
Task T254690

The lint error grid is giving a 404 not found. —Anomalocaris (talk) 20:36, 7 June 2020 (UTC)

I notified Firefly on their talk page. It's a bummer, too, because I just fixed like a thousand fostered content errors in main space and wanted to get some instant gratification by reloading the page. – Jonesey95 (talk) 22:56, 7 June 2020 (UTC)

The maintainer is having issues migrating to toolforge.org. (phab:T254690) — JJMC89 (T·C) 23:15, 7 June 2020 (UTC)

You are right. I am facing issues. I will try to resolve the error at the earliest. Sorry for the inconvenience caused. Adithyak1997 (talk) 11:25, 8 June 2020 (UTC)

@Anomalocaris:, @JJMC89: The issue is resolved. Adithyak1997 (talk) 16:28, 9 June 2020 (UTC)

Adithyak1997: Thanks! But the page hasn't updated since 2020-06-09 08:08:58, almost two days ago. It used to run every hour or two. —Anomalocaris (talk) 01:55, 11 June 2020 (UTC)

@Anomalocaris I have removed myself as the maintainer of the tool. Now, a new maintainer is needed for the same. I think the project will have to be upgraded to new Python version. Adithyak1997 (talk) 05:32, 11 June 2020 (UTC)

Just in case people are still using this, I've fixed it now (just needed the Python venv updating for Python 3) and it will start updating again shortly. Apologies for its absence, and my own! ƒirefly ( t · c · who? ) 11:28, 7 February 2021 (UTC)

Thank you! I missed this grid terribly during its absence. I find it very motivating, and it helps me be aware of little brushfires that are caused by errors in templates. – Jonesey95 (talk) 16:03, 7 February 2021 (UTC)

Not a problem - it seems to update a little slower now, I think the DB queries are taking longer. I'll try to parallelise them as much as I can to speed things up. ƒirefly ( t · c ) 16:07, 7 February 2021 (UTC)

Firefly, the table appears to be missing a column for Special:LintErrors/wikilink-in-extlink, a medium-priority error. Or maybe my eyes keep skimming past it and missing it? – Jonesey95 (talk) 18:56, 15 February 2021 (UTC)

Hmm... no, you’re not missing it, it’s definitely not there. I’ll look into it! ƒirefly ( t · c ) 19:29, 15 February 2021 (UTC)

Firefly: It would be great to have the links in links column added. I've searched this lint error manually a few times and worked to restricting it to the first six namespaces. —Anomalocaris (talk) 04:58, 20 April 2021 (UTC)

Now done - long overdue, but done nonetheless! ƒirefly ( t · c ) 16:47, 11 May 2021 (UTC)

Thank you! I see it. Now to get to work.... – Jonesey95 (talk) 16:52, 11 May 2021 (UTC)

Adithyak1997: Thank you! I also missed this grid during its absence, and I hope others will find it useful in creating executing lint-eradication tasks. —Anomalocaris (talk) 01:14, 10 March 2021 (UTC)

Unclosed div on user talk

I have seen users (including very recently) who have a div style at the top their talk but no closing div at the bottom. Indeed, if the close was included, it would be continually messed up when people add new sections or generally add comments without leaving the div close in place. Is there a procedure for dealing with that? Is there a good way of handling a talk page with a non-standard style? Johnuniq (talk) 06:35, 7 February 2021 (UTC)

Today, other than requesting it be removed, no (perhaps with the stick that it may not work in the indeterminate future, perhaps when Parsoid is made the sole parser). I filed phab:T271588 in the past month which would solve it. I suppose there could be a phab request for someone to customize the new section button, such that it removes an immediate preceding /div and adds its own, but that is still brittle for user expectation. Or something like that, anyway. --Izno (talk) 07:16, 7 February 2021 (UTC)

Thanks but I have to confess that the phab is over my head. Johnuniq (talk) 09:49, 7 February 2021 (UTC)

Basically, today TemplateStyles scopes all styles to elements with the mw-parser-output class, non inclusive, meaning I can target anything inside such a class but not the class itself. What the ticket proposes is some way to target the element with mw-parser-output. Then these page-long enclosed divs usually serving to style the whole page could have their styles moved to TemplateStyles targeting the mw-parser-output element (which is always the element closest to the parser output). Subsequently, the offending unclosed divs could be removed. --Izno (talk) 10:01, 7 February 2021 (UTC)

Yikes, that might lead to an outburst of, uhh, creativity. I see there is talk of restricting usage. Johnuniq (talk) 10:12, 7 February 2021 (UTC)

<div> should be closed on user talk archive pages, but as noted, they sometimes have to be left open on user talk pages. —Anomalocaris (talk) 18:51, 23 March 2021 (UTC)

What's needed is a new template. Somewhere near the top of the page, you would put {{Endinsert|</div>}} and that would insert </div> at the end of the page. —Anomalocaris (talk) 20:06, 31 May 2021 (UTC)

class without quotes

We already know that the linter fails to detect noncompliant markup including using

bgcolor=color instead of style="background:color"
align=place instead of style="text-align:place"
table cell rowspans and colspans without quotes

In addition to these I note the use of

<div class=class instead of <div class="class", i.e. omitting the quotes around class.

Is this an error? Is there a phab for it? If not, should there be? And should one routinely quote unquoted classes? —Anomalocaris (talk) 20:52, 20 April 2021 (UTC)

I don't know about all of these, but Help:Table shows a working example of colspan=2 without quote marks. I'm assuming that it is not an error, or that the Remex developers decided to continue supporting it when they dropped Tidy. – Jonesey95 (talk) 22:43, 20 April 2021 (UTC)

According to mw:Help:Lint errors/obsolete-tag, bgcolor and align are obsolete HTML, but Linter doesn't detect them. There is Phabricator: T173944 ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 06:21, 21 April 2021 (UTC)

In HTML, quote marks are not required for attributes which have no whitespace contained in their values. It is usually safer to include them, just the same, but they are not something you should do anything more than fix as you travel the wiki doing other things. Izno (talk) 14:04, 15 June 2021 (UTC)

missing end tags not detected for the "include" tags

The linter fails to detect missing end tags and stripped tags for noinclude, includeonly, and onlyinclude. —Anomalocaris (talk) 11:06, 14 December 2020 (UTC)

These are not HTML and should not be parsed/checked as such. Izno (talk) 14:09, 15 June 2021 (UTC)

Firefly counts are wrong for Multiple unclosed formatting tags

Resolved

Right now and the past several updates, the Outstanding linter errors on enwiki grid counts for Multiple unclosed formatting tags are Articles, 15; User, 2. The actual numbers are Articles, 4; User: 1. This error has persisted for at least a few hours now. —Anomalocaris (talk) 17:44, 18 May 2021 (UTC)

Pinging Firefly. The page appears to be updating the date stamp, but the error counts are not changing. I have noticed this in other table cells as well, in spaces where I have recently fixed dozens or hundreds of problems. – Jonesey95 (talk) 17:46, 18 May 2021 (UTC)

Yes, Misnested Tags has been frozen for the past ten or twelve hours, at least. I hope this can get sorted out, it's been really nice having that page working lately. pauli133 (talk) 01:08, 19 May 2021 (UTC)

@Anomalocaris, Jonesey95, and Pauli133: The tool uses the toolforge DB replicas for its data, it seems that it's this that is stuck for some reason. This Quarry query gives the same result for the Misnested Tags count as the tool - 3982. Could be replag, but it's more likely that for whatever reason the actual counts in the live DB aren't being updated. Perhaps a Phab ticket is needed... ƒirefly ( t · c ) 08:15, 19 May 2021 (UTC)

Well, that's a change from the 4023 it showed all day yesterday, and it's now at 3980, so it looks like things are moving again. pauli133 (talk) 13:30, 19 May 2021 (UTC)

It looks like this toolforge:replag problem is fixed now. – Jonesey95 (talk) 13:34, 19 May 2021 (UTC)

Pinging Firefly. Outstanding linter errors on enwiki last updated 2021-05-31 07:03:49. —Anomalocaris (talk) 16:54, 1 June 2021 (UTC)

@Anomalocaris:

Fixed - job stuck in the queue, now killed off and everything's back to normal. firefly ( t · c ) 18:03, 1 June 2021 (UTC)

Paging Dr. Firefly. For over 24 hours, Outstanding linter errors on enwiki has not responded at all: 404 not found. —Anomalocaris (talk) 20:34, 8 June 2021 (UTC)

@Anomalocaris: that is weird - it works for me. Don’t suppose you can try on a different network (e.g. mobile?). Could be DNS weirdness. firefly ( t · c ) 20:41, 8 June 2021 (UTC)

My grid tab was browsing the wrong URL. Not sure how that happened. Never mind! —Anomalocaris (talk) 20:56, 8 June 2021 (UTC)

The Linter count has not updated in the last 48 hours. Pinging Firefly for attention. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:04, 15 June 2021 (UTC)

ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, looks to be working as normal now at least. firefly ( t · c ) 13:39, 15 June 2021 (UTC)

Yes, seems it returned to normal shortly after I posted. And I see new "Namespace total" column and "Lint error total" row that I don't recall seeing before. Useful stats. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:52, 15 June 2021 (UTC)

ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ, yes, they're new today! I'll make a proper post here about them shortly. Thank Izno for prodding me to add them! firefly ( t · c ) 14:03, 15 June 2021 (UTC)

Paging Dr. Firefly. Great new design, but is the new plan to update the page only every other day? —Anomalocaris (talk) 22:40, 16 June 2021 (UTC)

Anomalocaris, no, if it's doing that then something's wrong. I'll look into it. Glad you like the new design! firefly ( t · c ) 06:41, 17 June 2021 (UTC)

Anomalocaris, fixed! Job stuck in the queue, probably didn't like me deploying the new version of the script while it was running...! firefly ( t · c ) 12:26, 17 June 2021 (UTC)

"Template:Human timeline"

NOTE: Copy of the original post at User talk:Drbogdan#"Template:Human timeline":

Hi, you introduced a div-span-flip error with your changes to Template:Human timeline today. All the pages it links to are now appearing in the WP:LINT filter Miscellaneous issues And I'm not seeing what needs to be adjusted to correct this issue. I thought you'd appreciate this message more than me attempting to tinker with it. Zinnober9 (talk) 20:50, 5 July 2021 (UTC)

@Zinnober9, Hike395, and Jonesey95: (and others) - Thank you *very much* for your post re the "WP:Lint" issue - at the moment, I have no idea whatsoever how to solve this problem (I'm a "newbie" with much of the template coding) - any help solving this template problem would be *greatly* appreciated - Thanks in advance for your help with this - and - Stay Safe and Healthy !! - Drbogdan (talk) 21:30, 5 July 2021 (UTC)

Fixed. I had to swap two nested templates. In short, {{font}} uses span tags, and {{Vertical text}} uses div tags. Div tags don't like to be inside of span tags. – Jonesey95 (talk) 22:48, 5 July 2021 (UTC)

Thank you @Jonesey95: Thank you *very, very* much for your help with this linter error - lesson learned - Thanks again - your help is *greatly* appreciated - Stay Safe and Healthy !! - Drbogdan (talk) 00:01, 6 July 2021 (UTC)

Linter bogus file option error?

Linter reports a bogus file option error "120x120px" in the picture gallery in Brighton, Victoria. But there is no "120x120px" anywhere in the article text. —Bruce1ee^talk 13:24, 10 July 2021 (UTC)

There was an invalid file option 80px in gallery. Not sure why it was showing as 120x120px, but the error is gone now. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:49, 10 July 2021 (UTC)

Thank you. —Bruce1ee^talk 13:59, 10 July 2021 (UTC)

Help required to fix obsolete HTML tags

Linter is reporting obsolete HTML tags in a user signature at Wikipedia:WikiProject Resource Exchange/Resource Request/Archive 31#African writers. The signature in question is:

 <font style="white-space:nowrap;text-shadow:#FF0000 0.1em 0.1em 1.5em,#01EE796D -0.1em -0.1em 1.5em;color:#00000F">[[User:Masssly|<font color="#01EE796D"><b>—M@sssly</b></font>]][[User talk:Masssly|<font color="#FFEG0000"><sup>✉</sup></font>]]</font>

which yields:

—M@sssly^✉

I've tried changing it to:

 <span style="white-space:nowrap;text-shadow:#FF0000 0.1em 0.1em 1.5em,#01EE796D -0.1em -0.1em 1.5em;color:#00000F">[[User:Masssly|<span style="color:#01EE796D;"><b>—M@sssly</b></span>]][[User talk:Masssly|<span style="color:#FFEG0000;"><sup>✉</sup></span>]]</span>

but it gives:

—M@sssly^✉

which is not the same as the original. The envelope isn't red and the user name appears to have lost its bolding. What must I do the fix this?

Thanks —Bruce1ee^talk 11:28, 2 August 2021 (UTC)

Bruce1ee, fixed. Problem was because 8 digit hex codes are valid in font tag, but not in CSS. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 12:27, 2 August 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: I see what the problem was – I should have changed the 8-digit color codes to 6 digits. Thank you for your help. —Bruce1ee^talk 12:49, 2 August 2021 (UTC)

Feature requests/protocol suggestions

@Jonesey95 and WOSlinker: I decided to post here instead of y'alls talks to inform and/or get input from the delinting community.

To me, perhaps I'm wrong, lint is something that can be removed innocuously, without changing the rendered page, unless something is broken to begin with. However, delinting these colon-indents changes the page output, and nothing was "broken" prior, just undesired. So I would suggest the following improvements:

replacing page-changing-lint with the appropriate syntax, if possible,
inform the lint-producing editor more carefully/obviously of the alternatives (it's not obvious to me which error @ Special:LintErrors I've created),
since the WP:Linter software already knows which rules are broken, in order to categorize them, it should be relatively easy to list them in the edit summary.

Re #1: how do I properly indent these templates? ~ Tom.Reding (talk ⋅dgaf) 17:05, 18 August 2021 (UTC)

Thanks for the note. I often fix Linter errors by replacing invalid code with valid code, or by closing unclosed tags, but using colons for indenting has been discouraged for a long time, and it is not clear to me what the colons are intended to achieve on that page. See MOS:INDENT for guidance, and MOS:INDENTGAP for recommended alternatives. – Jonesey95 (talk) 17:05, 18 August 2021 (UTC)

Unfortunately, that doesn't help, and raises more questions.

MOS:Accessibility#Indentation promotes colons.
MOS:Accessibility#Indentation promotes bullets. Are bullets OK instead of colons?
Which error @ Special:LintErrors did I create?
Original colon-indented output (top) vs. delinted output (bottom):

#invoke unnamed parameter:

Error! Function find_var can't find the variable text in category "Navseasoncats/testcases".***Navseasoncats failed to generate navbox***V

Category:Navseasoncats using unknown parameter

Error! Function find_var can't find the variable text in category "Navseasoncats/testcases".***Navseasoncats failed to generate navbox***V

Category:Navseasoncats using unknown parameter

#invoke unnamed parameter:

Error! Function find_var can't find the variable text in category "Navseasoncats/testcases".***Navseasoncats failed to generate navbox***V Category:Navseasoncats using unknown parameter Error! Function find_var can't find the variable text in category "Navseasoncats/testcases".***Navseasoncats failed to generate navbox***V Category:Navseasoncats using unknown parameter

~ Tom.Reding (talk ⋅dgaf) 17:25, 18 August 2021 (UTC)

When you use a colon to indent the template, like :{{Navseasoncats |2010}}, it creates nonsensical list markup, and also puts an opening div tag on the first list-markup (colon-indented) line, and the closing div tag on a final line that is not part of the list markup. This causes two Linter errors: a missing closing tag (for the div on the list markup line), and a missing opening tag (for the closing div tag that is not part of a list). Linter errors like this are often caused when people use * or # or : to the left of a block-level div element. – Jonesey95 (talk) 17:47, 18 August 2021 (UTC)

I see that you have restored the spacing of the second example above, making it all run in one long line, as wikitext does even if you insert a single manual line break. I don't know why you did that; it makes it more difficult to see the difference between the two rendered examples. If you want white space between lines, insert white space between lines (see the Help page linked two sentences ago). – Jonesey95 (talk) 23:53, 18 August 2021 (UTC)

I want to show what your & WOSlinker's delinting edits did, with the intent of lessening future formatting conflicts. The difference is pretty clear. The point being that one can delint and break intended formatting (though the missing open & closing tags were not intentional).

Can WP:Linter be made more editor friendly by at least identifying what errors it is fixing? ~ Tom.Reding (talk ⋅dgaf) 00:23, 19 August 2021 (UTC)

At this time, you need to install LintHint to see and be directed to the Linter errors on a given page. – Jonesey95 (talk) 03:30, 19 August 2021 (UTC)

New Linter bogus file option errors

Does anyone know why this version of my sandbox is displaying a Bogus file option of 120x120px for each image? I think this has to do with new bug fixes related to Linter bogus file option detection code that rolled out in the latest version of the MediaWiki software, e.g. T215999. – Jonesey95 (talk) 05:41, 26 February 2021 (UTC)

Not only that, a file link with a valid caption ending in "px" is falsely detected as a bogus image option. —Anomalocaris (talk) 21:36, 9 March 2021 (UTC)]]

I forgot to respond to my own post after I figured it out. Apparently, using an unlabeled px size in a gallery results in a Linter error; the gallery code sets a default size of 120px for width and height. Removing the unlabeled px sizing in a gallery entry fixes the Linter error. I added that information to the Linter help page.

I filed the latter condition as a bug a few days ago (T276675). – Jonesey95 (talk) 22:31, 9 March 2021 (UTC)

Thank you for the explanation and editing the Linter help page.

Thank you for filing the bug report. —Anomalocaris (talk) 01:08, 10 March 2021 (UTC)

A workaround for captions ending in "px" is to replace px with px. —Anomalocaris (talk) 09:24, 31 August 2021 (UTC)

I haven't come across one of these in a while, but adding a non-displaying character like {{sp}} or {{nbsp}} after the px will also work around the problem. – Jonesey95 (talk) 15:52, 31 August 2021 (UTC)

Linter bogus file options false positive?

The gallery in my sandbox (from Krýza's crèche) returns a bogus file option of "Centre". But "Centre" is a file caption. If you change "Centre" to "Cent", no lint errors are reported. Is this a false positive? —Bruce1ee^talk 15:45, 1 September 2021 (UTC)

Yes, it is. This is T266406, a fix for which is supposed to be deployed in the next couple of weeks. You can work around it for now by adding {{sp}} after the word "Centre". I did that in your sandbox as a demonstration [3]; I hope you don't mind. – Jonesey95 (talk) 21:23, 1 September 2021 (UTC)

@Jonesey95: Not at all. I didn't realize it had already been logged as a bug. Thanks for the fix. —Bruce1ee^talk 22:02, 1 September 2021 (UTC)

New bogus file options errors detected

FYI, a bug fix was deployed in the last 24 hours that will flag some (or all?) upper-case file options, like "Left" instead of "left", as bogus file options. The fix is to use all lower-case, as shown in the Wikipedia:Extended image syntax documentation. – Jonesey95 (talk) 14:15, 3 September 2021 (UTC)

Undetected div-span-flip lint errors

According to HTML Block and Inline Elements at w3schools.com:

Note: An inline element cannot contain a block-level element!

But here in Wikipedia, the linter doesn't detect all such improper inline elements wrapping block-level elements as div-span-flip lint errors:

<small><ul>
<li>One</li>
<li>Two</li>
</ul></small>

One
Two

In this example, inline ... tags wrap both <ul>...</ul> and <li>...</li>, both of which are block-level elements.

<small><blockquote>Blockquote</blockquote></small>

Blockquote

In this example, inline ... tags wrap <blockquote>...</blockquote>, a block-level element.

Of course, this issue affects other inline elements and other block-level elements. When I'm editing an article for any reason, I fix any such flips that I notice. It would be helpful if the linter or some other tool flagged such flips. —Anomalocaris (talk) 01:58, 20 September 2021 (UTC)

I have noticed these Linter lapses as well. The div/span wrapping errors are the ones that seem to be flagged most inconsistently to me. If you create a sandbox page with a simple test case, I will be happy to submit a bug to Phabricator. If the bug ever gets fixed, of course, that will leave us with more Linter errors to fix. – Jonesey95 (talk) 03:43, 20 September 2021 (UTC)

My understanding is that Parsoid checks against the parsing algorithm only, not the various other content model requirements. I do not know why the div span error exists from that perspective since I was pretty sure it is not in the parsing algorithm. Izno Public (talk) 08:36, 20 September 2021 (UTC)

As for inline versus block, these are no longer terms used in HTML 5 (except in the context of CSS display directives). Span is phrasing content and div is flow content.

The differences for many elements are immaterial, but for some elements the difference does matter. Izno Public (talk) 08:42, 20 September 2021 (UTC)

Strange errors: Paragraph wrapping bug workaround

Paragraph wrapping bug workaround is reporting bogus errors, or at least errors that lintHint cannot detect. There are now 7 unique files that have such errors, not including one that merely transclude other pages with errors. In every case, when I edit click the edit link, a string of text is highlighted, but there doesn't seem to be anything wrong with the highlighted string.

lintHint doesn't detect errors
lintHint doesn't detect errors if the page is copied into ExpandTemplates
Copying the highlighted text into a sandbox and saving the sandbox doesn't result in the sandbox having lint errors, according to its page information page
A null edit does not cause the purported lint errors to go away

According to MW:Help:Lint errors/pwrap-bug-workaround, this error is supposed to be triggered by markup like

<div><span style='white-space:nowrap'>
foo
</span>
</div>

but the bogus errors are more like

:<span style='white-space:nowrap'>foo</span>

without any apparent div markup. —Anomalocaris (talk) 03:33, 24 September 2021 (UTC)

That looks like a Linter bug to me, but a strange one. It lists one in User talk:Elonka/Archive 43, which also had a dozen other Linter errors. LintHint shows the paragraph wrapping error when the page is in read mode, but not in edit mode (I get that sort of problem with other pages, especially templates (e.g. at Template:Code), but I have been ignoring it for a long while, figuring it will maybe go away on its own, and there are enough real errors to deal with).

I copied the entire contents of that User talk page to my sandbox, where LintHint showed a dozen Linter errors, but no paragraph wrapping error. Just for kicks, I fixed all of the Linter errors in User talk:Elonka/Archive 43 and in the identical copy in User:Jonesey95/sandbox. My sandbox shows no Linter errors now, but the User talk page shows a paragraph wrapping error. The pages are identical except for their namespace. The code that Linter highlights when you click "edit" from the listing is {{nowrap|{{code|?fuzzy{{=}}1}}}}, which looks fine when expanded.

I don't see anything relevant in Related changes for that User talk page, which makes me think this is a change related to the new version of MediaWiki; WP:ITSTHURSDAY, after all. I have no conclusions from all of this. – Jonesey95 (talk) 04:19, 24 September 2021 (UTC)

Replacing {{nowrap|{{code|?fuzzy{{=}}1}}}} with {{nowrap|<code><nowiki>?fuzzy=1</nowiki></code>}} removed User talk:Elonka/Archive 43 from error report. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:03, 24 September 2021 (UTC)

The bogus lint errors are gone now. —Anomalocaris (talk) 07:01, 24 September 2021 (UTC)

But new ones are appearing. Presumably this is related to the issues noted in the next session and we should look forward to seeing "this fixed for next week's train" per SSastry (WMF). —Anomalocaris (talk) 21:38, 24 September 2021 (UTC)

Incorrect "Multiple unclosed formatting tags" report?

Multiple unclosed formatting tags is reporting a "small" lint error in Talk:Fortnite (permanent link). lintHint also reports an error when I specify the talk page name, but when I paste the contents of the talk page into lintHint, it reports no error! (Saving the page in my sandbox also reports no error.) Linter appears to be reacting to the adjacent  tags, but there's nothing wrong with that – the user just wants extra small text, and the tags are closed later with . —Bruce1ee^talk 11:12, 24 September 2021 (UTC)

As in the section above, replacing the code template with tag removed the error. Something about the code template is triggering Linter today. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 12:07, 24 September 2021 (UTC)

Thanks for fixing that. But what is interesting is that if the page (with the code template) is pasted into lintHint, or copied into a sandbox, no lint errors are reported. —Bruce1ee^talk 12:30, 24 September 2021 (UTC)

I see Jonesey95 has added back the code template, which now gives 1 multiple unclosed formatting tag and 2 missing end errors. I think we should ignore these errors till the actual cause is found out. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 13:08, 24 September 2021 (UTC)

My revert was unintentional, as was my omission of an edit summary. I was just doing a null edit, and it didn't give me an edit conflict warning. It's a day for bugs. – Jonesey95 (talk) 14:11, 24 September 2021 (UTC)

Sorry y'all! Jonesey95 thanks for the report on mediawiki's Linter help pages. I looked into this, and there is an unintented breakage in Parsoid (probably with the most recent Mediawiki train) where Parsoid leaves behind a stray closing p-tag around extension output (after some change in core) that then later trips up many things, but the most visible effect of which are these many spurious lint errors because of the stray closing p-tag. We'll get this fixed for next week's train. SSastry (WMF) (talk) 14:45, 24 September 2021 (UTC)

Thanks, SSastry (WMF). I wasn't sure whether it warranted a phab ticket or not. We will sit tight for a week. – Jonesey95 (talk) 00:22, 25 September 2021 (UTC)

A week later, we're still getting spurious results, where lintHint doesn't detect errors, but the errors stay in the Page information page. See Multiple unclosed formatting tags. —Anomalocaris (talk) 19:15, 1 October 2021 (UTC)

I'm not sure if it's helpful information, but I'm seeing errors highlighted (briefly, as usual) on each of the pages currently on that list without lintHint. pauli133 (talk) 19:45, 1 October 2021 (UTC)

Replacement for vlink?

Can anyone suggest a replacement for the following: [[User:Tomtheman5|tiZom]][[User talk:Tomtheman5|(2¢)]]. I had not seen a signature with vlink attribute before. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:51, 6 October 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: so not exactly...but I don't think it matters because the inline styling shouldn't be changing based on the visited stated of that username link, so it can likely be removed. Also, the second part of that doesn't seem to even work - so my suggested replacement would be:

[[User:Tomtheman5|<span style="color:#08457E; font-weight:bold;">tiZom</span>]]<sub>[[User talk:Tomtheman5|<span style="color:#000000;">(2¢)</span>]]</sub>

If that vlink state actually was happening, since it appears this is just about color, a !important could be added on the color: declaration, but I don't think it is needed and certainly don't recommend it. — xaosflux ^Talk 15:12, 6 October 2021 (UTC)

@Xaosflux: thanks. On a side note, is there any disadvantage of using ''' or  for bolding, rather than font-weight:bold;? I have been applying style to  since it reduces the length of signature code. Similarly I replace things like [[User:Abc|Abc]] with [[User:Abc|Abc]]. I use span tags only in situations when styling cannot be applied to other tags. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:47, 6 October 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: b tags are still fine, and wikitext with ''' outputs b tags currently, b tags went through several conceptual changes in their life and in general are not used much here on enwiki. Combing elements and avoiding unneeded spans is fine. I don't really want to dive in to the semantic/presentation/structure arguments right now - but volumes can be written on them - in general for things like signatures most users just throw copypasta at it until it looks like what they want on one device, and they don't put in the effort to select specific coding. — xaosflux ^Talk 18:13, 6 October 2021 (UTC)

Unclosed font tags in signature

Blaze The Wolf caught a malformed signature Talk:Roblox/Archive 1 that made all the following text white. We manually fixed it in these edits. Could Linter be expanded to find these types of errors, so bots can go around and fix them? Thanks! GoingBatty (talk) 17:02, 11 October 2021 (UTC)

The version of the page before that problem was fixed had 107 Linter errors, according to LintHint. My experience has been that when there are that many errors, LintHint can't always make sense of the syntax and does not report every single error correctly. The best way to fix a specific error is sometimes to fix all of the errors on a page.

I copied that broken signature into my sandbox, where LintHint detects the missing font tags correctly. – Jonesey95 (talk) 17:16, 11 October 2021 (UTC)

That particular signature appears on just 37 pages, if I am doing a search correctly. An editor with a script or AWB should be able to make quick work of it, fixing eight Linter errors per instance of the signature. – Jonesey95 (talk) 17:18, 11 October 2021 (UTC)

BTW, Blaze The Wolf's edit was close but not quite right: it resulted in misnested font and small tags. You need to have one set of tags on the "outside" and one set on the "inside", like font small ... /small /font, not font small ... /font /small. Linter fixes can be tricky. – Jonesey95 (talk) 17:30, 11 October 2021 (UTC)

Ah ok. I knew the  tag needed to be added somewhere, so I simply just put it in a place that seemed like it would work. Thanks for letting me know what would've been correct. ― Blaze The Wolf^Talk_{Blaze Wolf#6545} 18:35, 11 October 2021 (UTC)

@Jonesey95: Thanks for the info! I presumed that there would be a visible category on the page, and was wrong. It's fun that there's always new things to learn on Wikipedia. Since there were only a small number of fixes needed them all via AWB (with proper nesting). Thanks! GoingBatty (talk) 18:42, 11 October 2021 (UTC)

No, there are no categories for Linter errors. I asked for them in a phab ticket a long time ago, since categories can be very useful for searching, but it wasn't a priority, apparently. You have to use the LintHint script and the pages at Special:LintErrors and the firefly report. At some point, we'll be down from 20 million errors to a few million, at which point it might make sense to ask again for error categories and better ways to prevent new errors from being added to pages. Right now, bots are removing errors from the count on the firefly table at a rate of about a million per month (see discussions above). – Jonesey95 (talk) 19:58, 11 October 2021 (UTC)

If anyone finds Linty signatures, you can add it to User:MalnadachBot/Signature submissions and I will have the bot replace it. Currently I am barely able to stay ahead of the bot. I have approval to fix signatures that give any of the high-priority Lint errors, so they will be fixed quickly. You can also add signatures giving medium and low priority errors be fixed in a future bot task. The bot has fixed over 2 million errors in the last 2 months. I expect the number of high-priority errors will be down to 5 digits by the end of this year. After that I intend to submit a bulk BRFA for signatures giving misnested, missing end and stripped tag errors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:09, 12 October 2021 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: I wanted your bot to make these changes, but your bot page states "For signatures that give medium and low priority errors, they should be present in at least 100 pages", and gave up trying to figure out how to see whether this was a high, medium, or low priority error. GoingBatty (talk) 15:59, 12 October 2021 (UTC)

Yes, it is not always easy to identify the type of error without using LintHint. Special:LintErrors lists the error names according to priority. The whole thing is a bit inaccurate really. Some of the "high" priority ones do not cause a difference in page rendering, whereas some "low" priority ones affect everything in the page after it. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:45, 12 October 2021 (UTC)

The vetting of user signatures

I was under the impression that all current user signatures in Special:Preferences were vetted for lint errors. This current article for deletion has two signatures with obsolete HTML tags, and I have seen others. It would help hugely if current signatures could be vetted. —Bruce1ee^talk 11:51, 3 November 2021 (UTC)

If you try to change your signature to something that contains errors, then yes, it will get flagged. However, most of the error-inducing signatures haven't changed in years (sometimes decades) before the error check was put into place. Primefac (talk) 12:26, 3 November 2021 (UTC)

Adding to that: obsolete tags are intentionally allowed when saving a signature, see mw:New requirements for user signatures § Outcome. They could be disallowed using a MediaWiki setting, $wgSignatureAllowedLintErrors. You can try to obtain consensus for changing it locally. Rummskartoffel 12:57, 3 November 2021 (UTC)

You can see a report of editors with invalid signatures who have contributed ~~to a discussion page in the last 90~~ in the last 30 days. A few of us have been notifying editors with Linter errors in their signatures and asking them to change their sigs, with some success. Invalid signatures are allowed to remain in effect, but editors can't save a new custom signature with Linter errors (except obsolete tags, of course). We'll be cleaning up font tags forever. [ETA: the report appears to have regressed to a previous state. It should be showing what is in the struck text above.] – Jonesey95 (talk) 16:47, 3 November 2021 (UTC)

Thanks everyone for your responses. They have been very helpful. —Bruce1ee^talk 17:08, 3 November 2021 (UTC)

Missing end tag report

The report at Wikipedia:CHECKWIKI/WPC_551_dump, updated monthly, has a long list of articles with at least one or two missing end tag errors, typically stray bold or italic markup, or bold/italic markup that is mistakenly wrapped one line below where it should go. Someone better with tools than I am might be able to use a script or AWB to make a run through this list to either remove the stray markup or remove line breaks, as needed. – Jonesey95 (talk) 21:09, 3 November 2021 (UTC)

Discussion of redirect at Template:Br

Some of you may have run into editors inserting {{Br}} (a redirect to {{Clear}}) and thereby causing (div inside of span) Linter errors. I have started a discussion about this redirect at Wikipedia:Redirects for discussion/Log/2021 December 24#Template:Br. I obviously have an opinion on the matter, but I am attempting to keep this notification neutral. If you can think of other good places to post a link to that discussion, please do so. – Jonesey95 (talk) 00:43, 29 December 2021 (UTC)

Linter slow

The Linter used to update almost immediately on publishing changes to a page. Now it's taking at least hours in many cases. —Anomalocaris (talk) 06:07, 16 January 2022 (UTC)

Someone else reported that as well, I've filed phab:T299302 to track it specifically. Legoktm (talk) 08:00, 16 January 2022 (UTC)

Yes there was a spike in submission of linter jobs after the latest release, resulting in a backlog of about 9 million jobs. We've raised the concurrency of the job temporarily to confront the increased backlog, which should be emptied in about 6 hours. Sorry for the inconvenience. GLavagetto (WMF) (talk) 08:38, 16 January 2022 (UTC)

Possible false positive in table parsing

Of note: VPT thread about a possible false positive in table parsing. This is causing new errors to be detected at List of Caltrain stations, Template:Wikinews/doc, and other pages. I do not think these are real errors. – Jonesey95 (talk) 14:20, 16 January 2022 (UTC)

Bogus file options false positive?

[[File:Apollonian_gasket_symmetrical_3.svg|thumb|OK at 200px]] (from Wikipedia:SVG help/Archive 7) generates a "Bogus file options" lint error. Replacing "px" with "pixels" clears it, but is this a false positive? —Bruce1ee ^talk 09:07, 15 January 2022 (UTC)

@Bruce1ee Yes, this is a known issue with the linter. See phab:T276675. the wub "?!" 10:23, 15 January 2022 (UTC)

Thanks. I've changed the picture capition to "OK at 200 pixels". —Bruce1ee ^talk 10:27, 15 January 2022 (UTC)

This is noted on the Help page, along with a workaround: To work around a false positive error when "px" is at the end of a caption, add {{sp}} after "px". It will add a space, which does not change the displayed caption but which makes the error go away. – Jonesey95 (talk) 14:20, 15 January 2022 (UTC)

@Jonesey95: Sorry, I should have checked the help page first for known bugs and workarounds.

That's an example of "Two captions". Feel free to improve the help page if it is confusing. Also, I'll give you a cookie if you can figure out which tool is causing this "file name as an extra caption" problem. I have seen tons of them, by many different editors, so I think it is being done by some toolbar button or other semi-automated tool. – Jonesey95 (talk) 15:43, 15 January 2022 (UTC)

I've tried all the editor toolbars I can find, including Visual Editor, and none of the "add file" buttons use the file name as a caption – they all prompt the editor for the caption and alt text. Semi-automated tools generally use predefined edit summaries, and I've checked some of the edits that do this (for example here), but none of them have any edit summaries at all. I can't see why the editor would want to repeat the file name, unless they have seen it done elsewhere and assume that that is how it's done. —Bruce1ee ^talk 06:54, 18 January 2022 (UTC)

Special:LintErrors/inline-media-caption

It looks like the Friday software update came with a surprise: Special:LintErrors/inline-media-caption, which is for some reason listed as a high-priority Linter error, even though it is unclear what part of a page is broken when this condition exists. The not very helpful Help page is at mw:Help:Lint errors/inline-media-caption. Its recommendation to place a caption in the alt "parameter" is curious and is certainly not always the best resolution (making the caption display on the page is probably a better resolution in some cases).

Before people jump in and start "fixing" these conditions (I hesitate to call them errors), we should probably discuss them here. Links to phab tickets or other discussions are welcome. – Jonesey95 (talk) 05:06, 14 January 2022 (UTC)

Follow-up: I found T297443 by stumbling around. At this point, this change looks like it was implemented by a single developer. There were no other contributors to the phab ticket, as far as I can tell. I wish I could get someone with this sort of influence to actually fix some of the Linter bugs instead of working on random ideas. – Jonesey95 (talk) 05:17, 14 January 2022 (UTC)

That seems like a pretty unfair characterization about what happened. If you read the linked Phab tickets from that task (e.g. T50958#534409), you'll see that this has been discussed as early as 2013 and is a spot of divergence between Parsoid and the PHP parser, which is what the main focus is these days, it's not a "random idea". I do agree it would be good if it was in Tech News, etc. as was the plan on the task, but I don't think it's a big deal if it gets announced a week later.

As for the issue itself, AIUI the problem is that for inline images, the "caption" is not actually displayed as a caption, rather it ends up being used as the alt text as a fallback. This is "high" priority because Parsoid does not have the same fallback, it only adds alt text if it is explicitly specified as such. So having that text be present using the caption syntax is wrong (similar to bogus media options IMO), and it should either explicitly be the alt text via |alt=, or it should be dropped and proper alt text be added. Or, as you said, the image should be rendered in a non-inline fashion. Legoktm (talk) 05:45, 14 January 2022 (UTC)

This change should be reverted and then discussed. Using a caption in this way is a documented feature, per MediaWiki's own documentation at mw:Help:Images: Caption text shows below the image in thumb and frame formats, or as tooltip text in any other format. The originally recommended "fix" breaks the tooltip. Using a caption as alt text is also specifically recommended, with an example, at Wikipedia:Manual_of_Style/Icons#Remember accessibility for people with visual impairment. We need a discussion before this sort of usage, which has been recommended and depended upon for years, is deprecated. – Jonesey95 (talk) 15:19, 14 January 2022 (UTC)

Well MalnadachBot and WOSlinkerBot had brought down the number of high priority errors down from 2.4 million in last May to 130k last week. Now this will probably kick the numbers up to millions again.

Pinging Firefly, would be useful to have a new column to track this in the Linter table. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:58, 14 January 2022 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ of course, will do :) firefly ( t · c ) 08:07, 14 January 2022 (UTC)

I don't think "problem" would be fixed by just changing captions to alt text. The value set by the caption is shown as a tooltip when the mouse pointer hovers over an image. Moving this to the alt text would loose this feature. Also, not all the values set to a caption are suitable to be directly used as alt text and may need tweaking. Captions could be dupliated into the alt text value, but again, that still depends on what the caption says, so could only be done by bot for very specific values. Caption:

, Alt:

. -- WOSlinker (talk) 09:59, 14 January 2022 (UTC)

This Linter error should be marked as "low-priority", not "high-priority". In most cases, I have adjusted the woeful help text at mw:Help:Lint errors/inline-media-caption to suggest the addition of alt text instead of conversion of a caption to alt text. I have also added a possible bug to the phab ticket and again requested reversion of this change while further testing and discussion happens. – Jonesey95 (talk) 15:37, 14 January 2022 (UTC)

I see that this has been removed from Special:LintErrors. Help:Lint errors/inline-media-caption states "This new (January 2022) Linter error has been withdrawn. A revert of its implementation has been requested at task T297443." —Bruce1ee ^talk 09:38, 18 January 2022 (UTC)

... although "Inline media with captions" errors are still showing up in articles. See Amia (fish)‎, for example. —Bruce1ee ^talk 13:56, 18 January 2022 (UTC)

As usual, the developers do not see the world in the same way that editors and readers do. I believe that "withdrawn" in this case means that someone has submitted a change to the main MediaWiki software, which will roll out on a regular schedule (possibly late Thursday) as part of the software update process. From the developers' perspective, the fix is complete, but of course, from the editor/reader perspective, it hasn't been fixed yet. We'll see what the world looks like on Friday.

I do hope that if the developers want to implement this tracking in some way, that they ask for help from actual editors who deal with these sorts of problems. I offered in that Phab task to participate in any such discussions. – Jonesey95 (talk) 14:08, 18 January 2022 (UTC)

This linter category was disabled this morning. This (a) stops accumulating new lints of this type (b) removes the category from display. But, it doesn't remove existing lints which will show up in any other queries that request all lints on a page. Those will clear out gradually after this week's train rolls out unless we purge the database explicitly. SSastry (WMF) (talk) 14:22, 18 January 2022 (UTC)

As for this, we'll first revisit what we were trying to accomplish here and if we decide to introduce a new lint, we'll provide you all a heads up about it so we can talk through it. SSastry (WMF) (talk) 14:22, 18 January 2022 (UTC)

Thanks. Definitely get in touch if you decide to move forward. Since there are millions of potentially affected pages, and there is long-standing documentation specifically saying to use the syntax that the Linter error was detecting, it would be useful to have some discussion about how to proceed, including whether to track this condition (I hesitate to call it an error) using Linter or categories. – Jonesey95 (talk) 15:13, 18 January 2022 (UTC)

Multiline table in list

I recently had some issues with multiline table in list lint. I fixed the problem moving the tables outside the list, but I would like the previous code to work too, making possible to have tables inside lists without generating lint errors. What can I do? —Est. 2021 (talk · contribs) 16:56, 19 January 2022 (UTC)

Blockquote proposal could result in more linter errors

Hi, subsequent to HTML spec change on how blockquotes should be structured, I've prepared Template:Blockquote/sandbox to bring the template to spec. One issue, I think the linter is missing nesting errors e.g. {{blockquote}} with the current blockquote template, but will start catching those same errors with the sandbox template. That would result in an apparent increase in linter errors. See Template talk:Blockquote#Attribution outside blockquote element. Matt Fitzpatrick (talk) 04:14, 24 January 2022 (UTC)

How many instances of that are there? Isn't that already a violation of MOS in most circumstances? pauli133 (talk) 12:03, 24 January 2022 (UTC)

Please respond at the linked discussion to avoid a talk fork. – Jonesey95 (talk) 18:11, 24 January 2022 (UTC)

Cross-post: bots editing concern

There is a discussion at BOTN about a bot editing to remove font tags and other linter errors. Your input would be appreciated. Primefac (talk) 16:08, 28 January 2022 (UTC)

Bogus file option "-nanpx"

This file option appears to be generated by Module:Main page image which Jonesey95 reported here. My question is, what must be done with existing "-nanpx" lint errors? The project namespace has dozens of them. Should "-nanpx" simply be removed, for example in Wikipedia:Main Page history/2022 February 11b? On some of the pages, like Wikipedia:Selected anniversaries/February 11, I can find "-nanpx" if I expand the templates, but I can't see where to remove it. —Bruce1ee ^talk 10:56, 15 February 2022 (UTC)

Yes it should be removed. This is likely the audio clips, where width calculation fails because audio doesn't have an inherent width/height of the original file. In that case just have the Module fallback to the requested/desired/default width, instead of casting the NaN of the calculation to string. —TheDJ (talk • contribs) 11:20, 15 February 2022 (UTC)

if not page.file.width > 0 or not page.height > 0 then use default —TheDJ (talk • contribs) 11:24, 15 February 2022 (UTC)

@TheDJ: Thanks, I'll remove it where I can. —Bruce1ee ^talk 12:48, 15 February 2022 (UTC)

I've fixed the Main_page_image template to output frameless for the size instead of -nanpx. -- WOSlinker (talk) 11:44, 15 February 2022 (UTC)

@WOSlinker: Thanks for the fix. Hopefully that will stop it recurring. —Bruce1ee ^talk 12:48, 15 February 2022 (UTC)

Bogus Misnested tags from Template:AFC submission

Every day, I would estimate, the Linter is detecting and reporting 10 or more new Misnested tags in the Draft namespace allegedly involving  and associated with {{AFC submission}}. Editing any such draft and running lintHint, the error does not exist. Saving with any actual change causes the bogus lint error to go away. (As of 15 February 2023^[update] articles of the form "Draft:List of sovereign states in (year)" have actual misnested tags.)

Also, for more than a year now, a null edit usually triggered an immediate Linter review of any page, but for the past couple of weeks, null edits have not triggered an immediate Linter review; to get that one has to make an actual change to the article, even if just a white space adjustment in markup. —Anomalocaris (talk) 04:38, 15 February 2022 (UTC)

Not bogus is my assessment. The one at Draft:Danny Dimian appears to be caused by the username *Treker, which no doubt causes problems in other places as well. Doing a dummy edit (for example, adding a space) changes the REVISIONUSER from one that starts with an asterisk to a non-degenerate username, presumably fixing the problem. – Jonesey95 (talk) 05:51, 15 February 2022 (UTC)

Great work, Jonesey95! So, if this username causes problems with {{AFC submission}}, and possibly other templates, such affected templates should be modified to accept usernames starting with asterisk without causing lint errors. There appear to be hundreds of usernames that start with asterisk and we can't ask all these users to change their usernames. —Anomalocaris (talk) 09:38, 15 February 2022 (UTC)

I have seen some glitches related to usernames as well. If you see this search, one of the results is User talk:Assert(false); Clicking it says the user is not registered on this wiki. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:09, 15 February 2022 (UTC)

Ugly. I have started a discussion at WT:Username policy. – Jonesey95 (talk) 19:27, 15 February 2022 (UTC)

Bogus detection of missing end tag with apostrophe bold markup

Template:ClinicalStudyInfo has a bogus detection of two missing end tags for bold. If one replaces the first set of three apostrophes with  and the second set of three apostrophes with , the lint errors go away. I've checked 9 of the 14 pages that transclude this template, and none of those 9 have any lint errors. Something is messed up. —Anomalocaris (talk) 06:41, 9 February 2022 (UTC)

I'm hesitant to mess with it (I'm not operating at 100% right now), but it looks like the current bold tags are covering two consecutive calls of template:switch. Perhaps they can be tagged separately? pauli133 (talk) 12:55, 9 February 2022 (UTC)

I played with this one a while ago. I think that the Linter parser perceives a new line somewhere, but it does not render. The false positive could probably be resolved by putting the whole switch statement on one line, but that would be ugly. There are a few dozen template pages with apparent false positives like this (about 60 missing end tag errors and 100 stripped tag errors). As far as I know, I have looked at all of them, and they do not cause any problems in articles, and there are no article pages with the same sort of false positive. I have left them alone to focus on real errors. If we ever get the Linter error table cleaned off, we may want to submit this as a bug. – Jonesey95 (talk) 15:02, 9 February 2022 (UTC)

"If we ever get the Linter error table cleaned off": Now that Show preview is providing warnings of various errors in the cite templates, it's also getting to be time for Show preview to provide warnings of lint errors, perhaps starting with only high-priority lint errors. —Anomalocaris (talk) 08:59, 16 February 2022 (UTC)

Possible new false positives in template space

The following template pages appeared in the "Stripped tag" report for templates in the last couple of days, despite not having been modified. They all have complex tag wikitext, and my guess is that some change in the MediaWiki Lint error detection code has put them on the list by mistake.

{{Anontools}}
{{Anontools/sandbox}}
{{Hover title}}
{{Hover title/sandbox}}
{{Oldid2}}
{{WPBannerMeta/hooks/bchecklist/syntax}}

I don't see anything to fix, but before I report this as a bug, does anyone have any ideas about what might be going on here? – Jonesey95 (talk) 19:58, 20 February 2022 (UTC)

Some lint is giving me a hard time

See User:Chicdat/permalint. 🐔dat (talk) 11:40, 5 March 2022 (UTC)

Those have all been fixed for you. If you do not yet have the syntax highlighter gadget enabled, I recommend it. It can help you find tricky errors like these. – Jonesey95 (talk) 15:46, 5 March 2022 (UTC)

21 million errors, and headed down

For what it's worth, the firefly table currently shows just under 21,000,000 total errors, down from 22 million a month or two ago. Some great bot work by a few different bots has brought this number down recently. We are also just under 400,000 total errors in article space, a number that is also declining slowly. If you are interested in working in article space, User:Galobot/report/Articles by Lint Errors provides a good place to make a dent in the count; it includes all errors except obsolete tags. Note that most of the articles with an error count above 5 are there because of templates that need rethinking.

Also note that the 21 million figure is an undercount, because Linter maxes out at 21 of any given category of error per page. If a page has 65 font tags and 47 stripped tags, it will show only 21+21=42 errors in this report. – Jonesey95 (talk) 15:39, 13 September 2021 (UTC)

More than half of the remaining article space Lint is because of obsolete center tags. There are articles with more than thousand center tags like this. Trying to replace them manually is too tedious, you have to use scripts to make the job easier. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 16:30, 13 September 2021 (UTC)

I've used the Regex editor template script in edit mode to do bulk center tag replacement within an article. Search for /<center>/g and replace with {{center|, then search for /<\/center>/g and replace with }}. —Bruce1ee^talk 17:14, 13 September 2021 (UTC)

Unfortunately, that is not a cure-all. If the center tag is used to center a table, or an image, or other non-text stuff, the center template (or the equivalent set of div tags) does not always work. – Jonesey95 (talk) 19:55, 13 September 2021 (UTC)

Thanks, I'll watch out for that. I do always check where the center tag is used in the article before doing a search-and-replace. —Bruce1ee^talk 20:34, 13 September 2021 (UTC)

Also, when a table cell is centered:

it's best to change <center>table cell</center> to style="text-align:center" | table cell
also change bgcolor="color" to style="background:color" (sometimes the quotes around the bgcolor are missing; also # before hexadecimals is optional with bgcolor and mandatory with style markup)
such centering and background color style markup should be merged with each other and with any existing style markup

—Anomalocaris (talk) 01:25, 20 September 2021 (UTC)

As of this time stamp, we are just under 20 million errors. Good job, bots and gnomes! – Jonesey95 (talk) 14:59, 5 October 2021 (UTC)

19 million errors as of this time stamp, 23 days after 20 million. It took us 22 days to get the previous million, so the pace continues to be steady. If someone is willing to set up a bot to fix the easiest of the obsolete font tags (font tags with supported CSS colors or six-character hex codes wrapping plain text, for example), it could make a huge dent in the total error count while we humans work on the tricky errors. – Jonesey95 (talk) 15:58, 28 October 2021 (UTC)

It's on my bot task to-do list, but won't be able to get there for 6 months at least. There are lots of more important errors that can be fixed by bot. It is worth more to replace signatures giving misnested, missing end and stripped tag errors. Or even tt tags since they do not work in mobile. I am not aware of any device in which font tag doesn't work. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 18:12, 28 October 2021 (UTC)

Below 18 million at this time stamp. – Jonesey95 (talk) 03:49, 5 December 2021 (UTC)

Note that most of the articles with an error count above 5 are there because of templates that need rethinking is there a list of the problematic templates? If so, I can try and fix some of those. Gonnym (talk) 15:45, 5 December 2021 (UTC)

That statement is no longer true after a few template fixes like this in late September. At this time, anything with a count higher than 4 is there because of a change made since the previous report. – Jonesey95 (talk) 16:34, 5 December 2021 (UTC)

We are down to 17 million now. Also a note to a wider audience that my bot now has approval to fix any Lint error without having to go through separate BRFAs. Just add anything you want done to User:MalnadachBot/Signature submissions and I will process them. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 08:04, 21 January 2022 (UTC)

Under 16 million as of this time stamp. MalnadachBot has been working away at hundreds of thousands of pages with "low priority" errors, and human editors are making slow but consistent headway on article space (under 342,000 errors as of this time stamp). – Jonesey95 (talk) 17:34, 18 February 2022 (UTC)

Under 15 million errors as of this time stamp, just 18 days after reaching 16 million. There are 328,000 errors in article space. – Jonesey95 (talk) 15:35, 8 March 2022 (UTC)

There were 338,000 errors in article space on 1 March, and 435,000 last June. So we've fixed almost 12,000 errors per month^[a] in the last 9 months, and 10,000 errors in the last week or so. That's some good progress! From looking at Galobot's report, we're well on our way to fixing all articles with 3 or more lint errors.^[b] --rchard2scout (talk) 09:21, 10 March 2022 (UTC)

Galobot's report does not include obsolete tags. I estimate there are several thousand articles with more than 50 center tags. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:35, 10 March 2022 (UTC)

Notes

^ (435,000-328,000)/9
^ They're alphabetical, and we can already see up to V

Obsolete signature font tag

Hello! I noticed that usually whenever someone's signature uses obsolete font tags, when someone else comes along and fixes them, the user is never actually notified so there's no way they could know their signature uses obsolete font tags that need fixing, meaning they won't actually know they need to fix it until they either happen to notice the edit someone made to their signature or someone notifies them on their talk page. An easy solution would be to simply just mention the user who's signature has lint errors in the edit summary that fixes said lint errors. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 20:47, 16 March 2022 (UTC)

If someone chooses to do this, please ensure that the editor's current signature still has font tags in it. You can see an editor's current signature using this tool. Here's an example of the output, showing that an editor's current signature (as of this writing) uses obsolete font tags.

T248632 implemented changes to the custom signature save process to prevent Linter errors in newly saved signatures, but obsolete tags, frustratingly, were excluded from the scope of those checks. – Jonesey95 (talk) 20:54, 16 March 2022 (UTC)

Blaze Wolf: When I find a lint error in a recent signature, I check to see if the user's current signature still has lint, and if so I go to the user's talk page and let them know and offer a workaround, for example. My message does, unfortunately, repeat the lint error(s) one more time, but it's the only way to show that the replacement signature matches exactly. —Anomalocaris (talk) 22:50, 16 March 2022 (UTC)

@Anomalocaris: WOuld you mind explaining what you mean by "It's the only way to show that the replacement signature matches exactly"? I'm not exactly all that familiar with how this works. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 22:57, 16 March 2022 (UTC)

Blaze Wolf: Click my for example link and see how I provided a replacement signature string. In order to show that the original string and the replacement string generate the same signature, I have to use the original linty signature string one more time. —Anomalocaris (talk) 23:01, 16 March 2022 (UTC)

@Anomalocaris: The thing I"m struggling to understand is how the replacement signature would look different than the original signature with the lint error. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 23:13, 16 March 2022 (UTC)

Blaze Wolf: My purpose is to provide a signature that looks exactly the same, but without any lint errors. —Anomalocaris (talk) 02:35, 17 March 2022 (UTC)

Using AWB to replace <center> with align=center

I was wondering which AWB replacement pattern would be able to replace <center> with style="text-align:center" or {{center}}, for that matter, to remove as much of said lint error as possible, thereby reducing the backlog of 34.000+ hits in "search". Qwerty284651 (talk) 09:39, 17 March 2022 (UTC)

If your entire reason for replacing one value with another is to make searching easier, then "no". If there are practical or technical reasons, that can probably be discussed. Primefac (talk) 09:43, 17 March 2022 (UTC)

@Primefac: My point was to remove as much as of the lingering <center> deprecated tags in wikipedia articles as possible using AWB. I linked the result to show how many pages still have/use the obsolete markup. That's my goal, not to alleviate searching. Can you help me out replace the tag with style="text-align:center"? Qwerty284651 (talk) 09:51, 17 March 2022 (UTC)

Yes, which is what I realised and why I removed my comment, because it was an incorrect statement. Could you just remove it again please? Primefac (talk) 09:52, 17 March 2022 (UTC)

Yeah, an edit conflict with my version restored your comment unintentionally. Why remove it? It's no big deal. Qwerty284651 (talk) 09:55, 17 March 2022 (UTC)

It's not always possible to just do a search and replace with one method. As mentioned at Wikipedia:HTML5#center, there are a few options depending on context. Also, with tables that have a lot of cells center aligned then it may be better to set the whole table style to text-align:center and then use styles of text-align:left or text-align:right against a few cells that don't want center aligning. -- WOSlinker (talk) 10:20, 17 March 2022 (UTC)

@WOSlinker, and how does one do that exactly? Qwerty284651 (talk) 10:37, 17 March 2022 (UTC)

Not sure of all the options as I don't use AWB. But one thing you could do is refine the search to look for center in certain contexts and then just start with those replacements. For example simple text wrapped in center tags. -- WOSlinker (talk) 10:43, 17 March 2022 (UTC)

@Qwerty284651: If you are going to do this from your main account, you are likely to get complaints that these are against WP:AWBRULES point 4. I replace center tags using javascript script, you can see User:ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ/center.js for some of the replacements I use. align=center is obsolete in HTML5 too, though it does not create a Lint error. Better to use the various options listed at Wikipedia:HTML 5#center. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:49, 17 March 2022 (UTC)

Fixing a lint error would be an exception to that. Primefac (talk) 10:53, 17 March 2022 (UTC)

Yes, I was saying that people would say it is insignificant anyway as it is not explicitly mentioned as an exception. Qwerty284651 should be aware that. I have had some people complian about font tag replacements by MalnadachBot in discussion pages even though it is policy compliant. Linting article space using AWB from a non-bot account will surely get more attention from users. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 11:25, 17 March 2022 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ: How about replacing the enclosed markup tags <center> and </center> with style="text-align:center" or {{center}} instead of with the deprecated align=center? Would that make things anything easier and compliant with the policies? Qwerty284651 (talk) 11:59, 17 March 2022 (UTC)

You are welcome to copy any of the regex replacements I have set up at User:Jonesey95/AutoEd/coauthors.js (ignore the strange name of the script). Some will quibble and say that for table cells, I should use "style" instead, but {{center}} gets the job done reliably. My script could be better, but I have been careful to limit it to avoid false positives. Since I started using it, I have done a few hundred edits with zero false positives, as far as I know. It does not center tables or other multi-line objects, just strings of text on a single line. – Jonesey95 (talk) 14:05, 17 March 2022 (UTC)

@Jonesey95 Do you have a similar setup for replacing align=center| with style="text-align:center", given the former is mostly used in data cells in tables and charts? Qwerty284651 (talk) 16:36, 17 March 2022 (UTC)

No, since that construction does not (yet) cause Linter errors. – Jonesey95 (talk) 16:49, 17 March 2022 (UTC)

Just using AWB to make mass edits that does not make a difference in page rendering will cause some people to complain, it doesn't matter to them what it is replaced with. style="text-align:center;" and {{center}} are indeed better than align=center. <center>...</center> tags do not have a one-size-fits-all replacement. Here is an example of various ways center tags are used in articles and how to replace them. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 14:28, 17 March 2022 (UTC)

@ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ I discovered a couple of new variations of valid center tags by looking at your examples, that I haven't heard of before. Can you upon getting a hit from AWB during search of the <center> check what kind of markup it's being used in, i.e. gallery, table, template? Qwerty284651 (talk) 16:43, 17 March 2022 (UTC)

Yes, you can use regexes to Find and replace center tags used in different contexts. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:58, 17 March 2022 (UTC)

Lint detection delay

The linter is detecting some lint errors many years late. For example, today there was a new detection of Multiple unclosed formatting tags in Talk:Project Blue beam caused by <big>...<big>. This talk page was created more than 8 years ago, 19 January 2014, and never edited again until I fixed the lint error today. How long before every page is checked? —Anomalocaris (talk) 23:02, 16 March 2022 (UTC)

Earlier today a new batch of lint errors popped up on File talk pages that hadn't been edited for many years. For example File talk:Blazing Angel Jet Dragster.jpg and File talk:Cat03.jpg. —Bruce1ee ^talk 23:17, 16 March 2022 (UTC)

These events are probably related to this VPT discussion, which resulted in an editor starting to run a null-edit bot on millions of pages that had not been refreshed for many years. The need for this localized null-editing is due to a long-standing problem report that the Wikimedia developers have not prioritized. There are links to the relevant phabricator tasks in that discussion. You should expect to see more "new" Linter errors popping up over the next few months, assuming that this editor continues their helpful null editing. – Jonesey95 (talk) 23:33, 16 March 2022 (UTC)

It appears that the bot is going through untouched pages in the User space right now, in alphabetical order. About ten pages starting with "C" and "D" appeared in previously empty Linter categories like "Unclosed quote in heading" in the past few hours. Expect more. The bot has processed about one-third of three million pages so far. – Jonesey95 (talk) 05:57, 18 March 2022 (UTC)

Thanks for that. I guess we'll just have to deal with these "new" errors as they come. Where the sudden increase is particularly noticeable is in cells in the firefly report that are usually empty (like "Missing end tags" in the Category talk namespace). —Bruce1ee ^talk 09:35, 18 March 2022 (UTC)

CommonsDelinker generating Bogus file option lint errors

CommonsDelinker sometimes generates Bogus file option lint errors when it removes files from picture galleries. It breaks the picture caption of the preceding file in the gallery. See for example here and here. Sometimes it doesn't generate lint errors, but leaves behind the caption of the file it removed, for example here. This was reported at Bitbucket five days ago, but the bot is still misbehaving. —Bruce1ee ^talk 07:48, 19 March 2022 (UTC)

Suggest that the bot provide an edit summary, especially when editing an article

Suggest that the bot provide an edit summary on why it made a change, especially when editing an article. Given the quantity of different reasons bundled in the tool, "fix lint errors" says absolutely nothing. Sincerely, North8000 (talk) 17:14, 21 March 2022 (UTC)

Obsolete center tag question

Template:Onychophora has five obsolete center tags, but I can't work out how to replace them and preserve the template appearance. What is particular puzzling is that if I simply remove the center tags, three of the items remain centered, but two of them (Peripatidae and Neopatida) are not. Yet the markup for all five is identical. —Bruce1ee ^talk 08:06, 24 March 2022 (UTC)

The issue was with the margins, by setting it to -40px for the two mentioned was shunting them beyond the space given by the navbox. I've tweaked a few of those values and it seems to be appearing reasonably well now. Primefac (talk) 08:29, 24 March 2022 (UTC)

@Primefac: Thanks for that, I didn't think of adjusting the margins. Is there no way to replace center tags with HTML5 compliant code in template navboxes? —Bruce1ee ^talk 09:31, 24 March 2022 (UTC)

Pretty sure you can chuck the centring into the  itself, but I'm not awake enough to remember the specific syntax. Primefac (talk) 09:42, 24 March 2022 (UTC)

The problem is that the center tag did two things:

Center align all contents
Center align itself

In modern html this is split into two different behaviours. And worse, depending on if it is text or another element, even those two new behaviours have to be targeted differently. So the problem is not that it cannot be done, the way to do it is just different and depending upon the content and some of those contents can have different overrides etc etc etc. —TheDJ (talk • contribs) 10:49, 24 March 2022 (UTC)

Thanks, I see what the problem is. —Bruce1ee ^talk 11:26, 24 March 2022 (UTC)

Tidy font-link bug false negatives

Tracked in Phabricator
Task T294720

All 5 signatures listed here exhibit behaviour which is tracked by Special:LintErrors/tidy-font-bug. i.e they have a font tag with color attribute outside link and the link color does not change as intended. But Linter is not detecting them as the high priority font-link bug, it is detecting only the low priority obsolete html tag error. From the examples it seems Linter gives false negatives when their is font tag with style color outside link, font tag with color attribute wraps multiple links, and when it wraps both link and plaintext/whitespace/other html tags. Also a signature like [[User:abc|abc]] has the same behaviour as font-link bug, but it not detected as a Lint error at all. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:31, 30 March 2022 (UTC)

I have already reported some of these at T294720, opened in October 2021. I have added a link to a few more of these cases to that ticket. I don't think there is anything else to do here. Since your bot is fixing obsolete font tags, this sort of error can go into its queue and get processed at some point. – Jonesey95 (talk) 19:39, 30 March 2022 (UTC)

Something's wrong with Linter

The Linter tool is reporting lint errors on several articles, including Wyandotte Terminal Railroad, Muhsin al-Ramli, 2012 Georgia Force season, Shtil', and Auiones. However, I have fixed all errors on those pages, and LintHint agrees. Is there a glitch? 🇺🇦 Chicdat ^{Bawk to me!} 11:38, 27 April 2022 (UTC)

Agreed. {{User interest South Dakota}} and similar templates show two Linter errors in their Page information, presumably due to a page move of a transcluded template that happened about 12 hours ago, but no amount of null-editing fixes the Page information display. LintHint correctly shows that there are no errors on the page. We may just have to wait for some process to catch up. – Jonesey95 (talk) 13:25, 27 April 2022 (UTC)

This appears to have been fixed, at least in Template space. – Jonesey95 (talk) 16:34, 27 April 2022 (UTC)

Also fixed in article space. 🇺🇦 Chicdat ^{Bawk to me!} 09:56, 28 April 2022 (UTC)

Bogus file options and {{Largethumb}}

Well over 1,000 {{Largethumb}} file option lint errors have appeared in the article namespace. Replacing "{{Largethumb}}" with "thumb" removes the lint errors with no change to the picture size on the page, regardless of whether a pixel-size is specified or not. {{Largethumb}} has been nominated for deletion, and clearly, if it is deleted, it will have to be replaced with something where it is used as a File/Image option.

This seems to me to be an ideal candidate for a bot task or AWB to replace "{{[Ll]argethumb}}" with "thumb". The trick is to ensure that the replacement only occurs when the template is used as a file/image option. —Bruce1ee ^talk 09:58, 30 April 2022 (UTC)

It was causing Lint errors because of the TFD notice. I have wrapped it in noinclude tags, which has removed Lint errors in transcluded pages. If the template gets deleted, TFD bots will replace it with something suitable. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 10:29, 30 April 2022 (UTC)

Oh, is that what it was! So replacing {{Largethumb}} with thumb wasn't necessary. Thanks for the fix. —Bruce1ee ^talk 10:37, 30 April 2022 (UTC)

Should we add obsolete tags to Galobot's report?

Way back in 2018 when I requested that Galobot's Linter report be created, I asked for obsolete tags to be ignored in the report because they were not doing any harm to articles. At that time, there were thousands of articles with at least 42 errors (the maximum official count for any type of error is 21), so there were plenty of real errors to fix. A few days from now, thanks to the diligent work of many gnomes, the report will be limited to all articles with more than two errors, as reported in Page Information (which is sometimes wrong, but that's another story).

Should we ask for the report to be modified to show obsolete tags, now that those present the most significant opportunity to reduce error counts in article space? More than 99% of the obsolete tags, as far as I know, are <center>...</center> tags; gnomes have fixed nearly all <tt>...</tt> and ... and <strike>...</strike> tags in article space. – Jonesey95 (talk) 14:57, 10 March 2022 (UTC)

On the one hand, I want to say yes, it's probably time to start fixing those tags too. On the other hand, I now use the report daily to fix articles that have recently gotten a lot of lint errors, so that they can be fixed early. This also helps in finding and reverting vandalism. Maybe we could have two separate reports? --rchard2scout (talk) 16:09, 10 March 2022 (UTC)

Agree, a separate version of the report with just the obsolete tags in it would be better. Here's a query example. Also, here's a query without center example. -- WOSlinker (talk) 21:52, 10 March 2022 (UTC)

WOSlinker, can you turn that page into a report, or dump the list into my sandbox? I can start working on that list; I've been working for a while from custom searches that turn up trivial-to-fix patterns. I'm actually happy to see that there are thousands of articles with 20+ obsolete tag errors, since that means that a few thousand edits will reduce the error count by tens of thousands. – Jonesey95 (talk) 02:38, 11 March 2022 (UTC)

Jonesey95, I've added all the 21 center lint to User:WOSlinker/lint_center_obsolete. -- WOSlinker (talk) 08:25, 11 March 2022 (UTC)

By the way, I recently created {{la4}}, so that it's easy to immediately go to the edit page. It saves me a click per page when working through User:Rchard2scout/linterrors (which is essentially the same data as Galobot's report). --rchard2scout (talk) 15:01, 11 March 2022 (UTC)

That looks useful; I'll try it on a list of pages. It should probably have a more descriptive name. – Jonesey95 (talk) 17:22, 11 March 2022 (UTC)

It probably should, I just named it after {{la}}, and {{la2}} and {{la3}} were already taken. --rchard2scout (talk) 09:24, 15 March 2022 (UTC)

Indeed, there are a bunch of templates like this that could use a more expanded/descriptive name. Primefac (talk) 09:37, 15 March 2022 (UTC)

I've BOLDly moved {{la4}} to {{Link to edit}}, with the short name kept as a redirect. So this is what they call "leading by example"? rchard2scout (talk) 10:58, 15 March 2022 (UTC)

Hah! Being bold is so far the only way I've managed to get these sorts of changes through; everything else gets shot down... Primefac (talk) 11:45, 15 March 2022 (UTC)

@Jonesey95, WOSlinker, and Rchard2scout: There's now User:Galobot/report/Articles by Obsolete Tags and I made the bot use {{Link to edit}}. Let me know if there's other stuff that can be done to make the report more useful; for the next while I should have the time to make some updates to how the report is generated. Galobtter (pingó mió) 02:43, 23 May 2022 (UTC)

Thanks! I will definitely use that report. I have been slowly chipping away at the pages with 20+ center tags, fixing maybe 100 pages per week. Maybe this report will motivate me to do a few more. – Jonesey95 (talk) 03:48, 23 May 2022 (UTC)

Stupid question: why is 21 the maximum error count limit? This report would be even more useful if it could include articles with > 21 obsolete tags. —Bruce1ee ^talk 07:32, 23 May 2022 (UTC)

Because over a certain number, it's apparently not worth counting. The report does include articles with >21 tags, the Linter extension just stops counting at 21 identical errors. It looks like the limit was originally supposed to be 20, but because off-by-one errors are one of the Hard Things^TM in programming, it's limited to 21. I don't think it's necessary to increase that number, but if someone wants to do it, it's MAX_PER_CAT in Database.php that you'll want to increase. And the off-by-one error is in Hooks.php, which should use a >= comparison. --rchard2scout (talk) 12:16, 23 May 2022 (UTC)

This limit means that the total error count on firefly's table is an undercount, but it doesn't really matter, since 21 is the same as 57 as a way of saying "this page has lots of errors". On this new report, once we get through the first couple thousand pages with 21+ errors, the numbers will start to be meaningful (except that multiple errors within some templates and tables are counted as a single error in Page Information, but that's a different limitation of Linter). – Jonesey95 (talk) 12:48, 23 May 2022 (UTC)

You also get undercounts when the errors are wrapped within a template as the can end up getting counted as just 1 or each type rather than all the items. -- WOSlinker (talk) 13:22, 23 May 2022 (UTC)

Thanks guys, that explains it nicely. I've always wondered why the actual number of errors in a page is sometimes far grater than the number Firefly reports. —Bruce1ee ^talk 13:41, 23 May 2022 (UTC)

[1] (435,000-328,000)/9

[2] They're alphabetical, and we can already see up to V

[a]

[b]