When is this fix going to be deployed? This mass message arrived in the past 24 hours with a Linter "bogus image options" error in it:

I suggest adding something like "The new category names are listed at [[Special:TrackingCategories]]."

This is still a problem, despite assurances in 2021 from @Sbailey (See above. This is not about Sbailey personally, but I worked in IT customer service for a long time and learned not to promise things that I was not sure I could deliver by myself).

Thank you for the patch. I would support a separate fostered-transparent lint category. It should be low priority or just a tracking category when it starts, as it will probably list some false positives that either can't be "fixed" or do not need to be "fixed".

Please restore the previous correct Linting functionality until you figure out a new way to manage these transparently rendering items. Right now, we have hundreds of false positives cluttering up the reports, which makes it difficult to find and fix actual errors.

It appears that this patch has been deployed and has fixed most or all pages in template space. For some reason, at least some pages in article space are still reporting false positive fostered content errors. See, for example, https://en.wikipedia.org/wiki/List_of_Pomona_College_people.

This is a known bug, one of many in Linter related to include/noinclude tags; this one popped up sometime around a year ago. I poked around to look for a phabricator task, but I can't find it. The workaround is to put a line break before the noinclude tag. We had to do this to a pile of templates on en.WP.

This bug is still present. The screen shot is of https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1229635601 using Brave for Mac, Vector 2022, logged out, desktop view.

This is still happening: https://en.wikipedia.org/w/index.php?title=2022_African_Championships_in_Athletics_%E2%80%93_Men%27s_110_metres_hurdles&diff=prev&oldid=1229211021

This appears to be related to T367480.

This is related to T367480.

The code that caused these breaking changes really needs to be rolled back and fixed on a development server. It is far too disruptive to be on the live encyclopedia.

The infobox at https://en.wikipedia.org/wiki/2024_European_Parliament_election_in_Ireland is much too wide in Vector 2022. My content column is 900 pixels wide, and my window width is 1,230 pixels. The infobox goes off the right side of the screen, overlapping the right-side toolbar when it is visible, at any window width from 630 pixels to 1,230 pixels. It was working fine before, staying inside the content column.

I have copied multiple reports of undesirable behavior from the English WP Village Pump (technical) into T367462. If any of the problems are not related to the style changes reported in the original bug report, they may need to be split into separate bug reports.

Multi-column tables in infoboxes are aligned badly. See https://en.wikipedia.org/wiki/Chris_Dangerfield for an example.

For me, at least, the font size in infoboxes on en.WP has changed to 90% of the default size instead of 88%, which it has been forever. In Vector 2010, the font size in infoboxes is still 88%. I am looking at en:John Dalton, for example. I have the (formerly default) "small" font size selected as my prose body font preference in the new radio-button switcher on the right-side toolbar.

A message box showing no image in Vector 2022 and working fine in Vector legacy:

In T367463#9891120, @Jdlrobson wrote:

Template:Navbox and Module:Message box als

Have you got sny example URLs handy? I've been going through WhatLinksHere but haven't found some examples yet.

FWIW, thumb-sized images show slightly smaller than my chosen preference (300px) in infoboxes on en.WP in Vector 2022 now. A normal thumbnail image shows as 300px, and the same image in Template:Infobox person (which defaults to the "frameless" image size option) shows as 295px.

This is either a subtask of T329673 or redundant. Enabling the sticky header on all pages should be a quick fix. I have done it with CSS for well over a year, with no ill effects.

This may be a subtask of T329673. Enabling the sticky header on all pages should be straightforward. I have done it with CSS with no ill effects.

We prevent the addition of obsolete tags to user signatures. Why not elsewhere? Other editors are just going to have to fix them eventually. We are making work for ourselves by allowing these new errors to be created.

This is still happening:

• https://en.wikipedia.org/w/index.php?title=User_talk%3AWil540_art&diff=1225244330&oldid=1224957255
• https://en.wikipedia.org/w/index.php?title=User_talk%3AZI_Jony%2FNewsletters&diff=1225244299&oldid=1224026744

In T365656#9824144, @Pppery wrote:

Until T52182 is resolved I think it's not VisualEditor's responsibility to censor the input the user passes to a template parameter.

Linter has been flagging these obsolete tags for at least six years, and some bots and editors on some wikis have made good progress in updating the syntax, but two big problems remain:

This is tangentially related to T52182. If I want to center a template parameter value, it should be straightforward for an editor to select it, cut it, insert Template:Center, and then past the template parameter value into the nested template. Instead, once I am inside the template parameter value editing box, I lose access to the template insertion menu. That encourages the use of obsolete methods.

Why is this bug report from 2013 still open? I just had to remove a link from a Wikidata page that was a copyright violation, but without an explanation, my edit might look like vandalism. We need to be able to add a short explanation like "copyright violation" to our Wikidata edits. This should be a no-brainer.

In T145604#9804125, @Rich_Farmbrough wrote:

Why, since the comments on the RFC were overwhelmingly against this proposal, was it implemented?

