Wikipedia talk:Linter

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Night mode: New lint rule[edit]

The Wikimedia Foundation Web team is currently working on a dark theme for Wikimedia projects and soon Wikimedia skins will support two color schemes.

This has implications on user-generated content which in the past has made understandable assumptions about how the content will be displayed. For example in the past, if text was given a yellow background the assumption was made that the text color would be black. In dark mode where the text will now be white, this creates accessibility issues.

While the Web team is aiming to minimize the work required by editors in the short term, this work has flagged a long-term need for lints to help editors locate pages with accessibility issues. Next week, we will add a new linting rule to flag pages which we have identified as problematic. To minimize disruption this will be initially hidden as we iron out any problems. The Web team has provided a set of recommendations to support this work.

In addition to this and to reduce the burden new lint rules can cause to the community workflow, we are working with the Content Transform team on T334527  so that community adoption/acceptance of lint rules in future can be done separately from the creation of them. We are documenting this on mediawiki.org.

Please let us know about any questions or concerns you have by replying here. You can also raise bugs by creating a ticket in https://phabricator.wikimedia.org/project/view/6717/.

Thank you! Jdlrobson (talk) 17:07, 14 March 2024 (UTC)[reply]

I'm wondering how signatures with colors will work with the dark theme and if they will be flagged by the linter. Gonnym (talk) 17:29, 14 March 2024 (UTC)[reply]
Jdlrobson, thanks for the note, the links, and the process improvements. Are there instructions anywhere explaining how to turn on this new night mode so that we can see if the lint-flagged condition really causes a problem? That might help us determine if the lint condition is flagging any false positives. I also have a question similar to Gonnym's: many signatures use code like font color=black or span style="color:black" to color text, with no specified background color. Will those signatures be flagged by the new linting rule? If so, I foresee a LOT of errors. – Jonesey95 (talk) 18:00, 14 March 2024 (UTC)[reply]
If they are flagged, how will they interact with the new rule that doesn't allow lint errors in signatures? Gonnym (talk) 18:32, 14 March 2024 (UTC)[reply]
Those will not be flagged for now. Right now we are only flagging the case where background is defined without a color.
Those will be an issue with the night mode feature however.
You can test night mode (for time being only working on mobile) by appending ?minervanightmode=1 or ?vectornightmode=1 on any URL. Jdlrobson (talk) 19:54, 14 March 2024 (UTC)[reply]
Jdlrobson, it appears that signatures are indeed being flagged by this new Linter rule. Is this intentional? See this VPT post. – Jonesey95 (talk) 16:41, 22 March 2024 (UTC)[reply]
Also, the Linter rule appears to have errors detecting nested span tags. See T360797 and mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled, two related cases. – Jonesey95 (talk) 16:56, 22 March 2024 (UTC)[reply]
Was wondering that too. I will say though that I regularly use a dark mode browser addon (Dark Reader), and any black text is displayed as white, so curious if that will be a similar thing with this Wikipedia setting, or if black = black in all cases. The addon I use does make some color combos that look fine in light mode turn hellish in dark though; cyan backgrounds almost always are hell with this as it leaves the cyan background alone, but turns the darker text shades to a lighter (inverse?) color and the combo becomes unreadable. In those cases I've had to turn it off to preview those pages I'm fixing. Zinnober9 (talk) 23:10, 14 March 2024 (UTC)[reply]
Related discussion at Template talk:Episode list#Accessibility problems with this template in night mode (also by Jdlrobson).
Some TV related templates that use colors that should be tested they aren't producing lint errors:
Gonnym (talk) 06:45, 15 March 2024 (UTC)[reply]
Probably most sports navboxes which already violate color will also appear on this list. Gonnym (talk) 17:34, 17 March 2024 (UTC)[reply]
@Jdlrobson, see mw:Talk:Reading/Web/Accessibility_for_reading#Signature_disabled. Sdkb talk 16:16, 22 March 2024 (UTC)[reply]

How much attention should be paid to this new tag?[edit]

I am finding it challenging to determine how much attention to pay to this new tag. When I am logged out, the code to force vector night mode results in a bunch of black-on-black and blue-on-black text for me (example: John Dalton), except, ironically, in elements like navboxes and message boxes, many of which trigger this new Linter rule. Those items show in "regular" mode, with white backgrounds, not anything like "night" at all.

