From Wikimedia Commons, the free media repository

Shortcut: COM:VP

#	💭 Title	💬	👥	🙋 Last editor	🕒 (UTC)
1	Vector 2022 will be the default skin	12	10	Jon (WMF)	2025年02月24日 20:37
2	Brunei Darussalam Newsletter	0	0
3	Discussion of sockpuppetry issue for Anonymous Hong Kong Photographer 1 on Meta	32	6	HingWahStreet	2025年03月02日 06:03
4	Category for passage from street to courtyard	18	6	Jmabel	2025年02月25日 20:43
5	Mass-archiving of endangered US-government datasets	12	4	PantheraLeo1359531	2025年02月24日 14:09
6	Actions regarding post-ban of Shāntián Tàiláng	4	2	MGeog2022	2025年02月27日 14:29
7	We are hosting the wrong Wikipedia icon	2	1	Nosferattus	2025年02月26日 21:57
8	Flickr2Commons problems again	5	2	Jmabel	2025年02月24日 22:26
9	Which categories?	3	3	ReneeWrites	2025年02月25日 08:54
10	Naming of Category:PD-Art (Yorck Project)	1	1	BMacZero	2025年02月24日 17:46
11	Category:License review needed	7	5	MGA73	2025年02月28日 07:54
12	Word, category for	3	3	Nakonana	2025年02月25日 17:02
13	Swiss local trains in France	1	1	Smiley.toerist	2025年02月25日 16:17
14	Wiki Loves Bangla 2025 has begun—Join us!	1	1	Moheen	2025年02月25日 17:47
15	What has happened to the instructions on reusing a file?	3	2	Jmabel	2025年02月25日 21:36
16	Central banner request for Wiki Loves Bangla 2025 contest	1	1	Moheen	2025年02月26日 07:23
17	Standard way to add an image ID in {{Information}}	7	3	D-Kuru	2025年02月28日 21:23
18	Do we have a category for images that are now censored by the source?	2	2	ReneeWrites	2025年02月26日 20:04
19	Categorisation by location	8	6	Multichill	2025年02月27日 22:54
20	Cascade protection	7	4	Jeff G.	2025年02月28日 18:10
21	Summaries of the last two Commons Community Conversations now available	4	2	Jeff G.	2025年03月01日 17:59
22	UploadWizard and license review	15	8	JWilz12345	2025年03月02日 12:50
23	Commons Gazette 2025-03	1	1	RoyZuo	2025年03月01日 01:55
24	video2commons not working	4	3	Prototyperspective	2025年03月02日 15:23
25	Webservice request timed out for glamorous tool on toolforge	1	1	Prototyperspective	2025年03月02日 16:02
26	Question to native English-speakers about correct category name	4	4	Jmabel	2025年03月02日 21:51
27	No to intimidation of volunteer contributors	1	1	Christian Ferrer	2025年03月02日 17:50

Legend
In the last hour
In the last day
In the last week
In the last month
More than one month
Manual settings
When exceptions occur, please check the setting first.

Centralized discussion See also: Village pump/Proposals    ■しかく Archive Commons_talk:Freedom of panorama#Proposal to abolish acceptance (2 March 2025) Categorization of SVG files (13 February 2025) RfC: Should Commons ban AI-generated images? (3 January 2025) Costumed character files (14 October 2024) Was the closure of the deletion discussion concerning the current lede image for Philippe Pétain proper under Commons policy? (22 September 2024) Third-party images published by the National Weather Service (26 August 2024) Commons:Requests for comment/Hosting of free fonts in Commons (18 July 2024) How do we organize categories by date (14 May 2024) Should PD-CQ Roll Call be used for recent images? (5 January 2024) Template: View    ■しかく Discuss    ■しかく Edit    ■しかく Watch

Hello. We are the Wikimedia Foundation Web team. We are here to announce that the Vector 2022 skin will become the default desktop skin here on 10 February. We will gladly answer your questions, concerns, or additional thoughts! We will also help you adjust things which Vector 2022 may not be compatible with. Check out our FAQ – you will find many useful answers there.

If you are using Vector legacy skin, you may find yourself receiving the Vector 2022 skin. You may select Vector legacy as your global preference to avoid seeing the change. Logged-in users can at any time switch to any other available skins, or stay with Vector 2022 and enjoy choosing between its light and dark mode. Users of other skins will not see any changes.

Why are we changing the skin now

For technical reasons (listed below), we need to deploy the skin soon. After deployment, we will continue discussing issues and questions about the interface, and we'll be ready to work with you on various issues like gadget compatibility.

How to request changes to the skin

We are guessing that some of you may want to see some changes to the skin. We are still improving Vector 2022 and the overall reading experience. If you have a feature request or a bug report, we encourage you to comment here or open a ticket in Phabricator. We will decide on the priority of these requests alongside our regular processes after deployment. Some fixes may be done via gadgets or user scripts, too.

About the skin

We encourage you to try out Vector 2022 by going to the Appearance tab in your preferences and selecting it from the list of skins. Getting used to it may take a few days, and that's the standard for interface changes.

How will we go through the change

• Wiki page: we would like to kindly suggest creating a page similar to English Wikipedia's w:WP:V22. It may explain the basics like how to opt-out or customize the skin.
• CentralNotice banner for logged-in users: before and shortly after deployment, we will display a banner announcing the change. It will be linking to Commons:Vector 2022 if you decide to create such a page. Otherwise, it will be linking to this announcement. This should limit the confusion and the number of repetitive questions about the change.

If you think there are any significant technical issues, let us know – perhaps we've missed something. We're looking forward to your comments and reactions from readers after deployment. Thank you! OVasileva (WMF) and SGrabarczuk (WMF) (talk) 01:06, 24 January; Unarchiving to keep this here SGrabarczuk (WMF) (talk) 19:20, 14 February 2025 (UTC) [reply ]

This is great news! I've been using Vector 2022 here for over a year now without issue, and it's important that Commons looks the same to users as the other Wikimedia projects. Thanks. Mike Peel (talk) 19:25, 10 February 2025 (UTC) [reply ]

Personally I'm hating it.StarTrekker (talk) 07:06, 11 February 2025 (UTC) [reply ]

I think I don't like some things either. However, it takes some time to get used to it and afterwards one likes it more than the prior skin. It would be good to name some things that may be problematic if there are any so it could get improved upon. For example, I think it may make the links to the Welcome and Community portal pages and possibly a few other things like the link to the page information page with the Pageviews link too hard to find. Prototyperspective (talk) 13:18, 11 February 2025 (UTC) [reply ]

I think the links to the Wikipedia articles are now too hidden, especially for users not very familiar with the site. I think the Wikipedia article of the language the user has configured with a fallback to the English article if there's no article in that language should be linked well-visibly, for example right before the category description at the top of the page. Prototyperspective (talk) 18:14, 12 February 2025 (UTC) [reply ]

