Commons:Village pump

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

This page is used for discussions of the operations, technical issues, and policies of Wikimedia Commons. Recent sections with no replies for 7 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Archive/2022/01.

Please note:

  1. If you want to ask why unfree/non-commercial material is not allowed at Wikimedia Commons or if you want to suggest that allowing it would be a good thing, please do not comment here. It is probably pointless. One of Wikimedia Commons’ core principles is: "Only free content is allowed." This is a basic rule of the place, as inherent as the NPOV requirement on all Wikipedias.
  2. Have you read our FAQ?
  3. For changing the name of a file, see Commons:File renaming.
  4. Any answers you receive here are not legal advice and the responder cannot be held liable for them. If you have legal questions, we can try to help but our answers cannot replace those of a qualified professional (i.e. a lawyer).
  5. Your question will be answered here; please check back regularly. Please do not leave your email address or other contact information, as this page is widely visible across the internet and you are liable to receive spam.

Purposes which do not meet the scope of this page:

Search archives:

 

Start a new discussion

Village pump in Rzeszów, Poland [add]
Centralized discussion
See also: Village pump/Proposals • Archive
Template: View • Discuss  • Edit • Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

December 28[edit]

Let's help Rehman[edit]

Hi all; let's support our colleague Rehman, he is a great Commoner and Wikipedian, and currently is in a critical economic situation. Here you can support; any donation and sharing this campaign is highly appreciated. Regards --A.Savin 18:03, 28 December 2021 (UTC)[reply]

January 07[edit]

Banning IP edits in general[edit]

In the last time I did a lot of patrolling. I checked the edits of IP users and my experiences are showing to me that we have a huge problem with accidental edits and a lot of spam. The most IP edits are okay, but only because of some people doing things like mass categorization with many hundred edits as IPs. When banning IPs I think we would not loose those small group of "IP-power-users", they just would create accounts for them.

The time we need to check and revert so many edits is much more then the good contributions added to commons. With the time saved we can check the edits of new users and contact them to help. This is much more important for getting new contributor then the ability to edit without an account.

With this introduction I want to start a discussion on this for later creation of a proposal with all details, like which namespaces should be protected. --GPSLeo (talk) 11:45, 7 January 2022 (UTC)[reply]

A key problem with this is that many editors start out by making IP edits before creating an account. If I had needed to create an account before experimenting with Wikimedia projects, I would never have participated at all. By closing the project to named accounts only, we are likely to intensify the reduction in active editors in the long term. From Hill To Shore (talk) 13:08, 7 January 2022 (UTC)[reply]
I think moth users start with uploading their own photos where an account is already required. --GPSLeo (talk) 13:19, 7 January 2022 (UTC)[reply]
Symbol support vote.svg Support It's a great idea, especially that movements in this direction can be observed on other wikis, some of them even have already banned IPs. It is exactly like you have said – a small number of IP editors make tons of good edits, while tons of IP editors make a few crappy "test edits" (or just pure vandalism). These good IP editors, if forced to create accounts, could be later granted "autopatrol", what would reduce amount of work for patrollers. And of course getting rid of vandals and ordinary morons would reduce amount of work for everyone and the time saved could be spent on more productive activities here. Anyway, I think that editing of structured data (including file captions) should be banned immediately for IPs. It is very hard to find a good SDC related edit made by an IP. --157.25.186.137 13:58, 7 January 2022 (UTC)[reply]
If IP users are an especially big issue with Structured Data on Wikimedia Commons (SDC)-related edits then making an edit filter that disallows from making such edits is a better solution than just blanket banning them / y'all from all editing. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:43, 7 January 2022 (UTC)[reply]
Symbol oppose vote.svg Oppose I disagree with the premise that most good IP edits are from mass categorization, In the past 2 weeks I have noticed One IP Categorize various Churches in London and another IP Categorize Streets in Southwark neither of these were or could have been done by mass categorization. The last time I noticed a Spammer was more than 2 years ago, their edits were easy and took seconds to undo. I can say I would not have started or persisted with editing If there had been a requirement to register. I find that your assumptions that "we would not loose those small group of "IP-power-users"" "moth users start with uploading their own photos" to be unsupported by credible evidence, such as statistics or even personal observations. I have sometimes used IP edits when I am away from my home PC and can't use the PC at hand to log in, inability to do this would mean I don't do those edits and would have put me of the project in the beginning. As for mistakes. I make them, admins make them we all make them if we are here long enough. Not a big problem and certainly not as big a concern as problem admins such as Blackcat who has a history of admin tool abuse. Having to log in or register does not deter abuse or unwise edits. Finally it would be a big step to losing our open approachable status/vibe and a step on a journey to being a small clique of people making irrelevant edits that no one is looking at or engaging with. Oxyman (talk) 14:03, 7 January 2022 (UTC)[reply]
Your idealistic views clearly show that you have zero counter vandalism exprience. Just use RTRC, let's say for a month, and I assure you will change your mind about IP editors. --157.25.187.217 14:38, 7 January 2022 (UTC)[reply]
It's worth to mention that Portuguese Wikipedia also has very positive experiences in this area. --157.25.187.217 18:45, 7 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose per Oxyman. Being welcoming to newcomers is one of the most important aspects of a collaborative, free culture project. At the same time, wikis need a significant pool of good faith contributors that can push the equilibrium toward quality. In my view, we should only change our IP policy when it is absolutely necessary for maintaining the quality of the project, not merely out of convenience.  Mysterymanblue  17:27, 7 January 2022 (UTC)[reply]
For sure IP editors will not help to "push the equilibrium toward quality". No way. Let's face it, an average internet user is an idiot. I do not think any Wikimedia project needs them. Projects need committed people, at least committed enough to create an account. IMO we need quality over quantity (what is exactly opposite to WMF's views). --157.25.187.217 18:45, 7 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose, mostly because this is directly in response to the new privacy measures being taken by WMF Legal. People check IP edits if they can't immediately see where they're from and people will check Masked IP edits. Wikimedia websites should be as open as possible to new users and these websites are some of the last bastions on the internet where unregistered users are still allowed. If Masked IP users cause more vandalism than we have today then it would make sense, but since this new feature hasn't been implemented anywhere it is reasonable to not change anything until after we see if the new IP masking will cause more vandalism or not. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:17, 7 January 2022 (UTC)[reply]
Yeah, another WMF's nonsense. Instead of banning IP editors (what would "magically" solve many problems) they are wasting man-hours, i.e. money. Anyway, requirement to create an account has nothing to do with openness. --157.25.187.217 18:45, 7 January 2022 (UTC)[reply]

Does anyone other than me find it ironic that other than the original proposer, the main proponent here of banning IP editors is an IP editor? - Jmabel ! talk 19:23, 7 January 2022 (UTC)[reply]