I posted a note to Template talk:Navbox with some thoughts about that template's triggering of this new rule. It is unclear to me whether something actually needs to be fixed, because when I force night mode, everything on the page looks terrible except for the element that is supposedly out of conformance. Because of my inability to make night mode function reasonably, I have no way to test whether adding an explicit color declaration does anything useful. I feel like I'm missing something. – Jonesey95 (talk) 05:23, 23 March 2024 (UTC)[reply]

The night mode for Vector 2022 hasn't been built yet. It will be built over next 4 weeks in an identical fashion to Minerva. We are releasing the lint error so editors get a head start on fixes. ?vectornightmode=1 is therefore not the query string to use. You need to use Minerva for now e.g. https://en.wikipedia.org/wiki/John%20Dalton?minervanightmode=1&useskin=minerva.
You can also add the following to Special:MyPage/minerva.js to force night mode on for all pages (e.g. template namespace)
(function () {
   const c = document.documentElement.classList;
   if ( c.contains( 'skin-night-mode-page-disabled' ) ) {
     c.remove( 'skin-night-mode-page-disabled' );
     c.add( 'skin-theme-clientpref-night' );
   }
}());
🐸 Jdlrobson (talk) 06:00, 23 March 2024 (UTC)[reply]
Also here's an example of a fix: https://en.m.wikipedia.org/w/index.php?title=Grand_Slam_(TV_series)&diff=1215109361&oldid=1203322851&title=Grand_Slam_%28TV_series%29&diffonly=1
From what I can see the lint rule is working as expected. 🐸 Jdlrobson (talk) 06:01, 23 March 2024 (UTC)[reply]
Thanks for the Minerva tip; I was just applying the instructions you gave above and was confused. That Minerva string works on the John Dalton page, but when I go to https://en.wikipedia.org/wiki/Template:Bolvadin_District?minervanightmode=1&useskin=minerva or https://en.wikipedia.org/wiki/User:Jonesey95?minervanightmode=1&useskin=minerva I see a regular look. What am I missing now? – Jonesey95 (talk) 13:23, 23 March 2024 (UTC)[reply]
There is rule in Minerva to mitigate breakage: [style*="background"] elements get set to a black color with !important. The hope is to eventually remove this when the lints are fixed. You can disable this rule in developer tools if that is helpful. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)[reply]
Also see my script above to force it on for other namespaces. 🐸 Jdlrobson (talk) 14:46, 23 March 2024 (UTC)[reply]

bgcolor[edit]

Using bgcolor in a table doesn't trigger the lint rule. It's only seems to be triggered by background in the style attribute. 

{| class="wikitable"
|bgcolor="yellow"|test
|}

-- WOSlinker (talk) 13:01, 1 April 2024 (UTC)[reply]

good point. I thought bgcolor was already covered by Special:LintErrors/obsolete-tag but I guess that only applies to HTML4 tags not attributes? 🐸 Jdlrobson (talk) 00:46, 2 April 2024 (UTC)[reply]
If these attributes are also obsolete they should probably be tracked by the lint. Gonnym (talk) 12:47, 8 April 2024 (UTC)[reply]

New Linter tracking tag: night-mode-unaware-background-color[edit]

Links related to the above section: See Special:LintErrors/night-mode-unaware-background-color and mw:Help:Lint errors/night-mode-unaware-background-color. The relevant feature creation task was T359205.

I don't have time to work on anything related to this in the next week, but I am putting some links here in case people are wondering why many of the reports changed today. Queries may have to be adjusted, or maybe these conditions might be easily fixable in a few templates. I don't know, since I haven't really looked at it yet. – Jonesey95 (talk) 16:17, 22 March 2024 (UTC)[reply]

From an initial poke around, it appears that many or all of the templates listed at {{Table cell templates/doc}}, as well as {{navbox}} and {{ombox}} and probably similar boxes are affected by this new tracking tag. I expect that a systematic fix for some of these sets of templates will be a better path than simply adding a text color specification to each template. – Jonesey95 (talk) 16:37, 22 March 2024 (UTC)[reply]

Request for feedback on Help:Lint_errors/night-mode-unaware-background-color[edit]

