In T135964#12416242, @Wbm1058 wrote:

I see that T132467 has already identified a longstanding problem needing attention, which should probably be a higher priority to address, in favor of further enhancements to this workaround such as taking the work my bots do inside the server's maintenance jobs.

This bug continues to cause Linter errors. Here's one from today: https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AManual_of_Style&diff=1378601273&oldid=1378595402

If this rendering change is not going to be modified to match the legacy parser, please provide a recommendation for fixing pages that are affected by this change.

Can this typo be fixed please? Is it more complex than the initial assessment?

This is still happening. Here's one from 16 September 2026: https://en.wikipedia.org/w/index.php?title=Sea_of_Faith&diff=next&oldid=1375340109

Still happening as of 26 June 2026:

The English Wikipedia has decided not to hide this inconsistent spacing while also encouraging the WMF developers to finish this task (and, by extension, T432324). See this discussion. Thanks.

This looks like a test or an error. The merged tasks should probably be reopened.

I think this and other tasks were marked as duplicates in error.

In T316147#8183261, @matmarex wrote:

If you align the text baseline, the icon will look misaligned instead.

In T316147#8182768, @Aklapper wrote:

I can neither reproduce in Chromium 104 (Vector 2022) nor Firefox 104 (old Vector) on Linux. What does the HTML/CSS show in the browser's Developer tools?

Elena, thank you for confirming that you can replicate the bug. A "Watch" link being present in the Tools menu instead of on the same line as the Article/Talk/Create links is an accurate description of the bug.

Another editor reports that "Watch" and "Unwatch" have moved to the right sidebar's Tools menu, but only for nonexistent pages. I can confirm that this inconsistent UI is currently what I see as well.

Happy belated tenth birthday to this bug report! Maybe it will be fixed on the server side in its eleventh year. https://quarry.wmcloud.org/query/63654 shows that we have articles that are 44 days stale, and that number of days is reduced by a bot workaround while we wait for a server-side fix.

I think this bug has been fixed. Please follow up with an after-action report to understand how this bug was allowed to be in production for almost a week, affecting thousands of articles across multiple Wikipedias. It would be great to avoid this sort of thing happening in production again.

There are a few articles left in the "broken maps" category after null edits, such as https://en.wikipedia.org/wiki/Alfred_the_Great#Death_and_burial and https://en.wikipedia.org/wiki/Boeotia#Boeotian_League

It appears to be fixed on the English Wikipedia. I am null-editing the "broken maps" category members now to see if there are remaining errors; it will take an hour or two.

Changing the template to use %7c renders "%7c" outside of a wikilink. That probably makes it a non-starter. I have taken the liberty of updating your page with an example.

https://en.wikipedia.org/wiki/Category:Pages_with_broken_maps has expanded to 6,764 pages as of this writing. Red error messages are displaying instead of maps.

This appears to be due to a recent code deployment. It was not happening yesterday. See https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1365746588#%22not_a_valid_map_data_page%22 for some links.

According to https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)/Parsoid#Timeline Parsoid was rolled out to Talk namespaces on 20 July, which is probably why this neglected bug is popping up with some frequency in the last couple of days. Some attention to this bug, or reverting the rollout of Parsoid to Talk namespaces, may be helpful.

This issue has become more urgent with the rollout of Parsoid to discussion pages. I have run into it a few times in the past week, and it's a topic on WP:VPT on en.WP. See https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=1365462662#Why_have_section_edit_previews_changed? which is about two different Parsoid rendering and editing issues.

I think that @ppelberg summarizes the concerns well for the English Wikipedia. I can't speak for the other languages that have concerns about colon spacing or non-colon separator characters. Thanks for taking the time to write it up.

does not show the error message