It has been around for a quite long time in Wikipedia and other wikis. Software changes are often disruptive at first, but once you get used to them, you don't want to go back. MGeog2022 (talk) 18:30, 12 February 2025 (UTC) [reply ]

Amazingǃ Comfortable visual consistent across the projects. Thanks. Ong Kai Jin (talk) 13:02, 11 February 2025 (UTC) [reply ]

@OVasileva (WMF) @SGrabarczuk (WMF): I think it makes sense as a whole. But there are a couple of things that I don't understand and that I think are relevant to all readers and users. I suppose this has been discussed before.

• I don't really see how other Wikimedia projects are "Tools." I doubt readers will look for them there. It also doesn't seem ideal to have to scroll in a drop-down menu, in a lot of cases. Why not a separate "In other projects" tab?
• In the file namespace, perhaps the "Download," "Use this file" etc menu shouldn't be to the right of the previewed filed, since it can overlap awkwardly with the default position of the "Appearance" settings. Or is it an intentional choice that "Appearance" can overlap with other elements?

Sinigh (talk) 14:18, 11 February 2025 (UTC) [reply ]

Tracked in MediaWiki talk:Gadget-Stockphoto.js#Vector 2022 vertical support Jon Robson, WMF 20:37, 24 February 2025 (UTC) [reply ]

I've seen Appearance panel was overlapped on right side. [1] -- Great Brightstar (talk) 05:39, 16 February 2025 (UTC) [reply ]

• I've just edited Commons:File_renaming to match the new skin. Is the "More" menu completely replaced by "Tools"? CMD (talk) 08:28, 16 February 2025 (UTC) [reply ]

  Yes, I can see the "Rename" link in the "Tools" menu after logged in. -- Great Brightstar (talk) 17:43, 17 February 2025 (UTC) [reply ]

Now I see the stockphoto layout panel moved to the top of image. This is fixed. -- Great Brightstar (talk) 14:22, 3 March 2025 (UTC) [reply ]

Hello! I came across the Brunei Darussalam Newsletter, where some of the older issues contain a sidebar on the left side of page 2 that states: "Brunei Darussalam Newsletter is published fortnightly by the Department of Information. It reports on government, social and business events in the country. All money values are expressed in Brunei dollars ,ドル unless otherwise stated. Any information in this newsletter may be reproduced; a clipping of the publication would be appreciated. For free subscription (Excluding postage) write to Information Department, Jalan Stoney, Bandar Seri Begawan 2041, Brunei Darussalam." An example would be here. So my question is whether the term "information" in that specific issue could also apply to images.

This has been previously used in "Category:Ministry of Foreign Affairs (Brunei) News Digest issues". — Preceding unsigned comment added by Pangalau (talk • contribs) 13:52, 3 February 2025 (UTC) [reply ]

Hello. I recently opened a request for comment on Meta regarding sockpuppetry issue of User:Anonymous Hong Kong Photographer 1. You can join the discussion here. 〈興 華 街〉📅 ❓ 13:48, 4 February 2025 (UTC) [reply ]

looking for the commons cat for the thing discussed in https://www.reddit.com/r/architecture/comments/9bxcqd/ask_what_is_such_a_passage_called_that_connects/ , which is said to be "de:wikt:Hauseinfahrt" in german.

also, this pic shows tracks laid with steel plates. any jargon for this?--RoyZuo (talk) 08:03, 15 February 2025 (UTC) [reply ]

Category:Passageways? (The steel plates are probably just for underground water runoff). --Adamant1 (talk) 08:12, 15 February 2025 (UTC) [reply ]

The steel plates are for the wheels of motor vehicles or carriages to avoid damage to the tiles on the floor. They are very common in older German mixed residential and industrial/workshop buildings. I do not know if there is a special term for these but something like "Building passageway carriage tracks" could be a reasonable name. I would not use only "tracks" to not mix them with railway tracks. GPSLeo (talk) 09:50, 15 February 2025 (UTC) [reply ]

@RoyZuo and Adamant1: See also Commons:Categories for discussion/2020/02/Category:Passages (architecture).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:35, 15 February 2025 (UTC) [reply ]

Also, if it's wider, it's a breezeway, but I see Category:Breezeways has some that are far narrower than where I think a native speaker would use that term, and should be recategorized as passageways. File:Seattle U - Engineering Building breezeway, looking south 03.jpg (at right) is close to the minimum to be properly a breezeway. - Jmabel ! talk 19:32, 15 February 2025 (UTC) [reply ]

@Jmabel: Can you change the size of your image so it's not a part of my post? I tried to resize it but nothing happened. Thanks. --Adamant1 (talk) 04:36, 16 February 2025 (UTC) [reply ]

Category:Driveways in Germany? That's what Wiktionary suggests[2]. And there are some images that are similar[3] [4] [5]. Or Category:Carriageways (which seems to be an even better fit). Or Category:Roadways through buildings. Nakonana (talk) 18:49, 23 February 2025 (UTC) [reply ]

I think clearly not Category:Roadways through buildings, because it seems to be for when an actual road passes right through the building, not a route into the courtyard. I suppose they are in some sense driveways, passageways, and carriageways. I'm guessing that if GPSLeo doesn't know a name for these as such, we have actually hit the rare case where even the German language lacks a specific word. - Jmabel ! talk 21:46, 23 February 2025 (UTC) [reply ]

If it was just about a German word, then there's also "Gebäudedurchfahrt" (e.g. used in a court decision by the Higher Regional Court Hamm: [6]). But of course there's no Commons category with that name. Nakonana (talk) 22:09, 23 February 2025 (UTC) [reply ]

Certainly a reasonable word, though, with an obvious etymology for anyone who knows German. Possibly what we should use, though I see it only gets 2180 Google hits, so even in German it must be a pretty obscure word. I presume the plural would be Gebäudedurchfahrten. - Jmabel ! talk 00:42, 24 February 2025 (UTC) [reply ]

@Jmabel: Google Translate says that would be "Building passages" in English. How about "Building entry passages," as connected to the road and distinguished from the 3! similar twisty little passages one would find in the original Adventure text game?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:05, 24 February 2025 (UTC) [reply ]

@Jeff G.: that's just a straight etymological translation, though; not sure there is any evidence that it is used. A Google search on "building passages" turns up nothing with this meaning in the first 30 hits. Instead, it's things like "Sailing Trips & Mile-Building passages". "Building entry passages" gets one Google hit; I guess this discussion will make it two. So no evidence for this expression with this meaning in English, and we are not supposed to make up arbitrary English names for things that have a solid name in another language; the question would seem to be whether Gebäudedurchfahrten is even at all common in German (2180 Google hits is not very encouraging, but they do seem to be relevant Google hits, unlike the English). - Jmabel ! talk 04:49, 24 February 2025 (UTC) [reply ]