T358921 was not linked above. While doing QA for this task, please try undoing this change in https://en.wikipedia.org/wiki/Template:Quote_box/sandbox to see if the spacing at the bottom of the quote box remains the same.

Signatures should definitely need to confirm Linter errors. That is by design, and it took us years to get it rolled out. See T355462 and its predecessors.

Also see https://www.mediawiki.org/wiki/Talk:Reading/Web/Accessibility_for_reading#Signature_disabled which illustrates a different kind of nesting.

This might be difficult to find, since the italics on either side of the URL may be marking up text that is outside of the link.

In what way is this a wikitext syntax error?

In T344378#9612102, @bvibber wrote:

In T344378#9611682, @Jonesey95 wrote:

If this condition is to be tracked and the communities do not get a say about whether it should be done at all, it should be done with a normal MediaWiki tracking category at Special:TrackingCategories. Tracking categories can be documented locally by editors from each community, hidden if desired, and ignored if necessary. That makes them a much better tool for this purpose.

Tracking categories don't include the location and target file information we have here.

In T344378#9612102, @bvibber wrote:

In T344378#9611682, @Jonesey95 wrote:

Using Linter to track missing alt text is a Bad Idea. Missing alt text is not a syntax error. Please learn from your big mistake in the "wide table" Linter tracking fiasco. Linter tracking is for syntax errors that can and should be fixed in all cases; missing alt text, like "wide tables", does not meet any of those criteria.

Note that linters don't track *errors* per se, they track potential issues which you might need to fix up with manual intervention.

Using Linter to track missing alt text is a Bad Idea. Missing alt text is not a syntax error. Please learn from your big mistake in the "wide table" Linter tracking fiasco. Linter tracking is for syntax errors that can and should be fixed in all cases; missing alt text, like "wide tables", does not meet any of those criteria.

In T358921#9609778, @Jdlrobson wrote:

It looks like the development team working on these vertical spacing issues needs a much more varied set of test cases.

MediaWiki engineers cannot possibly test every single template across all our projects - that doesn't scale well. I think in general it's a good idea to specify in the template exactly how it should be rendered and not rely on browser or skin defaults which can change any time. That ensures the design is future proof to changes.

Task T358921 was closed as a duplicate of this one. Please ensure that any test cases related to fixing this problem include the multiple situations described in that bug report.

This is happening for me today at https://en.wikipedia.org/wiki/Template:Random_slideshow on the English Wikipedia. If I switch to non-Parsoid, two normal categories and two hidden categories are shown. If it matters, I am using Vector 2022.

Additional vertical spacing problems, this time excessive padding around blockquote tags, has been reported at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&curid=3252662&diff=1211600813&oldid=1211518868#Excessive_indentation_of_block_quotations

Reported at https://github.com/wikimedia-gadgets/shortdesc-helper/issues/17 just to cover my bases. I am not a programmer, so submitting a pull request with modified code is probably beyond my skills.

I posted it a month ago with no response. It is unclear to me who maintains this gadget. I do not see a link to an official bug-reporting venue at the gadget's page, but I may have missed it.

Something possibly related to this series of changes messed up the symmetry of the padding at two en.WP templates. See https://en.wikipedia.org/w/index.php?title=Template_talk:Quote_box&oldid=1209709062#bottom-of-box_sizing and https://en.wikipedia.org/w/index.php?title=Template_talk:Talk_quote_block&oldid=1209711889#Ugly_bottom_padding

Yes, and thanks to the bug fixer!

Nothing appears to have been fixed. I just opened https://en.wikipedia.org/wiki/John_Dalton in Chrome for Mac OS, logged out, and when I inspect the "Special pages" link in the Tools sidebar on the right, I get this:

One way to start the discussion would be to create a wiki page listing all of the current Linter errors. For each one, figure out whether it can cause real rendering problems on pages (e.g. link-in-link errors cause real display problems every time; some unclosed tags cause all subsequent text to be smaller or cause subsequent sections to be nested inside an unclosed div). For obsolete tags, figure out whether support for obsolete tags is going to be removed. And so on.

This enhancement has caused Linter "span wrapping div" errors in pages transcluding some Special pages. See T275230 and https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1199067000#Possible_WP:ITSTHURSDAY_change_causing_Linter_errors

This appears to be happening with Special:RecentChanges/25 as of today. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1199013916 for an example.

Thanks for making that extra effort. The screen shots are nicely comparable now by switching two tabs back and forth.

It is difficult to compare the two screenshots, because they appear to have been taken with different screen resolutions. Also, one is logged in and one is logged out, so I can't tell if any user-specific CSS is being applied. Would it be possible to take two comparable screen shots. The second one does look promising, but without the same environment in each, I can't say for sure. Sorry to be so picky.

This bug description does not appear right to me. It seems like the bottom margin for the p tag is the problem, not the top margin for lists. I suppose the overall problem could be addressed from either direction.

