In T326898#10383980, @Dbrant wrote:

All the updates have been deployed, but it looks like there are some loose ends:

• SDNONE still has some pretty ingrained guidance about using none for the intentionally-empty case. Should someone update that page?
• The shortdec-helper gadget still treats none as the intentional case, and treats an empty description with a CTA to "add" a description. This would need to be updated, too.

In T326898#10392753, @ARamadan-WMF wrote:

Received from the support email:
"The Wikipedia Android app suggests users add short descriptions to articles with the {{short description|none}} template. For an example, see "Domestication of the cat" on enwiki. That template with the value set to none is used to mean a short description is not needed, i.e. the title is descriptive enough. When users add short descriptions to those articles, they end up being confusing because they either restate the title or say something that shouldn't be in a short description."

Not fixed for me. See attached screen shot, taken just now. Note browser inspector pointing at empty, 24px-tall space labeled vector-sitenotice-container.

The permalink for the demonstration is https://en.wikipedia.org/w/index.php?title=User:Amire80/templatestyles_content&oldid=1229737521

Thanks for the quick and detailed attention. I hope the fix works.

Something has changed recently, even in Vector 2022. Yesterday, red links were showing as red for me, even with this code in my personal CSS:

In T315347#10261564, @Jdlrobson wrote:

In T315347#10261554, @Jonesey95 wrote:

Here's a screen shot from my browser on the linked page, with relevant inspector information highlighted. I am logged in, in mobile mode, in Firefox for Mac OS. Logged out, I see red links. Where could the blue color be coming from? I don't know enough about the CSS to know where load.php is pulling this color from.

I looked through my preferences and saw a few gadgets that adjust link color, and I guess if I have to turn them off in batches to see what fixes it, I could, but any clues would be helpful.

It's coming from your user CSS: https://en.wikipedia.org/wiki/User:Jonesey95/common.css#L-286 - common.css loads on all skins including mobile and will override any existing rules. You'll need to revise it.

Here's a screen shot from my browser on the linked page, with relevant inspector information highlighted. I am logged in, in mobile mode, in Firefox for Mac OS. Logged out, I see red links. Where could the blue color be coming from? I don't know enough about the CSS to know where load.php is pulling this color from.

This bug report is from 2022. It is not recent, but it is still happening. The reason that I found it is that I was alerted to this rendering problem in a conversation on my talk page after I reverted another editor for leaving a red-linked template on a page. The editor reported that nonexistent templates do not show up in red on mobile, and I was able to verify the problem.

This is still happening. It appears to be a Visual Editor bug.

See also T315347, which appears to be related.

This appears to be a generalized mobile view problem, not just an apps problem. See https://en.m.wikipedia.org/w/index.php?title=Fran%C3%A7ois_Mitterrand&oldid=1250330772 for an example (I am using Firefox for Mac OS on a computer, clicking the Mobile link at the bottom of the page). The nonexistent "Template:ISBN)" shows as blue, as do all of the nonexistent article links in the succession boxes at the bottom of the page (Roger Gillot, Jehan Faulquier, etc.)

Thank you for the explanation. It would have been helpful to have this explanation earlier. Now that the category is mostly cleared out on en.WP, it has revealed at least one Linter bug; I filed T376943. So this code is useful on en.WP after all!

This change should be reverted entirely, as far as I can tell. Special:LintErrors/bogus-image-options already detects this condition. Why have a tracking category for this one condition and not for all of the Linter issues, as has been requested many times?

When you create a new Linter error, even if it is hidden, make sure to add it to https://www.mediawiki.org/wiki/Help:Lint_errors and complete the rest of the "new Linter error" checklist.

See this detailed discussion.

This is still happening. A fix would be welcome.

I suggest using a bronze star, not a green star. In the Olympics, for example, gold is for the top performance, silver is for second place, and bronze is for third place. We should use that existing color scheme, which is known by everyone.

In T200517#10181767, @ABreault-WMF wrote:

including the Page Information entry for each page

Do you have an example where it isn't showing up? It appears to be working here,
https://www.mediawiki.org/wiki/Extension:Scribunto?action=info#Lint_errors

Can someone please perform the rest of the "add a new Linter condition" checklist before closing this ticket? The new condition needs to be added to the lists in which Linter errors appear, including the Page Information entry for each page, and the necessary documentation and help pages need to be completed.

https://en.wikipedia.org/wiki/User:Shrikarsan/shri.js has a link that goes to a different location than expected. The link is:

In T368166#10171647, @stjn wrote:

It would be much more helpful to others if you actually provide links to false positives.

This new behavior appears to have some false positives and undesired conversion of plain, unlinked text into links. As such, it should probably be opt-in via text inside the syntaxhighlight tag rather than on by default.

I am unable to replicate it either. I have asked at https://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor#consistently_creates_referencing_errors

This problem is still not fixed (link is to a mass message from 14 September 2024). This message went to 1,293 pages, according to search results!

In T374311#10131678, @Pppery wrote:

@cscott Is this intended to populate the tracking category? I personally think it's reasonable behavior that both <gallery widths=180> (concise) and <gallery widths=180px> (technically redundant but clearer) are accepted and don't populate the category. Both syntaxes are widely used.

Why was this change deployed? I don't see a link to an affected article or page. These errors were already tracked via the Linter "bogus file options" flag, as far as I know. I fixed hundreds or thousands of them at en.WP.

This is clearly a bug.

We added the magic word to Template:testcases notice on en.WP yesterday, but when the report updated 22 hours later, pages like https://en.wikipedia.org/wiki/Template:Afd_bottom/testcases were still on the report.

I would hope and expect that
Wikimedia representatives would be diligent about heeding these warning messages (and about posting messages that use nonexistent templates). This feature request does not appear to have been implemented effectively and is causing volunteer gnomes to have to tidy up after message senders.

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.