Thu, Jul 9
I don't know how often the link= problem is turning up. The devs could probably do some sort of database search to look for VE edits that added link=, which people should almost never be adding.
Wed, Jul 8
Another variant on this bug: the following wikicode renders on en.WP with the "link" section as the caption, and Linter does not flag the real caption as extra text. That looks like two bugs in one image call.
This problem is not (completely) fixed. Here's an edit from 7 May 2020 (source: Times of India) that shows the problem:
Sun, Jul 5
Another flavor that is not detected as a Linter error (extra "300px" parameter):
Fri, Jun 19
Or implement tracking categories, as has been suggested for years. I don't know why we have these Special pages that make it harder to see and count the errors. The "edit" links are handy, but that's about it; LintHint provides those for pages anyway.
The maintainer of Fireflytools has abandoned updates. It would be useful for this tool to be maintained centrally.
This seems like something that should be addressed via WPCleaner or bot runs. It is not invalid markup, so it should not be tagged as part of the Linter project.
Can we close this? It's simply not a bug.
This problem appears to be still happening, for example at:
Jun 12 2020
Thanks for the response. I continue to hope that someday, the Linter tracking will actually apply Wikipedia categories, so that we can work with them in the usual way.
Why was the error-tracking category (Pages using invalid self-closed HTML tags) removed? Will there be something to replace it? Gnomes use it regularly to find pages with invalid code; will it be possible to find such code in some other way? Will each wiki have to create its own detection method?
Jun 11 2020
Still happening (loss of session data error on attempted save) on enwiki as of this time stamp.
Jun 10 2020
Jun 5 2020
May 31 2020
FWIW, inserting Template:Cite interview with VE works for me on enwiki. My screen does not look anything like the OP's however, so there may be some interaction with the browser, user scripts, user preferences, or something else that does not match my configuration.
May 29 2020
Thank you for this response. It was very clear.
May 28 2020
This is the wrong order. The correct order is:
- Warn the tech folks about incoming questions ("STEP 4")
- Stop the bleeding ("STEP 3")
- Ask affected people to update their sigs ("STEP 2")
"Warn the tech folks" and "Stop the bleeding" should happen in rapid succession. After that, we can take months to "Ask people".
May 22 2020
I am disappointed that obsolete tags are not being addressed in this phase. It seems like this means that obsolete tags are not really a problem to be fixed, if the WMF is willing to implicitly encourage them to proliferate on project pages. Perhaps the Linter "obsolete tag" checking should be deactivated, for consistency.
May 16 2020
WMF staff, please hold up your end of our agreement by disabling the Wikidata fallback for short descriptions at en.WP.
Apr 21 2020
Thanks for the response.
Apr 20 2020
I don't understand the comment about tracking. The MW software has performed this tracking for more than three years, per Part 2 of the Exploration section of the original ticket description above.
Please read the request again. It is not entirely clearly written, but the request is asking ISBNs to be pasted as plain text. The MW software turns plain-text ISBNs into magic links (deprecated but still active). Treating ISBNs as plain text has been the request this whole time.
Apr 15 2020
Apr 7 2020
Still happening (edit from March 29):
Apr 4 2020
Mar 24 2020
Thank you for the more detailed answer, the key part of which for me is that this may have been happening way back in 2015 (or possibly still in March 2019, in the diff I provided above, where a new section was added and the unchanged section above it appears to have been modified poorly by Parsoid), but it is probably not happening now. That seems like a valid reason to close this bug. We gnomes will continue to fix the links-in-links errors.
I am glad to see that some of these very old VE bugs are being worked on, but....
Mar 3 2020
Here's another one, if it helps:
Mar 2 2020
Another one: https://en.wikipedia.org/w/index.php?title=1956_Finnish_Cup&type=revision&diff=943578321&oldid=934271489 had 157 missing end tags before I fixed them. I found the problems using an insource search. The article did not appear on the report linked above, but it should have. Before my edit, the article was edited on 5 January 2020, so its Page information lint error count should have been updated at that time.
Feb 29 2020
I don't think so. For example, https://en.wikipedia.org/wiki/Brian_Willoughby has the same type of error (unclosed italics). LintHint and the Page information both show 21 missing end tag errors. My experience has been that on most pages I have worked on, the number of errors reported on Page information has matched LintHint's error count.
Feb 28 2020
This is probably a bad idea. An unclosed "font size=+3" or unclosed "tt" tag can make the whole rest of a talk page display giant text, or monospace text, respectively. Whether the font or tt tag gets replaced or closed by a de-Linting editor, the problem needs to be fixed.
Feb 26 2020
Feb 21 2020
Thanks for the attention, and let me know if I can help with troubleshooting.
Feb 20 2020
This is still happening. There has been no action on this bug report in over a year, not even triage, apparently. Bogus File Options are listed as a "medium priority" Linter error, FWIW. Please let us volunteers know how we can help.
Feb 17 2020
Not a bug. Fixed with this edit:
Feb 13 2020
Feb 11 2020
I have added some text to the help page (thanks for starting it!) and copy-edited it a bit.
Feb 6 2020
Here is another variant on this bug:
Feb 2 2020
The following Visual Editor edit broke a correctly formatted table, as far as I know:
Jan 25 2020
Thank you for not waiting for Parsoid deployment. My thanks to C. Scott for that sage advice; it'll be my treat the next time I see you at the Haven.
Jan 12 2020
I think this has been implemented via LintHint, if I understand the feature request.
Can I just mark this as Resolved?
This bug has been resolved: https://de.wiktionary.org/w/index.php?title=Vorlage%3Afachspr.&type=revision&diff=7087425&oldid=3145589
I know that I have suggested in other locations that Linter errors be placed in actual WP Categories instead of on these very limited Special pages, but I can't locate those other suggestions right now. Categories would be helpful in resolving this sort of problem. The categories should probably be subdivided by namespace and linter error, something like 32 (namespaces) times 18 (linter error types) categories in total.
One of the notes I added to Help:Images: "If there is a space character between alt and the equals sign, the alt statement will be treated as a caption." This behavior is contrary to how editors are used to working with template parameters. Yes, I know that images are not templates, but it is difficult to manage this inconsistent behavior, and there does not appear to be a good design reason for treating these spaces as syntactically meaningful while (for example) stripping out spaces after the equals sign.
Is there any progress on this feature request? Signatures are still being added that cause Linter errors, e.g. this one from 11 January 2020:
Jan 7 2020
This may be related to T216566.
Jan 5 2020
May be a duplicate of T66413.
Jan 2 2020
Is this problem related to the "error -- Error: Unsupported Media Type" message that I receive on every page in en.WP when I have LintHint enabled? LintHint works if I edit the page, but not in viewing mode.
Dec 24 2019
And now bdi tags are being added inside the Special:Booksources link:
Now there are bdi tags being added for some reason:
What is the status of this ticket? As far as I can tell, it has been more than three years since the release of MW 1.28 (https://www.mediawiki.org/wiki/MediaWiki_1.28), but magic links are still functioning, at least on en.WP.
Dec 13 2019
ISBN magic links have not been removed from en.WP, despite that change being planned and announced many years ago. Here's an example of a functioning magic link:
Dec 12 2019
Dec 10 2019
Really? Look at the span tags. They say
Dec 9 2019
This is still happening, requiring cleanup by en.WP gnomes. Please make it stop. Here's an example from a few days ago:
Nov 28 2019
Still happening. Please fix.
Nov 21 2019
I think that I have fixed all of these errors (there were only a couple dozen). Please ensure that this bug has been fixed. Thanks.
I have fixed half a dozen of these. The rest are likely to be listed at the top of en.WP: Wikipedia:WikiProject Check Wikipedia/ISBN errors
Oct 22 2019
You're right, "substed" is not quite correct, but somehow, "templatestyles src="Module:Citation/CS1/styles.css" " is getting into the wikicode. I don't imagine that editors are typing that themselves manually, especially editors prone to using VE, so some interaction between the actions of the human editor and VE's programming are probably causing this bug.
Oct 11 2019
Here's an edit adding substed a citation template on 4 October 2019:
Oct 8 2019
Still happening as of 11 August 2019:
Sep 23 2019
This bug still needs action. Here's a more recent illustration of the problem.
This may be a sub-task of T54582.
Sep 15 2019
This is still a problem. Please implement a solution that checks custom signatures for Linter errors. Here's a set from a few days ago that I just fixed.
Sep 9 2019
It looks like this change has been partially implemented. IABot is inserting "url-status=alive". Unfortunately, "alive" is not valid; please use "live" instead.
Jun 6 2019
Re: Retro's comments: There is already a bot working through a limited set of signatures. See https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Ahechtbot_5 and its siblings. The current BRFA process, and the time-consuming nature of finding faulty signatures in talk pages and figuring out a fix for each one, makes it pretty slow to chip away at faulty signatures, but it is possible.
Jun 4 2019
Can we please have this report for main space pages?
Jun 3 2019
I welcome bot fixes of Linter errors in signatures. They will not fix the root cause of the problem, however, which is that custom signature code is allowed to contain Linter errors. @WOSlinker proposed a reasonable fix above.
May 17 2019
If this change has been deployed on en.WP, it did not resolve the problems. Sorry.
May 9 2019
Thanks for the patch. Things are much better today, but still not entirely fixed.
May 7 2019
The bot should not insert an invalid title. If it is unable to insert a valid title, it should leave the title blank so that the error message makes it obvious to editors that something needs to be fixed.
May 6 2019
This is a significant problem affecting some of the most active editors, at least at en.WP. If it helps, here are the Watchlist preference settings that I have selected:
May 2 2019
Apr 11 2019
I think I have found a similar situation here:
Apr 10 2019
Still happening as of April 5:
Here's a link to a broken page:
Thanks for the quick patch, but wouldn't it make more sense to roll this out with the normal Thursday/Friday patch cycle? Now that I think of it, why was this non-urgent change applied out-of-cycle in the first place, without the usual announcement in Technical News? (As always, I am probably misinformed about how this process works; I am merely a volunteer editor, not a developer or other insider.)
Apr 9 2019
It is not really even obvious what this new thing does
, or where the useful slider GUI went. Whatever choices the developers are making, can you please move these experiments to the bottom of the page, or into a collapsed box, so that busy editors can see the actual links in the actual revision history, which is the title of the page, after all. Thanks.
Apr 4 2019
Apr 2 2019
Mar 28 2019
It is possible that the situation has deteriorated. I don't remember if the foreign-language text was present in the gray-on-white subheaders last summer, but now I'm seeing things like:
Mar 27 2019
Please increase the priority of this fix. Signatures are still causing Linter errors. Here's a two-day-old one that I just fixed:
Mar 15 2019
This appears to be happening again:
Mar 14 2019
Per @Izno, this also appears to be happening with DOI and ISSN links. More junk for gnomes to clean up. See https://en.wikipedia.org/w/index.php?title=Purges_of_the_Communist_Party_of_the_Soviet_Union&diff=prev&oldid=884801720 for a sample diff.
The link to ISBN exists for a reason, as @Izno explains.
Mar 12 2019
This is still a problem. See https://en.wikipedia.org/wiki/Template_talk:Infobox_settlement#Category:Wikipedia_page_with_obscure_country_or_subdivision_and_this_template for a recent discussion where only about half of the articles had been updated after a month.
Feb 19 2019
This one is actually flagged as an error on en.WP:
Delete the manual line breaks after the /nowiki tags.
This would be a useful addition, if it is possible. I have fixed a few thousand pages with Linter errors, including many transcluded pages, on en.WP, and here are some things to consider: