Thank you for your tireless high-quality coding work:) PantheraLeo1359531 😺 (talk) 19:46, 22 March 2026 (UTC)
Glad to be helpful:) -- DaxServer (talk) 19:07, 16 April 2026 (UTC)
Round 1 of Picture of the Year 2025 voting is open!
2024 Picture of the Year:Mundari man polishing the horns of one of his Watusi cows using a mixture of cow urine and ash as a ritualistic and protective practice in a temporary cattle camp in Terekeka, South Sudan.
Dear Wikimedian,
Wikimedia Commons is happy to announce that the 2025 Picture of the Year competition is now open. This year is the twentieth edition of the annual Wikimedia Commons photo competition, which recognizes exceptional contributions by users on Wikimedia Commons. Wikimedia users are invited to vote for their favourite images featured on Commons during the last year (2025) to produce a single Picture of the Year.
Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community in the past year are all entered in this competition. These images include professional animal and plant shots, breathtaking panoramas and skylines, restorations of historical images, photographs portraying the world's best architecture, impressive human portraits, and so much more.
For your convenience, we have sorted the images into topical categories. Two rounds of voting will be held: In the first round, you may vote for as many images as you like. The top 30 overall and the top 5% of most popular images in each category will continue to the final. In the final round, you may vote for just five images to become the Picture of the Year.
The idea of auto-applying the title template and the right align of draggable templates is a very good idea:) --PantheraLeo1359531 😺 (talk) 15:04, 8 April 2026 (UTC)
It was bugging me as well for some time to fix! -- DaxServer (talk) 17:05, 16 April 2026 (UTC)
@DaxServer, the discussion is now archived at COM:AN/Archive 104. There isn't a lot of work, we just need to know the correct place where replacement is needed. Shaan SenguptaTalk 06:12, 18 April 2026 (UTC)
Round 2 of Picture of the Year 2025 voting is open!
Dear Wikimedian,
You are receiving this message because we noticed that you previously voted in the Picture of the Year contest. Wikimedia users are invited to vote for their favourite images featured on Commons during the last year (2025) to produce a single Picture of the Year.
Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community in the past year were entered in this competition. These images include professional animal and plant shots, breathtaking panoramas and skylines, restorations of historical images, photographs portraying the world's best architecture, impressive human portraits, and so much more.
In this second and final round, you may vote for a maximum of five images. The image with the most votes will become the Picture of the Year 2025.
I found a Mapillary API integration on Github (https://github.com/mapillary/api-demo), which may include useful functions for the Curator tool! The implementation of a sequence preview on a map is also a splendid implementation. Also thanks for fixing the tool;). Best regards --PantheraLeo1359531 😺 (talk) 14:45, 20 April 2026 (UTC)
@PantheraLeo1359531 That looks pretty good. Something I'm looking forward to integrate and provide good experience in Curator;) -- DaxServer (talk) 16:09, 20 April 2026 (UTC)
If you believe the content does not meet the criteria for speedy deletion, you may replace the speedy deletion tag with a regular deletion request (if the content has not been deleted) or request undeletion (if the content has already been deleted).
All your uploads, including deleted ones, are listed in your upload log.
If you need help, please read our frequently asked questions or visit the help desk. Please do not remove this message from your talk page. You may set up archiving instead.
I have a question about Curator and the upload procedure. Let's say I create 10 upload batches (1000 images in every sequence) and the batches are not processed one after another, but simultaneously with 3 or even 10 threads per batch. What would the upload rate limit be and what parameters have to be considered? First, I read somewhere that Mapillary allows 50k API accesses per day. Second, Wikimedia Commons allows only a limited edit rate of maybe 999 in 3 minutes or so, and maybe the toolforge servers also have a limited resource management. I am just curious how far the boundaries at least in theory can be measured :D. Best regards and have a nice weekend:) --PantheraLeo1359531 😺 (talk) 19:51, 24 April 2026 (UTC)
We're close to 1M transfers and it might be interesting to figure out how high the process rate in maximum should be and how to handle the ingested data (in the future) :D. --PantheraLeo1359531 😺 (talk) 19:54, 24 April 2026 (UTC)
Hi @PantheraLeo1359531 That's indeed a great milestone.. thanks for making it happen! 🙏
I'll get back to you in a couple of days on the uploading internals. Just exploring Milan before the hackathon over this weekend.. I plan to add the filtering that you've requested over this period. -- DaxServer (talk) 15:46, 28 April 2026 (UTC)
Sounds exiting! Take care of yourself;). Over the time, we see more people using the tool. Slowly but surely the tool is used more and more by more users in the community :D. Have a nice time :3 --PantheraLeo1359531 😺 (talk) 18:23, 28 April 2026 (UTC)
Upon creating a batch upload, the ratelimits for the account is looked up https://commons.wikimedia.org/w/api.php?action=query&meta=userinfo&uiprop=ratelimits which lists out all sorts of rate limits for various actions grouped by usergroup. We need upload and edit ratelimits. For each of those, the most permissive limit is considered.
For example, for my account and probably yours at that link, we will see user and patroller under each action type. For uploads, we see 480 per 4320 seconds under user and 999 per 1 second under patroller group - thus the most permissive would be 999 per 1 second for upload. The same is checked for edit.
For each image, we consume 1 upload and 2 edit: 1 upload to upload the image, 1 edit to add SDC and 1 edit to perform null edit to purge cache so that the infobox shows data from SDC. (I'm not sure if the null edit consumes an edit, so I just considered it would so that there will least amount of rate limit errors on Curator.)
Now, of these two different rate limits (upload and edit), the most restrictive one is selected (e.g., 20 per second vs 40 per second - most restrictive would be 20 and most permissive would be 40). I went with the restrictive so that there'd be least amount of rate limit errors :P
Once the rate limit is determined, the uploads are queued at that time intervals with 1.5x additional time buffer. For example, effective rate limit is now 10 per minute - that'd be one task per 6 seconds. So, the tasks are queued at an interval of 6*1.5=9 seconds.
This calculation counter is preserved so that new batch creations would be scheduled after the last scheduled task in the future. Once all the tasks are done and move past that "next task should be at" calculation counter, the counter would be in the "past" and so is invalid and would be reset to "now" and the cycle goes on. The calculation counter is per user as one's uploads do not affect another's.
At the moment, there is only a single queue and all the [scheduled] tasks from all the users go into that. I'm running three parallel threads that work on these tasks as you see "3 in progress" for most of the time. There was a time where I experimented with different queues, but switched back to single queue. I think I want to revisit that approach so that uploads from different users could be processed a bit better.
Maybe, I'll get some ideas from fellow hackers here in the next couple of days.
Let me know if you've questions on this process. Happy to expand on anything! -- DaxServer (talk) 15:21, 30 April 2026 (UTC)
Thank you for your detailed answer! It helps to understand the process a lot. I can remember that in a very rare case, I had an upload error because I simultaneously had a VFC batch running XD. The question came to me again because it fits into a bigger picture: How much files can and will Commons collect? A user asked why a batch upload was "approved" (they didn't know you didn't need permission). I filed a request to upload NAIP imagery. We have now >100 TB archived on Commons, a lot of course! But the increase of collected data grows exponentially, the Internet Archive hosted 170 petabytes in 2024 (unique data). Mapillary has more than 3 Billion images now.
Of course, a lot of images is of very low quality and some are duplicates or just equipped with wrong metadata. But if even if we want (and this may be discussed) to backup only 3% of the imagery NOW, we end up having 90 Million files as of 2026. A higher process rate would make this easier to process in a faster time. But of course, increasing the upload rate means the chance of upload failures rises. Some Mapillary users are very diligent to create sequences with several thousand images, every day. This would fit into the pattern that Commons will get huge increases in the next years. But I see us on a very good track and yes, maybe some fellows have some ideas, too:). --PantheraLeo1359531 😺 (talk) 17:10, 30 April 2026 (UTC)
Have fun! The descriptions and tool extensions show well how complex a project can get :D. I remember the first experiments with the Curator tool, and since then, the User Experience is far better:). It is a bit sad that some functions may not be implemented appropiately, because of the API limitations on the Mapillary side. I wish you a splendid time and a healthy discussion;). Best regards --PantheraLeo1359531 😺 (talk) 19:55, 30 April 2026 (UTC)
I am surprised what can be found on Mapillary. One sequence has 10,000 images. It's huge. I can imagine some larger roads in the world contain similar large batches. The data gets more and more:). By the way: Are you happy with the results/outcomes on the hackathon? --PantheraLeo1359531 😺 (talk) 18:16, 4 May 2026 (UTC)
10k? Huge!!!
I really liked the event, met a lot of people and defo had a great time. I'd say I'm pretty happy of the outcomes. I'm looking forward to see how things go from here! -- DaxServer (talk) 18:55, 5 May 2026 (UTC)
I am in the picture;) -- DaxServer (talk) 18:39, 6 May 2026 (UTC)
Happy to hear;). I am really glad to see so many people put their free time into building up infrastructure and pipelines curating free media. This is an effort that will bloom in the near future, with many people being relieved there were folks who made a positive difference :D. I bet you are the one waving hands 😉 --PantheraLeo1359531 😺 (talk) 08:06, 7 May 2026 (UTC)
Help needed
Hi! Two days ago (23.4.), I tried to upload some files using Curator. All uploads failed – it just says "query".
Can you tell me what I did wrong?
Thank you, Albinfo (talk) 10:21, 25 April 2026 (UTC)
Hi @Albinfo From the logs, I see that CSRF token retrieval for making edits is causing the error. I've added some more logs so we can get more info on the errors. Interestingly, this is only happening to your account. Can you logout in Curator and login again? -- DaxServer (talk) 15:47, 28 April 2026 (UTC)
Thanks for the confirmation, @Albinfo! I believe I figured out the cause and I'd be working on a handy solution in case such errors recur in the future. -- DaxServer (talk) 14:41, 30 April 2026 (UTC)
Map of Bremke
Hallo DaxServer, du hast vor einigen Jahren eine Reihe von Karten auf dem Gebiet von Eslohe hochgeladen: Category:Maps of Eslohe. Der Ortsteil Bremke kommt dabei ungünstig weg, da der Blattschnitt mitten durch den Ort verläuft. Wäre es möglich, eine Karte hochzuladen, die Bremke zentriert zeigt. Vielen Dank und Grüße Milseburg (talk) 10:43, 3 May 2026 (UTC)
Hallo @Milseburg! @PantheraLeo1359531 kennt sich mit diesem Thema besser aus als ich. Kannst Du bitte dich an Sie wenden, die Unterstützung zu bitten? Vielen Dank, VG! -- DaxServer (talk) 12:50, 3 May 2026 (UTC)
@Milseburg Guten Tag! Ja, in diesem Fall leider werden die Karten so gekachelt, dass sie durch einige Ortschaften gehen. Ich kann gerne eine Karte hochladen, die deinen Wünschen entspricht. Grüße! --PantheraLeo1359531 😺 (talk) 12:57, 3 May 2026 (UTC)
Hi @Kleeblatt187 Thanks for reaching out to me with this discrepancy. I've update the module to have the same sort keys as the template. I've also updated the World photos to use the module. I did a null edit for a couple of categories that you mentioned with the - sortkey and they are now under G, like before. Do you also want me to track down inconsistently sorted categories and do a purge for them? -- DaxServer (talk) 20:30, 5 May 2026 (UTC)
Hi, thanks for your quick response and fixing this! Thanks a lot! If it's not too much work, I would appreciate if you would purge those categories somehow automatically . And if not, I'll be fine. Purging will happen happen some day anyway. Greetings, Kleeblatt187 (talk) 20:45, 5 May 2026 (UTC)
Sounds good! I'll try to gather that list and do the purge over the next few days. For now, I'll go and sleep;) Bis dann! -- DaxServer (talk) 20:47, 5 May 2026 (UTC)
Is it possible for the categories to keep their previous sort key (which was the first letter of the category) for just the "Photos taken on YYYY-MM-DD" categories? Currently the only categories with the sort key * there are for photos-by-day that are not of countries (railway photos, photos of the sun, photos of mars, photos of the ISS) while the countries were sorted alphabetically, but now they're all grouped together. ReneeWrites (talk) 20:41, 5 May 2026 (UTC)
Hi @ReneeWrites I've updated that as well just before my reply above. They should now behave like the previous one, they just need to be null-edited so that the cache will be purged. -- DaxServer (talk) 20:46, 5 May 2026 (UTC)
Thank you for the (very!) fast response:) ReneeWrites (talk) 20:50, 5 May 2026 (UTC)
