Commons:Village pump/Technical

Welcome to the Village pump technical section

Technical discussion
Village pump/Technical
Bug reports
Code review
Tools
Tools/Directory
Idea Lab

This page is used for technical questions relating to the tools, gadgets, or other technical issues about Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; recent archives: /Archive/2025/01 /Archive/2025/02.

Please note

Feature or bug reports should be filed on Phabricator (see how to report a bug). Bugs with security implications should be reported differently (see how to report security bugs).
Have you read the FAQ?

Start a new discussion

	SpBot archives all sections tagged with {{Section resolved\|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.

Twinkle

Hello, I’ve noticed that some files have been created solely for advertising purposes. When I used Twinkle to request speedy deletion under criterion G10, the tool displayed the message: "Tagging page: The edit was disallowed by the edit filter: 'Protect page section headings'." I’m unsure what this means, and in this case, the tool wasn’t able to apply the speedy deletion template. I would greatly appreciate it if you could help clarify this for me. Thank you so much, and have a nice day! P. ĐĂNG (talk) 07:43, 3 January 2025 (UTC)[reply]

You tried to replace the hole page content with the speedy deletion template. All deletion templates have to be added at the first line of the page content and the content must not be removed. GPSLeo (talk) 10:15, 3 January 2025 (UTC)[reply]

Just because something was upladed for advertising purposes does not mean that it is not usable. --MGA73 (talk) 18:19, 27 January 2025 (UTC)[reply]

UploadWizard mistaking license on Flickr uploads

So earlier I used my alt account to upload this file (https://www.flickr.com/photos/presidenciaecuador/54268607515/) with UploadWizard, and when I finished and clicked the file page open the license it showed was PD-US instead of the normal CC0 license on Flickr. Special:Diff/985808004. Did anyone else encounter this as well? Not sure whether it is related to the earlier cases of UploadWizard messing up licenses above. 沪A 05683D_S5A-0043 07:34, 21 January 2025 (UTC)[reply]

That file is licensed on Flickr as PDM, not CC0. I don't think Upload Wizard was ever updated to reflect that licensing. The correct license tag is {{PD-author-FlickrPDM}}, which I add manually whenever I have time to revisit such uploads. RadioKAOS / Talk to me, Billy / Transmissions 07:45, 21 January 2025 (UTC)[reply]

Oops, read wrongly (facepalm). I’m pretty sure UploadWizard does have the PDM though-or at least back in 2023 when I uploaded this file. 沪A 05683D_S5A-0043 09:58, 21 January 2025 (UTC)[reply]

So is this issue solved? Prototyperspective (talk) 15:33, 26 January 2025 (UTC)[reply]

Not quite. See Special:Diff/990789717 which I newly uploaded. S5A-0043🚎^{(Leave a message here)} 09:19, 31 January 2025 (UTC)[reply]

Tech News: 2025-05

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

Patrollers and admins - what information or context about edits or users could help you to make patroller or admin decisions more quickly or easily? The Wikimedia Foundation wants to hear from you to help guide its upcoming annual plan. Please consider sharing your thoughts on this and 13 other questions to shape the technical direction for next year.

Updates for editors

iOS Wikipedia App users worldwide can now access a personalized Year in Review feature, which provides insights based on their reading and editing history on Wikipedia. This project is part of a broader effort to help welcome new readers as they discover and interact with encyclopedic content.
Edit patrollers now have a new feature available that can highlight potentially problematic new pages. When a page is created with the same title as a page which was previously deleted, a tag ('Recreated') will now be added, which users can filter for in Special:RecentChanges and Special:NewPages. [1]
Later this week, there will be a new warning for editors if they attempt to create a redirect that links to another redirect (a double redirect). The feature will recommend that they link directly to the second redirect's target page. Thanks to the user SomeRandomDeveloper for this improvement. [2]
Wikimedia wikis allow WebAuthn-based second factor checks (such as hardware tokens) during login, but the feature is fragile and has very few users. The MediaWiki Platform team is temporarily disabling adding new WebAuthn keys, to avoid interfering with the rollout of SUL3 (single user login version 3). Existing keys are unaffected. [3]
View all 30 community-submitted tasks that were resolved last week.

Updates for technical contributors

For developers that use the MediaWiki History dumps: The Data Platform Engineering team has added a couple of new fields to these dumps, to support the Temporary Accounts initiative. If you maintain software that reads those dumps, please review your code and the updated documentation, since the order of the fields in the row will change. There will also be one field rename: in the mediawiki_user_history dump, the anonymous field will be renamed to is_anonymous. The changes will take effect with the next release of the dumps in February. [4]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 22:11, 27 January 2025 (UTC)[reply]

Regions of Belarus

Hi! Could you help with the module for categories by year for regions of Belarus, Kazakhstan, Uzbekistan, Kyrgyzstan and Tajikistan on {{Region year}}? This is the equivalent of the template {{Oblast year}} for Russia and Ukraine. MasterRus21thCentury (talk) 20:23, 29 January 2025 (UTC)[reply]

Category for City by year

How do I go about creating or editing a new category for a city/town by year? For example, when viewing Category:Oshawa by year, select 2024 for example and hit 'Edit' all you can see is "CanadaYear|Oshawa|202|4" which automatically adds the bar at the top to filter by year and categories. Is there a template somewhere? PascalHD (talk) 20:46, 1 February 2025 (UTC)[reply]

Creator Possible error

Unless I'm missing something, it seems that Template:Creator possible isn't properly putting things in Category:Creator templates to be created by a bot when it should be. ToxicPea (talk) 04:42, 2 February 2025 (UTC)[reply]

"Defective" files

There's an issue with a lot of video files on Commons where, if a video file does not have metadata associated with it, it shows as "0.0s" in length. This issue's intensity can vary from the video file being watchable but not entirely technologically readable across WMF projects, to a video file not even being able to skip forward, but only play in one go.

I think this is probably some kind of bug in the Wikimedia video software. If a file was not given metadata, you can fix this by using the following FFMPEG command in your terminal. For example:

ffmpeg -i The_Crisis_\(1916\).webm -metadata title="The Crisis" -metadata year="1916" -metadata artist="Colin Campbell" -metadata genre="Drama, Historical" -metadata description="A silent historical drama film directed by Colin Campbell, based on the novel by Winston Churchill." -metadata comment="Silent film classic from 1916." -c copy The_Crisis_\(1916\)_metadata.webm

I feel like any bogus data being thrown in there should be fine. I did this for File:The Crisis (1916).webm and the issue was fixed immediately.

This issue, with "defective" files (that are in my opinion not fully defective but the software treats them as if defective) can lead to video files being dangerously deleted, such as File:Old Ironsides (1926).webm once was, before I saved it with a higher quality version. This sets a precedent for these "0.0s defective files"—of films that are often quite rare finds and may no longer exist anywhere but Commons!—to be simply speedied without notice.

I think the solution to this problem is to add to the list of Commons bots a "fix defective file bot", that simply adds some metadata to the video file (possibly based on what's in the Commons description or just random data), so that the number of files with this problem doesn't keep building up. Or, we could fix the WMF video technology, to where the backend automatically populates the metadata of a metadata-less file.

At the very least, is there a category that keeps up with files listed as "0.0s"?

Nevertheless, this is a recurring issue, and I want to see if there's some way to fix this problem quickly using a systemic method (bots, site code, etc.)? Pinging @Racconish and Yann: who have noticed video files with this kind of defectiveness before as well. SnowyCinema (talk) 16:28, 2 February 2025 (UTC)[reply]

The solution is either a solid investment of hardware, software and staff in being able to handle video decoding in a more efficient way or stop uploading video all together. This is such a recurring topic and we're just wasting resources at the moment. Sjoerd de Bruin (talk) 17:51, 2 February 2025 (UTC)[reply]

‘-i---i-’ prefix in filenames

I happened to see the ‘-i---i-’ prefix in filenames in different contexts, so I had a look. There seem to be a lot of files where their names all start with ‘-i---i-’ and they were all uploaded using Flickr2Commons, but they are otherwise unrelated. What’s going on? Brianjd (talk) 07:11, 3 February 2025 (UTC)[reply]

Probably some bad import from the Flickr. I ocasionally rename some of these files, but it's a Sisyphean work. Some bot action would be really appreciated, e.g. renaming the files with the Description field as a filename. — Draceane ^talk_contrib. 09:07, 3 February 2025 (UTC)[reply]

Hello @Brianjd

If you come across such files and have a better description of what the image represents, please suggest a rename. Greetings זיו「Ziv」 • For love letters and other notes 04:06, 4 February 2025 (UTC)[reply]

@Ziv: I will (for files I care about enough), but that’s sort of missing the point. The question is not what to do with these filenames (we all agree they should be changed), but where they come from in the first place. Brianjd (talk) 06:39, 4 February 2025 (UTC)[reply]

I'm not sure where the precise string "-i---i-" comes from, but it usually seems to show up on untitled Flickr images, e.g. File:-i---i- (50282028261).jpg was imported from this untitled photo. It'd be nice if Flickr2Commons could be a little pushier about requiring users to enter titles for these imports. Omphalographer (talk) 00:08, 7 February 2025 (UTC)[reply]

@Omphalographer: Yes, that does seem to be it. Sometimes it is even worse: -i---i- (32552103431).jpg has no title and also has no description. Brianjd (talk) 07:44, 7 February 2025 (UTC)[reply]

Tech News: 2025-06

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

Editors who use the "Special characters" editing-toolbar menu can now see the 32 special characters you have used most recently, across editing sessions on that wiki. This change should help make it easier to find the characters you use most often. The feature is in both the 2010 wikitext editor and VisualEditor. [5]
Editors using the 2010 wikitext editor can now create sublists with correct indentation by selecting the line(s) you want to indent and then clicking the toolbar buttons.[6] You can now also insert <code> tags using a new toolbar button.[7] Thanks to user stjn for these improvements.
Help is needed to ensure the citation generator works properly on each wiki.
- (1) Administrators should update the local versions of the page MediaWiki:Citoid-template-type-map.json to include entries for preprint, standard, and dataset; Here are example diffs to replicate for 'preprint' and for 'standard' and 'dataset'.
- (2.1) If the citoid map in the citation template used for these types of references is missing, one will need to be added. (2.2) If the citoid map does exist, the TemplateData will need to be updated to include new field names. Here are example updates for 'preprint' and for 'standard' and 'dataset'. The new fields that may need to be supported are archiveID, identifier, repository, organization, repositoryLocation, committee, and versionNumber. [8]
One new wiki has been created: a Wikipedia in Central Kanuri (w:knc:) [9]
View all 27 community-submitted tasks that were resolved last week. For example, the OCR (optical character recognition) tool used for Wikisource now supports a new language, Church Slavonic. [10]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 00:05, 4 February 2025 (UTC)[reply]

Unrealistic minimal length requirement (minimal number of characters) for file captions in East Asian languages

Tracked in Phabricator
Task T286735

if you know the cjk script, you will know that many words are just 2 characters long. spider = 蜘蛛, North America = 北米... many are even only 1 char. oranges = 橙, mountain = 山...

for all these examples, the english words can become files' english captions (string length > 5), but the kanjis cant be accepted because length < 5.

it's been many years since i filed this bug and it's still bugging me even though i rarely write cjk captions. cant imagine how annoying this is for users who write in those languages. when will this alphabet-centric problem be solved? RoyZuo (talk) 20:22, 4 February 2025 (UTC)[reply]

Low-resolution old images from the Library of Congress

People periodically upload the low-resolution files available from the Library of Congress (or in some cases the LoC makes available better files). I've tried (well to be honest I've used ChatGPT, as I know no SQL) on-and-off to formulate a Quarry query for this for several months now, to no great success.
My ideal search would be something like what follows:

Resolution under 2MP (not picky here)
Permission or source template has a link to the Library of Congress or uses one of the LoC templates with ID.
The file is in use on a Wikimedia project

I've been experiencing timeouts of my queries (among other issues(, so my parameters are either too complicated or botched by ChatGPT. Has anyone technical expertise enough to take a look? JayCubby (talk) 18:46, 5 February 2025 (UTC)[reply]

I can try to do a better query. Can you give some example image for the starting point? --Zache (talk) 19:09, 5 February 2025 (UTC)[reply]

The most straightforward-seeming images are ones like File:Albert Dillon Sturtevant in 1918.jpg, File:Col Charles Lindbergh.jpg, or File:CharlesRMabey.jpg which use {{LOC-image}}

Examples of 'bad' source listings are files like File:Two Winnebago men by WH Illingworth.jpg (the listed source URL is this, but the proper file can be found by searching 'two winnebago men illingworth')

File:Dixie 5249224624 c423d81d41 o.jpg is somewhere between straightforward and weird, with the LoC description copy-pasted.

Hope this helps,

JayCubby (talk) 19:24, 5 February 2025 (UTC)[reply]

Here is one only with images that use template:loc-image, limited to max 1414px width and height, which is just below 2MP. A list of Libary of Congress templates that have an ID parameter would be nice, it is not something I can query. Query took for me 28 seconds.

select page_title from page
join image on page_title = img_name and img_width < 1414 and img_height < 1414
join templatelinks on tl_from = page_id and tl_target_id = 1396
join globalimagelinks on gil_to = page_title
where page_namespace = 6
group by page_title limit 1000

Snævar (talk) 19:36, 5 February 2025 (UTC)[reply]

This one way to do the traightforward case (ie same than you did but with ID). It is not faster than your version, but seems to be solid without timeouts

https://quarry.wmcloud.org/query/90505

--Zache (talk) 20:39, 5 February 2025 (UTC)[reply]

Also if you need only first 1000 you can do it like this. Basically it does the filtering the results based on templatelinks and externallinks first and limit number of results to wanted number in subquery. Then in second part it will filter the results to images used in wikipages using using globalimagelinks.

- https://quarry.wmcloud.org/query/90518 Zache (talk) 10:43, 6 February 2025 (UTC)[reply]

Thanks a ton! I will run these through Glammorgan and deal with the top-used ones, unless someone can automate this. The LoC has an API, which might be of help to more technical folks. JayCubby (talk) 14:00, 7 February 2025 (UTC)[reply]

@JayCubby: In the case of File:Col Charles Lindbergh.jpg, you should upload the original and the cropped versions separately. Thanks, Yann (talk) 09:26, 7 February 2025 (UTC)[reply]

Done! JayCubby (talk) 14:01, 7 February 2025 (UTC)[reply]

disappearing thumbnails for pdf/djvu files

from all my 17 pdf uploads there are only 4 left with thumbnails at the moment. some of thumbnails disappeared in minutes after uploading, some in weeks. i had vague hopes it will be fixed by itself in time, but this magic works one-way only so far.

the issue seems to be seriously impacting the general search in "other media" tab. for example: "koltsov" or "Кольцов" search leads to "Invalid search Could not normalize image parameters for Aleksey_Vasilyevich_Koltsov_Yego_zhizn_i_sochineniya_1914.pdf" message.

attempts to search for "moskovskij zhurnal", "Московский журнал", "teleskop", "телескоп" lead to the same 'invalid search' result

while trying to search for "брюсов" i found another user affected by the same issue. the search led to "Invalid search Could not normalize image parameters for Первобытный_Брюсов_календарь_(1875).pdf" message.

some of the flies uploaded by HareGovorittKrishna with disappeared thumbnails arent ruining the search - theyre just staying invisible for it:

but some are: check lomonosov/ломоносов search.

none of the old HareGovorittKrishna's uploads are affected - so the issue mightve been started since at least november 2024.

so now my only way to upload while not ruining anything is uploading files with nonsense names, but i have a real distaste for the idea. TheyStoleMyNick (talk) 17:03, 8 February 2025 (UTC)[reply]

looks like HareGovorittKrishna's File:В. П. Благовещенский. Мыловарение (1909).djvu got its thumbnail back. its still invisible for the search though TheyStoleMyNick (talk) 17:29, 13 February 2025 (UTC)[reply]

Fix needed for template:Extracted from

The {{Extracted from}} template currently has a switch so that if the source file does not exist, it displays {{Extracted from deleted}} - "The source image was deleted for reasons that do not affect this image, like a derivative work which is not a part of this cropped image."

Unfortunately, this is a bit misleading - the original image might well have been deleted for a reason that also applies to the crop, eg an unlicensed image. We've discussed this on the talkpage and would like to switch this back so it just includes Category:Extracted images with broken file links rather than the template, but the template is quite complex and used 750,000 times - I don't want to break it, so would someone more confident than me be able to have a look at it? Thanks! Andrew Gray (talk) 22:31, 10 February 2025 (UTC)[reply]

Tech News: 2025-07

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

The Product and Technology Advisory Council (PTAC) has published a draft of their recommendations for the Wikimedia Foundation's Product and Technology department. They have recommended focusing on mobile experiences, particularly contributions. They request community feedback at the talk page by 21 February.

Updates for editors

The "Special pages" portlet link will be moved from the "Toolbox" into the "Navigation" section of the main menu's sidebar by default. This change is because the Toolbox is intended for tools relating to the current page, not tools relating to the site, so the link will be more logically and consistently located. To modify this behavior and update CSS styling, administrators can follow the instructions at T385346. [11]
As part of this year's work around improving the ways readers discover content on the wikis, the Web team will be running an experiment with a small number of readers that displays some suggestions for related or interesting articles within the search bar. Please check out the project page for more information.
Template editors who use TemplateStyles can now customize output for users with specific accessibility needs by using accessibility related media queries (prefers-reduced-motion, prefers-reduced-transparency, prefers-contrast, and forced-colors). Thanks to user Bawolff for these improvements. [12]
View all 22 community-submitted tasks that were resolved last week. For example, the global blocks log will now be shown directly on the Special:CentralAuth page, similarly to global locks, to simplify the workflows for stewards. [13]

Updates for technical contributors

Wikidata now supports a special language as a "default for all languages" for labels and aliases. This is to avoid excessive duplication of the same information across many languages. If your Wikidata queries use labels, you may need to update them as some existing labels are getting removed. [14]
The function getDescription was invoked on every Wiki page read and accounts for ~2.5% of a page's total load time. The calculated value will now be cached, reducing load on Wikimedia servers. [15]
As part of the RESTBase deprecation effort, the /page/related endpoint has been blocked as of February 6, 2025, and will be removed soon. This timeline was chosen to align with the deprecation schedules for older Android and iOS versions. The stable alternative is the "morelike" action API in MediaWiki, and a migration example is available. The MediaWiki Interfaces team can be contacted for any questions. [16]

In depth

The latest quarterly Language and Internationalization newsletter is available. It includes: Updates about the "Contribute" menu; details on some of the newest language editions of Wikipedia; details on new languages supported by the MediaWiki interface; updates on the Community-defined lists feature; and more.
The latest Chart Project newsletter is available. It includes updates on the progress towards bringing better visibility into global charts usage and support for categorizing pages in the Data namespace on Commons.

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 00:08, 11 February 2025 (UTC)[reply]

Categories not updating

Hello, few days ago I updated the template {{Hangzhoumonth}}, so it will categorize pages to their respective month (e.g. Category:April in Hangzhou) instead in Category:Hangzhou by month. However, the pages are still showing up in Category:Hangzhou by month. I tried purging my browser’ cache and waited for a few days, but it is still not working. Can someone give me some advice on what I should do? Thanks. Tvpuppy (talk) 15:53, 12 February 2025 (UTC)[reply]

This is bug phab:T132467. If you want the images to get their updated category in a timely fashion, then go over the transclusions of the template and do a null edit (or ask a bot to do it). A null edit is a edit that does not change anything. That will fix the issue. If not, you will most likely need to wait for 3 months for it to fix itself. I doubt you have that kind of patience. Snævar (talk) 11:51, 13 February 2025 (UTC)[reply]

I understand. Thank you very much. Tvpuppy (talk) 13:20, 13 February 2025 (UTC)[reply]

Publishing errors for days

Hi!

I recently experience several errors when publishing or uploading via Chunked Uploads (file could not be locked etc.) and sometimes, the publishing process takes a lot of time. Longer than usual. An issue that happens over years --PantheraLeo1359531 😺 (talk) 11:24, 13 February 2025 (UTC)[reply]

Upload not working?

I first tried the Wikisource upload tool (upload failed) and then gave up and went to Special:Upload. I figured I'd note here that Our servers are currently under maintenance or experiencing a technical issue

Request served via cp1102 cp1102, Varnish XID 582907980 Error: 503, Backend fetch failed at Fri, 14 Feb 2025 15:51:39 GMT

Cremastra (talk) 15:55, 14 February 2025 (UTC)[reply]

Mass message not delivered

I attempted to send a mass message following Commons:Administrators' noticeboard#Wiki Loves Earth in Ukraine: Request for MassMessage#this request. I have acted on such requests before, and never had any issues. This time, the mass message was sent to queue and has not been delivered for three days. Mass message did not have any edits after my request. Any tips what I could have done wrong and what I can do to have it delivered will be appreciated. Ymblanter (talk) 09:09, 15 February 2025 (UTC)[reply]

Now MediaWiki message delivery edited yesterday again, but my message has still not been delivered, meaning it is not going to be delivered. I will really appreciate some help. Ymblanter (talk) 10:06, 16 February 2025 (UTC)[reply]

I think there is some sort of database/cache/memory issue or lag going on with the MMS system. Mine message of 13th Feb also took several minutes to start delivering and it was 20 targets only. Maybe report on Phab? -- CptViraj (talk) 14:48, 18 February 2025 (UTC)[reply]

Thanks. Tbh I am pretty much disappointed about phab, whatever I reported there either took years to be resolved or remains unresolved even after many years. Ymblanter (talk) 18:44, 18 February 2025 (UTC)[reply]

I sent it again now and it seems to have worked this time. Ymblanter (talk) 19:55, 18 February 2025 (UTC)[reply]

Mutinous robots mark images for deletion, even when properly licensed

When uploading images with flickr2commons, somewhere along the process, a robot tags images that had a license of public domain mark for deletion EVEN WHEN THE IMAGE DESCRIPTION HAS HAD A VALID LICENSE ADDED TO IT!!!! Today's examples: a b c d e f g h i j k l m n o

I told flickr2commons to add the {{PD-USGov-State}} template to each of these images. It did add that perfectly valid and appropriate tag. Nevertheless these images were tagged for deletion by an out of control robot.

Yes, I could go to each of those images, and remove the improperly placed deletion tags.

But robots are supposed to be our slaves. They are supposed to serve us, not vice versa. I shouldn't be cleaning up after mutinous robots.

It should be trivial to make the robot check the information template for a valid license, before it calls for deletion under a claim the image is unlicensed.
But, really, it is long past the time we maintained a whitelist, of flickr contributors known to mistakenly tag images with a public domain mark.
1. That whitelist should include all flickr IDs that are maintained by employees of the US Federal government. When they are uploading images taken by US Federal employees we KNOW those images are unambiguously in the public domain.
2. There are many flickr contributors who are excellent prolific photographers, who generously want to put their fine photos in the public domain, who routinely mark their photos with the public domain mark.

We maintain a blacklist, a list of flickr contributors known to have unreliably tried to license images with free licenses, when they didn't own the IP rights to those images. If we can maintain that blacklist we can maintain a whitelist of flickr contributors whose public domain Marks should be recognized as stating the image is in the public domain. Cheers! Geo Swan (talk) 06:33, 17 February 2025 (UTC)[reply]

Your license template looks to be in the wrong parameter, it should probably be inside Permission instead of Description for the bot to recognize it. Sjoerd de Bruin (talk) 08:31, 17 February 2025 (UTC)[reply]

Template RCIN not working

Template:RCIN is not working. I don't actually know what's wrong so unsurprisingly I could not fix it. Thanks. — Diannaa 🍁 (talk) 13:12, 17 February 2025 (UTC)[reply]

Tech News: 2025-08

Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.

Weekly highlight

Communities using growth tools can now showcase one event on the Special:Homepage for newcomers. This feature will help newcomers to be informed about editing activities they can participate in. Administrators can create a new event to showcase at Special:CommunityConfiguration. To learn more about this feature, please read the Diff post, have a look at the documentation, or contact the Growth team.

Updates for editors

Starting next week, talk pages at these wikis – Spanish Wikipedia, French Wikipedia, Italian Wikipedia, Japanese Wikipedia – will get a new design. This change was extensively tested as a Beta feature and is the last step of talk pages improvements. [17]
You can now navigate to view a redirect page directly from its action pages, such as the history page. Previously, you were forced to first go to the redirect target. This change should help editors who work with redirects a lot. Thanks to user stjn for this improvement. [18]
When a Cite reference is reused many times, wikis currently show either numbers like "1.23" or localized alphabetic markers like "a b c" in the reference list. Previously, if there were so many reuses that the alphabetic markers were all used, an error message was displayed. As part of the work to modernize Cite customization, these errors will no longer be shown and instead the backlinks will fall back to showing numeric markers like "1.23" once the alphabetic markers are all used.
The log entries for each change to an editor's user-groups are now clearer by specifying exactly what has changed, instead of the plain before and after listings. Translators can help to update the localized versions. Thanks to user Msz2001 for these improvements.
A new filter has been added to the Special:Nuke tool, which allows administrators to mass delete pages, to enable users to filter for pages in a range of page sizes (in bytes). This allows, for example, deleting pages only of a certain size or below. [19]
Non-administrators can now check which pages are able to be deleted using the Special:Nuke tool. Thanks to user MolecularPilot for this and the previous improvements. [20]
View all 25 community-submitted tasks that were resolved last week. For example, a bug was fixed in the configuration for the AV1 video file format, which enables these files to play again. [21]

Updates for technical contributors

Parsoid Read Views is going to be rolling out to most Wiktionaries over the next few weeks, following the successful transition of Wikivoyage to Parsoid Read Views last year. For more information, see the Parsoid/Parser Unification project page. [22][23]
Developers of tools that run on-wiki should note that mw.Uri is deprecated. Tools requiring mw.Uri must explicitly declare mediawiki.Uri as a ResourceLoader dependency, and should migrate to the browser native URL API soon. [24]

Tech news prepared by Tech News writers and posted by bot • Contribute • Translate • Get help • Give feedback • Subscribe or unsubscribe.

MediaWiki message delivery 21:18, 17 February 2025 (UTC)[reply]

Language-independent anchors on file pages？

Now, if i copy the anchor to file page, e.g. File:Test.wav#Summary, the link will fail if the person clicking it is not using english ui.

i think we should make the anchors language independent somehow, so that we can create links that jump to specific sections on file pages that work for all users.

another idea is, we keep the current anchors but add language independent ones somewhere next to them, if the current anchors based on i18n headers cannot be changed.

why such links are needed? coz sometimes file pages are long, and it is beneficial to jump to for example "summary" for all the file descriptions when i am referring specifically to them. RoyZuo (talk) 20:28, 19 February 2025 (UTC)[reply]

Don't know how this {{int:filedesc}} works but that is supposed to be at the top of the content and the anchors work for the other sections across languages... e.g. File:Test.wav?uselang=de#filehistory which is a section I find sometimes useful to link to. Prototyperspective (talk) 22:53, 19 February 2025 (UTC)[reply]

hmm, i looked at view-source:https://commons.wikimedia.org/wiki/File:Test.wav?uselang=de#filehistory . if i understand correctly, the file history html tag id remains "filehistory", but the "Summary" tag id also changes to "Beschreibung" as it is translated. RoyZuo (talk) 10:55, 21 February 2025 (UTC)[reply]

Yes, that's what I've been saying. Again, I don't know how this {{int:filedesc}} works – that's where this would be changed if doing so is needed or good. I guess HTML id tags should stay the same regardless of language so as long as nobody has a good argument against it, I'd support a request to change it albeit I currently see no need for it. These id tags can however be very useful, e.g. to screenreaders and for ways to convert pages into other formats like audio etc. Prototyperspective (talk) 13:15, 21 February 2025 (UTC)[reply]

CC-BY license, without attribution text/information

Some (or many) CC-BY licensed files are missing "attribution" attribute in {{Information}} (Summary) section.

I suppose this "attribution" tag shall be the proper location to give the required text for attribution, but:
- note1: this tag is created by {{Credit line}}, in entry "other_fields", in {{Information}} template (nothing seeming related to "attribution")!!!
- note2: {{Credit line}} only require a "license" value!
without mandatory "attribution" text
for a CC-BY... license, no "attribution" information seem to be checked.
- as Category:CC-BY, and its sub-categories, are automatically populated with file license of these kinds, why not populate a category such as Category:CC-BY without formal attribution?

Thanks for reading. Despite my searches, please indicate if this subject was already answered.

Note: as a sample, please see Systeme olfactif.png for my additions, I assume they are required for CC-BY files.

En rouge (talk) 17:36, 22 February 2025 (UTC)[reply]