Hey there I was curious to hear from people who have used Help:Lint_errors/night-mode-unaware-background-color

I have a few questions

1) How: Forgetting the "why" these need to be fixed, when interacting with the lint rule is it clear what to fix and how to fix it? If not, how could we improve it?

2) Why: How can we improve the documentation over on Help:Lint_errors/night-mode-unaware-background-color to make it clearer why these are important to be fixed?

3) What would need to happen before we could consider promoting this rule so it is not hidden?

Thanks in advance for your feedback! 🐸 (accidentally posted under volunteer account) Jon (WMF) (talk)

Answering 1 and 2. I have found that "color:inherit" seems to work sometimes and break things other times. It is not clear to me why that is the case. Better guidance around when it is safe to insert "color:inherit" might help. When that string does not work, it is not clear what to do. Inserting "color:black", for example, seems counter to letting dark mode pick an appropriate color, but maybe not.
Answering 3. Please refer to the discussion above. Feedback from WMF folks like The night mode for Vector 2022 hasn't been built yet and There is rule in Minerva to mitigate breakage: ... You can disable this rule in developer tools if that is helpful was helpful to me, in that it helped me to understand that this new Linter rule was not ready for me to work on yet. To be able to work on it, I would need a way to look at a page in Vector 2022 (the default skin) using dark mode, see the breakage, and then apply changes and look at them in preview to see whether the problem is fixed. AFAIK, I can't do that yet.
More answers to 3. Jdlrobson has been doing good work around the site to update templates that need fixing. That work is necessary to clear out the vast majority of tracked pages, which have tracking assigned to them by templates such as {{navbox}}. I don't think the rule should be promoted until the template space is largely free of tracked pages and pages affected by transcluded templates have been null-edited to remove them from the lists. – Jonesey95 (talk) 02:31, 19 April 2024 (UTC)[reply]
Answering 2 specifically: Here's an example of where "color:inherit" did not work for me: I tried applying it next to every instance of a background color at {{2008 NHL Entry Draft (WHL draftees)}}, and it turned the "show/hide" links black instead of using the default blue for links. Using "color:black" had the same effect. Not good. I have exhausted the advice in the "How to fix" section of the Help page. What should I have done? – Jonesey95 (talk) 04:22, 19 April 2024 (UTC)[reply]
You are thinking about this correctly. In your example the correct fix would be setting color to something black.
And yes.. this does make the show/hide links black. Previously they were inaccessible in that page when they are blue and the associated code will transfer color to the element. While I think the UI could be improved here (perhaps an icon would be better) at least they are now readable to 100% of people regardless of disability. If you have concerns around the resulting UI it would be worth filing a bug about that. 🐸 Jdlrobson (talk) 14:54, 20 April 2024 (UTC)[reply]

Milestone!![edit]

As of 2024-05-05 20:16:47, NO error type per namespace exceeds 1 million. "Missing end tags" in "User Talkspace" just fell below 1 million. Still have a ways to go before we can say No error type exceeds 1 million total, but certainly getting there!

And for a second (smaller) milestone that is soon approaching, "Table tag to be deleted" will be pretty much gone from all of Wikipedia in the next few days. 137 at the moment with their days numbered. Zinnober9 (talk) 20:32, 5 May 2024 (UTC)[reply]

