Wikipedia talk:Linter

Archives

Archive 1	Archive 2	Archive 3
Archive 4	Archive 5

This page has archives. Sections older than 270 days may be automatically archived by when more than 10 sections are present.

Wikitext linting database updates temporarily disabled

See https://phabricator.wikimedia.org/T240057 for more details. — Preceding unsigned comment added by SSastry (WMF) (talk • contribs) 23:54, 6 December 2019 (UTC)[reply]

@SSastry (WMF): Someone made it a security task. --Izno (talk) 00:55, 7 December 2019 (UTC)[reply]

Fixed. SSastry (WMF) (talk) 13:12, 7 December 2019 (UTC)[reply]

Looks like linting database updates are enabled again. —Anomalocaris (talk) 08:45, 12 December 2019 (UTC)[reply]

No, not yet. But, it will very likely be enabled tomorrow. SSastry (WMF) (talk) 09:16, 12 December 2019 (UTC)[reply]

I edited Draft:Kwesi Wilson and a bunch of lint errors updated away. But then I edited Draft:EIP (law firm) and Draft:KK Crvena zvezda in EuroLeague and the lint errors didn't update away. —Anomalocaris (talk) 09:20, 12 December 2019 (UTC)[reply]

A related issue, related at least minimally because until the linting database updates are re-enabled, lint errors aren't updating:

I have long noticed that, if I edit an article that formerly transcluded lint errors, but the transcluded lint errors were fixed, after a null edit and weeks of waiting, the lint errors often don't get erased from Page information, but a trivial edit that adjusts white space results in erasing the lint errors from Page information within seconds. Isn't a null edit supposed to trigger an immediate entry of the article into the queue of articles to be scanned for lint errors, just like a non-null edit? —Anomalocaris (talk) 23:28, 10 December 2019 (UTC)[reply]

We didn't know this till now, but I bet null edits don't show up in Parsoid's parse queue (likely a performance optimization higher up in the software stack to avoid useless parse requests to Parsoid). I don't have an immediate solution for that problem now, but perhaps worth a Phab task to see how null edits are handled and what else it should enable (like in this case). SSastry (WMF) (talk) 07:20, 11 December 2019 (UTC)[reply]

Error message: "error -- Error: Unsupported Media Type" with LintHint on all pages

I am getting "error -- Error: Unsupported Media Type" on all pages in "view" mode, for a couple of weeks now. Normally, it loads a list of errors.

It is working fine in Preview mode, although at about the same time, the down arrow that jumps to the error and highlights the erroneous block of text started highlighting text below the actual error.

Is anyone else experiencing these two errors with LintHint? – Jonesey95 (talk) 22:42, 31 December 2019 (UTC)[reply]

@PerfektesChaos: --Izno (talk) 22:15, 1 January 2020 (UTC)[reply]

HNY.

The first issue is a temporary decoupling from Wiki server due to overload problems. Should be resolved within January.
I have observed the second issue already.
- Beginning with December 2019 the parsing software has been changed from Parsoid/JS to Parsoid/PHP.
- I guess that computation of target coordinates is less exact now.
- That might be reviewed, but since the parsing software is not ultimately ready I do not take any action here. Might be influenced by browser issues as well.
- Does the same behaviour occur if you follow regular links from special page? Then the positions are miscalculated with new parsing software.

Please direct issues regarding LintHint towards LintHint global feedback page, de:BD:PerfektesChaos/js/lintHint.

There you might have found the answer on the first point already.

Greetings --PerfektesChaos (talk) 11:40, 2 January 2020 (UTC)[reply]

Re following the links from the Special Linter pages, I tried a few "edit" links, and they highlighted the correct locations. I don't know if it works for every article. – Jonesey95 (talk) 16:03, 2 January 2020 (UTC)[reply]