Yes, but the world's largest book burning campaign was conducted by a librarian (Mao Zedong) and the genocide of the intellectuals and basically anyone who can read was done by a school teacher (Pol Pot), so the world is full of irony. While I agree that they do have strong arguments, I am still inclined to disagree with them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:31, 7 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose as GPSLeo concedes, "most IP edits are okay", and the assumption banning IPs I think we would not loose those small group of "IP-power-users", they just would create accounts for them is just, that, an assumption. Gestumblindi (talk) 11:05, 12 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support - The little they contribute is not worth the trouble they cause to the community & reusers, in my experience, due to the high rate of vandalism (and a huge security & privacy issue for more than 20 years which finally and thankfully is being addressed by WMF). Should never have been allowed in first place.-- Darwin Ahoy! 17:55, 13 January 2022 (UTC)[reply]
Exactly. IP editing is a design flaw. --157.25.245.205 18:17, 13 January 2022 (UTC)[reply]
As the original proposer GPSLeo themselves conceded, "most IP edits are okay", and they don't contribute exactly "little". There are, as GPSLeo says, "some people doing things like mass categorization with many hundred edits as IPs", which are fine - GPSLeo just assumes that these people would create an account, but I wouldn't count on that. A blanket ban on IP edits without actual research first that robustly shows that IP contributors are doing more harm than good here on Commons (other projects might have other experiences), and this also in comparison to registered accounts (of which many are throwaway accounts doing lots of rubbish edits/uploads, too!), is out of the question IMHO. We shouldn't go by a "IPs are evil" gut feeling here but base our decisions on hard facts. Gestumblindi (talk) 18:37, 13 January 2022 (UTC)[reply]
You are an admin, but have zero experience in patrolling of recent changes. You just assume that "IPs are good". No, they aren't. Just use RTRC for some time and see for yourself. --157.25.244.244 19:04, 13 January 2022 (UTC)[reply]
I have quite a lot of experience in deletion requests (though my level of activity varies, granted), and in my experience, IP contributors often bring very reasonable arguments in deletion discussions, for keeping as well as for deleting files, and I wouldn't like to miss them. It's interesting to discuss this with an IP contributor, by the way ;-) Gestumblindi (talk) 19:37, 13 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support Commons will still be the free educational media repository that anyone can edit, but they need to register to do it. I agree with the IP above that we need quality over quantity. In defence of Gestumblindi, I'd like to note though that I rarely click the "mark as patrolled" button when I check new files or recent edits. So that log might not be indicative of one's experience with IP vandalism. De728631 (talk) 19:21, 13 January 2022 (UTC)[reply]
That's very bad. There are not enough active patrollers while clicking on that link costs you virtually nothing. --157.25.242.36 20:04, 14 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support IMO, the ratio of good v. bad edits for IP is very low. As De728631 says above, it is better to focus on quality rather than quantity. Creating an account is very easy, and it is not an obstacle for users willing to contribute positively. Yann (talk) 20:32, 13 January 2022 (UTC)[reply]
IMO, for such decisions, we don't really need "IMO's" here but actual, tangible data - i.e. though I have a different perception of IP contributors from my experience (mainly in deletion discussions), that doesn't mean that I am right, and if a true statistical evaluation of IP contributions proves that they do more harm than good in comparison to registered accounts, I will readily change my opinion. Gestumblindi (talk) 20:46, 13 January 2022 (UTC)[reply]
While I don't have detailed numbers , my facts are based on 18 years of activity on Commons. Yann (talk) 21:00, 13 January 2022 (UTC)[reply]
Mine too ;-) (nearly - my first Commons edit was on 18 November 2004, so two months after you). Gestumblindi (talk) 21:47, 13 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Is this a joke? If so it's in very poor taste. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 21:21, 13 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose Apart from the arguments presented (we need real stats), we have a different situation than e.g. the Wikipedias. Over there you can have a small community of contributors and other people will just read. Here we should serve also authors, copyright owners and reusers. Those should be able to comment without searching for an e-mail address or registering an account. I know about myself, that when commenting on anything requires registering a user name, I just don't comment. Even here, it is not clear what one is committing to when clicking "create account", and there is no telling whether the process will be easy or not. –LPfi (talk) 21:40, 13 January 2022 (UTC)[reply]
Authors and copyright holders who publish here directly have to have an account here anyway. Others, who publish in other places (e.g. Flickr) have to contact VRT in order to their comment have any meaning. And you are right. Commons and especially Wikidata are different. They serve as repositories for wikipedias, wictionaries, etc., therefore they should not allow "anonymous" morons to easily vandalize these projects. --157.25.185.156 06:05, 14 January 2022 (UTC)[reply]
There are lots of them that published elsewhere and don't have accounts here, and there is no need to go via VRT to point out that the work elsewhere on the internet is attributed to a named person, not the pseudonym that uploaded it as "own work", or to add details on what a photo is about (I don't think VRT should be burdened with such requests). These persons do not need to know about VRT and other procedures, and banning IP editing means they cannot even ask for advice (you could limit them to certain namespaces, but the right place to ask might not be obvious to them). –LPfi (talk) 09:29, 14 January 2022 (UTC)[reply]
How and where can they ask for advice if they "do not need to know about VRT and other procedures"? On a random page? Face-smile.svg What basically means that their request will go down the drain. Anyway, they can create an account. Only usernane and password must be provided, no other data, even an email address, is required. BTW, I think that email address should be obligatory – it would make LTA's life harder if they were forced to create a new email address for each sockpuppet. --157.25.242.36 10:15, 14 January 2022 (UTC)[reply]
Not a random page, but a relevant page. If they see a deficiency in the file description, editing that page would not be far fetched. From that page there are links, some of which (ultimately) leads to pages such as the village pump and help desk, and the file description has links to users with talk pages, perhaps to a deletion request. File talk pages may not be well patrolled (are they?), but comments might be seen by people interested in the specific file. Those are all pages that a random visitor should be able to leave comments on. –LPfi (talk) 15:14, 14 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support it is how it should be in every Wikimedia project by default. Wostr (talk) 01:17, 14 January 2022 (UTC)[reply]
  • Symbol oppose vote.svg Oppose. Hulged (talk) 07:21, 14 January 2022 (UTC)[reply]
  • We should keep in mind that the culture in Commons is different from say, Wikipedia. In the latter, "anyone can edit". We don't have an equivalent of that here. The main way of contributing to Commons, which is uploading, already requires you to register an account first. So the argument that we would be missing out on many good contributions by unregistered users is questionable.

    So I think we should restrict IP editing further. How much should we restrict? For the minimum we should at the very least disallow structured data edits from IPs, as most of the vandalism and test edits I see come from captions and marking a property as "prominent" even though that's not how it works. For the maximum, we disallow every namespace except Commons and discussion pages. That way it should significantly reduce vandalism on our files and galleries, while still being open to IP feedback. pandakekok9 11:00, 14 January 2022 (UTC)[reply]

    I also noticed something: most of the vandalism came from mobile. Perhaps we can do a trial first where we disable editing in mobile via CSS or edit filter? That way we could see if there's improvement or not. Those who want to continue editing unregistered can always go to the desktop version anyway. Seems like a good compromise to me. pandakekok9 11:18, 14 January 2022 (UTC)[reply]