It looks like this patch is waiting for someone to "schedule the change for one of the available backport windows". I read the relevant wikitech page, but it is way beyond my skills.

Another one, to help with tracking down the cause of this bug:
https://en.wikipedia.org/w/index.php?title=Cunobeline&diff=1192840869&oldid=1187335708

I also see the large, downward-facing black triangle after clicking directly on https://en.wikipedia.org/wiki/User:AnomieBOT/TPERTable when it is listed in my Watchlist as having changes.

Done =)

I guess I should have said that this is probably a zombie process, since the bot has not edited (on en.WP) in seven years.

This problem does not appear to be fixed in the Zebra redesign (see screen shot).

Same. Maybe the Zotero engine has been tweaked since the initial report. OK to close the ticket, I guess.

This bot is long-dead. I helped with getting it set up on the user specification side.

The OP's problem, as illustrated in the image uploaded on 7 December, is fixed at en.WP now. Thanks!

In T350833#9363957, @Sarai-WMDE wrote:

After some investigating, the Design System Team settled on initial values for the small text style of 0.75em with a line-height of 1.5 (translates to 12px/19.2px under 16px).

Like the rest of Codex's typographic scale, this is a work-in-progress style, and we were hoping to test the appropriateness of its values with help from the Web team.

Something to keep in mind: we went for such a small size in order to generate contrast with the default UI and body size of 14px.

Interesting. I don't know why all of that process would be needed for a serious error that can leak into the rest of the page, including the TOC, the right-hand sidebar in Vector 2022, the title, and just about everything else on the page. See https://en.wikipedia.org/w/index.php?title=User:Robertgreer/sandbox/NYCB/Saratoga&oldid=962070708 for an example.

It seems like it should be a relatively quick fix to get this to appear on the list of errors at Special:LintErrors. Is there anything that regular Wikipedia editors can do to move this ticket along?

It appears that the "signature too long post substitution" detection is not working properly. As an example, user Adam Cuerden is listed at https://signatures.toolforge.org/reports/en.wikipedia.org but their expanded sig is fine. The problem may be that the tool does not fully expand the signature before testing it. See https://signatures.toolforge.org/check/en.wikipedia.org/Adam%20Cuerden

Was it intentional that this change also applied to other text of lesser importance (and therefore semantically smaller in the design until this change) such as the text output by the short description gadget?

In T346062#9308576, @jhsoby wrote:

I'm sorry to be "that guy", but I'm not a big fan of this change. Having these elements (especially everything in #contentSub) a smaller font-size made it more immediately apparent that these elements are not part of the page content and are something else. Now everything sort of just blends together visually. Any chance of restoring the 13px size?

mw:Help:Images specifically says that images using the "right" option are supposed to float right, but the VPT thread contains a screen shot showing the header text overlaid on the image. I don't think "thumb" should be required to stop that from happening, unless mw:Help:Images needs to be corrected.

It appears that the WMF may be on the hook for updating the format of the link called "View detailed information on the lint errors" on the "Page information" page for any page having Linter errors. See https://en.wikipedia.org/w/index.php?title=User:WOSlinker/lint14&action=info for a current example of one of these links. The results show pages in two namespaces instead of just the page in question.

Thanks for the quick reply. We will see about getting the links updated. Thanks for this new namespace selection feature. I have already used it a couple of times to narrow the list of results, and it seems to work fine.

It appears that this change has been rolled out to en.WP. Is the breakage of existing links like https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=0 (missing end tag errors in article space) intentional?

Please note that the above screen shots do not show the right-side toolbar.

Is this task related to a strange new development that we are seeing at en.WP? When we click an "edit" link from https://en.wikipedia.org/wiki/Special:LintErrors/deletable-table-tag?namespace=0 we get "action=parsermigration-edit" at the end of the URL instead of "action=edit".

Please don't revert the changes, which have been helpful overall. I have been adding line breaks before the noinclude tags to a few hundred template pages, and that seems to resolve this false positive error without changing the table's display.

Here is a similar case that was causing a Linter false positive error:

This is affecting dozens, possibly hundreds, of template pages. If it could be fixed soon, that would be helpful.

I found and fixed similar (and different, but still undetected) cases at:

• https://en.wikipedia.org/w/index.php?title=Catholicity&diff=1178578750&oldid=1176889179
• https://en.wikipedia.org/w/index.php?title=Eug%C3%A9nie_Foug%C3%A8re&diff=1178583792&oldid=1173473263
• https://en.wikipedia.org/w/index.php?title=Flying_Blind_%28film%29&diff=1178584874&oldid=1173845460
• https://en.wikipedia.org/w/index.php?title=HMS_Pilote&diff=1178612036&oldid=1124674850
• https://en.wikipedia.org/w/index.php?title=Pelargonium&diff=1178681708&oldid=1174661287 (this one is inside an sfn template, which is maybe a little different)
• https://en.wikipedia.org/w/index.php?title=KkStB_269&diff=1178675475&oldid=1070681481