There's the Scottish equivalent: Pend. As for Germany, while people might not know the word for those passages, they are definitely a common architectural feature in Germany. I know several such residential buildings in different cities in Germany. Nakonana (talk) 18:31, 24 February 2025 (UTC) [reply ]

"they are definitely a common architectural feature in Germany": Absolutely, and in much of Central and Eastern Europe. That's why I want to set up a category.

For now, I'm going to make this Category:Gebäudedurchfahrten. If someone thinks there is a better name, renaming categories is not all that difficult. - Jmabel ! talk 20:23, 24 February 2025 (UTC) [reply ]

@Nakonana: could you explain further on "pends"? Category:The Radical Pend, for example, does not look like it leads to a courtyard. Ditto for Category:The Pends. - Jmabel ! talk 20:34, 24 February 2025 (UTC) [reply ]

I'm definitely no expert on this stuff. The Pends seem to be the remnants of what would have qualified as Gebäudedurchfahrt in the past but is now in ruins. "Ruins of Gebäudedurchfahrten" so to speak. From this website: "At the east end of South Street there is a pair of fourteenth-century arches known as "the Pends". These were part of a gateway to the walled enclosure surrounding St Andrews Cathedral. During the Middle Ages many cathedrals and monasteries had impressive gatehouses controlling access to and from the religious community. The Pends were originally covered by stone vaults (the supports for which can still be seen)." So, there were archs, and they led to a courtyard.

As for the Radical Pends, it sounds more like a tunnel, but maybe short tunnels have been called pends? Or pends aren't exclusively about passageways to courtyards. But I don't know tbh. Nakonana (talk) 20:55, 24 February 2025 (UTC) [reply ]

Just a small correction: My comment that I do not know a word for this was about the metal tracks on the floor. The term "Gebäudedurchfahrt" for such passages is a quiet commons word at least in Berlin. GPSLeo (talk) 17:42, 25 February 2025 (UTC) [reply ]

@GPSLeo: perfect! - Jmabel ! talk 20:43, 25 February 2025 (UTC) [reply ]

Hi!

The topic was raised in similar circumstances already, but I stumbled across a reddit thread that might be worth discussing: https://www.reddit.com/r/DataHoarder/comments/1iuhcu8/save_the_maps/.

As the government restructuring and reduction under the Trump presidency progresses, many datasets (up to many terabytes) are at risk. A user commented while adding some useful links to some resources. Several of them should be in public domain as they are created by federal agencies.

How should we deal with the part that is relevant for us?

(Mentioned in this subreddit:

• https://www.ncei.noaa.gov/data/
• https://www.ncei.noaa.gov/pub/data/cirs/climdiv/
• https://droughtmonitor.unl.edu/DmData/GISData.aspx
• https://www.nass.usda.gov/Data_and_Statistics/index.php
• https://search.earthdata.nasa.gov/)

Thanks! --PantheraLeo1359531 😺 (talk) 08:47, 21 February 2025 (UTC) [reply ]

I wonder what the cost of merely keeping (not producing) those datasets is. The cost of storing that data should be almost negligible for US Federal Government (even after strong budget cuts), so it's striking that public data is being mass deleted. MGeog2022 (talk) 16:32, 22 February 2025 (UTC) [reply ]

Sure that is striking. It's totally not my own priority on Commons, but I do hope that US contributors to the platform will try to archive that stuff either on other platforms where we will have access, or directly here on Commons.

Also, I do hope that WMF is quickly enough in relocating all Wikimedia datacenters to safe places in Europe before they are nationalized or switched off. --Enyavar (talk) 17:34, 22 February 2025 (UTC) [reply ]

I agree that keeping those would not cost that much. But I think that many people don't recognise how important it is to archive and preserve files (how much images are flushed into the net, and the uploaders don't think far into the future how to handle historical files). Any some may have concerns that the data could be used against them someday (especially when making dubious claims). And yes, I hope WMF has sufficient backups and copies in the whole world. --PantheraLeo1359531 😺 (talk) 17:45, 22 February 2025 (UTC) [reply ]

I hope WMF has sufficient backups and copies in the whole world: all text content (including full history) from all WMF wikis (Commons included) is periodically dumped to several mirrors worldwide, but most of them are also in the USA, and one of them is in Russia, which doesn't exactly give too many guarantees either. Out of the USA and Russia, there are only 2 mirrors: 1 in Brazil and 1 in Sweden. If we talk about media files in Commons, things look worse: there are no copies out of the 2 main WMF datacenters, both of them located in the USA (see here and the references section at the bottom of that page).

I think that wiki texts can generally be considered at safe (dumps are continuously downloaded here and there all over the world, at least for Commons, for Wikipedia in the major world languages, and many other specially notable wikis). As for the media files in Commons, this ticket has been waiting for years, with with very little progress.

In the meantime, it seems that Internet Archive continues to host the vast majority of its contents in a few rack cabinets in 2 places in the same seismic area (at least, there is no public information saying otherwise). After the first election of Donald Trump, they proposed to create a full copy of the Archive in Canada: there was no more news about it. After his second election, when it would seem that there should be more serious reasons for concern, there is no news about it either. The risk of earthquakes does not seem to be causing any major concern either.

Returning to Commons, let's hope that nothing happens, but I think more copies around the world would be highly recommended. Human beings usually only learn by making mistakes: I'd say that, if nothing changes, most of Internet Archive is very likely to be lost at some point in this century, since earthquakes will not stop hitting San Francisco, as they have for centuries, and a small fire destroying a group of 4 cabinets is something that can easily happen with or without an earthquake. At that (really sad) moment, a more resilient Archive would likely be built. Commons, having several copies in 2 distant datacenters in safe areas, is very likely to be in place by then, and to contribute many media content to the new archive. And, after that hypothetical catastrophe for the preservation of human knowledge, it's also likely that Commons itself will be mirrored in several more places, for greater security. MGeog2022 (talk) 20:34, 22 February 2025 (UTC) [reply ]

By the way, if you think that things are bad now, about 5 years ago there were no true backups at all of Commons media files. Files were often lost simply due to bugs in MediaWiki software: no need for earthquakes or totalitarian governments. MGeog2022 (talk) 20:39, 22 February 2025 (UTC) [reply ]

Just my two cents; I don't think that Commons with its ultra-strict adherence to copyright is really suited to reliably "archive" stuff. We regularly delete media for reasons such as "this 1939 nazi propaganda poster's author is unknown" or "this high quality photo of some building is very good, but some law does not allow commercial use of it". Only one law needs to change that might affect copyright status retroactively and we would be sitting here deleting stuff en masse. I think that the Internet Archive is a lot better for such archiving. ~TheImaCow (talk) 20:57, 22 February 2025 (UTC) [reply ]

