Wikipedia talk:Linter/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Policy question

I'm aware of user who has actively reverted all delinting attempts by gnomes and bots from their userspace, and talk archives. When asked on their userpage why they are taking such actions, they reverted the question with a curt "no." offering zero reason or explanation with this request of information, and no edit summaries used when they've reverted these fixes.

Are they in right, since these are their userpages, or is there a Wikipedia policy that supersedes the "my userspace, my rules" right in this regard with these page errors that would permit gnomes to proceed and renable these fixing edits without fear of edit warring repercussions? Some are high priority errors, which break elements when read. I have not reinstated my clearly explained, clean fixes since there are far easier lints to tackle at the moment and I'd rather avoid edit warring discussions/arbcom, but it may come to that with this editor. No 3rr has been crossed on any individual page history (either side), but they have overcrossed 3rr IFF their page reverts are viewed as a collective. I'm not seeking action at the moment, just information gathering. Zinnober9 (talk) 04:58, 10 April 2023 (UTC)

Your pointless fixes to very old records is fiddling of old pages that shouldn’t happen, and is thus disruptive. The policy violation is WP:BOTLIKE by lint fixers. SmokeyJoe (talk) 05:14, 10 April 2023 (UTC)

Zinnober9: Thank you for your work to eliminate lint errors from Wikipedia. SmokeyJoe uses uninformed and illogical reasoning to get to an invalid conclusion: Fixes are "pointless" because the "records" are very old, therefore it's just "fiddling of old pages", therefore it shouldn't happen, therefore it's disruptive. But if there is a page with a series of <small> tags "closed" with another <small> tag, not contained within a table, the display (now) gets smaller and smaller with each successive <small> tag, and this is not OK. If the markup is from before July 2018, the original appearance was (at least usually) that the linter silently changed the closing <small> tags to </small> tags. So, fixing pages with this problem is good because anyone looking at such pages will see them as they originally appeared (if the markup is from before July 2018) instead of the unworkable way they look with the Multiple unclosed formatting tags lint errors, and if the page is newer, it's still worth fixing even if not restoring an original appearance. SmokeyJoe is also incorrect in linking WP:BOTLIKE here, because there, the issue is human editing in a careless manner as if by bot. For example, there could be a bot that looks for any page that says {{use American English}} and includes the word "honour", and changes it to "honor". This would be wrong, because the word "honour" might be in a book or article title, or in an anecdote about spelling. WP:BOTLIKE is concerned with such a bot, or a human editor who performs a program of editing on the same principle as this hypothetical bot, without considering which occurrences of "honour" should be left unchanged. I know this because WP:BOTLIKE specifically relates to edits that "cause errors an attentive human would not make". Assuming Zinnober9's edits are consistent with the due diligence an "attentive human" would use, they are not contrary to WP:BOTLIKE.

There are users who have claimed that third parties should never correct talk pages or User space pages. I have had some discussions with them, and when I point out that on Wikipedia, we edit talk pages all the time, for example, to avoid copyright infringement, that always ends that argument. Zinnober9 is right to fix lint errors, even on archives of 15-year-old discussions.

That said, if a user asks me to leave their page alone, and I am unable to convince them that smaller and smaller and smaller and smaller markup all the way to the end of the page is not a good idea, I don't usually edit "their" pages against their will. Instead I hope that eventually another Wikipedian will fix the same page, and maybe the "owner" will realize that the de-linting community is right in the effort to fix lint errors, even on User pages and ancient talk pages. —Anomalocaris (talk) 06:40, 10 April 2023 (UTC)

Zinnober9 should write a bot, and get it approved, before embarking on or continuing widespread fixes. SmokeyJoe (talk) 10:39, 10 April 2023 (UTC)

SmokeyJoe has made this assertion/claim/argument before, but it's not supported. Wikipedia:Linter authorizes and encourages fixing lint errors, individually or "widespread", and has done so in language largely unchanged for over four years. Once, I noticed that Benicia, California, was widely misspelled on Wikipedia as "Benecia", so I searched for "Benecia" and corrected each one. (I used due diligence in case of original errors in newspaper article titles, but there weren't any such original errors.) I didn't need to write a bot, and I didn't need to get approval, to make "widespread fixes". I just did it. Lint errors are the same. Just fix them. You don't need to write bots or get approval. Cheers! —Anomalocaris (talk) 18:28, 10 April 2023 (UTC)

Fixing mainspace errors is always good.

Fixing old archives is different. Fixing an archive compromises the purpose of the archive, which is to be an accurate record of what it was at the time of archiving. If the fix needs doing, the bot process is appropriate to judge that. An ordinary editor account should not be editing others archives without very good reason. SmokeyJoe (talk) 23:20, 10 April 2023 (UTC)

Other than Non-mainspace edits have more rules to follow, and archived pages having very specific rules to stay within, they are not different. Fixing problematic and obsolete syntax is one of the only acceptable and valid edits on archives, and is permitted. Of my archive edits, NONE, I repeat, NONE, of my archive edits have altered or compromised any meaning or structure, and none violated any of the rules stated here at WP:LINT. And in cases where archived pages had leaking syntax errors, actually improved the readability of these pages so that (madeup user1)'s leaking signature color didn't color everything after his comment, or (madeup user2)'s leaking small tags didn't make reading things hellish to read or violate accessibility, or mix with someone else's error and create some other illegible mess. (I'll end the color here, as I don't wish to be obnoxious with my example). The vast majority of lint errors are in people's fancy signatures and every edit I've made correcting these have retained (or repaired when broken) functionality of the users' signature links and the users' intended display, despite your baseless accusations to the contrary.

the bot process is appropriate to judge that. Really? I've found all Bots to severely lack any sentient judging ability required to decide anything and no ability to judge any appropriate course of action for unidentified errors. They are a script to find clearly identifiable patterns. If the known pattern is found, it changes X to Y, in a safe, repeatably accurate, edit. That's it. It makes no judgement calls. Not all errors are easily identified, and unless you can write a script for a bot to identify a specific pattern and change it to the acceptable correction without breaking something else, the error is not botable and would need to be edited by a human to fix.

Quit harping on this utter bullshit claim that our delinting edits are compromising pages. It is overwhelmingly, repeatably, and demonstrably false, and has become a personal attack due to your continued (and unsupported) accusations our edits. Making unsupported accusations of other editors is a violation of WP:No personal attacks, but you know that. Zinnober9 (talk) 04:02, 11 April 2023 (UTC)

Coding is not one of my talents and I do not have the coding knowledge needed to create anything that I think would be approved. Those who have made approved bots already have far better coding knowledge than I, and I will leave the task of creating these vastly helpful bots to them. Zinnober9 (talk) 20:15, 10 April 2023 (UTC)

If you’re not up to making or altering bots, then you most certainly should not be doing BOTLIKE edits to archives. SmokeyJoe (talk) 23:22, 10 April 2023 (UTC)

Again, I'm not making botlike edits. I make clean, manual edits that address all remaining errors on pages in a final edit, with due dilligence for no errors, as is permitted by WP:LINT and are nessecary actions that I enjoy. Stop changing the subject and quit turning this into a WP:WITCHHUNT. This topic is NOT about me, my coding skills, the validity of delinting actions, the policy botlike, or you, it is about how to proceed with a noncommunitive user who reverts all delinting efforts, human or botmade and refuses to comment on such when directly asked. Zinnober9 (talk) 04:02, 11 April 2023 (UTC)

Zinnober9 has averaged around 45 edits per day in the last six months [1]. This is nowhere near BOTLIKE editing. You can easily make that many delinting edits in 5 minutes without any mistakes, check out this video. At this point MalnadachBot and Legobot have made at least one attempt to fix most pages in every namespace that has a Lint error, taking out most of the easy errors. There is still a lot that can be mass fixed by bots in more passes, but that takes time. There are many context sensistive changes that bots cannot handle, which has to be made by human editors. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 05:08, 11 April 2023 (UTC)

Thank you, Anomalocaris. At this time, I'm not intending to reinstate my error free edits on this specific user's pages, despite no stated request for me to leave these pages alone (the reverts are a quiet indication of such feelings, but are not a stated request. So it's enough for me to pause and watch for the time being). Other delinters going for those pages will likely occur more frequently as other high priority errors get further reduced and these errors become bigger fish in the shrinking pool. Sadly most of the errors on this user's pages are the typical obsolete, missing, stripped tags, which are still in great number across the site. But the specific errors I was specifically going after are in a dwindling pool, so hopefully these will get further action by others as those errors dwindle elsewhere and become more prominent. Hopefully these pages be cleaned again without any fuss. Zinnober9 (talk) 20:31, 10 April 2023 (UTC)

I hope you had a wonderful Easter, SmokeyJoe. Your reply has nothing to do with my original question, however. You've been told by multiple users, MULTIPLE TIMES, that these delinting actions DO NOT violate WP:BOTLIKE. Botlike is about speed and error creating edits that are repetitive, pointless or problematic, and that are not indicative of human behavior. Our delinting actions are not such behavior. Delinting are corrective actions, and (if done with care and with reasonable expectations of due diligence to be error free) are permitted actions that will continue since bots cannot, (and I will boldly claim, robots will NEVER), be smart enough to fix every code error that humans have made on Wikipedia. You whining about this shit is a tired broken record and NOT ONCE have you provided an valid explanation showing how delinting violates botlike.

So far (as it appears to me) you have tried to spin it into a fantasy statement of "stop fixing errors and just build a bot to fix them all". Sure, that would be great if bots were able to clear all such errors, but this idea that every error that exists on Wikipedia can be fixed by bot is so far into the clouds of hypothetical dreamland for this to ever become a reality. While possible that many current errors will become bot achievable, not all will. We would love for such a bot to exist so that we wouldn't have many corrections to do, but UNTIL SUCH EXISTS, we gnomes will continue our responsible gnoming actions.

YOU have largely ignored requests for YOU to make everyone happy by sharing this magical code that you think exists that would fix everything correctly without errors (such as those here AND above when you whined last month about our fixes).

Until such a bot is created and approved to attend to all errors correctly, quit your whining, (re)read WP:BOTLIKE as you seem to have an incorrect understanding, and have a wonderful day. Zinnober9 (talk) 20:14, 10 April 2023 (UTC)

I reject your reading of BOTLIKE editing policy. You, and others, non-bot-experienced, editors have been violating BOTLIKE for years, with the associated problems: mass repetitive edits with mistakes, generation of edits that others have to check, compromising archives that are supposed to be unedited. BOT approval and the associated hiding of bot edits is a huge advantage of bot processes.

For a while, my watchlist was half-filled with BOTLIKE linter edits to old archives. This in itself is a problem. After my first complaint, the rate of BOTLIKE linter editing of archives dropped off, but slow editing is not the answer. SmokeyJoe (talk) 23:29, 10 April 2023 (UTC)

Well, good luck with that. Many editors have told you that your view of this policy is incorrect, and you refused to give any evidence or explanation for how botlike governs any human delinting efforts, or the delinting of archives, and have chosen to instead further whine and kvetch about these differing views with false and unsupported accusations about our delinting actions, which are starting to violate WP:No personal attacks due to the accusations without proof portion of this policy. Best wishes, Zinnober9 (talk) 04:02, 11 April 2023 (UTC)

• On the original question, does an editor have a right to tell you to get out of their archives? Yes, they do, unless the fixes are pre-approved under bot policy. —SmokeyJoe (talk) 23:31, 10 April 2023 (UTC)

Yes, the user I speak of most certainly has that right, and if such right is stated by them, I'll honor it. But as I already stated, (which you seem to have overlooked) this user has not stated such request in such written terms anywhere, even when asked for comment, so there's a standoff at the moment in this regard due to their lack of comunication. I was checking to see if I was overlooking any potential route for resoluion. Anomalocaris does not seem to think so, and I value their opinions. I also value the views and opinions of ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ and Jonesey95 as all three have vast knowledge of clean, reliable editing and addressing issues, and explain things well with supporting evidence.

Please take your kvetching elsewhere, your unfounded, offtopic complaints are no longer welcomed on this topic and are a distraction from this topic's original discussion. Thank you. Zinnober9 (talk) 04:02, 11 April 2023 (UTC)

SmokeyJoe asks the wrong question. The question is not, "Who owns archive pages?" The question is, "What are archives for?"

Archives are a tool that allows others to look back and see what went before. Outside Wikipedia, there are archival sound and film recordings. There are original sound recordings on easily-broken wax and shellac 78 RPM phonograph records. With the invention of vinyl 33+1⁄3 RPM records, precious original 78s were transferred to the newer media, which is less damaged by repeated use, and has other advantages. Later, 33+1⁄3 RPM records were transferred to newer media that are not even slightly damaged by replay. With passing time, fewer and fewer people have ready access to equipment to play 78s and even LPs, so they are well-served by the transfer to new media. Meanwhile, the original sound recordings are saved.

And so it is with Wikipedia. Just as technological changes makes it inconvenient for most people to play 78s, technological changes make it difficult or impossible to see original Wikipedia pages as they would have appeared in the past. Changes in Wikimedia software includes changes to how Wiki markup gets pre-processed into HTML, and changes in the definitions of HTML can affect display, perhaps in the future if not already. Wikipedia editors can fix technology issues, such as by fixing lint errors that were harmless in 2004 or June 2018 but became disastrous in July 2018. There is no loss to people who have reason to see the original, for just as archivists save the old 78s and LPs, Wikipedia automatically saves old versions of pages. Now that we understand what archives are for, there is no valid objection to trained experts such as Zinnober9 to repair old busted pages and preserve them through a round of technological innovation.

SmokeyJoe also errs in raising the red herring of "unless the fixes are pre-approved under bot policy". It is true that a user can get approval to use a bot. But that doesn't mean that this method is ever required. The reason we like to get approval before launching bots is that that bots do not have human judgment, so we want to have some confidence that they work as intended, and only as intended, and not where they shouldn't, before we run them. Regular human Wikipedia editors do have human judgment, so they don't need pre-approval to embark on a program of edits.

Cheers! —Anomalocaris (talk) 05:36, 11 April 2023 (UTC)

Mostly I agree with all of that. Pre-approval for editing archives, whether a user’s user_talk, or old XfDs, would be good, and doesn’t need to be bot approval, but I think bot approval would be a good thing to do, before fixing things like users’ user_talk archives. SmokeyJoe (talk) 08:56, 11 April 2023 (UTC)

SmokeyJoe: If you are able, please present diffs of this alleged bot-like editing by human editors and explain how a bot could have performed the large series of repeatable edits that you have linked to. Pending that, please stop repeating the same unsubstantiated claims against editors who are performing helpful error-fixing edits. – Jonesey95 (talk) 16:18, 11 April 2023 (UTC)

Ok, but in starting, I find this to be an inappropriate edit. The page was a history of someone’s signatures, and now it is not. SmokeyJoe (talk) 21:35, 11 April 2023 (UTC)

That's an excellent example, because it shows that the Linter fixes restored the signatures to how they originally looked, before the MediaWiki software was modified to deprecate some kinds of syntax. So: not bot-like, and the opposite of a disruptive or inappropriate edit. Next? – Jonesey95 (talk) 02:21, 12 April 2023 (UTC)

I could agree with SmokeyJoe on this one. The user wrote that two of their signatures were "too long", which means more than 255 characters. As it happens, the two signatures that were too long before delinting are also too long after delinting, but the one that "looked crappy" and the "signature for some time" both crossed from less that 255 to more than 255 in delinting. And we have the puzzling "at last" signature, which was more than 255 characters before delinting, so how did that work? Anyway, for a discussion about signatures and whether the preferences page will accept them, I think part of due diligence might be to leave the linty signatures alone. —Anomalocaris (talk) 23:20, 14 April 2023 (UTC)

While I can see both sides to this, in the end, after some days of considering how to proceed with this sort of page, I felt the more important aspect was retaining the visual display of their signature's history. The Tidy Font error pretty much destroyed how the signatures looked (colors defaulting to normal link blue instead of the user's stated colors). While the length was commented on in that example, I didn't feel that it interfered with rewriting them if the rephrased version had the same issue. Zinnober9 (talk) 04:45, 15 April 2023 (UTC)

