Commons:Village pump/Technical

Shortcuts: COM:VP/T • COM:VPT

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

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/2024/05 /Archive/2024/06.

COMMONS DISCUSSION PAGES (index)

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

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.

Cat-a-lot does not work for categories

There seems to be a technical problem with Help:Gadget-Cat-a-lot: when I click on Preferences, click on "Allow categorising pages (including categories) that are not files", then select one or more subcategories and try to move/copy/delete them to/from another category (like I always do), nothing happens but an endless "Editing page 1 of X". Moving files is no problem. Can this be fixed? JopkeB (talk) 11:05, 16 February 2024 (UTC)

I am not the only one having troubles, see Commons:Village pump#Cat-a-lot as well. JopkeB (talk) 13:27, 16 February 2024 (UTC)

Same for me: moving categories does not work, moving files works. --Reinhard Müller (talk) 14:49, 16 February 2024 (UTC)

I confirm that it is not working. Theklan (talk) 09:36, 24 February 2024 (UTC)

I can also confirm that it's not working for categories, although it will sometimes say that the category was moved.Smasongarrison (talk) 00:28, 27 February 2024 (UTC)

Note: If there is specific categories where problem can be replicated then please list them. (ie. fixing requires example cases) --Zache (talk) 15:58, 16 February 2024 (UTC)

I would like to copy a lot of subcategories in Category:Energy by type of energy to Category:Energy by topic‎ (all except for the 'by' categories). JopkeB (talk) 16:20, 16 February 2024 (UTC)

It was broken by a change to the HTML structure of the category pages, see phab:T355636#9553616. I hope it will be fixed by another change to the HTML structure, but if not, an interface admin should update the method getMarkedLabels() to account for the change. —Tacsipacsi (talk) 14:02, 18 February 2024 (UTC)

Same problem for me. I have posted this on MediaWiki talk:Gadget-Cat-a-lot.js but the only replies are people saying "Same problem for me". So nobody is actually looking after this? Cnbrb (talk) 23:19, 27 February 2024 (UTC)

For me moving categories was never possible with cat a lot. Always moved one by one.Paradise Chronicle (talk) 05:24, 14 March 2024 (UTC)

Help:Gadget-Cat-a-lot#Preferences. RZuo (talk) 06:31, 14 March 2024 (UTC)

 Question Is there any chance that we get an indication of:

• What is the priority to solve this problem?
• Whether someone is working on the solution of this problem?
• How long it might take before it is solved?

--JopkeB (talk) 07:13, 5 April 2024 (UTC)

the solution would be to revert phab:T355636. Can someone do that? Enhancing999 (talk) 15:25, 17 April 2024 (UTC)

No we can just apply this change to Cat-a-lot, as Tacsipacsi indicated above. Nardog (talk) 16:03, 23 April 2024 (UTC)

Can someone actually implement the fix? Smasongarrison (talk) 22:03, 23 April 2024 (UTC)

Only an interface admin can. Nardog (talk) 20:40, 24 April 2024 (UTC)

Nardog has asks on https://commons.wikimedia.org/wiki/MediaWiki_talk:Gadget-Cat-a-lot.js#Cat-a-lot_failing_202402 to solve this problem. Thanks! One big step forward. JopkeB (talk) 04:08, 25 April 2024 (UTC)

Since today it looks like Cat-a-lot is also disabled for search results, see Commons:Village_pump#Cat-a-lot_disabled_for_search_results? for details. See also Commons:Village_pump/Technical#HotCat (added today). --JopkeB (talk) 14:48, 16 May 2024 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. Fixed in Special:Diff/876867555, see MediaWiki talk:Gadget-Cat-a-lot.js#Cat-a-lot failing 202402. —⁠andrybak (talk) 22:02, 4 June 2024 (UTC)

New tool for detecting logos

Hi all! As you already probably know, the Structured Content team is working this year on improving the current user experience with UploadWizard. We already have done some work on the “release rights” step, and we recently concluded a community discussion about the “describe” step. We are currently integrating the feedback received from you into our workflow.

Another thing we are working on is a potential improvement to automatically detect logos when uploaded on Commons through UploadWizard, in order to facilitate their evaluation by the community. A need for machine detection tools was raised in several discussions and user interviews we had in the past with the community, and logos are the second reason for media deletion after Freedom of Panorama, so we decided to work in that direction.