I exclusively edit on mobile, the mobile interface is already horrible to work with and deliberately handicapped, making it even worse to use is not the solution because forcing people to exclusively use the "Desktop view" will make a lot of tasks more difficult for a lot of people. Unless you mean exclusively ban mobile edits by non-registered users, in any case this anti-mobile discrimination has got to stop. Furthermore, "anyone can edit" and "Ignore are rules" and all the other "Wikipedian" things are also a part of "the pillars of the Wikimedia Commons", this just means that the software is open to everyone to make improvements, IP editors at the English-language Wikipedia already cannot create new articles or upload and "ignore all rules" never meant "ignore all laws" and Wikipedia's hunt down copyright violations as much as the Wikimedia Commons, these policies exist to be open to anyone for improvements. You don't need to register an account to fix categories, fix a license, or nominate a file for deletion and I have seen IP editors do all those things with good faith here. You don't want a copyright violation to fly under the radar simply because the person who notices doesn't want to register an account. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:48, 14 January 2022 (UTC)[reply]
I wonder why people choose to use devices which by design are total crap for uses such as editing a wiki. Do not expect a good software on a crappy basis. Although people are strange – I know a person who prefers to watch movies/Youtube on a 5" smartphone than on a 50" TV. Face-smile.svg --157.25.242.36 20:24, 14 January 2022 (UTC)[reply]
This is something you can say in Poland, this is something you can say in places like Europe, North America, South America, and Oceania... But not something that would translate well in most of Asia and Africa, for many Indians and Pakistanis mobile telephones are their only ways of accessing the internet. The only reason why the editing experience for mobile sucks is because rather than just using "a mini-desktop editing interface" (which already exists, try opening a new section in mobile (although it used to be better a few years ago as the WMF is actively sabotaging mobile users), but for whatever reason the WMF sees mobile users only as consumers, meaning that the only people that would want to edit are the vandals or the very dedicated, as the interface doesn't allow for casual editing without constant frustrations. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:30, 14 January 2022 (UTC)[reply]
Well, if you look at contributions from mobile IP ranges from India, Pakistan and generally south Asia and north Africa, you will see that there are not many useful edits. And they are produced not by vandals but by ordinary morons with smartphones who don't know what they're doing. Anyway, you can connect a desktop or laptop to a smartphone through an USB cable or WiFi and use USB or WiFi tethering – the smartphone acts as a modem in this setup. This way you can avoid to use crappy mobile user interface. --157.25.245.179 20:55, 14 January 2022 (UTC)[reply]
Replying to (whom I assume is) Jdx, well, you can still upload via the mobile app (although it's a crappy interface that only allows a single upload at a time and purports that the Commonswiki only owns own works, so maybe it's not the best example), but in general Mobile users cannot see categories unless they're signed in, they cannot see talk pages, they only see the files, the reason why vandals are overrepresented among the mobile IP editors is simple, good edits are being actively disincentivised by the software itself. The issue isn't with the people, the issue is with the software. If you only access this website through a mobile browser and never register an account you won't even know talk pages and categories and the like exist, nor can you nominate bad files for deletion, so the fact that the only people that make edits are vandals make sense, the issue is the WMF actively discouraging good edits by mobile users. If the "Mobile" interface changes into a miniature version of the "Desktop view" interface today you'd see the percentage of mobile IP edits being identified as vandalism decline in a couple of months. Humans work with incentives and if you take away the incentives to do good things only bad things will happen. The WMF sabotages the mobile interface, not the vandals, they are simply a product of this disregard for mobile editors. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:44, 14 January 2022 (UTC)[reply]
Unless you mean exclusively ban mobile edits by non-registered users That's obviously what I meant. I don't support restricting mobile edits from registered users; that would be overkill. pandakekok9 02:22, 15 January 2022 (UTC)[reply]
  • Symbol support vote.svg Support Account creation is easy enough and is more private. As others have said, IP editing was a bad idea from the outset. But I doubt this will ever happen.
That said, most problem edits here on Commons seem to come from a handful of accounts, not the IPs. Andy Dingley (talk) 21:01, 14 January 2022 (UTC)[reply]
  • Pictogram voting comment.svg Comment This would a huge step to take, a major change, and we should consider it slowly and carefully before moving forward. The numbers below are a good start towards aiding an informed decision. --Malcolmxl5 (talk) 22:48, 18 January 2022 (UTC)[reply]

Banning IP edits: can we have some numbers, please?[edit]

Mobile/web uploads in 2014: that was crap and we could prove it

In the comments above I see a lot of opinions based on hypotheses and personal experience. While it's good the hear what's going on "in the trenches", I don't think that this is a decision that should be made on what in the end would be a collaborative gut feeling. When we decided to ban "mobile/web" uploads in 2014, we had good reasons to do so, because Lupo and others had done the research. One basic question we should ask before making any decision is, in my opinion: What is the actual ratio of good vs. bad edits made by IPs, and how does that compare to registered users? "Good" and "bad" are to be defined, but a simple starting point could be looking at the revert ratio. That shouldn't be too difficult to extract that from the database, right? --El Grafo (talk) 11:23, 14 January 2022 (UTC)[reply]

@El Grafo: Thanks, that's exactly what I am saying, too. The statistics added below are a start, but there is no comparison to registered users yet. Gestumblindi (talk) 19:37, 14 January 2022 (UTC)[reply]

Statistics[edit]

I did some statistics with the data from the API querying with "recentchanges". The edits are between 2021-12-15 13:40 and 2022-01-14 13:42. There are little inconsistencies for unknown reasons.

All IPs IPs with >100 edits IPs with 10-100 edits IPs with 2-9 edits IPs with 1 edit IP edits mobile All users (no IP, no Bot) Users with <10 edits
IPs/Users in group 7378 85 449 2299 4545 3803 24540 18039
Edits in group 54983 29975 13304 7359 4545 7889 2866015 48517
% of IP/User edits 100% 54.5% 24.2% 13.4% 8.3% 14.3% 100% 1.7%
Unchecked edits 50874 28252 12530 6858 4230 5550 569508 (autopatrol as checked) 43620
% of unchecked edits 92.5% 94.3% 94.2% 93.2% 93.1% 70.4% 19.9% 89.9%
Checked edits (Revert + Patrol) 4109 1723 774 501 315 2339 2296507 (autopatrol as checked) 4897
% of edits checked 7.5% 5.7% 5.8% 6.8% 6.9% 29.6% 80.1% 10.1%
Patrolled edits 1845 528 211 130 51 673 20488 627
% of edits patrolled 3.4% 1.8% 1.6% 1.8% 1.1% 8.5% 0.7% 1.3%
Reverted edits 2264 1195 563 371 264 1666 39394 1063
% of edits reverted 4.1% 4% 4.2% 5% 5.8% 21.1% 1.4% 2.2%
% of checked edits reverted 55.1% 69.4% 72.7% 74.1% 83.8% 71.2% 1.7% 21.7%

I also want to have a look at mobile edits, I am a working on this. --GPSLeo (talk) 17:09, 14 January 2022 (UTC)[reply]

Added mobile data not divided by edit count. Mean edit count for all IPs 7.5 and 2.1 for IPs edited mobile. The median is 1 for both cases. --GPSLeo (talk) 17:58, 14 January 2022 (UTC)[reply]
So overall, we have 55% garbage from IPs among on 7.5% patrolled/checked edits only? Wow, this is even worse than I thought. It also means we have probably around 25,000 bad edits nobody checked. --Yann (talk) 19:18, 14 January 2022 (UTC)[reply]
No reason to assume that edits that aren't explicitly patrolled are all bad. Gestumblindi (talk) 19:40, 14 January 2022 (UTC)[reply]
Nobody assumes this. Yann assumes that "only" 55% of unpatrolled edits are bad. Face-smile.svg --157.25.242.36 19:52, 14 January 2022 (UTC)[reply]
Meh, I expected something like 80%. Face-smile.svg @GPSLeo: It would be more transparent if you posted queries/scripts used to create the table. --157.25.242.36 19:52, 14 January 2022 (UTC)[reply]
I copied the API script and some of the analyze functions to User:GPSLeo/stats-tools --GPSLeo (talk) 22:06, 14 January 2022 (UTC)[reply]
Do patrollers typically choose what edits to check? If suspicious edits are more likely to be checked, the garbage would be concentrated in the checked ones, and the percent of garbage could be lower in the remaining >90% of edits. –LPfi (talk) 14:25, 15 January 2022 (UTC)[reply]
Yes of course if you come to a page and see that there is spam on the page you revert these edit. If the page looks fine you do not go to the version history to look if there are unpatrolled edits. If you are actively patrolling with tools like RTRC you can filter for marking and abuse filters. That is why the mobile edits are much more patrolled. To estimate the under reporting you would have to check more edits and look how the rate of reverted edits changes. If the rate of reverted edits does not decrease you would know that the rate of bad edits of all edits is nearly the same as in the checked edits. If you do not not find much more edits to revert you know that the bad edits where already found and nearly all unpatrolled edits are okay. --GPSLeo (talk) 14:51, 15 January 2022 (UTC)[reply]

Is there a good editor / organizer for Wikimedia?[edit]

I've been pretty active lately uploading images and reorganizing them (categories, etc.) where nnecessary. Now I've been doing all of this manually via the website; adding categories; or editing the source text to apply multiple edits; that kind of thing. But I think I heard/read one time that there are tools to more easily move multiple images for instance. Is that true and does anyone have experience working with it? If so I'd like to know more, because that would be great for some jobs... Greetings, RagingR2 (talk) 16:49, 7 January 2022 (UTC)[reply]

VisualFileChange (see under Preferences | Gadgets) can do a lot, but it's not the friendliest. Please ask me if I can help with anything specific. Andy Dingley (talk) 17:02, 7 January 2022 (UTC)[reply]
Looking at the description of that tool it's not exactly what I was looking for, but I'll let you know if I decide to use it and need any help! Greetings, RagingR2 (talk) 17:03, 12 January 2022 (UTC)[reply]
@RagingR2: Check also Help:Cat-a-lot and Help:HotCat. I remember what it was for me to work categorization without these and other stuff such as Help:VFC and MediaWiki:Gadget-GalleryDetails.js: It got suddenly so much better! -- Tuválkin ✉ ✇ 13:11, 12 January 2022 (UTC)[reply]
Thanks, sounds great. I have enabled it but even though I emptied my browser cache I don't see it appearing on category pages yet. Maybe I am doing something wrong... I'll try again later. Greetings, RagingR2 (talk) 17:03, 12 January 2022 (UTC)[reply]
@RagingR2: You may need to close and reopen your browser the first time. You will also need to enable java script for Wikimedia Commons if you use a script blocker like "No Script." Cat-a-lot should appear as a tiny icon in the bottom right of your browser screen on categories and search result pages; it is often easy to miss. From Hill To Shore (talk) 17:22, 12 January 2022 (UTC)[reply]
THanks, it works now! Greetings, RagingR2 (talk) 23:16, 14 January 2022 (UTC)[reply]

Hamburg S-Bahn station[edit]

Wich stations? Smiley.toerist (talk) 23:12, 7 January 2022 (UTC)[reply]

Hamburg S-Bahn 1989 1.jpg
I suspect Stellingen, as the only S3 station ending with 'en' on the station sign.
@Smiley.toerist: In the second photo, where did you see the -en ending? The sign next to the clock is a timetable announcement displaying the departure time to Neugraben, but it is not the name of the local station. As to the first pic, I don't know either. The sign above the benches is just an advertisement for some cemetery gardeners. De728631 (talk) 16:36, 8 January 2022 (UTC)[reply]
After playing with contrast and brightness, I found also that the sign on the very left edge of the second image says "Süßwaren" (sweets), so that's just a shop and not the station sign either. De728631 (talk) 16:56, 8 January 2022 (UTC)[reply]
See those blue brick walls and what seems to be a railyard in photo 2? Looks like an older version of Elbgaustraße. --HyperGaruda (talk) 17:19, 8 January 2022 (UTC)[reply]
Yes, I was also thinking about some stations in the northwest area. It might also be Eidelstedt. De728631 (talk) 17:43, 8 January 2022 (UTC)[reply]
where in Hamburg?

January 11[edit]

Structured Data on Commons: references for files' metadata are now live[edit]

Tracked in Phabricator
Task T230315

Hello everybody! A small, yet important change is coming to Structured Data on Commons: users are now able to add references to a file’s metadata.

References were always a part of the project, but until now they weren’t visible to end users, nor was there an interface to add them. This has been fixed with the current update.

References for Structured Data on Commons will work exactly like they work on Wikidata: you can use URLs or items for reference; adding, removing and changing references will share the same experience of doing it on Wikidata; and there will be no limit to the number of references that can be added.

I am here in case you have any questions or requests for more information. -- Sannita (WMF) (talk) 15:07, 11 January 2022 (UTC)[reply]

@Sannita (WMF): I'm testing the references features (which is great, btw) but still find a lot of Wikibase warnings (check this example). Is this the expected behavior? Thanks —Ismael Olea (talk) 15:51, 14 January 2022 (UTC)[reply]
@Olea thank you for noticing me. I'll pass this bug to the dev team, and they will investigate the problem. I guess something should be fixed, since from a Wikidatan point of view, it shouldn't behave like that. I'll keep you posted asap. ~~~~ Sannita (WMF) (talk) 18:12, 14 January 2022 (UTC)[reply]

January 13[edit]

New tool for coloring the world map[edit]

I'm moving to her the pose below from Commons talk:Graphic Lab/Map workshop#Tool for coloring the world map:
"I've created a python code that makes effortless to color the world map. Feel free to check it out:[1]--Mikey641 (talk) 22:22, 10 January 2022 (UTC)"[reply]

Look like usfull tool. -- Geagea (talk) 10:05, 13 January 2022 (UTC)[reply]

There's a similar tool for coloring the states of the U.S. (with a GUI) here: https://svg-map-maker.toolforge.org/ Nosferattus (talk) 03:16, 17 January 2022 (UTC)[reply]

Proposal: Update Wikimedia Commons' default markup for 'Use this image' Inbox[edit]

Tracked in Phabricator
Task T299064

I have raised a ticket to change the default text component of the markup snippet generated by our "use this image" links, on file pages, so that it will use the structured data caption, where available, instead of repeating the file name. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:44, 13 January 2022 (UTC)[reply]

Alsdorf steam activity[edit]

Alsdorf Anna mine 1986 2.jpg

I scanned several 1986 slides of a working steam locomotive at Anna coke plant by Alsdorf. (Alsdorf Anna mine 1986 1.jpg to Alsdorf Anna mine 1986 6.jpg). The location is close to Category:Bahnhof Alsdorf-Annapark but clearly an other subject. Some new categories are needed for the 'Coke plant', the industrial rail operator and locomotive type.Smiley.toerist (talk) 11:33, 13 January 2022 (UTC)[reply]

Not used files by user[edit]

Is there a tool or a gadget to list all files uploaded by X that are not used on any page in any project? Wostr (talk) 14:42, 13 January 2022 (UTC)[reply]

  • @Wostr: Can you give some context as to why you would want that? I'm guessing that only about 10% of all images on Commons are "used" in this sense within WMF projects. - Jmabel ! talk 17:09, 13 January 2022 (UTC)[reply]
    • @Jmabel: I have over thousand files uploaded, some of them were meant to be a replacement for files (a few thousands) that are going to be proposed for deletion. I can easily see all files uploaded by me using Special:ListFiles and in the same way files of a banned user (most of them will be proposed for deletion). However, I can't – other than manually – check which files uploaded by me are already in place, which are still not used, and which files of this banned user need to be redrawn and replaced by correct ones. Wostr (talk) 17:19, 13 January 2022 (UTC)[reply]
  • Why are files being deleted solely as the uploads of a banned user? Andy Dingley (talk) 17:30, 13 January 2022 (UTC)[reply]
    • That is not the reason for deletion, but that discussion is not about those files. Wostr (talk) 17:54, 13 January 2022 (UTC)[reply]

January 14[edit]

Scan the world[edit]

Hello. A series of 3D images have been uploaded to Commons in the .stl format. While they seem to be freely licensed, the description associated with these files seems a bit promotional. Let me quote it for you:
This object is part of "Scan The World". Scan the World is a non-profit initiative introduced by MyMiniFactory, through which we are creating a digital archive of fully 3D printable sculptures, artworks and landmarks from across the globe for the public to access for free. Scan the World is an open source, community effort, if you have interesting items around you and would like to contribute, email stw@myminifactory.com to find out how you can help.
While the "Scan the World" initiative may be non-profit, MyMiniFactory certainly is not.
As you probably don't know what I am talking about, here is an example File:Burj Khalifa.stl. Cheers, --SVTCobra 01:56, 14 January 2022 (UTC)[reply]

  • I would say that moderate self-promotion is not nearly as problematic as the lack of an actual description and any categories that aren't simply about themselves and the technical nature of the file.
  • I would not discourage them from uploading, but I would feel perfectly free to overwrite the so-called description. - Jmabel ! talk 04:00, 14 January 2022 (UTC)[reply]
OK, thanks, but "they" (being the company) are not doing the uploads. User:RuleTheWiki is uploading them and then adding them to Wikipedia articles. It was severe enough that it was brought to WP:COIN. I brought it here as it is obviously outside the purview of a Wikipedia noticeboard. Cheers, --SVTCobra 04:26, 14 January 2022 (UTC)[reply]
(You didn't mention the Wikipedia issue in your original post.) Wikipedia has far more concern with conflict of interest than we do on Commons. Basically, if the image is useful, we don't generally care if it's somewhat self-promotional. The uploader, especially someone uploading third-party work, doesn't have real "ownership" over the description, especially if the description as originally given is not useful. I believe the licenser actually could put a statement like that as part of the required attribution, but it appears they haven't, so we can just overwrite it with a useful description. The problem isn't with the files themselves, it's with the description, right? - Jmabel ! talk 04:31, 14 January 2022 (UTC)[reply]
Yes, indeed, Jmabel, it is the description which is visible when a thumb of these 3D images is clicked (and it's necessary to click to get the 3D experience). If I had to guess, it was mainly the email address bleeding through that got it reported to COIN. I have already told the uploader they are not obligated to copy the source's description. And at the very least it should describe the file and not be a generic text. Thanks you so much for your feedback. Cheers, --SVTCobra 05:09, 14 January 2022 (UTC)[reply]
As a concession to @AndyTheGrump i have rectified the description for all files that i have uploaded. RuleTheWiki (talk) 06:23, 14 January 2022 (UTC)[reply]
@RuleTheWiki: Thanks for updating the description. However, at least File:Burj Khalifa.stl has an unrelated but important issue: it is not compatible with COM:L. The source provided at the file description page only leads to this user/project page. Had it been correctly pointing to [2], it would have been immediately clear that it is licensed CC-BY-NC-SA 4.0 rather than CC-BY-SA 4.0. That means commercial use is not allowed, which means that per our own rules it's not allowed on Commons. Any chance they can change the license at myminifactory.com? Because otherwise we'd have to delete it ... --El Grafo (talk) 09:00, 14 January 2022 (UTC)[reply]
You'd have to ask @Jonathanbeck because apparently they're the person behind 'Scan The World' and their uploaded objects are under CC-BY-SA, I'm not sure if that's the correct license or the one listed on their user page on MyMiniFactory is the correct one. RuleTheWiki (talk) 11:01, 14 January 2022 (UTC)[reply]
I see that File:Burj Khalifa.stl has been nominated for deletion as "Derivative work of the Burj Khalifa; the design is considered copyrighted by its architect(s)." No comment on whether that is valid grounds, though I would note that I'm unsure how the file (relating to a building 2722 ft high) could be the result of a 3D scan -you'd need a helicopter to scan it, which seems rather unlikely for the open-source Scan the World project. More to the point, the issue with licensing seems to apply to other Scan the World files too: both File:Big Ben (detailed).stl and File:Statue of Liberty.stl seem to be marked CC-BY-NC-SA on the MYMiniFactory website, and there may well be more. There may be further legal issues too: I note that File:Scan the World - SMK17 - KAS2036 - David With The Head of Goliath (Donatello).stl, also uploaded by Jonathanbeck has a notice indicating that "the uploader of this file has agreed to the Wikimedia Foundation 3D patent license..." No idea whether such a notice is ever necessary (it might seem unlikely for this file at least, since the object scanned dates to the Renaissance) but the fact that it is there has to be an indication that someone thought it was. AndyTheGrump (talk) 16:47, 15 January 2022 (UTC)[reply]
NB: I think that patent template may be a default thing you have to agree to when uploading anything .stl. There were some concerns about this when 3D model uploads were enabled, but I can't find the discussion right now ... El Grafo (talk) 12:13, 17 January 2022 (UTC)[reply]

Can an image with extraordinary aspect ratio appear on the front page as Picture Of The Day?[edit]

Chinese scroll showing Hajj pilgrimage routes

Posting here because Commons talk:Picture of the day is low traffic and my question there was never answered. This scroll image passed Featured Picture review last year. I'd like to be able to include it in Picture Of The Day, not least because it relates to the Hajj, which is an important topic for Muslims, who make up a quarter of the world's population. Because the aspect ratio of this image means it is not legible on the front page in its original form, I took the step that has been used in the past for FPs on English Wikipedia and extracted part of the image to act as a preview on the front page. That scheduled image was reverted since the extract did not have Featured status. This I can understand, but the question remains of how this distinctive, time-relevant Featured Image can appear as Picture of the Day. MartinPoulter (talk) 14:07, 14 January 2022 (UTC)[reply]

January 15[edit]

Question regarding DR transclusions[edit]

Hello!

When a DR is created at the same page as a previous DR a problem arises. The current DR gets shown at Commons:Deletion requests/Archive/YYYY/MM/DD and the previous DR at Commons:Deletion requests/YYYY/MM/DD. This is of course because the entire DR page is transcluded onto both the current and archive DR page. When the second is closed both DRs will bo shown on their respective archive page. Is there anyway to fix this? Something like a partial transclusion?Jonteemil (talk) 04:19, 15 January 2022 (UTC)[reply]

@Jonteemil: Hi. The software doesn't support partial transclusion to both pages. Noincluding any closed section would unfairly remove it from display in the archive(s). We are used to seeing the history of DRs of a page (or a mass of pages) when it is renominated for deletion.   — Jeff G. ツ please ping or talk to me 06:39, 15 January 2022 (UTC)[reply]
An easy technical solution would be to automatically create second (2nd, or third) pages when nominating the file for deletion (again), for example "Commons:Deletion requests/File:Dubious file.whatev" and then "Commons:Deletion requests/File:Dubious file.whatev/2nd nomination" and that only the second nomination is transcluded in the current list of DR's, second pages can easily be added to talk pages using "Kept2", "Kept3", "Kept4", "Kept5", Etc. for every nomination. The first DR would automatically be "noincluded" but visible when visiting the DR page itself. Since the software can already see if a page had earlier been nominated for deletion I don't think that such a solution would be technically difficult. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 02:02, 16 January 2022 (UTC)[reply]
@Donald Trung: I'm confused, where would you noinclude what, exactly?   — Jeff G. ツ please ping or talk to me 04:25, 16 January 2022 (UTC)[reply]
It looked quite clear in my head but I can see why it might not have translated well into text, as an illustration it would look like this:
== File-Dubious image.whateverdude ==
  • Original deletion nomination. (Fully transcluded at 16-01-2022.)
Then a second (2nd) nomination
== <noinclude>File:Dubious image.whateverdude</noinclude> ==
  • <noinclude>Original deletion nomination.</noinclude> (Fully transcluded at 16-01-2022, not at 30-05-2023.)
== File-Dubious image.whateverdude (2nd nomination) ==
  • 2nd (second) nomination (only transcluded at 30-05-2023.)

Now because the second (2nd) page is a sub-page of the first (1rst) page it will change to:

== File-Dubious image.whateverdude ==
  • Original deletion nomination. (Fully transcluded at 16-01-2022.)
  • <noinclude>{{Commons:Deletion requests/File:Dubious image.whateverdude (2nd nomination)}}</noinclude> (Not transcluded at 16-01-2022.)
And because the first (1st) page is already the original it is easily accessed through subsequent nominations. It is really simple and all edit buttons will remain visible and will bring you to the relevant page, the original page will be transcluded on subsequent pages but not in general deletion request lists. I hope that I've now managed to explain it clearly. So the 2nd nomination page has "<noinclude>{{Commons:Deletion requests/File:Dubious image.whateverdude}}</noinclude>" at the top. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:21, 16 January 2022 (UTC)[reply]

@Jeff G.: , it would work probably like these concept pages, I changed the "== Exmaple.jpg ==" to "; == Example.jpg ==" to not break this page.


This deletion debate is now closed. Please do not make any edits to this archive. You can read the deletion policy or ask a question at the Village pump. If the circumstances surrounding this file have changed in a notable manner, you may re-nominate this file or ask for it to be undeleted.
== File:Example.jpg ==

Example of a good argument as to why this image should be deleted. --Not Donald Trung 『不是徵國單』 (Probably some Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:27, 16 January 2022 (UTC)[reply]

Kept: Per "User:Also not Donald Trung". --Mrs. Sysop 『管理員』 (Discuss my actions 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:39, 16 January 2022 (UTC)[reply]


== File:Example.jpg (2nd nomination) ==

I believe that this image should be deleted because of (insert argument here). --Someone that really doesn't like this file『刪除宣導者』 (Come talk to me, if you dare! 🤬💬) (WikiProject Numismatics 💴) (Articles 📚) 10:34, 16 January 2022 (UTC)[reply]

Both of these pages are transcluding each other, but could be transcluded separately. Neither page would show up in the other's DR list, so old discussions would only be visible where they are relevant. This would require so little changes that I think that the software could automatically make this a thing for new DR's. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:51, 16 January 2022 (UTC)[reply]

@Donald Trung: Both of these pages are transcluding each other, but could be transcluded separately. Neither page would show up in the other's DR list, so old discussions would only be visible where they are relevant. If this is correct I guess it's good. It's too bad that you have to create a new page each DR, eventhough it will be transcluded to the old one, but I guess this is a good solution as is possible. I think the new DRs should be transcluded onto the first one rather than vice versa though.Jonteemil (talk) 18:34, 18 January 2022 (UTC)[reply]
In the above proposed system users wouldn't have to do anything, the software automatically detects if a current DR for the image or group of images exists and automatically makes a sub-page that transclude the first (1st) and / or any prior deletion discussions, the "Nominate for deletion" button would do all the work and the end user would see no difference, other than that daily lists of DR's aren't cluttered with long gone old discussions only relevant to the current discussion.
Theoretically I also want Undeletion Requests (UDR's / UnDR's) to link "See also's" to prior deletion discussions, but that would require them to also have their own sub-pages, which despite already being approved by the community doesn't have a bot doing it. So even if there is consensus for a change someone with the technical know-how needs to implement it. The above would most likely just be an uncontroversial maintenance change, but if nobody who can do it will do it it will simply remain a proposal. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:18, 18 January 2022 (UTC)[reply]

unable to publish my work that i want to change something in Wikipedia[edit]

rabi crop is my website but whenever i share my website pics it got deleted please help me regarding this — Preceding unsigned comment added by Suraj kumar singh good (talk • contribs)

Your so far only deleted upload is File:Kharif Crops Examples.png, which was deleted as it is considered an advertisement. In addition, how should anbody here know that rabicrop.com is your website? Furthermore, having an image on your website doesn not necessarily mean, it's your own work, it might be licensed from somebody else. But whether this license is compliant to our policy COM:L, how should we know, when there is no information on your website. Finally, the terms of your website state "You must not: Republish material from Rabi crops / Sell, rent or sub-license material from Rabi crops". --Túrelio (talk) 10:46, 15 January 2022 (UTC)[reply]
You could go through the COM:VRT process to establish that the web site is yours. And/or you could indicate any relevant licensing on your web site, then cite it as a source. But, in either case: we don't want advertising, and you can only license work for which you own the copyright. - Jmabel ! talk 16:05, 15 January 2022 (UTC)[reply]

File:Flag of South Korea (1949–1984).svg is doubtful.[edit]

​​​The 1949 flag law stated that the construction was the same as the current one (File:Flag of South Korea (construction sheet).svg). Therefore the flag in 1949 should look like File:Flag of South Korea (1984–1997).svg.--Mike Rohsopht (talk) 11:12, 15 January 2022 (UTC)[reply]

Category:May Torok von Szendro[edit]

Hello! On this page, 3 inscriptions are incorrect. https://commons.wikimedia.org/wiki/Category:May_Torok_von_Szendro The Muslim passport (which I sent to a Hungarian editor) is for a non-Christian name. The signature is not a signature, but a seal, and it is not countess Török but Djavidan. The image highlighted in the passport also depicts a Muslim lady, not the false Török May. How can these be improved? puskas.istvan@teleheting.hu — Preceding unsigned comment added by Lajokka (talk • contribs) 13:38, 15 January 2022‎ (UTC)[reply]

@Lajokka: Hi, and welcome. Please use internal links. You are welcome to edit directly or use RenameLink or {{Rename}} to correct those faults, as needed.   — Jeff G. ツ please ping or talk to me 14:08, 15 January 2022 (UTC)[reply]
Hello Jeff.
I’ve just started editing Wikipedia these days, I don’t know anything yet. Djavidan Hanum was my aunt, so I got into editing at my age of 65. People have a right to know the truth. You can reach me at: puskas.istvan@teleheating.hu Lajokka (talk) 22:33, 15 January 2022 (UTC)[reply]
  • The image on the passport is the same image we already have of her, I don't think I understand what the problem is. It also matches the image found at other reliable websites like Geni and Familysearch. --RAN (talk) 18:16, 15 January 2022 (UTC)[reply]
    This is a mistake. The Turkish passport bears a Muslim name, which is Princess Djavidan Hanum.
    countess Marianne Török is a fatal mistake, because Marianne is the older sister to the Djavidan.
    Half-sister, only their mom is common.
    This lady (Djavidan) was never baptized, her only European name was established by a court, and that is "Puskás Májuska".
    I uploaded her verdict, but it went here:
    https://commons.wikimedia.org/wiki/File:Inheritance_lawsuits,_a_claim_lawsuit.jpg
    Because I'm still lame in wikipedia editing.
    If you can, please help change the picture because it is outrageous to depict a queen with a passport picture. Lajokka (talk) 22:23, 15 January 2022 (UTC)[reply]
The passport picture is so low resolution that it is useless. Are you asking for it to be deleted? --RAN (talk) 07:31, 16 January 2022 (UTC)[reply]
Hello RAN! You're right, but I don't have a better passport picture. Let's change the face instead. I have a picture of a princess dress, but I don’t know how to change it. This image is also unpleasant because, according to contemporary newspapers, she was a remarkable beauty. Lajokka (talk) 21:15, 16 January 2022 (UTC)[reply]

MediaViews for files on Commons[edit]

Just fixed the pageinfo link so that for files we now have a direct link to the statistics. Take a file, click on page information in the left toolbar, scroll to the bottom and you'll find a link to the MediaViews. In my opinion much more interesting than the page views for files. Multichill (talk) 17:17, 15 January 2022 (UTC)[reply]

Thanks, I didn't even know this existed -- El Grafo (talk) 12:02, 17 January 2022 (UTC)[reply]

Image of the Day[edit]

Today is the 15th, but it seems the whole day the IOTD for the 14th was shown!? --84.135.119.170 20:51, 15 January 2022 (UTC)[reply]

Never mind, it just updated - may have been a cache related problem..

January 16[edit]

Unexpected search results[edit]

To help with some pending DRs from a mass upload, I just tried this search — and the results are, so to say, unexpected: Isn’t -incategory:"foo" working anymore? -- Tuválkin ✉ ✇ 10:40, 16 January 2022 (UTC)[reply]

I thinks it does work. "-incategory" results in all files with Portugal, but not in the category. Do I miss something? --C.Suthorn (talk) 12:05, 16 January 2022 (UTC)[reply]
@Tuvalkin: Your search link comes out as 'Portugal -incategory:"Photos_uploaded_from_Flickr_by_Matlin_(needing_check)"'. The use of the "-" character (minus in this case) removes results from Category:Photos uploaded from Flickr by Matlin (needing check), so all the files showing Portugal that were not (uploaded by Matlin and needing check). Getting rid of that minus character results in this other search, showing Matlin's uploads one might want to check if one was in or very familiar with Portugal, which I guess is what you were going for.   — Jeff G. ツ please ping or talk to me 13:40, 16 January 2022 (UTC)[reply]
@Jeff G. and C.Suthorn: Never mind, you are right: I have no excuse for overlooking that "-", been using it correctly for years. I blame the coffee! (but lack or excess thereof…?) -- Tuválkin ✉ ✇ 15:10, 16 January 2022 (UTC)[reply]

Categories that can't be edited/removed -- any help??[edit]

Does anyone know why some of the files in this category seem to have the category "hard coded" into them? Category:Stations of the Cross in the Netherlands

1) I can't move the files to a subcategory (stations number 1 to 14) using cat-a-lot;

2) When I go to a file's page, the category shows up at the bottom, but it can't be removed or edited,

and 3) when I open the source text for those files pages, I don't see the category listed in the source. How does this work? WHY does it exist? And how do I circumvent or change it? So that I can move these files to their suitable subcategories (stations 1-14).

P.S. I have also seen this same phenomenon in categories with historical photographs in the Netherlands; i.e. black and white photographs from our national heritage service. When those photographs (or a category of them) shows up in the main category for (for instance) a city, and you want to move it to a subcategory like "Historical photopgraphs of [city]", sometimes you can't; which is pretty frustrating.

Greetings and thanks for any help, RagingR2 (talk) 14:59, 16 January 2022 (UTC)[reply]

@RagingR2: Some times, categorization is not simply present in a subcat’s wikicode, but transcluded through templates. When Cat-a-lot attempt to remove that non-existent reference, error ensues. -- Tuválkin ✉ ✇ 15:12, 16 January 2022 (UTC)[reply]
@RagingR2: If you can point to a specific file that you are having problems with, we can identify where the existing category is coming from. From Hill To Shore (talk) 16:04, 16 January 2022 (UTC)[reply]
@RagingR2: Looks like you ran into one of my old batch uploads. I think the clean up bot died in one of the Toolserver/Toollabs/Toolforge mishaps.
Maybe time to kill {{RCE-subject}}. In these cases the trick is to replace {{RCE-subject|Kruiswegstatie}} with {{subst:RCE-subject|Kruiswegstatie|subst=subst:}} (example). Things that are not mapped ended up in Category:RCE suggested categories. Multichill (talk) 17:52, 16 January 2022 (UTC)[reply]
By "kill {{RCE-subject}}" I assume you mean just remove that block of code from the source text of a specific file? If have no idea how these templates work in general ; I have never worked with them. But replacing the block of text as you suggested should be doable even for me. :) By the way if I look in the source text for File:Kruiswegstatie_I_-_Tilburg_-_20355327_-_RCE.jpg for instance, I see (at least) three templates mentioned onder the License header: RCE-license, RCE-subject|Processiepark and RCE-subject|Kruiswegstatie. Are these other templates not a problem? Is it just the RCE-subject|Kruiswegstatie one that I should edit/remove???
P.S. And in the example that you linked, I see that you removed the RCE-Subject completely and replaced it with a normal category.
Greetings, RagingR2 (talk) 18:07, 16 January 2022 (UTC)[reply]
@From Hill To Shore: This is one example: File:Kruiswegstatie_I_-_Tilburg_-_20355327_-_RCE.jpg
The category "Stations of the Cross in the Netherlands" appears at the bottom of that page; but it can't be edited or removed; there is no (−) (±) buttons at the bottom, and if you press "edit" the category doesn't show up in the source text either.
Greetings, RagingR2 (talk) 18:00, 16 January 2022 (UTC)[reply]
Zie Commons talk:Rijksdienst voor het Cultureel Erfgoed#Oude templates opruimen. Multichill (talk) 18:43, 16 January 2022 (UTC)[reply]

Something is terribly broken in Template:Artwork[edit]

Village pump

File:Alphonse Mucha - Poster for Victorien Sardou's Gismonda starring Sarah Bernhardt.jpg was converted from {{Information}} to {{Artwork}}, and the parameters were not changed, but here's what's being passed to the "Artist" field:

|Author={{Creator:Alfons Mucha}} Restored by [[User:Adam Cuerden|Adam Cuerden]]

But the only thing actually shown is the creator template for Mucha. The rest of the credit line is removed.


This is... obviously broken. You can't just strip credit from people. What on earth is happening here? How many files are affected? Who thought this was a good idea?

Adam Cuerden (talk) 16:13, 16 January 2022 (UTC)[reply]

@Adam Cuerden: Actually the creator template should have been put into the |artist= parameter, but since there is a Wikidata entry, we don't need that either. I removed the creator template from the "Author" field and your work is now being credited again. De728631 (talk) 16:21, 16 January 2022 (UTC)[reply]

This topic has also been started at Template_talk:Artwork#This_template_is_stripping_credit. and answered over there. No need to create additional drama. Multichill (talk) 17:37, 16 January 2022 (UTC)[reply]

@Multichill: I apologise if this came off as dramatic; I wasn't sure who to contact about the template, so figured that a message here would be a good heads up. Adam Cuerden (talk) 18:59, 16 January 2022 (UTC)[reply]
@Adam Cuerden: In the rare case where there is a need to post in two places, it's best that one post be just a link to the other, possibly with a brief comment for context. - Jmabel ! talk 02:50, 17 January 2022 (UTC)[reply]

Customizable image data for geographical maps[edit]

Sorry if this is off-topic here. I’m looking for ready-to-use but customizable image data that can be used to build your own maps. In particular this would be (SVG?) contours of countries (or regions within the countries) together with coordinate data where labels should be placed and probably other coordinate data for correctly placing the contours next to each other. (Ideally data that can also be used with LaTeX/TikZ, or that could be converted without too much effort.) Is there something like this available on Wikimedia Commons? I’d expect such data to be somewhere since many people are creating maps with all kinds of data for Commons; I’ve had a look at Commons:Map resources and think that contours may be available from (some? of) the SVGs at Commons:Map resources/Blank location maps, but I’m missing how I could get the corresponding coordinate information. Also the online tools linked there don’t seem to provide such data, they just let you create a map online and download an image file. --2A02:8108:50BF:C694:6C3E:7981:B6EC:318B 17:25, 16 January 2022 (UTC)[reply]

I suspect you might find someone at Commons:Graphic Lab/Map workshop who knows more about this. - Jmabel ! talk 02:51, 17 January 2022 (UTC)[reply]
As you've already found out, image files don't normally carry coordinates to locate them. The "proper" way to do this is using en:Geodata (vector data of country outlines, in your case). Natural Earth is a good starting point for that, and it's all Public Domain (some of that is available at Commons in the Data: namespace, but it's difficult to find and use). In order to handle that data and turn it into a map, you'll need a Geographic Information System. en:QGIS is a great GUI-based option, but there are alternatives. It takes a bit of learning to get into this whole thing, but if you're into making maps it opens up entire new worlds. And it's really not difficult at all once you've got the basics down. Whether that still counts as "ready to use" is another question ... --El Grafo (talk) 11:56, 17 January 2022 (UTC)[reply]
I didn’t know about Natural Earth and for the moment it seems to be indeed very close to what I was looking for. Thank you very much! I’ve downloaded the 1:100 Cultural Vectors set and managed to read in the shapes and attributes file, so I’m quite confident this will do for me. Yes, further digging into the matter will take some time I think… --2A02:8108:50BF:C694:8A8:D58:68EF:5C0 22:10, 19 January 2022 (UTC)[reply]
Awesome, good luck with that! --El Grafo (talk) 06:52, 20 January 2022 (UTC)[reply]