@TheImaCow, files deleted from Commons are not actually removed from WMF servers. They are taken in consideration even for backups, as if they were regular files. Copyvio files are often marked with a future undeletion date when they enter public domain (for example, 2072 or the like). Considering the problems facing Internet Archive, that I exposed above, I think that, for very long term preservation, Commons is far more reliable than Archive is, indeed (unless Archive starts taking backups seriously enough). MGeog2022 (talk) 21:08, 22 February 2025 (UTC) [reply ]

If I remember correctly, there is also some effort by voluntaries to make decentralized copies of Internet Archive content (e.g. if there are 100 PB of data, then it could be backed up by 1,000 people á 100 TB. Maybe something similar could be done to Commons, where the amount of data is much smaller. --PantheraLeo1359531 😺 (talk) 15:08, 23 February 2025 (UTC) [reply ]

But yes, the awareness of data conservation should be much more strongly represented in society. I work on setting up a free media database of my hometown, and am still surprised how much coverage is lacking --PantheraLeo1359531 😺 (talk) 15:10, 23 February 2025 (UTC) [reply ]

Yes, even if Commons reaches 1 PB, only 10 institutions (such as universities or libraries) donating 100 TB each would be needed for each copy. If we compare it with the list of Debian Linux mirrors and the total storage space used on them, it seems really easy. For Archive's 100 PB it isn't so easy, but at least 1 full copy might not be so difficult (specially given what is at risk, and the total absence of true backups for the vast majority of its content). I think that such efforts should always be made through institutions, not individuals. If data is in the computers of 1,000 different people, if the full collection is to be rebuilt 20 years later, some parts are highly likely to be lost, and collecting the parts that aren't lost would be like a nightmare anyway. MGeog2022 (talk) 15:45, 23 February 2025 (UTC) [reply ]

+1, the University of Erlangen-Nuremberg for example hosts a huge bunch of Linux distribs; something similar would be fantastic --PantheraLeo1359531 😺 (talk) 14:09, 24 February 2025 (UTC) [reply ]

• Shāntián Tàiláng (talk  · contribs)

Yesterday this user was globally banned and now the user page was changed by me to indicate this situation (I have preserved all final revisions of the user page created by this user here in Commons, as well as in Meta, Wikiquote and Wikisource). I prefer not to request for a speedy deletion of its user page, because the previous edits seem to have its historic value. Also requesting is that the three-month local block for this user should be extended to indef to match the current ban status of this user. 興華街 (Hing Wah Street) - 💬 - 📝 08:23, 22 February 2025 (UTC) [reply ]

because the previous edits seem to have its historic value. Maybe it isn't the case here, but if a previously good user suddenly turns to the contrary, it can be because his/her account was hacked, and the user completely lost access to it. In those cases, it would be a good thing that the user's page, talk page, contributions, etc, are indefinitely kept as they were, with all subsequent vandalisms reverted and revision deleted, and the account permanently locked (if there is no way to return the account to the user with due guarantees). I'm probably not the first one to think about this, and maybe this is how it is usually done already. MGeog2022 (talk) 16:25, 22 February 2025 (UTC) [reply ]

... it can be because his/her account was hacked, and the user completely lost access to it. The user is not hacked, but being kicked out due to his/her misconduct in several wikis. He/She did have access previously, and after being blocked in one wiki by another he/she created several socks to regain edit rights. 興華街 (Hing Wah Street) - 💬 - 📝 13:51, 27 February 2025 (UTC) [reply ]

Yes, I was only talking about the general case of user pages belonging to hacked users, I didn't mean that it applied to this particular case. MGeog2022 (talk) 14:29, 27 February 2025 (UTC) [reply ]

In 2007, STyx uploaded the image at right and named it Wikipedia's W.svg. This W, however, is neither the Hoefler Text W used in the 2003 Wikipedia logo (which is wider and has different serifs), nor the Linux Libertine W used in the current 2010 Wikipedia logo (which didn't exist in 2007). Five months later, it was replaced with the official Hoefler Text W. For fourteen years, it remained as the Hoefler Text W and was used in countless contexts, both official and unofficial. However, in late 2021, it was reverted back to the original mystery W. Now there are countless projects linking to this file and calling it the "official" Wikipedia icon and saying that it is based on the Hoefler Text font, which is no longer true. It is also included in the WMF's official Visual Identity Guidelines, although it was added when it was the Hoefler Text W, not the mystery W. The file is currently protected, so I can't revert it, but unless someone has a good reason, I think it should be reverted back to the official Wikipedia icon (based on the Hoefler Text W). And if anyone doubts that the WMF still considers the Hoefler Text W as the official Wikipedia icon, please take a look at [7] where all of the other icon images except File:Wikipedia's W.svg clearly use the Hoefler Text W. Nosferattus (talk) 20:16, 23 February 2025 (UTC) [reply ]

@GVarnum-WMF and Jdforrester: ^ Nosferattus (talk) 21:57, 26 February 2025 (UTC) [reply ]

Repeatedly, for about the last 30 minutes, at the point where I try to upload to Commons, I get a bogus "The file you submitted was empty," and it "goes red." I have some manual (non-tool) workarounds, but clearly something is wrong. - Jmabel ! talk 00:45, 24 February 2025 (UTC) [reply ]

Pardon me if I'm stupid, but have you tried Special:UploadWizard? Is that an implementation of Flickr2Commons? —Justin (koavf) ❤T☮C☺M☯ 01:55, 24 February 2025 (UTC) [reply ]

