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 5 days.
Get a sneak peak and help shape the Visual Editor user designs
Help us test the new design prototypes by participating in user sessions – sign up here to receive an invite. We're especially hoping to speak with people from underrepresented and diverse groups. If that's you, please consider signing up! No prior or extensive editing experience is required. User sessions will start May 14th.
We plan to bring this feature to Wikimedia wikis later this year. We’ll reach out to wikis for piloting in time for deployments. Creators and maintainers of reference-related tools and templates will be contacted beforehand as well.
If only you hadn't decided that VE's shortcomings meant you had to change from the straightforward syntax people had hammered out over years of discussion to a previously rejected option that tries to shove wikitext into a tag parameter. Anomie⚔12:41, 29 April 2025 (UTC)[reply]
I've commented there already, and you ignored me there too. I read your reasoning there as "VE has shortcomings and we don't want to fix it, so we're choosing a worse solution". Anomie⚔11:20, 30 April 2025 (UTC)[reply]
Sorry for leaving your comment [1] without a reply, I was on leave until this week [2]. Please note that WMDE Technical Wishes is a small team dedicated to improve certain MediaWiki features. We do not have the resources to take on VisualEditor, that's what the Wikimedia Foundation is doing. We were faced with the option to stop our work on sub-referencing indefinitely – despite having worked on it for years – or continue with a different approach. Based on community feedback from different projects we decided to do the latter. Johannes Richter (WMDE) (talk) 12:19, 30 April 2025 (UTC)[reply]
I can't speak for Anomie, but personally, I worry with a new feature like this that it will be deployed half-baked, as the Visual Editor and Vector 2022 and dark mode have been, and then the developers will move on to another project, even as volunteer editors dutifully report bugs in Phabricator. If the Wikimedia Foundation has a lot of resources and still lets the Visual Editor and Vector 2022 languish for years with unresolved bugs that make life difficult for editors who need to fix or work around problems, how is the WMDE going to address the inevitable bugs that are reported when editors get their hands on this new feature and start making a mess? – Jonesey95 (talk) 13:32, 30 April 2025 (UTC)[reply]
Will there be a way to make it as user-friendly as {{sfn}} (which creates nice and readable wikitext) by suitable wrapper templates? And how would something like {{sfnm}} work with sub-references? —Kusma (talk) 13:44, 30 April 2025 (UTC)[reply]
sfn and sfnm would need to be provided the parent's name in addition to their current information, and the general references would need to be moved into a <references> or equivalent (at a minimum). At which point it is a serious question whether even to continue using sfn on any specific page. There is no template-use-wide promotion from one system to the other without bot or script or manual effort. Izno (talk) 15:40, 30 April 2025 (UTC)[reply]
So there's no way to make an intelligent version of {{sfn}}? The "parent" of {{sfn|Foo|Bar|2019|pp=3–5}} should obviously be CITEREFFooBar2019, which would need to be put somewhere as reference but that should not be necessary to specify again. I don't quite understand how {{sfnm}} could be emulated, though.
I can't personally see how the new system would be generally superior to use of our current sfn (but I can see that it would greatly improve the citation sections of German Wikipedia, where the use of citation templates is much less common than here). It will be just another citation style with its own set of advantages and disadvantages. —Kusma (talk) 16:43, 30 April 2025 (UTC)[reply]
There is no way to make an intelligent version of sfn that is guaranteed to work into the arbitrary future, even if it potentially works now, based on statements already made by the parsing team. And based on how strip markers work, I am pretty sure it would not be something that could be used today.
sfnm would need a new additional syntax, 1ap=Parent_Name or similar, just the same as sfn.
I can't personally see how the new system would be generally superior to use of our current sfn There are two primary preferable factors.
It would not rely on templates, making it much more suitable for large pages. Eventually, we may even be able to remove the IDs that the cite modules output, benefiting the largest pages (WP:PEIS would be reduced).
It integrates well with the Cite display. References in the reference list will be listed in the context of their parent, rather than arbitrarily located. And also, there will be integration with reference popups, so that you can see both the child and parent reference at the same time.
I think the second factors are the pretty killer feature that doom sfn, but being able to decrease the output of our citation module would be another win. And would coincidentally fix the issue that a number of Wikipedians think is a non-issue with respect to ouptutting duplicate IDs on many pages. Izno (talk) 16:54, 30 April 2025 (UTC)[reply]
I haven't actually met WP:PEIS in articles yet, so I don't think it is a huge issue. And the code looks a bit messy so I am sure people will use suitable wrapper templates anyway. For the second point, the proposal replaces one arbitrary ordering (by the point where a specific reference including page number is first used in an article) by a different arbitrary ordering (by the point where a specific reference is first used, and these are then sorted by where the specific page number is first used). It is just a new and additional citation style. I don't think the features are "killer" enough to convince the people at FAC to make this the default in less than a decade or two. —Kusma (talk) 18:27, 30 April 2025 (UTC)[reply]
@Kusma I monitor this search, and there are usually half a dozen or so articles per day that exceed the limit and need to be fixed. I'd say that the majority of my edits these days are fixing WP:PEIS errors in mainspace. --Ahecht (TALK PAGE)19:08, 7 May 2025 (UTC)[reply]
@Kusma Sure, there are lots of longer pages where a majority of the post-expand include size is citation templates. In many of these cases this could be fixed by using {{#invoke:cite|web}} in place of {{cite web}} (the former has half the include size of the latter), but that's usually a last resort since it makes the source "ugly". Usually, if an article has so many citations that the citation templates are the problem (and we're often talking close to 1,000 citations), it's time to split the article anyway. --Ahecht (TALK PAGE)21:22, 7 May 2025 (UTC)[reply]
We will be enabling the new Charts extension on your wiki soon!
(Apologies for posting in English)
Hi all! We have good news to share regarding the ongoing problem with graphs and charts affecting all wikis that use them.
As you probably know, the old Graph extension was disabled in 2023 due to security reasons. We’ve worked in these two years to find a solution that could replace the old extension, and provide a safer and better solution to users who wanted to showcase graphs and charts in their articles. We therefore developed the Charts extension, which will be replacing the old Graph extension and potentially also the EasyTimeline extension.
After successfully deploying the extension on Italian, Swedish, and Hebrew Wikipedia, as well as on MediaWiki.org, as part of a pilot phase, we are now happy to announce that we are moving forward with the next phase of deployment, which will also include your wiki.
The deployment will happen in batches, and will start from May 6. Please, consult our page on MediaWiki.org to discover when the new Charts extension will be deployed on your wiki. You can also consult the documentation about the extension on MediaWiki.org.
If you have questions, need clarifications, or just want to express your opinion about it, please refer to the project’s talk page on Mediawiki.org, or ping me directly under this thread. If you encounter issues using Charts once it gets enabled on your wiki, please report it on the talk page or at Phabricator.
Except for the fact that it pushes the content down when it's within the length of the infobox. It's also way to high. 12.172.251.103 (talk) 11:47, 8 May 2025 (UTC)[reply]
I'm running on the assumption it's configurable enough to not take up the entire page width each use. CMD (talk) 11:50, 8 May 2025 (UTC)[reply]
Sannita (WMF) Does it support horizontal bars? During the outage, I tinkered with a stopgap replacement that is template-based, and uses horizontal bars. For example, on Talk- or other non-mainspace pages, horizontal bars would permit the use of timeline-based charts that grows vertically downward as the timeline period is longer, unlike wit vertical bars which get thinner and thinner until they are squished into lines or become merged if too long a period is specified, unless averaging is introduced, which loses some detail and may hide sudden peaks. Meanwhile, the entire chart can be collapsed so it takes almost no vertical space on the Talk page except for the header. I am thinking in particular of the old, {{pageviews}} template often used among the headers of Talk pages, and disabled during the outage. Is there an option for a horizontal chart in the new extension? For some examples of horizontal pageviews from the temporary {{Xreadership}} template implemented as a stopgap during the outage, see Talk:Houthis, Talk:Same-sex marriage, or Talk:Pokémon. Thanks, Mathglot (talk) 21:26, 10 May 2025 (UTC)[reply]
Issues with the search bar
Hello. For some reason, the mobile search bar seems to be having issues with some pages, where it refuses to show them as a partial title match. It seems completely random which pages are affected, but try typing Kirby and the Forgotten Land or Georgette Heyer into the search bar and you will see what I mean. This issue affects both desktop and mobile. The weirdest part is that not every page is affected, only some. If anybody knows what is causing this, please let me know. Thanks, QuicoleJR (talk) 17:12, 7 May 2025 (UTC)[reply]
“partial” ye more like completely inaccurate i get 2005 page search results when i look up 2025 2601:586:4600:58B0:D874:DC52:810D:1C3C (talk) 21:25, 7 May 2025 (UTC)[reply]
20711499 Big Daddy G: FOUND
23148143 List of Salyut expeditions: FOUND
63868331 Sinicia gens: MISSING
1517496 Blessed Sacrament Catholic Church (Ottawa): FOUND
61762773 Francesco d'Errico: MISSING
40368221 Dasht-e Ahmad: MISSING
1806748 Doumbi Fakoly: FOUND
57248169 Thomas Kavali: MISSING
14070558 Celtic academy: FOUND
63368386 Árpád Érsek: MISSING
27371437 Antliff: FOUND
10393060 Paul Masnick: FOUND
43161650 Squash at the 2014 Commonwealth Games – Women's doubles: MISSING
20474762 Ponca Reservation: FOUND
17987330 Qiu Fazu: FOUND
15262879 Diocese of Killala: FOUND
7246021 Star-Spangled Banner (flag): MISSING
30371379 Amasa Day House: FOUND
9930252 Iosif Chișinevschi: MISSING
2011429 Wafangdian: FOUND
4302235 Lillias Hamilton: MISSING
67844683 Tachidiidae: MISSING
57345495 Ceraticelus bulbosus: MISSING
40275632 Blacksburg Historic District: MISSING
40898555 Djiboutian art: MISSING
So, I recently found that a new user's talk page: User talk:Epic failure72 is caught in Mediawiki:Titleblacklist due to .*Epic fail.* in it, meaning that they won't be able to create pages in their own userspace and user talk space. I believe that the blacklisted title should also blacklist usernames automatically, or there should be a way to exempt users from titleblacklist within their own userspace. Thanks! —CX Zoom[he/him](let's talk • {C•X})12:05, 9 May 2025 (UTC)[reply]
Yes, just those in the title blacklist at Meta. Those that are in the local blacklist prevent page creation but do not prevent username creation. —CX Zoom[he/him](let's talk • {C•X})13:57, 9 May 2025 (UTC)[reply]
Since SUL, the local title blacklist can't block account creation, because someone could easily get around it by creating their account on Meta. The only other way for it to possibly work would be for all 800-some active projects' blacklists to apply, which would be challenging to check for every creation. Anomie⚔22:47, 9 May 2025 (UTC)[reply]
Is this a potential security risk?
Hello. I have thought of this hypothetical scenario:
A bad actor creates an account with the now available username Example Jr.
That bad actor, now able to edit User:Example Jr/script.js, places whatever code they wish to steal accounts, cause mass vandalism (if the script is widely used), etc.
Can this happen? Or do I not understand? I know that the page would be moved (because of the name change) but they could remove the redirect. loserhead (talk) 16:26, 9 May 2025 (UTC)[reply]
@Loserhead for WMF wikis at least, ordinary users should not be able to create new accounts with the now vacated username. A "bad actor" as described in step 4 would be a trusted user in one of the many Foundation wikis (holding the override-antispoof userright). – robertsky (talk) 16:41, 9 May 2025 (UTC)[reply]
Yes, it's valid JavaScript. But it's also recognized as a redirect by the software, as illustrated by the fact that you had to use {{-r}} to link directly to it. CSS pages work similarly with a specially marked @import, and Lua modules with return require. Anomie⚔22:51, 9 May 2025 (UTC)[reply]
Can the template list be closed by default in the editing window?
Note: Actually, it is just after the edit window, and is labeled "Templates used in this preview".
It is really annoying to have to scroll by a huge list of templates (especially in country list articles) before I can see changes, or see the full preview.
Mediawiki remembers whether the template list was collapsed or not from before. Most of the time though I don't pay attention because I am not on country list pages, and the template list is much shorter. And I may have looked for some template on that short list.
But then I happen to be working on a country list page, and have this problem. I would like some CSS to keep the template list closed by default regardless of my last use of it. --Timeshifter (talk) 17:58, 10 May 2025 (UTC)[reply]
Yeah, the keyboard shortcut isn't sticky. Fwiw, I don't think this is something you can do with CSS, but there might be a javascript solution. Afraid I'm not personally familiar enough with the editor to make any specific suggestions for that, tho. -- Avocado (talk) 18:59, 10 May 2025 (UTC)[reply]
The keyboard shortcut is not working for me at all on Firefox on Win 10 Pro.
It works for me in Firefox on Mac -- or at least, the "fold all"/"unfold all" ones do. You do have to click into the edit box first, which sometimes gets me. (And this is in the 2010 source editor, fwiw, with syntax highlighting enabled.) -- Avocado (talk) 23:19, 10 May 2025 (UTC)[reply]
I see the problem. We are talking about 2 different things. You are talking about within the edit window.
I am talking about the template dropdown list after the edit window labeled "Templates used in this preview". I added a note at the top of the thread. --Timeshifter (talk) 23:38, 10 May 2025 (UTC)[reply]
The "Templates used in this preview" list, and the other collapsible lists below the edit form, should remember their state. If you collapse it, then it should start off collapsed the next time you open the editor. Matma Rextalk00:07, 11 May 2025 (UTC)[reply]
Timeshifter knows that. They wrote I would like some CSS to keep the template list closed by default regardless of my last use of it., so what they want is for the collapse state to be forgotten, and re-initialised to collapsed. The related HTML is
which makes the triangles point to the right when the list is collapsed. Collapsing and uncollapsing are done by means of some JavaScript, which:
if the current state is collapsed: removes the mw-editfooter-toggler-collapsed and mw-collapsed classes, and also removes the display: none; declaration
if the current state is uncollapsed: restores the mw-editfooter-toggler-collapsed and mw-collapsed classes, and also restores the display: none; declaration
The presence or absence of the mw-editfooter-toggler-collapsed class determines whether the triangle points right or down.
The presence or absence of the display: none; declaration declaration determines whether the list is hidden or visible.
I can write a CSS rule (or two) which will make the list start off collapsed, but the collapsing would then be permanent; I think that JavaScript is required to then make it uncollapsed on click. --Redrose64 🌹 (talk) 10:42, 11 May 2025 (UTC)[reply]
If you can get it to always be collapsed when I load, reload, or save a page that would be great. But I want to be able to manually open the list. I'll use whatever works that I can add to my user CSS and user JS. --Timeshifter (talk) 18:18, 11 May 2025 (UTC)[reply]
Oh, sorry I misread that. You could do this in your user JS:
I'm running a bot on Toolforge, but suddenly I can't SSH into login.toolforge.org any longer. The issue persists even after generating a new key and registering it to my developer account.
The server accepts the key, but then immediately closes the connection. Has anyone else experienced this or know what might be going on? Dragoniez (talk)07:15, 10 May 2025 (UTC)[reply]
@Someonefighter don't worry about the language links in the future. New articles are usually picked up quite fast by bots and editors on wikidata side. If it is still an issue editing on wikidata for you, you might want to apply for WP:IPBE there. – robertsky (talk) 09:16, 10 May 2025 (UTC)[reply]
How can I use different colors in light theme and dark theme?
Some wikis support using different colors in light theme and dark theme. Is this feature currently supported in English Wikipedia, or not yet? Upset New Bird (talk) 12:00, 10 May 2025 (UTC)[reply]
@Isaacl, @Timeshifter: For example, I mean how to show the colors "white", "yellow", "purple", "red", "black" and "gray" in light mode as "black", "blue", "#80FF80", "cyan", "white", and "gray" in dark mode. Upset New Bird (talk) 00:07, 11 May 2025 (UTC)[reply]
There's no simple way to shift specific colours to different colours. The link I provided has a link to a page listing the standard set of colours, named by their role in the user interface design. You can redefine the corresponding custom CSS properties to different colour values, but you'll have to be comfortable with writing CSS to do that. isaacl (talk) 02:32, 11 May 2025 (UTC)[reply]
Thanks for making me aware of the light-dark() feature, first deployed by browsers in 2024. I'm not sure what your planned usage is, though. If you're using it in text you're writing, for example, then using light-dark() will ignore the user's light/dark mode Wikipedia setting in favour of the user's setting in the browser/OS. It also will only work with newer browsers. The page to which I linked explains how to write CSS rules that will follow the user's light/dark mode Wikipedia settings, including if they configure it to follow the browser/OS setting. isaacl (talk) 04:23, 11 May 2025 (UTC)[reply]
Clearly there's some subtleties in the dark mode implementation that I don't know about... The other issues I described remain. What is your intended usage? isaacl (talk) 08:41, 11 May 2025 (UTC)[reply]
The light-dark() function is quite new, it was added to CSS Color Module Level 5 with the 29 February 2024 revision. Since this doc is a W3C Working Draft, it should not be relied upon. To those sceptics who have told me in the past that W3C Working Drafts will eventually make it to W3C Recommendation, please note that the color-contrast() function, which was last described in the 28 April 2022 revision, has since been dropped. --Redrose64 🌹 (talk) 11:59, 11 May 2025 (UTC)[reply]
@Redrose64: It seems that English Wikipedia supports "light-dark()" function, but does not support "color-contrast()" function. This table shows different colors by the user's color mode (light or dark). [5]Upset New Bird (talk) 01:01, 12 May 2025 (UTC)[reply]
Support for light-dark() and color-contrast() is nothing to do with Wikipedia, it's entirely in your browser. If your browser doesn't support color-contrast(), that does not surprise me, as it was removed from the CSS Color Module Level 5 spec, which as I already mentioned, is a draft and subject to amendment. --Redrose64 🌹 (talk) 16:02, 12 May 2025 (UTC)[reply]
Are you referring to a specific table? For tables in general, I think it's better to just use colours from the standard set. The actual colours used in light and dark modes will be centrally maintained, and can be adjusted by skins. isaacl (talk) 14:30, 11 May 2025 (UTC)[reply]
I don't understand what is the current problem with tables in dark mode, or why any issues can't be handled by using the standard set of colours. isaacl (talk) 04:35, 12 May 2025 (UTC)[reply]
Note: The "light-dark()" feature is now available in all three major browser engines, and becomes Baseline Newly available as of 13th May 2024. See [6]. Upset New Bird (talk) 02:48, 12 May 2025 (UTC)[reply]
AIUI, light-dark is insufficient to support all display modes on Wikipedia. There is "light mode", "dark mode", and "OS mode" here. light-dark meaningfully supports only the last of the three. Izno (talk) 03:03, 12 May 2025 (UTC)[reply]
light-dark() reacts to the color-scheme property that is set by the dark mode toggle, so it should work also for "forced" light and dark mode. hgzh08:56, 12 May 2025 (UTC)[reply]
Trying to balance the party colours in this template I am creating
Hello, with the 2025 Australian Senate Election results currently being counted I am creating this template to create a new standard for Joint Tickets in the senates results. Currently they are raw modified tables in the results at the New South Wales and Victoria bits (look for the joint tickets involving HEART, People First and Libertarians), and on the pages there the 3 colours are balanced. I am trying to replicate this with the template to replace the need for modifying the table directly but it isn't working properly and I have no idea how to get the 3 colours to balance. The documentation provides an example from the NSW results of that election. Any tips or help on how I can get these colours to be balanced? Thanks in advance! Comfisofa (talk) 11:41, 11 May 2025 (UTC)[reply]
When I'm doing WP:DRAFTNOCAT/WP:USERNOCAT cleanup, because Category:Living people is massive (thus impossible to search manually) and collects new draft and user sandbox pages daily instead of once in a blue moon, I do an incategory search on it a few times a day instead of only dealing with it when the weekly reports run. I've noticed that for several weeks now that after getting a draft or user page out of the category there's been a lag before the page would actually drop out on refreshing the search — in the past a page would typically drop out close to instantly in some cases, and within 30 seconds to one minute in others, but for several weeks now it's taken more like 10 to 15 minutes before a page would drop.
Today, however, all of the draft/user pages that were in the category this morning still haven't dropped out more than two hours after being removed. So I wanted to ask, is there something wrong with incategory searching all of a sudden? Bearcat (talk) 15:39, 12 May 2025 (UTC)[reply]
Thanks for noticing, indeed the indexing pipeline got stuck today around 13:30 UTC and no updates were being processed. It failed very early in the bootup process which didn't trigger our typical alerts. New alerts have been added, and that system has been restarted and is now processing edits again. most of the pages in the example have cleared out, the rest of the backlog should finish soon.
As to the update latency, around 5 minutes is the expected minimum latency for edits to make it into search today. Somewhere between 5 and 8 is probably most typical. That was indeed on a 30s cycle previously, but the update pipeline had to change to include asynchronously generated information (such as article topic predictions) which pushed the minimum update time to around 5 minutes.
Thanks for figuring this out so quickly. No worries on the five to ten minute drop time — it is a minor hassle when I'm doing draft/user nocat cleanup, because I have no way to distinguish "page that just hasn't dropped yet" from "the creator added the categories back again one minute after I removed them" or "I actually missed a category the previous time" without checking the page a second or third time, but all things considered if that's the worst thing that happens to me all day it isn't that big a deal. So if there's a clear reason for it, it's a thing I can continue to live with — but obviously pages not dropping hours later was something weird, so thanks for resolving it. Bearcat (talk) 20:17, 12 May 2025 (UTC)[reply]
Viewing watchlist by date added?
I'm familiar with the Raw Watchlist view, but that's alphabetical. Is there any way to get a listing of all articles on one's own watchlist, ordered by date added? -- Avocado (talk) 21:35, 12 May 2025 (UTC)[reply]
Fixed and added a comment to help future editors understand why the template is written the way that I just did. —CX Zoom[he/him] (let's talk • {C•X}) 12:59, 12 May 2025 (UTC)