January 17[edit]

Wrongly categorized photos at Category:Commodores[edit]

The category has a blend of one group and another group using the same name. One group is an American R&B; the other is some sort of military orchestral band (or something like that). I don't know who's interested in such cleanup... or suggestions. George Ho (talk) 09:19, 17 January 2022 (UTC)[reply]

The correct cat would be Category:Navy Commodores, a cat, that already exists, but I don't know how a bot could possibly solve that, it's probably a task for humans. Grüße vom Sänger ♫ (talk) 09:52, 17 January 2022 (UTC)[reply]
Been there, done that Face-wink.svg It was as well two commodores of the US Navy, also in two sub-cats. Grüße vom Sänger ♫ (talk) 10:24, 17 January 2022 (UTC)[reply]
Thanks a bunch. I've also requested a move on the category, ensuring that something like this doesn't happen again. George Ho (talk) 10:26, 17 January 2022 (UTC)[reply]
Where will this be discussed? The correct name for the cat would be Category:The Commodores, not some weird stuff with long brackets. Grüße vom Sänger ♫ (talk) 11:25, 17 January 2022 (UTC)[reply]

I went to the category and found a small handful of photos from a rinky-dink concert held well after the group's prime. It suggested to me that this yet another category created solely to support a Wikidata infobox. As for any confusion, adding explanatory text and/or hatnotes to the category page worked just fine for years and years. Is there a reason why people refuse to do that anymore?RadioKAOS (talk) 13:14, 19 January 2022 (UTC)[reply]

