If you want to report a JavaScript error, please follow this how-to page. Questions about MediaWiki in general should be posted at the MediaWiki support desk. Discussions are automatically archived after remaining inactive for 5 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. An offline spellcheck of all articles is run by Wikipedia:Typo Team/moss; human volunteers are needed to resolve potential typos.
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.
For me, I noticed that for a while in mobile mode, none of the links turned purple at all. Additionally, as for desktop mode, for the past day or so, some pages, on both my laptop and phone, wouldn’t have links turn purple when clicked, but others did. This issue happened regardless of whether I was signed into my account. I tried clearing the cache on my laptop and I tried restarting, but it didn’t change anything. Illini11 (talk) 18:22, 1 July 2026 (UTC)[reply]
Always link to example pages. Give examples of specific links that have this problem. I just clicked on the blue talk page links in your signatures, and they turned from blue to purple, so it does not appear to affect all links. – Jonesey95 (talk) 20:39, 1 July 2026 (UTC)[reply]
Thanks for those links. The blue-to-purple change is working for me on those pages (Vector 2022, desktop mode, Firefox for Mac OS). Let us know your skin, desktop/mobile, and browser. That might help narrow down the cause of the problem. Also, does it happen if you log out? – Jonesey95 (talk) 01:21, 2 July 2026 (UTC)[reply]
Hi, we (content transform team) are trying to find what is causing the issue, or specific steps to reproduce it because from the bug report we couldn't end up with a strong case on what is the root cause. There are some unknowns like:
Parsoid read views rollout
currently main namespace in enwiki is rendered with parsoid but during the rollout there were a few days were users could end up with traffic that is mixed (some content using legacy, some content using parsoid)
It could be the case that after clicking the link the new page was using a different parser backend than the initial page causing the mismatch
Browser specific issue
People reporting issues mentioned that this is an apple specific, but I tried to reproduce the issue on the reported articles without success (iPhone, macOS).
What would be useful is for folks who encounter this behavior (link not showing up as visited after click) to restrict on their preferences their parser backend (eg. use only parsoid or use only legacy) and check if the issue is reproduced. Configuration is under Preferences -> Editing -> Developer tools -> Use the new wikitext parser.
It could be the case that this is issue is transient while we rollout parsoid as the default parser on en.wikipedia.org main namespace (which is now complete). JGiannelos (WMF) (talk) 16:14, 2 July 2026 (UTC)[reply]
I tried that as well and it worked for when logged in on both desktop and mobile, but @Jonesey95, I noticed the issue still persists when logged out. Is there a solution for that? Illini11 (talk) 19:42, 2 July 2026 (UTC)[reply]
When you are logged out, you are probably seeing pages rendered by the new Parsoid rendering engine, which appears to be necessary for this bug to manifest. Can you please go to Safari -> About Safari and report the version number that is shown there? That might help the developers to reproduce this bug. – Jonesey95 (talk) 19:50, 2 July 2026 (UTC)[reply]
I don't see why Parsoid should have anything to do with it. Your browser maintains a browsing history; this is, essentially, a table of all the URLs that you've visited within the last n days (n is usually configurable), or since you last cleared the history (some browsers also allow you to remove individual rows selectively). Visited links have a row in that table; unvisited links do not. If you've never clicked a link, there's no entry in the history table and so it's displayed in blue (or whatever colour is specified by the :link pseudo-class in the style sheet); upon clicking it, and returning to the page containing the link, it's now purple (the :visited pseudo-class), because it now has an entry in the browser's history. If a link has an entry in the table, and it's not in the :visited colour, something's seriously wrong. Does this mean that parsoid is somehow able to manipulate the browser's history table? --Redrose64 🌹 (talk) 20:20, 3 July 2026 (UTC)[reply]
Or else something in Parsoid's different DOM is somehow mismatching whatever CSS is supposed to apply the different coloring for :visited. I doubt the modern skins are leaving it up to the browser's default stylesheet. Anomie⚔23:29, 3 July 2026 (UTC)[reply]
There is a bug, when you open the wikitext editor that causes the images to be duplicated multiple times, obscuring all the text to be edited. - Alanscottwalker (talk) 11:06, 3 July 2026 (UTC)[reply]
Not that I'm aware of. If it's any benefit I switched WikEd off some time ago and haven't really missed it. The find and replace is the only bit I regret not having immediately to hand and even then it's easy enough to do via a browser extension. Nthep (talk) 13:00, 3 July 2026 (UTC)[reply]
FWIW, all 3 of the default editors have find and replace (with regex), e.g. phab:F91701205 screenshot showing the WikiEditor (2010), WikiEditor (2017), and VisualEditor. But I might be forgetting extra-aspects within WikEd's version, or significant bugs/limitations in the defaults. HTH. Quiddity (WMF) (talk) 18:12, 3 July 2026 (UTC)[reply]
Looks like I'm having this same bug with WikiEd, which I still use. It went away when I disabled WikiEd, but that was a major loss of functionality. Is WikiEd going to be fixed? And is this hitting all editors or just people with "Alan" at the start of their user name? Alansohn (talk) 13:01, 5 July 2026 (UTC)[reply]
I have fixed wikEd. That said, while I plan to continue to address very severe bugs as they come up on a best-effort basis wikEd has not really been maintained for years so beware. And, although I'm sure that was a joke question, the bug didn't care about your username and affects people not named Allen too. * Pppery *in solidarity16:04, 5 July 2026 (UTC)[reply]
@Hawkeye7: I don't know what you refer to. The three default editors mentioned by Quiddity (WMF) are maintained and bugs can be reported at phab: although minor bugs sometimes don't get much attention. PrimeHunter (talk) 00:33, 7 July 2026 (UTC)[reply]
It looks to me like that page is not being updated anymore, but if I search phabricator for tasks within the "VisualEditor" umbrella that were closed as "Resolved" in the last month, I find 33 tasks. So VE is definitely actively maintained. --rchard2scout (talk) 06:19, 7 July 2026 (UTC)[reply]
If I need to grab a citation from somewhere else, I can do that with normal cites. With SFNs, I can't even find what they're citing at all. Like I just had to dig for an amorphous "Newsome 2022", do you know how little search-engine optimization the words "Newsome 2022" have? Whose bloody idea were these abominations? Snokalok2 (talk) 15:50, 3 July 2026 (UTC)[reply]
Sfns are designed to be linked to a longform citation further down in the references. It's an extra click, but it should be possible to find. What article are you referring to? CMD (talk) 16:23, 3 July 2026 (UTC)[reply]
This is a forum for technical issues. I don't see a specific technical issue here. Every sfn has a corresponding full citation that can be copied to other articles. Except in the longest articles, it is typically not difficult to find the full citation using a unique string from a title or author name.
As for the assertion about searching, when I search for "Newsome 2022" (including the quote marks), I get a total of six articles in the results, and the text snippets make it clear that just two of them are the ones I am looking for. If I click on one of them, Persecution of transgender people in Nazi Germany, I can then do a Find for Newsome, then click on the "Newsome 2022" link, which takes me to "Newsome, William Jake (2022). Pink Triangle Legacies: Coming Out in the Shadow of the Holocaust. Cornell University Press. doi:10.1515/9781501765506. ISBN 9781501765506." Clicking edit on the section containing that full reference makes it easy to copy and paste the full reference. I'm not seeing any cancer here. – Jonesey95 (talk) 16:29, 3 July 2026 (UTC)[reply]
I'm also not a fan of SFN, for much the same reason @Snokalok2 is talking about. An alternative, sub-referencing, is working its way through the deployment cycle right now. I'm cautiously optimistic this will provide a superior alternative to both {{sfn}} and {{rp}}. I can't find the right phab ticket for the deployment schedule but my recollection is it will hit enwiki by the end of the summer.RoySmith(talk)14:40, 4 July 2026 (UTC)[reply]
Indeed, we haven't set a date yet, but deployment on English Wikipedia might happen end of August / beginning of September. We're rolling out in batches to make sure we have enough capacity to deal with potential issues and any other feedback from local wikis.
In a recent discussion on Discord some community members asked about deploying to enwiki earlier. We intend to start a discussion about this soon, we would be happy to have enwiki editors using the feature as early as possible to provide valuable feedback for further improvements to sub-referencing. We are still fixing some edge cases like phab:T415207, that's the why we wouldn't want to deploy to enwiki earlier without community approval. Johannes Richter (WMDE) (talk) 06:47, 5 July 2026 (UTC)[reply]
I'm cautiously optimistic this will provide a superior alternative to both {{sfn}} and {{rp}}. Ditto. I've used rp because I really dislike sfn as a reader, but rp itself isn't great either. Schazjmd(talk)15:17, 4 July 2026 (UTC)[reply]
My dream scenario would be that subrefs turns out to be as wonderful as it promises to be and both {{sfn}} and {{rp}} end up getting deprecated. Then everybody will move to using the same citation system. This will be better for editors who will no longer have to struggle with some citation system they're not used to just to make some minor update to an existing article. It will be better for readers because they will understand how to navigate every article they read. It will be better for tool writers who will be able to concentrate all their development efforts on a single standard, creating a rich ecosystem of easy-to-use interoperable tools and add-ons.
Of course, that's a pipe dream. Each standard will continue to have its own groupies who will insist that for the type of articles they write, their personal choice is the only one that could possibly work. Readers will continue to be confused and the tooling space will continue to be fragmented. RoySmith(talk)15:34, 4 July 2026 (UTC)[reply]
Just dropping to say, yes, sfn (and all the harv variants) is fucking awful. It's like someone sat down and asked themself "How can we make referencing as difficult and error-prone as possible for editors, and as obscure as possible for readers?" and then brain-washed a lot of otherwise very intelligent people into using it badly. DuncanHill (talk) 18:00, 4 July 2026 (UTC)[reply]
No and I remember one editor made a point of unilaterally going through and rewriting an entire large article in like one 200k edit, and in the process he changed everything to sfn - and when people tried to change back parts of it they didn't like his rewrite of or tried to implement new content, he just aggressively went Shortened footnotes must be used. There's no way around this; if you're not willing to implement them, they will be removed. and just started reverting everyone either without comment or with like Not sure how much clearer "USE SHORTENED FOOTNOTES" needs to be. and I'm sitting there thinking "Mate, what is your fucking problem?"
To go back to my "we need one standard" theme, for a long time part of my dislike of SFN has been that you can't just hover over a citation and click on the link to get to the linked URL. Various people have told me that I was wrong about that, and of course you can hover and click. It's only in the past couple of days that I finally started figuring out what's going on.
It turns out that the popup-on-hover behavior sometimes works and sometimes doesn't. See the two attached screenshots. Both on The Revolutionary Army Because of the way the screenshots were captured, you can't see the cursor, but in both cases I was hovering over the [3]. One got me the tooltip, the other didn't. What's different? I finally noticed that what's different is that in the one with the tooltip, the page is scrolled to a place where the reference in the reflist has scrolled off the bottom. If you scroll down a bit so more of the reflist is visible, the tooltip goes away. I suppose there is some logic in this, i.e. why show it to the user when it's already visible somewhere else, but damn does that violate Principle of least astonishment. Digging further, I starting thinking it might be due to some user script I'm using, so I started hunting in my common.js and didn't locate anything. Then I tried preferences/gadgets and found that I had Reference Tooltips checked. So I unchecked that and tried again, which resulted in some slightly different behavior, but still some flavor of tooltip, which confused me. And then I discovered there's also "Enable reference previews" which I also had checked, but was disabled because Reference Tooltips overrides it. And both of those interact with "Navigation popups" in some way that I have not yet been able to figure out.
So, we've got multiple citation styles, each of which gets affected by some combination of three different preference settings which all interact with each other. And all of that further affected by where my window happens to be scrolled to. It's all just way too complicated. I've been on wikipedia for 20 years and spent twice that amount of time writing software for a living. If I can't figure out what's going on, it's just way too complicated. RoySmith(talk)19:13, 4 July 2026 (UTC)[reply]
If you scroll down a bit so more of the reflist is visible, the tooltip goes away. I suppose there is some logic in this, i.e. why show it to the user when it's already visible somewhere else, but damn does that violate Principle of least astonishment. As the author of the latest rewrite of Reference Tooltips, I fully agree with you. I kept that only because it was the original behavior, and it wasn't 100% clear to me it's undesirable. Since then, it has become so. Jack who built the house (talk) 19:18, 5 July 2026 (UTC)[reply]
@RoySmith "Then everybody will move to using the same citation system". True, but millions of articles will still use the old system. I'm not against the new system, but any corrections to existing cites may require using the existing format.
I view the ability to mix citation styles as way of encouraging new users. If somebody has something useful to add to an article and we force them to learn some complicated citation system before being allowed to click the Save button, they'll probably just abandon the edit and we've driven away a new user. If we let them add an "incorrectly" formatted citation (perhaps copy-pasted from something like ProQuest which helpfully offers you a few common formats), they've done something useful and it's easy enough for somebody else to come along later and fix the formatting. RoySmith(talk)16:48, 6 July 2026 (UTC)[reply]
Of course some templates might show a template error if you tried using them in a sub-reference just with the page number (e.g. cite book requires the title parameter). But that can be solved by either changing templates or creating new ones, that's not a technical issue. Johannes Richter (WMDE) (talk) 22:33, 6 July 2026 (UTC)[reply]
What happens with
Main<refname=foo>Text of foo</ref> and subref<refdetails="{{cite book| title = bar
| id = baz
}}"/>
Perhaps I'm misunderstanding what you mean by backlink? I see a link under end note 1.1 that jumps back to the corresponding location in text. isaacl (talk) 17:04, 9 July 2026 (UTC)[reply]
Sorry, I'm so used to seeing multiple citations to the same reference that I was looking for ^a when I should have been looking for ^. Also, I should have checked the documentation for changes before my initial comment. Sorry for the confusion.
I'm really not a fan of all that ibid, loc cit, op cit stuff. It may make sense in academic literature where readers are expected to be sophisticated, but we're aiming for a lay audience who we should not expect to understand obscure latin abbreviations. RoySmith(talk)14:44, 10 July 2026 (UTC)[reply]
<ref name="Jones 1867 Poems">{{cite book |last=Jones |first=Amanda T. |author-link=Amanda T. Jones |title=Poems |url=https://archive.org/details/poemsjones00joneiala |location=New York |publisher=[[Hurd and Houghton]] |date=1867 |page=105 |via=[[Internet Archive]]}}</ref>
And these are the inline refs:
{{r|Jones 1867 Poems|p=105|q=PORTER JONES, 2D N. Y. M. R., DIED OCTOBER 14, 1864, AGED 18 YEARS.}}
{{r|Jones 1867 Poems|p=64-66|q=The Prophecy of the Dead, April 1861.}}
Sometimes one just needs to show page numbers. Many sources can be quite long, and finding a specific piece of information among even a few pages is a PITA. I tried on some of my earlier articles to subdivide ref by pagenumbers and it was a hassle to edit. sfn is better for this purpose. This sub-referencing looks fine-ish although I wonder if it takes up more bytes in the edit window. Jo-Jo Eumerus (talk) 08:17, 5 July 2026 (UTC)[reply]
Technically yes, since {{sfn|Miller|2005|p=23}} is 24 bytes while <refname="Miller2005"details="p. 23"/> is 40. On the other hand, I won't be terribly surprised if someone makes a template that's invoked like the former and works like the latter (e.g. like {{dref|Miller2005|p. 23}} or {{dref|Miller2005|p=23}}) if those few extra bytes are a problem.Then, too, there's the question of whether people use LDR or not for the work itself; if "or not" then the work-itself part will wind up inside <ref>...</ref> somewhere in the body of the article instead of being tucked away at the end. I threw together a quick example of the three approaches at testwiki:Special:Permalink/750148 in case that helps. Anomie⚔17:25, 5 July 2026 (UTC)[reply]
I suspect the non-LDR version will get some complaints from SFN fans, though, if people change articles to that style instead of the LDR version. Anomie⚔20:44, 5 July 2026 (UTC)[reply]
Yeah, that's nice, thanks. One thing I see is that if I wanted to find all the places that cite Miller, I can search for "[1." in my browser and keep doing Find Next. Doing that with SFN is way more work. RoySmith(talk)18:43, 5 July 2026 (UTC)[reply]
Au contraire. With sfn, you can search for "Miller" to find all the sfn's, which works both in the rendered page (two clicks per) and in the wikicode (one click). Not sure what you meant by "[1." as neither article nor wikicode contains that string, but if you meant something like "1.^ a b c d " on the rendered page, then yes, it's faster with ref's, provided they reuse the same named ref plus {{rp}} for citations to different pages, but by no means do all users do that (48k occs). If you meant the wikicode, then it's about the same speed once you've found the ref name in the code, easy if they call it Miller-yyyy, but the great majority of the time[slow link] they do not, and then finding the name of the named ref that you need to search for is annoying, and for four Miller cites, by the time you find it, you would have found all four sfn's already. Mathglot (talk) 22:35, 5 July 2026 (UTC)[reply]
I'm looking at the example @Anomie posted above, i.e. testwiki:Special:PermanentLink/750148. If I search for "Miller", I find "Miller 2005, p. 23." and " Miller 2005, p. 34" under Notes, but what I was really looking for was where they were used, i.e. "The Sun is pretty big,[1]" and "The Sun is also quite hot.[3]". In the sub-ref version, searching for "[1." takes me directly to those places in the text. RoySmith(talk)22:50, 5 July 2026 (UTC)[reply]
Ah, I see. Searching the rendered page for some subref string (here, "[1.") would be a significant improvement over searching the rendered page without subrefs is I think what you are saying, and I agree. It's also likely faster than searching for sfn's on the rendered page, where you need two clicks per "Miller" ref you want to locate, as opposed to just one per ref. But it's about the same as searching for Miller sfn's in the wikcode, which is also a Next-next-next browser operation, the difference being however long it takes to open the wikicode. But I take your point, and mobile users (the majority) especially are not going to mess with the wikicode.
On the flip side: it will likely be a long time before subrefs become widely used enough for this faster searchability to become available on more than a tiny proportion of articles. Even now, 19 years after it was created, {{rp}} (which I use and recommend) is present on < 1% of articles. Although I just love {{citec}}/harvc for citing multiple chapters of the same source, even more than I like rp, it is used in a pitifully small number of articles. Gazing into my crystal ball, and based on my SWAG, I reckon that subrefs have about the same order of complexity as citec/harvc, and will be adopted along a similar curve. I sincerely hope I am wrong, but great ideas don't always win. Mathglot (talk) 23:22, 5 July 2026 (UTC)[reply]
One of the problems with the plethora of ways to do citations is that a newbie has to pick one. And lacking any realistic way to evaluate all the options, they just end up picking one at random. I remember the first time I tried to figure this stuff out. I don't remember all the details, but I do remember slogging through some endless morass of help pages on citations trying to figure out which one to use. What I really needed was someplace that said "This is how it's done, end of story". RoySmith(talk)01:07, 6 July 2026 (UTC)[reply]
The interesting thing about parenthetical style was it actually served a very good purpose in its original environment. In scientific writing, there are often small communities of researchers who know each other's work well. When you see (Foobar 2023), you often don't even have to look at the reference listing to know what paper it is because you've already read it, cited it in your own work, perhaps reviewed it when it came out. None of which is true for our intended WP:AUDIENCE, i.e. the WP:READER. RoySmith(talk)12:47, 6 July 2026 (UTC)[reply]
I decided to give sub-refs an actual try now that it's installed someplace. I copied Big Duck (which uses {{rp}}) over to testwiki. To actually do the conversion, I then copied the wikitext over to my laptop and did a little emacs query-replace magic to normalize the wikitext. In some places I had {{rp}}, in other places {{Reference page}}, there was also a little variation in location=x vs page=x. Once I got that done, it was just a simple macro to find ":8" >/{{rp and shuffle things around a bit. The result is at testwiki:Big Duck.
The conversion process was easier than I expected, and it looks like it would be trivial to write some user javascript to automate the process (I imagine somebody has already done so). I must have messed something up along the way because I started out with 8 citations (a-h) and ended up with 7. I should probably go back and figure out what went wrong there, but whatever.
One issue I found is that the formatting of "p" vs "p." vs "pp." is embedded in the {{citexxx}} and {{rp}} macros now, and that needs to be hard-coded in the details parameter. That seems like a really minor thing (and something a conversion script could handle along the way) so I'm not worried about it. RoySmith(talk)16:41, 6 July 2026 (UTC)[reply]
German Wikipedia community members actually agreed to deprecate {{rp}} in favour of sub-referencing and proceeded to replace the template, using auto-replacement scripts like de:User:ⵓ/ARreplace (in combination with rules like de:User:ⵓ/common.js#L-110 ff.). If individual editors wanted to replace rp in articles they've created, they could probably re-use that script. Johannes Richter (WMDE) (talk) 22:47, 6 July 2026 (UTC)[reply]
Now that I've done a little experimenting, it seems like it would be perfectly safe to add all the details attributes now, yes? Before sub-refs are enabled, it should be totally ignored. And then on some future Thursday when sub-refs get deployed, all I need to do is delete all the {{rp}} templates and Bob's your uncle.
I'm thinking I'd like to be the first sub-ref article nominated at WP:FAC and it would be cool to do it on day zero. I was going to submit SoHo Weekly News soon, but I'd be happy to hold it up a couple of months to get my firsties. RoySmith(talk)23:04, 6 July 2026 (UTC)[reply]
Totally off the subject of this thread but since rp has been mentioned above, I'd like to vent some anti-rp feelings. Ugh. Sorry if there are fans here but I think that particular ref style is incredibly hard for readers to navigate and verify. Seriously. Lol might be hard for some of us editors to navigate too... - Shearonink (talk) 02:24, 7 July 2026 (UTC)[reply]
It's theoretically possible to already add details= (example [3]), those references are still shown as regular re-used references. But it leads to the reference error category being added to the page (I would have expected an error message as well, but I don't see one to my own surprise). Johannes Richter (WMDE) (talk) 06:23, 7 July 2026 (UTC)[reply]
I figured out the 7-vs-8 citation mystery. One of my citations did not have a details attribute, which it handled intelligently. There really are 8 citations; one to the main reference, 7 below it to specific page numbers. RoySmith(talk)12:30, 7 July 2026 (UTC)[reply]
As far as I can tell, sub-refs are not as good as sfn, and I cannot see myself using them. The sfn format allows for a compact bibliography and notes like you have in a book. Couldn't we just have the pop-ups show the book as well as the page? Hawkeye7(discuss)01:47, 7 July 2026 (UTC)[reply]
That's probably not a good line of argument. {{sfn}} has a |loc= parameter for arbitrary locations, and if people really want other details (without abusing that parameter) they could construct the short-form <ref> manually. The objection here seems to be that some people just really like the separate "References" and "Bibliography" format. Anomie⚔11:30, 7 July 2026 (UTC)[reply]
As far as I can tell, {{sfn}} and sub-refs contain exactly the same information. It would be really awesome if there was a single way this information was represented in the wikitext, with just a switch to say "Render this in SFN style" or "Render this is sub-ref style" (or potentially other styles). That way, authors who like the separate bibliography can have their articles done that way, and authors who like the sub-ref style can get that. But either way, the actual data is represented in a uniform way, so tool builders can have a single data format to code against. Everybody will benefit from having a richer tool set. RoySmith(talk)17:08, 7 July 2026 (UTC)[reply]
Even if that were doable, it would be a significant software development effort imho, providing no actual additional feature that did not exist before, but only different rendering. Which would have to work on different skins, and on the mobile app. The question would become one of priority (and resources): would you rather have WMF build that, or something on the m:Community Wishlist that delivered something new? Mathglot (talk) 23:03, 7 July 2026 (UTC)[reply]
By forcing editors to use a single "one true form of referencing", which seems to be what this section proposes, will annoy and upset other editors who use other systems, including short citation systems like sfn, just as much as these systems seem to annoy and upset the people who propose this scheme. Such a proposal is likely to drive many editors away. Is that the intention?Nigel Ish (talk) 20:30, 8 July 2026 (UTC)[reply]
The use of flags in the Venue/Event columns appears to be inconsistent with MOS:FLAGANDNAME and MOS:FLAGCRUFT. The flags do not have an accompanying country name, and the flags unduly emphasize the event's venue nation. It would be better to leave out the country altogether or to write "2023 PDC World Darts Championship" and have a separate column, if desired, for the venue (United Kingdom). – Jonesey95 (talk) 19:25, 3 July 2026 (UTC)[reply]
Flags need not be images. They might be pairs of Unicode characters, selected from the 'REGIONAL INDICATOR SYMBOL LETTER' range: 'A' (U+1F1E6) through 'Z' (U+1F1FF) inclusive. Pick the two letters that make a valid ISO 3166-1 alpha-2 country code and put them together, to make flags. Examples:
Most of these templates use Lua. I expect somebody could write something that does it all in Lua, using a two-character string variable to hold the value retrieved by {{ISO 3166 code|country name}} so that it doesn't need to be called twice. --Redrose64 🌹 (talk) 23:07, 6 July 2026 (UTC)[reply]
It could even be a new function within the existing Module:ISO 3166. That already has a code function to return "GB" etc.; a flagfunction could simply call code and replace each of its two letters by "&number;". Certes (talk) 13:29, 7 July 2026 (UTC)[reply]
@Redrose64 Not sure if it's a OS/Font issue, but on my Windows 11 machine in both Chrome and Edge, those "flags" just show up as the smallcaps letters "GB", "FR", and "DE". They work on my Android phone, but support is obviously not universal enough to be using that in articles. --Ahecht (TALK PAGE)17:23, 7 July 2026 (UTC)[reply]
This looks like a matter for Phabricator but I'd welcome advice from anyone who has insights or is already dealing with the issue. DisamAssist is a tool for fixing wikilinks to dabs, e.g. replacing [[Mercury]] by [[Mercury (planet)|Mercury]]. It displays a dab, modified by adding a link to each entry; clicking the added link selects that entry as the intended target. Those links appear with the legacy parser but do not appear with Parsoid, making the tool almost useless. Its author is no longer active. Previous discussion: User_talk:Qwertyytrewqqwerty/DisamAssist#Not_working_for_me. Certes (talk) 22:13, 4 July 2026 (UTC)[reply]
Parsoid changed how the URLs are rendered in page content HTML, which this script uses to figure out whether a link is a valid fix target. I fixed it in my fork but someone needs to fix it along those lines in the original version. I doubt the user in question would since they haven’t edited Spanish Wikipedia since 2018 (8 years now). I proposed adopting this script before so it gets more frequent updates but it didn’t get much attention or approval. (Happy to move that forward again however people would see fit, though. For instance, we could move it to a gadget in Russian Wikipedia so people don’t worry about my potential disappearance.) stjn15:30, 5 July 2026 (UTC)[reply]
I also have a personal fork of DisamAssist and would be happy to document and explain its enhancements. Thank you for the fix; I'll incorporate it into my own fork but obviously can't fix the master version. I also would like the script to be adopted in some way but don't plan to commit to maintaining it indefinitely myself. Certes (talk) 15:55, 5 July 2026 (UTC)[reply]
@Stjn: Please do you have a diff which just makes the changes for Parsoid, without the other enhancements? I'm sure they are all useful but I would find it much easier to understand if I can see which code changes implement each piece of new functionality. Certes (talk) 16:03, 5 July 2026 (UTC)[reply]
Entire diff is related to parsing new URLs better. But the most basic link parsing there comes from extractPageNameRaw function, so I guess you can copy that part to your fork. It should work fine independently. stjn16:25, 5 July 2026 (UTC)[reply]
FWIW, I looked at the changes in User:Certes/DisamAssist-core.js and some are either implemented in mine already (like proper redirect handling) or seem unnecessary ({{siadn}} redirects to {{dn}}, why handle them differently?). The only part I don’t have implemented is Make creation of Foo (disambiguation) redirect optional which is probably worthwhile to add (in Russian Wikipedia that part of the script is disabled so I don’t have a strong opinion on that either way). stjn16:45, 5 July 2026 (UTC)[reply]
Thank you! I've copied extractPageNameRaw from your version to mine. The links now appear for me and I've successfully disambiguated a wikilink as a test. It would still be great to get an adopted version so that this can work for everyone. Certes (talk) 17:26, 5 July 2026 (UTC)[reply]
@Certes There isn't a good way to usurp a userscript from an inactive user other that publishing your own version, notifying all current users of the old version that they might want to switch, and changing shortcuts such as WP:DisamAssist to point to your version. --Ahecht (TALK PAGE)17:40, 9 July 2026 (UTC)[reply]
Yes, we'd have to move the script elsewhere. I'm not proposing that it go in my userspace, as that potentially carries the same problems as we already have and I'm no expert in its programming language. Stjn's version is a better candidate to become the One True Version as it has several advantages over mine. The one feature I would add there is the ability to run on a non-dab page without creating a Foo (disambiguation) redirect to it. Certes (talk) 17:48, 9 July 2026 (UTC)[reply]
My version makes redirect creation optional because I've also removed the check that the page being "disambiguated" is actually a disambiguation page. I also find DisamAssist useful for other mislinked pages. For example, new links to Zunz are invariably intended for Leopold Zunz. Running DisamAssist on Zunz is a quick way of fixing them, but we don't want a Zunz (disambiguation) redierct. Certes (talk) 22:43, 5 July 2026 (UTC)[reply]
Category:Pages with DEFAULTSORT conflicts is a hidden category, but it is no longer shown in an article even when you've enabled the display of hidden categories. There used to be a red error message Warning: Default sort key "x" overrides earlier default sort key "y". Now, neither the warning nor the category is displayed in an article. They do still show up in other spaces, such as Draft:, Talk:, or User:. MANdARAX • XAЯAbИAM18:26, 5 July 2026 (UTC)[reply]
The named reference "$1" was defined multiple times with different content (see the help page).
as shown at CAT:DUPEREF. I resolved the duplicate definition in this edit, thus removing Eala from the category, but I still don't know why the multiple def wasn't flagged in the article. As a test, I defined ref name "Philstar" twice on purpose in this test revision, and as expected, it displays the H:CERDK error. Any ideas why earlier rev. 1362254545 of 20:04, 2 July 2026 did not complain about duplicate defs of name "WTA-AE"? User:Mathglot (talk) 22:10, 2 July 2026 (UTC)[reply]
Parsoid is the new way that wikicode gets turned into html (someone else will probably be able to give a better explanation). It will soon to used for all pages, but for the moment you can see if a page has been made using parsoid by searching for "Page was rendered with Parsoid." at the bottom of the page. All of your examples are using parsoid, so this appears to be another bug. -- LCU ActivelyDisinterested«@» °∆t°21:16, 6 July 2026 (UTC)[reply]
I found a related error message in the cite template error message that is shown in preview, so I reported it, along with some of the details from here, at the relevant talk page. I also added a bug report to T423924, which may be the same bug or may be only related. – Jonesey95 (talk) 21:20, 6 July 2026 (UTC)[reply]
Parsoid uses the structure of the ref tag content to determine duplicates, but the legacy parser uses wikitext to determine duplicates. In these cases, it is likely that the ref content is identical even if the duplicate named ref's wikitext is not identical. So, Parsoid doesn't display the error. But, the reason it is still showing up in the category is because we are still using the legacy parser for generating that info. We'll be using Parsoid for generating category metadata in the coming months which should fix this inconsistency. SSastry (WMF) (talk) 21:23, 6 July 2026 (UTC)[reply]
While waiting for the bug to be fixed, add ?useparsoid=0 to the end of the URL to force the page to render with the previous parser. At List of Suits episodes, a big red error message appears at reference 3, ref name="futoncritic". – Jonesey95 (talk) 21:24, 6 July 2026 (UTC)[reply]
Looks like Suits season 9 defines the futoncritic ref tag but changes the order of params and whitespace (compared to how it is written in Suits season 1 and Suits season 2). The generated content is identical so Parsoid treats it as not a duplicate. But, you would have to go to the 9th season article and make it identical if you wanted to remove this from the category (since Parsoid isn't used for that category yet). SSastry (WMF) (talk) 21:35, 6 July 2026 (UTC)[reply]
{{Hatnote}} is a generic hatnote template that can contain any text, including possibly valid red links. You might want to look at templates like {{For}} and other templates in Category:Disambiguation and redirection hatnote templates, which specifically take arguments that are supposed to be the names of existing pages. I put together a pretty hacky check in {{For/sandbox}}; a decent programmer will be able to do something more elegant. – Jonesey95 (talk) 01:40, 6 July 2026 (UTC)[reply]
Hi there, in the last few days, it seems that infoboxes, but also the size of the text in notes and references, are having some kind of bug or something. Anyone knows why? Cheers Tuesp1985 (talk) 16:01, 6 July 2026 (UTC)[reply]
You will need to point to a page or two and then precisely explain the issue you're seeing. In addition, tell us what your skin, browser, browser version, operating system and operating system version. Izno (talk) 16:32, 6 July 2026 (UTC)[reply]
Thanks for the reply. I see it in all pages with infoboxes. It comes and goes, for example, in Google Chrome I was seeing the issue, but now it has come back to normal, while in Firefox, the issue remains, but a while ago it was normal. In short, the border line disappears, the text size increase considerably, plus flags, maps and other links are pushed to the left. I can post a print screen of the issue, if that's allowed. Tuesp1985 (talk) 16:40, 6 July 2026 (UTC)[reply]
@Tuesp1985 do you know how to use the developer tools on Firefox? If so, the next time this happens, look in the console to see if there are any error messages. Also, look in the network tab under Web Developer Tools. If this is a problem with a CSS file loading, you'll probably see a 40x or 50x series error in the network tab for the style sheet. RoySmith(talk)16:52, 7 July 2026 (UTC)[reply]
It's working now fine on all browsers. But, if I see the issue again, I'll look that up, thanks. Not sure if this is some glitch like the timeline graphics had a few weeks ago. Tuesp1985 (talk) 18:33, 7 July 2026 (UTC)[reply]
@PrimeHunter you mentioned this happens on 2026 Iran war That transcludes {{2026 Iran war infobox}} which in turn includes many national flags using #invoke:flag. I can't remember the details, but I know we've seen examples in the past where lots of transcluded flags blew something up during rendering. It also includes {{2026 Iran war map}} which has more markers than I've ever seen in a mapframe. That's probably not helping either. RoySmith(talk)17:48, 7 July 2026 (UTC)[reply]
@RoySmith: There is a new limit of 1000 images per page in Parsoid. The mobile version already had a 1000-image limit but with another result when it's broken. I have documented the Parsoid limit at Help:Template limits#Images but it's not a factor in 2026 Iran war which only has around 125 images. I don't know whether the markers count but there are far from enough to reach 1000. Anyway, Parsoid just makes links (which are red upload links even if the file exists) instead of displaying the image. My example 2026 Iran war was from the poster at Wikipedia:Help desk#revert infoboxes who apparently had the issue on many pages but failed to give a link on my request and only said "Iran War". I normally use Firefox where I haven't seen the problem. I briefly tried Chrome where I saw it on 2026 Iran war. PrimeHunter (talk) 19:41, 7 July 2026 (UTC)[reply]
Was just coming here to report this and, after a hard refresh, the issue seems to be fixed for me now too. Thanks for fixing this! --Grnrchst (talk) 18:59, 9 July 2026 (UTC)[reply]
I had the same issue for the last few days on desktop Google Chrome: all infoboxes (countries, people, and so on) looked as if their styling was broken. I was confused at first, wondering why Wikipedia would make such an odd visual redesign. But right now I just did a hard refresh (Ctrl+Shift+R), and it instantly fixed the issue. Which is great! Beethoven (talk) 18:06, 8 July 2026 (UTC)[reply]
The citation rendered incorrectly. Looking at the source, it appears to be normal Wikitext. So I think there's either something wrong with the Citation Needed template, or in MediaWiki's rendering of it. Omentic (talk) 22:13, 6 July 2026 (UTC)[reply]
I changed all of the <, \, and > to HTML code to fix the issue. I am fairly certain that the only one causing the issue was >, but that was the last one I checked, so I just changed them all. 1brianm7 (talk) 22:35, 6 July 2026 (UTC)[reply]
I think that both the less-than and greater-than are the problem, but not the backslash. The value of the |reason= parameter ends up in the title= attribute of a <span>...</span> element; and certain characters are illegal in HTML tag attributes. Basically, anything that might cause ambiguity as to where the attribute value ends is illegal. --Redrose64 🌹 (talk) 23:26, 6 July 2026 (UTC)[reply]
So, this is sort of a big-scope question: how do we fix this? Is there some way to make every template that generates an image both honor the user preference and support upright? I fear the answer is "No: every template does its own thing and they're all different, so we're screwed". Assuming that's the case, is there at least some way to at least find all the templates that have this problem, perhaps so we can drop a note on the template's talk page urging whoever maintains it to add support? RoySmith(talk)23:43, 6 July 2026 (UTC)[reply]
I've been thinking about this too. Having each of these thumbnails slightly differ in size doesn't look very professional. A few days ago I proposed adding a thumb-size magic word in m:Community_Wishlist/W552. That *may* be a solution, though perhaps not the best one. Check the talk page there as well, and feel free to join the discussion. Ponor (talk) 23:53, 6 July 2026 (UTC)[reply]
I'm not the most technically minded, but that definitely sounds like it could work (with a bit of finessing the templates after the fact). I would definitely prefer to have standard sizes and upright capability for template-posted images! — Chris Woodrich (talk) 00:04, 7 July 2026 (UTC)[reply]
Suddenly, my reading lists and over a thousand pages disappeared within them. I created a task on the Phapricator platform for this problem, but I'm posting it here in case someone can help. Additionally, I'm using the Wikipedia iOS app, and this problem suddenly occurred. The "Synchronize reading lists" setting was always on. When I restart the app and go to the lists section, there's a loading bar at the bottom, but it's always halfway through and disappears after a few seconds. Lock46 (talk) 11:42, 7 July 2026 (UTC)[reply]
Hi @Lock46 — so sorry you're experiencing this! To help our engineers investigate what happened, if you're willing, it'd be helpful if you could share your database contents (which will contain reading history, etc.). To do that, from within the iOS app go to Settings → Help and feedback → Export user data. You can send that file via email (it's a zip archive) to ios-support@wikimedia.org. Sdkb‑WMFtalk16:14, 8 July 2026 (UTC)[reply]
A different image of a similar phenomenon For me, I see the animation initially paused, then it performs one half of a cycle (3 seconds), pauses (5 seconds), then performs the other half (3 seconds) of the complete cycle, pauses and repeats. The whole cycle takes about 16 seconds. This is on both Firefox 152 (Windows 10) and Safari (iPad as mentioned in previous posts). By comparison, c:File:Spin250.gif animates continuously - and faster too. --Redrose64 🌹 (talk) 18:53, 8 July 2026 (UTC)[reply]
Indeed. Protection prevents people from creating the category — but it doesn't prevent anybody from trying to file articles (or other non-article pages) in the category as a redlink and then walking away. Normally, if that happens I could just remove the redlinked category without having to trouble anybody else about it — the problem in this case was bad code on a page that I don't have the specialized privilege to be able to edit in order to have removed it myself. Bearcat (talk) 14:31, 10 July 2026 (UTC)[reply]
On the page 1943 Eddisbury by-election in the boxes one of the political parties is referred to as National Liberal, linking to National Liberal Party (UK, 1931). It should display as Liberal National, as this was the party's name at the time (it did not change to National Liberal until 1948), but still link to the same target. I feel sure someone once told me how to make it display correctly, but I can't remember how and can't find where or when I asked. So, can anyone please help me again? There are a few other article which will need the same fix too. Thanks, DuncanHill (talk) 21:40, 7 July 2026 (UTC)[reply]
Category:Lang and lang-xx using deprecated ISO 639 codes was speedy-moved to Category:Lang and langx using deprecated ISO 639 codes a couple of days ago, but as of right now the new category is completely empty while the old one is still sitting on 10 pages as a template-transcluded redlink — but the template that's transcluding it is smuggling it in from a module, and that module in turn is a morass of nested submodules that's causing me to lose my poop trying to figure out how to fix it, because I can't find it in either Module:Lang or Module:Lang/ISO 639 synonyms but I don't otherwise have enough expertise in the langx modules to know where else to find it.
So could somebody with more knowledge of langx modules than I've got figure out where it's coming from and update the category accordingly? Thanks. Bearcat (talk) 22:32, 7 July 2026 (UTC)[reply]
Oh, I've sometimes gone months without having to post here at all, because most of the time I'm able to fix such things myself without needing to trouble anybody else about them — and even when I do have to post here, it's usually either a single standalone category or a batch of related categories that are all the same source and the same fix. It's definitely strange to have three separate, completely independent things that all surpass my ability to fix on my own happen within a few days of each other. The trickster gods are obviously having some fun using me as a punching bag! (I just wish I knew what I did to deserve that, is all...) Bearcat (talk) 13:36, 8 July 2026 (UTC)[reply]
I keep getting a Lua error that the time taken to execute scripts has expired on Ragnar Hoen. The page is TINY. However, I also just made some changes to {{Infobox chess player}} and I'm worried I may have broken something? The parser profiling data shows surprisingly long times for such a small page... Any help appreciated! Zackmann (Talk to me/What I been doing) 22:47, 7 July 2026 (UTC)[reply]
The article is ok at the moment but {{sports links}} (using Module:External links) is a mess. The Lua time and memory usages are: 3.3 seconds, 17.8 MB (with the template) and 0.4 seconds, 9.7 MB (without). The module pulls external links from Wikidata. Johnuniq (talk) 01:29, 8 July 2026 (UTC)[reply]
CS 1 should supply the default ref names for citations using CS 1 templates in the visual editor
Meta-Wiki is in the process of rolling out better "ref names" for the citations it produces. (Currently it produces ref names like this <ref name=":0">.) They are considering various ways of producing these and there is a consensus for author-date names and that they should give the wiki's some control over these names.[1]
Our team here at CS 1 is better equipped to deliver the default ref-name than Meta-Wiki, for several reasons, given below. This requires that Meta-Wiki give us the ability to supply the default ref-name with a template.
This solution is most useful with CS 1 templates (used 6 or 7 million times in Wikipedia), but it would also provide a way to create a default ref name for any template whatsoever on any wiki.
How it would work
1. Wiki editors create a template that will produce the preferred ref-name for each citation template. E.g.: On Wikipedia, editors create a template called "Template:cite book/ref name" for {{cite book}}. The template takes the same arguments as cite book and would produce a name like "Smith2009" (or related things in unusual circumstances).
2. Editors set "ref name constructor" in TemplateData. E.g.:
"ref name constructor" : "Template:cite book/ref name"
3. When Visual Editor adds a citation, it checks the TemplateData to see if there is ref name constructor, and if there is, it substitutes it into the citation with the same arguments as the citation template. E.g.: In Wikipedia it would produce this:
<ref name = Smith2020>{{cite book|last=Smith|first=Karen|year=2020|<etc...>}}</ref>
If there is no constructor, they produce the default ref-names that they are using now.
On Wikipedia, the CS1 templates' ref name constructors will produce author-date names, using the code that is already written to produce CITEREF HTML anchors. This code has been in use for more than twenty years and, in that time, it has become very robust and complete: it handles all sorts of unusual cases and these solutions and work-arounds have been developed and documented.
These unusual problems are, well, unusual, and the vast majority of the time these solutions are not necessary. But with 7 million articles and ~70 million citations these problems eventually occur. The CS1 team has found solutions. Among the things that they've handled:
HTML encoding issues and foreign spellings
Intelligently finding the name from among parameters: last, surname, author, author-last, author-surname, contributor, contributor-surname, contributor-last, editor, editor-last, editor-surname (X a couple of ways to number them, such as author1-last and author-last1). The code handles things like:
Sources with dozens of authors (as happens in large scientific projects e.g. this[2])
Finds the year from the "year" and "date" parameters
It supports 20-25 different date formats
It can find and report errors in dates
It handles date ranges e.g. 2016-2017
It handles the situation where the year of the source is unknown. (e.g. "n.d.", "no date")
"c." or "circa"
The template has a parameter (|ref=) to specify the ref name when the automatic system fails
It has complete documentation and a set of recommended "best practices" for things like:
Variations in format, such as author-title
More than one work by the same author in a year
Two works in the same year by authors with same last name
No author name, e.g.:
Author is the institution
Anonymous author in a magazine
Simply "Anon."
And I'm sure there are other problems that have been solved. (I gathered this information by studying the Lua code and the documentation -- it would be easy if I missed a few.)
I make this long list to prove the point that: Meta-Wiki should not attempt to duplicate this code. It's more complicated than you think, once you take into account everything that can happen in 70 million (plus or minus) citations.
For CS1 programmers, I did a sketch of what the adapted Lua code would look like here. I am not a Lua programmer and this code probably won't even compile, but I sketched it to show that it's feasible and requires almost no re-factoring. (In my days in software development, I would have sized it at one man-day for a minimum viable product, five man-days to work the kinks out.)
Strengths
This method requires minimal effort by the visual editor team.
All responsibility for maintenance and design is transferred to the individual wikis. It allows the normal wiki process to: handle suggestions; uncover problems, unexpected cases and unintended consequences; develop solutions and workarounds; support variations and innovations. This allows thousands of editors to participate. Problems are typically solved quickly, rather than languishing on wish lists for decades at a time.
CS 1 style templates already have code that produces the CITEREF* anchor. The hard part has already been solved. Building the new entry point should require only a few days.
The CITEREF code at CS 1 is robust, as shown above.
The visual editor team will not be able to simply "define a few rules" and solve all the potential problems into the unforeseeable future. It has taken years of effort catch all the weird things that can come up with CITEREF. The visual editor team shouldn't try to solve a problem that's already been solved.
An individual editor can solve problems without having to ask for help from Meta-Wiki or even CS 1 programmers.
Author-date ref names are machine readable and human readable; they have genuine semantics. Editors will find them easier to use than opaque, inscrutable ref names.
Author-date ref names come close to uniquely identifying the source. They are (in almost all cases) portable to other articles.
Weaknesses
I can't think of any.
Please show your support here
But don't: discuss any other issues outside this proposal, such as citation styles, the use of the visual editor, or templates or any other contentious subjects. This is a very narrow proposal: we're only talking about the default ref-name for citations made by the visual editor.
I support this change. It would make it much easier for other editors in source editor to see at a glance what visual editor users are trying to do. I often have to use a user script to achieve the same outcome. -- Reconrabbit (talk) 12:53, 8 July 2026 (UTC)[reply]
We recently published an update announcing that we'll move forward with the project, given the broad support especially for content-based reference names (reference names based on template parameters or URLs if there's no (configured) template). You can follow the project by subscribing to phab:T430051 (or any sub-tasks that might interest you). Note that the task descriptions might not be complete yet. You can also watch our project page and it's talk page for any updates.
As with any project we're working on, we're aiming at a solution that benefits all Wikimedia wikis. There are thousands of citation templates across hundreds of wikis – most of them far less advanced than enwiki's CS1 templates. I'm happy about any input, but we won't implement solutions which are specific to English Wikipedia only (by the way based on WP:Citation templates and reference anchors it seems to me that even many enwiki templates wouldn't be covered by the proposal above).
Note that we are a small team at Wikimedia Germany working on community wishes. That's why we stated from the beginning that changes to the user workflow are out of scope for us, as are any changes that would allow automatically updating existing reference names if the reference content changes [6]. Our intention is not to build the perfect solution, but to find a simple and lean one that alleviates the pain currently caused by auto-generated names like <ref name=":0">. We are confident that we can implement a simple mechanism allowing all wikis to define ref name patterns, regardless of how advanced their templates are.
I can't think of anything "leaner" for you all than just leaving it to the template builders. If they can build the ref name, you don't have to. ---- CharlesTGillingham (talk) 21:27, 8 July 2026 (UTC)[reply]
I believe there's a misunderstanding. We won't create ref names based on templates ourselves, we'll create a mechanism allowing local wikis to define their preferred ref name pattern (likely via TemplateData). The main difference is that our approach doesn't rely on the CITEREF code you mentioned above (which doesn't exist on many wikis). Johannes Richter (WMDE) (talk) 05:49, 9 July 2026 (UTC)[reply]
@Johannes Richter (WMDE):: I think you might be misunderstand me, actually. You said "we'll create a mechanism allowing local wikis to define their preferred ref name pattern (likely via TemplateData)". All I am doing is describing one such "mechanism" "via Template Data", a very simple mechanism can handle any possibility: TemplateData has the key ref name constructor =, and if it is set, you use the template to create the default ref name. If you want to develop a different "mechanism" as well, this does not preclude that. ---- CharlesTGillingham (talk) 00:27, 11 July 2026 (UTC)[reply]
You are describing an approach with doesn't require wikis to just add a line to TemplateData, but also to create and maintain complex templates which most wikis are not equipped to do based on my experience (other editors seem to agree [7]), English Wikipedia can do amazing technical stuff, but that's a major exception across the ~300 Wikipedia language versions and the hundreds of sister projects. We are looking into your proposal to see if it can spark inspiration for our approach. Johannes Richter (WMDE) (talk) 05:42, 11 July 2026 (UTC)[reply]
References
^I heard about that this literally days before they closed the discussion, and missed the opportunity to pitch this there.
^Walborn, Nolan R.; Sota, Alfredo; Maíz Apellániz, Jesús; Alfaro, Emilio J.; Morrell, Nidia I.; Barbá, Rodolfo H.; Arias, Julia I.; Gamen, Roberto C. (2010). "Early Results from the Galactic O-Star Spectroscopic Survey: C III Emission Lines in of Spectra". The Astrophysical Journal Letters. 711 (2): L143. arXiv:1002.3293. Bibcode:2010ApJ...711L.143W. doi:10.1088/2041-8205/711/2/L143. S2CID119122481.
What tool to use to quickly fix disambigs after a move?
I just moved Starblade (1991 game) from Starblade, which should be a disambig given there is also a notable Starblade (1990 game) (https://www.mobygames.com/game/6902/starblade/) that I may create an article for. Is there a good tool to quickly disambiguate (fix) the links? I think pretty much all the links we have to Starblade go to the 1991 game. I don't think the 1991 game is more notable than the 1990 one, both have more than dozen contemporary reviews (fine, 1991 has more but it's a tough call to call it dominant search term in this obscure environment). Well, if someone wants to revert my move and just say I should hat 1991 game once it is created, I won't fight it, but if you can fix the post-move disambig issue (or teach me how to do it easily) that would be better, IMHO. TIA. Piotr Konieczny aka Prokonsul Piotrus| reply here12:21, 8 July 2026 (UTC)[reply]
We have a big problem with banner bloat on Wikipedia, and this template [{{Contains special characters}}] seems to me like it's part of it. For the circumstance in which someone does have rendering support for special characters (which is increasingly common over time), it's entirely unneeded, and even for the situation in which they don't have rendering support, I question whether the clutter it creates is worth it — most people can intuit when they see boxes that there is a rendering support issue, and regardless the box doesn't tell them much about how to get support.
Would there be any way to detect whether a user has rendering support for particular characters used in an article and to hide this notice if so? Sdkbtalk19:22, 25 June 2026 (UTC)[reply]
@Sdkb We do have technology for that, being charset detection, and we can hook it up to whether or not we can hide the templates, but it's essentially a probabilistic approach to pinpointing what character set exactly the reader is using.
I think it's a hard problem to solve. Probably impossible without custom js at least. Maybe post to VPT and hope someone really clever has a solution? Trialpears (talk) 09:58, 8 July 2026 (UTC)[reply]
I would vote for just nominating the template for deletion. It's widely misused on pages that have things like simple Greek or Arabic characters that have been part of Unicode since 1991. As a start, I'd have the template hide itself is the specified language is anything included in Unicode 1.0 (Arabic (including Perso-Arabic and Urdu), Armenian, Bengali, Bopomofo, Cyrillic, Devanagari, Georgian, Greek and Coptic, Gujarati, Gurmukhi, Hangul, Hebrew, Hiragana, Kannada, Katakana, Lao, Latin, Malayalam, Odia, Tamil, Telugu, Thai, and Tibetan). --Ahecht (TALK PAGE)17:27, 9 July 2026 (UTC)[reply]
@Ahecht, I don't feel like I have enough familiarity with character recognition technology to make the most informed TfD nomination. Would you have an interest in drafting it? Sdkbtalk20:54, 9 July 2026 (UTC)[reply]
Since I deleted some Arabic script, when I go to highlight text (especially more than one word) the highlighting breaks up, and/or partially undoes itself, and/or auto-enters. Having Googled the problem, it gives me a L>R text solution for Word, which I have tried, even though I'm not having a problem with Word, just Wikipedia. How can I clear this problem on Wikipedia? (Windows 11 Pro, MS Edge, Vector Legacy (2010) - Many thanks - Arjayay (talk) 11:41, 9 July 2026 (UTC)[reply]
@Arjayay: Arabic is displayed right-to-left and this can affect how you mark text. You may have to move in the "wrong" direction but it can be confusing, especially when mixed with left-to-right text. If you cannot read Arabic or other right-to-left scripts anyway then you may prefer to display them left-to-right when you edit with code like this in your CSS:
Thanks PrimeHunter, but that is not the problem. I had no problem highlighting until I deleted the Arabic text, which took a couple of goes, but since then I have had trouble marking any text in standard English in any article, I am not trying to highlight Arabic, or any other text, just English. The highlighting initially moves the way I drag the cursor, and then reverses, or jumps, part way along the line. - Arjayay (talk) 12:29, 9 July 2026 (UTC)[reply]
@Arjayay: I don't use Edge. Have you tried to close and restart the browser or the whole computer? Does it happen on pages with no right-to-left text like Example? My CSS might also work for your issue. PrimeHunter (talk) 12:45, 9 July 2026 (UTC)[reply]
@Arjayay: It sounds like an Edge setting unless the mouse has problems (can you try another?) which just happened to start after the Arabic thing and would probably also affect other programs. Use User:Arjayay/common.css to apply the code to all skins. Only enter the rendered code starting at "textarea", not the code in the edit window. The code only affects the text area where you edit but if you have the problem on pages without any right-to-left text then I doubt it will help. PrimeHunter (talk) 13:49, 9 July 2026 (UTC)[reply]
If you right-click on the text field, then select Writing direction → Left to right, does that resolve the problem? (Being able to toggle this is a feature unique to Edge, AFAIK) Matma Rextalk17:52, 9 July 2026 (UTC)[reply]
Thanks Matma Rex - that seems to have worked (so far, but I'm not counting chickens) even though left to right was already ticked when I looked, I re-ticked it. That might also explain why it wasn't a problem om Word. Thanks again. - Arjayay (talk) 18:10, 9 July 2026 (UTC)[reply]
That article is rendering as intended, although it could be more flexible. The quote template was set to a fixed width=20em, which is fine for desktop screens but not great for very narrow mobile screens. Removing that fixed width allows the template to use a more reasonable amount of space on all screens. There may be a way to make the template more responsive in the mobile view, but letting it auto-size is better than a fixed width. – Jonesey95 (talk) 19:51, 9 July 2026 (UTC)[reply]
It’s not really a bug. Some things are expensive to do and will sometimes fail. It’s the system protecting itself from edge cases. —TheDJ (talk • contribs) 10:40, 11 July 2026 (UTC)[reply]
It may be a bug, but determining that would require looking at the database queries being generated and whether the database is handling them correctly. I've seen plenty in the past where queries needed improvement, or databases needed maintenance to pick the correct plan, or upstream bugs in MariaDB needed reporting. Anomie⚔12:56, 11 July 2026 (UTC)[reply]
Screenshot showing the suite of desktop Usability Improvements enabled at en.wiki
Next week, a set of incremental design and functional changes will become available by default for Wikipedia's talk pages. You can opt-out of these changes at any time in user preferences. More details below.
For context: Since 2023, 85,000+ volunteers at en.wiki have been trying these features via Beta Features. English Wikipedia is the last wiki where these changes haven't yet been deployed to as default.
Details: Usability Improvements for Discussion Tools are a set of incremental design and functional changes to Wikipedia’s talk pages, aimed at making these spaces more intuitive and accessible for all contributors, especially newcomers. The improvements focus on visual clarity, easier navigation, and better tools for communication. Some earlier research shows these changes lead to more productive participation and fewer reverts. These changes complete the talk pages improvements by addressing long-standing usability issues identified in the 2019 Talk Pages Consultation. They align with Wikimedia's goal to make editing more inclusive and accessible.
These are the main improvements that will be added to talk pages by default:
Visual Clarity: Sans-serif fonts and lines placed above H2 section-titles, and clearer action buttons (reply, subscribe, new topic), make talk pages more clearly different from articles.
Metadata: We show the number of comments per topic, the date of the latest comment, and an improved table of contents (in Vector-2022) that highlights the number of replies.
Action Tools: Easier-to-find buttons for subscribing, replying, starting new topics on an empty page, thanking contributors, copying a link, and reporting problems from the reading interface.
Backward Compatibility: Usability Improvements apply to all skins, on both mobile and desktop experiences.
Thanks, that looks like a (minor) bug. I think some ID data was added to be used internally by the interface library, but they are somehow being copied as HTML IDs as well, and HTML IDs are supposed to be unique. ESanders (WMF) (talk) 16:37, 11 July 2026 (UTC)[reply]
It seems that the search box at the top of all Wikipedia pages has recently moved slightly to the left. Looking at the Wayback machine I can see this change be made. This is it last year and this is it now (make sure you enable the left sidebar). The search box used to be aligned with the content column (not sure what its proper name is) but now it's not aligned and it looks a bit odd. Panamitsu(talk)09:21, 10 July 2026 (UTC)[reply]
For some reason, the WMF developers took away the globe when they changed to the 25th anniversary logo, even though they modified the globe logo to add a 25th anniversary puzzle piece. That globe removal moved the search box to the left, because it is rendered to the right of the Wikipedia logo text. If you want to fix this bug, you can add
Me and multiple other editors have partway through an edit been logged out and been hit by an autoblock seen here when i request the block be softened to allow me to continue editing, and here when @Beta Beta Beta noted they had had a similar issue and later another user @Épine also reported to have had similar issues. This may be a major underlying problem. Jabba550 | ✉ in solidarity09:43, 10 July 2026 (UTC)[reply]
I must clarify a misunderstanding on my end, while I observed the sudden logouts while browsing and editing multiple times, I am not personally caught in a range block. Sorry for the misunderstanding there! épine♬09:53, 10 July 2026 (UTC)[reply]
That would be quite concerning at scale. But yes, I do feel like some weirdness is going on, even if not everyone has the same exact symptoms. Thanks for starting the discussion. épine♬10:06, 10 July 2026 (UTC)[reply]
These don't sound like autoblocks. Switching IPs and hitting an IP block isn't so unusual (Jabba550). Beta Beta Beta may have been editing from a blocked range all along, and not noticed it until they were logged out for whatever reason - I haven't checked this, but many people edit from soft-blocked ranges. These incidents are two months apart. Logging out when hitting a block would be unexpected, and it might be worth trying to see if it can be repeated. -- zzuuzz(talk)10:34, 10 July 2026 (UTC)[reply]
I hadnt changed IP and was randomly logged out and my IP is the same as a schools, so it was of course blocked, however I was blocked after logging back in by an autoblock, its also the fact that people are randomly being logged out without reason. Jabba550 | ✉ in solidarity10:52, 10 July 2026 (UTC)[reply]
I don't have any reason to believe both. My phone was on mobile data and I am currently in Hawaii (I am assuming at least one other Wikipedian listed is a few thousand miles away from me maybe). Beta Beta Beta - talk22:03, 10 July 2026 (UTC)[reply]
I am quite positive that I have not been on the same network as the aforementioned parties as I was editing on my personal home network. épine♬22:03, 10 July 2026 (UTC)[reply]
While editing suddenly I jumped out of Monobook (which is still listed as my preference) to whatever this jumble of things is, which only appeared when I tried to edit. So I logged out, back in, and now Monobook is completely gone. No clue as to why, so asking for help, thanks. Randy Kryn (talk) 14:48, 10 July 2026 (UTC)[reply]
"Bizzaroworld skin" isn't very helpful for figuring out the problem. Did you check your preferences to make sure they didn't change for whatever reason? Have you tried switching to a different skin, saving, then changing the pref back? If that doesn't work, my guess would be maybe you accidentally switched from desktop view to mobile view, but without more info or a screenshot I can't be sure. – Scyrme (talk/solidarity) 14:59, 10 July 2026 (UTC)[reply]
No, have never used mobile, but, as mentioned above, I may have somehow clicked on it. Where would I find it to reclick? Thanks. This skin I've been tossed into looks like the instrument panel of an airplane, how do editors work on this thing? Thanks. Randy Kryn (talk) 15:05, 10 July 2026 (UTC)[reply]
Tried your suggestion to enter a new skin and then back to Monobook, same problem still present so maybe I did click on mobile since the page sections are segmented into separate boxes. Now, how to find where I clicked into mobile. Randy Kryn (talk) 15:14, 10 July 2026 (UTC)[reply]
Must be in mobile as the navboxes don't appear at the bottom of the pages. Categories do though, I thought categories did not appear in mobile. Randy Kryn (talk) 15:17, 10 July 2026 (UTC)[reply]
Based on your edit tags [8] it seems like you're currently using the mobile skin, I guess you accidentally clicked on the "Mobile view" link. Scroll down to the end of the page, you should see a link "Desktop view" next to "Cookie statement", "Terms of Use" etc. Johannnes89 (talk) 15:20, 10 July 2026 (UTC)[reply]
Thanks Johannnes88, that seems to have worked. What a horrible experience, falling into mobile. When Monobook was overturned as the default skin in 2009 it must have been a mess for new users, and I have no idea how new users now find their way through the maze of instructions and odd symbols. No wonder more than half of new users never edit once they sign in. Randy Kryn (talk) 15:27, 10 July 2026 (UTC)[reply]
The mobile skin looks better on actual mobile devices in my opinion, it's not really made to be used on desktop devices... And users (like me) who started using the internet (and Wikipedia) when Monobook was no longer the default, are probably used to a user experience with lots of icons (especially on mobile). That's also true for the default desktop Vector 2022 skin which looks much more like what I'm used to from other websites compared to Monobook. Johannnes89 (talk) 15:43, 10 July 2026 (UTC)[reply]
Thanks for the help earlier. Back in Monobook. That mobile thing really should be overhauled to create a very friendly user interface. Recently read somewhere that more than half of new people who are in the middle of making their first edit back off and don't make the edit. This experience of being suddenly thrown into mobileland gives me a good look at why. Monobook is easily edited, and you say that Vector 2022 is as well (have never spent time on it). Mobile isn't. Randy Kryn (talk) 00:39, 11 July 2026 (UTC)[reply]
Well, the trickster gods really have it out for me this week, because the latest run of Special:WantedCategories features yet another batch of redlinks I can't fix on my own. There are three distinct batches of related problems — one of which I took to Wikipedia talk:Featured topics instead of here, but the other two are surpassing my ability to know how to fix again.
Category:Treaties of and Category:Treaties of Georgia, both being autogenerated and transcluded by the {{Intellectual property treaties of country category header}} template, which again is smuggling the redlinks in via the country2nationality module. If it helps, the incomplete "of nothing" category name is being transcluded onto two former countries that no longer exist, while the "of Georgia" one is being transcluded onto a category that is already correctly named "Georgia (country)" itself — the expected Category:Treaties of Georgia (country)does exist, yet somehow the template is transcluding the undisambiguated category instead of the one that actually exists. But I don't know enough about how the nationality module works to figure out why that's happening when the same module isn't doing that in other invocations as far as I can see, and I can't justify creating it as a categoryredirect precisely because of the standard ambiguity between Georgia-Tbilisi and Georgia-Atlanta.
Category:Pages using infobox netball biography with deprecated parameters and Category:Pages using infobox speed skater with deprecated parameters, both being transcluded by the use of the named infoboxes on testcase pages that wouldn't belong in the categories even if they did exist — and which both somehow got added to the testcase pages within the last couple of days as a result of edits which purported to be fixing the use of deprecated parameters. Yet even when I attempted to remove the category from the speed skater infobox, the category still stayed transcluded onto the testcases page anyway, meaning that it was again coming from somewhere else rather than from the code I tried to remove. (I've already reverted myself, since the edit failed.)
Is there a script/gadget or something that can be used to check a Talk page for common issues which prevent Talk pages from archiving properly?
I'm aware that missing/broken signatures can stop a section from archiving, but occasionally the entire page just doesn't archive. Sometimes the fix is easy, like moving the bot configuration outside the {{Banner holder}} if it's been moved inside by an editors unaware that this stops it from working. I think sometimes it can also be due to broken tables or lint errors; for that I can check Special:LintErrors. However, sometimes I run into a page where there's no obvious problem. I've checked all the signatures and Special:LintErrors, checked for any misplaced {{DNAU}}s, and made sure the bot configuration is as it's supposed to be, but none of those things appear to the problem. It would be helpful if there were script that could read the page the way the bot does and report anything strange to save on having to manually review the page and guess at what the problem might be.
While I could brute force it by manually archiving the page to clear whatever is impeding the bot, I generally prefer to fix the underlying issue. If the archival bot has trouble reading the page, then other bots (like archive indexers) or automated tools might too. – Scyrme (talk/solidarity) 17:49, 10 July 2026 (UTC)[reply]
Noreplace should become the default. It is almost never helpful to replace a SD which has been set earlier in the page. Certes (talk) 21:30, 10 July 2026 (UTC)[reply]
That was evil. Even the demons that I summoned for a second opinion, thought the use of noreplace was a step too far. I have fixed the issue quite painlessly by using a named section. This allows much more control over what is included and especially what is not included. It allows the Utilitiessection of the Venezuela article to bypass the SD and also exclude the update template that talks about the complete article — GhostInTheMachinetalk to me06:56, 11 July 2026 (UTC)[reply]
My collapsible-table-rows workaround just broke, and I'm not sure why
On the mathematical article Golden field, there is a table of the first several elements of the field and some information about them at §Table of integers. Because there are a lot of rows, and the details are not necessarily of deep interest to every reader, I split the table into two parts: the first 12 rows, which I want to display by default, and an additional 15 rows which are gated behind a "show/hide more rows" toggle which should un-collapse and then re-collapse the table. I looked at mw:Manual:Collapsible elements for advice about how to accomplish this, and then just fiddled with it until I got something working.
Because, unfortunately, several table rows can't fit inside a single HTML element (at least when using wikimarkup for describing the table), as a workaround I put the same class="mw-collapsible mw-collapsed" id="mw-customcollapsible-morerows" on every row that I want to toggle shown/hidden, and then put a "mw-collapsible-toggle" text link at the bottom. This worked great. It seems to still work just fine when just the table code is isolated on this talk page:
But on the actual article it is now mysteriously broken: Golden field § Table of integers. I hadn't noticed this issue before, so presumably something changed recently about Wikipedia/Mediawiki.
Can anyone figure out what the problem is, what might have changed in mediawiki in the recent past to cause the issue, or suggest alternative technical methods/workarounds to achieving this goal? –jacobolus(t)00:57, 11 July 2026 (UTC)[reply]
Presumably the new parser is inevitable and it's probably safe to assume that whatever it didn't like about this isn't going to be easily fixable by changing the wikimarkup.
So in that case, can anyone think of some other way of accomplishing this kind of collapsing/uncollapsing of a table? Either making the full table visible by default or removing the default-hidden rows would make the article significantly worse in my opinion. –jacobolus(t)01:39, 11 July 2026 (UTC)[reply]
No, there is no way to do something like this. That it ever worked is something of a mystery to me.
Another possibility might be to just write raw HTML for the tables and use multiple separate <tbody>...</tbody> elements. I was hoping to stick with wiki-markup for the tables though. Edit: that's probably impossible as judging by mw:Help:HTML in wikitext Mediawiki stupidly doesn't seem to allow the use of explicit tbody elements. –jacobolus(t)06:22, 11 July 2026 (UTC)[reply]
Ah, that could be fine. I'll give it a shot. Thanks! (Aside: it would have been a lot better if the collapsing code used a class for this instead of an ID.) –jacobolus(t)17:39, 11 July 2026 (UTC)[reply]
If I edit a page section and add a watchlist label, it's not being stored after saving the edit. If I then go to that article in Edit watchlist, it's not there and it also isn't there the next time editing the article. Simeon (talk) 11:57, 11 July 2026 (UTC)[reply]
I copyedit articles section-by-section to avoid edit conflicts, and used to get a boilerplate advisory message if a named reference was defined outside the section I was editing. These are now coming up as ref errors, although there are no ref errors when I view an entire page. Due to the timing I suspect Parsoid, but the same ref errors were generated when I switched to the legacy parser and cleared my cache. This seems to defeat the purpose of using named references. Any help appreciated! In solidarity, Miniapolis16:56, 11 July 2026 (UTC)[reply]
Schazjmd (talk) 15:41, 4 July 2026 (UTC)
You are invited to join the discussion at Template talk:Navbox § New self-linking behavior. Sdkb talk 13:05, 7 July 2026 (UTC)
.gif)
Done * Pppery * in solidarity 21:08, 7 July 2026 (UTC)
