A different set of Linter errors inside Template:Pre popped up at https://en.wikipedia.org/w/index.php?title=Wikipedia:Press_coverage&oldid=1326593225

Please see T412577, which may have been caused by changes related to this template at en.WP.

"Your Wikipedia account is almost complete" seems like it is missing a word or two. One does not "complete" a Wikipedia account. How about "Creation of your Wikipedia account is almost complete"?

This Linter problem is still happening. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1325855942 for an example found in the wild today.

I don't think we need to hide the graph. Please just add the word "maximum" before the number "1,000". That provides enough information.

Done at T410345. You can close this ticket. Thanks.

That editor has 66 contributions in the last four years, so I suspect that the WMF might have to take responsibility for that supported gadget. I left a message on the author's talk page on the off chance that they are watching.

Item #1 in the initial bug report is not fixed.

A new version of this bug has been found. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1321865922 where the option "super" and the caption "super" are used for an image, and the second "super" is both (a) detected as a bogus option and (b) not displayed as hover text.

I can replicate this problem by zooming in and out.

Is there a reason that this minor inconsistency has not been fixed? I clicked on the link above and muddled my way through to https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/pull/4/commits/162527e0526ae6e6dce309e743dd31f679e9aada but then I got a link telling me that I needed to install a command-line program on my Mac and do some SSH stuff, which is beyond what I am willing to try right now just to fix what is essentially a copy editing error. Maybe someone here can use my diff above to submit an actual patch.

The page at https://en.wikipedia.org/w/index.php?title=User_talk:Nishidani/Index&oldid=1263003121 contains multiple ! characters inside a "display:none" span. They appear to be interpreted as table markup. I don't know if that is a bug, and if so, if it is the same bug as this one. It's something to look at, anyway.

What's happening on this task? These info cards still provide significant amounts of misleading information. Please at least add a disclaimer.

In T162291#11049378, @Esanders wrote:

Hey Erik. Yes - pasting external links is configurable since T129546 and enabled on mediawiki.org, metawiki, officewiki etc.

$wgVisualEditorAllowExternalLinkPaste = true;

In T403653#11148121, @cscott wrote:

If the Parsoid behavior is correct, I'm inclined to resolve this as 'Declined' since the legacy parser is already being deprecated. Parsoid is expected to be the default within a year.

In T396789#11137475, @Novem_Linguae wrote:

Saw this in tech news. Thanks for your work on this. My watchlist already groups by pages and I like the feature.

Can you clarify exactly what you're changing? Are you just pulling this already existing setting out of a menu, for increased visibility?

On the English Wikipedia, https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/Bot1058_8 has been running for over three years to work around this issue, and as far as I know, there has been no negative impact on performance, with the positive impact of providing more accurate category populations and Linter tracking information to editors.

I have removed all instances of "cx-segment" from en.WP article space as of this date stamp. (link to search). That search link can be used to see if any new instances arrive (excluding "new" instances via reverts or page moves).

I think that I already have that kind of grouping on en.WP, by enabling "Expand watchlist to show all changes, not just the most recent".

Is there a place other than Phabricator where we can see this in action? The screen shot, with grouping enabled, looks just like my regular watchlist at en.WP.

I had this problem at https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Templates&oldid=1305235543 when trying to edit the last section.

This task might want to be linked to T208072.

Possibly related: T348149.

This task might want to be linked to T208072.

At least in the English and German Wikipedias, all of the fostered content errors have been fixed for a while. Making such pages uneditable in VE should be fine; to make them editable, editors just need to fix the fostering using a source editor.

The fundamental problem is that the top-of-page header is different from the sticky header, which is very confusing from a UX perspective.

This works for me:

If there is a 1,000-item limit for some of the data, that should be clearly stated somewhere. It causes many issues; some are listed at https://www.mediawiki.org/wiki/Talk:Product_Safety_and_Integrity/Anti-abuse_signals/User_Info#Data_is_wrong_for_reverted_edits,_edits_in_last_60_days,_and_probably_more