Wrong preview of PDF pages[edit]

Hello everyone, the preview of pages of File:Grammatica Germanicae Linguae.pdf consists of a lot of white space. Does anyone know what the problem of this file is? Thank you in advance, --Arnd (talk) 19:01, 17 January 2022 (UTC)[reply]

  • I hate when people scan the entire scanner bed and do not use the preview feature to set the scan boundary. This is the first I have seen it compiled into a pdf, usually after one page you notice the error and set the scan boundary. --RAN (talk) 01:32, 19 January 2022 (UTC)[reply]
RAN, but why within the PDF all looks fine? --Arnd (talk) 14:14, 19 January 2022 (UTC)[reply]

Update on Nicholas Alahverdian images[edit]

Hello everyone. On request of Wikimedia Foundation counsel, we have restored the images previously deleted following a takedown request. For clarity, this affects the following files:

You are welcome to discuss this action at COM:DMCA#Nicholas Alahverdian. Thank you! Joe Sutherland (WMF) (talk) 20:18, 17 January 2022 (UTC)[reply]

Template Creation[edit]

I believe that the creation of templates on Brazilian political party websites that allow the reproduction of their files would be of great help. to make it clear, the parties that allow this are: PSOL [3] and PCB [4]. For me, the main reason for creating these templates is to show that a given site follows the Wikipedia Attribution Licenses, also because the sites belong to parties that are registered with the TSE. And with that, officially becoming a party.

