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.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
If an image thumbnail is not showing, try purging its image description page.
If the image is from Wikimedia Commons, you might have to purge there too. If it doesn't work, try again before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
I’m Eliza Blackorby from the WMF’s Reader Growth team. A few weeks ago, WMF posted here about declining pageviews to Wikipedia – that’s what our team is working to address. We want both new and existing readers to return to Wikipedia because they find it a compelling place to learn. Over and over, a top request from readers is that they wish for “more images/photos” on Wikipedia, as demonstrated in surveys of global internet users. As a result, we want to show readers more images and display images in a more enriching way. Our hypothesis is that by making it easier to explore images already in articles, readers may find Wikipedia more engaging and return more frequently, with some of them eventually becoming editors.
What idea are we testing?
A few weeks ago we shared how we were considering a test of a sliding gallery view of all an article’s images at the top of the article that readers can then click to jump to that part of an article, inspired by Community Wishlist requests for improved discovery of media. We’ve since built a prototype, called Image browsing, that takes your feedback into account. You can try it by adding the url parameter ?imageBrowsing=1 to the end of any URL on the mobile view for enwiki. For example: https://en.wikipedia.org/wiki/Hummingbird?useskin=minerva&useformat=mobile&imageBrowsing=1
What stage is this project in?
Our initial discussions with you constituted phase 0 of our reader experiment phases. We now want to enter phase 1: launching a small test with an early version of these ideas. It’s not yet clear whether this feature will be an improvement for readers, so we want to test it to determine whether to proceed into Phase 2: building a feature.
What is the timeline?
We will A/B test this version with 0.05% of mobile readers on English Wikipedia starting the week of November 17 and ending four weeks later on December 17.
What does the experiment include?
This test will include a gallery at the top of an article that shows all the article’s images. The feature will be available for any article that has three or more images. Tapping on any image will open a browsing experience with the image enlarged, its caption, and options to view it on Commons (if available). Readers will see images and paragraph-excerpts from the article itself in the gallery and will be able to switch back to where the image appears within the article. At the bottom of this experience, readers will be able to view images selected by editors for the same article in other Wikipedias.
Screenshots:
Below are three separate screenshots of the test's different aspects to demonstrate the experience when a user clicks through and scrolls.
What input are we looking for from you?
While this round of the experiment is focused on simply testing if readers are interested in image browsing, there are still issues that would need to be resolved before developing this into a feature, including those around bad images and cross-wiki images as it relates to conflicting policies or cultural sensitivities. We invite you to help us continue to identify concerns like this. In the collapsed box you'll find a summary of the feedback and risks we heard from you in September, along with how we're thinking through them.
Feedback from Phase 0
Mixed feelings on showing images from other projects
Commons: Some editors liked the idea of pulling more images from Commons, while others felt there was too much risk to showing Commons images without editor oversight. For this test, we have decided to only use images that have been added to at least one Wikipedia.
Images from other wikis: Some editors felt that allowing readers to click to see images from other wikis for the same article could pose a risk to editor oversight. For the purposes of gathering information in this test, we are including the ability to view images from other wikis, and will carefully observe and share the results with you for future conversations.
Risk of showing inappropriate images
We’ve set up this first A/B test so that you can exclude page images by adding the tag for exclusion, but we agree there’s still some risk. If we decide to proceed with this idea after the test, we’ll review ways we can expand this list to include further editorial oversight.
Risk of showing irrelevant images
Here, we’ll be using the same classes as MediaViewer. Instructions on how to add these classes are available on this page. Images already excluded from Media Viewer will not appear in the experience.
We agree this is a risk when displaying images from across wikis since not all wikis have the same level of moderation. We’ll be reviewing this piece with our legal team and current policy to make sure everything is aligned.
The guidelines in the Manual of Style for images focus on how images are presented within article content. Since this experience is more like a navigation or browsing experience outside the main content space, similar to how images appear in Media Viewer, we’re not sure how or whether to apply the MOS here, so let’s keep talking about that.
Since this work is still experimental, we expect to refine and adjust this idea based on your feedback. We’d love for you to try the feature on a few articles using the url parameter above. Your input will help us decide how to improve it if we move forward after the test. Also, stay tuned for the test results. We’ll share them with you and discuss together whether it makes sense to continue with this idea into Phase 2, and if so, what additional changes we will need to make before proceeding. Please share your thoughts and questions here, and for more info, see our project page.
When I go to the hummingbird page and click on the article image that has the caption "Adult male bee hummingbird, Cuba", I am taken to a page that contains the image, along with credit and a link to the license information. It is my understanding that CC licenses require that information to be linked to and displayed when the image is clicked. When I click on the same image in the slide show, I do not see any licensing information. This may be a problem.
The other obvious issue, of course, is that the images are displayed without their captions until you click them individually. As User:DarthVader might have said, I find your lack of context disturbing. – Jonesey95 (talk) 01:21, 7 November 2025 (UTC)[reply]
Hi @Jonesey95, thanks so much for flagging. You raise some important points. We've taken them into conversation with colleagues in the Legal department, and agree that we would need to address them if we end up building a future feature out of this experiment. I'll follow up more here if/when that happens. EBlackorby-WMF (talk) 22:31, 7 November 2025 (UTC)[reply]
Is it really OK with the legal department to knowingly violate the terms of CC-BY-SA, even on an experimental basis? I'm not a lawyer, so I don't know if it really is a violation, but it doesn't seem like something that would normally be allowed here at en.WP. If someone tried to roll out a template that behaved in this way, I think it might get some license-related pushback. – Jonesey95 (talk) 00:15, 8 November 2025 (UTC)[reply]
@Jonesey95 I disagree that there is any semblance of a violation here. There is a prominently displayed link to commons off to the side, which imo counts as attribution. I also disagree that if a editor made a similar choice, they would get any license related pushback. The practice of using images as background and then overlaying attribtuion text is pretty common across userpages (a example of this would be Sigma's userpage) Sohom (talk) 13:30, 11 November 2025 (UTC)[reply]
The Creative Commons licences do not require a specific method for providing attribution. The licence states that it may be reasonable to meet the attribution requirement by providing a link to a page that has all the required information. Since clicking on a gallery image displays an expanded image with an overlaid link to the attribution information, personally I feel this is a reasonable approach to provide attribution. isaacl (talk) 06:02, 8 November 2025 (UTC)[reply]
I find the workflow to jump to the section where the image is located to be awkward. After swiping through the gallery at the top of the article, I select an image, and see an expanded image at the top of the page, but there's no link to the section. I have to scroll down through the list of images (with the little summaries) until I reach the image I originally selected, and then I can select "View in article". I think it would be better if the little summary and "View in article" link appeared directly below the expanded image, so the context and jump link would be immediately available. (I think it should still appear within the comprehensive list as well.) isaacl (talk) 06:11, 8 November 2025 (UTC)[reply]
Hi @Isaacl, thanks for this feedback! It's helpful to hear your thoughts and ideas around page navigation. We're still figuring out the best way for anchor links to behave on the page in a way that more seamlessly connects images with context via their summary and their place in the article. Our design team will take a closer look with this in mind. Do you think the summary and "view in article" link would work best overlaid on top of the expanded image, underneath where the caption currently is? Or do you have something different in mind? EBlackorby-WMF (talk) 20:48, 13 November 2025 (UTC)[reply]
Due to the length of the blurb (I guess it's an excerpt, not a summary), I think it would be better to appear below the image, as I suggested. From a UI perspective, since the "view in article" link will bring you to the text in the excerpt, I think it would be better for the link to appear floated to the right at the top of the excerpt. I suggest leaving a bit of extra space at the bottom so the top of the excerpt and the link is visible without scrolling. I think it is better for the text to appear distinct from the caption, so prefer the text not to appear as though it is floating over the image. isaacl (talk) 22:43, 13 November 2025 (UTC)[reply]
I think the general idea here is good. If we can increase the visibility of media in a way that enhances the usefulness of Wikipedia to readers, then I'm all for it. The current implementation also seems to be decent, although some kinks may have to be worked out as pointed out above.
Even if directly pulling images from Commons is ruled out, what about simply providing a link to the Commons category? We already have {{Commonscat}}, so I don't see how this would be controversial. The link could look something like this:
Hi @~2025-32228-23, thanks for the note, glad you like the idea so far. Potential connections with Commons is something we are thinking about a lot, and this idea you've posed is a good one for future investigation. How do you feel about offering a link to view media from other projects besides Commons (like other language wikis)? EBlackorby-WMF (talk) 21:01, 13 November 2025 (UTC)[reply]
@EBlackorby-WMF: I think the way this feature currently works in the demo is mostly reasonable.If editors on another language edition have decided to include a photo, then it is probably at least somewhat illustrative and useful. On the other hand, Commons categories sometimes include low-quality / low-relevance media, which makes including photos from Commons more problematic.
I do see some risk of cross-wiki vandalism. For example, if a troll wants to deface a protected English Wikipedia article on a popular or contentious topic, then they could instead add an inappropriate image to the equivalent article on a different language edition that has barely any eyes on it (e.g., Udmurt Wikipedia). It might take a while for editors to catch this kind of thing.
what about simply providing a link to the Commons category?Support. I think there should be some load more button on the right of the images panel to load more images from the Commons category (e.g. first files that in a deepcategory: scan of the category have most uses in mainspaces) and/or a button there to go to the category. The best may be to have both but usually subcategorization of the Commons category is important where one can't just show random files only directly in the category and when using subcategories too some less-related or less-useful files may show up and it would be difficult to sort them. Thus, ideally the user navigates to the category page by opening it in a new tab or via some integrated Commons category browser that could be added into the Image browsing panel.
Moreover, I like that proposed button design – however not for the Image browsing panel but what would best be added to the See also section (not buried underneath the long References section) and labeled "More media on Wikimedia Commons". Most Wikipedia users aren't really aware of Commons and don't see the Commons category link at the bottom. It needs a modern and well visible button like this and I'm sure readers would find it useful. Prototyperspective (talk) 00:03, 24 November 2025 (UTC)[reply]
Just a quick thing, but I think it would be better if the gallery layout was closer to the one used on Commons for category slideshows. It would provide more context to users. Also, on my mobile device (tablet, using a Chromium browser), the photos were ever so slightly cut off on the sides and I think that having margins/a border like in slideshows would help prevent this. postleft on mobile!19:07, 24 November 2025 (UTC)[reply]
Over on ang:, the Main Page has an issue: it has daily features like en:, using {{CURRENTDAY}} {{CURRENTMONTHNAME}}, but does not tick over to the next day: it can be stuck on one date for ages. It updates if we amend the page, or actively purge the cache: the main page is called 'Heafodtramet', so the clicking a 'Special:Purge/Heafodtramet' brings it to the current date. I did that again this evening.
Is there another way to write it so that {{CURRENTDAY}} etc reflects the current date without intervention?
The NewPP limit report in the HTML of the main page at ang: says "Cache expiry: 2592000". That's in seconds and equals 30 days which is indeed far too much for a main page using {{CURRENTDAY}}. phab:T119366#6407916 by Krinkle in 2020 sounds like it should have been set to an hour. I don't know whether that still applies and I don't know a way to control it. PrimeHunter (talk) 21:01, 20 November 2025 (UTC)[reply]
Thanks for the ping. I recall in the past Parsoid did not yet support reduced cache expiries (e.g. T329067), but that was fixed two years ago and these days Parsoid is enabled by default on several Wikivoyage and Wiktionary wikis. Searching on Phabricator, I don't see any known issues that would explain this. Ping @Cscott. Krinkle (talk) 15:37, 21 November 2025 (UTC)[reply]
Hi all, yes, this is a bug in Parsoid we discovered recently. The same issue as tracked in T408741 which we've been working through and looks like there is something in Parsoid's metadata collection itself we may need to address to fix this. SSastry (WMF) (talk) 15:54, 21 November 2025 (UTC)[reply]
@Hogweard it's not an ideal term solution, but I have an old script to trigger page purging which I wrote for Wikidata - I could set it up to run on the ang mainpage once a day at midnight as a stopgap, if that would help? Andrew Gray (talk) 12:47, 21 November 2025 (UTC)[reply]
@Hogweard okay, set up - it will run at one minute past midnight UK time (so 1.01 UTC in the summer, if it's still going) and purge ang:Heafodtramet. (It will also purge ang:user:AGbot which uses CURRENTTIME, so I have a test to make sure it's working - I guess we find out in half an hour.) The bot won't actually edit anything on the site. Happy to leave it running as long as is needed. Andrew Gray (talk) 23:30, 21 November 2025 (UTC)[reply]
On the BLP noticeboard, people are sometimes directed to the FAQs at the top of talk pages. However, on mobile view, this is all hidden behind a non-obvious sign saying "more about this page". Is there anyway of making that clearer? Red Fiona (talk) 21:46, 23 November 2025 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Updates for editors
Last week, the Wikimedia Search Team recreated the "DWIM" (Do What I Mean) gadget functionality server-side, for Russian and Hebrew Wikipedias. This feature adds cross-keyboard suggestions to the standard search-box suggestions. For example, searching for cxfcnmt on Russian Wikipedia will now add suggestions for счастье ("happiness") that the user probably intended. They plan to enable this feature for other Russian and Hebrew wikis this week. [1]
Later this week, users of the "Improved Syntax Highlighting" beta feature will have syntax highlighting available in DiscussionTools. This requires that the "Enable editing tools in source mode" preference be set. [2]
Campaign events extension – the set of tools for coordinating events and other on-wiki collaborations has now been deployed to all Wikimedia wikis. A new feature known as Collaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcoming learning session to see the new feature in action and share your feedback.
View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [3]
Updates for technical contributors
Users of Wikimedia API can join a usability study to help validate the new design of Wikimedia REST API sandboxes. Interested participants should fill the recruitment survey. [4]
The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support for format=xml&xlst={stylesheet} will be removed from Wikimedia projects by the end of November, 2025. In addition, it will soon be disabled by default in MediaWiki release versions: v1.43 (LTS), v1.44, and v1.45. Support for XSLT stylesheets will be fully removed from MediaWiki v1.46 (expected to release between April and May 2026). [5]
The WDQS legacy endpoint (query-legacy-full.wikidata.org) will be decommissioned at the end of December 2025, and finally closed down on 7th January 2026. After this date, users should expect requests to query.wikidata.org that require the full graph to fail or return invalid results if they are not rewritten to use SPARQL federation. The team encourages users to ensure that tools and workflows use the supported WDQS endpoints (https://query.wikidata.org/ - Main graph or https://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review the Data Access and Request a Query pages for details and assistance on alternative access methods.
Hello everyone, i am trying to modernise the imdb name module of a version of wikipedia in an other language (that supports lua), to use lua, and i cannot understand how can i get the property P345 of a an actor wikidata object. What do i have to do, do i need to get the wikidata object of the wikipedia page and using mw.wikibase.getEntity(), to get all the properties of the person/object and then from the extracted wikibase entity somehow query the P345 property.
Note: I have also noticed when i try to run functions on the entity object that got returned, by assigning the wikibase.getEntity() result to a local "a" variable and then executing a.getEntity(l it fails, with an error along the lines of "You cannot run operations on a local variable defined wikibase entity".
The problem I have is the decentralised nature of technical help questions in Wikimedia. For example, if a user has a problem with inserting OpenStreetMap (OSM) data into an article they might post on the article's talk page, the Help desk, a related WikiProject, the graphics lab, mediawiki, meta or Commons.
Is there a tool that scans talk page comments for keywords, to connect helpers with questions? To reduce the amount of work it needs perform it could work on a defined list (like "OSM", "OpenStreetMap", etc), only scan once per day, limit to lingua franca English wikis and only look at new section creations. Would this sort of thing be feasible on Toolforge? The defined keyword list would need some thought, but things like "OSM", "{convert}", and "copyright" are some of the things I would look out for. Commander Keane (talk) 07:39, 25 November 2025 (UTC)[reply]
The table below was taken from Hexadecimal clock and truncated by way of showing the hex triplet colors. The nine used (#0000, 0100, #0200, #0400, #0800, #1000, #8000, #F000, and #8000) are upon review, however, all zeroed out, i.e. the numerals are all zero. Get back into editing, and lo! they are all back. Most curious!
mw:Page Previews § FAQ says "Is this enabled by default for logged-in users? No." Is that correct for the English Wikipedia? I'm asking because at Help talk:Link § "The tooltip does not show the page one will arrive at." some logged-in users say Page Previews were on by default for them. They're on for me, but I don't remember whether that was by default or I turned them on, and I don't know how to check. I could create a new account just to test this, but that seems a bit wasteful. :-) Ideally, an answer would point to somewhere in the MediaWiki source code, or on Phabricator, or a configuration here on enwiki, or an official announcement. That would be awesome. Thanks! — Chrisahn (talk) 04:11, 26 November 2025 (UTC)[reply]
P.S. I checked my account on a couple of other Wikimedia projects. Page Previews are off for them, and I don't think I turned them off, so it looks like the claim "Is this enabled by default for logged-in users? No." is correct for most other projects. P.P.S. I think I recall that Page Previews were enabled by default on the German Wikipedia a few years ago, but I didn't like them at first and turned them off. Maybe the claim in question is correct for most (all?) projects except enwiki and dewiki? — Chrisahn (talk) 04:18, 26 November 2025 (UTC)if[reply]
Thanks! Another question: The answer below says Page Previews is enabled by default for users registered after 16 August 2017. Was your alternative account registered before this date? Then it would make sense that reset disables Page Previews. I guess it resets the preferences to the original settings for the account, not to the settings a new account would get. Thanks a lot for your answer! — Chrisahn (talk) 15:08, 26 November 2025 (UTC)[reply]
The FAQ seems a bit out of date. The actual configuration can be found here: [6] which says:
Users registered after Popups launch on 16th August 2017 will get page previews and references previews enabled by default. Any user registered before this date will get the value defined in $wgPopupsOptInDefaultState (defaults to "0").
The per-wiki values for $wgPopupsOptInDefaultState can be found here: [7] (on for a few Wikivoyages, off elsewhere)
On a Wikipedia file page like File:Example.png, where it's a file from Commons, if you click the Commons icon in the top right, it currently takes you to the Wikipedia page for that icon, File:Commons-logo.svg. It used to take you to the Commons version of the file you were looking at.
This is possibly a very recent change to a template or the backend, as I only started encountering it yesterday, presumably it being my muscle memory way of navigating to Commons from a Wikipedia file page. archive.org shows that it changed less than a month ago.
Worth changing back, if this is a simple template issue? Few users would want or expect to be taken to the logo SVG page when clicking the icon. Belbury (talk) 10:07, 26 November 2025 (UTC)[reply]
Recently, all international sports federations have been using the names Czechia and Türkyie, instead of the official names Czech Republic and Turkey. That's quite weird. And even weirder, many Wikipedia editors use these names as an additional parameter in sports templates:
And that really annoys me. It would be nice to write an essay on this topic; how to use/not use these name parameters. Alternatively, we could start thinking about modifying the country-data templates. Maiō T. (talk) 13:35, 26 November 2025 (UTC)[reply]
If you do encounter "Türkyie", please change it to "Türkiye", as that's the correct spelling. :-) I'd not recommend changing "Türkiye" to "Turkey" though, at least not where "Türkiye" is the name recognized by the respective sport's main international organization. Before you make such changes, you should discuss them. — Chrisahn (talk) 12:08, 27 November 2025 (UTC)[reply]
Hello, I'm writing on behalf of the Wikimedia Foundation Product Safety and Integrity team. Over the past few months, we have been working on the User Info card. When you tap or click on the "user avatar" icon button next to a username, it displays data related to the user account. It helps access key information that can be helpful while patrolling. The feature is available for all users in preferences as well as global preferences ("User Info" under "Advanced options").
We released the feature on all wikis, saw good feedback and at this point, we believe that we can go further. Enabling it by default for some user groups will make their workflows simpler and more efficient, especially in the temporary accounts world. Specifically in relation to temporary accounts, the User Info card highlights if another user has turned on the ability to view temporary account IPs and provides an estimated number of temporary accounts from associated IP addresses.
We are planning to enable this feature by default for admins, checkusers, rollbackers and Temporary accounts IP viewers (TAIVs). The feature can be easily disabled in preferences.
What does by default mean? Will it be enabled for me too even though I enabled/disabled it in the past? (because popups felt superior, and it doesn't require an extra click!) — DVRTed (Talk) 22:40, 26 November 2025 (UTC)[reply]
Hey, I'm guessing that it'd appear for each user with any of these rights, regardless of whether they've enabled or disabled the preference before or not. But I will ask my colleagues to confirm this. SGrabarczuk (WMF) (talk) 22:52, 26 November 2025 (UTC)[reply]
Oh. I'm sorry, that is unexpected. When I tested that behavior a few months ago, I recall that conditional defaults would not override a locally or globally set preference. KHarlan (WMF) (talk) 11:59, 27 November 2025 (UTC)[reply]
So even greater display of info on registered users, and more secrecy for drive-by anons? Is that really a good direction to be pushing internet social projects? Andy Dingley (talk) 15:48, 27 November 2025 (UTC)[reply]
Hiding IP has made dealing with vandalism and especially political bias (Persistent PoV pushing that's not actionable single-edit vandalism) much harder. Who benefitted from that? Andy Dingley (talk) 16:12, 27 November 2025 (UTC)[reply]
You must have misunderstood the feature being enabled here. It's about providing more info about unregistered editors, and it is providing that info to the listed roles above.
If you are annoyed by temporary accounts, there is plenty of consternation at WP:VPWMF where you may provide feedback. You should move on if you have nothing to say about the specific feature in this announcement. Izno (talk) 16:23, 27 November 2025 (UTC)[reply]
I would like to publicly thank SGrabarczuk (WMF) and the other WMF developers who worked on this feature for listening to the feedback that early testers provided and making changes to the cards in order to make them more accurate. Good work. – Jonesey95 (talk) 17:48, 27 November 2025 (UTC)[reply]
Is there a way to get rid of the million tiny heads that are now cluttering almost every page that has usernames? It's visually utterly useless. --jpgordon𝄢𝄆𝄐𝄇20:05, 27 November 2025 (UTC)[reply]
@Quiddity (WMF): It's pretty bugged at the moment—likely due to the recent changes to .mw-userlink, I assume. Screenshot showing too many user account icons in my watchlist. This is with ?safemode=1. — DVRTed (Talk) 20:23, 27 November 2025 (UTC)[reply]
Perfect, thanks - but in future, can such changes be announced so people can opt in, rather than forcing us all to have it and then try and turn it off? GiantSnowman21:44, 27 November 2025 (UTC)[reply]
I found that the heads are clickable; clicking produces a pop-up box; near the top of that box is a three-dot icon, clicking that generates a menu which has "Turn off this feature", a direct link to the above setting. --Redrose64 🌹 (talk) 22:08, 27 November 2025 (UTC)[reply]
I turned mine off too, via this route. I do use most of the info provided by the box on a regular basis perhaps once or twice a day. If the head icon wasn't so overwhelmingly distracting I might have left them there, but the distraction far far overwhelms the utility of the function. - WalterEgo10:06, 28 November 2025 (UTC)[reply]
I came across an article where another editor had changed various geographical wikilinks from complete wikilinks to piped wikilinks:
[[Roanoke, Virginia]] to [[Roanoke, Virginia|Roanoke]],Virginia and
[[Halifax County, Virginia]] to [[Halifax County, Virginia|Halifax County]], Virginia.
The editor cited WP:GEOLINK as the reason. I know that Geolink states "For a geographical location expressed as a consecutive comma-separated sequence of two or more territorial units, link only the first unit." but the changes just look like a lot of unnecessary piping to me... - Shearonink (talk) 03:53, 27 November 2025 (UTC)[reply]
Saving on Vector appears to display the previous section, with the header hidden under the top bar. It looks like someone has tried to correct the old problem where the section header was just too high to be visible, and made it worse, by displaying the wrong header, also too high to be visible. This has been going on a couple of days now. I thought they would notice that it does not work and revert, but it is still happening. It is more annoying than the original problem and something of a time waster. Cheers, · · · Peter Southwood(talk): 06:49, 27 November 2025 (UTC)[reply]
Can you reproduce this bug consistently on a sandbox page? I've been trying to reproduce it in my own sandbox but I cannot reproduce exactly what you're describing. I can only reproduce a different bug, whereby if two section-headings use identical text, and I edit from the second section-heading, then after saving it will show me the first heading (unexpectedly), but correctly located beneath the window-top (Vector) or the sticky header (Vector-2022).
P.s. Example locations/diffs almost always help a lot, in bug-reports! E.g. I tried looking at your contributions to try to identify where exactly you had encountered the bug, so that I could attempt to reproduce, and because I suspected it might be caused by collapsible templates/tables; however it doesn't seem to be from that, as I see you'd edited freediving before writing this post, and I can't see any obvious causes for scrolling-misalignment (or duplicate headings) in that article. Quiddity (WMF) (talk) 20:37, 27 November 2025 (UTC)[reply]
The edit does exactly what is supposed to do, it is the screen display that comes up on save that is offset. I can't see how I can show you the result that I get if it doesn't happen for you, but I will give it a go. The sticky header on Vector-2022 covers the section header. · · · Peter Southwood(talk): 04:17, 28 November 2025 (UTC)[reply]
I want to change my skin to Vector legacy (2010) but I can't save it at all. All the time the skin is stuck on Vector (2022), even Monobook or other skins don't work. What is the problem? Demigorgen (talk) 09:19, 27 November 2025 (UTC)[reply]
Given your edit is tagged with "Mobile web edit", what you think is Vector 2022 might be Minerva, the mobile skin. If you see "Desktop" at the bottom of the page, click it. Nardog (talk) 09:25, 27 November 2025 (UTC)[reply]
The mw-userlink class is now applied to links to user in edit summaries and the like, making it impossible for gadgets and scripts to rely on the class being only in core interface parts. This potentially affects dozens of scripts. Nardog (talk) 14:41, 27 November 2025 (UTC)[reply]
They apparently wanted to be able to grey-background links to temporary accounts wherever those might appear, and usurped the "mw-userlink" class to do so. It may be worth filing a Phabricator task requesting they bring back a way to find the performing user in a watchlist or Special:RecentChanges row now that mw-userlink can also be applied to the page affected, the diff and history links, and links inside the edit summary. Anomie⚔15:09, 27 November 2025 (UTC)[reply]
Hello! I'm sorry to have caused this issue... Extending the set of cases where mw-userlinks is applied definitely wasn't planned nor needed for the task I was working on (which is adding gray backgrounds to selected temp. user links in content area). For that, we had to change the code that's responsible for adding the user-related classes to the links, and alas, we didn't catch the unwanted change to the scope of mw-userlinks.
The patch to fix the behavior has already been prepared and waits for CI and review. Given that this issue probably isn't a reason for emergency backport (which is the only kind of deployment allowed on Fridays), I expect the fix can be deployed to production on Monday morning.
Again, I'm sorry that this happened. As a person, who's part of the wiki communities, I feel how it is when gadgets break and require fixing. Unfortunately, this time, I'm at the more bitter side of things and I can't help immediately. I'll ensure, though, that the fix lands on production as soon as possible (which is unlikely to be today). MSzwarc-WMF (talk) 08:35, 28 November 2025 (UTC)[reply]
Well, don't be so hard on yourself. In fact I'm pleasantly surprised you're reverting it—most of the time devs are like "tough luck" when this kind of thing happens. Nardog (talk) 13:15, 28 November 2025 (UTC)[reply]
Why are my span.mw-usertoollinks modifier user scripts all messed up suddenly?
Basically, they modify the user tool links "(talk | contribs | block)" next to each user listed on the specific special page or area, and add more links to them to make performing actions much quicker.
Since the end of yesterday, suddenly, they're all completely messing up! They're now adding links to the wrong account or user from someone further up the list, and the scripts are now starting to set the "current_user" to "contribs" instead of the username of the current user to add user look links next to.
I'm stumped! I did make some code improvements to some of the scripts, but all four of them are having problems despite me only updating three of them. Rolling back all of my changes and clearing browser cache, the whole works, made no difference. What's going on? Can someone look at these scripts and maybe tell me if something has changed? They were all working perfectly fine up until when the user cards feature was deployed.
PLEASE HELP! I'd be forever in your debt and eternally grateful for any help, input, or guidance.... :-) (Please ping me in your responses, as I'm currently working on cleaning out my watchlist for being way too full...) ~Oshwah~(talk)(contribs)17:06, 27 November 2025 (UTC)[reply]
DVRTed - Oh, trust me... I'm absolutely not saying that the script I wrote is the best thing in the world code-wise. I happened to see the discussion made right above mine, and it looks like others have already beat me to it with their observations as well. Okay, cool! I'm just really happy to know that it wasn't me that overlooked something and caused these scripts scripts to mess up. My thanks to Izno for nesting my cry for help under the discussion located above this one, and my sincere thanks to you, DVRTed, for taking the time to look through my really shitty JS code... :-) ~Oshwah~(talk)(contribs)19:25, 27 November 2025 (UTC)[reply]
DVRTed - Thank you so much! Ugh... I was educated in C++ when I went to college, which is what I actually have my bachelor's degree in (whether you believe it or not, based off how awful my code is here...). What I need to do is find a resource that will help me to learn and get more familiar with JS and how it all works on the web vs my object-oriented programming mindset that's engraved into my brain. I wish there was something out there that could help me sharpen my skills with JS and with the MediaWiki libraries and built-in variables and functions... Thanks again; I owe you one... :-) ~Oshwah~(talk)(contribs)19:52, 27 November 2025 (UTC)[reply]
@Oshwah Re: I wish there was something out there that could help me sharpen my skills with JS and with the MediaWiki libraries and built-in variables and functions. I found it all very overwhelming when I first started working with MW components, APIs, etc. I learned a lot simply by looking at existing userscripts. I've rewritten your History-Log-Links from scratch with way too many comments, which might be useful for maintaining or debugging this script (and other related ones.) See User:DVRTed/sandbox/temp.js. PS: I hope this gesture doesn't come off as patronizing—this is me genuinely trying to be helpful because it seemed like you could use some pointers. PPS: Happy coding! — DVRTed (Talk) 01:58, 28 November 2025 (UTC)[reply]
DVRTed - Oh hell yes! Thank you for doing this! What you described and what you did for me is exactly what I needed! Looking at existing user scripts, forking some scripts and changing the code in order to customize them to my personal preference, and (at least attempting to) create some of my own scripts is exactly how I've managed to learn some of the MediaWiki libraries and (if anything) just how different JS is than the object-oriented programming mindset that I'm so used to. No, you're not coming off as patronizing or anything like that at all! This is really awesome and extremely helpful to me, and I seriously appreciate it a lot! Thank you. Now I just need to fix the other .mw-usertoollink scripts I wrote (such as this one) so that they work properly as well. If I had working examples of these scripts performing exactly what I intent, it would provide me a lot of good information and learning. I hope this response doesn't come off as me requesting you to spend more time and fix these other scripts as well. Either way, I'll eventually figure it out. Thanks again! :-) ~Oshwah~(talk)(contribs)02:10, 28 November 2025 (UTC)[reply]
DVRTed - Ohhh, SWEET JESUS... You have absolutely no idea how awesome this is and how happy you made me. I almost shook my computer monitor violently in excitement when I looked through that code. I obviously have a shit ton to learn with JS vs C++ (as I've been saying), such as how the value assignment works on line 20 with your constant var declaration, why you put publiclog_link into an array format [publiclog_link] on line 44, what ${variable} does vs just entering variable, how the different built-in tools and functions work, and many many more things. Ugh, I just need to find a resource that can just teach me JS from the very beginning... You made me very happy, and I thank you very much! :-) ~Oshwah~(talk)(contribs)02:29, 28 November 2025 (UTC)[reply]
C++ is generally harder to learn, but understanding certain basics about Javascript makes it much easier to follow, and also certain basics about Javascript running in a browser environment. So I agree with your assessment about finding a good introductory resource :-). (Some key differences off the top of my head: Javascript is garbage collected, and much like Java and other newer languages, its variables can only hold values of a specific set of types or the equivalent of a C++ reference to an object. Thus an object isn't copied when one variable is assigned to another; both variables point to the same object. Although ECMAscript version 5 does introduce the concept of classes, and thus ways to scope symbols within a class, the older versions do not have classes, and the only way to scope symbols is to declare them locally within a function. That's why you'll see Javascript code do things like declare an anonymous function and invoke it immediately, in order to avoid introducing symbols into the global namespace. Javascript does have an interesting inheritance mechanism where each object can hold an object reference to a prototype object that gets searched for a matching property if none exists in the current object. (The prototype object can have its own prototype property; the search will go up the chain until a match is found or there are no more prototypes to search.) I don't believe Wikipedia supports ECMAScript 5 in user scripts so only prototype-based inheritance can be used. In a browser environment, there is a pre-defined window object, and all global variables are properties of the window object.) isaacl (talk) 03:16, 28 November 2025 (UTC)[reply]
I don't believe Wikipedia supports ECMAScript 5 in user scripts so only prototype-based inheritance can be used.: User scripts run on your browser JS engine, and pretty much every modern browser has support for the class keyword. ChildrenWillListen (🐄 talk, 🫘 contribs) 03:27, 28 November 2025 (UTC)[reply]
As I recall, user scripts are validated before being served by the MediaWiki server, and the validator being used doesn't support ECMAscript 5. isaacl (talk) 03:31, 28 November 2025 (UTC)[reply]
Well, I should start using classes, too then :-). As I recall, there was a Phabricator ticket about updating the validator; perhaps it has been resolved. (Or maybe I've confused it with a ticket for ECMAscript 6 support.) isaacl (talk) 03:44, 28 November 2025 (UTC)[reply]
Thanks for the update. Last time I suggested to someone to use "let" they told me it was unsupported, which was the last time I looked into it. isaacl (talk) 04:01, 28 November 2025 (UTC)[reply]
Oh, and $(something) is functionality added by the jQuery library, so you can add reading a basic jQuery tutorial to the list. Nowadays, there is equivalent functionality in the Document Object Model API provided by the browser for a lot (most?) of the jQuery API, but some may still prefer the syntactic sugar of using something like $(".someParentClass .someChildClass") to fetch all matching elements. isaacl (talk) 03:27, 28 November 2025 (UTC)[reply]
It's checking if special_pagename is a truthy value (it would be false on a non-Special page) ANDif the current page name is included in the list of names; if both of these conditions are met, it is a "supported page." (MDN)
const new_links = [publiclog_link]; is so that the publiclog_link is added before anything else; this is to maintain the order from your original script: talk, contribs, publiclog, [ip related links], [other links, i.e, block]. With template literals, instead of something like "Hello " + name + "!", you can simply write `Hello ${name}!`. See https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals that explains it very well. Regards, — DVRTed (Talk) 03:52, 28 November 2025 (UTC)[reply]
Please describe any preferences you may have set (or not set) on the relevant tab(s; RC options can also impact WL) in Special:Preferences. Also ensure that it is(n't) an issue with ?safemode=1 appended. Izno (talk) 18:47, 27 November 2025 (UTC)[reply]
I want to translate and create articles from Persian (Persian Wikipedia) to English. How do I activate the toen wiki tool? What are the article translation tools and how do I activate them? AndisheyAzad (talk) 23:12, 27 November 2025 (UTC)[reply]
Hi, after publishing an edit, its "Edit summary" text is locked and is not modifiable, even for the publisher. This is not good, because publisher may have some typo or forgot some text ideas. I propose to correct the scenario so that only the publisher of an edit would have the ability of modifying an edit's "Edit summary" after publishing that. For example, in this history of article Tehran which is this page, edit summaries are not modifiable. Thanks, Hooman Mallahzadeh (talk) 11:53, 28 November 2025 (UTC)[reply]
@Chipmunkdavis Hi and thanks for your comment. I think this ability improves the "quality of an edit" significantly. A good "Edit summary" is one of the main aspects of an edit (in addition to time, editor name, byte size difference). In addition, I propose that ordinary editors have the ability of modifying "edit summaries" so that if the edit publisher is novice, other editors provide a good summary for that edit. Maybe such edit summary modifications should be logged into a database with a unique id to avoid related confusions. Even though it "has never gained support" I really propose to implement that. Thanks again. Hooman Mallahzadeh (talk) 14:25, 28 November 2025 (UTC)[reply]
but then we have a history of a history, and you you would have to explain the change you mad in another edit summary.. in which you can make a mistake that you need to correct again. —TheDJ (talk • contribs) 14:28, 28 November 2025 (UTC)[reply]
No! In fact, "Edit Summary Modifications" data should be kept in another Table, named "Edit Metadata Modification Table" and each "Edit Table" item should have a pointer which points to "Edit Metadata Modification Table". Then, modifications to edit summary are logged in that "Edit Metadata Modification Table". Hooman Mallahzadeh (talk) 14:34, 28 November 2025 (UTC)[reply]
How can I bypass Cloudflare to archive a site? I can’t archive it because of Cloudflare’s verification issue. (Sorry if this isn’t the right place for technical questions, I don’t know where else to discuss this.) Rafael Ronen08:07, 29 November 2025 (UTC)[reply]
No idea how long this has been going on but {{page needed}} is displaying some odd behaviour. Rather than displaying correctly it display as [, page needed], potentially effecting of tens of thousands of pages[8] -- LCU ActivelyDisinterested«@» °∆t°11:51, 29 November 2025 (UTC)[reply]
Enforce the rule. Right at the top of the {{page needed}} template doc is a message box that tells editors that they should not use {{page needed}} in citation templates. This because {{page needed}} creates this mix of html and wiki markup:
<supclass="noprint Inline-Template "style="white-space:nowrap;">[<i>[[Wikipedia:Citing sources|<spantitle="This citation requires a reference to the specific page or range of pages in which the material appears.">page needed</span>]]</i>]</sup>
Nothing in that mess is a page number or a range of page numbers. Don't corrupt the citation's metadata.
@Trappist the monk: Thanks. The report linked a search with 31,320 results but it doesn't have quotation marks and search ignores special characters so it's the same search as 91 page needed 93 which finds all articles with those words and numbers anywhere. "91 page needed 93" with quotation marks only gives 48 results which could easily be fixed manually. Any volunteer? PrimeHunter (talk) 15:52, 29 November 2025 (UTC)[reply]
When I'm viewing the preview of my edit(s) on my sandbox (when the User sandbox template is there, this message appears), it shows this message at the top:
“This sandbox is in the article namespace. Either move this page into your userspace, or remove the User sandbox template”.
However, when the NAMESPACE template is up there instead, the preview shows nothing — the dialog is gone — but after saving the page, it just displays User.
I think it's time then we allowed the option to opt out of Twinkle messages. To mute users should mean the ability to stop talk page messages from people. I have nothing against Joe and don't have an issue with him prodding articles which genuinely don't have adequate sourcing online, but I don't want to receive the prod notices. ♦ Dr. Blofeld20:41, 29 November 2025 (UTC)[reply]
Twinkle is used for many things, e.g. escalating warnings. Disruptive users shouldn't be able to opt out of that. Others might opt out of Twinkle to avoid one type of post and then miss other types. PrimeHunter (talk) 21:05, 29 November 2025 (UTC)[reply]
I am working on getting 1st Maine Cavalry Regiment out of Category:Harv and Sfn no-target errors and have run into a problem with cite books. As I have been going editing the article I am getting new error messages of "Script warning: One or more {{cite book}} templates have errors; messages may be hidden (help).", one more every time I have fixed a harv cite issue. I apparently do not have a script installed to see what these issues are. Can someone look in on the article and tell me the error? And maybe also what I need to install so I can see the cite book errors as well? Thanks, Shearonink (talk) 18:28, 29 November 2025 (UTC)[reply]
You don't need a script. cs1|2 error messages are visible to everyone unless you have explicitly set your css to hide them (you haven't; at least not in your common.css). The easiest way to find those sorts of errors is to use your browser's find function (ctrl+f in windows) to look to the string (help.
You have hidden the two sidebars that can end up in that space. One of them is the goggles at the top right. One of them is the tools dropdown below the languages dropdown. Izno (talk) 21:46, 29 November 2025 (UTC)[reply]
No, it is by design. Reporting it will simply cause it to be closed immediately. You have been provided the two supported ways to deal with the layout of the page. Izno (talk) 22:02, 29 November 2025 (UTC)[reply]
Yes, and part of their objection was fixed by providing the goggle dropdown. (I don't know if it solved all of their objection.) Izno (talk) 22:33, 29 November 2025 (UTC)[reply]
Looks like you did create the page at one point: you created the redirect (in Special:PermaLink/852535838) by renaming the old version of the page to Glynis Jones (disambiguation). The history doesn't look like it because someone later did some history merging and splitting, which resulted in some of the disambiguation page edits you had moved to be merged with the redirect.Apparently xtools identifies a "creation" by looking for the rev_parent_id field to be 0. I don't know of any straightforward way to reset this (since T183375 fixed preservation across deletion and undeletion). Anomie⚔02:34, 30 November 2025 (UTC)[reply]
View all 24 community-submitted tasks that were resolved last week. For example, the bug which stopped CodeReviewBot from working, has now been fixed. [3]
with this in your CSS: 