Since T213258 was closed as a duplicate, here's my recent comment from that task:

This is still happening:

This is still happening, six years later. See https://en.wikipedia.org/w/index.php?title=Abdourahamane_Soli&oldid=1303063596

This bug is still present. See https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1303358064

This may be related to T132467.

I don't see Diff pages mentioned here. This page is missing the spacing between the namespace and the title:

Well done. Thanks for addressing this bug.

Thanks for these answers, even though they are dissatisfying. I would hope that the parser could check the actual output for compliance with having both a color: and a background-color: specified, since that is the underlying concern.

Still happening.

Thank you for asking about this at en.WP. A brief discussion, linked from a couple relevant notice boards, has not surfaced any potential negatives regarding this new Linter "category".

Thanks. I have fixed the Medal template that had line break issues. All issues related to these changes appear to be resolved.

Possibly related to this parsing change:

The problem appears to be related to table markup used inside image captions, which again, renders fine.

This is still happening. Please fix pasting of ISBNs so that they are pasted as text. The explanation by DLynch above does not make sense. If I paste "foo bar", it pastes as plain text. Pasting "ISBN 1234567890" should be the same. If I type that string in the regular editor, I see plain text and it is saved as plain text. There is no linking involved. VE should behave the same way.

In T47224#10605603, @Danny_Benjafield_WMDE wrote:

@Jonesey95 you might find this Wikidata tool very helpful: EditSum

A bot just cleaned up hundreds of edits caused by this bug on the English Wikipedia, and they are happening again at a rate of at least one per day. Here's one from teh last 24 hours: https://en.wikipedia.org/w/index.php?title=History_of_the_metre&diff=1274677738&oldid=1274351949

I just had a need for an edit summary again. I made these edits because importing the unranked data was causing an error on Wikipedia. I would have been happy to explain my edit, but there was no way to do so. I was reverted by someone who didn't understand why I made the edit, and the only way to provide an edit summary was to revert.

Template:Short description on en.WP has been modified as requested.

This is still happening. It's been two years since this apparently simple bug was reported. Please fix. https://en.wikipedia.org/w/index.php?title=Economy_of_Spokane,_Washington&curid=21067578&diff=1272521263&oldid=1265830445

What is happening?

This is still happening (September 2024): https://en.wikipedia.org/w/index.php?title=Alpha_Beta_Alpha&diff=1244031457&oldid=1242538958

I'm not sure why this is stuck or needs analysis. Show the existing sticky header on all pages when they are scrolled. Done. If you want to change the content of the sticky header, that can be a different ticket.

Possible bug: An editor using the Android app reports that they were prompted to add a short description to an article that already had a short description of "None". This should not be happening. Please investigate. See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Short_description&oldid=1267806510#Is_none_case-sensitive?

In T326898#10383980, @Dbrant wrote:

All the updates have been deployed, but it looks like there are some loose ends:

• SDNONE still has some pretty ingrained guidance about using none for the intentionally-empty case. Should someone update that page?
• The shortdec-helper gadget still treats none as the intentional case, and treats an empty description with a CTA to "add" a description. This would need to be updated, too.

In T326898#10392753, @ARamadan-WMF wrote:

Received from the support email:
"The Wikipedia Android app suggests users add short descriptions to articles with the {{short description|none}} template. For an example, see "Domestication of the cat" on enwiki. That template with the value set to none is used to mean a short description is not needed, i.e. the title is descriptive enough. When users add short descriptions to those articles, they end up being confusing because they either restate the title or say something that shouldn't be in a short description."

Not fixed for me. See attached screen shot, taken just now. Note browser inspector pointing at empty, 24px-tall space labeled vector-sitenotice-container.

The permalink for the demonstration is https://en.wikipedia.org/w/index.php?title=User:Amire80/templatestyles_content&oldid=1229737521

