If you want to report a JavaScript error, please follow this guideline. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for five days.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
I've enabled the gadget that pops up a micro-summary of an article whenever I mouse over a link to it. Unfortunately, it's not working properly with redirects. For example, if visit Serial comma#Mainly British style guides opposing typical use, I'm given the following text: I dedicate this book to my parents, Martin Amis, and JK Rowling. If I mouse over the first link, I get a picture of Amis and this text:
Sir Martin Louis Amis (25 August 1949 – 19 May 2023) was an English novelist, essayist, memoirist, screenwriter and critic. He is best known for his novels Money (1984) and London Fields (1989). He received the James Tait Black Memorial Prize for his memoir Experience and was twice listed for the Booker Prize (shortlisted in 1991 for Time's Arrow and longlisted in 2003 for Yellow Dog).
However, if I mouse over the second link, I get this text:
JK Rowling ⋅ actions ⋅ popups Redirects to J. K. Rowling ⋅ actions
Is there a way to change this, so that the popup shows the target of the redirect (as if the link went to the target), rather than the redirect itself? I can't imagine a reason why we should care whether it's an article or a redirect. The documentation suggests that identifying pages as redirects helps people fix them, but You probably don't want to "fix" such links every time you come across them, and WP:NOTBROKEN actively prohibits changing those redirects without some alternate reason, e.g. it's fine to replace "JK Rowling" with "J. K. Rowling" if we want the full stops and space to appear in the article, but not good to edit the article just to change [[JK Rowling]] to [[J. K. Rowling|JK Rowling]]. If there are any legitimate uses for distinguishing redirects from articles with this tool, that's different, but as far as I can see, it merely gets in the way of using this tool. Nyttend (talk) 22:12, 19 January 2025 (UTC)[reply]
@Nyttend: The first time I hover over a redirect like JK Rowling after loading or reloading a page, I see text from the target below the text you quoted. If I come back to hover over the same link, I only see what you quoted. PrimeHunter (talk) 23:58, 19 January 2025 (UTC)[reply]
Can confirm I'm seeing the same thing - on first mouseover it loads the redirect section, pauses a second or so, and loads the popup for the final target page below that. Subsequent mouseovers (including of the same link elsewhere on the page) just get the redirect section. I think in the past the behaviour was slightly different - it would always load the popup for the final target page below the redirect section - but I couldn't swear to that. Andrew Gray (talk) 20:48, 24 January 2025 (UTC)[reply]
Some table classes yet to be adapted for Dark Mode
I would like to get a list of urls to all class B articles. I know programming. But from what I could figure out up to now, it seems quite tedious to go to Category:B-Class_articles and do all subcategories in a recursive manner and change targets from talk pages to the actual articles. Is there any easier way to do it?
thanks for your response. I think I got a toolforge account. So I will try to quarry the database. The reason why I want to work with such a list is my mediawiki2latex program. I want to run it on all class B articles to try if a PDF is created in every case and fix the cases where it does not happen.
now PetScan works again. The results seem very similar to the one I got with the database query below. But good to know that the two methods of obtaining the solution generate roughly the same results. Dirk Hünniger (talk) 13:32, 25 January 2025 (UTC)[reply]
thanks a lot for you query 90084 example. I am not really used to SQL, but this was a nice opportunity for me to practice SQL. I came up with a modified version of your query, that seems to do what I need quarry:query/90125. I exported it to csv and built a set of the lines, which resulted in 151299 elements, which is the right order of magnitude.
For my purpose it is good enough, I just need a set of Wikipedia articles with not too short content, that I can use as test data for my mediawiki2latex program.
I am trying to retrieve multiple property values from wikidata (using Module:wd) in one call but it is ignoring the other properties I give so I only ever get one property value. I must not be giving things in the correct order but none of the Module examples help me. For example, given a mountain name, I want to retrieve the elevation, prominence, mountain range, coordinates and the first ascent significant event. I can get all the values if I code one call per property but how do I code it so I can get all the properties in one call?
So given this:
P2044 = elevation
P2660 = prominence
P4552 = mountain range
P625 = coordinates
P793 = significant event; Q1194369 = first ascent; P585 = point in time
how do I get all the property values in one call?
{{#invoke:wd|property|P2044|P2660|P4552|P625|property|qualifier|P793|Q1194369|P585|page=Mount Robson}} RedWolf (talk) 19:10, 22 January 2025 (UTC)[reply]
The documentation for the "property" command says "Returns the requested property – or list of properties". Yet, I see no example or syntax of how to specify this list of properties. RedWolf (talk) 22:35, 22 January 2025 (UTC)[reply]
Hi, near the bottom of Anglo-German Fellowship is the giant red error message "Lua error in Module:Navbox at line 604: attempt to concatenate field 'argHash' (a nil value)." Does this mean anything to anybody? And, more importantly, can anyone make it go away? Thank you, DuncanHill (talk) 19:40, 22 January 2025 (UTC)[reply]
"Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value). Lua error in Module:Navbox at line 535: attempt to get length of local 'arg' (a number value)." Is it WP:THURSDAY? Hawkeye7(discuss)20:08, 22 January 2025 (UTC)[reply]
Obviously this is beyond the scope of Wikipedia, but it seems to be impossible to find snapshots of new links that can be archived at the moment. It simply produces an error message such as "Fail with status: 498" or "We're sorry — something's gone wrong. Our team has been notified." This is a nuisance as archiving links via the Wayback Machine is important. Are other people having this problem? ♦IanMacM♦(talk to me)20:03, 22 January 2025 (UTC)[reply]
An editor has requested a change to the way we display categories in the Category: namespace. The existing system, which looks approximately like this:
This sort of sounds like it would be an overall general improvement - that is not something special for only the English Wikipedia, and for only users with their interface language in en. If so, this should be requested upstream. — xaosfluxTalk01:56, 23 January 2025 (UTC)[reply]
I think it'd be better to do this locally, where it's been requested. If it seems to be a net improvement, we could always suggest it for widespread use (which would require re-translation of the string for all 300+ languages – not something that can happen quickly). WhatamIdoing (talk) 03:44, 23 January 2025 (UTC)[reply]
+1 for doing it (it's an improvement), and +1 for doing it locally (no need to wait, and can easily undo the local change if and when upstream decides to do it). DMacks (talk) 19:55, 26 January 2025 (UTC)[reply]
Twice in the past three days, AnomieBOT has created the entirely unpopulated maintenance category Category:Articles lacking reliable references from 2025-01-19 from January 2025, which has in turn generated a nonsense redlink for Category:Monthly clean-up category (Articles lacking reliable references from 2025-01-19) counter — but since YYYY-MM-DD is not part of our naming format for either "Articles lacking reliable references" or "monthly clean-up category" maintenance categories, neither of these are categories that should ever exist at those names at all. But when I deleted the referencing category as both nonsense and empty earlier today in order to blow up the monthly clean-up redlink, the bot came along and recreated it again a few hours later even though it's still both nonsense and empty.
Could somebody look into this and figure out how to make it stop? I haven't deleted the category again this time, though I have wrapped the template in {{suppress categories}} since the redlinked parent still needed to go away regardless. Thanks. Bearcat (talk) 01:29, 23 January 2025 (UTC)[reply]
If that was the cause of this, then why was it not in the category I asked about, either time that it appeared at WantedCategories? I found that other category by perusing the edit history of an individual editor whom I was able to figure out had some connection to the issue after asking about this here, but it was never, ever filed inCategory:Articles lacking reliable references from 2025-01-19 from January 2025 at all, so how can it possibly have cascaded into the creation of a parent category it was never in? Bearcat (talk) 16:18, 24 January 2025 (UTC)[reply]
Did you check the link that I provided? If you do so, and go to the categories box at the very bottom, the first cat shown - a redlink - is Articles lacking reliable references from 2025-01-19. This means that the article was in that category, between 22:16, 19 January 2025 (UTC) (the time of the first of that pair of edits) and 01:51, 20 January 2025 (UTC), which is when this corrective bot edit was applied. --Redrose64 🌹 (talk) 00:35, 25 January 2025 (UTC)[reply]
Third level list item if there's a line separating this from the previous list item
^^ Why is this the default behavior for multiple asterisks? Does anybody ever actually want every asterisk to render as an additional dot? Why isn't *** by default just a twice indented bulletpoint, even if not immediately preceded by a once indented bulletpoint? This silliness is why many people wind up starting lines with e.g. :*:::: or :::::*, which if I recall correctly isn't ideal for accessibility. At minimum, given the ubiquity of unordered lists in wiki discussion pages, shouldn't indents be the default behavior (with perhaps some template for anyone with a weird multi-bullet use case)? — Rhododendritestalk \\ 03:46, 23 January 2025 (UTC)[reply]
Because any ‘lists’ with newlines between them are not actually one united list. See MOS:LISTBREAK. Sadly MediaWiki does not make this obvious enough, if anything, but both are bad for accessibility. Editors should be advised not to insert blank lines between list items, or at least to insert them as blank lines with indentation (*** <blank>), as that would generate a hidden empty list item that would unite the markup. stjn04:59, 23 January 2025 (UTC)[reply]
It becomes immediately obvious when using hashes to make an ordered list:
List item
Second level list item
Third level list item if there's a line separating this from the previous list item
Notice the lack of an item numbered 2. This is such a long-established feature of the MediaWiki software that it's unlikely to be changed. But you can use CSS to highlight the problematic markup. Here's a quick-and-dirty rule that draws a thick dashed red line in the gap of the first example above:
I actually have a user style called user:stjn/linter.css (in Russian Wikipedia) that highlights a bunch of accessibility/markup-related issues like this, including one mentioned here. I mostly advertised it on Discord, though. (Recently I’ve been thinking of turning it into a user script that can then provide more refined suggestions, since CSS can have too many false positives if you try to write, for example, a rule specifically for a list containing only another list.) — stjn00:33, 24 January 2025 (UTC)[reply]
Your style does something entirely different: instead of highlighting incorrect code, it just styles discussions a certain way. stjn16:15, 26 January 2025 (UTC)[reply]
Yes, that's what I said. As a side effect, it makes it easy for me to see problems in list nesting levels, but doesn't highlight them. isaacl (talk) 17:06, 26 January 2025 (UTC)[reply]
Hi, For PetScan, when launched, it shows
Error: This web service cannot be reached. Please contact a maintainer of this project.. Needed to run an hour ago and still fails. Will check again later today. Regards, JoeNMLC (talk) 14:32, 23 January 2025 (UTC)[reply]
It only accepts bug reports on github, where there is bug 187 open now. Github isn't really good for operational bugs, just software ones... This is another project with a lack of active onwiki volunteers unfortunately. — xaosfluxTalk15:31, 23 January 2025 (UTC)[reply]
@Xaosflux - Thank you for digging into this issue. PetScan really is a great tool for category filtering of articles. I regularly use to find Unreferenced + Orphan articles combination. For now, "Plan B" is to search thru just the old Unref. articles. Yes, it would be great to find an expert to: 1. Identify what is broken; 2. Fix it. There are some Bots that occasionally fail off & need to be restarted. Cheers, JoeNMLC (talk) 17:41, 23 January 2025 (UTC)[reply]
LDAP shows that Magnus Manske is the only maintainer. Since this is a very important tool, I think the Wikimedia Cloud team can help restart the web service if Magnus is not available. – DreamRimmer (talk) 18:04, 23 January 2025 (UTC)[reply]
As of now PetScan is running Okay, and seems to be faster. Hoping it continues processing requests. Will give it a few days before tag with "Done". Cheers! JoeNMLC (talk) 19:46, 24 January 2025 (UTC)[reply]
I don't get an interstitial when I click the action=edit or action=submit links above. Maybe I have a preference set that takes me to the edit window directly. – Jonesey95 (talk) 01:12, 24 January 2025 (UTC)[reply]
Not seeing it logged in, as I have have ever once answered that popup. Even logged out, once you answer it - subsequent loads will bypass it. — xaosfluxTalk10:21, 24 January 2025 (UTC)[reply]
Forgot what you call this. But every page on top has a little updated notice on how many views, etc. have been on that page. This is not browser specific, in my case. I have three browsers, and it's the same on all of them. Now I see a little left-hand dot moving back and trying to load the page stats. But it just keeps going back and forth with no results. — Maile (talk) 23:31, 23 January 2025 (UTC)[reply]
Whatever it's called, it is working perfectly now. To the left of it, is a little colored "Assessment" button. I just discovered that if I click on it, it takes me directly to XTools. — Maile (talk) 00:12, 24 January 2025 (UTC)[reply]
The assessment is working fine as not all XTools components are down. Without going through and checking individually, it's at least edit counter, page history, and authorship that are down. CNC (talk) 14:57, 24 January 2025 (UTC)[reply]
Rest assured, any downtime with XTools is relayed to maintainers automatically, and usually a flood of pings gets sent my way as well ;) I was traveling during this outage, but the Cloud Services team graciously came to my aid. All should be fine now.
The assessment is working fine as not all XTools components are down.
I think what happened here is the API server (which the gadget queries) was restarted successfully, while the main app server was stuck in a reboot loop. — MusikAnimaltalk08:46, 26 January 2025 (UTC)[reply]
By "semi" I mean I only have to click "log in" to get back in, not fill in my password or anything. But still annoying to have Vector2022 constantly flash onto my screen. This has been happening last three days or so, sometimes as often as every ten minutes. Cremastra (talk) 23:52, 23 January 2025 (UTC)[reply]
Please see "Page top edit counter down" above. I just noticed today that once again I cannot access my own XTools and keep getting "Wikimedia Cloud Services Error/ This web service cannot be reached. Please contact a maintainer of this project." Seems to me this is all related to some snafu at Wikimedia Cloud Services. — Maile (talk) 13:45, 24 January 2025 (UTC)[reply]
Agree with Cryptic - in case it's any help, I've just run a query across all of 2024 and after removing a couple of redirects for T (magazine), I make it 10676 views for all ~100 pages starting T:, combined - so about 30 hits per day among the whole lot. A quarter of those are T:TDYK. Andrew Gray (talk) 21:09, 24 January 2025 (UTC)[reply]
I'm experiencing an issue with the "dark mode" theme. When using this theme, certain elements, such as the binary tree in articles (e.g., ), become barely visible as they blend into the background. This makes it challenging to view the content clearly. The same issue occurs with any outlined transparent images.
Is there a way to fix this issue or improve the visibility of such elements in dark mode? A possible solution could be to add a white background to these elements, ensuring they remain visible when dark mode is enabled. Lunar Spectrum96 (talk) 23:07, 24 January 2025 (UTC)[reply]
@Lunar Spectrum96 For me, the SVG given appears fine. There's the screen's black background, and then the SVG's white one. I cam see the numbers fine. Could you perhaps provide a screenshot of how it looks to you? Cremastra (talk) 23:56, 24 January 2025 (UTC)[reply]
Cremastra, not your likely gadget dark mode, the one that comes native with Vector 22 and Minerva, where the image displays without a background, meaning the text is black on dark grey.
Suppose I come across some template like {{No Internet}}. Would it be fine to just replace [[User:{{ROOTPAGENAME}}|{{ROOTPAGENAME}}]] in its message parameter to {{#ifeq:{{NAMESPACE}}|Template|(Your name will automatically go here)|{{ROOTPAGENAME}}}} as in at {{Off and On WikiBreak}} so as to make "(Your name will automatically go here)" appear instead of template's name on the example at the template page? I am asking this as I don't have any experience in template editing at that level. Thanks, 𝓔xclusive𝓔ditorPing Me🔔20:08, 25 January 2025 (UTC)[reply]
[[People's Park (Berkeley)#May 15, 1969: "Bloody Thursday"|Bloody Thursday]]
However, turns out that the encoding that follows the section marker, #, isn't really encoding. It's exactly like % encoding, but with the percent signs switched to dots. This issue is fairly widespread, see [2] where I'm searching for the pattern .28[...].29, for a matching set of parens which would normally be encoded as %28[...]%29. I get about 8.5K hits, which includes some unrelated things, but that indicates the scale of the issue.
1) Does someone know the cause of such half-garbled links? Or can investigate to find it/have some insights? Most incidents I can find seem to have been added in the mid 2010s, e.g. [3]
2) Bot cleanup is likely needed on this. I haven't made a WP:BOTREQ yet, but bot/script coders and technical people might want to chime in on what might be involved for cleanup here. Even a better / more comprehensive regex search would be useful here. I've used round brackets for my search, but quotes (%22), ndash/mdashes, slashes/backslashes, and other %-encoded characters would likely be fruitful.
The cause is that that's what MediaWiki used to generate. It was an XHTML4 thing that the anchor targets were "officially" restricted to a subset of ASCII characters, so "percent encoding with % changed to ." was used to turn section titles into valid anchor targets. Once MediaWiki switched to HTML5, anchor targets could contain basically any UTF-8.I don't know that cleanup is really needed. The encoded targets are still also output so as to not break old links (as long as the target is still there at all). Unless MediaWiki devs have indicated that they plan to turn that off? Anomie⚔13:30, 26 January 2025 (UTC)[reply]
BTW, note that the dot-encoding isn't necessarily trivially reversible. For example, while == 0% == produce an XHTML4-style anchor of "0.25", so does == 0.25 == because the dot itself is not encoded. Anomie⚔14:13, 26 January 2025 (UTC)[reply]
That argument sounds very much WP:COSMETICBOT. Why should a bot go through these specifically, rather than letting people do it manually in cases like that article (or bots do it as general fixes along with a more substantive edit) as we do for other cosmetic things? While someone could argue that the changed fragment in the rendered link is (barely) non-cosmetic under the first bullet, since readers do see the fragment if they follow the link, you're not making that argument. Anomie⚔14:32, 26 January 2025 (UTC)[reply]
I'm making the argument that this is extremelyeditor-hostile wikitext, and should be fixed to something sane, much like AWB already does for properly %-encoded links. Manual cleanup of this would be very, very tedious and error prone. Headbomb {t · c · p · b}14:45, 26 January 2025 (UTC)[reply]
@Anomie: There's no such thing as XHTML4. There's XHTML 1.0, and there's HTML 4.0, with considerable overlap between the two specs, but with one being more restrictive than the other in certain areas. Prior to HTML5, our servers produced XHTML 1.0 pages. The relevant parts of the specs are C.8. Fragment Identifiers in XHTML 1.0 and the ID token in HTML 4.0, from which it is clear that the restriction prohibiting the percent sign was not with the URL fragment, but what it pointed to in the served page. --Redrose64 🌹 (talk) 17:07, 26 January 2025 (UTC)[reply]
I would advise caution when changing these links automatically, as there are real section names out there that look just like this encoding – for example, IEEE 802.11#802.11-1997 (802.11 legacy) – and trying to "fix" them would break them. At minimum the bot would have the verify that the link still works after the change. Matma Rextalk14:04, 27 January 2025 (UTC)[reply]
Checking ref 15 in 1452/1453 mystery eruption I found that it was a bad link. I then checked it in the wayback machine and found that although the most recent copy on 2 April 2022 is also a bad link, there is a good copy dated 22 February 2003 at [4]. I ran the article through Analyse a page and it archived the recent bad copy, so the ref now has both the original and archived copies bad. Is this a weakness in 'Analyse a copy' and is there any way round it? Dudley Miles (talk) 14:15, 26 January 2025 (UTC)[reply]
My understanding is that it's a heuristic used to identify new comments, in order to avoid sending a notification when someone copy edits a comment, or moves a comment to a new location, for instance. isaacl (talk) 17:12, 26 January 2025 (UTC)[reply]
Yes, it's not a technical limitation but a deliberate feature. We don't want a lot of notifications when somebody makes manual archiving of a discussion or something like that. PrimeHunter (talk) 20:52, 26 January 2025 (UTC)[reply]
Hi, WP Technical Village Pump Team and happy belated New Year! I attempted to boldly move the Cartoon Network (British and Irish TV channel) page to Cartoon Network (United Kingdom and Ireland) on 24 January. I was expecting the software to deny it so I can instigate an RM for it, but strangely instead, it was granted and executed, only for the page to revert back to the prior title without any record on the page history except rather for the page history of my suggested title (see here and here for proof). Is something wrong with the bold-move mechanism of the software that's cusing this, as this is so new to me or because this is something I barely witness from the software's mechanisms? Intrisit (talk) 19:47, 26 January 2025 (UTC)[reply]
Basically IP address makes several questionable unsourced edits, but subsequent edits by another user were constructive and I don't want to undo them. SigillumVert (talk) 21:39, 26 January 2025 (UTC)[reply]
Yes, the MediaWiki servers should be re-parsing every page periodically, but they do not do so. See T132467, a long-standing feature request from 2016. (And the related T157670.) As far as I know, a cron job needs to be set up, but it has never been followed through on. I think Wbm1058 is still running a bot on the English Wikipedia to refresh stale pages, and that this query shows the current staleness of pages by date (the maximum appears to be 88 days right now). It is not great to be dependent on a bot for this critical maintenance, and 88 days of staleness is too much. It would be great to know that pages would never be more than X hours or days stale, with X being a small number. – Jonesey95 (talk) 15:07, 27 January 2025 (UTC)[reply]
Resolved
), become barely visible as they blend into the background. This makes it challenging to view the content clearly. The same issue occurs with any outlined transparent images.