The tool we developed has shown promising results (accuracy is ~96%); in case you’re interested, you can see a brief summary of an evaluation of a sample batch of images. Our intention is for you to discuss and then, if consensus is reached, to integrate the tool in UploadWizard, in a way that would be beneficial for moderation workflow.

We would love to have your input. Do you think this tool could be useful? Do you think this tool could be integrated in UploadWizard, and then integrated in your moderation workflow? Sannita (WMF) (talk) 10:18, 9 April 2024 (UTC)

Maybe you could run it through the "icons" category to test. Enhancing999 (talk) 10:53, 9 April 2024 (UTC)

If integrated into the MediaWiki Upload Wizard, how would it work? Would it prevent the uploading of a PD-textlogo or would it detect if an incompatible license or attribution is present? Or would it simply add them to a daily page for community evaluation, akin to "User:Minorax/PD textlogo/2020 June 6"? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:03, 9 April 2024 (UTC)

@Donald Trung This is actually something that we wanted to discuss with the community. The tool, as of now, only recognises logos with a very high accuracy, but we want to ask the community what to do next. We are open to suggestions. Sannita (WMF) (talk) 11:17, 9 April 2024 (UTC)

Sannita, I think that it might be wise to index all logos by date of upload on a single page and have the tool also detect the licenses, and then add these into sections like "Logos with Creative Commons licenses tagged as Own work", "Logos with public domain licenses", "Logos with Creative Commons licenses attributed to an external source". That way we can easily go through each type of upload, a lot of (new) users upload free logos as "Own work" with wrong licenses, these are the most problematic, but those uploaded with external links and / or specific licenses tend to be less problematic, so we would immediately know which areas to focus on, but still evaluate the other logos. For example, a very complex logo shouldn't be in "PD-textlogo" and can be deleted if not found to have a free license, which would also be easily detected using such a system. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:26, 9 April 2024 (UTC)

For clarification "I think that it might be wise to index all logos by date of upload on a single page and have the tool also detect the licenses" would be a page like "Commons:Image detection/Logos/2024/November/12", I deliberately made logos as a sub-category of image detection because of the suggestions below by user "Adamant1" to also add this for postcards. I think that a tool like this could supersede the groups based on category done by the OgreBot today in the future. The page "Commons:Image detection" could be a central hub where reviewers (in the broadest sense) can use the AI-powered tool to find and detect logos. Heck, maybe in the distant future it can also detect images based on freedom of panorama (exterior images) and many other categories. Logos is a good start, though we should make sure that we don't discourage people from uploading, we should simply make it easier to detect possible copyright ©️ violations. We also used to have a page for uploads by new users, but I am not sure if we still have that (I think that I read somewhere that an update to the MediaWiki software made it difficult to maintain), perhaps the "Image detection" page can also have a sub-category for new users as well.
Heck, maybe we can even use this tool retroactively to group images together on a page like "Commons:Image detection/Logos/2012/December/8" and have like a button that trusted users can press to mark an image on that page as "patrolled" independent from the current solution we have. There are many ways that such a tool could be implemented, however, I sincerely hope that it won't be included before an image is published, as we could be missing out of valuable uploads because a new user (or a Wikipedian not familiar with this website) would be scared off by a warning message. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:21, 9 April 2024 (UTC)

My own humble suggestion is to disable and dismantle this whole thing, and rather redirect WMF’s funding and priorities to actually useful things requested by the community — like, say, fixing the 10 year old bugs that still plague the unified login process.

I have nothing against some random AI outfit making use of Commons’s publicly available data to “train” their GIGO machines: Good luck with that. But WMF funding should not be used for this sort of useless, misleading, hyped-up nonsensical makework.

And I know that this suggestion will never be given any attention, but that’s how it goes. -- Tuválkin ✉ ✇ 01:14, 10 April 2024 (UTC)