Something that also makes me make this request is that images of logos, images of party affiliates and other images involving parties are uploaded here, but there is no notice that can be included about image licenses.

An asterisk, if the creation of these templates is implemented, I would also like to mention the sites of the PSOL deputies, since they adhere to the Creative Commons License by-sa 3.0 BR, which is compatible with Wikipedia. [5], [6] and [7] Luiz79 (talk) 23:09, 17 January 2022 (UTC)[reply]

January 18[edit]

Talk to the Community Tech[edit]

Community Wishlist Survey Lamp.svg

Hello

We, the team working on the Community Wishlist Survey, would like to invite you to an online meeting with us. It will take place on 19 January (Wednesday), 18:00 UTC on Zoom, and will last an hour. This external system is not subject to the WMF Privacy Policy. Click here to join.

Agenda

  • Bring drafts of your proposals and talk to to a member of the Community Tech Team about your questions on how to improve the proposal

Format

The meeting will not be recorded or streamed. Notes without attribution will be taken and published on Meta-Wiki. The presentation (all points in the agenda except for the questions and answers) will be given in English.

We can answer questions asked in English, French, Polish, Spanish, and German. If you would like to ask questions in advance, add them on the Community Wishlist Survey talk page or send to sgrabarczuk@wikimedia.org.

Natalia Rodriguez (the Community Tech manager) will be hosting this meeting.