@Koavf: Yes, there are other ways to copy images from Flickr. As I said, I have workarounds. Flickr2Commons is my preferred tool for the particular ongoing task I am doing; it is in several ways better than UploadWizard for that particular task. (Also better than Flickypedia, and I'll be very sorry when that eventually supersedes Flickr2Commons, as I gather it will.) - Jmabel ! talk 04:54, 24 February 2025 (UTC) [reply ]

Working again now, in any case. - Jmabel ! talk 05:27, 24 February 2025 (UTC) [reply ]

And now, less than a day later, failing. - Jmabel ! talk 22:26, 24 February 2025 (UTC) [reply ]

I came across this image that I don't think is a ‘real’ photo and added the category Computer-generated images of people. This image looks like a real photo, but the user has added the categories AI-generated images and Portrait photography. Finally, I occasionally come across ‘real’ photos of people's faces that are, however, software-polished in such a way that the skin, for example, is unnaturally flawless. So there too, a computer has been used to alter the original image. Which categories are best in the first two cases? Wouter (talk) 14:40, 24 February 2025 (UTC) [reply ]

In the first case Category:AI-generated men (the image doesn't seem useful by the way) and Category:AI images generated by unidentified software. In the second case also the latter since there is no cat for StyleGAN yet. Prototyperspective (talk) 17:21, 24 February 2025 (UTC) [reply ]

As for the latter, there is Category:Retouched pictures, which has various subcats depending on the type of retouching that was done or the software used. (It's a maintenance category however, and you're not supposed to add pictures manually.) ReneeWrites (talk) 08:54, 25 February 2025 (UTC) [reply ]

I had an edit request to make regarding the categoization performed by {{PD-Art-YorckProject}}, but there are a few options, so some discussion is probably in order. See Template_talk:PD-Art-YorckProject#This_template_is_categorizing_all_files_into_Category:PD-Art_(PD-old-70). – BMacZero (🗩) 17:46, 24 February 2025 (UTC) [reply ]

Many files have languished in Category:License review needed so long (e.g. over a decade) that there is no hope of ever definitively resolving whether they were appropriately licensed at time of upload. As a result, it is very difficult to find files that are capable of being effectively reviewed, because that category and its subcats are so clogged with hopeless cases.

I would like to see us clear these one way or another. I have several ideas of what we could do, but it's not an area I've worked in much, and for all I know some good decisions may already have been made and I'm just not aware of them. Does anyone have more sense of what is going on here? - Jmabel ! talk 21:33, 24 February 2025 (UTC) [reply ]

1. probably no file has "languished... over a decade", since at some point many years ago the category was close to empty. rather, some users recently slapped the template on old uploads.
2. use the TOC to jump to recent uploads.

RoyZuo (talk) 09:55, 25 February 2025 (UTC) [reply ]

Probably the decade-plus-old files were not initially tagged, but they never had their licenses reviewed. They were tagged later. E.g. File:Tiziano Ferro on Radio Bruno.jpg, File:Tradlinx logo.png, File:Image of Timothy Elisha McPherson Jr.jpg (just under a decade). - Jmabel ! talk 20:51, 25 February 2025 (UTC) [reply ]

This pops up every once in a while, see Commons:Village_pump/Archive/2024/10#Almost_400k_files_need_license_review, Commons:Village_pump/Archive/2023/05#License_reviews and Commons:Village_pump/Archive/2023/04#103,857_unreviewed_files. Let's add a timestamp just like {{Uncategorized}}. That doesn't solve the problem, but does break it into small blocks people can work on. Multichill (talk) 21:43, 25 February 2025 (UTC) [reply ]

@Multichill: I like that idea.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:51, 25 February 2025 (UTC) [reply ]

Category already sorted by time. RoyZuo (talk) 14:28, 26 February 2025 (UTC) [reply ]

• There is a proposal at Commons:Village_pump/Proposals#Add_an_outcome_of_LicenseReview and it can't solve the problem, but it can help. We need more people (or bots) to help review files but there are a number of files there are hard to fix. And my guess is that when someone meet files they can't fix they are likely to skip it and if the next files are also hard to fix then there is a risk they give up and stop reviewing files. So we need to make it possible to do something about those hard files. And I do not think the solution is always to delete. --MGA73 (talk) 07:54, 28 February 2025 (UTC) [reply ]

? RoyZuo (talk) 14:28, 25 February 2025 (UTC) [reply ]

@RoyZuo: I think you got it right the first time, with Category:Material cracks.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:41, 25 February 2025 (UTC) [reply ]

The dark lines on the road are likely Category:Bitumen lines. Bitumen is used like an adhesive for asphalt.[8] Nakonana (talk) 17:02, 25 February 2025 (UTC) [reply ]

There used to be project to run a local international service, with Swiss trains. Except fro this one picture, I have never seen any other local Swiss train in Mulhouse. Is this a project wich has been abandoned? Around Geneva there are plenty of local international trains. Does anyone knows what happened?Smiley.toerist (talk) 16:17, 25 February 2025 (UTC) [reply ]

Hello,

Greetings from the Wiki Loves Bangla Team!

We are excited to announce that Wiki Loves Bangla 2025 is coming soon! This year, the contest theme will focus on Birds of Bengal, inviting participants to capture and share stunning images of Bengal's diverse birdlife.

Contest Details

📅 Dates: 1 – 31 March 2025

📍 Theme: Birds of Bengal

🎯 Organized by: Bangla WikiMoitree

Wiki Loves Bangla is an international photography contest hosted on Wikimedia Commons to document Bengali culture and heritage worldwide. As part of the Bangla Culture and Heritage Collation Program, it is held annually with a specific theme, inviting participants to contribute their photographs to Wikimedia Commons to expand free knowledge. Through this campaign, you can become part of a community dedicated to preserving and showcasing the beauty, behavior, and biodiversity of Bangla’s birds. This initiative aims to highlight the richness of Bangla’s natural heritage to the world.

How can I participate?

The contest runs from 1 - 31 March 2025 on Wikimedia Commons. To take part, simply:

📷 Capture photographs of Birds of Bengal.

📤 Upload your images to Wikimedia Commons under the Wiki Loves Bangla 2025 category.

📖 Learn more about contest rules and guidelines on the contest page.

Why participate?

By contributing, you help in documenting the rich birdlife of Bengal, making knowledge accessible to all. Plus, there are exciting prizes to be won!

Prizes

1st prize: BDT 50,000, crest, and certificate.

2nd prize: BDT 25,000, crest, and certificate.

3rd Prize: BDT 15,000, crest, and certificate.

If you are interested in participating in the photography campaign, start photographing and get ready for the photo campaign happening on Wikimedia Commons. For more information about the rules and prizes of the contest, refer here. For any questions, email us or join our telegram group here.

Warm regards,
~Moheen ^{(keep talking)} 17:47, 25 February 2025 (UTC) [reply ]
Wiki Loves Bangla Team.

#WikiLovesBangla

I am guessing that this is a result of the change to the Vector 2022 skin, though possibly it happened some other way. We seem to have lost the "Use this file" links (which I had quite recently mentioned in Commons:How to#How do I reuse Commons content?), and there is no obvious substitute. How are end users supposed to know how to properly credit a Commons file when reusing it? - Jmabel ! talk 20:56, 25 February 2025 (UTC) [reply ]

@Jmabel: You might want to ask at MediaWiki talk:Gadget-Stockphoto.js.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:30, 25 February 2025 (UTC) [reply ]

Ah, there is already discussion there; someone turned it off on purpose (ill-advised in my view, but I'll change the documentation). - Jmabel ! talk 21:36, 25 February 2025 (UTC) [reply ]

The second edition of the Wiki Loves Bangla photography contest will take place on Wikimedia Commons from March 1 to March 31, 2025, aiming to enrich content related to Bangla culture and heritage. A central notice request has been submitted to reach both registered and non-registered WikiCommons users. Thanks. ~Moheen ^{(keep talking)} 07:23, 26 February 2025 (UTC) [reply ]

Is there an already existing way/template to include the image/object ID information with template {{Information}} (for example for objects photographed in a museum or as inventory number of larger image collections)?
An example what I'm looking for would be something like {{Object location}}. I know that you can create your own information fields with {{Information field|name=|value=}}, so I'm asking if there already exists a solution for this. --D-Kuru (talk) 07:48, 26 February 2025 (UTC) [reply ]

So basically a template for this item on Wikidata Q1417099 - accession number --D-Kuru (talk) 07:52, 26 February 2025 (UTC) [reply ]

@D-Kuru: I think what you're looking for might be in one of the derivative templates like {{Artwork}}, which has parameters for collections or museum exhibits. ReneeWrites (talk) 09:31, 26 February 2025 (UTC) [reply ]

Seconding ReneeWrites here. {{Art Photo}} may be what you want. See File:Frederic Storck - Muncitorul pietrar - 1896 - 01.jpg for a recent example where I used it this way. - Jmabel ! talk 06:35, 27 February 2025 (UTC) [reply ]

@Jmabel: |accession number = sounds pretty much like the thing I am searching for, but I wonder if this can also be included in {{Information}}. The general parameters of {{Artwork}} work somewhat, but don't really fit all that well either. Additionally it looks a little bit of overkill to the one line I actually need in the information template. --D-Kuru (talk) 07:16, 27 February 2025 (UTC) [reply ]

@D-Kuru: A slightly less cumbersome way to do it (output will be clear to humans, but not to bots) would be to set the "other fields" parameter of {{Information}} to {{InFi|accession number|the actual number}}. - Jmabel ! talk 17:25, 28 February 2025 (UTC) [reply ]

This is what I thought would be the easiest (not necessarily best) option for now (the so called "temporary"-forever). IMO the ID could be made machine readable if included in the structured data with Property:P217 - inventory number. --D-Kuru (talk) 21:23, 28 February 2025 (UTC) [reply ]

See: File:ETH-BIB-Abessinische Frau und zwei Männer-Abessinienflug 1934-LBS M平成02年22月10日82.tif. The image is no longer available from the source, except to researchers, because of implied exploitation from the public nudity. --RAN (talk) 16:24, 26 February 2025 (UTC) [reply ]

We don't have a category for it, but we do have a template: {{Change-of-license}} ReneeWrites (talk) 20:04, 26 February 2025 (UTC) [reply ]

Established categorisation practices make it difficult to differentiate between media depicting objects in a certain location from media which have any sort of relation to this location. For example:

• If you look up all images categorized under Category:Hamilton, Bermuda, you'll see a gallery of ships photographed around the world, since Category:Ships registered in Hamilton, Bermuda is so huge.
• Category:Road transport in the Bronx, New York City consists largely of Manhattan photos, because categories such as Broadway (Manhattan) are included in Category:Streets in the Bronx.

It can we solved by using Images by location categories but they seem to have limited implementation. For example, Category:Images by district by country is only utilized for Category:Photographs of Hesse by district. Situation seems to be better for cities but still categories such as Photographs of South Korea by city include only 130 photos of Seoul and Incheon.

It would be beneficial to change the established categorisation practices and think of a way to set up necessary category structure (semi-)automatically. Qbli2mHd (talk) 16:48, 26 February 2025 (UTC) [reply ]

Thanks for raising this, it's an important issue. I think this can be solved by how the relation is categorized. Things that only have some relation to a category should only be linked via see alsos instead of being subcategories.

Additionally or alternatively, things that only have some relation to a place like 'books published in {city}' (a useless overspecific cat in my opinion) could all go into one main category and things that have a direct relation as in depicting the place could all go into another main category – if one cleanly divides like that one can use the deepcat only on either of those. They could be subcats of a common cat or just link to each other via see alsos.

As a further option there could be preconfigured filters for deepcat – maybe even turned on by default but at least enabeable with just two clicks – that excludes certain type(s) of cats: in your example, excluding Category:Registries would solve this across all categories no matter if it's ship or anything else. (Registries could be in some pre-made filter or the page could show the most populous subcats which one can exclude with a ×ばつ click.) So you'd append -deepcategory:"Registries". That doesn't seem to work probably because of deepcat issues that need to be fixed but this works. Prototyperspective (talk) 18:51, 26 February 2025 (UTC) [reply ]

The first problem is one that I agree needs a technological solution - some way to indicate to tools that "this category is for things that have a relation to the parent category but aren't necessarily part of it." That would be useful for a variety of "people from...", "ships registered in...", "companies headquartered in...", etc - categories that are useful but slightly orthogonal to the usual subcategory relationship.

The second problem can usually be addressed by adjusting categorization. When something like a road crosses multiple jurisdictions, especially when it skews other things like this does, it's sometimes best to subdivide it to reflect that. There really should be Category:Broadway (Manhattan–Westchester County) (linked to the enwiki article), with subcategories of Category:Broadway (Manhattan), Category:Broadway (The Bronx), and Category:Broadway (Westchester County). The existing structure of Category:Massachusetts Avenue (metropolitan Boston) and its subcats is a good model. Pi.1415926535 (talk) 20:14, 26 February 2025 (UTC) [reply ]

Actually Broadway is divided in categories such as Broadway in the Bronx and Broadway below Canal Street, but they all have Broadway (Manhattan) as a parent category for a whole street, which is in turn categorized under both Category:Streets in the Bronx and Category:Streets in Manhattan. And I'm not sure if such a division for every street would serve any other purpose beyond solving this particular issue - a tiny street may cross an administrative border after all. I think it would be better if territorial categorisation was independent from street category hierarchy. Qbli2mHd (talk) 21:57, 26 February 2025 (UTC) [reply ]

Maybe it's just the areas I work in but it seems like see alsos are way under utilized on here. More to the topic, there's a ton of categories for objects being housed in museums and the like that aren't originally from there but are subcats of ones for "objects of X location." Which is just wrong. Users don't seem to know what the difference is between a particular object being "of", "in", or "from" somewhere. Either that or they just don't care. But it's a massive mess either way and one that doesn't seem to have an easy fix since it's probably a language issue more then intentional miscategorization. --Adamant1 (talk) 22:13, 26 February 2025 (UTC) [reply ]

As I see it, the category system itself only bothers with two questions: 1) Does a relation exist? 2) Is there a hierarchy of groups? It's not surprising when users only consider these when they pick categories. Unless a different system is employed which would necessitate to establish a particular sort of relation (included in full, included in part, originates from, registered in etc), certain rules/guidelines are warranted to define which kinds of relations should be separated and explain why it is important. If such practices are not commonplace and not prescribed, users will never now they should have these considerations when they work with categories.

About "see alsos" - I don't edit Commons often, and I can't remember even seeing it here. But I know that some Wikipedia editors consider "See also" sections in articles problematic and see it necessary to eliminate/reduce them whenever possible. It might in part explain the aversion. Qbli2mHd (talk) 23:05, 26 February 2025 (UTC) [reply ]

For the general problem of the semantics of category inheritance, see comment made 20:10, 24 February 2025 (UTC) in the discussion at Commons:Village pump/Proposals#Major damage to Wikimedia Commons.

{{See also cat}} is fine, and is usually used for things where the relation is too loose for category inheritance, e.g. to refer from a cat for a person to one for a close associate or relative.

In the example that started this section: you may happen to have been searching for things in the location, but you can't presume that would be the only interest of someone making a search on that location. For example, someone searching for Ancient Egypt could very well be interested in Ancient Egyptian artifacts that are not now located anywhere near Egypt; someone searching for Armenia might well want instances of Armenian culture outside of just that nation-state. - Jmabel ! talk 06:47, 27 February 2025 (UTC) [reply ]

Have a look at Commons:Structured data. Multichill (talk) 22:54, 27 February 2025 (UTC) [reply ]

Apparently, the cascade protection is not working properly. I saw a spam edit from a recently created account here and was able to revert it without any issues. I tested it, and it seems I could edit the page as an IP. Is this a recognized issue, or am I mixing things up? RodRabelo7 (talk) 04:54, 27 February 2025 (UTC) [reply ]

Of course, there's a warning stating the "page is currently protected, and can be edited only by administrators". RodRabelo7 (talk) 04:55, 27 February 2025 (UTC) [reply ]

@RodRabelo7: That looks like a bug, please see mw:How to report a bug.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 07:35, 27 February 2025 (UTC) [reply ]

There have been some fixes to cascade protection this week see phab:T24521, to fix the years long issue that the file description was protected instead of the actual file. I'm assuming it is related to those changes. —TheDJ (talk • contribs) 10:07, 27 February 2025 (UTC) [reply ]

@TheDJ: Protecting just the description sounds very unprofessional.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:51, 27 February 2025 (UTC) [reply ]

Previously the file description page and and image itself was protected when the media was transcluded, but this caused issues for people that wanted to nominate images for deletion or make improvements to the caption or file description. Now only the image itself is proected. The message is leftover that needs to be removed. Dylsss (talk) 21:55, 27 February 2025 (UTC) [reply ]

@Dylsss: AIUI, part of the point of the cascading protection is that files which are on the main pages of our project and many other projects are high-visibility targets for vandals, and should have their file description pages fully protected for the durations of their stays on said main pages. COM:AN can be used to make legitimate suggestions for changing anything on those file description pages. Just protecting from upload vandalism does not mitigate other types of vandalism. Where did the community have a chance to vote on this change?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:10, 28 February 2025 (UTC) [reply ]

@Jeff G. "the point of the cascading protection" This is what it has been used for. But the point of cascade protection is to protect the things that are transcluded into the protected page. This didn't work for files and it seems we have since used it to indirectly protect the file pages. But if I make a link on wikipedia, that also doesn't protect the article that we link to, and changing the file description does not change the original page that the file is transcoded into either, indicating that file description pages being protected is not the intended functionality. —TheDJ (talk • contribs) 14:40, 3 March 2025 (UTC) [reply ]

Hello all! The summaries from our last two Commons Community Conversations are now available on Commons:

• Community call on Tool investment priority (January 2025)
• Community call on Impact and funding model (February 2025)

If you have more feedback coming about the topics we discussed, you can do so in the Community calls talk page.

Thank you very much for participating and sharing your feedback! Sannita (WMF) (talk) 15:32, 28 February 2025 (UTC) [reply ]

@Sannita (WMF): Thanks! When do you anticipate them being available for the first four converstions?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:12, 28 February 2025 (UTC) [reply ]

All four summaries (and the summaries of the two meetings before the conversations) are already available at Commons:WMF_support_for_Commons/Commons_community_calls#Past_discussions. Sannita (WMF) (talk) 17:14, 1 March 2025 (UTC) [reply ]

@Sannita (WMF): Thanks! I'm sorry, I must have missed those.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:59, 1 March 2025 (UTC) [reply ]

Currently, other than the special case that they UploadWizard has for direct uploads from Flickr, when a user uses UploadWizard to upload a file sourced from a third-party site, there is no built-in way to request license review. This certainly results in some link rot, because source pages go away (or change their license) and for licenses that were never reviewed we have no way to prove the older license. (Sometimes it can be done cumbersomely through the Internet Archive, sometimes not even that.)

I had suggested that whenever page on another website is given as a source for copyrighted free-licensed material, UploadWizard should automatically tag with {{License Review}}. Sannita (WMF) raised the reasonable concern that might go too far the other way, and overburden admins and license reviewers. (I'm not sure if that concern carries the day or not: after all, every unreviewed license of this sort is at risk of us being unable to keep the file for the long term, because its license status could become questionable.)

Sannita and I both agree this requires broader community discussion, so here we are. Obviously, the most affected people are admins and license reviewers, so we would especially like to hear from them, and in particular from people who already do a fair amount of reviewing licenses. - Jmabel ! talk 17:38, 28 February 2025 (UTC) [reply ]

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 18:14, 28 February 2025 (UTC) [reply ]

 Comment - if we do this - and perhaps even if we don't! - we ought to change the messaging in the wizard to make it clearer that:

1. The source URL should, in most cases, be the URL of a web page on the site where the file came from - not just the domain name, nor a direct link to the file itself.
2. If the license is not immediately apparent on that web page, another URL should be included which can be used to verify the license.

As a license reviewer, one of the hardest parts of verifying licenses for content that isn't from major web sites (Flickr, YouTube, etc) is figuring out where the license was specified. It's often hard to distinguish between "the license is there, it's just really hard to find" and "the content was never actually released under a free license". Omphalographer (talk) 19:58, 28 February 2025 (UTC) [reply ]

What happens if a file passes license review but was never archived, then the license changes and someone requests takedown? I think a focus on archiving sources when uploading files is also important.  ${\displaystyle 999}${\displaystyle 999}REAL 💬 ⬆   20:12, 28 February 2025 (UTC) [reply ]

@999real: good practice by any uploader, but not a burden I'd want to place on the reviewers.

The whole point of license review is that someone trusted by Commons has verified the license. The scenario you are describing might be an issue for someone outside Commons who does not share that trust, but that's not necessarily our responsibility to deal with. I would assume that the broader Wikimedian community will also trust Commons on this. - Jmabel ! talk 02:16, 1 March 2025 (UTC) [reply ]

About archiving I did not mean to say license reviewers should have to do it, but that in the UploadWizard suggesting to uploaders to archive the source could be useful.  ${\displaystyle 999}${\displaystyle 999}REAL 💬 ⬆   02:34, 1 March 2025 (UTC) [reply ]

The question remains, why isn't archiving done automatically? The English-language Wikipedia already automatically archives any external link. Maybe we could change the way URL's are displayed at the Wikimedia Commons, that "Archive now" and "Check the archives" become automatic options for any URL. Maybe the toolbox for license reviewers could include a option that is "Archive this link" whenever they click on an external link, but not every website allows archiving. I noticed ever since LLM's became popular a few years ago that more and more websites now disallow bots (including the Internet Archive's Wayback Machine) from scraping its content. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:29, 1 March 2025 (UTC) [reply ]

I  Support this in general, but I worry this will just create an even bigger backlog, and the same problems (e.g. link rot) will still occur when the license is not reviewed in time. I think before implementing such feature, we need to find ways to reduce the workload of licence reviewers, so we will be well prepared to deal with the influx of license reviews. Tvpuppy (talk) 03:21, 1 March 2025 (UTC) [reply ]

 Support -- Ooligan (talk) 03:19, 2 March 2025 (UTC) [reply ]

 Support this proposal/suggestion (as a license reviewer myself, but I unfortunately had no ample time recently to review files that have external links). Yeah, a downside on this is the "bloating" of categories related to licensing reviews. Suggest that, like in enwiki, there should be a bot that will be able to archive external links and automatically add the Wayback Machine links to file description pages. JWilz12345 (Talk|Contributions) 12:50, 2 March 2025 (UTC) [reply ]

@Jeff G., Omphalographer, 999real, and Tvpuppy: are any of you license reviewers? (& same question to anyone else who may reply here.) - Jmabel ! talk 06:03, 1 March 2025 (UTC) [reply ]

I'm not a license reviewer, just wanted to express my opinion on this as an uploader/contributor. Tvpuppy (talk) 06:25, 1 March 2025 (UTC) [reply ]

Yes. I haven't had time to do much reviewing lately, but I'm familiar with the process. Omphalographer (talk) 06:27, 1 March 2025 (UTC) [reply ]

I am not. To be clear, my intention was to express that I think encouraging uploaders to archive the source (or automatically archiving) at the time of upload is an alternative that burdens license reviewers less and can help anyone later verify the license.  ${\displaystyle 999}${\displaystyle 999}REAL 💬 ⬆   15:08, 1 March 2025 (UTC) [reply ]

@Jmabel: Yes, but I haven't had time to review many licenses lately. Perhaps if the source could be split into three parts, that would help with the reviews: raw file URL; page on which the file appears; and page on which the license appears (or exactly how to find it on the page on which the file appears).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:22, 1 March 2025 (UTC) [reply ]

In February 2025, 1 sysop was elected; 1 sysop was removed. Currently, there are 182 sysops.

Election:

• User:Gnom was elected sysop (29/2/2) on 20 February.

Removal:

• User:Spiritia was removed on 12 February due to inactivity. She had served as sysop from 9 April 2008.

We thank her for her service.

---

Edited by RoyZuo.

---

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing!

--RoyZuo (talk) 01:55, 1 March 2025 (UTC) [reply ]

Hello everyone,

I am writing an article about Katu Mirim and I found this CC BY video on youtube which would be a great illustration. When I try to pass it through https://video2commons.toolforge.org/ though, I get the error : Error: An exception occurred: DownloadError: b'ERROR: [youtube] RhbJjHhm6LU: Sign in to confirm you\xe2\x80\x99re not a bot.

Could anyone else try, see if you get the same error ? Thank you !

https://www.youtube.com/watch?v=RhbJjHhm6LU

have a good day Vache-crapaud (talk) 22:50, 1 March 2025 (UTC) [reply ]

Hello, if you check Commons:video2commons, you will see unfortunately it stopped working for YouTube videos for a while now. The problem came from YouTube itself so currently there are no fix for it. As a workaround, you just have to download the video manually then upload the file through videos2commons. Tvpuppy (talk) 23:53, 1 March 2025 (UTC) [reply ]

Thank you! Vache-crapaud (talk) 09:50, 2 March 2025 (UTC) [reply ]

Tracked in GitHub
toolforge/video2commons/issues/237

Created the issue. See Commons:YouTube files/Downloading for info how to download as webm without the tool. Prototyperspective (talk) 15:23, 2 March 2025 (UTC) [reply ]

Seems like there is not GitHub repo and the issues are also not tracked in phabricator. I don't understand why that is since that makes it unlikely for other to discover and help develop these useful tools.

Does somebody here know why the glamorous and glamorgan – which can be used to see file uses of files (example) – are getting the 504 Gateway Time-out – is there an issue somewhere?

--Prototyperspective (talk) 16:02, 2 March 2025 (UTC) [reply ]

Some time ago I created Category:Child victims of National Socialism, and since I'm not a native English-speaker, I used the already existing Category:Child casualties and Category:Child Holocaust victims for guidance on choosing a proper English name for my category - both categories use the singular form for the word "child". Recently, @Blackcat moved[9] the category to the plural form "children": Category:Children victims of National Socialism. I asked[10] Blackcat about the move, because the naming is not in line with the other categories and to me the singular form "child" sounds like the correct form. I might be wrong, of course, but Blackcat also doesn't seem to be a native English-speaker, so I'm hoping to get some input from native English-speakers on the category name. Should it be "child victims" or "children victims"?

(Side note: in the user talk page discussion, you'll see that "Japanese children" and "Children of Japan" were mentioned. This is in reference to some other category moves that Blackcat did (e.g. [11]) and which I absolutely support, because the original category naming in those cases was definitely non-standard and I only had chosen that non-standard naming because there was already a category with that naming pattern when I started to create similar categories for children of other nations; namely, it was this one: [12]. But the non-standard naming also created issues with country-navigation template usage, so I'm glad that Blackcat fixed those with the move.) Nakonana (talk) 17:06, 2 March 2025 (UTC) [reply ]

I think that using the singular form "child" sounded more correct. Using the plural form, i.e. "children victims", doesn’t seem correct in the same way as using the plural form for "adult", i.e. "adults victims". Tvpuppy (talk) 17:35, 2 March 2025 (UTC) [reply ]

"Child victims" is correct. "Children victims" doesn't make sense. --Adamant1 (talk) 17:44, 2 March 2025 (UTC) [reply ]

"Child" is correct, and in this context it is an adjective, not a noun. English-language adjectives don't change forms in the plural. - Jmabel ! talk 21:51, 2 March 2025 (UTC) [reply ]

"Child victims" is the correct plural. ReneeWrites (talk) 12:10, 3 March 2025 (UTC) [reply ]

Hello, just for your info, there is an open letter in the French Wikipedia fr:Wikipédia:Lettre ouverte : non à l'intimidation des contributeurs bénévoles in support to a user (also user here) who suffered pressure and threats from a newspaper journalist. Christian Ferrer ^(talk) 17:50, 2 March 2025 (UTC) [reply ]

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=1004903403"

Category:

• Commons community

Hidden categories:

• Noindexed pages
• Commons maintenance