If you want to report aJavaScript error, please followthis guideline. Questions aboutMediaWiki in general should be posted at theMediaWiki 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. Seetask 3864. There is anaccesskey property on it (default toaccesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadgetin their preferences.
No, we will not add a spell-checker, or spell-checkingbot.
You can use a web browser such asFirefox, which has a spell checker.
If you changed to another skin and cannot change back, usethis 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, trypurging 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 blockURLs 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’sReader Growth team. A few weeks ago, WMFposted 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 insurveys 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.
Our initial discussions with you constitutedphase 0 of our reader experiment phases. We now want to enterphase 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 intoPhase 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 thefeedback 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 thetag 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 availableon 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 ourlegal 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 ourproject 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 theLegal 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 beSigma'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 someload more button on the right of the images panel to load more images from the Commons category (e.g. first files that in adeepcategory: 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]
@Timrollpickering It looks like itwas that recent edit, you just needed to wait a bit for the category to clear (there was a recent Tech News item about some backend changes that result in delayed category updates).{{User x}} checks if the category exists before placing the template there, so ifCategory:User en-gb-3 were deleted it wouldn't be a problem. That being said, the real solution would be to not have different capitalization between the template and the category, and I would suggest doing a mass-move on the en- templates to capitalize them.--Ahecht (TALK PAGE)14:15, 20 November 2025 (UTC)[reply]
Unfortunately it's still there; I don't know if this is because of another user making a needless edit about whitespace. These language categories are a total pain in the backside with a lot of inconsistency (only en-GB and en-CA seem to be capitalised) and some off site stuff that isn't maintained well. Is there a simple way to zap the problems once and for all?Timrollpickering (talk)22:00, 20 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 atang: 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 byKrinkle 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 isenabled 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 inT408741 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 purgeang:Heafodtramet. (It will also purgeang: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]
Spur (the company from which we source IP Proxy information used by various tools) gave a webinar yesterday. Therecording is available on-line It's a little bit promotional, but I found lots of good information about how the residential proxy ecosystem works that I didn't know before, so if you do anything with blocking of IPs, it's probably worth watching.RoySmith(talk)15:35, 21 November 2025 (UTC)[reply]
I came across theOtago article atthis version and noticed that the extended footnote after the first word of the lead, which addresses pronunciation and the name of the area in Maori, wasn't appearing at the bottom of the article. I noticed that there wasn't a{{notelist}} tag at the bottom, so I added one but, when I previewed the result, the list still didn't appear. Investigating, I found that there was a{{notelist}} tag at the end of the first table of the Population section, evidently meant for displaying an extended footnote for the first data row, Dunedin, so both notes were being displayed there. I tried to solve the problem by setting distinct|group= parameters for each of the{{efn}}s, and setting the corresponding|group= parameters for the{{notelist}}s. But that didn't work: the two notes still both appear under the table, and the{{notelist}} in the Notes section I created at the bottom, above the References section, is empty. I saved my work underthis diff. Can someone see what's preventing the breakdown by group from occurring?Largoplazo (talk)18:55, 21 November 2025 (UTC)[reply]
{{efn}} only recognizes the following values for|group=: note, upper-alpha, upper-roman, lower-alpha, lower-greek, and lower-roman. Anything else defaults to lower-alpha. You tried to use "main" and "pop".Anomie⚔22:55, 21 November 2025 (UTC)[reply]
Ahhhh. I hadn't grasped that the distinction had to be based on the numbering scheme. That's a little bizarre, actually, seems to me they should be independent dimensions, say, if you have 15 tables and want each to list its own set of notes at the bottom—and have them styled consistently, each starting from the beginning. But that's beside the point here. Thanks.Largoplazo (talk)03:25, 22 November 2025 (UTC)[reply]
@Largoplazo: You can have multiple notelists, each using the same style and each with its own sequence, provided that where there are two in parallel, they use different styles. Consider this:
Text in article lead.{{efn|Note relevant to text in the lead}}==Section one==Table row 1{{efn|group=lower-roman|Note for section one, table row 1}}Table row 2{{efn|group=lower-roman|Note for section one, table row 2}}{{notelist|group=lower-roman}}==Section two==Table row 1{{efn|group=lower-roman|Note for section two, table row 1}}Table row 2{{efn|group=lower-roman|Note for section two, table row 2}}{{notelist|group=lower-roman}}==Notes=={{notelist}}
Now I see—in my version, both were consumed by the first notelist because everything was being treated as lower-alpha, so both footnotes got captured there. Cool, thanks!Largoplazo (talk)01:12, 23 November 2025 (UTC)[reply]
Old talk page discussions left behind during multiple page moves
Hi all, the articleAl-Marwani (current title at time of writing) was created in September, initially as a draft. The draft was then moved to mainspace by its creator and has been moved again over a dozen times since. Along the way, at least two different talk page discussions have been left behind with former page titles instead of following the article's moves to the most recent titles; specifically,here at the draft talk andhere at one of the former titles. I'm not sure how this happened, but in any case I'm wondering if there's a way to move/restore those talk page discussions to the article's current talk page? Is there a better way to do this now other than just copy-pasting the discussions? Thanks,R Prazeres (talk)07:30, 22 November 2025 (UTC)[reply]
@R Prazeres: Done in an administrator-only way which preserves the page history on the same talk page. There were 25 redirects to the article. I checked that only the two mentioned had other talk page content than redirects.PrimeHunter (talk)11:31, 22 November 2025 (UTC)[reply]
There were a lot of recent undiscussed changes toTemplate:Merge,Template:Merge from andTemplate:Merge to, mostly byFaviFake (talk·contribs), who made insufficient prototyping in the template sandboxes, and didnot use the testcases pages at all. I've reverted the template changes, and raised the protection to Template-protected. Honestly, I could have blocked FaviFake outright for breaching a final warning not to mess about in highly-visible pages without discussion. I might still do that. --Redrose64 🌹 (talk)10:58, 23 November 2025 (UTC)[reply]
{{{case: ~ }}} would mean the value of the template parameter namedcase: ~.{{{case: {{{1|}}}}}} would mean the value of a template parameter whose name is based on the value of parameter1.That very old template was intended to be used something like{{switch|value | case: a = something | case: b = something else | case: c = etc | default = a default value }}, and the{{{case: {{{1|}}}|{{{default|}}}}}} handled selecting the appropriate named parameter based on the passed invalue. These days we havemw:Extension:ParserFunctions that lets the same thing be done more efficiently (and with slightly different syntax) using#switch.Anomie⚔16:08, 23 November 2025 (UTC)[reply]
Minerva not showing edit count and user groups for certain users (?)
I didn't know this mobile feature which was poorly described. CompareSpecial:Diff/1323787535 by Izno andSpecial:Diff/1323780893 by Theknoledgeableperson in the mobile version in a narrow window. The bottom of the Izno diff has an up-arrow which displays "148,425 edits | 3 user groups" and a circled "i" icon to show the groups. The Theknoledgeableperson doesn't show any of this. Tests with other users show that you only get the info if the user has at least one user group (which may be extended confirmed). It makes some sense to not write "0 user groups". I don't know why the edit count is omitted in that case but it may be deliberate.PrimeHunter (talk)20:38, 23 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]
{{MusicBrainz meta}} (should that really be used in the article? – meta templates generally aren't suitable for mainspace) doesn't support|ref=. You might rewrite that reference as:
Latesttech 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, theWikimedia 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 forcxfcnmt 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 inDiscussionTools. 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 asCollaborative contribution to help organizers and participants see the impact of activities has also been added. Join the upcominglearning session to see the new feature in action and share your feedback.
View all 24 community-submitted tasks that wereresolved 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 therecruitment survey.[4]
The MediaWiki Interfaces team is deprecating XSLT stylesheets within the Action API. Support forformat=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 orhttps://query-scholarly.wikidata.org/ - Scholarly graph). For support with migrating use cases, please review theData Access andRequest 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, thegraphics 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 fromHexadecimal clock and truncated by way of showing thehex 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 atHelp 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 likeFile: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]
Hello, I'm writing on behalf of the Wikimedia FoundationProduct Safety and Integrity team. Over the past few months, we have been working on theUser 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 inpreferences 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 foradmins, 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]
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]
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]