For me, sometimes the linter page edit links don't highlight anything at all. When they do highlight, they highlight the exact location of the lint error. However, lintHint highlighting is often below the actual error, and it tends to get farther away the deeper you get into an article. There is a discussion of this topic at de:BD:PerfektesChaos/js/lintHint#Pointers are pointing to the wrong place. —Anomalocaris (talk) 21:32, 3 January 2020 (UTC)[reply]

I think the incorrect location for highlighting the error is a Parsoid bug. Can you point me to a page on which this happens? That will help us investigate this. SSastry (WMF) (talk) 04:56, 4 January 2020 (UTC)[reply]

Here's one that shows the problem for me: go to Georgian scripts. Click the yellow LintHint box. When the error list appears, scroll to the last "missing end tag" error and click the down arrow. When I do it, "n equal number " is highlighted instead of "''labial sign", which is approximately 2,745 characters before the highlighted section. – Jonesey95 (talk) 05:09, 4 January 2020 (UTC)[reply]

So, first of all, when I loaded LintHint and clicked on it, I got the "Error: Unsupported Media Type" error. That error comes from these lines which indicates that LintHint is probably passing an incorrect Content-Type or is not sending in a content-type. For the missing case, we could probably default to application/json but that will take a few days since we need to discuss what is a reasonable default. But, User:PerfektesChaos, maybe you can look at your script and see if you are passing this header correctly. Parsoid/PHP might be behaving stricter compared to Parsoid/JS here. SSastry (WMF) (talk) 06:32, 4 January 2020 (UTC)[reply]

As for the second problem (incorrect highlights), I think I know what the issue could be. Parsoid/PHP computes offsets in terms of bytes whereas Parsoid/JS computes offsets in terms of characters. While storing lints in the database, we convert the offsets from bytes to characters. But, when tools requests these offsets via the linter API (like LintHint does), we have probably forgotten to add the offset conversion. This affects any page that has non-ASCII characters (which is probably most pages). Anyway, we'll fix that and deploy a fix this week. SSastry (WMF) (talk) 06:32, 4 January 2020 (UTC)[reply]

SSastry (WMF), thank you for the speedy debugging! – Jonesey95 (talk) 15:24, 4 January 2020 (UTC)[reply]

I will do my very best.

Please note that doc says to use GET/page/lint/{title}.

Therefore, lintHint is using GET on executing page name (revision) queries.

I wonder how that getParsedBody() will be ever reached on GET method.

Current L190 does assign [] to $body immediately.
In lintHint offline development mode I tried it anyway and provided application/json on GET. The error message was kept.
I guess the error message was issued from anywhere else in .org/api/rest_v1/ path, or it is not this rGPAR/extension/src/Rest/Handler/ParsoidHandler being executed.

Please note that it is not very common to ask for any particular Content-Type on a GET query since the message is the URL, and there is no body nor content to be encoded, even more not as JSON. Everything is in the header fields.

The doc tells explicitly that application/json is the format of the answer to a GET query, but does not make any restrictions on the query before.

There is a sandbox form on doc page. Just fill in Wikipedia_talk:Linter and watch the answer.

Greetings --PerfektesChaos (talk) 21:17, 4 January 2020 (UTC)[reply]

Okay, we'll look a bit more closely during the week and see what is going on. SSastry (WMF) (talk) 03:17, 5 January 2020 (UTC)[reply]

This might be a RESTBase issue that forwards linter request to Parsoid. Parsoid's lint API endpoint is a POST request (Parsoid supports posting wikitext to get linted). We'll dig into that. As for the offsets problem, https://gerrit.wikimedia.org/r/c/mediawiki/services/parsoid/+/562094 should fix that once reviewed, merged, and deployed SSastry (WMF) (talk) 08:08, 6 January 2020 (UTC)[reply]

The gerrit patch was deployed about 7 hours back, and the offsets problem should now be fixed. We haven't yet looked at the HTTP 415 problem. SSastry (WMF) (talk) 04:52, 9 January 2020 (UTC)[reply]