Invitation link

We hope to see you! SGrabarczuk (WMF) (talk) 00:21, 18 January 2022 (UTC)[reply]

Subscribe to the This Month in Education newsletter - learn from others and share your stories[edit]

Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter (This Month in Education) invite you to join us by subscribing to the newsletter on your talk page or by sharing your activities in the upcoming newsletters. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context.

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaik@wikimedia.org.

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony (Talk), Thursday 20:58, 20 January 2022 (UTC)[reply]

.MP4 (again)[edit]

Tracked in Phabricator
Task T258540
Main gallery: Commons:Village pump/Proposals/Archive/2019/11#We don't have enough videos, some proposals to Improve the issue of meagre video files on Wikimedia Commons.

Back in 2019 there were several proposals to make uploading video files to the Wikimedia Commons easier (see above), among these was the proposal to allow MP4 (.mp4) files which was approved with 15 (fifteen) people voicing Symbol support vote.svg Support and a lone person voicing Symbol oppose vote.svg Oppose. However, despite there seemingly being concensus to allow the uploading of MP4 format files the MediaWiki Upload Wizard still doesn't allow them. This seems like a minor technical switch that can simply be turned on, right?

I found a treasure trove of video's over a century old on Google's YouTube streaming service, often by people who have been dead for almost a century, but importing these to the Wikimedia Commons ain't as easy as simply downloading it from there and then uploading it here. Format support is necessary to have an open platform anyone can contribute to. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:37, 18 January 2022 (UTC)[reply]