@Tuvalkin, I'm not sure I'd have ranked it as the top priority (just since the old wizard wasn't especially bad), but I do think that improving the wizard is a reasonable place to focus. We're a media repository, which makes the process for uploading media a pretty essential function. We lose an untold number of contributions (Sannita, do you have any data?) from people who aren't able to go through it successfully, and it's the first line of defense to prevent/fix problematic contributions (which reduces moderation work later). Sdkb ^talk 04:48, 10 April 2024 (UTC)

Oh, I don’t think the upload wizzard should exist, at all. So there’s that. (Before you ask, I use Special:Upload or external tools, like Vicuña and Commonist.) I agree that uploading media a pretty essential function — therefore gamified uploads from clueless jokers should be discouraged. You however both bemoan those lost uploaders (can it be lost, that which never existed?…) and also call for a better ratmaze to make sure their “work” is not too deterimental to Commons, in terms of scope and copyright blunders.

At the same time many of the same people who cheer for this sort of continued addition of even more bells and whistles to the upload process, supposedly to avoid that loss of untold poor dears, are the same who constantly decry mass uploads, and who are happy to dance on the grave of the most prolific uploader (both quantity and quality) Commons ever had.

So, basicly not impressed. Wont help the Upload Wizzard this adding to the loop of an opaque step which likely takes pre-published media files away from WMF purview off to some blackbox; the environmental impact of the additional computing resources needed — that’s a cherry on top. (Remings me of: Hop on a jet plane to join all the WMF cronies for needless face-to-face meetings: The cafeteria is 100% vegan because environment, dontcha know?)

To clarify: In my opinion, one-off uploads, especially by editors creating articles in other projects, should be allowed into Commons via a pipeline that’s not the same of mass or “expert” uploading — I presume the Visual Editor has such a function (never used it — unsurprisingly, I think it’s also nonsense). However, it’s not helping this the training of an A.I. (and I’m all out of irony quote marks at this point) who will nag Clippy-style said unexperienced uploader, muddling the process even more. Especially since it will, most of the time, be confusing for logos all kinds of icons, diagrams, maps, flags, and traffic signs.

Was I the only one who shook their head and palmed their face at the apparent fact that the control group for this A.I. training was the contents of Category:Logos, with depth=0…? Yes, that one garbage-bag category where end up stuck all the poorly categorized logos, including, more than any deeper subcat, miscurated images which are anything but logos! Just wow — the more I think of this, the worse it looks like.

But you’re right that this sort of nonsense is (also) «requested by the community». Sad…!

-- Tuválkin ✉ ✇ 06:39, 10 April 2024 (UTC)

Re training using a depth of 0, oof — Sannita, you all should rethink that.

Re your braoder point, you seem to be pursuing a world in which it's far harder for newcomers to contribute to Wikimedia. That's a world in which our projects have more systemic bias and less overall content, which is not what I'd want. Sdkb ^talk 14:17, 10 April 2024 (UTC)

@Tuválkin: thanks for your comments. Logo samples in the evaluation dataset were collected via a PetScan query with a category depth > 0. I'm sorry I couldn't retrieve the exact depth from that query.

Cheers, MFossati (WMF) (talk) 16:55, 11 April 2024 (UTC)

I agree to Tuválkin’s point that this looks like very weird priorities. Recently, UploadWizard became so broken for me that I have to look into different tools for upload. (I don’t know if it would still be usable with high-income country bandwidth and no power cuts.) Why do people start to work on new features of something whose basic function is more or less broken? Just because AI sounds fancy or it’s interesting to play around with it?

Just to be clear: Also agree with Sdkb that I’m not in favor of a world in which it's far harder for newcomers [and] more systemic bias. However, this doesn’t invalidate wondering about reasons for prioritizing a potentially useful feature over basic functionality. —Marsupium (talk) 01:25, 7 May 2024 (UTC)

This looks like a super cool tool. I was just wishing there was something similar for detecting images of postcards. I have to agree with Donald Trung that it's probably better to use an indexer of exiting files instead of being directly integrated into UploadWizard. I imagine things like this are going to be the future of detecting and organizing specific types of images anyway and I doubt every use case going forward could be integrated into UploadWizard, but a hub for different types of detected images going forward would be great, starting out with logos and then integrating it with other types in the future. I don't think turning UploadWizard into a metaphorical Swiss Army knife of image detection at the point of upload would really be practical or useful though. From what I've seen most people are usually turned off by that sort of thing. Especially new users. UploadWizard is hard enough to understand and work with as it is already. --Adamant1 (talk) 12:57, 9 April 2024 (UTC)

This seems like a really useful tool! As far as integration into the Upload Wizard, we could use it to customize the user experience. For instance, there could be a dialogue "This looks like a logo. Is that correct? [Yes] [No]". [Yes] would autocategorize the image and lead to follow-up steps trying to confirm the copyright (e.g. directing them to COM:RELGEN if they claim it's their own work), and [No] would apply a hidden category or add it to a feed of reported false positives. Sdkb ^talk 16:29, 9 April 2024 (UTC)

Very nice! The model seems to detect reliable for graphics vs. random photos. Let me suggest some curveballs, from the type of images I often encounter: How does it perform when you include Flags and CoAs into the mixup? Uploads of those categories are also often deleted, but less often than logos. Another test could include Map details (i.e. cutouts) which are usually not deleted.

Also, what would this tool actually do after the detection? Bring the positives into a dedicated (hidden) category for users to evaluate? Yes, I could really see a use in that, for quicker processing of uncategorized uploads. --Enyavar (talk) 12:19, 9 April 2024 (UTC)

@Enyavar Thanks for your opinion. For now, we limited ourselves to logos because they were easier to detect, but if there is consensus for it, we can expand our work to other kinds of images.

About what the tool can actually do... that's the point of the discussion. We have suggestions to make, but we want to hear from you first, not to influence the discussion. The dedicated category/tag was actually one of the suggestions that we had, to be fair. But we'll take note of this suggestion, thanks! Sannita (WMF) (talk) 14:12, 9 April 2024 (UTC)

Ah, sorry, I meant something else with my first comment: can the tool reliably detect logos in the presence of these other (similar looking) images? What are the percentages for examples A, B, C, D, E or possibly F, G, H? It won't be totally bad if these get detected as logos with a certainty of 90%+... I'm just curious whether or not files from these categories have a higher false positive rate for the current tool. --Enyavar (talk) 15:08, 9 April 2024 (UTC)

Good idea, to test on coats of arms, flags and maps in addition to icons I mentioned above.

Wonder if the training set was useful: Commons mainly has simple logos for which it doesn't actually matter that they are also logos. Enhancing999 (talk) 20:04, 9 April 2024 (UTC)

Hi @Enyavar and Enhancing999: {{u}} here, I'm the main technical point of contact behind this effort. Thanks for your feedback, very useful and appreciated! Here are the probability scores of the images you mentioned:

• A = 77.82 %
• B = 48.96 %
• C = 88.9 %
• D = 97.9 %
• E = 99.87 %
• F = 0.45 %
• G = 0.36 %
• H = 43.29 %

A few observations:

• all scores but D and E seem low enough to be cut out;
• as a human, I'd consider D and E as logos if I didn't know what coat of arms are. The model was indeed trained on logos and non-logos, so it hasn't got any notion of coat of arms;
• probability threshold selection will be crucial to tune the amount of what we’d like to consider as true positives.

Anyway, I definitely think that your suggestions make a lot of sense: testing the robustness of the model against visually similar inputs is now in my to-do list.

Cheers, MFossati (WMF) (talk) 11:03, 10 April 2024 (UTC)

This doesn't seem un-useful, but I am a bit skeptical that it will move the needle much in terms of checking logos for copyvio/spam. There is already an overwhelming backlog of this stuff -- 118,798 files in Category:Unidentified logos alone. The most likely outcome is another backlog. Gnomingstuff (talk) 20:42, 9 April 2024 (UTC)

What would probably make it a lot more useful is if it was used for flow control in the upload wizard. If an image is detected as a logo and the user confirms that it's a logo, that could eventually shunt the user into a workflow that asks them for logo-specific information, e.g. "what does this logo stand for", "where did you find this logo", etc. Omphalographer (talk) 18:57, 10 April 2024 (UTC)

I can see both sides and arguments here. Tuvalkin is strictly against adding such "another whistle and bell" to the upload wizard (I find it tedious too, and I can understand how a Clippy-style intervention during the upload would frustrate the more experienced uploaders). On the other hand, this addition to the wizard could immensely enrich the descriptions of uploaded logos by one-time contributors (often by the companies/brands who hold copyright of the logo, i.e. these are officially sanctioned uploads that we'll be able to use) who we can never contact again even a week later for clarification on their uploads. --Enyavar (talk) 09:32, 11 April 2024 (UTC)

Thanks all for your interventions! We've already identified some good things we can work on, even though we would like the discussion to go on and let you continue have your say. We would like the discussion to go on some more days, to try to get some consensus going on. Sannita (WMF) (talk) 10:17, 15 April 2024 (UTC)

New tool for cropping and rotating images (proposal)

MediaWiki or at least Commons should have a function that allows to crop images and save them as separate ones directly, including the original description.

Why would we need it when most phones can crop or even rotate images?

• preserve image resolution
• preserve metadata
• ensure derivation is annotated on original file

We currently have a bot and a user tool that have some of the functionality, but this lags behind a reasonable functionality. Maybe WMF development can be facilitated by adopting some of their code. Enhancing999 (talk) 08:13, 12 April 2024 (UTC)

Enhancing999, CropTool has no lag for me. You ask to crop an image, you crop it and it is immediately uploaded. I use it regularly and I do not have any complains about it. Rotatebot also seems to work fine. You tag a file for rotating and within 24 hours it is rotated. I guess we could have a tool to rotate immediately, but the current approach is not bad. --Jarekt (talk) 00:42, 18 April 2024 (UTC)

There are two years of open bug reports and feature requests on the tools talk page.

I agree it works on files of 500 KB, but larger ones fail now, especially when attempt to fix rotation by a few degrees. Rotatebot can't handle that. Also the automated border detection fails. Enhancing999 (talk) 08:15, 18 April 2024 (UTC)

Lots of miscellaneous failures over the last few years, and no one committed to maintaining it.

I'd be glad to see a group of three or more volunteers take it on, or WMF, but finding one more individual to do it just postpones collapse, because the environment keeps changing. - Jmabel ! talk 12:46, 18 April 2024 (UTC)

Isn't development of key features meant to be done by paid WMF staff? It's not a content/editorial issue. Enhancing999 (talk) 07:41, 20 April 2024 (UTC)

@Enhancing999:

Why would we need it when most phones can crop or even rotate images?

That assumes that users use phones. The section ‘Mobile versions of user talk pages are useless’ did point out that some users exclusively use phones, shunning other devices such as laptops and desktop computers.

But not all users are like that. There are good reasons for using other devices, including (but not limited to) the criticisms of Wikimedia's mobile versions given in that same section. Brianjd (talk) 08:30, 23 April 2024 (UTC)

This section is actually about two distinct actions:

1. Edit an image (by cropping or rotating), while otherwise preserving image quality and metadata.
2. Upload the edited image with an appropriate filename and description and ensure that the original image’s description is updated accordingly.

But this section proposes to bundle these actions into one tool.

The problem is that there are other important types of edits besides crops and rotations. Even if Commons can’t help with the edits themselves, it should still help with filenames and descriptions, the same way as it does for crops and rotations. Brianjd (talk) 08:46, 23 April 2024 (UTC)

Well, in the past, bundling these actions have been proven fairly helpful. If you think other tools are needed at Commons, please discuss this elsewhere. Enhancing999 (talk) 14:35, 23 April 2024 (UTC)

@Enhancing999: I agree that bundling these actions into one tool is helpful. But that one tool should be implemented as a wrapper around more specific tools (one for cropping and one for handling filenames and descriptions), which should also be accessible separately. Brianjd (talk) 08:21, 24 April 2024 (UTC)

As user, I'm mainly interested in a stable, working tool. For the rest, WMF pays IT staff. Enhancing999 (talk) 08:40, 24 April 2024 (UTC)

There has been some code written to include cropping into mediawiki. Just needs someone to take it over the line. Bawolff (talk) 21:48, 11 May 2024 (UTC)

This talk page reports several problems with the current version of CropTool. As a user, I am indifferent about whether it is repaired or replaced. But something must be done, urgently. Pommée (talk) 08:17, 19 May 2024 (UTC)

Error "To avoid creating high replication lag, this transaction was aborted because the write duration (..) exceeded the 3 second limit."

I keep getting that. Enhancing999 (talk) 17:12, 5 May 2024 (UTC)

Yes, I got that too. I believe it was a temporary glitch. Yann (talk) 17:14, 5 May 2024 (UTC)

I've been getting the error for a while now and it seems to still be going on. --Adamant1 (talk) 17:49, 5 May 2024 (UTC)

Why does this warning message start showing up after I've clicked the publish changes button?

Hi, I having trouble editing pages. The warning message say:

"To avoid creating high replication lag, this transaction was aborted because the write duration (52.137077093124) exceeded the 3 second limit. If you are changing many items at once, try doing multiple smaller operations instead."

This issue seems to have started last week. It always happens at night. On the same page, I always have to try three or even five times before the system actually accepts my edits. It bothers me a lot, so if anybody know how to solve it then help me. Thanks.--125.230.68.137 12:06, 6 May 2024 (UTC)

I had the same problem when trying to add a category to File:Brouwerij Verhaeghe.jpg. [78b79d1d-ee4d-4bb7-a16e-3436aff4157d] 2024-05-06 19:03:00: Fatale fout van type "Wikimedia\Rdbms\DBTransactionSizeError". 5 minutes later I tried again. No problem anymore. Wouter (talk) 19:16, 6 May 2024 (UTC)

The problem is still happening intermittently. Nurg (talk) 01:25, 7 May 2024 (UTC)

I have opened a call at https://phabricator.wikimedia.org/T364360. Nurg (talk) 01:50, 7 May 2024 (UTC)

I received this kind of error, too. Seems to be a larger problem --PantheraLeo1359531 😺 (talk) 15:33, 10 May 2024 (UTC)

New tool for importing SteamGridDB images

Hi, just wanted to share a new tool I've made: sgdb2commons. It's a browser script that makes it easy to quickly import images from steamgriddb.com. The website is a pretty good source for high-quality video game logos, and many of those logos are too simple to be copyrighted, so this tool lets you pick images to copy to Commons. Installation and usage info can be found at User:IagoQnsi/sgdb2commons. This is a very simple first version of the script, so please let me know if you encounter any issues or have any suggestions! Best, IagoQnsi (talk) 02:31, 6 May 2024 (UTC)

I'm not certain that this site is an appropriate source for Commons media. Most of the images it offers are unofficial fan-created logos which should not be uploaded to Commons. Omphalographer (talk) 04:20, 7 May 2024 (UTC)

It has both official and custom logos, and each logo is tagged with which type it is (albeit not always accurately). It definitely requires discretion from the uploader to determine which files are worth transferring, but I would estimate there are thousands of images on the site that would be valuable and appropriate for Commons. –IagoQnsi (talk) 04:38, 7 May 2024 (UTC)

Tech News: 2024-19

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

Recent changes

Example of a talk page with the new design, in French.

• The appearance of talk pages changed for all wikis, except for Commons, Wikidata and most Wikipedias (a few have already received this design change). You can read the detail of the changes on Diff. It is possible to opt-out these changes in user preferences ("Show discussion activity"). The deployment will happen at remaining wikis in the coming weeks. [1][2]
• Interface admins now have greater control over the styling of article components on mobile with the introduction of the SiteAdminHelper. More information on how styles can be disabled can be found at the extension's page. [3]
• Wikimedia Enterprise has added article body sections in JSON format and a curated short description field to the existing parsed Infobox. This expansion to the API is also available via Wikimedia Cloud Services. [4]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 7 May. It will be on non-Wikipedia wikis and some Wikipedias from 8 May. It will be on all wikis from 9 May (calendar). [5][6]
• When you look at the Special:Log page, the first view is labelled "All public logs", but it only shows some logs. This label will now say "Main public logs". [7]

Future changes

• A new service will be built to replace Extension:Graph. Details can be found in the latest update regarding this extension.
• Starting May 21, English Wikipedia and German Wikipedia will get the possibility to activate "Add a link". This is part of the progressive deployment of this tool to all Wikipedias. These communities can activate and configure the feature locally. [8]

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

MediaWiki message delivery 16:41, 6 May 2024 (UTC)

Category:Files with coordinates missing SDC location of creation (52° N, 4° E)

Suddenly the files I uploaded started to get to this category. I am sure I am not doing anything different from what I usually do (I uploaded 25+ files today, and until 15 minutes ago everything was going ok). Ymblanter (talk) 19:45, 8 May 2024 (UTC)

@Multichill: Ymblanter (talk) 19:46, 8 May 2024 (UTC)

I see, the issue is somewhere with the syntax, instead of hidden categories redlinks are created. Ymblanter (talk) 19:51, 8 May 2024 (UTC)

@Ymblanter: Was doing some changes, see User_talk:Multichill#Category:Files_with_coordinates_missing_SDC_location_of_creation_(51°_N,_-1°E)_and_similar. Multichill (talk) 22:39, 8 May 2024 (UTC)

Tnx. Ymblanter (talk) 22:40, 8 May 2024 (UTC)

Tech News: 2024-20

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

Recent changes

• On Wikisource there is a special page listing pages of works without corresponding scan images. Now you can use the new magic word __EXPECTWITHOUTSCANS__ to exclude certain pages (list of editions or translations of works) from that list. [9]
• If you use the user-preference "Show preview without reloading the page", then the template-page feature "Preview page with this template" will now also work without reloading the page. [10]
• Kartographer maps can now specify an alternative text via the alt= attribute. This is identical in usage to the alt= attribute in the image and gallery syntax. An exception for this feature is wikis like Wikivoyage where the miniature maps are interactive. [11]
• The old Guided Tour for the "New Filters for Edit Review" feature has been removed. It was created in 2017 to show people with older accounts how the interface had changed, and has now been seen by most of the intended people. [12]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 14 May. It will be on non-Wikipedia wikis and some Wikipedias from 15 May. It will be on all wikis from 16 May (calendar). [13][14]
• The Special:Search results page will now use CSS flex attributes, for better accessibility, instead of a table. If you have a gadget or script that adjusts search results, you should update your script to the new HTML structure. [15]

Future changes

• In the Vector 2022 skin, main pages will be displayed at full width (like special pages). The goal is to keep the number of characters per line large enough. This is related to the coming changes to typography in Vector 2022. Learn more. [16]
• Two columns of the pagelinks database table (pl_namespace and pl_title) are being dropped soon. Users must use two columns of the new linktarget table instead (lt_namespace and lt_title). In your existing SQL queries:
  1. Replace JOIN pagelinks with JOIN linktarget and pl_ with lt_ in the ON statement
  2. Below that add JOIN pagelinks ON lt_id = pl_target_id
  • See phab:T222224 for technical reasoning. [17][18]

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

MediaWiki message delivery 23:55, 13 May 2024 (UTC)

HotCat

I've found my HotCat not really working today, it doesn't highlight any images after I select All. No Swan So Fine (talk) 10:43, 15 May 2024 (UTC)

Are you sure you mean HotCat and not Cat-a-Lot ? —TheDJ (talk • contribs) 11:23, 15 May 2024 (UTC)

You are correct, sorry. I meant Cat-a-Lot! I've replied at [19] No Swan So Fine (talk) 11:53, 15 May 2024 (UTC)

Changes to upload by URL

As of 1330 UTC today, there have been some backend changes to how uploading files by URL works. In order to address historical issues where larger files time out during upload (and to hopefully enable us to increase upload limits in future), URL uploads are now performed in the background after submission. This has been successfully tested in a few environments, but if you notice any issues with Special:Upload when using URLs, please post in the relevant Phabricator task. HNowlan (WMF) (talk) 17:02, 16 May 2024 (UTC)

Tech News: 2024-21

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

Recent changes

• The Nuke feature, which enables administrators to mass delete pages, will now correctly delete pages which were moved to another title. [20]
• New changes have been made to the UploadWizard in Wikimedia Commons: the overall layout has been improved, by following new styling and spacing for the form and its fields; the headers and helper text for each of the fields was changed; the Caption field is now a required field, and there is an option for users to copy their caption into the media description. [21][22]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 21 May. It will be on non-Wikipedia wikis and some Wikipedias from 22 May. It will be on all wikis from 23 May (calendar). [23][24]
• The HTML used to render all headings is being changed to improve accessibility. It will change on 22 May in some skins (Timeless, Modern, CologneBlue, Nostalgia, and Monobook). Please test gadgets on your wiki on these skins and report any related problems so that they can be resolved before this change is made in all other skins. The developers are also considering the introduction of a Gadget API for adding buttons to section titles if that would be helpful to tool creators, and would appreciate any input you have on that.

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

MediaWiki message delivery 23:01, 20 May 2024 (UTC)

Javascript issue

Hi, I got a JS problem. Help:Gadget-DelReqHandler doesn't load or work. Broken with Monobook and Timeless on Chrome and Firefox on Windows 10. Works with other skins. Yann (talk) 10:45, 23 May 2024 (UTC)

 Info -> Commons:Administrators'_noticeboard#Problem_with_DelReqHandler.--Wdwd (talk) 12:36, 23 May 2024 (UTC)

Is it possible to search EXIF tags?

Is it possible to search by EXIF tag, i.e., file metadata? The full text search allows a variety of operators, but I don't see anything for this, and it would be useful for some of the work I'm doing. grendel|khan 12:34, 25 May 2024 (UTC)

https://quarry.wmcloud.org/ has some limited support for searching through metadata, but it is far from ideal. Bawolff (talk) 23:13, 26 May 2024 (UTC)

Replicating s:Module:Copyright-until here

I am hoping that someone can do some work with s:Template:Copyright-until and the module by user:CalendulaAsteraceae at Wikisource to help reduce some of the problematic error generation that comes from just pasting links to files on a category page. Those cat pages are constantly generating errors for the red links, and it would be good if we could migrated to something a little less problematic. Thanks.  — billinghurst sDrewth 11:58, 27 May 2024 (UTC)

Tech News: 2024-22

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

Recent changes

• Several bugs related to the latest updates to the UploadWizard on Wikimedia Commons have been fixed. For more information, see T365107 and T365119.
• In March 2024 a new addPortlet API was added to allow gadgets to create new portlets (menus) in the skin. In certain skins this can be used to create dropdowns. Gadget developers are invited to try it and give feedback.
• Some CSS in the Minerva skin has been removed to enable easier community configuration. Interface editors should check the rendering on mobile devices for aspects related to the classes: .collapsible, .multicol, .reflist, .coordinates, .topicon. Further details are available on replacement CSS if it is needed.

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 28 May. It will be on non-Wikipedia wikis and some Wikipedias from 29 May. It will be on all wikis from 30 May (calendar). [25][26]
• When you visit a wiki where you don't yet have a local account, local rules such as edit filters can sometimes prevent your account from being created. Starting this week, MediaWiki takes your global rights into account when evaluating whether you can override such local rules. [27]

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

MediaWiki message delivery 00:12, 28 May 2024 (UTC)

User:Dispenser/Double extension

Can someone perhaps remove all the deleted and renamed files from User:Dispenser/Double extension so that only the ones that still need to be fixed are left? Jonteemil (talk) 20:46, 28 May 2024 (UTC)

Searching with 'haswbstatement' doesn't seem to filter properly.

See here for an example. I'm searching in the File namespace for incategory:"Photos by Grendelkhan" -haswbstatement:P170, which brings up files which do have creator (P170) defined on them. If I switch to incategory:"Photos by Grendelkhan" haswbstatement:P170, I get zero results. I'm confused. According to mw:Help:Extension:WikibaseCirrusSearch, this should be filtering on the presence of a structured data field, but if anything it's doing the opposite? grendel|khan 15:18, 30 May 2024 (UTC)

as i'm writing:

1. Media in category "Photos by Grendelkhan" The following 200 files are in this category, out of 725 total.
2. incategory:"Photos by Grendelkhan" -haswbstatement:P170 -> Results 1 – 30 of 725
3. 725-725=0 = incategory:"Photos by Grendelkhan" haswbstatement:P170

RZuo (talk) 21:26, 30 May 2024 (UTC)

Exactly; all of those photos have creator (P170) statements on them, but the filtering isn't doing the right thing. grendel|khan 16:44, 3 June 2024 (UTC)

Tech News: 2024-23

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

Recent changes

• It is now possible for local administrators to add new links to the bottom of the site Tools menu without JavaScript. Documentation is available. [28]
• The message name for the definition of the tracking category of WikiHiero has changed from "MediaWiki:Wikhiero-usage-tracking-category" to "MediaWiki:Wikihiero-usage-tracking-category". [29]
• One new wiki has been created: a Wikipedia in Kadazandusun (w:dtp:) [30]

Changes later this week

• The new version of MediaWiki will be on test wikis and MediaWiki.org from 4 June. It will be on non-Wikipedia wikis and some Wikipedias from 5 June. It will be on all wikis from 6 June (calendar). [31][32]

Future changes

• Next week, on wikis with the Vector 2022 skin as the default, logged-out desktop users will be able to choose between different font sizes. The default font size will also be increased for them. This is to make Wikimedia projects easier to read. Learn more.

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

MediaWiki message delivery 22:32, 3 June 2024 (UTC)

Discussion at MediaWiki talk:Gadget-Cat-a-lot.js#MediaWiki:Mobile-frontend-return-to-page vs MediaWiki:Returnto

You are invited to join the discussion about localization of the Cat-a-lot gadget at MediaWiki talk:Gadget-Cat-a-lot.js#MediaWiki:Mobile-frontend-return-to-page vs MediaWiki:Returnto. —⁠andrybak (talk) 21:59, 4 June 2024 (UTC)