These two milestones show the power of bots (see Wikipedia:Bots/Requests for approval/Qwerfjkl (bot) 29, a task that eliminated about 60,000 Linter errors in a couple of days) and the power of diligent, plodding human editors (the "Table tag" error was at 5,479 four months ago, and every edit required a manual fix). Keep it up, team! – Jonesey95 (talk) 03:00, 6 May 2024 (UTC)[reply]
Do you already have a next target in mind for the bots? Gonnym (talk) 07:27, 6 May 2024 (UTC)[reply]
There are a significant number of bot-fixable patterns that appear on hundreds or thousands of pages, listed at User:MalnadachBot/Signature submissions. I think going after some of those, especially the higher priority problems, would make sense. It would be helpful if the bot did not have to return to a page multiple times, since that is something people complained about with the previous most-active bot. – Jonesey95 (talk) 13:03, 6 May 2024 (UTC)[reply]
Yeah, I'm already way past the ignore stage for hearing those cries. No one has shown that they can code a bot to fix all errors on a page in one go, so there is really no need to take that unachievable goal into consideration. Gonnym (talk) 16:29, 6 May 2024 (UTC)[reply]
I'm pretty sure that Legoktm's lint-fixing bot had a method of checking to ensure that it was fixing all of the errors that it showed up to fix, FWIW. I don't know how that was done in the code. Unfortunately, that bot, which is still needed, is no longer active. – Jonesey95 (talk) 16:41, 6 May 2024 (UTC)[reply]
I don't think that bot was active that much to begin with, based on the lint decrease at the time. Gonnym (talk) 16:48, 6 May 2024 (UTC)[reply]
Legobot fixed a few hundred thousand Linter errors, as far as I know; here are nearly 5,000 edits performing Lint fixes. I think the operator kept a tally somewhere. I know that I was grateful for its work. – Jonesey95 (talk) 17:30, 6 May 2024 (UTC)[reply]
Jonesey95, I was looking at this earlier, it seems it can be done with Parsoid; see mw:Parsoid/API#Wikitext -> Lint. I've got it working with some python code. — Qwerfjkltalk 17:17, 6 May 2024 (UTC)[reply]
Nice. If you can figure it out, that would be great. I have come across plenty of user signatures that comprise the only Linter error on a given User talk page. This signature, for example, is often the only error on a page; I have fixed a few hundred of them, but it is tedious. – Jonesey95 (talk) 17:30, 6 May 2024 (UTC)[reply]
Jonesey95, from the first page from that search query, User talk:Jim1138, I get:
{'type': 'missing-end-tag', 'dsr': [9646, 9723, 29, 0], 'templateInfo': None, 'params': {'name': 'span', 'inTable': True}}
As far as I can tell dsr[0] and dsr[1] are the start and end indexes, which gives:
e="color:darkblue">Abelmoschus <span style="color:green">Esculentus]] <sup>[[
(There are also around 10 other lint errors on the page that it also returns.) — Qwerfjkltalk 17:45, 6 May 2024 (UTC)[reply]
It's close but not the whole error.
The signature is:
'''―[[User:Abelmoschus Esculentus#s|<span style="color:darkblue">Abelmoschus <span style="color:green">Esculentus]] <sup>[[User talk:Abelmoschus Esculentus#s|<span style="color:orange">talk]] / [[Special:Contribs/Abelmoschus Esculentus|<span style="color:red">contribs</span>]]</sup>'''
the fix is several closing span tags there:
'''―[[User:Abelmoschus Esculentus#s|<span style="color:darkblue">Abelmoschus</span> <span style="color:green">Esculentus</span>]] <sup>[[User talk:Abelmoschus Esculentus#s|<span style="color:orange">talk</span>]] / [[Special:Contribs/Abelmoschus Esculentus|<span style="color:red">contribs</span>]]</sup>'''
Gonnym (talk) 18:28, 6 May 2024 (UTC)[reply]
I have a regex for it in User:Jonesey95/AutoEd/doi.js. – Jonesey95 (talk) 19:15, 6 May 2024 (UTC)[reply]
More interesting: I think that the above misidentification should be filed as a bug if it has not been already. I thought that this was a problem with LintHint, but if it an API problem, maybe it can be fixed. The problem was reported to the LintHint maintainer about six months ago, and appears to have something to do with non-ASCII characters causing offsets to be wrong. – Jonesey95 (talk) 19:18, 6 May 2024 (UTC)[reply]
┌──────────────────────────────┘
Jonesey95, from what I can tell it's the byte offsets. When I account for that properly I get
<span style="color:darkblue">Abelmoschus <span style="color:green">Esculentus — Qwerfjkltalk 17:00, 7 May 2024 (UTC)[reply]
@Jonesey95 A good number of those 5479 Table tags were also triggering a Fostered content error within the same issue, so early on I'd compiled a list of pages containing both errors and hit those pages first to get through more errors quicker. Was exciting how quickly both dropped. Congrats and thanks to @Gonnym for the last Table tag fix, and thanks to Primefac for assisting. Zero remain, leaving "HTML5-incompatible misnesting" as the sole surviving High Priority error type with 9,625 remaining. Zinnober9 (talk) 14:06, 7 May 2024 (UTC)[reply]

Pages with no errors listed[edit]

@Gonnym There was certainly nothing passive aggressive about the edit I made. I even considered adding a parenthetical about there probably having been an error that got fixed, but the caches haven't caught up yet. However, that would have been speculation, since I'm not fully certain if that's the case or not. (There have been cases where I've looked at a number of recent versions and none of them had the listed error.) In any case, the exact reason isn't that important for the editor seeing a page on the list, my point was that there are cases when you don't need to do anything and it's not because you're having a short-circuit in your brain and can't see what's wrong. If you feel it's unnecessary to make a note of this to hopefully avoid people wasting their time like I did a few times when I didn't yet know about these occurrences - so be it, but no unspoken agenda was involved here. Gamapamani (talk) 08:39, 6 May 2024 (UTC)[reply]

I read "Highly impatient editors" differently, I'm happy that was only my reading of it and wasn't your intention. Gonnym (talk) 08:40, 6 May 2024 (UTC)[reply]
Oh, I worded it that way because I'm not sure it should be a general recommendation given that it causes additional server load. Anyway, does this mean that i can restore the note? I'm not attached to the "highly impatient" bit. Gamapamani (talk) 08:51, 6 May 2024 (UTC)[reply]
Yeah, no issues then. Gonnym (talk) 08:53, 6 May 2024 (UTC)[reply]
@Jonesey95, just curious, does your clarifying edit mean that this is happening solely because of transclusions? I've seen many occasions with indeed errors in templates or other transclusions putting nominally correct pages on these lists, but the cases I was talking about didn't seem to be because of that. If anything, the former error scenario mentioned by @Gonnym seems more plausible for them, although it still doesn't quite explain why sometimes previous edits from within a reasonable timeframe (in terms of caching) also didn't have anything. I guess the heavy edit traffic thing was a bit of a conjecture on my part, because I've often seen this with election pages with pretty high update frequency at the time.
And in terms of null edits vs purging, what's more benefitial about the former (since I've seen purging do the job as well)? I hope you don't mind educating me (and perhaps future readers) a bit. Gamapamani (talk) 13:52, 6 May 2024 (UTC)[reply]
No to the "solely because of transclusions". I removed the part about frequent editing, because I have never seen such a correlation. The pages that are transient in some lists are often the opposite: very infrequently edited. I have found that some pages tend to appear in the list as false positives due to their large size, which can cause timeouts that fail to process or render the whole page, leaving unbalanced markup. Other pages, including portal pages, transclude article sections that contain errors or contain closing markup that is outside of the transcluded section.
In either case, a purge changes the page for your display, but only a null edit (click edit, then publish without making a change) will make the error go away on the server side. – Jonesey95 (talk) 14:28, 6 May 2024 (UTC)[reply]
I think Gamapamani is referring to purging the page in the server cache (via the "Purge" option in the "More" menu at the top of the page, Alt+* in FireFox). I've found that removes the page from the error report most of the time, but if that doesn't do it, then I resort to a null edit. —Bruce1eetalk 14:50, 6 May 2024 (UTC)[reply]
Ah, yes, thanks, timeouts being the culprit makes sense. That could easily apply to the elections pages as some of them were quite slow to load. They definitely were frequently edited at the time, though. (But you were quite right to remove this part if you haven't seen the correlation I think I have, to keep things more objective.) I guess I just wasn't expecting Linter to have rather peculiar bugs like putting timed out pages on the error list for specific errors.
As far as purging only changing the page for the purger, I'm not sure that's the case, because linter error lists are generated on the server side (right?) and it does have an immediate effect on them. (Like @Bruce1ee just ninja'ed. I tend to just replace action=edit with purge, though, instead of going through a menu. Or, rather, I should say I've been doing it this way because I haven't seen this menu option.) Gamapamani (talk) 14:54, 6 May 2024 (UTC)[reply]
@Gamapamani: The purge menu option has to be enabled in your Preferences / Gadgets. —Bruce1eetalk 15:19, 6 May 2024 (UTC)[reply]
Thanks, just did that. (Actually, I first searched for "purge" on the gadgets page, found the Add a clock to the personal toolbar that displays the current time in UTC and provides a link to purge the current page option and ticked that without thinking. That's a rather strange gadget...) Gamapamani (talk) 15:29, 6 May 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Linter&oldid=1222770963"