Shortcuts: COM:VP/T • COM:VPT

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.

Please note
 
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 edit

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)Reply

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)Reply
Same for me: moving categories does not work, moving files works. --Reinhard Müller (talk) 14:49, 16 February 2024 (UTC)Reply
I confirm that it is not working. Theklan (talk) 09:36, 24 February 2024 (UTC)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

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

  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)Reply

the solution would be to revert phab:T355636. Can someone do that? Enhancing999 (talk) 15:25, 17 April 2024 (UTC)Reply
No we can just apply this change to Cat-a-lot, as Tacsipacsi indicated above. Nardog (talk) 16:03, 23 April 2024 (UTC)Reply
Can someone actually implement the fix? Smasongarrison (talk) 22:03, 23 April 2024 (UTC)Reply
Only an interface admin can. Nardog (talk) 20:40, 24 April 2024 (UTC)Reply
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)Reply

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)Reply

  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 edit

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)Reply

Maybe you could run it through the "icons" category to test. Enhancing999 (talk) 10:53, 9 April 2024 (UTC)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
@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). Sdkbtalk 04:48, 10 April 2024 (UTC)Reply
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)Reply
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. Sdkbtalk 14:17, 10 April 2024 (UTC)Reply
@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)Reply
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)Reply
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)Reply
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. Sdkbtalk 16:29, 9 April 2024 (UTC)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply
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)Reply

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)Reply

New tool for cropping and rotating images (proposal) edit

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)Reply

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)Reply
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)Reply
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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
@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)Reply
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)Reply
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)Reply
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)Reply

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

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

Yes, I got that too. I believe it was a temporary glitch. Yann (talk) 17:14, 5 May 2024 (UTC)Reply
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)Reply

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

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)Reply

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)Reply
The problem is still happening intermittently. Nurg (talk) 01:25, 7 May 2024 (UTC)Reply
I have opened a call at https://phabricator.wikimedia.org/T364360. Nurg (talk) 01:50, 7 May 2024 (UTC)Reply
I received this kind of error, too. Seems to be a larger problem --PantheraLeo1359531 😺 (talk) 15:33, 10 May 2024 (UTC)Reply

New tool for importing SteamGridDB images edit

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)Reply

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)Reply
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)Reply

Tech News: 2024-19 edit

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

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)Reply

@Multichill: Ymblanter (talk) 19:46, 8 May 2024 (UTC)Reply
I see, the issue is somewhere with the syntax, instead of hidden categories redlinks are created. Ymblanter (talk) 19:51, 8 May 2024 (UTC)Reply
@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)Reply
Tnx. Ymblanter (talk) 22:40, 8 May 2024 (UTC)Reply

Tech News: 2024-20 edit

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

HotCat edit

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)Reply

Are you sure you mean HotCat and not Cat-a-Lot ? —TheDJ (talkcontribs) 11:23, 15 May 2024 (UTC)Reply
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)Reply

Changes to upload by URL edit

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)Reply

Tech News: 2024-21 edit

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

Javascript issue edit

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)Reply

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

Is it possible to search EXIF tags? edit

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)Reply

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)Reply

Replicating s:Module:Copyright-until here edit

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)Reply

Tech News: 2024-22 edit

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

User:Dispenser/Double extension edit

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)Reply

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

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)Reply

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)Reply
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)Reply

Tech News: 2024-23 edit

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

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)Reply