I have only had time to look at two articles, but the highlight targets were perfect, and the "Error: Unsupported Media Type" is gone as well. At least for me, things are working again. Thanks for the quick turnaround! – Jonesey95 (talk) 06:19, 9 January 2020 (UTC)[reply]

Cleanup question/ideas/request for lint errors

First question does the bots for this do any auto work on the user talk pages or are they ignored for these purposes? The above will probably modify my further questions and ideas. Thanks121.99.108.78 (talk) 17:26, 7 January 2020 (UTC)[reply]

Yes, there is at least one bot approved to fix Linter errors in editor signatures, some of which appear on user talk pages. – Jonesey95 (talk) 19:04, 7 January 2020 (UTC)[reply]

Hi Jonesey95, thanks for that, however, I was looking more at the lint table of table errors that appear to be not related to signatures, and note that there are 1,000's of various errors on user talk pages, if the bots skip those then I may try to go in a different direction to try to reduce both the overhead and error reports to focus the workload and effort. Such as archiving user talk pages that have no activity/edits in the last say 6 months and or sending a message to active uses to delete the table in a uniform and trackable way, or asking them to request help to fix if the table is still valid and needed.... more to follow. Can-o-worms afoot?121.99.108.78 (talk) 19:28, 7 January 2020 (UTC)[reply]

I don't know whether you are being deliberately vague, but some specific examples, with links, would help clarify what you are asking. Since you specifically mentioned archiving user talk pages, that is generally left up to the user, and archiving would not get rid of the Linter error, it would just move it to the archive page. – Jonesey95 (talk) 22:14, 7 January 2020 (UTC)[reply]

Hi Jonesey95, certainly not trying to be vague or ambiguous, however, detailing one or two would not be that beneficial to the bigger picture, hence I asked if "the bots skip" user talk pages, essentially I was looking to drive a more focused report that Lint fixing editors see and only required work appears on each report and not have them clogged up with, in some cases, millions of signature errors, e.g. Tidy bug affecting font tags wrapping links (3,591,242 errors) (as at today). Driving that report can be somewhat time and resource heavy, I note your archive comment above, can we then set-up a bot to replace all error tagged signatures, say with a plain text version, across the project and advise or correct any current editors signature going forward, this will also solve some other lint errors. I know this is not an easy or quick fix, however, I do not want a quick fix, future proofing and targeted resources is the goal.121.99.108.78 (talk) 02:56, 27 January 2020 (UTC)[reply]

Moved to Wikipedia:Bot_requests#Bot_for_lint_errors for now, more may follow121.99.108.78 (talk) 10:09, 28 January 2020 (UTC)[reply]

How to reliably replace center tags

I can sometimes replace center tags with div tags set to style="text-align:center;" or style="margin:auto;", but it doesn't work reliably for things that are not text. I am looking at {{TOC001}}, and no matter what I try with div tags, I have been unable to get the TOC to sit in the middle of the page. Web searches have proved less helpful than I thought they would be. Does anyone have a reliable way to replace center tags with div tags when they wrap a big block of stuff? – Jonesey95 (talk) 22:45, 7 February 2020 (UTC)[reply]

