Sat, Apr 17
Here is another VE edit that inserted garbage into a cite template:
Tue, Apr 13
Most of the edits linked above were incorrect modifications to existing short descriptions, so fixing the two bugs described above (the edit summary containing "suggestedit-add" incorrectly, and fixing the lower-casing of the first letter) should help.
Sun, Apr 11
Can someone please disable this tool until it can be debugged?
Apr 8 2021
Possibly related: table markup inside an image caption causes similar false positives. See https://en.wikipedia.org/w/index.php?title=English_language&oldid=1016445842
This is a subtask of T274382.
Apr 5 2021
I'm not sure if this is the same bug or a different bug, but I just came across something similar with "Frame". This syntax on en.WP renders correctly (the word "Frame" appears as a caption) but generates a Linter false positive error:
Mar 30 2021
Mar 11 2021
And another variant found in the wild:
Mar 10 2021
Mar 6 2021
Mar 4 2021
It appears that the first error (duplicate upright) is detected now after some Linter bug patches, but the second error (a quote mark following the number) is still not detected. See this test case:
Feb 24 2021
No thanks. I must have misunderstood the call for submissions. I feel that I have described the work adequately.
Feb 23 2021
I would need help recruiting a technical mentor. Thanks!
Feb 19 2021
So that looks like only 10% more edit volume (on en.WP) over the course of a month to get caught up, and then something similar to that each month to keep pages current (articles could be kept "more current" than other namespaces, if necessary to control loads). Can someone please kick off this process? Thanks!
Feb 18 2021
For clarification, in case people are looking at this without context: Sometimes editors use "Center" as the caption for a gallery image, typically for an image showing the central area of buildings in a municipality. That caption is erroneously hidden by the MediaWiki software. It should be displayed.
Feb 16 2021
I do not have good answers for any of these questions.
Feb 10 2021
Jan 28 2021
How does 16.6M pages and 18.5 GB of wikitext compare to how many pages and GB are edited or otherwise refreshed per day or month on enwiki?
Jan 25 2021
A point of clarification: I am assuming that like the Linter requirement to avoid line breaks inside span tags or italic/bold/small markup, this requirement will disallow CR or LF characters, but wikitext tags like br or p will be allowed.
Jan 22 2021
I just wanted to make sure that all of the related bugs are mentioned in one place so that if a developer is looking at any of them, they can see all of them: T216566, T216003, T215999, T179605, T266406, T264464. If someone has a better way of making these bugs into a single project, please so do.
Dec 22 2020
This bug is somewhat confusing, but editors at en.WP are definitely being confused by the capitalization of the first character of the bolded label, even though the parameter name, which is all-lower-case, is being used as the label.
Is this going anywhere? There is still a need to be able to display an accurate version of many labels. Chemical and mathematical formulas need subscripts and superscripts. Species names need italics. For a concrete example, see https://www.wikidata.org/wiki/Q92315294 where the title should be displayed as "Reinstatement of Ptilotus parviflorus (Lindl.) F.Muell. (Amaranthaceae)".
Dec 9 2020
This is still happening on many pages. See https://en.wikipedia.org/wiki/2012_Australian_Open_%E2%80%93_Boys%27_Singles where Page Information says that there are two errors, but LintHint reports five errors, which is the correct number.
Nov 25 2020
Nov 20 2020
Nov 18 2020
This bug is still present: https://en.wikipedia.org/w/index.php?title=COVID-19_pandemic_in_Japan&diff=prev&oldid=988486465
Nov 12 2020
Please provide instructions for disabling this unwanted formatting.
Nov 11 2020
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.