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/03/Archive/2024/04.
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]
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]
Images from Commons not being shown on Facebook[edit]
Hello. About two weeks ago Facebook seemed to stop showing images from links to Commons files. I do not know if that problem has been discussed here, but it still persists. For those of us who regularly post links in Facebook groups it is a great inconvenience, also given that all the existing links stopped showing images. Facebook obviously thinks that there is something wrong with the setup of Wikimedia Commons, but it is impossible for a common user as I to ask them what is wrong. Does anybody at Wikimedia Commons know what has changed? Cheers Rsteen (talk) 03:48, 16 March 2024 (UTC)[reply]
Thanks for the info. I can see that the phab was assigned on March 6, so it would have been nice to get an answer at an earlier date from one of those involved with the phab. Cheers Rsteen (talk) 03:22, 12 April 2024 (UTC)[reply]
Image appears but doesn't appear although appear[edit]
W3C reports 2 errors. Namespace http://www.openswatchbook.org/uri/2009/osb not on whitelist. Used in linearGradient6213 and linearGradient4061. Both are single-stop gradients. Both gradients are unused. Nuked.
File has more than usual Inkscape verbiage. There are a lot of style="...;line-height=0%;...". There are empty g elements.
Now the question is: What to do? Ignore? Fix? I have a Bot in deWP and 7 years experience with this bot, but no idea with the bot policy here. --Wurgl (talk) 17:55, 24 March 2024 (UTC)[reply]
As I said: About 2000 affected pages for deWP, these 5 are just random examples. (I did not check any other language) --Wurgl (talk) 21:00, 24 March 2024 (UTC)[reply]
Right, but {{Districts of Saarbrücken Navi}} is used on 1586 categories and is the source for 2 of the 5 categories that you chose at random. It might be the cause of a big fraction of the 2000 affected pages that you identified. Commons bot policy is fairly permissive. You can read the policy at Commons:Bots and post at Commons:Bots/Requests if you want permission to run your bot on Commons. It might take a while to get approval, the Bot request board moves slowly. —RP88 (talk) 22:12, 24 March 2024 (UTC)[reply]
There are a 10 lines with "did not match" where that bad link is created magically by some template.
7 cases (use search pattern " ---") seem to by mistyped links to deWP, maybe these could be fixed manually, currently the bot transforms these links into plain text. --Wurgl (talk) 20:22, 9 April 2024 (UTC)[reply]
Thanks for uploading a log of the results, although it is hard to validate the proposed edits since the bot did not log the names of the pages to which the proposed edits applied. From what I am able to ascertain the results are probably OK — it is nice to see that fixing {{Districts of Saarbrücken Navi}} cut the number of pages that needed a fix down to around 500. I would recommend that in the cases where the bot detects what are possibly mistyped links that it not transform them into plain text, it should instead leave them alone (although I certainly wouldn't object to you fixing them manually, should you choose to do so). The suggested edits might also be adding extraneous blank lines, but I couldn't verify that without knowing the pages to which the proposed edits applied. —RP88 (talk) 20:39, 9 April 2024 (UTC)[reply]
Oops. Sorry. I run it again. For the mentioned possible typos, I have code (currently commented out) which changes [[de:article to [[:de:article --Wurgl (talk) 21:07, 9 April 2024 (UTC)[reply]
I've taken a look at your new log. For an example of an edit where the bot should not convert an interwiki link to plain text, see the proposed edit to Category:Coordinates_templates. The bot is proposing to convert {{Category redirect|Commons geocoding}}[[de:Kategorie:Vorlage mit Koordinate]] to {{Category redirect|Commons geocoding}}Kategorie:Vorlage mit Koordinate. The ideal change would be to fix the interwiki to the correct interwiki of [[de:Kategorie:Vorlage:mit Koordinate]]. Since the bot isn't able to make that fix, it should leave the original incorrect interwiki alone, not convert it to plain text. For an example of an edit where the bot is inserting an extraneous blank line, see the proposed edit to Category:Alejandro_Barberón. The bot proposes to add a blank line in the middle of a list of interwiki links. —RP88 (talk) 21:25, 9 April 2024 (UTC)[reply]
I really should not do such tasks in the late evening. I hope it is fixed now. Sorry. Those mentioned 7 cases need manual fixes, they are a little bit to different. --Wurgl (talk) 22:03, 9 April 2024 (UTC)[reply]
@Wurgl: Sorry, I had to step away for a couple of hours. I've looked at your latest log. I noticed the following issues, but I am not sure if they are problems:
Something weird, maybe due to trailing spaces at the end of line, appears to be happening at Category:Riaboshenko,_Anatoli.
It's probably unnecessary, and very nit-picky, but it would be nice that when there is a blank line before and after an interwiki link that ends up being removed, that the two blank lines that are now adjacent be converted into a single blank line. Examples are at Category:Verlegung_Stolperstein_Albert_Richter and gallery Buchholz-Orgel_Stralsund.
There are some blocks of text in the middle of the log that seems to indicate a problem occurred, but not does not appear to be associated with the immediately preceding or following page in the log. Here are three samples, but there are many more:
File: Category:1878 in fil/m Pattern @(.\[\[ *)([dD]e *:+ *(Filmjahr[_ ]1878) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
File: Category:Grave of Ludwig Zatzka Pattern @(.\[\[ *)([dD]e *:+ *(Gruppe[_ ]17[_ ]Nummer[_ ]30;[_ ]Mosaik[_ ]Leopold[_ ]Forstner) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
File: Category:Photos by User:Johann56 Pattern @(.\[\[ *)([dD]e *:+ *(Photos[_ ]by[_ ]User\:Johann56) *(#[^|\]]*)?(\|[^\]]*)?\]\])@s did not match
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
An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in Vector 2022 skin. A checklist is provided for site admins to follow.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar). [1][2]
@RZuo I just fixed SteinsplitterBot. It looks like when they did the migration to the new jobs system they forgot to migrate this one. But it should be working now, and will run daily in the future. Feel free to ping me if it stops, or if you notice any other issues with SteinsplitterBot (I have full access to the tool.) —Mdaniels5757 (talk • contribs) 23:15, 25 March 2024 (UTC)[reply]
@Sikander: As far as I can tell, the horizontal Category TOC on that page is working fine. I tried several different browsers as well as both logged in and logged out. I suspect the issue is at your end, perhaps try emptying your browser cache. —RP88 (talk) 18:03, 1 April 2024 (UTC)[reply]
Ah, seeing Enhancing999's replies led me to think what you might have meant by "doesn't work". In my reply I was saying that I saw {{CategoryTOC}} correctly displaying and working exactly as intended (but apparently not how you probably expected). As Enhancing999 implied, the template {{EC-Audiovisual Center}} invokes {{LicenseReview}}, which (while in the needs review state) uses Template:LicenseReview/layout-reviewme, which sets [[Category:EC-Audiovisual Center review needed|< PAGEID >]]. So the files in this particular category are sorted by their page id, like all other license review needed categories. —RP88 (talk) 18:43, 1 April 2024 (UTC)[reply]
Hmm... depending on what exactly you want to do, you might be able to use Special:Search with incategory:"EC-Audiovisual Center review needed" and then adjust the advanced search fields. This won't get you an alphabetically ordered list, but it would let you search the contents of the category. —RP88 (talk) 20:13, 1 April 2024 (UTC)[reply]
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
Users of the reading accessibility beta feature will notice that the default line height for the standard and large text options has changed. [3]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 2 April. It will be on non-Wikipedia wikis and some Wikipedias from 3 April. It will be on all wikis from 4 April (calendar). [4][5]
Future changes
The Wikimedia Foundation has an annual plan. The annual plan decides what the Wikimedia Foundation will work on. You can now read the draft key results for the Product and Technology department. They are suggestions for what results the Foundation wants from big technical changes from July 2024 to June 2025. You can comment on the talk page.
On an immediate level, that's because the {{Subject by century}} template (which is used to implement templates like {{Centuries BC in Romania}}) only runs from the 50th century BC to the 25th century CE. It will not display categories which lie outside those bounds.
Realistically, the use of year-based categories for time periods well outside recorded history like "49th century BC" may not be appropriate, as the margin of error on dates that far back is often wider than a century. (Nor am I convinced that it's correct to describe subjects like the Turdaș culture as being "in Romania" over five thousand years before any such country existed.) Omphalographer (talk) 00:02, 4 April 2024 (UTC)[reply]
Mobile versions of user talk pages are useless[edit]
Though I'm not active on Commons, I got bored and used my mobile device to look through some deletion requests, then at at a user's talk page. I knew that user had several deletion requests, but saw only one on their talk page. The talk page's history showed that old sections were archived, which was fine, but the page seemed to have no links to those archives.
I couldn't find the 'Read as wiki page' (or whatever it is) option, so out of desperation, I switched to the desktop version of the page. I was shocked at what I found there: not only the archive links, but also a notice that the user had been blocked indefinitely. (Before that, I hadn't seen any reference to a block.)
In summary, the mobile versions of user talk pages (and perhaps talk pages in general) are so crippled as to be useless. Brianjd (talk) 08:22, 4 April 2024 (UTC)[reply]
Yes, the mobile experience has always been really bad and as someone who basically exclusively edits with a mobile device it's not a fun experience. The worst part is that in most of the developing world the vast majority of people who surf the web do so using a mobile device. Not too long ago the experience of talk pages on mobile devices wasn't this bad, but they basically made it worse during an update a few months ago. After many, many years of neglecting the mobile experience I sincerely doubt that the developers are planning on fixing it anytime soon. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:47, 9 April 2024 (UTC)[reply]
That might go to far, to be honest, the best solution would be to make the mobile version identical to the desktop version but tailored for smaller screens, though the Wikimedia Foundation (WMF) have confirmed multiple times that they will not do that. I have no idea why they insist on delivering an inferior and often infuriating experience to us mobile users, but there doesn't seem to be much we can do about it. De-activating it would break more than it would fix. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:44, 17 April 2024 (UTC)[reply]
I wonder what there is to break. Consider file description pages: mobile version lacks have of the content (categories).
I think the skin running on each WMF site is determined by the communities. Accordingly, e.g. dewiki doesn't use the same as enwiki, as they consider it not suitable. Enhancing999 (talk) 15:49, 17 April 2024 (UTC)[reply]
I don't think it's available without login. We could keep the default mobile view from logged in users who require it (e.g. WMF staff for testing purposes). Enhancing999 (talk) 18:14, 17 April 2024 (UTC)[reply]
Yes, this "solution" only works if you have a Wikimedia SUL account and happen to know where to find the button to enable it. Imagine you're a re-user looking for similar images (or other files) from a certain category and can't figure out how to do that. Most people surf the web on mobile devices these days, this is especially true for people from developing countries. When I was in the rural Philippines a few weeks ago I met several people who have never worked with or used a laptop or desktop computer in their lives but all use smartphones, even homeless people have smartphones, these are the most affordable internet-connected devices for most people in the world. Yet, for whatever reason "the mobile experience" of Wikimedia websites is beyond bad. If possible we should put it to a vote to show the MediaWiki developers that we don't want to suppress vital information for a major part of the audience. Files are for re-users and if they can't find the files then there's something seriously wrong with the system. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:34, 17 April 2024 (UTC)[reply]
I have been impression that "advanced mode" is for things in beta testing, not ready for primetime, for whatever reason. We could though ask what are plans to primetime it. --Zache (talk) 18:40, 17 April 2024 (UTC)[reply]
Is there any way to get a list of users who uploaded images which appear in a Commons category?[edit]
Hi all
I'm working on some documentation around organising photography events and competitions and would really like to find a way to do this e.g I want to get a list of all the user names of uploaders for all the images in the category and all subcategories for Category:Potatoes. It would be a way to understand who is interested in the topic. I have a feeling this info might also be really useful for people who run the Wiki Loves photo competitions as well e.g 'this many people took part this year' although they may have other ways to do this.
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
Web browsers can use tools called extensions. There is now a Chrome extension called Citation Needed which you can use to see if an online statement is supported by a Wikipedia article. This is a small experiment to see if Wikipedia can be used this way. Because it is a small experiment, it can only be used in Chrome in English.
A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
Readers using the Minerva skin on mobile will notice there has been an improvement in the line height across all typography settings. [8]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 9 April. It will be on non-Wikipedia wikis and some Wikipedias from 10 April. It will be on all wikis from 11 April (calendar). [9][10]
New accounts and logged-out users will get the visual editor as their default editor on mobile. This deployment is made at all wikis except for the English Wikipedia. [11]
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]
@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]
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.
@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). Sdkbtalk04: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…!
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. Sdkbtalk14: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.
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. Sdkbtalk16: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:
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.
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]
How do I flag my bot’s edits as coming from a bot?[edit]
I'm using the wbeditentity API and setting the bot=1 query parameter like it suggests, but the edits aren't being flagged as bot edits.
This means that when I run the bot, the edits can overwhelm people’s watch lists (see feedback here: User talk:FlickypediaBackfillrBot#BOT flag).
I notice the wbeditentity API says This URL flag will only be respected if the user belongs to the group "Bots" – but this user is part of the "Bots" user group, isn't it?
@Alexwlchan, i tried to replicate the problem and by using pywikibot your post parameters are looking good. Maybe one thing what you could try is to check if the bot flag is working when you are doing edits through pywikibot? (to see if there is some problem with the user rights. Though afaik bot flag should be working.)
If I run your code, I do see my edits showing up with the bot flag, so it must be a bug on my side. I'll have a look through the pywikibot code to understand what I’m doing differently and find my mistake. Alexwlchan (talk) 13:30, 11 April 2024 (UTC)[reply]
Right, the issue seems to be how I'm authenticating – I'm using a Personal API token whereas the Pywikibot code is using some login cookies to make its request. I think I need to take a closer look at my auth code. :) Alexwlchan (talk) 15:20, 11 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.
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 ! talk12:46, 18 April 2024 (UTC)[reply]
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:
Edit an image (by cropping or rotating), while otherwise preserving image quality and metadata.
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]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
Problems
Between 2 April and 8 April, on wikis using Flagged Revisions, the "Reverted" tag was not applied to undone edits. In addition, page moves, protections and imports were not autoreviewed. This problem is now fixed. [12][13]
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 16 April. It will be on non-Wikipedia wikis and some Wikipedias from 17 April. It will be on all wikis from 18 April (calendar). [14][15]
Default category sort keys will now affect categories added by templates placed in footnotes. Previously footnotes used the page title as the default sort key even if a different default sort key was specified (category-specific sort keys already worked). [16]
A new variable page_last_edit_age will be added to abuse filters. It tells how many seconds ago the last edit to a page was made. [17]
Future changes
Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more.
Four database fields will be removed from database replicas (including Quarry). This affects only the abuse_filter and abuse_filter_history tables. Some queries might need to be updated. [18]
Module:Autotranslate was altered today to use more efficient test for presence of a language subtemplate. The new version was tested extensively, but please be on a lookout for any issues with templates using it. Please ping me if any issues are found or suspected. Jarekt (talk) 13:34, 18 April 2024 (UTC)[reply]
Anybody know if the feature is still being maintained? I reported a problem a while back about the impossibly to remove wrong statements, but it's still broken. Enhancing999 (talk) 07:44, 20 April 2024 (UTC)[reply]
Latest tech news from the Wikimedia technical community. Please tell other users about these changes. Not all changes will affect you. Translations are available.
You can nominate your favorite tools for the fifth edition of the Coolest Tool Award. Nominations will be open until May 10.
Changes later this week
The new version of MediaWiki will be on test wikis and MediaWiki.org from 23 April. It will be on non-Wikipedia wikis and some Wikipedias from 24 April. It will be on all wikis from 25 April (calendar). [20][21]
Future changes
This is the last warning that by the end of May 2024 the Vector 2022 skin will no longer share site and user scripts/styles with old Vector. For user-scripts that you want to keep using on Vector 2022, copy the contents of Special:MyPage/vector.js to Special:MyPage/vector-2022.js. There are more technical details available. Interface administrators who foresee this leading to lots of technical support questions may wish to send a mass message to your community, as was done on French Wikipedia. [22]
Question Is there any chance that we get an indication of:
An update was made on March 18th 2024 to how various projects load site, user JavaScript and CSS in Vector 2022 skin. A checklist is provided for site admins to follow.
The new version of MediaWiki will be on test wikis and MediaWiki.org from 26 March. It will be on non-Wikipedia wikis and some Wikipedias from 27 March. It will be on all wikis from 28 March (calendar). [1][2]
A new Edit Recovery feature has been added to all wikis, available as a user preference. Once you enable it, your in-progress edits will be stored in your web browser, and if you accidentally close an editing window or your browser or computer crashes, you will be prompted to recover the unpublished text. Please leave any feedback on the project talk page. This was the #8 wish in the 2023 Community Wishlist Survey.
_alterna.png){kind=link}
.jpg){kind=link}