Jonesey95 Usually issues like this are due to the child elements having an opinionated alignment, and because there was not a width on the parent element (0 auto is not pure magic), the div just says "okay, I'll lay out like the child" (I think that's what the auto actually means :D). I believe I've corrected it in Template:TOC001/sandbox. --Izno (talk) 23:40, 7 February 2020 (UTC)[reply]

Hmm, I see what you did, but I do not see how to turn that into generalizable advice to put on a page like the MW Linter obsolete tag page. – Jonesey95 (talk) 23:56, 7 February 2020 (UTC)[reply]

I don't really know how to do that either. I think just working with the two and then telling people to ask for help if one or the other two solutions doesn't work is probably preferable here. --Izno (talk) 00:07, 8 February 2020 (UTC)[reply]

Just putting this here in case someone else is looking for it: to center a whole table instead of wrapping it in center tags, this may work:

{| class="wikitable" style="margin-left: auto; margin-right: auto; border: none;" – Jonesey95 (talk) 18:46, 14 February 2020 (UTC)[reply]

The margin left/right declarations are almost equivalent to margin: 0 auto (difference of course is setting top/bottom borders to 0). Border none shouldn't be of interest and I expect that would be more likely to cause the border to disappear entirely... which is obviously suboptimal. --Izno (talk) 20:38, 14 February 2020 (UTC)[reply]

I just copied it from HELP:TABLECENTER. For some reason, I tried it on one table, and it added a border, which was weird. I've been leaving it out ever since. I don't think I will ever understand CSS. Anyway, I was able to use the left/right stuff to center a bunch of tables in templates, fixing a nice pile of Linter errors via transclusions. – Jonesey95 (talk) 02:02, 15 February 2020 (UTC)[reply]

"Page information" sometimes does not match actual Linter error count

Watchers of this page may be interested in T246403, which describes a problem I recently encountered. On a significant number of pages (I encountered at least a dozen while flipping through about 600 pages), the count of Lint errors on the "Page information" page is much lower than the actual count of errors on the page (visible via LintHint and manual inspection of the wikitext). This prevents the pages from appearing in User:Galobot/report/Articles by Lint Errors, a report that is supposed to show the 1,000 articles with the most Linter errors. A purge and a null edit did not fix the discrepancy. – Jonesey95 (talk) 01:10, 28 February 2020 (UTC)[reply]

Limits on custom signatures

(reposting text verbatim from a post by Whatamidoing (WMF) at Wikipedia:Bots/Noticeboard:) Please see mw:New requirements for user signatures. One of the goals is to make it easier for bots/scripts/tools to recognize custom signatures (e.g., by requiring that they all contain a link). Please share information or examples over there. – Jonesey95 (talk) 20:15, 4 March 2020 (UTC)[reply]

Note that one of the proposed requirements is that new or modified custom signatures with Linter errors will not be permitted to be saved by editors. They will need to fix Linter errors, including obsolete tag errors (e.g. font tags), before their new/modified custom signature can be saved and used. – Jonesey95 (talk) 20:15, 4 March 2020 (UTC)[reply]

Templates with noinclude markup surrounding table opening markup

There are now 52 fostered content lint errors for templates. Many of these are caused by markup along these lines:

<noinclude>{| </noinclude>

The fostered content lint error typically goes away when reduced to

{|

and these templates are not causing fostered lint errors where they are transcluded. Can the linter be revised to treat noinclude markup better, to make these lint errors go away? —Anomalocaris (talk) 02:23, 15 April 2020 (UTC)[reply]

Linter should probably just ignore noinclude tags, though there might be some side effects. When you put the template into Special:ExpandTemplates and expand it, there are no Linter errors. This feature request is already in Phabricator at T222643, created almost a year ago. My understanding is that the relevant developer resources are focused on Parsoid right now, and Linter will get some attention later in 2020. – Jonesey95 (talk) 04:54, 15 April 2020 (UTC)[reply]

Null edit now causes quick recalculation of lint errors

For a long time, I used to "adjust white space to force recalculation of lint errors", but this is no longer necessary. Thank you to whoever worked on making a null edit cause a quick recalculation of lint errors! —Anomalocaris (talk) 19:21, 1 June 2020 (UTC)[reply]

Where are you seeing this updated count appear? A while ago, I submitted a bug report related to what I think you are talking about, at T246403, but I am unable to make a null edit change the error count on Page Information for User:Jonesey95/sandbox21. – Jonesey95 (talk) 20:56, 1 June 2020 (UTC)[reply]

Here's another one, if it helps: Cuisine of Pembrokeshire. There are 35 missing end tag errors on this page, but Page information shows only 14. – Jonesey95 (talk) 21:08, 1 June 2020 (UTC)[reply]

Jonesey95: I tried a null edit of User:Jonesey95/sandbox21 and it didn't update the lint errors from 1 missing end tag. I made a copy of it at User:Anomalocaris/sandbox/Lint Test and there the information page shows 4 missing end tags. Um, well I thought it did, but now it shows 1. So the problem is not with the updating of the lint counter, but that the lint counter doesn't count very well. As for Cuisine of Pembrokeshire, lintHint shows 14, not 35 lint errors, so page information is correct.

My observation of making null edits to update error counts was in the portal space. I didn't keep track of things, but looking back, I see I edited Portal:Tajikistan/Things you can do and fixed a misnested tag, and then I suppose I did a null edit of Portal:Tajikistan, and it doesn't have a misnested tags lint error, so the null edit updated the count. Similarly, I edited Portal:Gibraltar/Selected picture/1...Portal:Gibraltar/Selected picture/10 and Portal:Gibraltar/Categories, fixing obsolete center tags, and then I suppose I did a null edit of Portal:Gibraltar, and this zeroed the Information page count of obsolete HTML tags. Also, I edited Portal:North America/To Do and Portal:North America/Projects and did a null edit of Portal:North America. —Anomalocaris (talk) 10:27, 4 June 2020 (UTC)[reply]

The change to Cuisine of Pembrokeshire's count was due to a partial fix of the Linter errors by WOSlinker. As you can see, they fixed a bunch of errors, and the count is still at 14 (perhaps coincidentally, the number of errors that WOSlinker left behind).

I find that sometimes a minor edit will cause the Page Information's Linter error count to be updated, but the reason I submitted the bug is that usually, in my experience, the count stays the same unless all of the errors are fixed. I haven't done a ton of experimenting with it, since I think the WMF developers should fix the problem so that null edits update the Linter error count (to an accurate value) in the same way that they update category memberships and renderings of transclusions. The big implication of the bug is that there are many articles and other pages lurking out there with high error counts, but we don't see them on reports like User:Galobot/report/Articles by Lint Errors. – Jonesey95 (talk) 14:32, 4 June 2020 (UTC)[reply]

You can reset the lint counts with a purge action. -- WOSlinker (talk) 15:53, 4 June 2020 (UTC)[reply]

That doesn't work for me at User:Jonesey95/sandbox21. Both purge and null edit appear to work occasionally, but not at all reliably. – Jonesey95 (talk) 18:20, 4 June 2020 (UTC)[reply]

Just now I edited Category:Satanist Wikipedians. lintHint showed a missing end tag for <b> localized in User:Phunting/Userboxes/LaVey. Leaving that edit session open, I edited User:Phunting/Userboxes/LaVey to remove a missing end tag error for <b>. Then I opened the information page for Category:Satanist Wikipedians and the missing end tag was still there. Then I saved without changing anything (null edit) and within two seconds, the information page updated to show zero lint errors. I have had similar experiences many times since I opened this thread June 1. A null edit really does cause a recalculation of lint errors. —Anomalocaris (talk) 01:52, 11 June 2020 (UTC)[reply]

Yes, but only sometimes, as I said above. When I null-edit User:Jonesey95/sandbox21, the Page information is stuck at 1 missing end tag error, even though there are 49 actual errors on that page. – Jonesey95 (talk) 13:33, 11 June 2020 (UTC)[reply]

Jonesey95: I edited User:Jonesey95/sandbox21 inserting <strike></strike>, and this updated the information page to show Missing end tag: 1, Obsolete HTML tags: 1. The problem is not that the count doesn't update. The problem is that sometimes, it counts only one out of several instances of an error. —Anomalocaris (talk) 18:25, 15 June 2020 (UTC)[reply]

Fair enough. My bug report describes that situation accurately. The developers might work on it someday. I have submitted a bunch of little Linter-related bug reports. – Jonesey95 (talk) 18:54, 15 June 2020 (UTC)[reply]

Lint error grid not found

Tracked in Phabricator
Task T254690

The lint error grid is giving a 404 not found. —Anomalocaris (talk) 20:36, 7 June 2020 (UTC)[reply]

I notified Firefly on their talk page. It's a bummer, too, because I just fixed like a thousand fostered content errors in main space and wanted to get some instant gratification by reloading the page. – Jonesey95 (talk) 22:56, 7 June 2020 (UTC)[reply]

The maintainer is having issues migrating to toolforge.org. (phab:T254690) — JJMC89 (T·C) 23:15, 7 June 2020 (UTC)[reply]

You are right. I am facing issues. I will try to resolve the error at the earliest. Sorry for the inconvenience caused. Adithyak1997 (talk) 11:25, 8 June 2020 (UTC)[reply]

@Anomalocaris:, @JJMC89: The issue is resolved. Adithyak1997 (talk) 16:28, 9 June 2020 (UTC)[reply]

Adithyak1997: Thanks! But the page hasn't updated since 2020-06-09 08:08:58, almost two days ago. It used to run every hour or two. —Anomalocaris (talk) 01:55, 11 June 2020 (UTC)[reply]

@Anomalocaris I have removed myself as the maintainer of the tool. Now, a new maintainer is needed for the same. I think the project will have to be upgraded to new Python version. Adithyak1997 (talk) 05:32, 11 June 2020 (UTC)[reply]

Signature replacement

I would like to know how the following signature can be replaced by removing the lint error:

<font style="font-variant:small-caps" color="darkblue" size="3px">Vēnī‧vīdī‧scrīpsī</font>

Adithyak1997 (talk) 19:23, 1 July 2020 (UTC)[reply]

Convert to span tags, like this:

Vēnī‧vīdī‧scrīpsī

Note that there are minor changes to the punctuation required. – Jonesey95 (talk) 20:14, 1 July 2020 (UTC)[reply]

If there is no link,

<span style="font-variant: small-caps; color: darkblue; font-size: 3px">Vēnī‧vīdī‧scrīpsī</span>

. If this is to be used in/around a single link,

[[Veni vidi vici|<span style="font-variant: small-caps; color: darkblue; font-size: 3px">Vēnī‧vīdī‧scrīpsī</span>]]

. If multiple links, we can provide an answer for that too, but it is a slightly different look at that point. --Izno (talk) 20:17, 1 July 2020 (UTC)[reply]

Removing /right/ option in image syntax

I'm getting a little sick of my watchlist getting cluttered with obsessive-compulsive removal of |right in image invocations, as if that's some sort of error [1]. It's not. There are valid reasons we might want to give |right explicitly, and going around removing it is just plain silly. Izno, you've got a good head on your shoulders -- maybe you can look into this. Fixing errors is good; fixing non-errors is evil. E Eng 20:26, 20 October 2020 (UTC)[reply]

Well fuck, here I get all up in arms and it turns out I'm being an idiot asshole. I apologize. In mitigation, in the past a lot of truly annoying, useless gnoming used to go on, and with the retirement of certain editors that seemed to have stopped, which was a great relief. So when I saw this, it's like when someone has a ~~prophylactic~~ ~~Anabaptist~~ anaphylactic reaction to something because you immune system has been hypersensitized by previous exposure. So again I apologize, but please let's not go back to the old days. E Eng 21:16, 20 October 2020 (UTC) And the edit summary could have been more explicit.[reply]

Did I mention that I deeply, truly, humbly and contritely apologize for flying off the handle? E Eng 21:19, 20 October 2020 (UTC)[reply]

I think you might have mentioned something about it ;-) Primefac (talk) 21:27, 20 October 2020 (UTC)[reply]