Wikipedia talk:Linter

Archives

Archive 1 Archive 2 Archive 3 Archive 4 Archive 5

This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present.

I propose to use this thread to track individual questions about, and problems with, the new dark mode Linter tracking. Please report questions, problems, false positives, false negatives, and other issues here.

I'm seeing what looks like a false negative in {{infobox royalty}}. In this version of the sandbox, we have this formatting for |succession=: | headerstyle = background-color: #e4dcf6;line-height:normal;padding:0.2em 0.2em. I see a background-color defined without a corresponding color, which I think should cause a Linter error when the infobox is rendered. In this forced dark mode view of the testcases page, the value of |succession=, "Queen consort of England", shows as black text on a black background, which is an error. The testcases page reports no Linter errors.

I'm also getting a report that "from desktop, the above (name) text in black however, in mobile app it is white and does not match with the background color." On the mobile view, I'm seeing the "above" text (e.g. "King Ahab") as black text on a sort of purple background. On the dark mode mobile view of the testcases page, I'm seeing the "above" text (e.g. "King Ahab") in white on black. What could be causing the person reporting this problem to see something different? – Jonesey95 (talk) 18:00, 4 July 2024 (UTC)[reply]

Hmm odd 🤔. I am seeing this in Special:LintErrors here: https://phabricator.wikimedia.org/F56229922 so am not sure why the testcases page is not reporting an issue? Maybe worth a bug?

https://en.wikipedia.org/wiki/Special:LintErrors/night-mode-unaware-background-color?wpNamespaceRestrictions=0&titlecategorysearch=Alexander+the+Great&exactmatch=1&tag=all&template=all

The headerstyle needs to be updated to have "color:inherit;" to fix this issue.

Regarding apps, I chatted with a developer about that yesterday and it seems apps are doing a few things that need adjusting now web has dark mode. I wouldn't worry about that for now - but do feel free to get a bug on Phabricator tagged with #dark-mode and someone in apps can look into it. 🐸 Jdlrobson (talk) 02:34, 5 July 2024 (UTC)[reply]

Alexander the Great turned out to be an unlucky example. It transcluded about ten templates that all needed to be updated. The article itself, and Infobox royalty, did not need to be changed to remove the dark mode tracking lint from Alexander.

Re the header style above needing to be updated, that is the bug I am reporting. It needs to be updated, it results in invalid dark mode output, but it is not throwing a Linter error. It should. – Jonesey95 (talk) 04:37, 5 July 2024 (UTC)[reply]

DId you report this on Phabricator already? It looks like an issue with mediawiki-extensions-Linter. Jon (WMF) (talk) 18:54, 5 July 2024 (UTC)[reply]

I was being lazy or hoping someone would explain why I was wrong. T369394. – Jonesey95 (talk) 21:06, 5 July 2024 (UTC)[reply]

Unsure if related or not, but the timing is peculiar. Today has brought on a new batch of 300some pages (most transcluded) claiming fostered content errors, due to the inclusion of includeonly and noinclude tags around startings and closings of tables. This behavior is typically not a lint error and is commonly used in the cases of transclusions. Why they are claiming errors I do not know. Anyone know what occurred? This isn't the only time I've seen this issue popup for select pages, but it's always cleared up before I get bothered enough to ask about it. Many of the pages are linked to the noinclude of the {{Ranks and Insignia of Non NATO Air Forces/OR/Blank}} template's opening bracket/parameters, and that page (really most of these pages) haven't been edited in awhile, and were not problematic when the fostered content errors were finished off to a remaining 10 or so pages two weeks ago. Zinnober9 (talk) 19:22, 4 July 2024 (UTC)[reply]

I think there was a bug report in Phabricator for this, but I am unable to find it via a Phab search. Pages like Line 4 (Shanghai Metro) appear to be affected; I remember that page and its siblings being affected by a similar problem a while ago. Since I could not find a bug, I filed a new one. T369317. – Jonesey95 (talk) 20:08, 4 July 2024 (UTC)[reply]

This phabricator bug has been fixed, so listed "fostered content" errors are real now. In articles, check for invalid recent edits (e.g. unsourced, vandalism, gibberish, terrible formatting); reverting them is often the easiest way to fix the Linter error. – Jonesey95 (talk) 00:43, 27 July 2024 (UTC)[reply]

One of the upsides of the previous error was that I've came across quite a few pages that an editor had used multiple noinclude type tags around the same section. Gonnym (talk) 11:07, 28 July 2024 (UTC)[reply]