Ah, I hadn't thought about the fact that the new linter software changed the display of the Tidy font link bug. I did say "I could agree with SmokeyJoe", but I could also agree with Zinnober9, and on balance, preserving the signature appearance probably trumps preserving the markup, even at the cost of crossing the 255-character limit for "preferences" signatures. —Anomalocaris (talk) 06:24, 16 April 2023 (UTC)

Template HST issue

There is a template error causing an issue on User:Basemetal/sandbox (and likely anywhere else this template is used). The template hst (and paired hsb) is registering stripped divs, despite correctly written usage of the start and end tags, with any content and/or without. While I could change it to a collapse top/bottom for the same visual effect, I feel that since the template's own examples are linty when tested, that the issue should be resolved in the template, not on Basemetal's sandbox. Where might I bring this template error to the correct attention for fixing/addressing? Thanks, Zinnober9 (talk) 00:39, 20 April 2023 (UTC)

Expanding on Zinnober9's observation:

• lintHint finds two stripped div tags located at {{hsb}}.
• Page information is correct and does not find the false stripped div tags.
• Expand Templates: copying the markup here, lintHint works correctly and does not find stripped div tags.
• Special:WhatLinksHere/Template:Hidden_section_top link count shows 251 transclusions, 23 direct and 228 indirect.
• The first item that linked to this template was Talk:Blood pressure.
  • Its page information showed 2 Obsolete HTML tags.
  • Editing revealed two obsolete <center> tags and 2 {{hst}}...{{hsb}}.
  • lintHint showed two stripped div tags for each {{hsb}}.
  • I fixed the two obsolete <center> tags and saved.
  • Page information page now shows no lint errors.
• So, the bug seems to be confined to lintHint in the editor but not in ExpandTemplates; the bug does not affect Page information or the lint error database.

I agree with Zinnober9 that the issue should be resolved in the templates, not in User:Basemetal/sandbox and other pages transcluding them. —Anomalocaris (talk) 07:30, 20 April 2023 (UTC)

This looks like another case where templatestyles is interfering with LintHint's ability to detect errors in edit/preview mode. If there is no actual Linter error present, maybe we should report the issue to the LintHint developer. – Jonesey95 (talk) 14:55, 20 April 2023 (UTC)

I overlooked that it was only confined to Linthint. Apologies. Thank you for clarifying. Zinnober9 (talk) 20:16, 20 April 2023 (UTC)

Paging PerfektesChaos! —Anomalocaris (talk) 18:41, 20 April 2023 (UTC)

lintHint does not ″find″ anything but is just forwarding messages from Wiki parser.

It is a well known issue with linter that conditional expressions are regarded as HTML as-is. Example:

• <div {{#if:{{{p|}}} | style="color:#000000">this</div> that | class="center">inside</div> outside}}
• Reported as superfluous end tag </div> etc.

Greetings --PerfektesChaos (talk) 10:35, 21 April 2023 (UTC)

gallery thumb lint errors, suddenly now

A few minutes ago the linter suddenly realized that the thumb parameter does not belong in a gallery for pages in the talk namespace and it's beginning to populate Lint errors: Bogus file options (talk namespace). Curious that it's happening now. Anomalocaris (talk) 19:23, 27 April 2023 (UTC)

This is a long-standing "bogus image options" bug (it should have been caught, because "thumb" is not valid within gallery tags) that was finally fixed. The code change is here. The bug (there may have been more than one) was T214601. The fix is to remove thumb from the gallery line. WOSlinker ran a bogus image options bot for a while, IIRC, and might be able to help. – Jonesey95 (talk) 20:36, 27 April 2023 (UTC)

Mostly they've been populating in main space. Talk's been slow enough to clean and keep up with so far, but if a bot's already pre-equipped to run this task, they are more than welcome to whack them all. Zinnober9 (talk) 21:14, 27 April 2023 (UTC)

The bot task in question appears to be Wikipedia:Bots/Requests for approval/WOSlinkerBot 15. I don't know if WOSlinker would be willing to run it through the remaining pages with bogus image options errors, including these newly detected gallery thumb errors. – Jonesey95 (talk) 21:25, 27 April 2023 (UTC)

I've done a few just to check that it's all working. I'll look at doing some more later on. -- WOSlinker (talk) 07:47, 28 April 2023 (UTC)

Thanks, that will be a great help. —Bruce1ee^talk 07:48, 28 April 2023 (UTC)

WOSlinker, thanks, some bot help would be great! There are currently 2,400 errors in the category, and we should expect more to trickle in over the next few days or weeks as pages get refreshed by the job queue. – Jonesey95 (talk) 16:02, 28 April 2023 (UTC)

Divspan Serbia

The div span errors of this afternoon are due to a del nom on Template:Kosovo-note. I really wish template del noms didn't throw a divspan flip error when templates are nominated, but at least they correct after the discussion is finished. I attempted to see if it was due to the |help=on parameter (defaults to on if parameter is absent), but adding "|help=off" changed nothing. Anyway, not a problem that needs correcting (unless there's some trick I'm not thinking of), just need to wait it out I believe. Zinnober9 (talk) 22:04, 2 May 2023 (UTC)

Adding |type=inline is the standard fix for this problem. (I also removed some extra white space.) – Jonesey95 (talk) 01:46, 3 May 2023 (UTC)

syntaxhighlight and source

I've noticed that <syntaxhighlight>...</syntaxhighlight> tags that are not closed, <source>...</source> that are not closed or opening with one and closing with the other are not reported by lint. Should they? Gonnym (talk) 11:11, 1 May 2023 (UTC)

My understanding is that Linter does not check for these since they are not HTML tags. Same thing happens for unclosed <noinclude> and <includeonly> tags. ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 07:01, 3 May 2023 (UTC)

Pandeism

Information page for Pandeism claims two lint errors on the page. Can’t find them nor know how to even begin. What to look for? Hyperbolick (talk) 07:03, 3 May 2023 (UTC)

That's odd, I can't see anything up with it, either. I tried an empty edit but that didn't clear it. LicenceToCrenellate (talk) 07:45, 3 May 2023 (UTC)

There are two missing end tag errors. The closing italics here:

<ref>[http://www.granta.demon.co.uk/arsm/jg/eriugena.html Genest, Jeremiah, ''John Scottus Eriugena: Life and Works] {{Webarchive|url=https://web.archive.org/web/20180728040718/http://www.granta.demon.co.uk/arsm/jg/eriugena.html |date=2018-07-28 }}'' (1998).</ref>

should be inside the external link's square brackets, not outside. I've fixed them here. —Bruce1ee^talk 07:59, 3 May 2023 (UTC)

Well that’s something. Hyperbolick (talk) 08:06, 3 May 2023 (UTC)

New linter error: large-tables

Hi all, just a head's up: a new linter error was created as part of T334528. From what I can see, it will show up in lintHint and on the page information, but it's not in the list at Special:LintErrors, so you'll have to know to go to Special:LintErrors/large-tables. It's not showing on Firefly's report, but I'm guessing it will start showing up in Galobot's report once that's updated. As far as I can tell, this linter error was created solely so that the WMF's Web team can understand the problem of large tables on mobile interfaces, I don't think there's anything here for us to fix. @Galobtter: can you exclude this lint error? Its linter_cat is 20. Thanks! --rchard2scout (talk) 09:53, 11 May 2023 (UTC)

Yes, this tracking group should be excluded from all reports. In my opinion, the WMF is misusing Linter, because there is nothing invalid about the syntax that they are trying to detect. They should have used a report or a hidden category or something else instead of polluting tools like LintHint that identify actual errors, IMO. If this mini-project interests you, however, and you want to provide feedback on the tables that are currently detected, please see T336316. – Jonesey95 (talk) 14:05, 11 May 2023 (UTC)

It looks like this new tracking flag may have been backed out as of this time stamp; I'm no longer seeing it in LintHint, and the Special link above no longer works. It will probably return in some form. – Jonesey95 (talk) 17:54, 11 May 2023 (UTC)

... and Special:LintErrors/large-tables appears to be redirecting to Special:LintErrors. —Bruce1ee^talk 21:46, 11 May 2023 (UTC)

The latest Thursday update to MediaWiki was apparently backed out completely due to a bug unrelated to this new Linter tracking flag, so all of the above features are gone for now. We should expect to see the flag return in the next week or so. – Jonesey95 (talk) 23:28, 11 May 2023 (UTC)

 Done Galobtter (talk) 01:17, 12 May 2023 (UTC)

It appears to be active again. Special:LintErrors/large-tables is showing all pages with "big tables", and lintHint is reporting big table "errors", for example on Decimal time. —Bruce1ee^talk 09:58, 12 May 2023 (UTC)

See mw:Help:Extension:Linter/large-tables for a current explanation of this linter flag. – Jonesey95 (talk) 13:17, 12 May 2023 (UTC)

LintHint is flagging a lot pages (e.g. Edward Balliol and John Balliol) with this "error" simply because of their (rather short) infoboxes.  — SMcCandlish ☏ ¢ 😼  05:41, 13 May 2023 (UTC)

I'm finding it on most every page with a table today. If the table's got 6+ columns they are flagged "large". Ridiculous. Zinnober9 (talk) 05:46, 13 May 2023 (UTC)

AFAICT, Edward Balliol is being flagged for its navbox, which appears to be fine. As I tried to say above, this new flag is not an error. – Jonesey95 (talk) 13:39, 13 May 2023 (UTC)

Thank you, I saw your comments above before my comment and I wasn't trying to contradict you or SMcCandlish with my observations. Just was adding how trigger happy I was finding this to be so far and what the tipping point appeared to be for if a table is flagged or not. In response to the John Balliol page, it's appearing to me that the navbox {{Pictish and Scottish Monarchs}} is claiming large table, and that John's infobox is not claiming anything. But regardless, I agree with you that Wikipedia should have handled this tracking venture differently and not used the lint feature for this since it's not an actual issue. Zinnober9 (talk) 23:55, 13 May 2023 (UTC)

I'm finding that https://wiki.riteme.site/wiki/Special:BlankPage/lintHint keeps claiming "Future problems detected." when reading a page that has one of these "dearGodthistableisnormalsized!" "large tables" (instead of stating the message "Big Tables that are hard to view on mobile" which displays in the linthint banner when editing on a page). Would it be possible to have these nonissues completely ignored in these two places as well? Or is this something on my end that could be ignored by adjusting the tool's code as written on my common.js page? Zinnober9 (talk) 05:42, 13 May 2023 (UTC)

You could ask at User talk:PerfektesChaos/js/lintHint (follow the redirect) for an option to ignore specific error types. – Jonesey95 (talk) 13:39, 13 May 2023 (UTC)

Thank you here as well, for the link and info. I've gone ahead and contacted PerfektesChaos to see if ignoring this item would be possible, either as a blanket default, or as an added line of user specified code. Hopefully it's possible and gets added soon. Zinnober9 (talk) 23:56, 13 May 2023 (UTC)

Did you see that some hiero-tags also are triggered by this linter category?

<hiero>V17-S29-n:n:n-N14-N33*N33:N33:N33</hiero>

I do think this is a problem, that should be fixed by the developpers. The tags seems to use tablesyntax. --Lómelinde (talk) 05:24, 15 May 2023 (UTC)

I have reported this at the above-linked phab ticket. – Jonesey95 (talk) 06:16, 15 May 2023 (UTC)

Thank you I am not able to report anything on pahb, it is for me like chinese words. --Lómelinde (talk) 06:30, 15 May 2023 (UTC)

@ Jonesey95, you have reported there https://wiki.riteme.site/wiki/Lake_Lemuria table on the top of the page

an other problem like in this case is, table in table will add columns and create lint errors. Examlple:

{| class="wikitable"
|-
! first table in table !! second table in table
|-
|
{| class="wikitable"
|-
| column 1 || column 2
|}
|
{| class="wikitable"
|-
| column 1 || column 2
|}
|}

If you count all columns (2×2 + 2 pipes [outer table] = 6) it appears im the lintertable. --Lómelinde (talk) 07:15, 15 May 2023 (UTC)

This new [not] error has made LintHint close to unuseable and seems to flag things other than just tables, like cladograms (or in at least one case, nothing I could see). As normal-sized tables and cladograms are not errors, nor using incorrect syntax, I regard this as a gross abuse of the Lint label and tools meant to aid cleaning up lint, as well as a significant dampener on my desire to track down and fix lint errors when 90% of articles I check are throwing out this not-error. --SilverTiger12 (talk) 03:46, 22 May 2023 (UTC)

I have added all or most of the above comments to T336316, and suggested that this Linter tracking should be removed until the developers have figured out what they actually want to track and how they want to resolve it. – Jonesey95 (talk) 05:56, 22 May 2023 (UTC)

Thanks for reporting. My apologies that we overlooked API access to lints that some tools use. We'll disable all API access to hidden lints for now so this won't happen. If we cannot figure out a way to do that right away, we'll temporarily disable the large-lints category till we can do this in a way that doesn't break existing tools and workflows based on the Linter. SSastry (WMF) (talk) 06:36, 22 May 2023 (UTC)

There is a patch that will remove large-tables lints from the restbase API json result array of records that should ride the train next week that will stop LintHint from seeing these research on mobile formatting "non errors" that the web team needs for their work optimizing mobile display of wide tables. We are very sorry the large-tables category records escaped our efforts to suppress them. Further improvements will be made to avoid future research and diagnostic lint records from showing up in API's or UI's unless special efforts are made to see them in the database, or with an API option. SBailey (WMF) (talk) 18:39, 25 May 2023 (UTC)

Firefly report up to date

The replication lag appears to have finally cleared and the Firefly report is up to date again! —Bruce1ee^talk 09:16, 31 May 2023 (UTC)

Userxx Template Issue

Hi all. I noticed that in Special:Linterrors and the category, Multi-colon escape, the template userxx appeared. I originally misattributed it to Jonsey95, but from a talk on their userpage, they had tried to fix it as well. There were no other relevant edits from when I looked on 1 June and 8 June. It appears there was a change from Mediawiki somewhere that drives this, but unknown which. Thanks. Inomyabcs (talk) 06:01, 8 June 2023 (UTC)

On Template:X45, I removed the <noincludes> and that resolved the linter errors. Have not applied it to the problem template. Inomyabcs (talk) 06:28, 8 June 2023 (UTC)

For Userxx, did this as a workaround. -- WOSlinker (talk) 07:53, 8 June 2023 (UTC)

I think it might be better to report this as a bug. The noincludes were a useful feature to demonstrate how the template works on its own page. Do we agree that this should not have been flagged as a double-colon error? – Jonesey95 (talk) 15:18, 8 June 2023 (UTC)

Update: I have filed T338475 after poking around some more. – Jonesey95 (talk) 15:31, 8 June 2023 (UTC)

Example code should always go in the /doc. If you need to make the actual code more complicated to show how it works, you are doing something wrong. Gonnym (talk) 15:57, 8 June 2023 (UTC)

It is very common to have noinclude tags in the template code to make an example of the template work on the page itself rather than showing {{{1}}} or error messages about missing parameters, which confuses the newbies. Either way, I'm pretty sure that it is a bug related to a change in the MediaWiki code, since there does not appear to be an actual multi colon escape condition, and this page was edited in September 2022 and didn't appear on the error list at that point. – Jonesey95 (talk) 16:35, 8 June 2023 (UTC)

User talk:Gazamp/Archive 2

User talk:Gazamp/Archive 2 was listed with a Multiline table in list lint error. LintHint was pointing to a seemingly innocent block in section "Portal tip #2: Making more Selected sections", below the line "Like this:". Large segments surrounding the alleged error, copied into a sandbox, did not usually show lint errors. Eventually I suspected that the problem is in random transcluded images. I did a null edit (saved with no changes) and the error went away. For what it's worth, this archive was edited once to replace two deleted templates, {{border-radius}} and {{box-shadow}}, and in the replacement, it looks to me like an extra semicolon was added to the replacement markup. The first template had one closing semicolon and now has two; the second template had zero closing semicolons and now has one. I don't think this is related to the Multiline table in list lint error; I think that was coming from a random transclusion that somehow caused lintHint to detect an error far from the transclusion. We can't have [[Talk:User talk:Gazamp/Archive 2]], there's no talk page to discuss problems with a talk page, so I'm discussing it here, in case the error comes back soon and someone else tries to work on it. —Anomalocaris (talk) 07:13, 16 June 2023 (UTC)

{{Transclude list item excerpts as random slideshow}} and that family of templates do occassionally run into multile table in list lint errors, and I've been cleaning them myself over time. They arise from when an article has a template on the same line as the lead text instead of above it, like here or here (which is the one that triggered the archive you link). One of the modules behind the template, Module:Excerpt/portals, attempts to avoid bringing in templates not part of the text, but this lack of spacing makes it think it's a wanted inline template. Aidan9382 _(talk) 07:27, 16 June 2023 (UTC)

Div-span-flip on Cherantha de Silva

Greetings. Going through the lint error list, I saw Cherantha de Silva on a div-span-flip list. I went through the article and narrowed it down to the navbox based template, Kenyon College, embedded in the medal template. The navbox, which starts with a div tag is enclosed in a span tag on the medal template, specifically in <span class="country_name">.

As far as I can see, there is no class labeled "country name" located in the medal template. My guess is that it is a reference pointer for commenting on what the "2" argument is for. I don't have many options to fix this myself. Out of curiosity, though, which method is more appropriate; changing the span in the medal template to a html comment or removing the Kenyon College template from the article's medal template?

Thank you. Inomyabcs (talk) 00:03, 20 June 2023 (UTC)

Ghost Draft talk errors in Firefly report

The Firefly report seems to have 1 Misnested tag and 3 Missing end tag errors for the Draft talk namespace that aren't there (when clicking on the entry, it's always zero). This has been going for at least a week I think. Gonnym (talk) 10:27, 21 June 2023 (UTC)

The same is happening with Bogus file options in the article namespace. It shows 1 error when there aren't any. I've seen this happen before, but after a while it seems to correct itself. —Bruce1ee^talk 10:37, 21 June 2023 (UTC)

@Firefly any idea what is causing this? Gonnym (talk) 06:08, 24 June 2023 (UTC)

It's been going on since April, and Firefly mentioned that it was related to toolforge DB replica replication delay.

That said, the count has slowly grown and hasn't decreased at any point since then in that namespace.

I know there's some lag, and that's what is contributing to my Needle in a Haystack question above with a huge page, but I don't think that's the story with the Draft Talks since they tend to be tiny. Zinnober9 (talk) 06:45, 24 June 2023 (UTC)

Needle in a Haystack

If anyone has an idea for how to find the Tidy Font error on User:Yasnodark/sandbox, I'm open to suggestions. (You are also welcome to it if you find it and want to fix it.) The page is so giant that it breaks LintHint and slows my browser down, and when I've broken the page down to thirds and "scanned" each third, they are all clean of any and all issues (per Linthint). I'm a bit puzzled. Zinnober9 (talk) 00:38, 4 June 2023 (UTC)

I think the problem may have been fixed already, but the Page Information has not caught up, possibly because of the recent replag problems or possibly for some other reason. If you go to the Linter error detail page and click the links, you are taken to portions of the text where there are clearly no errors. Something appears to be out of sync. Move on to the next page, and this one will most likely catch up at some point. – Jonesey95 (talk) 05:07, 4 June 2023 (UTC)

Relatedly, congratulations to the editors who removed tidy font errors from User space. This space has only 8 pages left with this error, one of which (User:Cscott/TidyTest) is an intentional test page, and the rest are edit-protected. —Anomalocaris (talk) 10:11, 4 June 2023 (UTC)

J: My edit to the page May 23 fixed the link in link errors, and did not find any Tidy Fonts. MalnadachBot's March 10 edit cleared two Tidy Fonts, so this page must be severely lagging if those two signatures are what it is remembering. Purging has not changed anything. I'm curious if blanking the page and then reinstating the content would clear the errors, but feel that is too drastic an action for these issues if all it is is lag.

A: Thank you, that was primarily my doing. 2800 errors with about 1550 edits; took about two months. Thanks to whoever finished the last few unprotected last night, I got sleepy and called it a night before I could get to them. The six (one transcribed) remaining edit protected ones I'll be making requests for (minus the one transcribed), since they've been simple X to Ys and haven't been too overwhelming so far. I've made similar requests on 10-15 other full protected Admin pages that were granted.

For the Tidy Fonts in Usertalk space however, 60% (4100) are on protected Admin talk pages, so clearing all those will not be as likely. That said, of all 6800, 1100 are EC or lower, and 1800 are full protected (nonadmin) and likely will be clearable (typically old socks that were full protected before Wikipedia have leveled protections). These two sets will make a nice dent. Also, it's interesting that the 4100 errors on 650 Admin talk pages are of only 47 Admin. I was not expecting it to be such a small pool of users. I wonder if there might be a targeted purge action approved when it gets down to just those. Clearing the last of these with one of the approved lint bots would be great if they are just a few specific signatures en mass, but not sure if such can happen, since bots don't appear to have Full Protection access. Zinnober9 (talk) 15:26, 4 June 2023 (UTC)

I tidied up some of the tricky and leftover font link errors in User space for you after you had done 99+% of the work. I think that you are seeing that concentration of errors in a small pool of editors' pages because the vast majority of font link errors were already cleaned up by a couple of Linter bots. Like boiling a stew, their edits necessarily left behind a concentration of errors that were not easily fixable by a normal bot. – Jonesey95 (talk) 15:45, 4 June 2023 (UTC)

I found the issue. There were one or two unclosed templates that needed to be closed and then the lint finder worked. Gonnym (talk) 09:46, 24 June 2023 (UTC)

New(?) error: Missing end tag in heading

I just stumbled across Special:LintErrors/missing-end-tag-in-heading. There is no help page, and this error is not listed at Special:LintErrors yet. Does anyone know anything about this error? – Jonesey95 (talk) 14:14, 7 July 2023 (UTC)

I made a help page, but I was unable to find anything in phabricator about the creation of this error. – Jonesey95 (talk) 15:09, 7 July 2023 (UTC)

Is Special:LintErrors/missing-end-tag-in-heading not simply a generalization of Special:LintErrors/unclosed-quotes-in-heading? If it were to be extended to include missing close italic and bold markups, then Special:LintErrors/unclosed-quotes-in-heading could be dropped. Special:LintErrors/missing-end-tag covers both missing end tags and missing close italic and bold markups. —Bruce1ee^talk 15:32, 7 July 2023 (UTC)

Update: I found T308398 and T336316, which appear to be related. I have asked for help in the latter ticket. – Jonesey95 (talk) 16:22, 7 July 2023 (UTC)

That's what I was thinking, that this seemed like an expansion on the unclosed quotes in headings error. If it is, I'd support unclosed quotes being dropped into this one since there's that overlap. That said, if this new set is fully populated right now, it's got just under 1700 lints across about 500 pages, and likely won't last toooo long before it's brought back down to reasonable nil. They seem easy to fix so far. Zinnober9 (talk) 03:06, 8 July 2023 (UTC)

Newly detected stripped tag errors may appear

It looks like T338325 has gotten some attention, which means that previously undetected stripped tags may start showing up in the error lists sometime in the next few weeks. To be clear, these are not new errors – they just weren't detected before. You can see some of the types of errors that may start appearing if you look at the phabricator ticket. – Jonesey95 (talk) 04:07, 30 June 2023 (UTC)

I've been seeing a few of those on pages here and there with others errors I'd been going after, and have cleared any I've seen. I got sidetracked, though, from asking here why those sorts weren't being flagged, so thank you for filing this report and getting action on them. Zinnober9 (talk) 23:50, 30 June 2023 (UTC)

It looks like this code change went into effect during Thursday's update. Since then, something like 7,000 new stripped tag errors have appeared in the official counts. – Jonesey95 (talk) 03:13, 17 July 2023 (UTC)

These newly detected errors, primarily stripped tags and misnested tags, are still trickling into the error lists, and since it can take months for every page to be null-edited by the job queue, that will probably happen for a while. Our total count is currently about 8,000 higher (3.730 million compared to 3.722 million) than it was before the update, despite our daily work to reduce errors (I know that I have cleared 500 to 1,000 per day in the last four or five days). Don't get discouraged!

If anyone wants to join me in working on Articles for deletion pages, I welcome the help. I like working on them because they are short and each one is transcluded in another page. This means that there are typically only a few easy errors on each page, and each fix counts double because you are fixing an error on the transcluding page as well. Here's a link to stripped tags on AFD pages. – Jonesey95 (talk) 23:33, 20 July 2023 (UTC)

New bots?

We really need to have new bots working on the list of known issues (found User:MalnadachBot/Signature submissions and others). Gonnym (talk) 09:35, 26 July 2023 (UTC)

Legoktm was going to try to restart Legobot. I keep hoping. – Jonesey95 (talk) 14:56, 26 July 2023 (UTC)

I did a run in either late May or early June and it fixed some pages but less than I was hoping, and I just haven't had the chance to dig through the skips to figure out what tweaks to make to hit more pages.

Semi-relatedly, during the BRFA you had said, "I would be wary of including User pages in your initial batches..." - should Legobot keep ignoring user pages? Legoktm (talk) 06:08, 27 July 2023 (UTC)

No, I was wrong. I think User pages should be edited at this point. I was wary that editors might be bothered by bots cleaning up their personal sandboxes where they were messing around with code, but after spending a lot of time in User space, that sort of thing is a negligible minority of what is there. Most User space content resembles the content in other spaces and needs to be fixed. On a different note, re "less than I was hoping", have you looked at User:MalnadachBot/Signature submissions? Putting some of those patterns into the bot's code would require some custom coding, but there is at least one pattern in there that would fix something like 70,000 errors. I have also found that old AFD pages often have a single non-font broken signature, and they are each transcluded, so they might be a good place to hunt for batches of bot-fixable signatures. – Jonesey95 (talk) 13:56, 27 July 2023 (UTC)

Legoktm, is the list of skipped pages available publicly somewhere? That might be a good one for some of us gnomes to go through to fix all non-bot-fixable errors. --rchard2scout (talk) 19:12, 27 July 2023 (UTC)

User:Galobot/report/Pages by Lint Errors is a fun place to visit if you're looking for pages with lots of errors. The first 50 or so pages are protected, so scroll down a bit. I usually try to fix all errors on a given page except obsolete tag errors, leaving those for bots. That reduces the error count to 21 or lower. – Jonesey95 (talk) 20:13, 27 July 2023 (UTC)

ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ has apparently lodged an appeal at the enwiki Arbitration Committee and Stewards (see here). So hopefully we'll see MalnadachBot in action again soon. —Bruce1ee^talk 15:12, 26 July 2023 (UTC)

Wikipedia:The Wikipedia Adventure

Seems there are a lot of errors caused by Wikipedia:The Wikipedia Adventure on user pages (see User:Nomvulamkhosi/TWA/Earth as an example). This seems like an easy fix for a bot. Gonnym (talk) 09:09, 15 August 2023 (UTC)

See Wikipedia:Bots/Requests for approval/SheepLinterBot 2. That bot edited as recently as 4 August 2023. The operator's page indicates that the bot may edit sporadically. – Jonesey95 (talk) 14:13, 15 August 2023 (UTC)

Milestone

As of a few minutes ago, we crossed under 100,000 total lint errors in mainspace! Having mainspace lint free is starting to feel possible! Zinnober9 (talk) 02:58, 29 August 2023 (UTC)

"Links in links" list in article space is empty (for now)

After five-plus years of work, the "Links in links" list in article space is empty (for now). I fixed a couple of templates to get some stubborn entries off of the list. No doubt new ones will turn up, but it is easier to keep a list clean than it is to empty it in the first place. Good job, team!

The only list in article space that has never been emptied is the "Missing end tag" list. There are currently about 98,000 entries in the list. Can we fix 1,000 errors per day and get it done in 98 days? That would be 25 December 2023. Let's give ourselves a Christmas present. – Jonesey95 (talk) 05:12, 18 September 2023 (UTC)

I knew some editor(s) were going after those LnL's and was very happy to see their number dwindle. Thank you for your (and anyone else's) actions to clear those.

I too would love to see the Missing End Tags disappear from Articlespace and become a cleared and manageable set. Christmas sounds a little optimistic, but I know they don't take that long to clear, since there's typically only one or two errors per article these days, and the fixes for these generally are obvious, by Christmas might be a reasonable challenge.

I also sure would love for the Tidy Font errors (~4800) to die off already, but with just over 3900 errors on ~600 pages for 45 admin, not sure how dentable that will be after I finish up the remaining 900 nonadmin Tidys. At least this error isn't repopulating with any real frequency, so their days are certainly numbered. And all the Fostered content errors in User Talk are on 0-EC pages, so those won't last too long either. Zinnober9 (talk) 05:59, 19 September 2023 (UTC)

Those admin pages could probably be completed in less than a day if a bot with an admin flag would do it. Gonnym (talk) 06:27, 19 September 2023 (UTC)

The alternate option, given that from a quick glance they are all archive pages, is that I could temporarily un-protect them to allow for Zinnober to clean them up before I re-protect. Would save the need to have an adminbot BRFA. Primefac (talk) 08:33, 19 September 2023 (UTC)

Even better. Gonnym (talk) 08:56, 19 September 2023 (UTC)

@Primefac I'd be very interested in that. We'll talk later. Zinnober9 (talk) 10:41, 19 September 2023 (UTC)

Sounds like a good challenge! Where do you get the 98,000 stat from? LicenceToCrenellate (talk) 06:22, 19 September 2023 (UTC)

The usual place: https://fireflytools.toolforge.org/linter/enwiki. It is a couple of days out of date right now. – Jonesey95 (talk) 14:08, 19 September 2023 (UTC)

Template: Kew List

I've been working through the linting errors and have come across a series of plant articles which are listed as having missing bold tags, but on closer investigation it seems to be down to them using the 'Kew List' template ({{Kew_list}}). I can't see what's up the the use of the template, can anyone else?

Some examples: Oeceoclades decaryana

Eulophia andamanensis

Tigridia LicenceToCrenellate (talk) 17:14, 1 October 2023 (UTC)

It took more edits than I would have liked, but I think that I have fixed it. The logic in the template was missing a few tests, resulting in empty output when there should have been text. – Jonesey95 (talk) 18:30, 1 October 2023 (UTC)

Excellent, thank you. They all seemed to have dropped off the list now. A few less to worry about. LicenceToCrenellate (talk) 21:29, 1 October 2023 (UTC)

Fireflytools down

Fireflytools seems to be down. Hope to see it return soon. Zinnober9 (talk) 13:16, 15 September 2023 (UTC)

Heh - I am fine, but yes the tools webpage seems to have gone to sleep. Will give it a bonk. firefly ( t · c ) 13:20, 15 September 2023 (UTC)

Lol. Adjusted. Thank you for the quick response and for giving it a check. Love using this tool. Hope it's something simple to wake up again. Zinnober9 (talk) 14:19, 15 September 2023 (UTC)

Firefly: "Internal Server Error"; Kindly bonk it again. —Anomalocaris (talk) 19:17, 15 September 2023 (UTC)

Yes I know - for some reason the toolforge webservice process doesn’t want to start correctly. I can look again tomorrow. firefly ( t · c ) 19:22, 15 September 2023 (UTC)

@Anomalocaris @Zinnober9 - fixed! firefly ( t · c ) 17:20, 17 September 2023 (UTC)

Thank you! Zinnober9 (talk) 18:05, 17 September 2023 (UTC)

Firefly: Great! But it hasn't updated since 2023-09-15 13:46:31. —Anomalocaris (talk) 19:25, 17 September 2023 (UTC)

@Firefly Might need another bonk. I overlooked that it wasn't updating when I commented on the 17th. At least the sectional links are functional. Zinnober9 (talk) 23:35, 25 September 2023 (UTC)

Working again. Thank you, Firefly! Zinnober9 (talk) 23:01, 3 October 2023 (UTC)

New Linter detection for missing table end

It looks like a fix for T295197, "Linter fails to detect missing table end", has gone into effect, just two years after the bug was reported. This means that you will see new "missing end tag" errors with "table" identified as the problem. The missing markup may be a closing table tag or the wikimarkup for closing a table, |}. – Jonesey95 (talk) 01:40, 6 October 2023 (UTC)