Thanks for the quick and detailed attention. I hope the fix works.

Something has changed recently, even in Vector 2022. Yesterday, red links were showing as red for me, even with this code in my personal CSS:

In T315347#10261564, @Jdlrobson wrote:

In T315347#10261554, @Jonesey95 wrote:

Here's a screen shot from my browser on the linked page, with relevant inspector information highlighted. I am logged in, in mobile mode, in Firefox for Mac OS. Logged out, I see red links. Where could the blue color be coming from? I don't know enough about the CSS to know where load.php is pulling this color from.

I looked through my preferences and saw a few gadgets that adjust link color, and I guess if I have to turn them off in batches to see what fixes it, I could, but any clues would be helpful.

It's coming from your user CSS: https://en.wikipedia.org/wiki/User:Jonesey95/common.css#L-286 - common.css loads on all skins including mobile and will override any existing rules. You'll need to revise it.

Here's a screen shot from my browser on the linked page, with relevant inspector information highlighted. I am logged in, in mobile mode, in Firefox for Mac OS. Logged out, I see red links. Where could the blue color be coming from? I don't know enough about the CSS to know where load.php is pulling this color from.

This bug report is from 2022. It is not recent, but it is still happening. The reason that I found it is that I was alerted to this rendering problem in a conversation on my talk page after I reverted another editor for leaving a red-linked template on a page. The editor reported that nonexistent templates do not show up in red on mobile, and I was able to verify the problem.

This is still happening. It appears to be a Visual Editor bug.

See also T315347, which appears to be related.

This appears to be a generalized mobile view problem, not just an apps problem. See https://en.m.wikipedia.org/w/index.php?title=Fran%C3%A7ois_Mitterrand&oldid=1250330772 for an example (I am using Firefox for Mac OS on a computer, clicking the Mobile link at the bottom of the page). The nonexistent "Template:ISBN)" shows as blue, as do all of the nonexistent article links in the succession boxes at the bottom of the page (Roger Gillot, Jehan Faulquier, etc.)

Thank you for the explanation. It would have been helpful to have this explanation earlier. Now that the category is mostly cleared out on en.WP, it has revealed at least one Linter bug; I filed T376943. So this code is useful on en.WP after all!

This change should be reverted entirely, as far as I can tell. Special:LintErrors/bogus-image-options already detects this condition. Why have a tracking category for this one condition and not for all of the Linter issues, as has been requested many times?

When you create a new Linter error, even if it is hidden, make sure to add it to https://www.mediawiki.org/wiki/Help:Lint_errors and complete the rest of the "new Linter error" checklist.

See this detailed discussion.

This is still happening. A fix would be welcome.

I suggest using a bronze star, not a green star. In the Olympics, for example, gold is for the top performance, silver is for second place, and bronze is for third place. We should use that existing color scheme, which is known by everyone.

In T200517#10181767, @ABreault-WMF wrote:

including the Page Information entry for each page

Do you have an example where it isn't showing up? It appears to be working here,
https://www.mediawiki.org/wiki/Extension:Scribunto?action=info#Lint_errors

Can someone please perform the rest of the "add a new Linter condition" checklist before closing this ticket? The new condition needs to be added to the lists in which Linter errors appear, including the Page Information entry for each page, and the necessary documentation and help pages need to be completed.

https://en.wikipedia.org/wiki/User:Shrikarsan/shri.js has a link that goes to a different location than expected. The link is:

In T368166#10171647, @stjn wrote:

It would be much more helpful to others if you actually provide links to false positives.

This new behavior appears to have some false positives and undesired conversion of plain, unlinked text into links. As such, it should probably be opt-in via text inside the syntaxhighlight tag rather than on by default.

I am unable to replicate it either. I have asked at https://en.wikipedia.org/wiki/Wikipedia_talk:VisualEditor#consistently_creates_referencing_errors

This problem is still not fixed (link is to a mass message from 14 September 2024). This message went to 1,293 pages, according to search results!