Thanks for these answers, even though they are dissatisfying. I would hope that the parser could check the actual output for compliance with having both a color: and a background-color: specified, since that is the underlying concern.

Still happening.

Thank you for asking about this at en.WP. A brief discussion, linked from a couple relevant notice boards, has not surfaced any potential negatives regarding this new Linter "category".

Thanks. I have fixed the Medal template that had line break issues. All issues related to these changes appear to be resolved.

Possibly related to this parsing change:

The problem appears to be related to table markup used inside image captions, which again, renders fine.

This is still happening. Please fix pasting of ISBNs so that they are pasted as text. The explanation by DLynch above does not make sense. If I paste "foo bar", it pastes as plain text. Pasting "ISBN 1234567890" should be the same. If I type that string in the regular editor, I see plain text and it is saved as plain text. There is no linking involved. VE should behave the same way.

In T47224#10605603, @Danny_Benjafield_WMDE wrote:

@Jonesey95 you might find this Wikidata tool very helpful: EditSum

A bot just cleaned up hundreds of edits caused by this bug on the English Wikipedia, and they are happening again at a rate of at least one per day. Here's one from teh last 24 hours: https://en.wikipedia.org/w/index.php?title=History_of_the_metre&diff=1274677738&oldid=1274351949

I just had a need for an edit summary again. I made these edits because importing the unranked data was causing an error on Wikipedia. I would have been happy to explain my edit, but there was no way to do so. I was reverted by someone who didn't understand why I made the edit, and the only way to provide an edit summary was to revert.

Template:Short description on en.WP has been modified as requested.

This is still happening. It's been two years since this apparently simple bug was reported. Please fix. https://en.wikipedia.org/w/index.php?title=Economy_of_Spokane,_Washington&curid=21067578&diff=1272521263&oldid=1265830445

What is happening?

This is still happening (September 2024): https://en.wikipedia.org/w/index.php?title=Alpha_Beta_Alpha&diff=1244031457&oldid=1242538958

I'm not sure why this is stuck or needs analysis. Show the existing sticky header on all pages when they are scrolled. Done. If you want to change the content of the sticky header, that can be a different ticket.

Possible bug: An editor using the Android app reports that they were prompted to add a short description to an article that already had a short description of "None". This should not be happening. Please investigate. See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Short_description&oldid=1267806510#Is_none_case-sensitive?

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.