I thought it was for all images. We were having trouble with some images loading because of issues with the thumbnails. The image has to be resized to fit in the infobox.
For Vargas Llosa, if I am reading the template code at {{infobox writer}} correctly, the image is being assigned the default size of frameless, which renders the image at the default thumbnail size width. That width was just increased from 220px to 250px, per the tech note above, after that change had been requested for many years. I see the image rendering at 250px, which means that things are working as designed. (Here are archive.org snapshots of the pages yesterday, 220px image and today, 250px image.) If you are seeing something that does not appear to be working as designed, please describe it here.
Also, the RFC from January 2024, linked to above, says This bifurcated discussion finds a strong consensus to increase the default thumbnail size on English Wikipedia to 250px.
@Neveselbert: Yes, but as noted elsewhere in this section (twice), the width used for |frameless is the same as the width used for |thumb. See demo at Wikipedia:Sandbox, preferably when logged out.
@Neveselbert: They're not independent settings, and AFAIK, never have been. A configuration change for |thumb has been carried out (on 17 April), as a consequence of which the with for |frameless necessarily had to follow suit. If you want them to be divorced, you need to file a ticket at phab:.
Some are set to use frameless and some are set to fixed pixel sizes. Some other common infobox graphics, like maps, can't be set to use the reader's thumbnail size preference, so some editors have chosen to use fixed sizes for images to match the width of maps.
It is even less of an improvement in the case of non-free images like film posters, which are compressed and consequently lack the clarity and detail necessary for comfortable viewing at this higher resolution.
Please link to an example article. Maybe we need to adjust our maximum acceptable size for non-free images. That would be a discussion for a different page.
Honestly, most of them. Though many are worse than others. I realise this is an issue with the files themself but it remains that this change renders these posters looking worse. Comparing png files like the ones at Boyhood (2014 film), Drugstore Cowboy or Good Will Hunting, which are far crisper, or high-res Commons photos like the ones appearing at M*A*S*H (film) or Seven Samurai, to the jpg at Short Cuts, you should see what I mean. Viewing that thumbnail at the original resolution looks better to my eyes. To a lesser extent, the one at Pulp Fiction. Must it be expanded to fill the infobox? Of course this is my opinion and I am not suggesting any actions. But 250px looks worse to my eyes for most posters.
The Short Cuts poster is 19KB and looks like it has been over-compressed. The previous infobox default was reducing it from 255px to 220px wide, and now it is being reduced to 250px, which highlights the over-compression. Someone needs to upload a better-quality image. The Good Will Hunting image is the same pixel size but is 231KB. That's probably why it looks better.
@Jonesey95 Film posters should be resized to 0.1 megapixels, which, for a standard 3:2 poster, means 258x387 (although they generally range from 254x393 to 260x384). We don't need to update the maximum size, but rather set the resizing bot to prefer a width of 250px if the final image is going to be close to that value to avoid unnecessary rescaling.
It depends upon the infobox. Some are coded to use a specific size; others are coded for the frameless type, which should read the user's preferences. No infobox should be coded to use the thumb type, because of the extra borders that produces.
I see the time, it’s in the upper right corner. But it is in UTC, amd should be one hour forward for Daylight Saving Time. It shows 17:16 instead of 18:16
@Doug Weller: If you see time in the upper right corner then you probably enabled "Add a clock to the personal toolbar that displays the current time in UTC" at Special:Preferences#mw-prefsection-gadgets. It's meant to be UTC as it says. Signatures are saved as wikitext in UTC but you can enable "Change UTC-based times and dates, such as those used in signatures, to be relative to local time" at Special:Preferences#mw-prefsection-gadgets. The timezone preference at Special:Preferences#mw-prefsection-rendering is only for time logs like in the watchlist, page histories and user contributions.
@Doug Weller: If it's the clock then add window.LiveClockTimeZone = 'Europe/London'; //LiveClock timezone settings to your common.js page. That should make it display BST for you now and it will autocorrect when the clocks go back.
Infobox parameters have to be implemented in the used infobox template. Frooti uses Template:Infobox Beverage which has no such parameters so they are ignored. See the template page for supported parameters.
For reference, the line of CSS I gave is the same exact thing but with 200% the spaces. Though, I also just changed my line of CSS to say "sticky-decoration" instead of "floating-decoration".
There was no opposition to the suggestions of creating a gadget to opt-out and for other editors to edit user pages to implement the class, but these issues did not have significant discussion. does not support the creation of a gadget, so I suppose you're taking up the suggestion? A one liner isn't really what we should support gadgets for, and it really is a one liner.
Normally I would agree with you. I think that telling people, in an official guideline, to go and check a box in their preferences is far superior to telling them to fiddle with their CSS. Best,
Just curious, but the RfC was about user pages, but are there any legitimate uses of these "position: <absolute|sticky|fixed>;" elements elsewhere? I know I have been meaning to get the up/down skip buttons used on WP:HD and WP:TEA adjusted so they don't obscure the mobile/desktop toggle.
Support, I guess. Though, this seems like a fool's errand, as editors can and will create new elements regularly, and these won't be with the class sticky-decoration (or whatever class name), so the gadget will do nothing.
The new section (WP:DecoFloat) created by that RfC which thus is now a guideline says that such new elements should have that class, and another thing unopposed (though not really discussed) in the RfC is that editors should be able to drive by and add the class. I'm sure opt-outers would gnome every example of such stickies.
That's all fine. As an editor who fixes lint and other errors, I doubt most people that add those annoying features are going to add the class, which then falls upon gnomes and other editors to fix those horrible features. So we require at least two steps for editors to not view these, and yet still non-registered users can't hide them.
I feel like most of this was already discussed in the RfC. There's no independent merits you've brought up that only apply to the gadget proposal and not the RfC.
If the usage on user pages is deemed a significant accessibility issue, then personally I think the elements in question should be hidden by default, and users can opt into seeing them. If there isn't enough usage to make it a significant accessibility issue, then I think the drawback of adding an additional gadget isn't warranted.
Managing accessibility concerns is about managing tradeoffs. Neither approach is perfect. In my opinion, if the accessibility issue is significant, then the better tradeoff is to let people opt into the problem, rather than opt out of it.
Just raising a specific point regarding the relative tradeoffs for managing accessibility, which was not discussed during the previous RfC. (As noted in the summary, detailed discussion of a gadget did not take place.)
It's only a significant issue for a significant but small percentage of users; I think it's worth the drawback (I presume you just mean the preferences table and the in-this-case-tiny burden on intadmins). The significant drawbacks of having such elements be hidden by default have been discussed in the RfC.
Since we're apparently doing the bold-face thing, I support making this into a gadget. If anyone thinks it should be default-on, we can have an RFC about that later. In the meantime the gadget will help those who wouldn't know display: none; from background: url(https://fsb.ru/1x1.png) enable an accessibility feature without worrying.
Conditional highlighting in a tableWhatamIdoing (talk) 3 days ago
This clever edit causes the most relevant line to be highlighted, e.g., in Butter#Nutritional information. However, in Shortening, to which Vegetable shortening redirects, the relevant line is not highlighted, because it's not at the "Vegetable shortening" page (not all shortenings are vegetable shortenings, but most of them are). Could someone please hard-code the page name "Shortening" into this template?
The title for Eileen Kelly appears to be automatically italicised for me on my mobile device; this seems to have happened when the podcast infobox was added to the article. Can anyone help?
The problem was that the podcast infobox ({{Infobox podcast}}) automatically italicizes the article’s title (since it assumes it’s on the article of a podcast). I’ve fixed this by adding | italic title = no to the template.Hope this helps!
If you go to the "View history" page, you can see a list of the edits. Click on the previous version in the left column of dots and the latest version in the right column of dots, then click "Compare selected versions". From that screen, you can see the changes that you made and click the "undo" link to restore the previous version. I did it for you this time.
@SergeWoodzing: Regarding [1], {{stack}} should only be used around right-floating elements. If they are not consecutive in the source then move them. This works.
As you see on this page, I've reported that I've lost access to Newspapers.com in the Wikipedia Library. As reported there, I originally lost access early last year when Newspapers.com made some sort of change and I was granted access that was to expire November 17 of this year. I've reapplied anyway, but I've heard nothing in about a week. What should I do to regain access?
@Maile66: It gave me this message: Your access to XTools has been blocked due to apparent abuse or disruptive automation. I find this to be very weird, since I edited last week with no trouble. And I have no need to edit XTools, so I do not understand why I am being blocked. Also the village pump over their did not even talk about me.
Update from the relevant task (phab:T384711): as the other times XTools went down, it was the fault of bot(s) making way too many queries and making the service run out of disk space.
The issue is that this bot is IP-hopping, so blocking only it was not straightforward.
I've reported the false positive. Maybe the blocking filter can be tweaked, who knows.
I have removed the block as the disruptive bots seem to have stopped for now. @Catfurball You shouldn't be seeing that message anymore. Sorry about that.
I'm not sure what to do long-term. A permanent solution is to always require login, then bad botz go bye-bye once and for all. But then everyone has to login, which I know is annoying, especially with known issues such as phab:T224382.
Alternatively, could require login just when you need to deflect the bad bots, or require login just when it appears someone is a bad bot (like what WMF is doing now I guess for login).
Yes, sorry. The flood of bot(s) came back again and I had to do the quick fix. I'm afraid even adding an OAuth login wall won't fix the problem. The sheer volume of automated traffic coming in necessitates blocking traffic at the server level. I will work with some folks to get this sorted out as soon as possible. In the meantime, using a different browser might help.
Despite what I said above, it appears the main issue is the volume of requests (up to 300+ a second). XTools was actually doing its job of preventing the bots from running any queries, for those few requests that actually managed to make it to the application layer.
How it happened: so when I replied to that thread, it automatically subscribed me, but the [subscribe] link suggested that I wasn't subscribed to the conversation.
What I did after posting this: I unsubscribed to both topics, and then subscribed manually again, and that seemed to fix the issue.
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
Wikifunctions is now integrated with Dagbani Wikipedia since April 15. It is the first project that will be able to call functions from Wikifunctions and integrate them in articles. A function is something that takes one or more inputs and transforms them into a desired output, such as adding up two numbers, converting miles into metres, calculating how much time has passed since an event, or declining a word into a case. Wikifunctions will allow users to do that through a simple call of a stable and global function, rather than via a local template. [2]
A new type of lint error has been created: Empty headings (documentation). The Linter extension's purpose is to identify wikitext patterns that must or can be fixed in pages and provide some guidance about what the problems are with those patterns and how to fix them. [3]
Following its publication on HuggingFace, the "Structured Contents" dataset, developed by Wikimedia Enterprise, is now also available on Kaggle. This Beta initiative is focused on making Wikimedia data more machine-readable for high-volume reusers. They are releasing this beta version in a location that open dataset communities already use, in order to seek feedback, to help improve the product for a future wider release. You can read more about the overall Structured Contents project, and about the first release that's freely usable.
There is no new MediaWiki version this week.
Meetings and events
The Editing and Machine Learning Teams invite interested volunteers to a video meeting to discuss Peacock check, which is the latest Edit check that will detect "peacock" or "overly-promotional" or "non-neutral" language whilst an editor is typing. Editors who work with newcomers, or help to fix this kind of writing, or are interested in how we use artificial intelligence in our projects are encouraged to attend. The meeting will be on April 28, 2025 at 18:00–19:00 UTC and hosted on Zoom.
Issue using labeled section transclusion (LST)Alex 21 (talk) 2 days ago
At List of Vikings episodes, I have <section begin=Amazon6B />{{efn|The second half of the sixth season concluded on December 30, 2020, when it was released in its entirety on Amazon Prime Video in select countries, ahead of its standard broadcast on History in Canada from January 1 to March 3, 2021.}}<section end=Amazon6B />. At Vikings (TV series) (and other articles), I'm trying to use {{#lst:List of Vikings episodes|Amazon6B}} to use the same note without duplicating it through transclusion, but it is returning empty (see the source code for this post, I'm using that same code after the colon: [a]). What appears to be the issue?
@Alex 21:List of Vikings episodes#Series overview uses <onlyinclude>...</onlyinclude> to control transclusion at Vikings (TV series)#Broadcast. It means {{#lst:List of Vikings episodes|Amazon6B}} also only sees the part inside <onlyinclude>...</onlyinclude>. onlyinclude is the standard method used to transclude such a series overview from an episode list to the main article about the TV series. Article content is rarely transcluded so it doesn't usually cause a conflict.
Collaboration or task tracker utilityGryllida (talk) 1 day ago
In a wiki project, I need to ping many users to work on a new draft. One of them takes it. Others need to be unpinged somehow. (like in phabricator: tag a task with "foobar", all members of foobar group get a notofication, one of them marks it as assigned to themselves, and others know that it already taken. There is a board showing list of untaken tasks.) Is there some such mechanism on-wiki? Thanks.
so I have been building an application to check suspicious links. I want it to list all external links on the page on a menu like twinkle but I don’t understand how to implement 00ui more than the alert menus. Any help would be appreciated
@Cyberwolf You can take a look at User:Ahecht/Scripts/pageswap-core.js (starting at about line 1305) for an example of how I populate the psReasonList and psWatchExpiry and in an OOUI form, but honestly for drop-down lists I much prefer to use something like Select2, like I do in the showRcatDialog() function of that script, or jquery.chosen, like I do in User:Ahecht/Scripts/draft-sorter.js.
so I've been trying to use { {Userbox |border-c=#006666 |border-s=2 |id-c=#008080 |id-s=10 |id-fc=#99FFFF |info-c=#008080 |info-fc=#99FFFF |id=Teal |info=This user's favourite colour is teal}}. I've been trying to add a white line between the box and the text but I cant find the part on the wikicode that lets me do that. possible (talk page stalker)
Now that Module:European and national party data and its templates (EUPP data, Political party data, and EU institution seats) are working and starting to be deployed, I am interested in translating them across wikis. I have already created the relevant modules, config files and templates, but results differ widely from one wiki to the other (see the test pages listed on the roadmap).
For now, PT alone works, NL works except composition bars, and for all others Wikidata qIDs are returned instead of values and composition bars don't work (ES is entirely broken). I assume this is because the wikidata/wd and composition bar modules are called differently from one wiki to the next.
What is the best way to move forward with this? Should a function take arguments and give out the right wikidata/wd/composition_bar calls with an IF based on the language used? Should we use the config file? Any ideas?
ERRORTypeError: Load failedCyberwolf (talk) 8 hours ago
I keep getting ERRORTypeError: Load failed after trying to retrieve data from virus total for my script I don’t know what to do to fix this
@Cyberwolf First problem is that the API address should end with "urls", not "url". Beyond that, you may run into CORS errors since VirusTotal doesn't send CORS headers, so you may have to run the API calls through a CORS proxy hosted somewhere like toolforge.
@Cyberwolf I'd start by reading the toolforge documentation. There are many possible implementations, but a quick google search shows that cors-anywhere is popular. You'd need to follow the instructions at wikitech:Help:Toolforge/Node.js to set up a Node.js webservice and then install cors-anywhere. There are third-party CORS proxies available, but it's a security risk to use them because they could theoretically rewrite any of the returned data, steal your API key, etc.
I have seen this format on User talk pages, from other users asking questions about Wikipedia. Is this coming from a mentorship program, or from the Talk page owner having signed up somewhere as a volunteer newbie-helper, or where exactly? There are many such queries at this User talk page, with ten appearing this month and destined never to be answered, most likely, as this user last contributed in March.
For the sake of other users needing answers to their questions, I would like to sever whatever connection this user has to some question-answering service, at least until the user comes back. But where is the connection? Just paging Sage (Wiki Ed) in case this is something from the Wikipedia Education program, but I don't think so. If not, then who? Thanks,
This is coming from w:WP:Growth team features#Help panel. Any admin can mark them as "away" via Special:ManageMentors, which I've now done and should cause questions to be directed to other more active users instead. There needs to be a more systematic process to handling this, though - I've been manually marking inactive users as away whenever I get around to it, but I'm using a way too loose definition of "away" and shouldn't be the only person doing essential tasks,.
Thanks for helping with this, @Pppery! I agree—it would be great if the Mentorship system automatically removed inactive Mentors. While the WMF Growth team has been focused on other priorities, I’m hoping to make time soon to work on some of the top mentorship-related tasks. Here are a few that come to mind:
Feel free to chime in if you have any thoughts on the top priorities for improving Mentorship. And thanks again for assisting with so much of the essential work behind the scenes!
The particular editor you pointed out here is still around and about, incidentally.
There may be an extension feature request to reassign mentees automatically after some arbitrary activity date, and/or mark as inactive, or whatever else you can do in the panel (as measured by things in Special:Contribs). I guess we could spin up an admin bot for it.
View all 37 community-submitted tasks that were resolved last week.
Why are infobox image sizes huge now?
Neveselbert (talk) 6 days agoSee Mario Vargas Llosa and Margaret Thatcher, for example. This really isn't an improvement.
Jlwoodwa (talk) 6 days agoSee the weekly highlight above in § Tech News: 2025-16
Neveselbert (talk) 6 days agoThis is clearly a bug. This change should only affect thumbnails, not infobox images.
Hawkeye7 (talk) 6 days agoI thought it was for all images. We were having trouble with some images loading because of issues with the thumbnails. The image has to be resized to fit in the infobox.
Neveselbert (talk) 6 days agoThere was no consensus here to increase the default size for all images, only for thumbnails.
Sjoerddebruin (talk) 6 days agoThe templates should be updated then, they just follow the default setting.
Jonesey95 (talk) 6 days agoFor Vargas Llosa, if I am reading the template code at {{infobox writer}} correctly, the image is being assigned the default size of
frameless, which renders the image at the default thumbnail size width. That width was just increased from 220px to 250px, per the tech note above, after that change had been requested for many years. I see the image rendering at 250px, which means that things are working as designed. (Here are archive.org snapshots of the pages yesterday, 220px image and today, 250px image.) If you are seeing something that does not appear to be working as designed, please describe it here.Jonesey95 (talk) 6 days agoAlso, the RFC from January 2024, linked to above, says
Neveselbert (talk) 4 days agoInfobox images are not thumbnails though. They use
frameless, notthumb.Redrose64 (talk) 4 days ago@Neveselbert: Yes, but as noted elsewhere in this section (twice), the width used for
|framelessis the same as the width used for|thumb. See demo at Wikipedia:Sandbox, preferably when logged out.Neveselbert (talk) 4 days agoIn which case, the width used for
framelessshould be restored to 220px pending consensus.|thumbhas been carried out (on 17 April), as a consequence of which the with for|framelessnecessarily had to follow suit. If you want them to be divorced, you need to file a ticket at phab:.Matma Rex (talk) 6 days agoInfobox images are thumbnails, are they not? I had my thumbnail size set to 300px in Special:Preferences#mw-prefsection-rendering-files for years, and it always affected infoboxes too.
framelessand some are set to fixed pixel sizes. Some other common infobox graphics, like maps, can't be set to use the reader's thumbnail size preference, so some editors have chosen to use fixed sizes for images to match the width of maps.Οἶδα (talk) 6 days agoIt is even less of an improvement in the case of non-free images like film posters, which are compressed and consequently lack the clarity and detail necessary for comfortable viewing at this higher resolution.
Jonesey95 (talk) 6 days agoPlease link to an example article. Maybe we need to adjust our maximum acceptable size for non-free images. That would be a discussion for a different page.
Οἶδα (talk) 6 days agoHonestly, most of them. Though many are worse than others. I realise this is an issue with the files themself but it remains that this change renders these posters looking worse. Comparing png files like the ones at Boyhood (2014 film), Drugstore Cowboy or Good Will Hunting, which are far crisper, or high-res Commons photos like the ones appearing at M*A*S*H (film) or Seven Samurai, to the jpg at Short Cuts, you should see what I mean. Viewing that thumbnail at the original resolution looks better to my eyes. To a lesser extent, the one at Pulp Fiction. Must it be expanded to fill the infobox? Of course this is my opinion and I am not suggesting any actions. But 250px looks worse to my eyes for most posters.
TheDJ (talk) 6 days agoI remember predicting this exact situation when the non-free content policy, limiting the size, was made.
Ahecht (talk) 6 days ago@Jonesey95 Film posters should be resized to 0.1 megapixels, which, for a standard 3:2 poster, means 258x387 (although they generally range from 254x393 to 260x384). We don't need to update the maximum size, but rather set the resizing bot to prefer a width of 250px if the final image is going to be close to that value to avoid unnecessary rescaling.
framelesstype, which should read the user's preferences. No infobox should be coded to use thethumbtype, because of the extra borders that produces.