{{#coordinates:}}: cannot have more than one primary tag per page

to the right of the coordinates in the infobox.

In T432127#12134002, @matej_suchanek wrote:

This is not an issue in the gadget nor related to lead section editing, this is how section editing in general behaves (try it).

Wow, that's a lot of infrastructure jargon that I don't understand. As an end user, what I do understand is that the reports that we run on the replicas are able to run daily and on-demand with little trouble, unless they time out. Maybe in the short term, some of the Special reports can run against the replicas instead of against servers that will bog down if reports are run against them. Then they could run more frequently.

You probably have to turn on the gadget called "Add an [edit] link for the lead section of a page".

Since nobody seems to want to finish this task, can we please roll it back in production? Developers are welcome to continue working on it on test platforms to incorporate the bug reports listed above.

In T310456#12115992, @Ladsgroup wrote:

In T310456#12113246, @Jonesey95 wrote:

In T310456#12113083, @Ladsgroup wrote:

In T310456#12112811, @Jonesey95 wrote:

Has this task been addressed? Even if reports take a while to update, it is useful to have them updated daily in order to detect vandalism and other inappropriate edits.

Hi, can you tell me which reports help you detect vandalism?

Any of the above reports, and many more, when they are updated frequently and thus able to be monitored and kept clean regularly, can indicate vandalism. Vandals and careless editors remove categories, leaving pages uncategorized. They remove links, leaving pages as dead ends. They remove valid transclusions of templates, leaving templates on a "not transcluded" report. You name it, vandals do it, and one purpose of pretty much every error-tracking category and report is keeping an eye on vandalism and being able to revert it quickly. When a report is refreshed only monthly or semi-monthly, that job gets much more difficult, and vandalized pages are visible to the world for much longer.

Here's an example: This careless edit removed the documentation from a template, which caused the page to appear on a report of templates with no categories. Because we keep that report clean and it refreshes daily, the careless edit was easy to fix before it was seen by many people, and before it was amended or "fixed" in some unhelpful way.

In this example, which report would have reflected that? The problem is that I need to know which one of these reports are higher priority and which ones can be done semi-regularly.

In T310456#12113083, @Ladsgroup wrote:

In T310456#12112811, @Jonesey95 wrote:

Has this task been addressed? Even if reports take a while to update, it is useful to have them updated daily in order to detect vandalism and other inappropriate edits.

Hi, can you tell me which reports help you detect vandalism?

I am able to reproduce this issue: See https://en.wikipedia.org/w/index.php?title=Auckland&action=submit&section=0&useparsoid=1 (which says "this page was rendered with Parsoid" at the bottom of the page)

Has this task been addressed? Even if reports take a while to update, it is useful to have them updated daily in order to detect vandalism and other inappropriate edits.

In T430854#12097147, @ssastry wrote:

Hi @Jonesey95 we just bumped up the limit a bit higher (1000 -> 1250) to unbreak rendering on a few more pages.

We need a limit. Otherwise the pages timeout or won't render properly. So, the discussion would be around what a reasonable limit is. If you have examples of other pages that are currently broken, we can evaluate what is a suitable limit. while we also fix the rendering issue (the UX that stjn flagged).

Unbreak now, please. Please remove this limit immediately while developers discuss options, implement a tracking category, if needed, and work on a better way to resolve the underlying problems. This unrequested feature of Parsoid has broken pages in the English Wikipedia article space that were working fine before Parsoid.

In preview, Lifes Rich Pageant (Parsoid edit link) on en.WP displays one normal Script warning for cite AV media notes, then displays "Script warning: {cite AV media notes}: this reference has maintenance messages [red]Harv error: link from CITEREF_temp_preview_id_251770 doesn't point to any citation.[/red]; messages may be hidden (help)."

I get new tiny folding arrows next to "Pages included in this section:", "Parser profiling data (help): ", and the other options that appear when I am in source edit mode on en.WP. They need to be larger. They changed about two weeks ago.

This ticket appears to have been closed in error as a duplicate. See https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&curid=3252662&diff=1362194586&oldid=1362152419#Links_not_changing_colour for a description of the problem, including links to pages that do not have underscores in their wikilinks and are not linking to other wikis.

https://en.wikipedia.org/wiki/Wikipedia:Manual_of_Style#SECTIONCOMMENT has documented this problem for a long time. Some syntax simply does not work and must be fixed when it is encountered.

This may be related to T422291 or T387520.

This is a show-stopper for Parsoid deployment, at least on en.WP. Clicking [edit] for a section of a template documentation page (the green section of a template page) results in an error message. A simple example:

cdxIconPower: the vertical line needs to extend above the circumference of the circle, per the ISO standard. See https://en.wikipedia.org/wiki/Power_symbol

A better fix would probably have been to display the globe logo that somehow went missing during the conversion to the 25th branding.

In T426452#11957798, @Ponor wrote:

This change has broken instant preview and regular preview. Go edit https://en.wikipedia.org/wiki/Template:Traffic_volume_top in code editor. The table has class=floatright, but the class is unknown to the browser and the table is shown on the left.
Edit https://en.wikipedia.org/w/index.php?title=Mississippi_Highway_69&action=edit&section=1, changing
{{tv-t|name=Mississippi Highway 69|align=left}}
to
{{tv-t|name=Mississippi Highway 69|align=right}}
No effect, both previews are broken.

The example code has an error in it. Erroneous output, as shown in both examples, is to be expected when there is erroneous input.

In T200517#11819750, @SyntaxTerror wrote:

@ihurbain The only thing I want to know is why is this lint error detected, and what is it useful for?

@Izno talked about a discussion on enwiki without giving a link to it, and he says that he wants to fix duplicate IDs, but we don't know what for.
I would like to know if detecting this supposed error really helped him and what for.

It is always possible to detect something, but why doing so if it is useless ?

Anyway, having to look into millions of pages cannot be the solution.

I don’t really care whether this error is detected or not, but I try to sort out issues whenever I can on frwiki, and all these false positives are probably masking a real problem.

Perhaps there aren’t any true positives because the problem hasn’t been properly identified, and there’s another way to solve it that doesn’t involve checking every ID on every page.

By the way, we have a whole project on frwiki ( Projet:Restauration des ancres brisées/Références Harvard) that involves correcting around 20,000 articles with Harvard ref not working.
These errors can be detected without that 8 million pages list.

This is still happening. Today I found it at https://en.wikipedia.org/wiki/User:Uhai/Pages_without_short_descriptions_by_view_count (two stripped span tags reported via LintHint, but nothing on Page Information). Expanding the code that LintHint identifies shows no Linter errors.

This bug has either not been fixed or has returned due to a regression. See T422021.

It looks like this bug was previously reported in T326898, which was closed without a patch being applied, apparently.

Here's one on Commons where LintHint shows no errors, the rendering is clearly broken, and Page information correctly shows the Linter errors:

Here's an opposite situation: LintHint reports no errors, either in Preview or on the rendered page, but Page information appear to correctly show a stripped /th tag:

In T170874#11730076, @ABreault-WMF wrote:

In T170874#11700304, @ABreault-WMF wrote:

In T170874#11609358, @Jonesey95 wrote:

I'm looking at https://www.mediawiki.org/wiki/Special:LintTemplateErrors/missing-end-tag which is populated. How do I get from "36. Template:Cquote (1)" to the list of affected pages? The template itself has no Linter errors, according to "Page information", so one of the 83 transclusions presumably has an error in it. But which one?

Right, I put up a patch for that in T170874#11700296

Here's the newly deployed report
https://www.mediawiki.org/w/index.php?title=Special:LintTemplateErrors/missing-end-tag&template=Template%3ACquote

which shows
https://www.mediawiki.org/w/index.php?title=Talk:Specs/HTML/2.8.0/Extensions/Cite/Announcement&action=edit&lintid=1940684

You can get to that on https://www.mediawiki.org/wiki/Special:LintTemplateErrors/missing-end-tag by clicking on the pages link (1, pages) of the list item

Here's an incorrect finding of a "Link in Link" error by LintHint (checking the API):

I have made a simplified example here:

Note that if you go to the File page and click on the image, it is sharp and looks normal. The problem happens when the image is rendered as part of a page.

Another example: At https://en.wikipedia.org/wiki/User_talk:Samuel_Blanning/February2006 LintHint shows an "empty heading" Linter error but Page information does not.

In T419596#11700686, @Bhsd wrote:

In T419596#11700628, @Jonesey95 wrote:

Have you actually tried that beta feature for fixing Linter errors? It has many problems that I identified with just a few clicks, making it essentially unusable for that purpose, at least for me.

Of course I use it all the time. You should really try the linting feature and will see a status bar at the bottom of the editor. You can easily scroll to the next issue by clicking on the error/warning icons or pressing F8. There is no need to use lintHint any more with CodeMirror.

We have already submitted patches for all the issues you mention (T407203 and T418329).

We are all volunteers. Please be more polite.

In T419596#11698377, @Bhsd wrote:

One workaround is to enable the improved syntax highlighting beta feature (CodeMirror 6) and enable the linting feature in CodeMirror preference dialog. It reports Parsoid lint errors consistent with the page information in my tests.

Here's example output for one of the images that Linter thinks has a misnested s tag:

In T403931#11304858, @ABreault-WMF wrote:

Post-deploy, Parsoid now renders the intended output, the legacy parser does not,
https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1310145580&useparsoid=0
https://en.wikipedia.org/w/index.php?title=User:Jonesey95/sandbox&oldid=1310145580&useparsoid=1

Also, the output https://om.wikipedia.org/wiki/Template%3AWikipediaTOC?useparsoid=1 is fixed

The new wording is much better, thank you.

In T170874#11592636, @Ladsgroup wrote:

For tech news:

There is a new special page listing templates that trigger the largest number of lint errors. For example: [[Special:LintTemplateErrors/night-mode-unaware-background-color]]

Edit mercilessly.

In T170874#11592789, @ssastry wrote:

It is worth noting on help pages (or on the special page listing itself) that the reason some template might repeatedly show up is not because of the template source but because of the args passed into the template. Even in those cases, it is is still an useful signal to focus on its uses on article pages.

Still happening:

Further details on Anomalocaris's post:

Removal of sorting is a misfeature. Sorting by expiry, labels, and other columns is useful. Please add/restore it.

I need to be able to show my whole watchlist on one page so that I can use my browser's Find command. Is there a secret switch for power users to go above 1,000 items per page? Please add an "All" option, or at least a "5,000" option, which is the secret limit on most other pages that list things (e.g. What links here, Contributions)

In T412630#11553654, @Ladsgroup wrote:

In T412630#11553524, @Jonesey95 wrote:

I would also support removal or refinement of the dark mode Linter issue, since it has so many false positives. If it can be refined to highlight only issues that actually cause problems in dark mode, I think the table would be a lot smaller.

It would be great if you share some examples of false positives to help the dev teams on refining the rule. I'd appreciate it.

Sure. Here's one at random from the first page of results: https://en.wikipedia.org/wiki/Template:Footer_Pan_Pacific_Champions_100m_Breaststroke_Men

It would be great if everyone could stop referring to these Linter issue lists and tables using the word "category", since that word has a specific technical meaning on Wikipedia. Linter does not cause any sort of categorization.

It looks like a patch is being added to exclude the Template namespace due to the parser interpreting plain-text values like {{{1}}} as template parameter code.

I was not sent a link to the commit. I had written an e-mail to noc@wikimedia.org, the address shown in the error message. I had no expectation that I would get anything useful in return, but my problem was acknowledged and fixed right away.

I corresponded with the e-mail address listed on the error page, and I received a response from Giuseppe Lavagetto that this was a bug. It was fixed immediately, on 12 January 2026. If this issue can no longer be reproduced, it may have been fixed at that time. I would tag Giuseppe but I do not know their username here. Possibly @Joe

I corresponded with the e-mail address listed on the error page, and I received a response from Giuseppe Lavagetto that this was a bug. It was fixed immediately, on 12 January 2026. If this issue can no longer be reproduced, it may have been fixed at that time. I would tag Giuseppe but I do not know their username here. Possibly @Joe

This bug is still happening and causing Linter errors. See https://en.wikipedia.org/w/index.php?title=Wikipedia_talk%3AWikiProject_Football&diff=1332222385&oldid=1332221864 (10 January 2026).

In T315893#11530676, @Novem_Linguae wrote:

Would recommend reverting to no space everywhere. 1) It was fine that way for many decades. 2) Adding a space in some places (displayed page title) and not others (mw.config.get('wgPageName')) introduces unnecessary complexity / inconsistencies / technical debt. It's likely to result in people writing it both the old way and the new way forever, which is confusing. Right now everyone writes it (e.g. creating wikilinks on talk pages, creating wikilinks in projectspace, etc.) without a space and this is simple and elegant and consistent.

Now that this feature is halfway rolled out and the sky has not fallen, it's time to finish the job and make this spacing consistent. As it stands right now, the spacing is different from page to page, and from page view to page view, with no apparent logic. The spacing should be added to every page view where a page title with a colon is shown.

Here's a permalink to the discussion.

See the recent merged bug for examples of this problem affecting templates that contain manual line breaks. The bug causes Linter errors.

This can be closed. This need is met by commonly used template code like this that deprecates parameters bar and bar2:

As many Wikipedias come closer to fixing the remaining existing Linter errors (some, like de.WP, are already done), it becomes increasingly disruptive when new ones are added, especially at scale. This issue still needs attention. The wikitext of this mass message was apparently in a page, and so the Linter check was not run, causing three Linter errors to be delivered to 179 pages on en.WP. Here's the message diff:

Still happening.