Note that when a template or other transcluded page is missing a table end tag, it probably needs to be placed inside the <noinclude>...</noinclude> tags that are typically at the end of a template page. If in doubt, leave it alone or check the pages in which it is transcluded to ensure that they are working after your edit. – Jonesey95 (talk) 03:40, 6 October 2023 (UTC)

There may be a minor bug, or something I do not understand, in this new code. See this edit, which makes it so that Linter stops detecting a missing table end, even though the table end is there all along. I have filed a bug report at T348296. – Jonesey95 (talk) 04:37, 6 October 2023 (UTC)

@Jonesey95: Thanks for fixing my mistakes. It seemed logical that because the table is outside the <noinclude>...</noinclude> tags, the table end tag should also be outside, not inside. —Bruce1ee^talk 08:57, 6 October 2023 (UTC)

Many "header" or "table start" templates open a div tag or a table but do not close it. This is by design. Putting the closing div or table tag in noinclude tags at the bottom gets the page off of the Linter error list but does not break the intended use of the template. – Jonesey95 (talk) 13:11, 6 October 2023 (UTC)

tt tags in Template:Turkey district populations

Any idea why the <tt>...</tt> tags in Template:Turkey district populations aren't triggering lint? Gonnym (talk) 05:42, 8 October 2023 (UTC)

Probably because there are no pages in Category:Pages using Turkey district templates with unknown parameters. As far as I can see, the tt tags are used only in error messages. If no pages have errors, no tt tags will be displayed. – Jonesey95 (talk) 12:34, 8 October 2023 (UTC)

Ah... I thought the error detection was smarter and it actually scanned the code itself, not just if it reach an active part of it. Gonnym (talk) 13:36, 8 October 2023 (UTC)

No, the error detection works only when a rendered page's wikitext has an error in it. That's why a template containing something like '''{{{1|}}}''' will not cause any trouble in transclusions until someone leaves |1= blank or omits it, resulting in '''''' on the rendered page. – Jonesey95 (talk) 22:21, 8 October 2023 (UTC)

Lint errors

Hi. Please see this, There is a lint errors. How to solve it? Does lint errors can affect in page displaying in mobile? Fade258 (talk) 16:39, 8 October 2023 (UTC)

Fade258: There is a bogus lint error "Big Tables that are hard to view on mobile". It was discussed at Wikipedia talk:Linter/Archive 4#New linter error: large-tables. In general, you should just ignore it. —Anomalocaris (talk) 01:31, 13 October 2023 (UTC)

lintHint not always highlighting text correctly

I noticed this began yesterday. It doesn't always do it, but when it does, it highlights text quite removed from where the lint error actually is.

Open this version of this article. In edit mode, lintHint reports two Missing end tags. Clicking on the 2nd down arrow highlights this text:

led with [[ground meat]] and flavor.<ref>{{cite web|url=http://www.qur

which is four lines down from where the missing end tag actually is:

*'''[[School|School for Muslim girls]]. [[Zeynalabdin Taghiyev]] (1904)

Clicking on the 1st down arrow works correctly. —Bruce1ee^talk 10:09, 20 October 2023 (UTC)

A simpler demonstration: Choose any article from one of the lint error reports with two errors. The 2nd lintHint down arrow highlights the incorrect text. —Bruce1ee^talk 10:30, 20 October 2023 (UTC)

I started noticing this yesterday as well. I thought it was my web browser. I recommend reporting the problem to the LintHint tool's talk page. – Jonesey95 (talk) 14:22, 20 October 2023 (UTC)

I've reported it on User:PerfektesChaos's lintHint talk page here. —Bruce1ee^talk 14:57, 20 October 2023 (UTC)

Succession boxes

I occassionally come across linting errors with succession boxes. It always seems to be the same thing - if someone has put a line feed in one of the fields, for example (from Lucille May Grace):

Is there anything that can be done about this, or are we just stuck fixing them? LicenceToCrenellate (talk) 15:14, 20 October 2023 (UTC)

I have cleaned up a ton of these. I think I usually just replace the line feed with a <br> tag. In the above case, I'm guessing that the subject of the article is Lucille May Grace, in which case just remove the name entirely. The person's name is not part of the position title. – Jonesey95 (talk) 15:59, 20 October 2023 (UTC)

Thanks, that's good advice. I wasn't sure if there was a background fix to stop them showing as errors, or something similar. LicenceToCrenellate (talk) 16:42, 20 October 2023 (UTC)

edit link for High Priority lint errors opens nonstandard edit window

The edit link for Paragraph wrapping bug workaround lint errors opens a nonstandard edit window that has a side-by-side display of two versions of the page, or one version of the page under two sets of display rules. Whatever it is, it is strange and unexpected, and I don't know what to do with it. —Anomalocaris (talk) 01:37, 13 October 2023 (UTC)

It seems that this undocumented "feature" was deployed for all "High Priority" lint errors. It has been deployed for Table tag that should be deleted, Old behaviour of link-wrapping font tags, Misnested tag with different rendering in HTML5 and HTML4, and Multiline table in list, in addition to Paragraph wrapping bug workaround noted earlier.

We need to go back to the old system. The lintHint tool does not appear on the edit page, and it still doesn't appear after clicking "Show preview" or "Show changes". Also, the page is a lie. At the top it says "This is only a preview; your changes have not yet been saved!" and below that, a left column marked "Old" and a right column marked "New", and the columns are different, but the user hasn't made any changes yet! Who installed this, and what tests were done to see if it works first? —Anomalocaris (talk) 06:26, 13 October 2023 (UTC)

This looks like it might be caused by T333179. I agree that the columns look differently. That's partly because the left column has non-functional scroll bars, but the main difference is that the two sides use two different parsers. As far as I understand it, the left column ("old") uses the current core parser, used for all page views, and the right column ("new") uses the parser that's currently in use for everything else (VE, linting, mobile apps, etc). Also see mw:Parsoid/Parser Unification.

For example, taking a page that currently has a linter error: [2], you can see that ref. 76 is shown in the list of references on the left, but not on the right. --rchard2scout (talk) 09:58, 13 October 2023 (UTC)

This is goofy. I posted a question at that phab task. For now, you can change "action=parsermigration-edit" to "action=edit" in your URL bar, or just click "Edit" at the top of the page and then run LintHint. – Jonesey95 (talk) 15:05, 13 October 2023 (UTC)

Yeah, was really offputting when I found it last night. It doesn't seem to work or update things when changes are made, and is annoyingly in the way of delinting efforts. I've been hitting edit to bypass this roadblock and I don't see it again when I do preview changes. Zinnober9 (talk) 16:48, 13 October 2023 (UTC)

This problem appears to have been fixed. —Bruce1ee^talk 09:38, 21 October 2023 (UTC)

Wikidata weekly summary #582

There is a links in links lint error in Wikidata weekly summary #582, which remains on 63 user talk pages after I fixed it on 3 user talk pages. The offending markup is

• *** (history) [https://w.wiki/6sWQ Where were the borders crossing between {{Q|Q16957}} and {{Q|Q713750}} ?]

which I changed to

• *** (history) [https://w.wiki/6sWQ Where were the borders crossing between] {{Q|Q16957}} and {{Q|Q713750}} ?

on User talk:MartinPoulter/Archive 32, User talk:Marek69/Archive 64, and User talk:AfroThundr3007730/Newsletters/Archive 21, The remaining 63 should be fixed systematically, and I'm not sure if my fix is ideal. —Anomalocaris (talk) 20:36, 24 October 2023 (UTC)

Given the apparent copy editing errors in the question itself ("borders crossing"?), I think your fix is fine. I've created a little script to fix them and will edit the affected pages. – Jonesey95 (talk) 21:01, 24 October 2023 (UTC)

I think I got them all, along with other errors while I was there. The new "LintHint doesn't jump to the right spot" bug makes it tricky to find and fix every last error with confidence. – Jonesey95 (talk) 03:47, 25 October 2023 (UTC)

Jonesey95: Thanks! To get around the "lintHint doesn't jump to the right spot" bug, I'll sometimes copy a chunk of wikitext around lintHint's indicated spot and paste it into an empty sandbox, which usually reduces the lintHint offset to zero. —Anomalocaris (talk) 05:39, 25 October 2023 (UTC)

Firefly report not displaying correct namespace

The Firefly report is displaying lint errors for all namespaces and not the namespace selected. Using the namespace dropdown fixes this. Not sure what's going on here. (Pinging Firefly). —Bruce1ee^talk 23:38, 2 November 2023 (UTC)

This is caused by T231161 being implemented in a way that appears to break existing namespace links. I have posted a note there asking if the breakage was intentional. If so, we'll have to fix links to use the new namespace selection format, which looks useful. – Jonesey95 (talk) 00:06, 3 November 2023 (UTC)

Thanks for that. —Bruce1ee^talk 00:26, 3 November 2023 (UTC)

The phab task contains a reply from a WMF developer. It looks like Firefly will need to change the link format in the report's table cells. – Jonesey95 (talk) 16:11, 3 November 2023 (UTC)

Also, the "View detailed information on the lint errors" link on the Page information links need updating as well. (example) -- WOSlinker (talk) 23:36, 3 November 2023 (UTC)

That link works for me. Is there an example of a link that does not work properly? – Jonesey95 (talk) 23:56, 3 November 2023 (UTC)

You'll see that the url has the "namespace" parameter in it. Here's an example page that has both the page and talk page linter errors shown at the same time. -- WOSlinker (talk) 07:24, 4 November 2023 (UTC)

Thanks. I have updated the phab ticket. – Jonesey95 (talk) 15:27, 4 November 2023 (UTC)

Misnested tags with Infobox officeholder

We're suddenly having a plethora of (over 100) Misnested tags associated with {{Infobox officeholder}}. I have fixed three two, Nawabzada Saifullah Magsi, Jason Sendwe, and Peter Thorneycroft, all suffering from the same problem, {{Collapsed infobox section begin}} ... {{Collapsed infobox section end}}. In all three both articles, I solved the problem by removing these two templates. Perhaps there is another way to fix the problem without removing the templates, which is why I am commenting here. —Anomalocaris (talk) 23:45, 26 November 2023 (UTC)

These errors are being caused by changes to {{En dash range}}. I tried to fix them with {{trim}}, but I was unsuccessful. I think {{trim}} may need to be applied in one of the subtemplates of the infobox. Pinging Neveselbert, who is making these changes. – Jonesey95 (talk) 05:19, 27 November 2023 (UTC)

I'm not sure what seems to be the issue here other than {{Collapsed infobox section end}} being included in the wrong parameter (such as those displaying below preceding parameters). I could try reimplementing the <div>...</div> version, which may make a difference if this is an issue of span tags within divs. ‑‑Neveselbert (talk · contribs · email) 05:22, 27 November 2023 (UTC)

If you apply the sandbox version of {{En dash range}} in the sandbox templates of {{Infobox officeholder}} and then expand one of the offending infoboxes in Special:ExpandTemplates, that should show a misnested span tag. It's convoluted, and there is probably a better way, but that is what I would try. – Jonesey95 (talk) 06:17, 27 November 2023 (UTC)

Firefly page is archived!

Others may already know this, but the Firefly page has been archived at Internet Archive.

• Oldest and only 2020: 27 October 2020
• Only 2021 and first with clickable links to error pages: 17 June 2021
• First of many in 2022: 1 March 2022
• Most recent right now: 3 October 2023

This is one way to follow the progress of lint eradication by lint type and namespace. —Anomalocaris (talk) 09:55, 28 November 2023 (UTC)

Most sources in the table in Wikipedia:Linter § Linter error count progression are links to those archives :) --rchard2scout (talk) 10:34, 28 November 2023 (UTC)

WikiProject The Beatles newsletter issue 16 - November 2008

WikiProject The Beatles newsletter issue 16 - November 2008 has two low priority lint errors:

• * [http://www.nme.com/news/the-beatles/40980 Beatles' 'Eleanor Rigby''s identity revealed?] - [[Paul McCartney]] reveals the inspiration for his song, [[Eleanor Rigby]].

should be

• * [http://www.nme.com/news/the-beatles/40980 Beatles' 'Eleanor Rigby'<nowiki/>'s identity revealed?] - [[Paul McCartney]] reveals the inspiration for his song, [[Eleanor Rigby]].

to avoid two apostrophes taken for italic markup; the article title really did have two apostrophes in a row, as can be seen at "Beatles' 'Eleanor Rigby''s identity revealed?". Archived from the original on 2009-01-09.

• </div></div></div></div>

should be

• </div></div></div>

to avoid stripped div tag ... I realize these are small errors, but the apostrophe issue affects display ... I've already fixed a few of these, for example, my edit of User talk:Vanished user ikijeirw34iuaeolaseriffic/Archives/2008/November. For what it's worth, a lot of The Beatles newsletters end with 4 closing div tags where there should be 3; I've edited a bunch of user talk pages with the Eleanor Rigby error and blindly changed every </div></div></div></div> to </div></div></div>, and it was always correct to do so, but a bot has to be more systematic than that. —Anomalocaris (talk) 07:46, 1 November 2023 (UTC)

With only 27 extant uses from what I can tell, I think this can be fixed manually rather than via bot. Primefac (talk) 09:28, 1 November 2023 (UTC)

Agreed, especially since there are no active Linter bots, AFAIK (*weeps quietly*). When I find a batch like this, I just load them all up in tabs and fix each instance. It's nice to get a hundred or so easy fixes in just a few minutes. – Jonesey95 (talk) 14:41, 1 November 2023 (UTC)

@Jonesey95, I wouldn't mind helping out with linter errors. — Qwerfjkltalk 21:59, 19 November 2023 (UTC)

Qwerfjkl: That would be wonderful. The best place to look for batches is at User:MalnadachBot/Signature submissions. Despite that bot being blocked, a few of us have continued to add patterns to that list. There is a single pattern linked from there that has two errors and is used on 93,500 pages; fixing those errors would fix almost 200,000 of the 3,600,000 remaining errors (over 5%). MalnadachBot also had a long list of signatures that it was fixing; I don't know if it had any unfixed patterns still to work on when it was blocked. – Jonesey95 (talk) 20:33, 20 November 2023 (UTC)

Jonesey95, BRFA filed. Sorry about the delay. — Qwerfjkltalk 16:56, 28 November 2023 (UTC)

Primefac, Jonesey95:  Done —Anomalocaris (talk) 06:02, 2 November 2023 (UTC)

Well, that's done

All 10,000+ tidy fonts from March are now gone as of Dec 6th! I'd been focused on eliminating this annoying error since May. There are still some Tidy Font like errors out there, but the flagger doesn't flag cases where a tag (eg bold) is between the outside font color and the link, such as (font color) (some tag) link (/end tag) (/end font color), so unless those cases were to be added to the Tidy Font flagging code, we won't know about them through linter. Keep an eye out for colors on the outside, and stick them inside when spotted. Big thanks to Primefac for your assistance, and thankyous to WOSlinker/WOSlinkerbot and Jonesey95 for clearing ones I hadn't gotten to yet. Zinnober9 (talk) 00:37, 9 December 2023 (UTC)

The "font link error not reported" phabricator task is T294720, which no developers appear to be interested in (it is more than two years old). Ideally, any bot that fixes font tags will put the converted span tags inside wikilinks instead of leaving it outside. Keep up the good work, everyone! – Jonesey95 (talk) 01:28, 9 December 2023 (UTC)

Fixed the last error in the "Misc Tidy replacement issues" category so that's another type completed.

@User:NicoV or @WOSlinker, can one of you use your bot task Wikipedia:Bots/Requests for approval/WikiCleanerBot 22 or Wikipedia:Bots/Requests for approval/WOSlinkerBot 15 to go over the "Bogus file options" in the User namespace? Gonnym (talk) 18:20, 10 December 2023 (UTC)

I've seen Misc Tidy replacement issues reoccur every so often a few pages at a time, so they will probably return again, but nonetheless it's always satisfying to clear off a set again. Thanks for fixing those. The main reason I'd announced the Tidy Fonts were gone was that they hadn't ever been zero'd out at any point since the issue started to be tracked, so it felt like a noteworthy milestone to mention and celebrate. I'm sure that they will pop up again like most other zero'd out errors that tend to reoccur, but nice to not have a few thousand just sitting there anymore.

Looks like the user with that divspanflip error (Misc Tidy issue) has reverted you though, so that error might need a little more thought. I've been rather puzzled by that one since it's error free on the page itself but transcribes dirty (oh, how I hate transcribed errors...). Hopefully we can clear the error while keeping that user happy.

I sure hope one of the bots can go after those Bogus EIS options. While I've cleaned some, I've thought that going after those weren't as fun as some other errors, and seemed rather straight forward for a bot to bang out, so was kinda ignoring them hoping for bot intervention. Zinnober9 (talk) 20:16, 10 December 2023 (UTC)

The Misc Tidy replacement issue

If anyone has an idea for how to clear up the issues for Paper9oll's archives stemming from their archive header of the past week, I think a solution would be much appreciated. I'm at a loss, and I'm guessing some others are stumped as well since it's lasted this long. @Jonesey95: You understand phab tickets and why things are broken far better than I, so you might have a better response than I for Paper9oll's reply here. Other knowledgeable replies welcomed too. Zinnober9 (talk) 04:27, 11 December 2023 (UTC)

I don't know why you are looking for a solution when I've already provided you with one. Gonnym (talk) 09:42, 11 December 2023 (UTC)

It's currently also a moot point as Paper9oll has restored my fix and the issue has been corrected for now. Gonnym (talk) 09:43, 11 December 2023 (UTC)

Did not mean to offend. I was only intending to see if there were any other possible solutions, since I knew at that time they had reverted your edit, and might have objected to that solution. If others were possible, then we could use the one everyone was happy with.

Thanks for being bold and giving something a go. I'm not always confident enough to do that, here or IRL. Your edit got the conversation started and ended with everyone learning something and (to my knowledge) a satisfying and clean solution, so congrats and thank you for your all your delinting efforts! Zinnober9 (talk) 05:52, 12 December 2023 (UTC)

Firefly page not updating

Firefly: Outstanding linter errors on enwiki last update 2023-12-19 15:01:40. —Anomalocaris (talk) 02:15, 20 December 2023 (UTC)

@Anomalocaris fixed firefly ( t · c ) 13:10, 26 December 2023 (UTC)

And Firefly fixed the links in the table as well! It's a Christmas miracle. – Jonesey95 (talk) 15:02, 26 December 2023 (UTC)

:D firefly ( t · c ) 15:43, 26 December 2023 (UTC)

@Firefly: Thanks, that's a great help. —Bruce1ee^talk 16:50, 26 December 2023 (UTC)

Fostered content in numerous articles caused by Template:Static row numbers arrows

Template:Static row numbers arrows was modified 00:59, 2 January 2024‎ (UTC) by HouseBlaster for a good purpose. This is the cause of most of the Fostered content in Article namespace, probably no point in trying to fix these lint errors until the template issue is resolved. —Anomalocaris (talk) 11:36, 2 January 2024 (UTC)

I haven't looked in detail, but issues like this are sometimes caused by TFD (templates for discussion) templates. They can be wrapped in noinclude tags, but then the template transclusions do not display the notice that is intended to draw editors to the discussion. Unless it's really breaking something, it's usually best just to leave it until the discussion is closed after seven days. There are 3.4 million other errors to work on.... – Jonesey95 (talk) 18:01, 2 January 2024 (UTC)

The error was caused by stray "class=static-row-header" markup. This was the fostered text. This markup was removed, so these lint errors are gone. —Anomalocaris (talk) 07:02, 3 January 2024 (UTC)

New pages being created from page histories, with many Linter errors

A bot has been approved to create new pages that, as far as I can tell, contain "In The News" entries from page histories. Many of these entries contained a variety of Linter syntax errors (and other types of errors such as transclusions of nonexistent templates), so the new pages, like Wikipedia:In the news/Posted/March 2004, will need cleanup. The bot operator has said that they will clean up the errors sometime in the next 12 or so hours. I don't know if the operator has experience fixing Linter errors, so they might need help. Pinging usernamekiran so that you know about this discussion. – Jonesey95 (talk) 23:44, 30 December 2023 (UTC)

@Jonesey95: Hello, thanks for the ping. Yes, I'm not much familiar with the linter errors. My first priority is to fix vandalism, and the display issues (like incorrect alignment), and if I couldn't fix the linter, I was going to ask for help here, and some other editors. For now, I'll be working on these pages off the site, and then upload the fixed text. I will fix most of the issues, but some linter errors may remain. I will update here once I create the pages. —usernamekiran (talk) 00:25, 31 December 2023 (UTC)

I fixed Wikipedia:In the news/Posted/December 2004. What a horror. It had crazy <div>, <ul>, and table markup that had most of the page appearing in a narrow column on the right edge of the page. I did the best I could. I Haven't looked at any of the others. —Anomalocaris (talk) 11:29, 2 January 2024 (UTC)

You are a far braver Wikipedian than I. I looked at that page a few times the first day it popped up, said "Yikes" and closed it, only to return a little while later and do the same thing a few more times before finally retreating back to finishing off the Table tag errors in User Talk that I had been working on eliminating.

Wikipedia:In the news/Posted/November 2004 was blanked for some reason, likely the NSFW gif spam and other display errors. Other pages don't have many issues, but I've only looked through 2004's set. I've cleaned up the egregious crap on November, but I don't feel like going after the rest of the issues this evening. Have at it if you want, I might nibble at it in the coming day (if I do, it will be after looking at what you did on December... oh so beautiful now after your hard work). Zinnober9 (talk) 02:04, 3 January 2024 (UTC)

I took a stab at the November page. It still looks a bit like a mess, mainly due to the removed images, ut at least it's free of linter errors. Feel free to make it prettier if you want though :). --rchard2scout (talk) 08:22, 4 January 2024 (UTC)

Missing end tag help requested

Ghosts (2019 British TV series) has a span missing end tag in the "Series 3 (2021)" section. Plugging that section into Special:ExpandTemplates and clicking lint-Hint narrows the error down to the end of the episode table header:

<span style="color:black;background-color:white;padding:1px;display:inline-block;line-height:50%"><ref name=ratingsBARBMostViewed/>

It's clear from this where the missing </span> should go in the expanded code, but I can't see what to change in the source code. —Bruce1ee^talk 08:24, 7 January 2024 (UTC)

Fixed. -- WOSlinker (talk) 08:59, 7 January 2024 (UTC)

@WOSlinker: So that's what the problem was: |country=U.K |episodes= was missing from the end of {{Episode table}}. I'm surprised that the "Series 3 (2021)" section rendered correctly without |episodes=. But anyway, thanks for your help. —Bruce1ee^talk 09:29, 7 January 2024 (UTC)

On a similar note, anyone know why Wikipedia:Birthday Committee/Calendar/Today is unhappy with a missing table closer claim? It popped up on about a dozen pages last night, and I haven't found the culprit page yet. Zinnober9 (talk) 14:11, 7 January 2024 (UTC)

Someone put a noinclude tag in the wrong spot. I fixed it by comparing the January 6 page to the January 7 page. – Jonesey95 (talk) 14:45, 7 January 2024 (UTC)

Ah, the opener was the culprit... was blinded by seeing this error coming from so many missing closer tags on hundreds of pages that I forgot to look at the opening statement construction (D'oh). Thanks for the quick fix. Zinnober9 (talk) 14:53, 7 January 2024 (UTC)

Multiline HTML table in list error caused by Template:WikiProject banner shell

Template:WikiProject banner shell is causing Multiline HTML table in list errors in markup like this:

:Indent
{{WikiProject banner shell|class=B|vital=yes|1=
{{WikiProject Mathematics|field=analysis|priority= high|vital=|historical=}}
}}

The templates or other markup within {{WikiProject banner shell}} don't matter, what matters is that {{WikiProject banner shell}} follows a "list" line. It doesn't matter how many blanklines are after the line with the colon, asterisk, or number sign. The error happens anyway.

The lintHint tool won't usually find the error on ordinary pages, but it does find the error on Special:ExpandTemplates.

I found a workaround that doesn't affect the display, other than fixing the indent leak: Insert just before {{WikiProject banner shell}} this markup:

<div style="clear:both"></div>

If there's a more elegant solution, I'd like to know.

However, as I was about to post this message, DMacks urged me on my talk page not to fix these errors, directing to the discussion at User talk:Kanashimi/Archive 1#Very strange change to project banner. So, pending further clarification, don't fix these errors. —Anomalocaris (talk) 10:48, 9 January 2024 (UTC)

I fixed about 25 or so last night that had the Multiline error, and commented my observations at the discussion on Kanashimi's userpage. The change the bot is making is NOT erroneous WHEN placed in the correct location, but for some reason it's encountering some pages that mess up the intended location, therefore triggering this error. I gotta go to work in a few, but I'll comment more this evening if unresolved, or more questions occur here/on K's talk page. Zinnober9 (talk) 11:25, 9 January 2024 (UTC)

Special:RecentChanges

Any idea what suddenly happened that transclusions of {{Special:RecentChanges/10}} are now being flagged with "div-span-flip"? Gonnym (talk) 18:48, 1 February 2024 (UTC)

There was a code change deployed last Thursday that made these new errors appear. I posted about it on VPT, and it looks like a patch was put into the pipeline. I don't know if it will be applied today or in a week or two. The errors can be ignored until the code patch is installed. [Edited to add: the patch is called "Avoid misnesting div in span..." in the MediaWiki version that is supposed to go live sometime in the next few hours.] – Jonesey95 (talk) 18:54, 1 February 2024 (UTC)

Ah, thanks! Gonnym (talk) 18:56, 1 February 2024 (UTC)

Mike Scotti

I must be blind here. The bold in Mike Scotti's lead sentence is messing it up. If you hit enter before "(Hachette/Grand Central)" it "fixes" it. I have no idea what is causing this. Any ideas? Gonnym (talk) 18:57, 1 February 2024 (UTC)

It was the bold around "This is War". -- WOSlinker (talk) 19:00, 1 February 2024 (UTC)

I'm so confused how an error lower in the document affected the text before it. Why did it treat the first single quote differently? Gonnym (talk) 19:06, 1 February 2024 (UTC)

That's a weird one. I find that the syntax highlighter gadget usually helps with these situations. In that previous version, everything after the error is has a gray background for me instead of white. I've never tried to figure out the why of it; it's GIGO in my book. I just fix it and keep moving.

In this case, though, it looks like the parser sees "apostrophe, opening italic markup, person's name, opening bold markup, text, closing italic markup (misnesting detected here, since there is no closing bold markup), more stuff, then closing bold markup". It's doing its best with gibberish markup. – Jonesey95 (talk) 19:08, 1 February 2024 (UTC)

Fewer than 1,000 pages with 42+ errors

I've been chipping away at User:Galobot/report/Pages by Lint Errors, which lists the 1,000 pages with the most Linter errors, and after I found a nice batch of similar pages to work on yesterday, that report is, for the first time, listing a few pages with only 41 Linter errors. Since the most errors of a given type that will be reported for a page is 21, "42 errors" typically means "at least 21 errors of two different types". I see it as a milestone that there are fewer than 1,000 pages with two overflowing error types instead of just one.

Thanks especially to Zinnober9 for getting a bunch of pages off of this list by fixing thousands of tidy font link errors that were on protected pages. – Jonesey95 (talk) 14:50, 7 January 2024 (UTC)

Belated thank you for the acknowledgment. So glad those annoying Tidy buggers are cleared (barring the occasional popup from a few users who haven't or just won't update their signatures).

Took a short break from table tag world today and went after a few more full protected pages. Dropped the max value on Galobot's report down to 53 errors. Your (and others?) chipping away at these have gotten the lower end down to showing 39+ errors now. Nice. Zinnober9 (talk) 04:30, 19 February 2024 (UTC)

Change to Template:quote box causing misnesting

I made a change to {{Quote box}} that is causing some misnesting errors to appear. Right now, there are only about 25 errors, so I think it may be easier to apply this fix than for me to come up with a workaround to my workaround to the bug fix to the bug fix that led to this situation. Sorry for making work for people. – Jonesey95 (talk) 06:37, 23 February 2024 (UTC)

sstyle vs style? What is the difference, or is the double s a typo? Zinnober9 (talk) 02:36, 24 February 2024 (UTC)

RTFM. |sstyle= is source style, which is styling for the |source= parameter's contents. There are other style parameters that apply styling to the contents of other parameters. I didn't make up the parameter names. I'm just working with what I was given. – Jonesey95 (talk) 03:19, 24 February 2024 (UTC)

Ah. Don't recall using such before and it didn't sound like a valid parameter name to me, but then it's been a long day of work, and on Wikipedia I've been a bit primed the last few months to use style= parameters, so it looked more like a typo than an actual parameter. Thanks for the explanation. Zinnober9 (talk) 03:41, 24 February 2024 (UTC)

Wikipedia:WikiProject Texas Tech University

Wikipedia:WikiProject Texas Tech University has no lint error but it obviously has a broken layout. Can't figure out how to fix this. Gonnym (talk) 11:50, 3 March 2024 (UTC)

Now fixed. Gonnym (talk) 12:37, 3 March 2024 (UTC)

Wikipedia Mobile App: Image Recommendations and New Lint Error

Hello,

This is Amal Ramadan, the Sr. Community Relations Specialist supporting the Wikipedia mobile apps team.

Our Android team is working on Image Recommendations that will enhance accessibility and user engagement within the Wikimedia mobile apps; our engineers are adding a new lint error type, which is planned to match images without alt text and are expected to trigger on a large number of pages.

It is planned to use this lint category to feed both existing linter-based correction workflows and a "microtask" workflow in the Wikipedia mobile app, where small work tasks can be presented to users in a relevant context.

We want to make sure this won’t be disruptive to existing linter system users and that updates to support the new lint type can be coordinated.

Our current technical evaluation doesn't expect performance problems from this, but if it's overloading people's workflows, we want to be sure to accommodate those needs.

Thank you for your understanding and cooperation as we work towards enhancing the Wikipedia mobile app experience. ARamadan-WMF (talk) 08:10, 27 February 2024 (UTC)

In what way is missing alt text a Linter syntax error? Can it break the page rendering in some way? Like the wide tables, I think that tracking this condition would be a misuse of Linter. A tracking category should be used instead. Unless I am misunderstanding the description. – Jonesey95 (talk) 14:38, 27 February 2024 (UTC)

Also, per Wikipedia:Manual of Style/Accessibility/Alternative text for images, An image that is purely decorative (provides no information and serves only an aesthetic purpose) requires no alternative text. (See also MOS:BLANKALT.) Tracking such images in some way would lead to many false positives, probably millions of pages, in this category. Have you analyzed a database dump to determine how many pages would be affected by this proposed new tracking?

You have not linked to any pages that show how this tracking would happen, or which namespaces would be tracked, or whether an empty |alt= would be tracked or not. Please show your work. Once you have a basic specification, you should bring this up at one of the Village Pumps here at en.WP, not at this page, since Linter should not be involved. People at the Village Pump will be able to give you helpful feedback. – Jonesey95 (talk) 14:40, 27 February 2024 (UTC)

Yeah also as a screen reader user I don't think adding alt text is really a task that random new mobile users should be doing, especially given edits I've noticed already on my watchlist from this kind of cohort. My initial mental ballpark figure for the number of people who'd get it right (i.e. produce something minimally useful) would be around 1%; maybe that's a bit harsh, but I'm sure it would be way less than 50%, and such an error rate (especially for text that most Wikipedia readers won't read at all) would be completely unacceptable. This is the short description problem all over again. I know adding alt text is becoming more mainstream these days in some quarters (which can only be a good thing), but compared to most sites, Wikipedia's requirements about it are ... more than a little bizarre. Something like "Refer to caption" as default alt text for thumbnail images would be infinitely easier to implement and more useful than what's being proposed above. Graham87 (talk) 15:32, 27 February 2024 (UTC)

Hello @Graham87,

Thank you for the good high-level feedback for the high-level feature, It's passed to the engineers who are working on this. ARamadan-WMF (talk) 08:47, 7 March 2024 (UTC)

@Graham87

Hi everyone, sorry for the confusion. The project page for this effort is actually here. By the way my name is Jaz, I am the Lead Product Manager for the apps. @Graham87 I fully agree that it is important to be intentional that in our effort to address the 95% of images that do not have alt-text on Wikipedia, but that in our quest in creating a more equitable experience for low vision folks and folks with low bandwidth where images do not load, we do not replicate the issues we see with 3% of images that do have alt-text. Our goal is to increase the 2% of helpful alt-text. As you’ll notice in our consultation strategy, we've brought a prototype to the GLAM conference and gathered our first round of feedback from volunteers in attendance regarding a prototype ; I welcome you to try it out. The insights were positive but there is a lot more careful testing we need to do before moving forward, which is what we are working on at the moment. All of our work is being done in lockstep with an Accessibility organization based in Latin America, our initial target audience are folks in Latin America and the Caribbean speaking French, Spanish and Portuguese. Starting out the feature will only be available for people with at least 50 unreverted edits, a measure we introduced for all app Suggested Edits including Article Descriptions in 2022 based on community feedback. We partnered with several community members to evaluate if there was an increase in the quality of suggested edits and did see a lift by adding that gate, although I am always happy to partner on improvements. The Suggested Edits project page will receive an update next week with additional details about the next phase of our experiment now that we've gotten feedback about the prototype. That update will also include an updated decision matrix for the next phase of this experiment. I will ensure Amal tags you on the talk page when the update is there so that you can review our decision matrix and contribute to other guardrails we can put in place to ensure this experiment is meaningful in deciding if we should proceed. The questions that @Brooke Vibber (WMF) and @ARamadan-WMF are asking about the Linter is to investigate if using the linter is a promising use case for providing a feed of contextualized alt-text in the case we have positive indicators. This investigation is not to convey that we are definitively rolling this out. I also want to assure you that this is a true experiment, it will be turned off after some people try the tool. We will evaluate the usefulness of what is produced in partnership with an accessibility organization before we proceed and will not leave the tool on while we make decisions. If you'd like to be apart of the evaluation process, I also welcome your partnership when we get to that stage! I've also created this thread to continue to discuss the project itself if you're interested. JTanner (WMF) (talk) 00:45, 8 March 2024 (UTC)

Hi@Jonesey95,

It's a pattern in the syntax that indicates something was left out that belongs according to standards.

Can it break the page rendering in some way? yes, those images have no alt text.

Mentioning the wide tables is something not specific to this issue; if you wish you help us can you elaborate more with what, specifically, would be inappropriate for the linter and why?

And, a tracking category does not carry markup location or list which image was affected, so does not provide us the information we need.ARamadan-WMF (talk) 08:40, 7 March 2024 (UTC)

Hello again @Jonesey95,

As noted we already expect a large number of matches, this is expected and will not be surprising. What we want to know is whether that will cause disruption to existing workflows using the linter data.

We've got code, which is even better. :) We already talked to the people who wrote the linter and wrote code that they have reviewed; we want to know about people using the linter to ensure that it would not cause disruption to workflows using the linter error data via special page or API.Thank you! ARamadan-WMF (talk) 08:44, 7 March 2024 (UTC)

The answer is YES, it will cause disruption to our Lint-fixing workflows, as the "wide table" tracking did. Please do not add this tracking to the Linter tables or to the Linter section of the Page information page. We had to modify all of our reports and filters and queries, and the LintHint tool, to exclude the "wide table" tracking, since it is not a Linter syntax error. Please use a tracking category. If you want editors to see the location of the error, you can use an error message in the edit preview to show the location of the error message, as Module:Check for unknown parameters does.

Also, you have not addressed my excerpt from the accessibility page above, which specifically says that some images do not require alt text. – Jonesey95 (talk) 14:24, 7 March 2024 (UTC)

Empty |alt= parameters is not a sounding like a lint issue, as it is not broken syntax, just is an unfilled parameter. I agree with the above replies and strongly request you do a tracking category instead of a lint category as this is sounding much worse than the big tables where action was *mostly* not needed and was rather annoying to deal with. WP:LINT is for things that break a page or don't display correctly on a page. It is not for "user experience inconvenienced" tracking. Please reconsider and change to a non-Lint tracking category if possible, and leave Lint out of this plan. Thank you. Zinnober9 (talk) 01:45, 28 February 2024 (UTC)

Yeah and another thing I thought of is that the people who'll be most affected by this (i.e. screen reader users) have an additional barrier to edit because of the inaccessible CAPTCHA. Graham87 (talk) 03:25, 28 February 2024 (UTC)

Screen reader users by definition are unable to perform this task because they cannot view the image.

Please elaborate more if you mean another thing. Thank you. ARamadan-WMF (talk) 09:06, 7 March 2024 (UTC)

@ARamadan-WMF: Screen reader users are pretty much the only people who'll see alt text. So if a new user adds "Pooppooppoop", "Buy my wears at amazingsite.com" or, even worse, completely wrong alt text (and it's not detected by the regular anti-vandalism filters, which for less obvious examples it may well not be), the only people who'll be directly affected are screen reader users and they'd face extreme barriers to correct the wrong alt text. Please discontinue this feature idea ... just ... nobody needs this ... and as other people can probably attest, I'm not usually this blunt about these sorts of issues. Graham87 (talk) 09:29, 7 March 2024 (UTC)

I commented at T344378 on Phabricator. Graham87 (talk) 09:47, 7 March 2024 (UTC)

Your comment is delivered on the Phab. ticket; thank you. ARamadan-WMF (talk) 09:58, 7 March 2024 (UTC)

Thanks for your feedback Graham87 -- it seems that you have some specific opinions on what kinds of markup patterns are suitable for the linter warnings/errors list and which aren't that aren't shared by the WMF Content Transformers team that maintains Parsoid, and that there's some history here about the linter in Parsoid that you, and perhaps others, have strong feelings about. We're happy to put the data elsewhere if that helps keep your existing workflows clear.

As for the general high-level feature feedback, that's useful too and will be passed on. Editing an encyclopedia is not an "easy" or "trivial" task, and never has been, and none of these things are expected to be possible without guidance and documentation for the user.

On the specific issue of empty alt text -- that can be explicitly signaled by setting alt= which will emit an empty, but present, alt text attribute. --Brooke Vibber (WMF) (talk) 16:29, 7 March 2024 (UTC)

It might be helpful for someone to link to a set of sample pages that would and would not trigger this tracking, or to the programming specification that will determine whether a page is flagged by this check for missing alt text. The initial description at the top of this section says "images without alt text". Some people might interpret a blank |alt= as "without alt text", even when it is a deliberate choice. A detailed spec would help to clear up such differing interpretations. Without a specification, we end up with unresolved parent tasks like T274382. Honestly, I would rather see programming time spent on fixing actual bugs like those listed in that task, instead of new features that will lead to more bug reports and more work for editors. – Jonesey95 (talk) 16:43, 7 March 2024 (UTC)

Hello @Zinnober9,

This is a very good comment; but a tracking category would not provide the information we need on location and file. Most likely we'd create a rough duplicate of the lint errors record and linter API feature just to record "something that's not a markup error but is a markup issue that can be caught algorithmically and recorded for human review" :) ARamadan-WMF (talk) 09:04, 7 March 2024 (UTC)

New Linter tracking tag: night-mode-unaware-background-color

Links related to the above section: See Special:LintErrors/night-mode-unaware-background-color and mw:Help:Lint errors/night-mode-unaware-background-color. The relevant feature creation task was T359205.

I don't have time to work on anything related to this in the next week, but I am putting some links here in case people are wondering why many of the reports changed today. Queries may have to be adjusted, or maybe these conditions might be easily fixable in a few templates. I don't know, since I haven't really looked at it yet. – Jonesey95 (talk) 16:17, 22 March 2024 (UTC)

From an initial poke around, it appears that many or all of the templates listed at {{Table cell templates/doc}}, as well as {{navbox}} and {{ombox}} and probably similar boxes are affected by this new tracking tag. I expect that a systematic fix for some of these sets of templates will be a better path than simply adding a text color specification to each template. – Jonesey95 (talk) 16:37, 22 March 2024 (UTC)

Request for feedback on Help:Lint_errors/night-mode-unaware-background-color

Hey there I was curious to hear from people who have used Help:Lint_errors/night-mode-unaware-background-color

I have a few questions

1) How: Forgetting the "why" these need to be fixed, when interacting with the lint rule is it clear what to fix and how to fix it? If not, how could we improve it?

2) Why: How can we improve the documentation over on Help:Lint_errors/night-mode-unaware-background-color to make it clearer why these are important to be fixed?

3) What would need to happen before we could consider promoting this rule so it is not hidden?

Thanks in advance for your feedback! 🐸 (accidentally posted under volunteer account) Jon (WMF) (talk)

Answering 1 and 2. I have found that "color:inherit" seems to work sometimes and break things other times. It is not clear to me why that is the case. Better guidance around when it is safe to insert "color:inherit" might help. When that string does not work, it is not clear what to do. Inserting "color:black", for example, seems counter to letting dark mode pick an appropriate color, but maybe not.

Answering 3. Please refer to the discussion above. Feedback from WMF folks like The night mode for Vector 2022 hasn't been built yet and There is rule in Minerva to mitigate breakage: ... You can disable this rule in developer tools if that is helpful was helpful to me, in that it helped me to understand that this new Linter rule was not ready for me to work on yet. To be able to work on it, I would need a way to look at a page in Vector 2022 (the default skin) using dark mode, see the breakage, and then apply changes and look at them in preview to see whether the problem is fixed. AFAIK, I can't do that yet.

More answers to 3. Jdlrobson has been doing good work around the site to update templates that need fixing. That work is necessary to clear out the vast majority of tracked pages, which have tracking assigned to them by templates such as {{navbox}}. I don't think the rule should be promoted until the template space is largely free of tracked pages and pages affected by transcluded templates have been null-edited to remove them from the lists. – Jonesey95 (talk) 02:31, 19 April 2024 (UTC)

Answering 2 specifically: Here's an example of where "color:inherit" did not work for me: I tried applying it next to every instance of a background color at {{2008 NHL Entry Draft (WHL draftees)}}, and it turned the "show/hide" links black instead of using the default blue for links. Using "color:black" had the same effect. Not good. I have exhausted the advice in the "How to fix" section of the Help page. What should I have done? – Jonesey95 (talk) 04:22, 19 April 2024 (UTC)

You are thinking about this correctly. In your example the correct fix would be setting color to something black.

And yes.. this does make the show/hide links black. Previously they were inaccessible in that page when they are blue and the associated code will transfer color to the element. While I think the UI could be improved here (perhaps an icon would be better) at least they are now readable to 100% of people regardless of disability. If you have concerns around the resulting UI it would be worth filing a bug about that. 🐸 Jdlrobson (talk) 14:54, 20 April 2024 (UTC)

Pages with no errors listed

@Gonnym There was certainly nothing passive aggressive about the edit I made. I even considered adding a parenthetical about there probably having been an error that got fixed, but the caches haven't caught up yet. However, that would have been speculation, since I'm not fully certain if that's the case or not. (There have been cases where I've looked at a number of recent versions and none of them had the listed error.) In any case, the exact reason isn't that important for the editor seeing a page on the list, my point was that there are cases when you don't need to do anything and it's not because you're having a short-circuit in your brain and can't see what's wrong. If you feel it's unnecessary to make a note of this to hopefully avoid people wasting their time like I did a few times when I didn't yet know about these occurrences - so be it, but no unspoken agenda was involved here. Gamapamani (talk) 08:39, 6 May 2024 (UTC)

I read "Highly impatient editors" differently, I'm happy that was only my reading of it and wasn't your intention. Gonnym (talk) 08:40, 6 May 2024 (UTC)

Oh, I worded it that way because I'm not sure it should be a general recommendation given that it causes additional server load. Anyway, does this mean that i can restore the note? I'm not attached to the "highly impatient" bit. Gamapamani (talk) 08:51, 6 May 2024 (UTC)

Yeah, no issues then. Gonnym (talk) 08:53, 6 May 2024 (UTC)

@Jonesey95, just curious, does your clarifying edit mean that this is happening solely because of transclusions? I've seen many occasions with indeed errors in templates or other transclusions putting nominally correct pages on these lists, but the cases I was talking about didn't seem to be because of that. If anything, the former error scenario mentioned by @Gonnym seems more plausible for them, although it still doesn't quite explain why sometimes previous edits from within a reasonable timeframe (in terms of caching) also didn't have anything. I guess the heavy edit traffic thing was a bit of a conjecture on my part, because I've often seen this with election pages with pretty high update frequency at the time.

And in terms of null edits vs purging, what's more benefitial about the former (since I've seen purging do the job as well)? I hope you don't mind educating me (and perhaps future readers) a bit. Gamapamani (talk) 13:52, 6 May 2024 (UTC)

No to the "solely because of transclusions". I removed the part about frequent editing, because I have never seen such a correlation. The pages that are transient in some lists are often the opposite: very infrequently edited. I have found that some pages tend to appear in the list as false positives due to their large size, which can cause timeouts that fail to process or render the whole page, leaving unbalanced markup. Other pages, including portal pages, transclude article sections that contain errors or contain closing markup that is outside of the transcluded section.
In either case, a purge changes the page for your display, but only a null edit (click edit, then publish without making a change) will make the error go away on the server side. – Jonesey95 (talk) 14:28, 6 May 2024 (UTC)

I think Gamapamani is referring to purging the page in the server cache (via the "Purge" option in the "More" menu at the top of the page, Alt+* in FireFox). I've found that removes the page from the error report most of the time, but if that doesn't do it, then I resort to a null edit. —Bruce1ee^talk 14:50, 6 May 2024 (UTC)

Ah, yes, thanks, timeouts being the culprit makes sense. That could easily apply to the elections pages as some of them were quite slow to load. They definitely were frequently edited at the time, though. (But you were quite right to remove this part if you haven't seen the correlation I think I have, to keep things more objective.) I guess I just wasn't expecting Linter to have rather peculiar bugs like putting timed out pages on the error list for specific errors.

As far as purging only changing the page for the purger, I'm not sure that's the case, because linter error lists are generated on the server side (right?) and it does have an immediate effect on them. (Like @Bruce1ee just ninja'ed. I tend to just replace action=edit with purge, though, instead of going through a menu. Or, rather, I should say I've been doing it this way because I haven't seen this menu option.) Gamapamani (talk) 14:54, 6 May 2024 (UTC)

@Gamapamani: The purge menu option has to be enabled in your Preferences / Gadgets. —Bruce1ee^talk 15:19, 6 May 2024 (UTC)

Thanks, just did that. (Actually, I first searched for "purge" on the gadgets page, found the Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page option and ticked that without thinking. That's a rather strange gadget...) Gamapamani (talk) 15:29, 6 May 2024 (UTC)

Infobox book plainlist problem

A True Novel flagged up as having an issue. It seems that if you have a plainlist in the 'publisher' field it reports it as missing an italic end tag. I can fix it by removing the plainlist, but is there anything that can be done to fix all these problems? LicenceToCrenellate (talk) 08:36, 15 May 2024 (UTC)

The error is at |title_orig= which is misused according to the template docs and expects only a single title. Also according to the infobox, |publisher= should not be a list of publishers, but the publisher of the first edition. If needed, |publisher2= should be used. Gonnym (talk) 09:28, 15 May 2024 (UTC)

{{Infobox book}} italicizes "title_orig", which causes problems if it spans more than one line. Probably the best solution here is:

| title_orig = {{lang|ja|本格小説}} ({{transl|ja|Honkaku Shōsetsu}})

or

| title_orig = {{lang|ja|本格小説}}<br />{{transl|ja|Honkaku Shōsetsu}}

Incidentally, the documentation says that "orig_lang_code" is required if "title_orig" is used. —Bruce1ee^talk 09:43, 15 May 2024 (UTC)

Tech News: Headings will be wrapped in div tags

Excerpted from section "Tech News: 2024-21" at User talk:Jonesey95, 20 May 2024
The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.
End of excerpt

I won't be surprised if this causes a few new kinds of Linter errors to appear, since there will be a whole bunch of div tags added to rendered pages. But maybe not, because they are applied at the skin level. If a new batch of errors appears in one or more of the categories, this may be something to remember. – Jonesey95 (talk) 23:56, 20 May 2024 (UTC)

Night mode: New lint rule

The Wikimedia Foundation Web team is currently working on a dark theme for Wikimedia projects and soon Wikimedia skins will support two color schemes.

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

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

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

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

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

I'm wondering how signatures with colors will work with the dark theme and if they will be flagged by the linter. Gonnym (talk) 17:29, 14 March 2024 (UTC)

Jdlrobson, thanks for the note, the links, and the process improvements. Are there instructions anywhere explaining how to turn on this new night mode so that we can see if the lint-flagged condition really causes a problem? That might help us determine if the lint condition is flagging any false positives. I also have a question similar to Gonnym's: many signatures use code like font color=black or span style="color:black" to color text, with no specified background color. Will those signatures be flagged by the new linting rule? If so, I foresee a LOT of errors. – Jonesey95 (talk) 18:00, 14 March 2024 (UTC)

If they are flagged, how will they interact with the new rule that doesn't allow lint errors in signatures? Gonnym (talk) 18:32, 14 March 2024 (UTC)

Those will not be flagged for now. Right now we are only flagging the case where background is defined without a color.

Those will be an issue with the night mode feature however.

You can test night mode (for time being only working on mobile) by appending ?minervanightmode=1 or ?vectornightmode=1 on any URL. Jdlrobson (talk) 19:54, 14 March 2024 (UTC)

Jdlrobson, it appears that signatures are indeed being flagged by this new Linter rule. Is this intentional? See this VPT post. – Jonesey95 (talk) 16:41, 22 March 2024 (UTC)

Also, the Linter rule appears to have errors detecting nested span tags. See T360797 and mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled, two related cases. – Jonesey95 (talk) 16:56, 22 March 2024 (UTC)

Was wondering that too. I will say though that I regularly use a dark mode browser addon (Dark Reader), and any black text is displayed as white, so curious if that will be a similar thing with this Wikipedia setting, or if black = black in all cases. The addon I use does make some color combos that look fine in light mode turn hellish in dark though; cyan backgrounds almost always are hell with this as it leaves the cyan background alone, but turns the darker text shades to a lighter (inverse?) color and the combo becomes unreadable. In those cases I've had to turn it off to preview those pages I'm fixing. Zinnober9 (talk) 23:10, 14 March 2024 (UTC)

Related discussion at Template talk:Episode list#Accessibility problems with this template in night mode (also by Jdlrobson).

Some TV related templates that use colors that should be tested they aren't producing lint errors:

• Template:Episode table
• Template:Episode list
• Template:Infobox television season
• Template:Series overview

Gonnym (talk) 06:45, 15 March 2024 (UTC)

Probably most sports navboxes which already violate color will also appear on this list. Gonnym (talk) 17:34, 17 March 2024 (UTC)

@Jdlrobson, see mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled. Sdkb ^talk 16:16, 22 March 2024 (UTC)

How much attention should be paid to this new tag?

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

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

The night mode for Vector 2022 hasn't been built yet. It will be built over next 4 weeks in an identical fashion to Minerva. We are releasing the lint error so editors get a head start on fixes. ?vectornightmode=1 is therefore not the query string to use. You need to use Minerva for now e.g. https://wiki.riteme.site/wiki/John%20Dalton?minervanightmode=1&useskin=minerva.

You can also add the following to Special:MyPage/minerva.js to force night mode on for all pages (e.g. template namespace)

(function () {
   const c = document.documentElement.classList;
   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {
     c.remove( 'skin-night-mode-page-disabled' );
     c.add( 'skin-theme-clientpref-night' );
   }
}());

🐸 Jdlrobson (talk) 06:00, 23 March 2024 (UTC)

Also here's an example of a fix: https://en.m.wikipedia.org/w/index.php?title=Grand_Slam_(TV_series)&diff=1215109361&oldid=1203322851&title=Grand_Slam_%28TV_series%29&diffonly=1

From what I can see the lint rule is working as expected. 🐸 Jdlrobson (talk) 06:01, 23 March 2024 (UTC)

Thanks for the Minerva tip; I was just applying the instructions you gave above and was confused. That Minerva string works on the John Dalton page, but when I go to https://wiki.riteme.site/wiki/Template:Bolvadin_District?minervanightmode=1&useskin=minerva or https://wiki.riteme.site/wiki/User:Jonesey95?minervanightmode=1&useskin=minerva I see a regular look. What am I missing now? – Jonesey95 (talk) 13:23, 23 March 2024 (UTC)

There is rule in Minerva to mitigate breakage: [style*="background"] elements get set to a black color with !important. The hope is to eventually remove this when the lints are fixed. You can disable this rule in developer tools if that is helpful. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)

Also see my script above to force it on for other namespaces. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)

bgcolor

Tracked in Phabricator
Task T173944

Using bgcolor in a table doesn't trigger the lint rule. It's only seems to be triggered by background in the style attribute.

{| class="wikitable"
|bgcolor="yellow"|test
|}

-- WOSlinker (talk) 13:01, 1 April 2024 (UTC)

good point. I thought bgcolor was already covered by Special:LintErrors/obsolete-tag but I guess that only applies to HTML4 tags not attributes? 🐸 Jdlrobson (talk) 00:46, 2 April 2024 (UTC)

If these attributes are also obsolete they should probably be tracked by the lint. Gonnym (talk) 12:47, 8 April 2024 (UTC)

Does anyone know of a BOT that will fix the bgcolor=f2f2f2 into style="background:#f2f2f2;" ? Maybe it's too complex a problem for a bot? Fyunck(click) (talk) 18:50, 30 May 2024 (UTC)

I see only seven instances, so a bot is probably not needed. – Jonesey95 (talk) 21:30, 30 May 2024 (UTC)