For context, all films issued during the Nguyễn Dynasty period in Vietnamese history are in the public domain, but using the Video2Commons software to import those here usually means having to wait like 4 (four) or 5 (five) hours before the file is uploaded. This system stops even passionate people from taking on video uploading projects, let alone noobs (novice users). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:00, 18 January 2022 (UTC)[reply]

Is that the way video2commons works? Isn't it possible to start v2c, then go back, start the next v2c process, then go back etc - then check the next day in the own uploads if all files succeeded? --C.Suthorn (talk) 22:16, 19 January 2022 (UTC)[reply]

Significant[edit]

Hi! I raised a question at Commons talk:Project scope/Precautionary principle about what the word "significant" mean. "The precautionary principle is that where there is significant doubt about the freedom of a particular file, it should be deleted." So as I understand it we should not delete files just because there is a small risk that a file is not free. The risk has to be significant. Question is how much significant is. Since the Precautionary principle is important I think it would be fair to make a post here as informatin. --MGA73 (talk) 16:23, 18 January 2022 (UTC)[reply]

It's a subjective word and different admins interpret it differently. Admin A: "Just because a file is a hundred years old with no listed author doesn't mean that it's in the public domain.", Admin B: "This file is over a century old by an unknown and/or anonymous author, it's unlikely to still be copyrighted." And both admins are right. The word probably just keeps the people that think that any suspicion is bad at bay, for example "This file has no metadata it must be copyrighted" despite scanners not always recording metadata and many image editors removing them or people removing them for privacy reasons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:33, 18 January 2022 (UTC)[reply]
I agree with Donald Trung and think there will be always some room for interpretation; we will not be able to achieve full consistency in decisions based on PRP. It should, however, prevent deletions based on mere suspicion without real base. The "no metadata" issue is a good example. Often, people nominate current "own work" images for deletion because the resolution is small and there is no metadata; this can be reasonable grounds for suspicion and for a deletion request indeed (often, such images are taken from somewhere on the web), but doesn't mean automatic deletion - we first have to check whether there is anything to confirm that suspicion, as it's absolutely allowed to upload your own images in lower resolution and Exif is not mandatory. Personally, in such cases, if I don't find any web source for the image with reverse image search tools such as Tineye and Google Images, and the uploader is otherwise in good standing (not known e.g. for mass copyright violations), I tend to keep such images. Gestumblindi (talk) 20:07, 18 January 2022 (UTC)[reply]
  • On a related topic of due diligence before nomination: When new uploaders participate, they tend to choose the default settings because our instructions are ambiguous. When you ask for the date, they choose the date of uploading, rather than the date of creation. They also choose own work, because they think you are asking who scanned it, or who uploaded it. We can fix these things with a little research, sometimes the correct information is in the filename. Before people nominate them for deletion, they should do some minimal due diligence to see if they can fix errors. I see so many deletion nominations because a scan isn't "own work" or the the image wasn't taken on today's date, despite all the correct information in the filename or at the linked source. There are at least a dozen public domain images nominated in the past two days whose only crime was the uploader ticking the box "own work" for a scanned image. See for instance Commons:Deletion_requests/Files_uploaded_by_Cadgepole --RAN (talk) 01:12, 19 January 2022 (UTC)[reply]

January 19[edit]

Films of France[edit]

When does a film enter the public domain in France? There is no specific mention of films in our copyright page for France. If it is considered a collective work, who is part of the collective? Would that include everyone listed in the credits? --RAN (talk) 01:25, 19 January 2022 (UTC)[reply]

@Richard Arthur Norton (1958- ): In France, films enter into the public domain 70 years after the author's death (usually the director, but other people involved may need to be taken into consideration, when they gave special artistic input). Regards, Yann (talk) 18:44, 19 January 2022 (UTC)[reply]

Audio recording from Gallica[edit]

Hi, Does anyone know how to get the audio recording from Gallica (French National Library)? As usual, everything is done so that we can listen, but we can't download them. :(( However some are undoubtedly in the public domain in France and in USA, so OK for Commons, e.g. [8] ; publication date: 1907, composer: Umberto Giordano (1867-1948), lyric artist: Giuseppe Armanini (1874-1915). Thanks, Yann (talk) 12:08, 19 January 2022 (UTC)[reply]

@Yann: I think I figured it out, though I didn't test it on other entries. Just drop the parameters from the URL and append '/f2.audio'. e.g. https://gallica.bnf.fr/ark:/12148/bpt6k1080412z.r=fonotipiaphonotypie?rk=21459;2 becomes https://gallica.bnf.fr/ark:/12148/bpt6k1080412z/f2.audio. – BMacZero (🗩) 18:03, 19 January 2022 (UTC)[reply]
@Yann and BMacZero: Please mind that this is originally an Italian recording, so you could use {{PD-Italy-audio}}. De728631 (talk) 18:10, 19 January 2022 (UTC)[reply]

January 20[edit]

Movement Strategy and Governance News – Issue 5[edit]

More languages • Please help translate to your language

Movement Strategy and Governance News
Issue 5, January 2022Read the full newsletter

Welcome to the fifth issue of Movement Strategy and Governance News (formerly known as Universal Code of Conduct News)! This revamped newsletter distributes relevant news and events about the Movement Charter, Universal Code of Conduct, Movement Strategy Implementation grants, Board elections and other relevant MSG topics.


This Newsletter will be distributed quarterly, while more frequent Updates will also be delivered weekly or bi-weekly to subscribers. Please remember to subscribe here if you would like to receive these updates.

  • Call for Feedback about the Board elections - We invite you to give your feedback on the upcoming WMF Board of Trustees election. This call for feedback went live on 10th January 2022 and will be concluded on 7th February 2022. (continue reading)
  • Universal Code of Conduct Ratification - In 2021, the WMF asked communities about how to enforce the Universal Code of Conduct policy text. The revised draft of the enforcement guidelines should be ready for community vote in March. (continue reading)
  • Movement Strategy Implementation Grants - As we continue to review several interesting proposals, we encourage and welcome more proposals and ideas that target a specific initiative from the Movement Strategy recommendations. (continue reading)
  • The New Direction for the Newsletter - As the UCoC Newsletter transitions into MSG Newsletter, join the facilitation team in envisioning and deciding on the new directions for this newsletter. (continue reading)
  • Diff Blogs - Check out the most recent publications about MSG on Wikimedia Diff. (continue reading)

Zuz (WMF) (talk) 08:20, 20 January 2022 (UTC)[reply]

Accidental duplication (more or less) of a file[edit]

Commons_talk:Featured_picture_candidates#File:Prangs_Valentine_Cards2.jpg - Just complicated enough that it's probably best to discuss before acting. Basically, a badly documented set of files led to a JPEG getting generated off a TIFF...which already had a JPEG version, and now both JPEGs, differing only in the settings chosen when converting to JPEG, are FPs. Adam Cuerden (talk) 10:08, 20 January 2022 (UTC)[reply]

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