Please see Template:Did you know nominations/St. Anne's Church, Moxi, which was showing a dark mode error. The page has a div tag that assigns a light green background. I tried added "color:inherit", but that turned the text white or light gray in dark mode. I changed that to "color:black", which displays the page properly in dark mode. The problem is that in both light and dark mode, the {{DYK tools}} box header shows black text; in the dark mode, that black text is on a black background. The page shows no Linter errors, but there is a display error. The DYK tools box header was also showing black-on-black in dark mode before I fixed the surrounding div tag. When I put {{DYK tools}} by itself in my sandbox, it shows the box header in white text on a black background. – Jonesey95 (talk) 20:32, 4 July 2024 (UTC)[reply]

I think this edit has fixed that. -- WOSlinker (talk) 21:33, 4 July 2024 (UTC)[reply]

Could really do with a full list of all those css variables and what the color values they are for both dark and light modes. Anyone know where these are? -- WOSlinker (talk) 21:35, 4 July 2024 (UTC)[reply]

What the heck is color: var(--color-base);? I don't see that anywhere on the Help page for this tracking category. Jdlrobson, do you know anyone who could improve the help page to add this useful tidbit and explain when to use it? So far, I'm limited to trial and error with color:inherit and color:black, which is not very sophisticated. – Jonesey95 (talk) 04:40, 5 July 2024 (UTC)[reply]

I've found a few of those CSS variables and have listed them at User:WOSlinker/CSSvars. -- WOSlinker (talk) 07:32, 5 July 2024 (UTC)[reply]

I updated https://www.mediawiki.org/wiki/Help:Lint_errors/night-mode-unaware-background-color#Quick_start. Hopefully that's the improvement you needed? Jon (WMF) (talk) 19:49, 5 July 2024 (UTC)[reply]

@Anomalocaris and Bruce1ee: There is a false result, which I have reverted here. The {{limited access}} symbol needs to go next to the URL link that has limited access, in this case the link to the Internet Archive item within the {{Internet Archive}} template. This is the case with {{cite web}} when the |url-access=registration parameter is used. However, by "fixing the lint error", the {{limited access}} template is instead placed outside to the right of the {{Internet Archive}} template, which results in the symbol being place next to the Internet Archive wikilink.

This is clearly fixing a problem that does not exist. How can we bypass this? Peaceray (talk) 23:35, 6 July 2024 (UTC)[reply]

Placing {{Limited access}} in the name parameter in {{Internet Archive}} appends File:Lock-gray-alt-2.svg to the name, which generates an internal link inside an external link lint error:

[https://archive.org/details/historyofancient0000unse_y5s7 History of Ancient Egypt [[File:Lock-gray-alt-2.svg]] ] at the [[Internet Archive]]

The problem is that {{Internet Archive}} does not have a |url-access parameter, and because moving {{Limited access}} outside {{Internet Archive}} is not producing the desired result, the only solution I can see is to use {{cite book}} instead. —Bruce1ee^talk 00:33, 7 July 2024 (UTC)[reply]

Seconding {{cite book}}. Lint issues aside, it looks cleaner and doesn't have the rather clumsy arrow+indicator combo obscuring the indicator:

EDIT: The original comparison containing a lint error can be seen here. Gamapamani (talk) 04:14, 7 July 2024 (UTC)[reply]

I used {{cite book}}; sorry if I included too many details and I also omitted |via=Internet Archive, feel free to fix. —Anomalocaris (talk) 04:58, 7 July 2024 (UTC)[reply]

Update: a |url-access parameter has been added to {{Internet Archive}}. (@Peaceray: FYI). —Bruce1ee^talk 07:02, 15 July 2024 (UTC)[reply]

Thanks! Peaceray (talk) 15:07, 15 July 2024 (UTC)[reply]

Really wish that "template is up for Merge/delete/some action requiring discussion" messages didn't trigger Lint when displaying along each use of the template. The sudden, large increase in some sections and namespaces tonight are due to this and almost certainly won't need individual addressing. At least they only last a week (or until discussion closed). Zinnober9 (talk) 02:57, 7 July 2024 (UTC)[reply]

I seem to recall that this can be fixed by moving the merge/delete tag in the template, but I don't remember what it was. Pinging Jonesey95. —Bruce1ee^talk 08:27, 7 July 2024 (UTC)[reply]

I've done this edit which I think has fixed it. -- WOSlinker (talk) 10:40, 7 July 2024 (UTC)[reply]

Thanks, that should help. —Bruce1ee^talk 11:23, 7 July 2024 (UTC)[reply]

Hi, my user page was recently edited for Lint errors. I was fine with the edit, but on reading the editor's talk page I found many complaints from other editors about unwarranted interference with their user pages, both home and talk pages. I started wondering whether user pages were somehow special or sacrosanct, and started a thread at WP:HD#Etiquette for user home pages/sandboxen. Looking more closely at the main page in the 'How you can help' section, there is guidance about editing User Talk pages, but there is nothing on User Pages (home pages) at all. Should this be remedied?

WP:TALK states that "It is not necessary to bring talk pages to publishing standards, so there is no need to copy edit others' posts. Doing so can be irritating. The basic rule, with exceptions outlined below, is to not edit or delete others' posts without their permission." Furthermore, WP:UOWN states that "Bots and other users may edit pages in your user space or leave messages for you, though by convention others will not usually edit your user page itself, other than (rarely) to address significant concerns or place project-related tags."

I was wondering how the above statements sit with the general advice to Linter-Gnomes on user pages? Should they perhaps be discouraged from making edits on such pages, especially unannounced and unexplained? Cheers, >MinorProphet (talk) 11:19, 17 July 2024 (UTC)[reply]

No one owns any page on Wikipedia, not even your own user page. This isn't your web page, "home page", or social network page. Errors, however small and insignificant it might seem to you, can and should be fixed. Ideally, you should be fixing them, but as history shows, most of the users who introduce errors, don't care to fix them. Zinnober9 was correct in both fixing your errors, how they've fixed them, and even left a good edit comment describing the issue. If after all this you still have an issue, then that's one problem we can't fix. Gonnym (talk) 11:29, 17 July 2024 (UTC)[reply]

Thanks for your helpful and incisive comments, with which I tend to agree - you press 'Publish' at your peril. I am not taking sides, or complaining at all about anyone or anything. As I said I was fine with the edit, for which I thanked the editor. But others are not so happy, as you can see by the editor's talk page. I'm merely hoping to find out exactly where any consensus ("by convention") has been reached about user pages, about which many people feel quite strongly proprietorial. Maybe they shouldn't. Other guidelines about User and Talk pages include:
WP:USERTALKSTOP says: ""In general, one should avoid substantially editing another's user and user talk pages, except when it is likely edits are expected and/or will be helpful. If unsure, ask.""
WP:AVOIDABUSE says "Editing another editor's signed talk page comments is generally frowned upon, even if the edit merely corrects spelling or grammar."
WP:OWN#User pages states: "Usually others will not edit your primary user page, other than to address significant concerns (rarely); or to do routine housekeeping, such as handling project-related tags, disambiguating links to pages that have been moved, removing the page from categories meant for articles, replacing non-free content by linking to it, or removing obvious vandalism or BLP violations."" These latter seem very trivial tasks: but is everything else on user pages, e.g. in the Linter 'High Priority' list, deemed a "substantial edit"? I'm not criticizing, merely curious. Cheers, >MinorProphet (talk) 13:26, 17 July 2024 (UTC)[reply]

Fixing Linter errors fits in with "routine housekeeping". All pages are fair game for fixing errors, replacing deleted templates, adjusting wikitext to conform to MediaWiki code changes, and other maintenance that keeps Wikipedia pages rendering correctly. – Jonesey95 (talk) 13:37, 17 July 2024 (UTC)[reply]

Many thanks for a clear and concise answer which also clearly states Linter's admirable purpose. I haven't come across anything as clear is this. Does this statement (or similar) appear anywhere else, e.g. WP:Linter WP:User pages, WP:Etiquette, and the others I quoted? I think it could be more widely understood that the way a user page renders is important, and that all articles and pages on WP fall under that remit of "routine housekeeping": and that includes "your" user page, however proprietorial you may feel about it. Thanks again, >MinorProphet (talk) 16:08, 17 July 2024 (UTC)[reply]

Great discussion. You are correct that not everyone likes or is thrilled when their userspace is edited, and since I've been targeting some LINT error types that weren't as numerous and had the chance at being completely eliminated, that's meant editing mostly in userspaces to eliminate them since 72% of the remaining errors are in userspace/user talkspace. Getting some grumpy feedback just comes with this territory. Most of the time though, I've get no feedback/response at all, or I get the occasional positive thank you notification. People tend to comment more when bothered, so that's what mostly ends up on my talk page. I'm sorry if my talk page came across as a red flag due to this. I do hope you saw, however, that I responded to each and every grumpy comment about my delinting, and attempted to find neutral ground for a solution that made both parties happy.

As to discouraged from making edits on such pages, especially unannounced and unexplained, I've found it's easier to ask for forgiveness afterwards from a few people then to ask and explain the edits prior to making them for every user needing pages fixed, and I'm less likely to have my edits rejected after the fact than upfront. Also in my way of thinking, it bothers people less to go ahead and do it, take care of all known syntax errors in one edit, and be done with it all with no need for subsequent delinting or bother, than it is to ask and explain and then do the corrections, but there is no perfect way and each method has some advantages and disadvantages. One and done tends to mean fewer but bigger edits, where Errortype focused edits means smaller, clearer edits, but more subsequent edits/notifications for the remaining errortypes.

You are also correct that these issues we are fixing seem more minor, but we've also cleared up most of the more major and problematic errors in the last few years, and the remaining 3.19 million errors are mostly Misnested, Missing, Stripped, or Obsolete tags of lower, but still important, priorities. I'm still seeing pages where someone's signature is missing a closing tag and the color, font style, and/or size "leaks" onto everything that follows after it, creating some crazy and unreadable messes. I've also seen cases where people had issues with their table structuring and it mixed with other code/tables to form a distorted layout messes when read.

I do need to make clear that there is a clear and distinct line between fixing syntax errors, and correcting someone's grammar.

Fixing grammar is rarely needed, not permitted by lint or other policies, and ticks people off with no real net gain.

Correcting various syntax errors on the other hand, clears up any issues the page has of displaying content as intended and helps prevent any current issues from becoming major issues as HTML and various code improves or is updated. It also reduces the likelihood of people seeing and copying another's HTML error(s), since most people's code knowledge is "I saw this, it looked cool, so I copied it for my own use", which has caused a fair amount of replicated errors. Zinnober9 (talk) 17:04, 17 July 2024 (UTC)[reply]

@ Gonnym "most of the users who introduce errors, don't care to fix them" That, and many people don't know the errors exist, or can't figure out what's wrong or how to fix them. Thanks for replying while I was offline. Zinnober9 (talk) 17:07, 17 July 2024 (UTC)[reply]

I absolutely concur. MinorProphet (talk) 21:25, 17 July 2024 (UTC)[reply]

That's great Z9, many thanks for showing me your understanding of how it all works (or ought to). MinorProphet (talk) 21:25, 17 July 2024 (UTC)[reply]

This month I've finished off 975 of 978 (or so) Link in Link errors, and we have three remaining due to these errors being discussed in their conversations: User talk:Beatboy16, User talk:Cyberpower678/Archive 76, and Talk:NeuroQuantology. The first two @Anomalocaris has left comments on as errors to skip, and the third is a near identical conversation of the second's error between different users (no comment currently).

While I agree that we shouldn't refactor the conversations that occurred, I'm also not of the mind to keep errors indefinitely when possible. And I realize in some cases, we just won't be able to do both. I'd like to open up the discussion about the possibility of addressing these in some agreeable way to keep the intent while addressing the error, or if these should be left alone for a better solution.

My initial thoughts are for encircling the error line(s) of each the conversations in either nowiki or pre tags, and likely adding a reply to the conversation stating the adjustment and reasoning, explaining that the reader may copy the error statement and either preview or temporarily use in their sandbox/userspace to fully understand the error, but that there isn't a need to keep the error in an active state indefinitely.

Would this be a reasonable way of handling these three errors, or is this idea getting a little too aggressive/bold on the delinting? Zinnober9 (talk) 03:20, 22 July 2024 (UTC)[reply]

Also, an additional thanks to the user(s) who in the previous few months have dropped these Link in Link errors from 3124 in March to under 1k by July. The low number was very tempting and was a refreshingly quick set to deal with after some of the more involved errors I've dealt with the past year. Grateful to you all and your efforts! Zinnober9 (talk) 03:20, 22 July 2024 (UTC)[reply]

Fixing lint errors on talk pages where the errors are part of a discussion are always tricky to handle. I think Zinnober9's suggestion of suppressing the errors with nowiki or pre and adding a note that a sandbox should be used to see the effect of the errors, probably is the best solution. —Bruce1ee^talk 06:41, 22 July 2024 (UTC)[reply]

Zinnober9's proposal is fine with me. —Anomalocaris (talk) 07:07, 22 July 2024 (UTC)[reply]

You could also put in a section link to a previous version of the page. People can click the link if they want to see the error. – Jonesey95 (talk) 12:56, 22 July 2024 (UTC)[reply]

Ah, I like the addition of view previous version. I've gone ahead and made these deactivations with these comments. If there's any issue or objections found later, we can adjust accordingly. This error is no more. Thank you all! Zinnober9 (talk) 16:38, 22 July 2024 (UTC)[reply]

That fix can probably be done in the module missing end tag and in the help fostered content to finish those off. Gonnym (talk) 17:21, 22 July 2024 (UTC)[reply]

As of earlier today, the list of articles with lint errors, when constrained to >=2 errors per page, was empty! Special thanks to WOSlinker who I've seen help out here a lot the last few days/weeks. I've since removed that >=2 constraint, and we've got a big list of more work to do.

Next, something I'd like some help with: 2024 United States House of Representatives elections in California keeps reappearing at the top of the list, with 2-4 stripped tag errors. The page is so big that lintHint chokes on it, and I can't even edit the article with syntax highlighting enabled. Purging the page will sometimes cause the errors to disappear, but they'll eventually come back. I've made a copy of the page in my sandbox, but that one does not show any stripped tag errors in the page information. Can someone shine some light on this? Feel free to experiment in my sandbox if it helps. --rchard2scout (talk) 12:15, 23 July 2024 (UTC)[reply]

It seems as though becasuse the page is so large, sometimes there are script timeout errors, which can cause then lint errors due to failed scripts. -- WOSlinker (talk) 12:29, 23 July 2024 (UTC)[reply]

Yeah, big pages are really annoying in this regard. I'm curious if there's a logical way to fix it, either with longer timeouts (unlikely solution), or if creating some subpages of say "Districts 1-26" and "Districts 27-52" (or each District individually?), and calling them in would address it.

If the data (like the tables) were all already existing on other pages and currently copied, I'd suggest removing the copies here and calling in those tables from the other pages, but it doesn't appear that these pages are set up like that as I'm not seeing identical tables on the couple of districts I looked at. Zinnober9 (talk) 17:23, 23 July 2024 (UTC)[reply]

Probably a discussion to be had at that talk page, but splitting it (in half, in groups of tens, etc) is probably a good idea. Primefac (talk) 17:53, 23 July 2024 (UTC)[reply]

Why does the lintHint button only appear in previous versions of a page in the article namespace? Being able to check for lint errors in previous versions is useful for establishing which version introduced errors. The only way to check for errors in earlier versions of a page in other namespaces is the go into edit mode – then the lintHint button appears.

Am I missing something? This is my lintHint setup in my common.js page:

var myLintHints = { };
myLintHints.rooms = "*";
mw.hook( "lintHint.config" ).fire( myLintHints );
mw.loader.load( "https://en.wikipedia.org/w/index.php?title=User:PerfektesChaos/js/lintHint/r.js&action=raw&maxage=86400&ctype=text/javascript" );

Thanks —Bruce1ee^talk 07:00, 17 August 2024 (UTC)[reply]

Not sure I'm following. You aren't able to use LintHint on article space in article view? If so, that is strange. I'm able to see the LintHint button and scan pages in every namespace in both past and current versions, both in source edit view, and article view, and we appear to have the same setup on our common.js pages. The only thing I've found to block/hide LintHint is activating preview, which is a little annoying, but is manageable. Zinnober9 (talk) 01:25, 19 August 2024 (UTC)[reply]

I'm sorry, I didn't make myself very clear. I can see lintHint in both current and previous versions of pages in the article namespace. But I can only see lintHint in current versions of pages in the other namespaces (Project, Template, etc), not previous versions. —Bruce1ee^talk 06:46, 19 August 2024 (UTC)[reply]

Looking at User:PerfektesChaos/js/lintHint § Configuration by JavaScript, I'd assume you'd also need to specify myLintHints.oldid = true; for the button to show on older revisions. Why it's appearing in old versions of articles despite that not being specified I'm not sure. Aidan9382 _(talk) 07:03, 19 August 2024 (UTC)[reply]

@Aidan9382: Thank you, that fixed it. The strange thing is that I tried that last week, but it didn't make a difference. Not sure what I did wrong then. —Bruce1ee^talk 07:29, 19 August 2024 (UTC)[reply]

Jdlrobson, this is a case for the developers who have been waiting patiently for us to report possible Linter dark mode detection bugs. In this version of my sandbox, {{WikiProject France/sandbox}} is used. It outputs a piece of code that is flagged by the Linter as a dark mode issue:

<td class="assess import import-Unknown" style="background:#DCDCDC">[[:Category:Unknown-importance France articles|???]]</td>

(which renders the box to the left of "This article has not yet received a rating"). The td element has color:black assigned by the CSS class assess in Module:WikiProject banner/sandbox/styles.css. If you highlight that table cell with an element inspector in a web browser, you can see that the element has these properties:

 
element {
  background: #DCDCDC;
  border: 0.075em solid #DCDCDC;
}
.mw-parser-output .assess {
  font-weight: bold;
  text-align: center;
  white-space: nowrap;
  color: black;
}

Note that both color and background are assigned to the element. I believe that this tag should not register a Linter dark mode flag. Also note that the root module in question, Module:WikiProject banner, has 11 million transclusions, so getting it to be compatible with dark mode seems like it would be important to WMF. Let me know if I should file a Phabricator task. – Jonesey95 (talk) 20:55, 21 August 2024 (UTC)[reply]

A Linter detection fix of this type would presumably also help with pages like Wikipedia:Articles for deletion/Donald A. Yerxa, of which we have many, where some xfd-specific classes are defined along with an explicit background-color. If one of the classes could be changed, site-wide, to have a default background-color and color defined, that would probably fix many pages. WP:AFD currently has 544,940 subpages, and I'm guessing that a significant fraction of those pages have the same setup. – Jonesey95 (talk) 21:44, 22 August 2024 (UTC)[reply]

This can be a potential problem in templates which rely on usage alongside other templates e.g. Colbegin for example OR if the stylesheet/template are modified in isolation from each other (Separation of concerns).

The appropriate fix would be to move the inline styles here to the stylesheet and use a class e.g.

.import-Unknown.assess { background:#DCDCDC; }

in this case.

(Note: The linter doesn't have access to the CSS currently.) 🐸 Jdlrobson (talk) 15:11, 25 August 2024 (UTC)[reply]

So, just checking, if color and background are both in the stylesheet then it will not register as an error. They don't need to be in the same class or anything like that? — Martin (MSGJ · talk) 09:40, 6 September 2024 (UTC)[reply]

There are 60 User talk pages with links in links error generated by a nonexistent template in Wikidata weekly summary #643. I have started a discussion at Wikipedia talk:WikiProject Wikidata#Wikidata weekly summary #643. —Anomalocaris (talk) 20:05, 2 September 2024 (UTC)[reply]

Hold -- per Jonesey95's reply at the discussion you've linked. Jonesy95 and I discussed it a bit earlier, and we want them to fix it since they broke it. I fixed a similar link issue on the #641 mailer 2 weeks ago, and I would like it not to become a regular thing. Zinnober9 (talk) 21:54, 2 September 2024 (UTC)[reply]

This issue has been addressed today is seems. Not sure how/who, but the result's clean and logical. Nice. Zinnober9 (talk) 22:36, 7 September 2024 (UTC)[reply]

lintHint is failing with an error seconds after clicking the button, even on very short pages. It started yesterday. Is anyone else experiencing this? —Bruce1ee^talk 09:10, 6 September 2024 (UTC)[reply]

Bruce1ee, I am too. It seems to be an error on Parsoid's end. — Qwerfjkltalk 12:53, 6 September 2024 (UTC)[reply]

Thank you, that helps. —Bruce1ee^talk 13:21, 6 September 2024 (UTC)[reply]

Working fine for me when used on Wikivoyage. Not here though. Zinnober9 (talk) 15:02, 6 September 2024 (UTC)[reply]

@Bruce1ee Yes, been getting HTTP 500 errors since yesterday as well. Special:ExpandTemplates works OK, though. Gamapamani (talk) 11:04, 7 September 2024 (UTC)[reply]

Thanks. I wonder why it still works in ExpandTemplates. —Bruce1ee^talk 12:21, 7 September 2024 (UTC)[reply]

Probably because it's not sending the source wikitext for analysis, but the expanded result.

I've experimented a bit, and this error seems to happen when you have any of the following on the page:

• {{SHORTDESC}}, which is used by {{Short description}}
• {{DEFAULTSORT}}
• {{Italic title}} or its Lua module, used by {{Infobox}} and it's derivatives (not all infoboxes)

There are probably more, but most wikitext appears to work OK when testing from the preview. Gamapamani (talk) 17:13, 7 September 2024 (UTC)[reply]