Wed, Nov 25
Fri, Nov 20
Wed, Nov 18
This bug is still present: https://en.wikipedia.org/w/index.php?title=COVID-19_pandemic_in_Japan&diff=prev&oldid=988486465
Thu, Nov 12
Please provide instructions for disabling this unwanted formatting.
Wed, Nov 11
Another similar edit with templatestyles tags added, probably a copy/paste edit of some sort: https://en.wikipedia.org/w/index.php?title=The_dismal_science&type=revision&diff=968216501&oldid=952239541
Here's a similar edit, but without a table involved, AFAICT: https://en.wikipedia.org/w/index.php?title=El_Pe%C3%B1%C3%B3n_de_Guatap%C3%A9&type=revision&diff=979436436&oldid=975071910
Oct 25 2020
Oct 24 2020
Oct 21 2020
Here's a minimal test case:
The disabling of these score tags appears to have some negative interaction with the rest of the page. See this revision:
Oct 20 2020
Oct 13 2020
Here's another upright option that is not detected as bogus by Linter:
Oct 2 2020
Until a minute ago, [[mw:Help:Images]] said "If multiple of these options are present, only the first one will be used".
Sep 28 2020
The following wikicode samples assign the non-numeric error category on en.WP:
Sep 22 2020
FWIW, I just copied the File wikitext from the original bug report to my sandbox on en.WP, then edited it with VE, changed one word in the caption, and saved it. I did not get a link= or alt= parameter, which means I am no longer able to reproduce the bug. Here's the diff:
Sep 6 2020
We still need this.
Aug 5 2020
These all appear to me to be features of the Linter engine. I see all of these features when I use LintHint on articles, and I agree that they could be improved. It might be a good idea to add the Linter project to this ticket.
Aug 2 2020
Jul 31 2020
These questions should be in a completely separate ticket that aims to improve the functioning of the Linter engine, or whatever it is called. They are out of scope for this ticket.
Jul 17 2020
In my experience (finding and fixing hundreds of thousands of Linter errors on en.WP), this is just how the current Linter works. If there are multiple errors, it does not always highlight the correct or complete string, and it does not always correctly identify the error types. It's a fundamental challenge with parsing invalid syntax: it's invalid, so it is difficult to write an algorithm to interpret its invalidity correctly every time.
Jul 9 2020
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.
Jul 8 2020
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:
Jul 5 2020
Another flavor that is not detected as a Linter error (extra "300px" parameter):
Jun 19 2020
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.