Wikipedia talk:Linter/Archive 1

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

In case it is helpful, this diff shows a fix I made on one of the pages where Infobox station is flagged as the source of the linter error. SSastry (WMF) (talk) 22:07, 24 November 2017 (UTC)

In case it is helpful, this diff shows a fix I made on one of the pages where Template:zh is flagged as the source of the linter error. Other pages using that template should be inspected and fixed. SSastry (WMF) (talk) 22:28, 24 November 2017 (UTC)

The linter fails to detect unclosed bold and italics set with apostrophes, for examples:

• A <small>'''bold</small> plan! : A bold plan!
• Help <small>''small</small> business! : Help small business!

These are also misnested. Wake up, linter! —Anomalocaris (talk) 10:53, 7 December 2017 (UTC)

I don' think that has anything to do with a lint error. That's just someone forgetting to put the closing apostrophes; it would happen whether the <small>...</small> tags were there or not. Primefac (talk) 12:32, 7 December 2017 (UTC)

@Primefac: Special:LintErrors/missing-end-tag. --Izno (talk) 14:06, 7 December 2017 (UTC)

The missing-end-tag category would have captured this, but right now, we've suppressed that error for quotes since we made maybe an (incorrect) early decision to only flag this error for HTML tags. But, we could enable this for quotes too. SSastry (WMF) (talk) 16:27, 7 December 2017 (UTC)

I believe that unpaired double and triple quotes should be indexed like other lint errors. Perhaps there be a new lint category for them, because, while they would usually be parsed as an opening tag, in some cases they should be parsed as stripped tags. For example,

• Why isn't this displaying as italic?'' : Why isn't this displaying as italic?
• Why isn't this displaying as bold?''' : Why isn't this displaying as bold?

However, this is probably too clever. More simply, unpaired double and triple quotes should always be parsed as opening tags, even when human readers would deduce that the intent was for them to be closing tags, and, after pre-processing them as opening tags, they should then fall into whatever existing lint categories apply, i.e. always Missing end tag, sometimes Misnested tags.

—Anomalocaris (talk) 23:20, 7 December 2017 (UTC)

Yes, I re-enabled them in the code yesterday. It will probably start showing up in the linter output when we deploy this code on Monday / Tuesday. SSastry (WMF) (talk) 18:38, 8 December 2017 (UTC)

It seems block elements within inline elements show up as "Multiple unclosed formatting tags", which is misleading since the problem isn't actually an unclosed tag, and the solution doesn't involve adding/fixing the closing tag. See Template_talk:Infobox_road#Plainlist_in_length_notes and the following section for details, but basically

<br><small>{{plainlist|
*item 1
*item 2
*item 3
}}</small>

showed up as Multiple unclosed formatting tags: <small>. The fix was

<div style='font-size:90%;'>{{plainlist|
*item 1
*item 2
*item 3
}}</div>

- Evad37 [talk] 02:37, 2 January 2018 (UTC)

Reported in Phabricator as phab:T183893 - Evad37 [talk] 08:54, 2 January 2018 (UTC)

I also agree that these should have a different category. --Izno (talk) 13:59, 2 January 2018 (UTC)

Slight comment: Small, and inline styling making text smaller, should IMO be removed from infoboxes generally because infoboxes already get an 88% font size. 85% is the smallest we allow generally. If you don't actually want to remove the smaller sizes, {{plainlist}} takes a style parameter, so the better less-than-perfect fix would be

{{plainlist|style=font-size: x%|
*item 1
*item 2
*item 3
}}

Or so. --Izno (talk) 13:59, 2 January 2018 (UTC)

I see some of you have been busy fixing things. Could you guys also focus on the high priority linter categories, especially Special:LintErrors/deletable-table-tag and Special:LintErrors/html5-misnesting categories? On this page (see the sample fix sections 2 and 3 above), I have provided some links to sample fixes in case it is helpful. Tidy removal is slated for end of June, but ideally we would love to have most wikis switched over well before, if possible. Let me know if there is anything that I can assist with here. SSastry (WMF) (talk) 03:27, 14 January 2018 (UTC)

I appreciate all the work you guys have been doing so far paring down the lint errors, getting user signatures fixed, etc. SSastry (WMF) (talk) 03:29, 14 January 2018 (UTC)

@SSastry (WMF): Those two categories are pains in the neck and almost always require hunting and pecking through the wikitext of the pages on which the errors are being reported. Hence why no one is working on them. :D Additionally, for the first error, sometimes the changes are not simply to insert a table row or cell but to get rid of the wrapping table entirely. --Izno (talk) 03:09, 19 January 2018 (UTC)

@Izno: I understand. But, looks like you are already doing the obvious thing which is to focus on templates first (ex: the citation template fixes you are pursuing). Yes, for the first error, in the majority of cases, the correct fix is to get rid of the inner wrapping table (because that is effectively what Tidy is doing). SSastry (WMF) (talk) 05:22, 19 January 2018 (UTC)

Yeah, to echo the above, template fixes are easy, but the remainder are "where the hell is that stupid lint error?" pages. I've looked for a bot solution on and off for the last month or two, and every time it just rolls back to "gotta do it manually". There's just too much diversity as far as "ways to throw a specific lint error" goes. Primefac (talk) 12:54, 19 January 2018 (UTC)

Same here, not "bot friendly" to fix most of these :( — xaosflux ^Talk 14:20, 19 January 2018 (UTC)

@SSastry (WMF): It would be very incentivizing to me personally if you could look into doing phab:T173943, because then I would have a saner goal number than "x million errors". Outside the wiki-side, you could change or add to your tracking pages for the "big error wikis" (mostly the big wikis) to shoot for 0 content space errors, which could be a sensible path to turning off Tidy. (People will bitch/moan about it, but there just aren't enough people who care to fix the stuff pre-emptively to get through 20 million-plus errors.) --Izno (talk) 14:41, 19 January 2018 (UTC)

@Izno: Fair enough. We'll work on that and roll it out soon. Next week is shot because of dev summit and all staff meeting, but soon after. @Xaosflux:, @Primefac:, that is precisely the reason why we couldn't introduce an automatic fix / correction in the parser itself. On some wikis like cebwiki, svwiki, the fixes were bottable because of a very specific kind of pattern causing the errors, but yes, otherwise, it does require manual inspection. But, yes, fixing T173943 is probably the best way to know the scope of the problem. SSastry (WMF) (talk) 15:30, 19 January 2018 (UTC)

Linter is not detecting a type of Tidy bug affecting font tags wrapping links:

• <font style="color:#FFFFFF;background:#000000;">[[Water]]</font> : Water
• <span style="color:#FFFFFF;background:#000000;">[[Water]]</span> : Water
• [[Water|<span style="color:#FFFFFF;background:#000000;">Water</span>]] : Water

In the first bullet, because of Tidy bug affecting font tags wrapping links, the link is white. With <span> markup in the second bullet, we see that without Tidy bug affecting font tags wrapping links, the link is in the default link color. Then in the third bullet, <span> markup inside the link overrides the default link color. Linter detects the obsolete <font> tag but it doesn't detect the Tidy bug affecting font tags wrapping links, as can be seen right now from User:Anomalocaris/sandbox/Lint_Test and click on page information.

PerfektesChaos: I was going to report this at de:Benutzer Diskussion:PerfektesChaos, but, as I prepared the message, it "misbehaved": Apparently on German Wikipedia, there is no Tidy bug affecting font tags wrapping links for this case, so it "correctly" doesn't detect it. But it should detect it on English Wikipedia. —Anomalocaris (talk) 07:23, 29 January 2018 (UTC)

Wait, which one are you suggesting is not being detected correctly? --Izno (talk) 12:45, 29 January 2018 (UTC)

Izno: On English Wikipedia, the first of the three bullets displays with text color white on black, because the Tidy bug overrides the default link color. But the linter doesn't detect this. On German Wikipedia, the first of the three bullets displays with default link color. —Anomalocaris (talk) 19:38, 29 January 2018 (UTC)

• The lintHint tool is just reminding when things are already in Linter database or detectable; it does not analyze anything itself.
• In December 2017, German Wikipedia switched from Tidy to Remex parser postprocessing, since our pages in focus are in good shape, at least most of them.

Greetings --PerfektesChaos (talk) 19:12, 29 January 2018 (UTC)

SSastry (WMF): I expected that you would be interested in this. —Anomalocaris (talk) 08:01, 4 February 2018 (UTC)

Yes, Parsoid only flags this when the color attribute is present on the font tag. It doesn't analyze style attributes. How common is this wikitext pattern? SSastry (WMF) (talk) 15:15, 5 February 2018 (UTC)

Probably not that common, as this is the first of its kind that I've noticed among almost 800 user signatures with <font> tags. This string was found in the signature of an editor who had made 3084 edits per Nihlus's database report. Maybe this user is the only one who has done this. I will flag this again if I find any more like it. —Anomalocaris (talk) 19:30, 5 February 2018 (UTC)

User:Anomalocaris has pointed out that there are something like eight million pages with user signatures containing <font> tags, which cause lint errors (I suspect Anomalocaris can better explain this part of it). I started fixing my own old signatures by hand (which made too many watchlists light up) and by bot, but this task is beyond me. Can a bot be tasked handle this entire fix? bd2412 T 17:49, 27 November 2017 (UTC)

This is a task which is likely need to need a WP:RFC worth of consensus given how much clamor people have already made about lighting up talk pages. My personal opinion is that users should be notified when they use a signature including lint errors (perhaps a bot should be developed for this aspect, since the related task on Phabricator probably won't go anywhere too fast), and old pages left to rot until an RFC approves the bot work, mostly because they are talk pages, and not primary to our mission, and if they don't display all that great (ref template deletions), that's not going to kill anyone. (Mind you, I would !vote support in an RFC to bot these away.) --Izno (talk) 17:59, 27 November 2017 (UTC)

He is over-stating his case somewhat, however. There are 8 million in total using a deprecated HTML tag (font being one of those, and probably the most-grievous offender). Some pages are using <tt> or <u> or <center> which are also caught in that particular lint error filter. --Izno (talk) 18:01, 27 November 2017 (UTC)

• I started working on this before Izno's comment, so I'll expand and reply to both.
• I believe BD2412 was successful in making a bot to fix BD2412's own signatures, and I believe this bot is now in the approval process. Obviously it's vastly more difficult to make a bot to safely fix every wikipedian's signatures.
• The current count is 8,830,084 obsolete HTML tags, of which perhaps 90% are <font> tags, and estimating an average of four obsolete tags on pages that have them at all, there are perhaps 2.2 million pages with obsolete <font> tags, probably well over half of which are in user signatures.
• I am all for working on this, but it's considered low priority.
• A higher priority would be a bot to fix Tidy bug affecting font tags wrapping links, which is needed before replacing <font> tags, because <font>...</font> wrapping Wikilinks needs to move inside the Wikilink before replacing it with <span style>...</span>.
• I don't think any consideration should be given to people who complain that editing a page causes watchlist notification. If something needs fixing, it should be fixed, and if that generates a flag on someone's watchlist, so be it.
• I have been notifying users with signatures that have obsolete HTML tags. I have notified 87 users so far. Part of the task is to offer a replacement string that matches their current signature without generating lint errors, and in some cases this is tricky, especially when it bumps into the character limit. I make no promises about continuing this project, and in any case I don't think I will ever be able to reach all users with linty signatures.

—Anomalocaris (talk) 18:31, 27 November 2017 (UTC)

I actually have not submitted my bot to BRFA for this, as the task is pretty far beyond the task of just grabbing x-thousand pages and running through them. bd2412 T 18:39, 27 November 2017 (UTC)

Could we consider moving this chat to WT:Linter? If we do really want to talk about removing font errors from talk pages (or really, a whole lot of other bot changes for linting), then we should consider having it in a place to generate consensus, rather than a place to generate the bot for an existing consensus. --Izno (talk) 19:03, 27 November 2017 (UTC)

No particular preference on where this discussion takes place, but thoughts regarding the actual process. First step is to get a list of users that Anomalocaris has notified. Second step is to then make a list of the old and new signatures. Third step is to do a Quarry run to find all of the pages using these signatures (though I suppose the Lint list could be used just as easily, provided the duplicates are removed). Fourth step is to run a big bot run.

As far as "people hating watchlists" - first, it will be a bot run so people can ignore it if they so choose. Second, I dislike mass changes as much as the next person but if they're all done at once (ish) like the 63 Mass Message Sender notifications I received for recipients of the Tech News, it's easy to just ignore them all. Plus, if it's broke, it needs to be fixed. Much like adages about bandages and candy wrappers, it's best to just get it done all at once.

I've been peripherally involved in the Lint discussions, but I probably won't follow this one, so feel free to ping me when a bot op is required. Primefac (talk) 20:46, 27 November 2017 (UTC)

I've completed a bot task for linter errors before (Wikipedia:Bots/Requests for approval/NihlusBOT 2) and would be willing to do it again. However, I received a lot of heat for it and believe a wider discussion should take place before continuing it. I do share Primefac's beliefs that people can/should ignore it, but I already know there will be complaints. Nihlus 20:51, 27 November 2017 (UTC)

If there is an RFC in which, for whatever reason*, the consensus is that we should actually fix these issues, then plough on through the complaints because an RFC is about as good as it gets. Primefac (talk) 20:56, 27 November 2017 (UTC)

I agree with Izno. This conversation does not belong here. I have many potential contributions to the topic of de-linting Wikipedia, and I will share them at WT:Linter as the structure there becomes clearer. —Anomalocaris (talk) 06:49, 28 November 2017 (UTC)

There's a related problem with dark skins. For some reason a bunch of users set the foreground to black and use a transparent background. — Dispenser 02:37, 28 November 2017 (UTC)

A bot which fixed the signatures of one user seems very undesirable to me. If it is not possible to fix the vast majority of problems with one pass of a bot, it would be better to abandon the project. A simpler process may be easier to code: (1) if a signature has a "simple" format (as judged by bot code), fix it; otherwise (2), remove all html elements from the signature. Johnuniq (talk) 07:05, 28 November 2017 (UTC)

Johnuniq, it sounds like there are about 87 individual signatures that would be fixed, so if one page had six invalid signatures from four users the bot run would fix all six. Primefac (talk) 13:11, 28 November 2017 (UTC)

@Primefac: No, 87 is probably the tip of the iceberg where Anomalocaris has identified consistent and repeated use of the same signature (of course it would be repeated). --Izno (talk) 14:02, 28 November 2017 (UTC)

I guess my point was that the botop would make every effort to get all of the affected errors in one pass. Primefac (talk) 14:16, 28 November 2017 (UTC)

Sure, and that's basically what John is advocating. Some of these signatures can be a bit pathological, however. --Izno (talk) 15:16, 28 November 2017 (UTC)

I wanted to chime in from the POV of replacing Tidy. As far as that project is concerned, it would be useful to focus efforts on article pages that use colored font tags around links and which show up in the Tidy bug affecting font tags wrapping links category. Everything else is not as important since losing link colors in signatures used in talk and archived pages is not catastrophic. Those can be fixed on a slower timeline based on resolving enwp-specific process-related issues as you folks have been discussing. But, getting users to clean up their signatures to not use linty signatures is probably useful. I will have to check but we might be able to generate that list (of users with linty signatures) for you. SSastry (WMF) (talk) 16:46, 28 November 2017 (UTC)

SSastry (WMF), while I completely agree that lint errors should be dealt with in the Article space first, there are zero Articles that have this particular lint error, and from what I've seen the template-space errors are all on DYK pages due to sigs so they're not being transcluded either. Thus, we're really just left with the signature issue. Primefac (talk) 16:58, 28 November 2017 (UTC)

Ha! I feel sheepish then for not checking that before I posted then. :-) Well, that is good - that category can be considered "fixed" wrt Tidy replacement! SSastry (WMF) (talk) 17:07, 28 November 2017 (UTC)

No worries! While we have you here, Ssastry, this is a definitely going-to-happen deal, right? So bot runs will be acceptable per "lets not break things", yes? So far there has been some pushback (and anticipated pushback) for fixing these errors because of "disruption". Getting the official go-ahead from the WMF would make the process a bit easier (at least to defend). Primefac (talk) 17:09, 28 November 2017 (UTC)

Primefac, Tidy is definitely going to be replaced, yes. We aim to complete it on all wikis by July 2018. A number of large wikis are slowing making the switch (dewiki, itwiki next week) and I or Elitre can point you to their discussions if that is helpful. But, as for the broader question around obsolete tags, see mw:Help:Extension:Linter#Why_and_what_to_fix, specifically the html5 compliance goal. SSastry (WMF) (talk) 18:03, 28 November 2017 (UTC)

The most important consideration is likely: what will the failure scenario present? Will signature fonts just not show - if so, not really much of a loss on old talk pages; will it break rendering for the entire rest of the page - then may need addressing. — xaosflux ^Talk 18:33, 28 November 2017 (UTC)

Not sure if I should continue here or at the end of the subheading "SQL report of current signatures" ... I'll go here.

1. I believe that lint errors on talk pages should be fixed, even if they are not as "important" as lint errors on article pages.
2. There's no point in deploying a robot to de-lint signatures until the users who make them have de-linted their customized signature.
3. By now I have notified 114 users with a custom signature using obsolete HTML tags. Of these, 44 have fixed their custom signature. One user, MjolnirPants, promptly deleted my posting with edit summary "I guess the giant red edit notice with a big, bold 'Fuck right off' wasn't clear enough", but most users are thankful and eager to improve Wikipedia; several have raised the question of going back and delinting their signatures on existing pages (including BD2412, who started to do so), which is what led to this discussion in the first place.
4. below, Dispenser informs us "There something like 400+ users still using <FONT> when signing"; I assume this is based on a search of pages updated within the past 30 days, and probably includes the 44 who have fixed their signatures at my suggestion, and probably includes most of the 114 I have notified.
5. If Dispenser can supply me with the list, it would save me quite a bit of effort, and if I average 15 a day, it would take less than a month to notify all of the ones on the list. (Probably a lot less than a month, but I want a bit of leeway.) As I did for the 114 I have already notified, I would manually construct proposed new signatures that preserve appearance, avoid lint errors, and comply with the 255-character limit. This is usually easy and occasionally challenging, and so far I have always managed to find a way to stay within the character limit.

—Anomalocaris (talk) 00:46, 29 November 2017 (UTC)

I disagree with #2 (which I have renumbered for ease of reference)--it would help us to identify new users, post-whenever we run a report to generate a list of users who currently are using font. --Izno (talk) 15:29, 29 November 2017 (UTC)

I concur; some users might be absent and not see the notification, and by putting off the task until everyone has changed we might never get it done. Primefac (talk) 15:55, 29 November 2017 (UTC)

Pardon if I've come late to the table but, counting my recent edit to my signature to de-lint it, I have the current and three old versions (not counting the raw version "out of the box") of my signature. Does that complicate the task?--Georgia Army Vet Contribs Talk 19:53, 10 January 2018 (UTC)

Gaarmyvet If one or more bots are constructed to help with de-linting, then if your X number of old signatures are of three versions instead of all of one version, it probably won't make the bot(s) work much harder. —Anomalocaris (talk) 11:59, 7 February 2018 (UTC)

-- ; sql --cluster=analytics enwiki
/* Checks nickname and fancysig fields in a users preferences.  Accounts matching
 * any banned code can be notified by bot or manually.  More sophisticated checks,
 * like a text length limit, can be done with REGEXP.
 */
SELECT name AS "User", editcount AS "Edits", up_value AS "Signature"
FROM user
JOIN user_properties AS fancy ON fancy.up_user=user_id AND fancy.up_property="fancysig"
JOIN user_properties AS nick  ON  nick.up_user=user_id AND  nick.up_property="nickname"
LEFT JOIN ipblocks_ipindex    ON ipb_user=user_id
/* User is not blocked */
WHERE ipb_user IS NULL
/* User edited a talk page in last 30 days */
AND user_name IN (SELECT DISTINCT rc_user_text FROM recentchanges WHERE
    rc_namespace IN (1, 3, 5, 7, 9, 11, 13, 15, 101, 109, 119, 447, 711, 829, 2301, 2303)
)
/* No unsubst'ed templates [[WP:SIG#NT]]; No images [[WP:SIGIMAGE]]; [[WP:SIGAPP]] */
AND nick.up_value REGEXP
    "(?i)[{][{](?!\\s*SUBST:)|\\[\\[(FILE|IMAGE):|<(BR|FONT)[^<>]*>"

Users with images in signatures (last 30 days)

User	Edits	Signature
Weapon X	2475	Weapon X (talk, contribs)
Raso mk	1634	R ašo
BallenaBlanca	4568	BallenaBlanca (Talk)
Komi3645	34	Komsk (talk me)

In 2011, I made signature linting demo, it went nowhere then. I've updated it to bring up to current the feature set. There something like 400+ users still using <FONT> when signing. — Dispenser 20:45, 28 November 2017 (UTC)

I sent requests to those image using users to change their signature. — xaosflux ^Talk 21:15, 28 November 2017 (UTC)

Those namespaces should probably include Project: as well since signatures show up there (VPP, ANI, etc.). --Izno (talk) 21:27, 28 November 2017 (UTC)

Dispenser, would you kindly provide the list of users still using <font> when signing? If it's not too much trouble, look for <tt> also, as there have been some of those in the past. —Anomalocaris (talk) 23:43, 1 December 2017 (UTC)

@Anomalocaris: You can find them at User:Nihlus/linter sigs. Nihlus 14:03, 7 December 2017 (UTC)

@Nihlus: Thanks! —Anomalocaris (talk) 17:35, 7 December 2017 (UTC)

@Nihlus: Your report reveals some interesting things. Starting with the most complicated, I do not understand what is going on with the signatures of Sigehelmus and TheJoebro64. These have some {{#if: and [[category:...]] markup, both of which would seem to be prohibited.

Your report revealed the following signature markups that are always prohibited, and therefore, we need to check for them:

• | (unescaped pipe)
• = (unescaped equals)

Your report revealed the following nonstandard, ignored markup on top of <font> markup; perhaps no separate search is necessary for these items as a Wikipedian correcting the <font> to <span style...> would take care of these anyway:

• <font ... size="yz" ...> (y is a number, z is %, px, pt, or anything else; no symbol or word should follow the font size within the quotes)

Your report revealed the following signature markups intended to enlarge, which is OK if it enlarges an envelope glyph to be as tall as letters, but should not be used to make letters larger than normal, and therefore, we need to check for them:

• <big>
• <font ... size="y" ...> (y>2)
• <... style="... font-size: ypx" ...> (y>13)
• <... style="... font-size: ypt" ...> (y>10)
• <... style="... font-size: yem" ...> (y>1)

Your report revealed probable violations of the prohibitions against categories and some template use in signature, and therefore, we need to check for them:

• [[category...
• {{ indicating the presence of a template, which should be checked

Some other signature markups that are prohibited that your report didn't find, but might occur, so it would be good to check for them:

• <br/> or <br />
• <hr/> or <hr />
• <font ... size="+y" ...> (y=anything)
• <... style="...font-size:y%"> (y>100)
• <... style="...font-size:zzz..."> (zzz ∈ {medium, large, x-large, xx-large})
• click here
• http: or https:

The highest priority is probably removing pipes and equals from signatures, so if you could run searches for those first, that would be great. —Anomalocaris (talk) 10:38, 10 December 2017 (UTC)

@Nihlus: I'm about 90% done notifying users with signatures identified so far. It would be great to have lists of signatures with issues noted above. —Anomalocaris (talk) 08:33, 19 January 2018 (UTC)

@Anomalocaris: I don't have the time currently to revise the regex of this query. You can find it here and revise as necessary. Nihlus 20:13, 19 January 2018 (UTC)

@Nihlus, Izno, SSastry (WMF), Xaosflux, Primefac, Gaarmyvet, Evad37, Johnuniq, and Legoktm: I have started two discussions at WT:Signatures:

• WT:Signatures#Signature size guidelines
• WT:Signatures#Excessive text shadow?

I have completed my notifications of the users in the December 7 list prepared by Nihlus, except about 16 that use markup to increase font size; I am awaiting consensus at WT:Signatures#Signature size guidelines before notifying them. Comment there, not here! —Anomalocaris (talk) 18:15, 24 January 2018 (UTC)

I pasted this suggestion on Template talk:Quote box in case any of you has edit rights on that template. SSastry (WMF) (talk) 00:06, 19 March 2018 (UTC)

For at least several days, on the Lint errors page, the count of Multi colon escape errors has been high. Right now it is 2, but Multi colon escape shows "No results". —Anomalocaris (talk) 19:22, 8 April 2018 (UTC)

I believe that Show preview should be enhanced to check for lint errors, and there should be a warning if there are any lint errors. Just as with invalid infobox parameters, which generate messages like

there should be a hatnote something like:

—Anomalocaris (talk) 01:28, 24 November 2017 (UTC)

I still think something should be done about this! —Anomalocaris (talk) 08:10, 9 April 2018 (UTC)

Once Tidy is replaced, some of the obvious breakages will show up in the preview without needing lint errors to be exposed there. But, we do want to implement this feature longer-term. Right now, we have our hands full. SSastry (WMF) (talk) 21:31, 11 April 2018 (UTC)

Given that we have not yet been able to work on schema changes and other linter code to more precisely identity error counts in article (ns0) and any other content namespaces, I figured I could run queries on wiki replicas of production dbs via quarry. So, here some results.

• Query showing counts in the article namespace: This shows that there are 3249 entries in the deletable-table-tag category and 6448 entries in the html5-misnesting category in the article (ns0) namespace. The good news is that besides these two sets of pages, there are 0 or fewer than 5 entries in the article namespace for all other high-priority linter categories.
• Query showing pages in the article namespace that have a sub html5-misnested tag: These pages that mis-nest a sub tag seem to affect math pages and could potentially affect the meaning of math formula and should definitely be fixed. There seem to be 155 pages in this list.
• Query showing pages in the article that have a sup html5-misnested tag: These pages that mis-nest a sup tag seem to affect math pages and could potentially affect the meaning of math formula and should definitely be fixed. There seem to be 173 pages in this list.

Hope this is helpful! SSastry (WMF) (talk) 03:13, 19 March 2018 (UTC)

I also posted on WT:MATH#Please_fix_incorrect_nesting_of_sub/sup_tags_on_pages_as_identified_by_Linter. SSastry (WMF) (talk) 21:24, 19 March 2018 (UTC)

SSastry (WMF): I accept the theory that most users deal with the article name space primarily and that talk pages are somewhat secondary. However, there are other namespaces that even users with no interest in editing will access, including the portal namespace. There are many "Tidy bug affecting font tags wrapping links" errors remaining in the portal namespace. —Anomalocaris (talk) 05:37, 11 April 2018 (UTC)

The local community decides what matters to them the most and where to start. No-one is saying "don't fix other namespaces" :) Elitre (WMF) (talk) 15:41, 11 April 2018 (UTC)

@Anomalocaris:. What User:Elitre (WMF) said. I provided the counts for the main namespace as an aid for prioritizing and giving you a realistic sense of where things are. I was definitely not discouraging you from fixing those other namespaces. If you need any information about counts in other namespaces, let me know and I can get them to you. SSastry (WMF) (talk) 21:35, 11 April 2018 (UTC)

For more than 24 hours, pages edited to remove lint have not had their page information updated to reflect the repairs, and the corrected pages are staying on the various lint error pages. For example, Special:LintErrors/self-closed-tag continues to list Nikolay Soltys even though those errors were fixed at 18:18, 2 March 2018. What's going on? —Anomalocaris (talk) 09:59, 4 March 2018 (UTC)

This has been fixed as part of https://phabricator.wikimedia.org/T188870. SSastry (WMF) (talk) 14:44, 5 March 2018 (UTC)

SSastry (WMF): See my reply at https://www.mediawiki.org/wiki/Topic:U8q07xrh4r67iql4. —Anomalocaris (talk) 18:39, 19 April 2018 (UTC)

Hey!
So a large part of the misnested tags from infoboxes seem to be caused be paragraphs nested in spans, causing problems and differing output (tidy created multiple spans, remex only one, see e.g.: [1], inspect the Location section in the infobox). Ways to fix this:

1. Fix all the transclusions by removing line breaks, existing and future (like [2])
2. Don't simply wrap user input in a span since you don't know whether it's bringing in block elements (like [3])
3. Get rid of those spans, in case this whole vcard idea is obsolete?
4. Change something in Remex to fix this like Tidy did, by creating multiple spans
5. ...?

Preferences? I'd go with #2, which will change the appearance of some infoboxes though. Ping User:Pigsonthewing who I assume introduced most of those. :) Amalthea 11:47, 20 April 2018 (UTC)

What about replacing the span tag with a div tag, as mentioned here? I don't know if there would be undesirable side effects. I did this to Infobox war faction yesterday, and it seems to have worked. I did have to delete some extra white space that appeared to be caused by a difference between div and span. – Jonesey95 (talk) 17:12, 20 April 2018 (UTC)

I've no problem with replacing spans with divs, as shown in the example diff, providing that it doesn't in turn cause display problems. We should also discourage colleagues from overloading fields as shown in the Bavarian International School example. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits

It looks like replacing span with div in templates like {{Infobox school}}, {{Infobox person}}, and similar infobox templates would get most of these articles out of this Linter category (though sometimes a different fix is needed). I don't think we can prevent editors from putting lists into template parameters. I don't have the guts to do it in these highly visible templates, but someone here (or on VPT) might be willing to make these changes. It would be nice to get this done in advance instead of waiting for these articles to break. – Jonesey95 (talk) 20:19, 20 April 2018 (UTC)

Yes, using a div was option #2 -- sorry, I didn't really make that clear, you had to click on the diff showing the change in the infobox sandbox.
As mentioned, with infobox school this will cause some pages to render incorrectly, and since avoiding that is the point of the exercise I'm hesitant; In addition, replacing them all can't actually be done: some of the parameters are combined via {{comma separated entries}}, and for that to work they can't be block items. Amalthea 20:47, 20 April 2018 (UTC)

I was looking at https://en.wikipedia.org/wiki/The_Lamb?action=parsermigration-edit which has a misnested cite tag from the {{quote box}}. The HTML shows this for the two versions:

 Little lamb, God bless thee!</p>
</div>
</div>
</div>
<p><cite style="display: block; text-align: left;">− William Blake, 1789</cite></p>
<p><cite style="display: block; text-align: left;"><br /></cite></p>
<div class="mediaContainer" style="width:220px"><cite style="display: block; text-align: left;"><audio id="mwe_player_0" controls="" preload="none" style="width:220px" class="kskin" data-durationhint="87.668004535147" data-startoffset="0" data-mwtitle="Songs_of_innocence_and_experience_the_lamb_blake.ogg" data-mwprovider="wikimediacommons">
<syntaxhighlight src="//upload.wikimedia.org/wikipedia/commons/c/ca/Songs_of_innocence_and_experience_the_lamb_blake.ogg" type="audio/ogg; codecs="vorbis"" data-title="Original Ogg file (92 kbps)" data-shorttitle="Ogg source" data-width="0" data-height="0" data-bandwidth="92439" />
<syntaxhighlight src="//upload.wikimedia.org/wikipedia/commons/transcoded/c/ca/Songs_of_innocence_and_experience_the_lamb_blake.ogg/Songs_of_innocence_and_experience_the_lamb_blake.ogg.mp3" type="audio/mpeg" data-title="MP3" data-shorttitle="MP3" data-transcodekey="mp3" data-width="0" data-height="0" data-bandwidth="167320" /></audio></cite></div>
</div>

 Little lamb, God bless thee!
</p>
</div></div>
</div>
<p><cite style="display: block; text-align: left;">− William Blake, 1789
</cite></p><p><br />
</p>
<div class="mediaContainer" style="width:220px"><audio id="mwe_player_0" controls="" preload="none" style="width:220px" class="kskin" data-durationhint="87.668004535147" data-startoffset="0" data-mwtitle="Songs_of_innocence_and_experience_the_lamb_blake.ogg" data-mwprovider="wikimediacommons"><syntaxhighlight src="//upload.wikimedia.org/wikipedia/commons/c/ca/Songs_of_innocence_and_experience_the_lamb_blake.ogg" type="audio/ogg; codecs="vorbis"" data-title="Original Ogg file (92 kbps)" data-shorttitle="Ogg source" data-width="0" data-height="0" data-bandwidth="92439" /><syntaxhighlight src="//upload.wikimedia.org/wikipedia/commons/transcoded/c/ca/Songs_of_innocence_and_experience_the_lamb_blake.ogg/Songs_of_innocence_and_experience_the_lamb_blake.ogg.mp3" type="audio/mpeg" data-title="MP3" data-shorttitle="MP3" data-transcodekey="mp3" data-width="0" data-height="0" data-bandwidth="167320" /></audio></div>
</div>

There's no visible connection to a "little blue clicky number", which is what the cite tags ought to be producing, so I'm not certain why the cite tags are being used at all. The visible difference is just an extra blank line. I think that the same problem is present in multiple quotations templates. @Izno:, what do you think of this one? Whatamidoing (WMF) (talk) 18:09, 23 April 2018 (UTC)

The page needed to be changed (as I expected ;)--the real issue was that <cite> is for phrasing content and the extra returns in the page source between the main part of the parameter and the audio file created at least one paragraph (which are flow content). I'm hopeful someone will improve the edit which fixed it. :) --Izno (talk) 21:11, 23 April 2018 (UTC)

@Whatamidoing (WMF): ^ Because I am bad at thinking about and then forgetting in the same editing session that I should ping certain people. --Izno (talk) 21:36, 23 April 2018 (UTC)

Hi, I just sampled some of the pages you listed at Wikipedia talk:WikiProject Aviation#HTML errors in aviation articles and have replied to that thread. — Cheers, Steelpillow (Talk) 10:36, 30 April 2018 (UTC)

Would someone like to clean the HTML from Fürstlich Sächsischer Hofbuchdruckerei zu Altenburg. The notes section (and a little above) is in a larger font suggesting a tag mismatch. Please be brutal, but it's beyond me. User:Johnuniq (talk) 11:15, 6 May 2018 (UTC)

@Johnuniq: - I've corrected the HTML as best I can. Richard⁰⁶¹² 13:11, 6 May 2018 (UTC)

Page information seems to confirm that edit fixed the issue. --Izno (talk) 13:16, 6 May 2018 (UTC)

@Johnuniq:: LintHint is easy to install and easy to use. It identifies the lint errors in a page, and you can use it multiple times in one edit session; it analyzes the page as-it-is-now. —Anomalocaris (talk) 04:28, 8 May 2018 (UTC)

When I fix lint errors in talk pages, broadly construed, meaning Talk, User talk, Wikipedia talk, etc., as well as articles in the Wikipedia space that consist of other people's comments, if I am in doubt as to whether my changes have preserved the appearance, I have been in the habit of doing a page preview in one tab and the original page in another tab, and I toggle between them and use page down to verify that I haven't messed up the appearance. Unfortunately the parsermigration feature makes this method impossible, and a workaround is needed. —Anomalocaris (talk) 10:24, 8 May 2018 (UTC)

Release 3 of lintHint will give you an easy approach to set the link mode explicitly.

• That will be disseminated during May.
• If you need it quickly, you may configure the layer option or run the development version d.js ahead of documentation and warranty.

Greetings --PerfektesChaos (talk) 11:08, 8 May 2018 (UTC)

Oh, I just learned that you are already using lintHint. Well, the following steps should work:

• Change /r.js in User:Anomalocaris/common.js into /d.js (“d” goes for development & debugging).
• Visit Special:Blankpage/preferencesGadgetOptions#lintHint.
• Click the green “+” button.
• Once you noticed a -3 version number you might return to the more efficient and stable /r.js (“r” goes for release).

Enjoy --PerfektesChaos (talk) 15:11, 8 May 2018 (UTC)

Looks like lintHint might do the trick for you. Thanks User:PerfektesChaos for that gadget and continued support. :-) But, User:Anomalocaris, I want to understand what exactly is going on with parser-migration tool for you since it does the side-by-side preview that you are trying to do with browser tabs. You can edit the page in the edit window, and preview, and both versions update. In any case, if you don't want to use parsermigration, you can edit the URL to replace "?action=parsermigration-edit" with "?action=edit". SSastry (WMF) (talk) 22:17, 8 May 2018 (UTC)

SSastry (WMF): Let's break this down. First of all, even on its own terms parsermigration isn't working properly. That is, sometimes the two columns insert soft line breaks, that is, they wrap ordinary text, in different places, for no apparent reason. For that reason alone I find it annoying and I wish it would go away until this is fixed. Yes, your URL modification technique will work if used before making any edits. If I've already edited the article and click "Show preview" or "Show changes", and then on the resulting page I change the URL as you've described, it simply loads in the page anew, so my edits are lost (although generally still available with the back button in Firefox but not in Internet Explorer). So if I remember to edit the URL upon loading, your workaround will work. I've never cared how the lint error interacts with an upgrade to Tidy to affect the page display, all I've cared about is that there's an error needing fixing, so parsermigration is irrelevant to me and entirely unhelpful. I don't need a side-by-side comparison of how the article-as-edited would look using old and new tidy processors. I need a comparison of the article-as-edited and the article-as-unedited to make sure I didn't mess anything up, and toggling between tabs with the preview page and the existing unedited page makes it real easy to see "blinks" if I accidentally messed something up.

PerfektesChaos: Several months ago you gave me instructions for making LintHint work on pages other than article pages, but I didn't understand it, or found it too overwhelming, so all this time, when I've needed to LintHint something that isn't an article, I've been copying its Wikitext into an article, running LintHint there, and copying the de-linted version back. If you're working on a new release, why not just enable LintHint for all namespaces? Anyway, the issue is that before parsermigration, "Show preview" showed what the page would look like after saving, so it was easy to compare it to what the page looks like before saving, and now Show Preview shows something entirely different. This has nothing to do with LintHint, it has to do with parsermigration.

• The any-namespace-feature was present since first advertising, but at the initial stage when linter was new and future uncertain, therefore only an expert mode was present.
• Now you might visit Special:Blankpage/preferencesGadgetOptions#lintHint, put an * into namespaces field and make that persistent with green „plus“.
• This is just an easier way to provide the same user options interactively.
• Once you saved that, you also made a statement whether you get the action=edit links on LintErrors special page, as until April 2018, or the parsermigration link.

Good luck --PerfektesChaos (talk) 17:10, 9 May 2018 (UTC)

PerfektesChaos: Special:Blankpage/preferencesGadgetOptions#lintHint is "This page is intentionally left blank." and there is no feature for editing it.

@Anomalocaris:

• Please see 15:11, 8 May 2018 and follow the steps listed there; especially turning /r.js within User:Anomalocaris/common.js into /d.js to use the preliminary code.
• Story began 11:08, 8 May 2018

Best wishes --PerfektesChaos (talk) 06:06, 10 May 2018 (UTC)

PerfektesChaos: Alles ist gut, danke! —Anomalocaris (talk) 07:43, 10 May 2018 (UTC)

I've created a tool that shows a breakdown of the linter errors across namespaces (I realise that phab:T173943 is being worked on, this is a temporary measure). It'll be updated every ten minutes to avoid hammering the Toolforge database replicas with queries.

Notifying Izno, Anomalocaris, SSastry (WMF) & PerfektesChaos who've been working on lint errors.

The source code will be released on GitHub later today, and I'm open to suggestions for improvements! :) Richard⁰⁶¹² 19:24, 20 May 2018 (UTC)

Richard0612: Thanks! This may be helpful in encouraging people to take on projects, among other things. Your page correctly reports that there are 0 Multi colon escape errors, while Special:LintErrors falsely claims there are 4 errors. However, your page agrees with Special:LintErrors in falsely claiming there are 4 Paragraph wrapping bug workaround, 3 in the Main (article) namespace, but there is only 1 in the Main namespace, viz. Toro Negro State Forest. Special:LintErrors has had these erroneous counts for weeks if not months, and your page isn't entirely immune to the miscount. —Anomalocaris (talk) 01:01, 21 May 2018 (UTC)

Richard0612: Also, there are Obsolete HTML Tags errors in these namespaces: Portal, Portal talk, Book, Book talk, Draft, Draft talk, Education Program talk, TimedText talk, Module, Module talk. —Anomalocaris (talk) 01:08, 21 May 2018 (UTC)

@Anomalocaris: Interesting. I'll have a look into those bugs. The page uses the counts from the database, so it's possible that those are wrong. In categories with only a few errors (N < 100?) a script could check the page source manually... Richard⁰⁶¹² 07:26, 21 May 2018 (UTC)

Thank you for notifying me and the creation of this tool.

• I am lecherous to see dewiki available.
• One suggestion: You might order the linter categories by severity, starting with high priority in first column, or in other words: The same sequence than on special page, where the upper left corner should show many zero figures, while less important things like non-HTML5 would be out of focus in right end columns.

Greetings --PerfektesChaos (talk) 10:21, 21 May 2018 (UTC)

Other wikis are to come, the code is all in place, I just need to set up the DB queries. As for severity, that's a good idea, I'll implement it. Richard⁰⁶¹² 10:29, 21 May 2018 (UTC)

Nifty. User:Richard0612, note that if you are getting the entries from the labs database, those counts are correct -- it just that the cloud db mirroring might lag behind the production databases. SSastry (WMF) (talk) 13:37, 21 May 2018 (UTC)

See https://quarry.wmflabs.org/query/25665 -- this db query shows zero entries in main namespace for the pwrap-bug-workaround category. So, worth checking your code to see if there is any lurking bug there. SSastry (WMF) (talk) 13:44, 21 May 2018 (UTC)

Nice looking Richard0612, would you mind adding some column sort buttons and perhaps hyperlinking each of the counts to the special page for that item? — xaosflux ^Talk 13:40, 21 May 2018 (UTC)

@SSastry (WMF): I will have a look tonight. @Xaosflux: Both excellent ideas, will implement tonight too. Richard⁰⁶¹² 13:46, 21 May 2018 (UTC)

I don't suppose it would be feasible to make this work on every project? (No fancy UI needed, perhaps just by entering in the projectname like "dewiki" or "eswikt" ?) — xaosflux ^Talk 13:49, 21 May 2018 (UTC)

Absolutely it would, and is planned. The infrastructure is all there, all I need to do is code the DB queries (well, add the relevant parameters). Richard⁰⁶¹² 14:02, 21 May 2018 (UTC)

@Richard0612: thanks, I added a link in to your tool from the top of Special:LintErrors as well. — xaosflux ^Talk 14:14, 21 May 2018 (UTC)

Tool has been updated, changelog is:

• Added other projects - currently dewiki, simplewiki & commons, but more will be added. Click the drop-down menu in the top-left to switch projects.
• Reordered columns to match the ordering at Special:LintErrors and colour-coded the high, medium and low priority categories.

JS column ordering and linking to the special pages are the next feature requests up to be done. Richard⁰⁶¹² 22:32, 21 May 2018 (UTC)

Great, very helpful, thanks a lot. --PerfektesChaos (talk) 15:19, 22 May 2018 (UTC)

Ah, one more suggestion just came up: You might put grey background on even rows, keeping the odd rows white.

The even ones are the talk pages, and we are less interested in talks and private user pages and village pump, as long as those are kept readable.

Both we do understand that table counts from zero, therefore odd rows mean even namespace numbers, oh to hell with double precision correctness …

Best wishes --PerfektesChaos (talk) 15:52, 22 May 2018 (UTC)

I am flummoxed. {{Rfplinks/sandbox}} on its own terms is lint-free, that is, its Page information page lists no lint and LintHint gives it a Green bill of health. However, User:Anomalocaris/sandbox/Lint Test has only one line, viz:

{{Rfplinks/sandbox}}

and it has 3 lint errors:

• Missing end tag <span>
• Misnested tag with different rendering in HTML5 and HTML4 <sup>
• Stripped tags </sup>

It had these same errors earlier, so I edited {{Rfplinks/sandbox}} more tightly wrapping <sup>...</sup> around things, and this preserved the appearance of the template but didn't solve the 3 lint errors. What is going on here? —Anomalocaris (talk) 22:15, 6 June 2018 (UTC)

@Anomalocaris: its pretty obvious that your sandbox is all messed up - just look at the output. — xaosflux ^Talk 23:03, 6 June 2018 (UTC)

Xaosflux: It's not "my" sandbox, and I don't know what its purpose is, really. I got here from Lint errors: Misnested tag with different rendering in HTML5 and HTML4:Template:Last page. What should we do now? —Anomalocaris (talk) 23:40, 6 June 2018 (UTC)

@Anomalocaris: I just meant the one you were using, not as in ownership. Anyway, I replaced Template:rfplinks/sandbox with the primary code base and purged your page. Is it better now? — xaosflux ^Talk 01:14, 7 June 2018 (UTC)

Seems to be, as the page information link listed no errors. --Izno (talk) 01:24, 7 June 2018 (UTC)

Xaosflux: Thanks! —Anomalocaris (talk) 01:25, 7 June 2018 (UTC)

It looks like tags such as <poem>...</poem> need to be outside the {{lang}} template (which produces span tags). That might be an AWB-able change, if there's more than a few of those to be done. Whatamidoing (WMF) (talk) 17:27, 24 April 2018 (UTC)

I've mentioned this on TT:Lang: it needs to have a block option. Removal would be incorrect. Addition of the lang attribute to the poem tag would be acceptable but suboptimal. --Izno (talk) 17:43, 24 April 2018 (UTC)

Just swapping the order (poem first, lang in the middle) seems to solve the problem (which is rather minor; it just seems to change the spacing a little). Whatamidoing (WMF) (talk) 17:48, 24 April 2018 (UTC)

That only works because poem uses line breaks rather than preformatted text elements. That is not a good fix either. --Izno (talk) 02:37, 25 April 2018 (UTC)

Does the lang family of templates need to use a span? Could we sidestep this problem by making it use div tags? There are thousands of these errors at ukwiki, and it's already the middle of June. Whatamidoing (WMF) (talk) 21:38, 12 June 2018 (UTC)

Yes, it is almost always inline and so span is the correct element to use. Allowing for block use of lang is somewhere on the feature list. Ukwiki will need to make edits for the latter regardless. --Izno (talk) 00:10, 13 June 2018 (UTC)

I have created Wikipedia:Linter/Pages with lint errors that should not be fixed. Perhaps it has too much detail, but it is easier to take detail out than to put it in. —Anomalocaris (talk) 05:50, 12 June 2018 (UTC)

Anomalocaris, is the fifth column on that page the reason for not fixing it? Whatamidoing (WMF) (talk) 21:37, 12 June 2018 (UTC)

Whatamidoing (WMF): Yes, sorry, I had zapped the table headers and now the headers are back. —Anomalocaris (talk) 01:57, 13 June 2018 (UTC)

Please see this discussion for opportunities to fix articles and templates on other-language WPs that have a few thousand Linter errors remaining. My sense is that some template fixes, at least on pt.WP, may resolve many of the article errors. People who have resolved similar problems here at en.WP may be able to make quick work of these errors. – Jonesey95 (talk) 14:30, 27 June 2018 (UTC)

It always amazes me how much is omitted in the way of orientation for would-be helpers. Little things, like bringing up a specific list shows three repetitions of the same article. Oh look, if I go fix three occurrences of the same goof, all three mentions go away in the list. Hey, I betcha there's a line per error occurring? So if there's only one line, there's probably only one problem to winkle out? Yes.

Reassurance/relevance: at the head page Special:LintErrors there's a lot of information. One piece is missing. When was the list last generated? How recent is the list? We've all seen examples here at WP where information is out-of-date by weeks. Is this one of them? How does nubee know?

Speaking of live vs. dead, it would seem the subsidiary lists like Special:LintErrors/self-closed-tag are quite live. Those numbers changed as I fixed those two pages, and is now empty. The main page Special:LintErrors changed from '8' (I believe) to '3'. Is the main page also 'live'? (though I can see "Note: The counts for categories are not exact, but are based on estimates.")

Maybe an orientation about what it would mean to fix errors which maybe are rooted in templates which can't be fixed by ordinary editors? And how to recognize when to give up / reverse course? I mean, woo, [Lint errors: Multiline table in list gets me into unfriendly territory fast, what with Template:Taxonbar mentioning "This template is used on approximately 380,000 pages, ..." If this is the best way to proceed, point that out?

Oh, and you've mentioned priorities, but not the priorities within the priorities. If I look at the main list I see "Unclosed quote in heading (2,022 errors)" Yikes. I go to that subsidiary list and see "User:West.andrew.g/Dead links/Archive 910" and "User:West.andrew.g/Dead links/Archive 787" from 2012. Really? Should I bother? When I ask if the more important stuff needs help, the list says 'no'. So I should turn to another list?

Help the helpers to be able to help. Shenme (talk) 05:10, 8 July 2018 (UTC)

@Shenme: Sometimes we don't get how much help you might need right because we didn't need as much. Don't be so indignant about it. ;) I think we should try not to overload the content at Special:Linterrors in favor of some added stuff here. Specific suggestions (or WP:BOLD) are welcome for either.

To answer your questions,

1. Yes, both the listings page and the main page are current/almost-live.
2. There are two kinds of problems with templates: sometimes the issue is in the wikitext inside the template on the wiki page you are editing, and sometimes the issue is systemic to the template. I think I agree that we can probably add some guidance here; the approach to fixing the former is just to fix the former (and is the predominant problem now), while the latter is usually something a bit more complicated or convoluted. If I can't figure out the problem, I usually post on the template talk page. So regarding the former, that's mostly just experience with the kind of error in question; the latter you should give up quicker and let someone more experienced/familiar with the template deal with it.
3. Yes, article space issues are the priority. I'm not sure if we say that if you need help, this talk page is the place. We should probably make the statistics page closer to the top so that the ones that need help are obvious (there's only two high-priority issues still needing help in article space).

--Izno (talk) 16:17, 8 July 2018 (UTC)

I'm trying to understand why a page is listed within Special:LintErrors/html5-misnesting, specifically page A Song of Autumn which is reported as

A Song of Autumn         span        Output not from a single template

I'm not actually seeing any problems with the span tags, but I do see a rather stark difference between the parser outputs.

The article has both English and German texts in parallel, within a table structure. The German text is surrounded with a {{lang|de| HERBSTLIED ...... Wenn de Herbst zieht in das Land.“}} request. That makes sense.

In the "?title=A_Song_of_Autumn&action=parsermigration-edit" version of the page, in the Old column, the text extensively uses <span>s to set the language lang="de", viz.

<td><br>
<p><b>German</b> <span lang="de" title=<br>
"German language text">HERBSTLIED</span></p><br>
<dl><br>
<dd><span lang="de" title="German language text">„Wo soll ich<br>
pflücken den Blumenstrauss,</span></dd><br>
<dd><span lang="de" title="German language text">Wenn der Herbst<br>
zieht in das Land,</span></dd><br>

Strangely, very strangely, in the New column, the same area has instead:

<td><br>
<p><b>German</b><br>
<span lang="de" title="German language text">HERBSTLIED<br>
</span></p><br>
<dl><dd>„Wo soll ich pflücken den Blumenstrauss,</dd><br>
<dd>Wenn der Herbst zieht in das Land,</dd><br>
  . . . . . . . <br>
<dd>Wenn de Herbst zieht in das Land.“</dd></dl><br>
</td></tr></tbody></table><br>

The German text lyric lines are not marked with lang="de" in any way. Only the first line of text, the title, is marked correctly. Unglaublich, nicht wahr?

So... is the new parser producing incorrect output, that is then causing the parser differences to be flagged as misnesting of <span>s?

That is, I found *two* bugs? And so am doubly irritating? :) Shenme (talk) 05:53, 10 July 2018 (UTC)

@Shenme: {{lang}} is not able to be used with block content at this time--phrasing content (span) cannot be wrapped around flow content (dl). The text which it is wrapping is the latter, which is why the new parser is giving up (as specified). There is a feature request on Template talk:Lang or thereabouts for a block version of {{lang}} (which I've thought to fix myself). In the meantime, you can either skip this kind of error, or you can use <poem> while specifying a lang on the poem element or the containing table cell. You still have to respect MOS:FOREIGN, of course. --Izno (talk) 14:04, 10 July 2018 (UTC)

Someone with AWB might be able to make quick work of fixing these 233 pages. There is a user signature with multiple unclosed font tags. I fixed one page by hand, but it is tedious work.

I am sure that the multiple unclosed tags error list contains more broken signatures like this one. – Jonesey95 (talk) 14:47, 23 July 2018 (UTC)

{{Uir}} appears to have unclosed bold format that is rendered on {{Uir/doc}}. The latter page is transcluded in hundreds of template pages. I have so far been unable to find the problem. I deleted one stray bold formatting string, but the linter error has not gone away. If I move the contents of Uir/doc to a sandbox page, "Page information" says that there are no linter errors. – Jonesey95 (talk) 20:27, 9 August 2018 (UTC)

There was a line break in one of the #ifeq statements inside the bolding, which if I recall correctly causes bolding errors. If that doesn't work, then I'll take a third look. Primefac (talk) 00:07, 11 August 2018 (UTC)

Thanks! It looks like this one change fixed almost 5,000 pages in template space. – Jonesey95 (talk) 16:43, 11 August 2018 (UTC)

The Firefly tools chart, Outstanding linter errors on enwiki, shows for Table tag to be deleted a total of 116,677, as of 2018-08-28 18:23:36. The main Lint errors page gives the total as 232,030 errors, which is, curiously, almost exactly double Firefly's total. What is going on? —Anomalocaris (talk) 20:14, 28 August 2018 (UTC)

In fact, the counts are way off for most lint errors.

Except for Obsolete HTML, the Linter count is always higher than the Firefly count, often by a double or more. —Anomalocaris (talk) 20:42, 28 August 2018 (UTC)

Hmm, I did note a big discrepancy but not the near exact double difference. The counts for lint errors on Special:LintErrors I feel are off because they vary way too much (being estimates, I suppose) and that the count for multiple unclosed formatting tags has been ~60000 for a long time despite big work on them Galobtter (pingó mió) 04:54, 29 August 2018 (UTC)

The linter project was launched with very little information. Among the items that has never been documented is how the lint pages, now numbering 13, are supposed to be sorted, and when they are not in correct sort order, why. Months ago, pages all seemed to be sorted in order of most recently edited last. But now, that doesn't apply.

Through the following inspection, I have established that none of the lint error pages listing more than 50 lint errors are sorted in order of most recently edited last, except possibly Multi colon escape.

It would be desirable if lint errors were listed in a predictable order. Most-recently-edited last is a good order to sort them into, because, then, if one edits an article, one can find it in a list of, in some cases, millions of errors. But, I have had experiences editing an article, using Page information to find that the list of lint errors had been updated, and finding that the page was not listed at or near the end of the list for a type of lint error it was known to have, and, in fact, did not appear among the last 500 or 1,000 listings for that type of error, no matter how long I waited. This impeded progress on the article I was working on. This problem went away for me when I started using LintHint, but it should still be solved.

Answering my question above, I believe that lint errors are actually sorted in the order that the linter detects them. Most recently edited pages would be sorted last, if the linter was always up-to-date. But the linter is not up-to-date. There are probably hundreds of user talk pages with welcome messages from PrincessofLlyr, Airplaneman, and Brambleclawx that have Paragraph wrapping bug workaround, and have yet to be reviewed by the linter. Every few days, the linter finds another user talk page, not edited recently, that has Paragraph wrapping bug workaround caused by one of these three welcome messages, and the page is added at the end of the list, and I fix it. What is taking so long? Why, after all these months, has the linter still not completed its first pass through the user talk pages? —Anomalocaris (talk) 11:45, 3 December 2017 (UTC)

Yes, lint errors are sorted in order that they are found and added to the database - I picked that since it was trivial to implement at the time. If you want to see something else, could you comment on phab:T151282? We can re-open that task if the current sorting is sub-optimal. Legoktm (talk) 18:59, 5 December 2017 (UTC)

As for the comment about linter not having processed all pages, looks like our script didn't process all namespaces properly. Later this week, I'll run the script on all non-Article and non-Talk namespaces since those have already been processed. SSastry (WMF) (talk) 19:51, 5 December 2017 (UTC)

@Anomalocaris: this is now done. All pages in the remaining namespaces have been processed. SSastry (WMF) (talk) 22:04, 8 December 2017 (UTC)

SSastry (WMF): I don't think so. User talk:BCTransResearch has a Paragraph wrapping bug workaround, but there is only one page listed for that lint error, and it's a different page. Also, User talk:BCTransResearch's page information page reports no lint errors, but just editing it you can see an obsolete <center> tag right there on the third line. On the same line is a <small> tag missing its end tag and a stripped <font> tag. I would bet there are thousands more pages that haven't been processed. —Anomalocaris (talk) 23:52, 8 December 2017 (UTC)

@Anomalocaris: indeed! The script had a bug that would only process one namespace fully and so, so far, it has processed article, talk, and template namespaces. I think I have the bug nailed this time and will report once the script finishes. SSastry (WMF) (talk) 18:56, 9 December 2017 (UTC)

@Anomalocaris: looks like all is well with the script. It has been chugging away processing pages in all the other namespaces. SSastry (WMF) (talk) 21:08, 10 December 2017 (UTC)

@SSastry (WMF):: Last week, I emptied out the deletable table tag in article space page (still not a Wikipedia Category, which would be a lot easier to work with), and today, there are pages listed on the page that have not changed in many months. For example, Province of A Coruña has not been edited since 17 May 2018 (more than four months ago), but it just appeared on the page in the last day or two. Unless I'm missing something, that means that the Linter error pages (please make real Categories!) are still not fully populated. Can you please investigate? Thanks. (possibly related: T157670) – Jonesey95 (talk) 09:20, 3 October 2018 (UTC)

@Jonesey95:, Note that pages can have new lint errors introduced when any of its templates (or any of the templates they in turn use) changes in some way. Pretty much every entry in there seem to be have errors in template generated code. So, my hunch is that this is the reason why you are seeing this now. I can investigate more closely later on if required, but I wanted to get this preliminary response out in case it is helpful. SSastry (WMF) (talk) 18:02, 3 October 2018 (UTC)

Thanks for the quick response. I understand what you are saying, but I do not think that a change in an underlying template is causing these pages to appear in the Linter list. Province of A Coruña, for example, has a very straightforward error, a table opening followed by another table opening. The page has not been changed since 18 May 2018. The first table opening is on the page itself, and the second table opening is in Template:A Coruña Province Population 18th Century, which hasn't been modified since 15 February 2018‎.

The simplest explanation is the one described in the phab ticket that I linked above, or something similar: pages go for too long without being refreshed, or having their links refreshed, or whatever the technical term is, which means that errors are not accurately tracked by categories (or by semi-randomly-ordered lists of pages with errors). Take a look at the comment dated 17 Feb 2017 in the phab ticket, posted by Legoktm; at that time, there were apparently millions of pages on en.WP that had not been refreshed for years. If you have a better explanation, I would love to hear all about it, especially if it comes with some sort of fix attached. Thanks.

[Edited to add: One thing I don't understand is why Province of A Coruña didn't end up in the list when it was edited on 18 May 2018, since AFAIK, the appropriate linter list page existed at that time. I could be wrong though; I know that the list of lists has been modified over time, although frustratingly, Special:LintErrors does not have a viewable page history – I wish this whole lint error system were friendlier to editors who are used to working on error categories and normal WP pages.]

[Edited to add again: All of the Citation Style 1 templates were updated 3-4 days ago, which means that millions of pages are slowly getting refreshed by the job queue, as long as it works the way I think it does and doesn't get tired and give up. So that could explain why these articles are showing up. It doesn't explain why the edit of 18 May 2018 didn't put the article on the list, or why, when Claudius was edited on 24 Sep 2018, it didn't go onto the list. The latter event, with Claudius, is a complete mystery to me. The list was completely empty, zero pages, last week, sometime after 24 Sep 2018. I'm used to tracking categories, which have their known quirks, but the lint error pages are a black box to me. Is there any chance that we can get them converted to real categories?]– Jonesey95 (talk) 18:28, 3 October 2018 (UTC)

@Jonesey95:, I will try my best to explain with the information I have currently. Around January 2018, I ran all pages on all wikis through the linter to "initialize" the linter database against all known linter categories. There are a number of reasons why some pages with errors could go missing in a specific Linter category. The core reason is this: losing linter errors is not a catastrophic error, i.e. it does affect the correctness of any critical products (besides linter results). So, if there are any errors (transient or otherwise) in any of the tools in the pipeline, linter errors can get dropped. When a page is edited (or when a template is edited that causes a page to be reparsed), it is picked up by a change propagation service and added to a queue. Parsoid is then asked to reparse the page. Parsoid then generates the lint errors and sends any lint errors to the MediaWiki API which then pushes them on to a job queue. When these jobs are processed by the Linter extensions, it updates the linter database. So, failures in any of these steps can cause lint errors to get lost. As you can tell, I am handwaving a bit since we haven't investigated where in the entire pipeline this might actually be happening, but that is because we don't consider lost lint errors a problem serious enough to warrant hardening any of these steps to prevent that. I understand it can be frustrating to editors when you find new entries in lint categories that you thought you had already addressed. Presumably (and it seems to be the case) the volume of such entries is fairly small. 22:09, 4 October 2018 (UTC)

@Jonesey95: At this time, we are a small team that does not have a dedicated person charged with developing and improving the Linter extension on an ongoing basis. When we did our initial work on this, we hadn't anticipated the volume of lint errors and all the various ways that editors might eventually want to slice and dice that information. We had to do a somewhat quick job of it to support the Tidy replacement effort without extending that timeline a whole lot. But, now that that milestone is behind us, we will have to redo some of our original database schema and when we are able to do that, we will get around to addressing some of the feature requests and bug fixes on the Linter extension. SSastry (WMF) (talk) 22:09, 4 October 2018 (UTC)

Thanks for the detailed (albeit hand-wavey) explanation. I figured it was something like that, since I have seen many similar things happen with categorization (see the phab link above). One thing I will add is that while Linter errors are not "catastrophic", things like missing table end tags can sometimes cause whole sections of pages to simply vanish when rendered, which I would rank somewhere above "minor/cosmetic". Good luck with your enhancements. We'll keep plugging away. – Jonesey95 (talk) 04:40, 5 October 2018 (UTC)

While working on table tag errors, which are quite interesting, I stumbled across Greek football clubs in European competitions, which had over 1,000 Linter errors, mostly missing end tags (crazy diff here!). I was able to fix them with a series of find-and-replace operations, so it wasn't too bad. Is there a way to find pages with many Linter errors? We could reduce our total count more quickly if we could knock out these busy pages.

I have also found in working on the table tag list that one missing or extra table tag can cause Linter to report that the page has half a dozen errors. Fixing the table tags often takes care of all of the problems, so it's a fruitful list to work on. I have found that most of the problems are due to a stray opening table tag that should be deleted, or a missing table end tag, often because a header template opens a table. – Jonesey95 (talk) 10:43, 30 August 2018 (UTC)

Ah, sports tables. The bane of my linting existence. The number of errors in the tables max at 20 for a particular page. phab:T151362 is a suggestion which kind of works around the issue, so that we could see more entries per page, but I think a task specifically for prioritizing counts would be great.

Also, good job getting table tag down from whatever X thousand it was at! --Izno (talk) 14:07, 30 August 2018 (UTC)

Thanks for the info. I've been working mostly on templates (and userboxes, though it looks like someone has already fixed most of them), some of which are used on many pages. I really wish we had these linter error groups as hidden categories instead of these janky Special pages, which are a pain to work with. It would be very useful, for example, to see all pages in a category listed alphabetically, or to be able to use petscan to search the category for pages that use a certain template. – Jonesey95 (talk) 17:10, 30 August 2018 (UTC)

I'd still like a way to show a list of pages with the most errors. Maybe a list of 1,000 pages with the most errors, or a way to request a list/table of all pages with 20 or more errors (and what types of errors exist on each page). It's fine with me if this report is limited to article space. Does anyone know how to create such a list? – Jonesey95 (talk) 10:50, 4 October 2018 (UTC)

Jonesey95, try WP:BOTREQ, since it'd likely require a script to go through the errors every week or so and find the pages with the most errors. Galobtter (pingó mió) 11:01, 4 October 2018 (UTC)

I could swear there's a task on phab for 'most errors'; I would support a bot report or similar for specific pages with many errors, mainspace only (to start). --Izno (talk) 14:49, 4 October 2018 (UTC)

Izno Done, the wonders of WP:QUARRY - see [4] and User:Galobtter/Articles_by_Lint_Errors Galobtter (pingó mió) 19:13, 14 October 2018 (UTC)

Jonesey95 ^ --Izno (talk) 19:42, 14 October 2018 (UTC)

@Jonesey95 and Izno: it should now automatically update daily Galobtter (pingó mió) 12:33, 17 October 2018 (UTC)

Daily! Yikes, I'd better step up my editing. Thanks again! – Jonesey95 (talk) 15:11, 17 October 2018 (UTC)

There appear to be about 1,000 to 2,000 Template:DYK nomination pages that are fixable with this edit. Someone with AWB or a bot should be able to make quick work of it. I don't mind 100 pages of tedium, but a couple thousand is too many for me. The list of affected pages is available here. – Jonesey95 (talk) 14:33, 4 October 2018 (UTC)

Just about 1.8k. I can file a BRFA for User:IznoBot sometime soonly. --Izno (talk) 01:59, 9 October 2018 (UTC)

Izno: How hard would it be to create a bot to continue the fixes like my edit of 1943 All-Ireland Senior Camogie Championship, starting with 1945? —Anomalocaris (talk) 05:46, 10 October 2018 (UTC)

I created a script to fix them, and I think I got them all. – Jonesey95 (talk) 08:53, 10 October 2018 (UTC)

Someone has worked through about half of the ones here. Down to just about 900. I submitted a BRFA anyway. --Izno (talk) 03:10, 18 October 2018 (UTC)

Moved from BRFA:

here you go. – Jonesey95 (talk) 04:36, 19 October 2018 (UTC)

@Jonesey95: I'm not getting results with that link. :D Oh boy! --Izno (talk) 04:58, 19 October 2018 (UTC)

Oh, it was searching for articles. I will have to double check the other search was definitely in template space. --Izno (talk) 04:59, 19 October 2018 (UTC)

Yup, just the 70 when I search in template space. I'll go plop a note on Xaos's page. --Izno (talk) 05:00, 19 October 2018 (UTC)

Just finished these on my AWB account since there were so few. --Izno (talk) 05:09, 19 October 2018 (UTC)

I would like to know the reason why the Obsolete tag 'Font' should not be removed before removing Tidy bug affecting font tags wrapping links. If you can, please provide an example.Adithyak1997 (talk) 18:30, 19 November 2018 (UTC)

This section explains how to fix the font-tag-wrapping-link error using a span tag. Similar instructions are here. The goal is to preserve the original editor's intent about how they wanted the text to look. – Jonesey95 (talk) 19:16, 19 November 2018 (UTC)

The Firefly Tools page Outstanding linter errors on enwiki hasn't been updated since 2018-10-04 17:37:53. What's going on? —Anomalocaris (talk) 20:56, 8 October 2018 (UTC)

Jonesey left a comment at Firefly's talk page about it. --Izno (talk) 21:33, 8 October 2018 (UTC)

Izno, Jonesey: Where is that? —Anomalocaris (talk) 01:48, 9 October 2018 (UTC)

Wrong Jonesey. See above thread. He went to user talk:Firefly. --Izno (talk) 01:53, 9 October 2018 (UTC)

Izno, Jonesey95: Thanks. That might not help, as Firefly's last edit was 4 August 2018. —Anomalocaris (talk) 05:34, 10 October 2018 (UTC)

It's possible the related API somehow got clobbered with the new software release on WP:THURSDAY. --Izno (talk) 22:51, 8 October 2018 (UTC)

As far as I can see, the code does not use any APIs but database queries Galobtter (pingó mió) 15:58, 16 October 2018 (UTC)

It has been two weeks. What does it take to get this page to refresh? —Anomalocaris (talk) 15:05, 16 October 2018 (UTC)

Firefly doesn't seem to have been active since August 4. Probably for him to start up the tool/fix whatever issue it is having and start it Galobtter (pingó mió) 15:58, 16 October 2018 (UTC)

I actually don't have any experience in this field but I have some basic knowledge in programming and interest also. So I have requested in phabricator(https://phabricator.wikimedia.org/T209147) for adopting this tool.Adithyak1997 (talk) 18:22, 12 November 2018 (UTC)

@Anomalocaris:,@Jonesey:,@Izno:,@Galobtter:, The tool has currently been updated except the page Long redirects. Instead of 10 minutes, it will be updated every 15 minutes.Adithyak1997 (talk) 18:30, 25 November 2018 (UTC)

Nice work, Adithyak1997! Galobtter (pingó mió) 18:36, 25 November 2018 (UTC)

Since I am a newbie to tools in wikipedia, I was helped by many members of wikimedia cloud and Phabricator. The tool has some more problems which will be solved within 1 to 2 days.Adithyak1997 (talk) 18:40, 25 November 2018 (UTC)

Thank you! – Jonesey95 (talk) 19:18, 25 November 2018 (UTC)

On the Interstate 81 in New York page, I sometimes see 719 "stripped tag" errors when I load LintHint. Then, if I preview the page or purge it or load its contents into Special:ExpandTemplates, sometimes LintHint shows as green (no errors). Can someone reproduce this odd situation and possibly explain it? – Jonesey95 (talk) 13:25, 26 November 2018 (UTC)

@Jonesey95:, does this tool shows in other pages, the errors during preview screen? In my view, there are no tr and td tags present in the page. All has been done by using '|' I think.Adithyak1997 (talk) 13:46, 26 November 2018 (UTC)

Actually, I don't know anything about ExpandTemplates. But when I ran the code through an external HTML5 validator, it shows that 'The string mw-deduplicated-inline-style is not a registered keyword'([link]).Adithyak1997 (talk) 13:52, 26 November 2018 (UTC)

The table tags are in Template: Jctint/core. I see similar problems in Business routes of U.S. Route 31 in Michigan and Interstate 87 (New York), among others. Also see this talk page discussion, where I am possibly going down the wrong rabbit hole. – Jonesey95 (talk) 14:01, 26 November 2018 (UTC)

I don't have the regex skills to fix this one, but here's a search link showing 134 instances of {{nowrap|{{marriage, which produces a div-span-flip error. The nowrap template wrapper should be removed. – Jonesey95 (talk) 08:32, 24 October 2018 (UTC)

Or one could replace it with <div class = "nowrap"> Galobtter (pingó mió) 08:57, 24 October 2018 (UTC)

Our obsession with nowrap probably should just die. :) --Izno (talk) 14:55, 24 October 2018 (UTC)

I played around with leaving it versus removing it, and I couldn't see a difference. Maybe my web browser works a little differently from other editors' browsers. I fail to see how putting a nowrap around a marriage template inside an infobox would provide any benefit to anyone. Demonstrations / test cases are welcome. – Jonesey95 (talk) 15:01, 24 October 2018 (UTC)

I'm a firm believer that Nowrap is almost never appropriate, and should be removed whenever possible. pauli133 (talk) 16:25, 31 October 2018 (UTC)

These are  Done. I sharpened up my regex skills and managed to fix most of them with a script. – Jonesey95 (talk) 16:25, 27 November 2018 (UTC)

I have a small doubt regarding the issue with signature. Please check [[ https://en.wikipedia.org/wiki/User_talk:Adithyak1997#Regarding_%22user_rights_issue%22]] link. I have doubt whether this is the cause of signature issue.Adithyak1997 (talk) 05:03, 29 November 2018 (UTC)

Adithyak1997: I do not see any errors there. Perhaps you meant to post this query on a different page? This page is for discussion of Linter, which attempts to clean up invalid wikicode on pages on Wikipedia. – Jonesey95 (talk) 05:45, 29 November 2018 (UTC)

Hi, Unrelated question - Last year I sent out a Christmas message which ended up containing many lint-issues/errors anyway I wanted to ask if someone could kindly check User:Davey2010/Merry Christmas box and update or remove any lint errors if there are any,
User:Anomalocaris checked it last year but it's not fair to ask them to check it every year so was wondering if someone here could be so kind as to check it for me,
Many thanks, –Davey2010^Talk 23:24, 19 December 2018 (UTC)

@Davey2010: You can check to see what kind of linter errors exist by looking at the page info. In this case, none. --Izno (talk) 23:40, 19 December 2018 (UTC)

Hi Izno , Ahhhh I've just viewed https://en.wikipedia.org/w/index.php?title=User_talk:Davey2010&action=info where it shows Lint errors, Ahhh right I didn't even know errors showed there, Ah right I'll look there infuture, Many thanks for your help :), –Davey2010^Talk 23:50, 19 December 2018 (UTC)

I had a question for you all. Now that Tidy has been replaced and you can actually see the impact of linter errors on pages, do you still see the need for the ParserMigration extension that shows the side-by-side preview with Tidy and Remex? We were planning to completely remove Tidy from the cluster which means the ParserMigration extension will no longer be usable in its current form. We'll repurpose it in the future for other such parser changes in the future, but for now, if we remove Tidy, we will effectively disable that extension.

SSastry (WMF) (talk) 21:37, 4 September 2018 (UTC)

Izno, Anomalocaris, any thoughts? SSastry (WMF) (talk) 20:31, 7 September 2018 (UTC)

Please retain Tidy in some form so that editors can see what pages looked like under Tidy and preserve the original appearance. Yesterday I spent a ridiculous amount of time trying to preserve the appearance on User:Hecseur, and suddenly I realized two things. First, that the appearance had probably changed with change of linters, and second, that I could view the page with parsermigration-edit, highlight the problematic section in the Tidy version, view source, and thereby snatch the effective markup, which I could properly code without lint errors. That's just one example of how parsermigration-edit is necessary to those of us working to fix lint errors. — Anomalocaris (talk) 21:31, 7 September 2018 (UTC)

I've been letting this percolate into my brain, so thank you for the reminder. ;) I don't have a problem ditching it, since errors now should be obvious on the page. I didn't personally use it all that often though, so, one of the other page watchers might have a greater attachment to it. The problem of course in some cases is matching intent, as Anomalocaris says, and you can't always get that just by knowing where the problem is. I don't think that's super great value, because most of the time you can get to the answer that the original editor had in mind, or if you make the edit and he says that's broken, you can talk about what he means for something to look like. --Izno (talk) 21:33, 7 September 2018 (UTC)

Thanks Izno, Anomalocaris: thanks for your input. Anomalocaris: that page looks like an instance pretty badly nested markup. From your comment, it appears that in the common case, it is not as relevant anymore. Is that correct? SSastry (WMF) (talk) 13:45, 11 September 2018 (UTC)

It is not unusual for User and User Talk pages to have markup that is much worse than the User:Hecseur page had. (Nice work, Anomalocaris!) LintHint shows 541(!) total Linter errors on User:the ed17/Archives/9/B, for example, and that's not cherry-picking on my part – it was listed on the first page of misnested tags.

We still have 595,238 instances (on the firefly page) of misnested tags on User Talk and 26,986 on User pages as of this writing. I think we'll need a comparison tool for a while. – Jonesey95 (talk) 18:52, 11 September 2018 (UTC)

Jonesey95: FWIW, User:the ed17/Archives/9/B has only 2 high-priority lint errors, Multiple unclosed formatting tags. It has 45 medium-priority lint errors, Misnested tags. All the rest are low-priority. The total number of lint errors isn't what drives the difficulty in cleaning them up. 100 obsolete <strike> tags can be dispensed with very quickly, but a Table tag that should be deleted can be quite subtle, and a single short snip of Wikitext with several misnested tags can be much harder to disentangle than when the misnestings are isolated from each other. —Anomalocaris (talk) 08:17, 12 September 2018 (UTC)

Jonesey95, As Anomalocaris noted, ParserMigration is only useful for the high-priority categories where the lint issues were related to Tidy's use. SSastry (WMF) (talk) 13:48, 12 September 2018 (UTC)

Thanks for the clarification, I guess. By the counts on the Lint errors page, there are over five million high-priority errors left to fix, so if Tidy is still useful for those, we have a way to go before it should be removed. Maybe I misunderstand. As for the table tags that should be deleted (or added, contrary to the name of the error group), I have been working on those in article space; they are good fun, and a nice challenge. – Jonesey95 (talk) 17:57, 12 September 2018 (UTC)

So, I finished up the apostrophe-in-headings issue yesterday and my experience was that ParserMigration didn't really help with that issue. I've seen it in the multiple-unclosed-formatting tags issue too and it doesn't help there (which usually blends with misnested-tags). With extra-tables, I definitely have not found it useful. I would definitely be in favor of turning it off. (Speaking of apostrophes, does anyone know some friendly admins to take care of the three protected archives?) --Izno (talk) 02:04, 9 October 2018 (UTC)

We disabled the parser-migration extension today prior to this week's MediaWiki train deployment. Tidy has been slowly purged from the codebase and configuration and this week's MediaWiki train would completely remove Tidy which means ParserMigration would no longer work. SSastry (WMF) (talk) 20:44, 10 December 2018 (UTC)

SSastry (WMF): Oh, I just found out about this. I was editing a File space page and trying to preserve appearance, so I compared the existing linty page to the preview of my delinted page, and it didn't match because now, Tidy bug affecting font tags wrapping links doesn't happen any more, so I wanted to see what the page looked like when the linty markup was added, and I couldn't because ParserMigration has been disabled. Is there any way of seeing what a page looked like under Tidy? —Anomalocaris (talk) 09:47, 28 December 2018 (UTC)

Sorry, there isn't a way to see what a page looked under Tidy (except in some cases via archive.org, but that is tedious). My recommendation is to fix the page without referencing Tidy, i.e. is it possible to assess the need for the presence / absence of color without having to rely on Tidy? SSastry (WMF) (talk) 19:42, 30 December 2018 (UTC)

SSastry (WMF): The issue comes up on mainly in user signatures on File, Wikipedia, and all kinds of talk pages, especially pages that are self-described as archives that shouldn't be edited. On those pages it's legitimate to fix errors while preserving appearance. —Anomalocaris (talk) 23:41, 1 January 2019 (UTC)

As I have stated, I do not see a reason for Tidy in that use case. It's obvious where the issues are just by looking at the page. --Izno (talk) 23:55, 1 January 2019 (UTC)

Izno: Of course it's obvious where the issues are. It's sometimes subtle to determine what those hot spots looked like under Tidy. If one makes a mistake in one's replacement code, for example, accidentally entering something like <span style="color=black"> instead of <span style="color:black">, the ability to compare with the target appearance is one way to reveal such mistakes, and it's a method upon which I have relied for over a year. —Anomalocaris (talk) 22:54, 2 January 2019 (UTC)

"I might make a mistake" doesn't really strike me as a terrible problem with these issues seeing as these are all super-low priority already. Worst comes to worst, you can always revert your mistaken revision and then make a new edit to fix the problem. --Izno (talk) 23:47, 3 January 2019 (UTC)

Copied from a post that I wrote at Wikipedia:Help Desk: Here is my workflow:

1. Enable the Syntax Highlighter gadget in Preferences -> Gadgets (I have this permanently enabled).
2. Pick an error and a namespace that you want to work on.
3. Go to Special:LintErrors and click through to that error and namespace.
4. Click on a page that you want to look at. Click Edit, then click the LintHint yellow button to get a list of errors.
5. Each error has a "down arrow" that will take you to that error (unless it's in a big block of interpreted code that LintHint can't see inside, in which case it will highlight the whole block).
6. If you can see and fix the error, fix it. The help text linked from the question mark at the upper right of the Special:LintErrors page may help. I say may help, because it's not very good. If the explanation doesn't help, post at Wikipedia talk:Linter, and I'll explain and improve the help text.
7. Use Special:ExpandTemplates to expand those pesky big blocks of code that LintHint can't see inside. Copy the block and expand it, then run LintHint and arrow down to each error.
8. If you fix the Lint error, click on the next down arrow to fix the next error. Note that if you have added or removed text, the down arrow's target will shift by that number of characters. That means that it may be easiest to fix from the bottom up. You can also Preview and click the LintHint button again to reset the list of errors.

You can look at my Contributions for sample fixes. Note that the Syntax Highlighter chokes on unclosed br tags, so I have a script that adds closing slashes to all of them before I start looking at a page. I also recommend https://tools.wmflabs.org/fireflytools/linter/enwiki as a useful page for "keeping score" and getting a sense of the size of each group of errors in each namespace. – Jonesey95 (talk) 06:15, 1 February 2019 (UTC)

Nice, thanks for that. I noticed that if you have the "add extra buttons to the ... editing toolbar" option selected (which gives you a different syntax highlighter which I feel is somewhat superior), you get a similar result; I found that when clicking "edit" it highlights the section. I went through your method and never saw the LintHint button, but then I got sucked in to fixing just about every horse race ever and haven't had a chance to dig deeper. Primefac (talk) 12:14, 1 February 2019 (UTC)

Oh yeah, those dam horse races. I've fixed a few of those. There are far too many. Thanks for taking them on.

You might find {{smalldiv}} useful. I created it when I couldn't find an elegant way to replace small tags wrapping bulleted lists.

I tried the other syntax highlighter when it first came out, but I couldn't get it to work with my browser, so I went back to the old one. Maybe I'll give it another look. (edited to add: For editors interested in making a dent in article space, User:Galobot/report/Articles by Lint Errors is a fun report, updated daily.) – Jonesey95 (talk) 13:17, 1 February 2019 (UTC)

I remove small categorically (I've voiced this before) since it is almost always inappropriate in its context. --Izno (talk) 14:49, 1 February 2019 (UTC)

Yeah, the majority of those horserace pages really didn't need to have the divs making the text smaller, but given how many there I figured I should leave well enough alone... Primefac (talk) 15:41, 1 February 2019 (UTC)

There was a recent request for Template Editor in order for the user to fix linter errors inside of template-protected templates. In going through some of the linter categories, I couldn't find any specific templates that would need this sort of fixing, but I'm also a bit out of the loop as far as linter goes these days - is there an easy/fast way of determining which/how many WP:TPROT templates have linter errors in them? I know from doing some cleanup the other day that the "found in templates" link on Special:LintErrors doesn't necessarily mean that the error is in the template. Primefac (talk) 11:42, 28 January 2019 (UTC)

The only way I know of to find Linter errors within templates is to manually scrub the list of Template pages at Special:LintErrors. Multiple editors have cleaned up more than 98% of all actual templates (not including DYK pages) with Linter errors, I believe (they are still out there, though; here's one I fixed a couple of days ago). Unfortunately, those Special:LintErrors template pages are littered with DYK nominations, which are in Template space due to some accident of history. There are only about 1,600 high- and medium-priority errors left in all of Template space, almost all of which are either: DYKs with editor signature issues, or sandbox/testcase pages.

Some Linter errors in templates show up only when those templates are used, or used with certain parameters, in another namespace, so the only way to find them is to stumble upon them while editing in another namespace.

You are also correct that the "Through a template" column on the LintErrors pages typically indicates that the error occurs somewhere within the template's transclusion on the page, not within the template itself. In the past, it was the case that there were many templates with Linter errors, but a few of us gnomes have fixed the vast majority of pages that are transcluded, including templates and userboxes (there were a LOT of userboxes with Linter errors, and there are probably still a decent number left that aren't categorized or listed on the userbox directory pages).

At this point, I suggest that any editor who thinks they have found a Linter error in a template should edit the template's sandbox with a proposed fix, and show that the fix works using that template's testcases page. I have User:AnomieBOT/TPERTable on my watchlist, so any templates with edit request templates will come to my attention pretty quickly.

I would be happy to support template-editor access for any editor who shows competence at the process I have described. Potential template editors need to demonstrate competence and trustworthiness through their edit history, not just a stated desire to edit templates. – Jonesey95 (talk) 12:24, 28 January 2019 (UTC)

On your last point, I completely agree; my query here is mostly to determine if this is a "there are thousands and it will take a year" or "there might be a dozen or two and we could clean it up in three months" sort of situation. Primefac (talk) 12:38, 28 January 2019 (UTC)

I believe that we are a lot closer to the latter. We have picked all of the low-hanging fruit in Template space. There are no doubt a dozen or two left, but it will take a while to track them down, because the only way to find them with the tools we have is to stumble upon them as we fix pages in other namespaces. Given that there are still a few million high- and medium-priority errors, that fixing will take a while. – Jonesey95 (talk) 12:49, 28 January 2019 (UTC)

Most of the problem templates have been taken care of over the past year or so, but there's still Taxobox/Speciesbox screwing up how it handles small tags on authorities. It's deep, but it hits a LOT of pages.pauli133 (talk) 16:15, 4 February 2019 (UTC)

Can you please link to some example pages where taxobox/speciesbox is causing Linter errors? I think that I have fixed a few, but I'm happy to take another look. Thanks. – Jonesey95 (talk) 20:45, 4 February 2019 (UTC)

There is a new Linter error: Special:LintErrors/wikilink-in-extlink. – Jonesey95 (talk) 07:38, 10 March 2019 (UTC)

I have a small doubt. Does this category have a lintercounts.value? Please check [this] page line 30 to know what I mean by that.Adithyak1997 (talk) 11:44, 10 March 2019 (UTC)

Pinging SSastry (WMF). I am unable to find documentation at mediawiki.org on this "lintercounts" variable. – Jonesey95 (talk) 14:03, 10 March 2019 (UTC)

No, this isn't part of the output of the linter. Is this generated by this file? SSastry (WMF) (talk) 00:48, 11 March 2019 (UTC)

I think it's from the file you mentioned. The problem is that I haven't yet made significant edits to this tool.Adithyak1997 (talk) 03:15, 11 March 2019 (UTC)

From the numbers in that file, I would guess that adding "18" after "11" might work. – Jonesey95 (talk) 05:54, 11 March 2019 (UTC)

@Jonesey95: I have made the edit but it didn't work for me.Adithyak1997 (talk) 15:10, 11 March 2019 (UTC)

Did you get an error message? Any sort of output that indicates the problem? It looks like https://tools.wmflabs.org/fireflytools/linter/enwiki has not been updated in at least 50 minutes (without a time zone in the timestamp header, I can't tell exactly when it was updated). – Jonesey95 (talk) 15:16, 11 March 2019 (UTC)

I didn't get any error messages now. But in the morning, I got 2 emails with the heading [Cloud VPS alert] Puppet failure on tools-sgeexec-0905.tools.eqiad.wmflabs. The page is updating now I guess but the problem is not resolved yet.Adithyak1997 (talk) 15:18, 11 March 2019 (UTC)

I see that the page updated 20 minutes ago. It looks like the time stamp is UTC time. I do not, however, see the new Linter error listed. SSastry (WMF), do you know anyone who might be able to help with this? I think we're looking for the "linter_cat" number for this new error. I see linter_cat used on pages like https://phabricator.wikimedia.org/T173943 and https://quarry.wmflabs.org/query/31876 and https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Linter/+/403318/3/includes/CategoryManager.php but I don't understand github well enough to dig through and find the list of error types and their corresponding linter_cat numbers. – Jonesey95 (talk) 15:41, 11 March 2019 (UTC)

It is 18 and Adithyak1997's script already includes it. I don't know if the VM that runs fireflytools has been updated to use the latest code. If that updating is done via puppet, then the puppet failures above might be the reason. Best to ask help on the wikimedia cloud services mailing list or their IRC channel. SSastry (WMF) (talk) 16:34, 11 March 2019 (UTC)

@SSastry (WMF): That change has come in the tool in which the updation occurred horizontally after Category Talk. Do you have any other solution?Adithyak1997 (talk) 13:45, 12 March 2019 (UTC)

@Adithyak1997: Sorry I don't understand what you mean by: "updation occurred horizontally after Category Talk". What is not working? SSastry (WMF) (talk) 16:25, 12 March 2019 (UTC)

In the Fireflytools page, please check the table. In that, please see the line after Category Talk.Adithyak1997 (talk) 16:39, 12 March 2019 (UTC)

I don't know why the new row is there, but a new "Links in links" column has appeared! That's progress. – Jonesey95 (talk) 17:41, 12 March 2019 (UTC)

But the tool has currently stopped working. I migrated the tool from Trusty to Stretch which caused the cron jobs to stop. I tried many methods to make it right but it is not worked.Adithyak1997 (talk) 17:56, 12 March 2019 (UTC)

@Jonesey95:, @SSastry (WMF): I guess the tool started working again.Adithyak1997 (talk) 14:34, 15 March 2019 (UTC)

Great! Nice work! :-) It is a useful tool. SSastry (WMF) (talk) 18:56, 15 March 2019 (UTC)

Resolved

I don't know when it happened, but the Linter error list pages are no longer sortable. They were fine a week or two ago. They don't have a page history showing what might have changed, so I don't know how to fix this problem. Can one of the page watcherts fix this problem? – Jonesey95 (talk) 10:13, 2 April 2019 (UTC)

It may have been deliberate? Was it sorting only the displayed page? @SSastry (WMF): I think there was some work done on the special page recently that probably removed this. --Izno (talk) 16:26, 2 April 2019 (UTC)

I don't remember sorting feature on special pages .. I wonder if User:Jonesey95 is referring to the firefly tools page. SSastry (WMF) (talk) 17:37, 2 April 2019 (UTC)

The columns on this page and similar pages had been sortable for as long as I can remember. I use the sorting feature all the time to sort by the offending bit of text, or by the template that is being used, or by the page name. They were sortable only on a per-page basis (please don't get me started again on these errors needing to be collected in actual Wikipedia categories, not weird 200-entry portholes in no reasonable order). – Jonesey95 (talk) 20:02, 2 April 2019 (UTC)

It has never been sortable for me, and the git blame for the code shows that it has not been sortable from the very beginning. So, perhaps you had some CSS or JS that made it sortable on a per-page basis? SSastry (WMF) (talk) 21:17, 2 April 2019 (UTC)

Wow, that's disturbing. I have definitely been able to sort those pages. I haven't changed any of my CSS or JS for a long time. Or else my memory is completely failing me, which of course happens, but I am pretty darn confident in it this time. – Jonesey95 (talk) 04:15, 3 April 2019 (UTC)

Update: Sortability of the tables has returned. Maybe I just needed to take a one week wikibreak. Thanks to whatever WMF gnome fixed it. – Jonesey95 (talk) 08:12, 2 May 2019 (UTC)

Why does for example lintHint report "Missing end tag: p" for the below wikitext or for a lone <p>, when the end tag isn't required in HTML5?

<p>text

Is it somehow because the parser is adding the end tag?

Is the reporting of this as a lint error desirable for some reason, or is it just noise? --Pipetricker (talk) 13:40, 3 February 2019 (UTC)

Under the hood, Linter is using the Remex extension, which is using the HTML 5 parsing algorithm. That algorithm doesn't necessarily match where elements are permitted (or their absence permitted) in the specification-proper. The p element is one of those points. --Izno (talk) 14:57, 3 February 2019 (UTC)

That said, I'm amused that the above wikitext emits an error when it outputs the escaped element. --Izno (talk) 14:58, 3 February 2019 (UTC)

Izno, I've had this same question for a while, and I do not understand your answer. It has a lot of words in a row, but it doesn't really tell us whether the "error" is real, or noise, or what action to take.

I definitely have not been "fixing" unclosed p tags. They seem fine to me. I learned HTML in the mid-1990s, though, so I may be having a "get off my lawn" moment. – Jonesey95 (talk) 17:35, 3 February 2019 (UTC)

Somewhat related, if I come across lone </p> tags I do deal with them, sometimes by removing or sometimes with <p></p> (Usually hit these on small wikis in languages I don't speak, and not sure what the editors may be trying to do, espc in some templates). — xaosflux ^Talk 17:40, 3 February 2019 (UTC)

I don't really understand it myself, since my expectation would be that the parsing algorithm and the standard would allow for the same code in the same place at the same time. I can write a human-readable-standard-conformant document, but for the parsing algorithm have that parsed DOM be non-conformant, which is in a separate section of the document... It's really a question for SSastry (WMF). --Izno (talk) 18:03, 3 February 2019 (UTC)

Lint detection is in Parsoid, not Remex. That is just an FYI. As for the p-tag, if you look at the spec, it is not always optional (for example, if followed by a span or other "inline" / "phrasing" tags). But, you are all right. Strictly speaking, Linter reports false positives for missing-end-tag for p-tags in many cases. That said, not everyone is likely to be able to keep the above difference in mind. So, overall, my opinion is that you (collective you) are less likely to make inadvertent markup errors when end tags are explicit. As it stands, end tag linter errors are the lowest priority errors. Clearly, most HTML5 parsers (and browsers) infer where they ought to be present even for non-optional end tags. The same arguments for adding missing end tags for other tags also apply to p-tags. Being consistent helps with keeping things simple instead of having to know the subtlety of the HTML5 spec as to where it is optional and where it is not. Hope that helps. SSastry (WMF) (talk) 23:17, 4 February 2019 (UTC)

Izno, Jonesey95, Xaosflux: I cannot get Pipetricker's w3.org external link to work, but according to Mozilla, for the <p> tag, "[t]he end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <div>, <dl>, <fieldset>, <footer>, <form>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <header>, <hr>, <menu>, <nav>, <ol>, <pre>, <section>, <table>, <ul>, or another <p> element, or if there is no more content in the parent element and the parent element is not an <a> element."^[1] However, it is annoying to have the linter reporting missing end tags for <p>, especially when the unclosed tag is in a template, whether in the template space or in another space but used like a template, and therefore I believe that templates and other reused items should close all <p> tags whether or not the closing tag is strictly required. The KISS principle suggests that SSastry (WMF) is correct. It is a low priority lint error, but if one is fixing lint errors in an article or page anyway, one might as well fix all of them, including unclosed <p> tags, which is probably less work than carefully deciding which ones are strictly speaking not errors, and leaving them for other editors to inspect forever. It's simpler to just fix them than to invest brain cycles deciding if they need to be fixed.

—Anomalocaris (talk) 07:17, 10 May 2019 (UTC)

I think there should be another category of lint error, "Obsolete HTML markup", probably low priority. It would include markup such as aligning table cells using

|align="center" | Content

or

|align=center | Content

instead of

|style="text-align: center;" | Content

—Anomalocaris (talk) 17:42, 3 September 2019 (UTC)

This is phab:T173944. --Izno (talk) 17:45, 3 September 2019 (UTC)

Editors have the ability to customize their signatures (inserted with four tildes) using HTML code. If these signatures have Linter errors in them, a new Linter error will be introduced to a page any time that editor inserts their signature. This makes me think that signatures need to be checked for Linter errors before editors are allowed to save custom signatures.

My guess is that signatures are not currently checked for Linter errors, based on a very recent signature I found on a discussion page:

*'''Support''' per other editor '''―[[User:redacted|<span style="color:red">redacted <span style="color:blue">redacted]] <sup>[[User talk:redacted|<span style="color:black">talk]] / [[Special:Contribs/redacted|<span style="color:blue">contribs</span>]]</sup>''' 07:19, 28 December 2018 (UTC)

I have obfuscated the personal information and the time stamp in the above signature (the date is accurate), because it's not important who wrote it, just that the code is missing span end tags. Does anyone know if signatures are being checked for Linter errors upon saving? If not, I think we should submit a phab request. – Jonesey95 (talk) 08:26, 16 January 2019 (UTC)

Never mind, I found it. It's bug T140606, over two years old. Until it is fixed, it is going to be very frustrating to try to make real progress on cleaning up talk pages, and we'll have complaints about "flooding of watchlists" and other such nonsense when we fix the Linter errors. Related: T178879. Is "Tidy bug affecting font tags wrapping links" really a "High-priority" error if the WMF is willing to let new errors be created instead of addressing this two-year-old feature request? – Jonesey95 (talk) 08:37, 16 January 2019 (UTC)

This is still a problem. Here's a two-day-old signature that I just fixed on a discussion page. – Jonesey95 (talk) 18:31, 27 March 2019 (UTC)

On October 15, 2017, I commenced an project to urge Wikipedia editors with linty signatures, or signatures out of compliance with WP:SIGAPP and related provisions to bring them into compliance. Most editors complied. Some editors didn't use their signature for an extended period of time ("sleepers"), so I didn't know if they had complied. Some ignored repeated requests. A small number refused to comply. From time to time I have reviewed my list of sleepers to see if they have complied, and remind them if they had not. As Jonesey95 noted, Special:Preferences still allows users to enter signatures with lint errors. It's way past time to fix this. —Anomalocaris (talk) 20:14, 18 October 2019 (UTC)

I think our best chance to get this fixed is to comment and subscribe at T140606. I didn't say it's a good chance, just our best chance. I have not had much luck with getting developers to work on feature requests and bug reports that I submit through Phabricator, but it is the official way that those things are supposed to be submitted, so.... – Jonesey95 (talk) 04:31, 19 October 2019 (UTC)

Many times a day, editors are making edits like this edit of Contempt of Congress, removing existing close table (|}) markup, which typically results in Table tag that should be deleted or Fostered content lint errors. Ideally, we wouldn't let editors save articles with new lint errors, but at least, we could warn editors on Show preview, something like,

Your edit is causing one or more new Table tag that should be deleted lint errors. Perhaps you have a table with two header lines, or a table without closing markup (|} or </table>).

Other warnings might be like these:

Your edit is causing one or more new Multiple unclosed formatting tags lint errors. Perhaps you are closing a <small> tag with another <small> tag instead of </small>.

Your edit is causing one or more new Self-closed tags lint errors. <small> should be closed with </small>, not <small/>.

We could also display such warnings on Publish changes, as we do now if the user doesn't enter an edit summary, so they have to press Publish changes a second time. It's time to take some steps to warn users of new lint errors when they edit. —Anomalocaris (talk) 02:05, 16 September 2019 (UTC)

This would be great. Many such errors are clearly unintentional. – Jonesey95 (talk) 04:05, 16 September 2019 (UTC)

SSastry (WMF), Izno, talk, Primefac, Pipetricker, Xaosflux, Adithyak1997, Galobtter, AlanM1, SMcCandlish, Nøkkenbuer, Firefly, JJMC89, DePiep: I moved this conversation to Wikipedia:Village pump (proposals)#Make it harder to create new lint errors. Please weigh in there; with enough demand maybe Wikipedia will take steps to make it harder to create new lint errors. —Anomalocaris (talk) 07:35, 18 October 2019 (UTC)

Absolutely. Though they are in red, errors can sometimes be missed by even the most experienced editors. I like the idea of having to confirm you want to save in such cases (like it's not your error and you don't have time to fix it, or a rare linter malfunction). —[AlanM1(talk)]— 17:21, 18 October 2019 (UTC)

Right now, WTE2017 with syntaxhighlighting does point out when you have lint in some cases (e.g. you mistyped a closing tag as an open tag will cause the would-be closing tag to display as red). --Izno (talk) 19:13, 18 October 2019 (UTC)

I strongly support this idea, as I said (under one ID or another) when this was mentioned at Village Pump.  — SMcCandlish ☏ ¢ 😼  00:48, 27 October 2019 (UTC)

The font tag is already losing support from a major browser. Specifically, Internet Explorer is not supporting 3-digit font colors with the <font> tag. This is not an issue with Mozilla Firefox or Google Chrome.

<font color="#F00">Red but not in IE</font>: Red but not in IE

<span style="color:#F00">Red even in IE</span>: Red even in IE

—Anomalocaris (talk) 17:34, 14 October 2019 (UTC)

No, the phenomenon you're experiencing there is a well-known IE bug since a long time ago. See StackOverflow. --Izno (talk) 19:12, 18 October 2019 (UTC)

It's obsolete HTML anyway, so may as well replace it upon contact with <font>...</font>.  — SMcCandlish ☏ ¢ 😼  00:47, 27 October 2019 (UTC)

Did you mean replace it with <span>...</span>? Part of the point of the original post is that <font>...</font> is obsolete. See mw:Help:Extension:Linter/obsolete-tag – Jonesey95 (talk) 01:44, 27 October 2019 (UTC)

I have trouble remembering that {{Unsigned}} and others (which?) are supposed to be subst'd. I also occasionally forget to sign talk page posts myself. It would be cool if the Linter would catch these unsubst'd templates and missing sigs. Can it? If not, is there perhaps a user script to do this when I preview/save – perhaps a user-side version of the Linter – or one that I could modify? I can't really claim to know JS, but I can probably modify some existing code that knows how to process the editor content. —[AlanM1(talk)]— 01:18, 27 October 2019 (UTC)

If there is a template that should always be substed, it should have {{Subst only|auto=yes}} in its documentation. See {{subst only}} for details. Before placing that template, you have to ensure that the template really is subst-able and that there is consensus that it should always be substed. – Jonesey95 (talk) 01:47, 27 October 2019 (UTC)

Thanks, but {{Unsigned}} does have {{Subst only}} on its doc page, placing it in Category:Wikipedia templates to be automatically substituted, causing AnomieBOT to fix it when I forget. I was just trying to avoid the bot having to do that if I can. —[AlanM1(talk)]— 03:06, 27 October 2019 (UTC)