Commons:Village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:Village Pump)
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

Turkey Beypazarı district Hırkatepe Village pump. [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]

  • After what seemed a good start, this seems to have pretty much stalled out 2 weeks ago at less than 10% of its goal. I strongly encourage people to consider donating. - Jmabel ! talk 03:41, 26 January 2022 (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]
@Andy Dingley I agree, it is not especially problematic in Commons, except for the severe security & provacy breach use of IPs is in every Wikimedia project. But they would not be missed either *shrugs*. Darwin Ahoy! 20:52, 21 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]
  • Symbol oppose vote.svg Oppose. My opinion on this is guided by my own experience. I started editing here anonymously. I don't think I would have done so if I had been required to sign up for an account first. I think my experience is unlikely to be rare. The cost of banning IP editing is far greater than just losing IP edits, it also includes losing all the edits from contributors such as me. Marbletan (talk) 21:57, 27 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]

January 18[edit]

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), Sunday 14:54, 30 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]
I think so, as I fell asleep with my last video, but you can't categorise the video in Video2Commons. But the current exclusion of .mp4 files also disincentivises new uploads as many users don't know about the other systems to upload. (As was expressed in the previous debate.). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:08, 25 January 2022 (UTC)[reply]

January 21[edit]

Uploaded PNG previews of SVG files: delete or?[edit]

what should be done when someone uploads PNG previews of SVG files? for example, File:Screenshot (167).png.

my impression of past experiences is that all these files would be deleted. RZuo (talk) 13:50, 21 January 2022 (UTC)[reply]

@RZuo:
Foregone deletion would violate policy. See COM:Redundant which states identical images using differing file types are considered for deletion on a case-by-case basis.
In this case, the PNG file is in use. I suspect that usage may be replaced with the SVG, and then a DR might succeed. The PNG has been around since Nov 2018, so I could see opposing a DR merely to preserve any external links that may have been made in the last 3 years. Several times I have followed links to Commons files only to discover the file has been deleted.
PNG versions can have a purpose. Sometimes a PNG of an SVG will be uploaded to illustrate rendering errors. WMF uses librsvg, and it commits several rendering errors. Such a PNG might be used in a talk page to describe the bug, so replacing that PNG with the SVG may be inappropriate. For example, some SVG rendering bugs have been fixed, so the SVG file would no longer show the rendering error. The PNG would be in use and not subject to deletion.
Glrx (talk) 18:16, 21 January 2022 (UTC)[reply]
  • I prefer saving the png, in many cases where a coat-of-arms is in svg, and is derived from the png, there have been small detail changes in color and in the choices of lions and eagles taken from stock svg files. This has been leading to drift away from the original in subtle ways. --RAN (talk) 03:20, 22 January 2022 (UTC)[reply]
    the case here is, the PNG is uploaded after the SVG.
    someone sees an SVG. out of the blue they download/screenshot the PNG previews generated from the SVG (those links underneath the pic on file pages), and then upload that PNG on commons.
    it's NOT "PNG versions that have a purpose". and it's NOT "svg derived from the png". it's plain junk uploaded by some clueless users. RZuo (talk) 09:23, 22 January 2022 (UTC)[reply]
  • Unused PNG previews should be speedy deleted IMO (no DR needed). — Draceane talkcontrib. 08:57, 25 January 2022 (UTC)[reply]

January 22[edit]

security feature[edit]

Keulen-Weiden West S-bahn station 2019 1.jpg

There is a special overhead structure to protect the railway from falling electricity wires. How can this be classified?Smiley.toerist (talk) 13:16, 22 January 2022 (UTC)[reply]

I'd suggest placing it in Category:Rail safety infrastructure or a subcategory. From Hill To Shore (talk) 00:19, 23 January 2022 (UTC)[reply]
How about Category:Overhead line supports? I once created a category containing this name. Overhead line gantries are similar, but the fact is not all overhead line supports are of truss structures. --トトト (talk) 15:50, 23 January 2022 (UTC)[reply]
  • Category:Rail safety infrastructure. There might be a further category for this type of temporary protection for overhead power lines (they're put in place when cables are being replaced above critical infrastructure such as roads). They're not railway infrastructure as such (at least not permanent), certainly not part of the (railway) overhead line equipment. Andy Dingley (talk) 16:10, 23 January 2022 (UTC)[reply]

Scope: academic articles[edit]

I believe academic articles published in peer-reviewed journals such as this one are in Commons scope. Is this correct? 4nn1l2 (talk) 20:45, 22 January 2022 (UTC)[reply]

@4nn1l2: Yes, I have personally uploaded dozens. —Justin (koavf)❤T☮C☺M☯ 06:35, 23 January 2022 (UTC)[reply]
@4nn1l2: To clarify: I could not load the web page you linked, but just to be clear, articles are in scope as such, but must be properly licensed, of course. E.g. the upload I just made is licensed CC BY 4.0. So as long as it has the proper license and meets a few other criteria, then yes, it's appropriate for Commons. —Justin (koavf)❤T☮C☺M☯ 10:44, 24 January 2022 (UTC)[reply]

January 23[edit]

PDF with password[edit]

Hi, Any idea how to remove the password in File:The Collected Works of Mahatma Gandhi, Vol-001.pdf? Thanks, Yann (talk) 22:51, 23 January 2022 (UTC)[reply]

@Yann: I uploaded the "PDF with text" version from archive.org. This has two benefits: it is not password-protected and it comes with searchable text instead of having scanned images on each page. Now there's still the URAA issue left though. De728631 (talk) 23:16, 23 January 2022 (UTC)[reply]
@De728631: Your version still has a problem, but I found another version without a password. The URAA issue is only for this edition, as this was previously published in small parts. Thanks, Yann (talk) 23:30, 23 January 2022 (UTC)[reply]
@Yann: If you have access to Acrobat DC, this can be done with that program. Otherwise, there are some fly-by-nite websites that will unlock PDFs for you and allow you to download the new versions. I would only use these if you have some solid ad-blockers in your browser and as long as you only upload documents that are not sensitive (who knows what these guys do with your uploaded PDFs???). Let me know if you need more help. —Justin (koavf)❤T☮C☺M☯ 10:53, 24 January 2022 (UTC)[reply]
I tried with Adobe Acrobat DC Pro, but I still can't remove the password. Yann (talk) 13:11, 25 January 2022 (UTC)[reply]
I found an easy way: open with Google Drive, print as PDF, enjoy! Yann (talk) 22:17, 25 January 2022 (UTC)[reply]

January 24[edit]

Dont understand the message[edit]

Hi, I don't understand this message "Warning: Default sort key "Tabery, Marta" overrides earlier default sort key "Taberyová, Marta"." If I look at the source code of the category, the default sort is correct. What is the point of this message? --Juandev (talk) 10:56, 24 January 2022 (UTC)[reply]

  • If one were to remove the {{Wikidata Infobox}} the message disappears, so it looks like it's doing something strange. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 10:59, 24 January 2022 (UTC)[reply]
@Juandev: The problem is that you cannot sort something two ways: you must choose one sort key (at maximum). In this instance, because the category includes {{Wikidata Infobox}} and that template uses information from d:Q64850421 in order to make a local sortkey that you cannot see in the code of the category, when you insert a second, local sortkey here, it conflicts with the initial one imported from Wikidata. The solution is to remove the local one and make sure that the data about the person's surname and personal name are correct at Wikidata. —Justin (koavf)❤T☮C☺M☯ 11:00, 24 January 2022 (UTC)[reply]
And to elaborate, d:Q37238554, is about the surname "Tabery", which is also known as "Taberyová" in Czech (but curiously, not in Slovak). —Justin (koavf)❤T☮C☺M☯ 11:03, 24 January 2022 (UTC)[reply]

Holocaust survivors classed as "freight"[edit]

I have twice reverted User:Wefrewe at File:Mother and daughter liberated from Bergen-Belsen train - 1945-04 - Clarence L. Benjamin.jpg, for their instance (per edit summary) in classifying holocaust survivors as "freight". I trust I shall not need to do so again. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:46, 24 January 2022 (UTC)[reply]

These carriages are called "Güterwagen" in German ("goederenwagon" in Dutch) and that translates to freight trains in English. So this is not about the people riding it, but the type of train used.
The inhumanity of transporting people like in freight trains is quite well documented. Looks like a case of lost in translation. Multichill (talk) 18:03, 24 January 2022 (UTC)[reply]
Güterwagen translates as "freight wagons", not "freight trains". The vehicles may be freight wagons; that does not make the people freight, in any language. The edit summary I quoted (in full: "These people are freight for German") was made in English. For shame.Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 24 January 2022 (UTC)[reply]
I have again removed their classification as freight. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:14, 24 January 2022 (UTC)[reply]
what's your point? they were transported in german freight trains, do you refute that?🙄--RZuo (talk) 19:49, 24 January 2022 (UTC)[reply]
Andy, are you really language shaming another user for not speaking proper English? And yes, these people were transported in freight trains so Category:Freight trains in Germany is correct. Multichill (talk) 21:10, 24 January 2022 (UTC)[reply]
No. And please keep your nasty insinuations about me to yourslef, as I have asked you previously, and on more than one occasion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:54, 25 January 2022 (UTC)[reply]
this whole thing seems like a storm in a teacup, but i suspect it's a case of overcat anyway, the file is already in Category:Holocaust trains shouldn't that category be in the relevant parent cats? Oxyman (talk) 21:05, 24 January 2022 (UTC)[reply]

Is this allowed? (almost 24.000 renames in 24 hours)[edit]

See here: to make a sort of set, Gaegae did almost 24.000 renames in one day [1]. I can't figure out if this is just right, or it is abuse of the file mover rights? - Richardkiwi (talk) (talk) 18:34, 24 January 2022 (UTC)[reply]

For me these mass moves are not covered by the COM:RENAME guidelines. --GPSLeo (talk) 18:57, 24 January 2022 (UTC)[reply]
That's what I thought, too. I can ask it themselves, but they are from Israel. - Richardkiwi (talk) (talk) 19:16, 24 January 2022 (UTC)[reply]
These files are files that should upload by me with COM:Pattypan tool. But the tool is broken. See the last 5 posts in Commons talk:Pattypan. So User Matanya helped me and uploaded the file using different method. But the files uploaded without "(" ")". So that should be harmonize to further exam. The files renamed (did not finnished yet) in a compliance with COM:RENAME guidelines option 4: "To harmonize the names of a set of images so that only one part of all names differs." and the edit summery says: "4. harmonize the names of a set of images". -- Geagea (talk) 19:20, 24 January 2022 (UTC)[reply]
it also says: "Just because images share a category does not mean that they are part of a set. There are two scenarios that this criterion is designed for. First, certain complex templates (such as those that use BSicons or that display football kits) assume that the images used in them will follow a specific naming convention. Wikisource also uses a specific naming convention for the source files they transcribe. Second, files that form parts of a whole (such as scans from the same book or large images that are divided into smaller portions due to Commons’ upload size restriction) should follow the same naming convention so that they appear together, in order, in categories and lists."
which scenario do you think applies? --Isderion (talk) 19:27, 24 January 2022 (UTC)[reply]
It's a part of a set as the set is File:....(997....).jpg. The last part is the set. You may consider them as mu own uploads if you wish. -- Geagea (talk) 19:31, 24 January 2022 (UTC)[reply]
@Geagea: I think these renames are probably justified under criterion 1 (original uploader requested), since even if they were uploaded under a different account they were uploaded on your behalf. However, I don't think they would have been justified under criterion 4. The footnote for criterion 4 only specifies two narrow cases. The first is where an external system (complex templates and Wikisource are mentioned) requires a particular naming scheme. The other is where a single source (such as a large book) has been split into pieces for loading onto Commons. Neither of those obviously applies here. I also notice that your new names don't have ')' characters in them. I do hope you haven't renamed 24,000 files to the wrong names! --bjh21 (talk) 19:33, 24 January 2022 (UTC)[reply]
A. truth, they have only '(' and the ')' will follow.
B. I do think that the last parts of the names are set. Not because the are in the same category but because I named them. I am trying to handle this large uplod after frustration from Pattypan tool. So please be helpfull. If you have another method to do the rename I'll be glad to hear. If yoy think that criterion 1 (original uploader requested) is better, it's fine with me. Matanya, can you comment her. -- Geagea (talk) 19:51, 24 January 2022 (UTC)[reply]
I really don't mind what you name the files, the only reason I am the uploader is pattypan's shortcomings. matanya • talk 20:42, 24 January 2022 (UTC)[reply]
in no way is a rename by adding only brackets (and here only the left brackets) for 20k files justified in any way. such "harmonisation" is a waste of resources.
file mover right would be immediately revoked for such careless and inappropriate use... but this is a sysop... ¯\_(ツ)_/¯ --RZuo (talk) 19:49, 24 January 2022 (UTC)[reply]
That doesn't matter if he is an admin. It's no play-tool. Everybody makes mistakes, but this is not good. - Richardkiwi (talk) (talk) 20:06, 24 January 2022 (UTC)←[reply]
  • My take is this: Just because you're the uploader doesn't mean you get to make nonsensical renames and I point blank refuse any renames that don't make any sort of sense irrespective of who's the uploader. Now all that being said Geagea has since stated "they have only '(' and the ')' will follow." which I'm fine with however I don't understand why they couldn't of added both brackets in the same rename as the names now look ridiculous and nonsensical.
As a way forward IMHO Geage should immediately stop mass renaming for the sake of one bracket and should add both brackets in the same rename (they however may add the other bracket to the names first), If they cannot do that they should be desysopped. (As per this reply the filemover right cannot be revoked from admins). –Davey2010Talk 13:03, 25 January 2022 (UTC)[reply]
if i counted correctly, User:NguoiDungKhongDinhDanh has just done 568 moves to add only "()". RZuo (talk) 21:17, 27 January 2022 (UTC)[reply]
See COM:VPT NguoiDungKhongDinhDanh 06:57, 28 January 2022 (UTC)[reply]

Too many licenses?[edit]

I've found this file (and its derivatives):

  1. I'm not sure about all these licenses – is it correct to pile on 10+ licenses to cover the sources?
  2. Specifically, the {{PD-CzechGov}} template surely doesn't cover data provided by government agecies (it's designated only for the official works such as flags or laws.). Therefore it's inappropriate to use this license for this file. I know very little about copyright/copyleft rules in other countries than Czechia, but there could appear the same problem.

— Draceane talkcontrib. 21:31, 24 January 2022 (UTC)[reply]

With so many sources this could be possible, but not only the Czechia licenses are wrong, the German is too. I did not checked the data itself for all cases but is has to be {{GeoNutzV}}, {{Data license Germany-attribution-2.0}} or {{Data license Germany-Zero-2.0}}. --GPSLeo (talk) 07:59, 28 January 2022 (UTC)[reply]

Desktop Improvements update and Office Hours invitation[edit]

Hello. I wanted to give you an update about the Desktop Improvements project, which the Wikimedia Foundation Web team has been working on for the past few years.

The goals of the project are to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use article tabs and the user menu, and more.

The improvements are already visible by default for readers and editors on 24 wikis, including Wikipedias in French, Portuguese, and Persian.

The changes apply to the Vector skin only. Monobook or Timeless users are not affected.

Features deployed since our last update[edit]

  • User menu - focused on making the navigation more intuitive by visually highlighting the structure of user links and their purpose.
  • Sticky header - focused on allowing access to important functionality (logging in/out, history, talk pages, etc.) without requiring people to scroll to the top of the page.

For a full list of the features the project includes, please visit our project page. We also invite you to our Updates page.

The features deployed already and the table of contents that's currently under development


How to enable the improvements[edit]

Global preferences
  • It is possible to opt-in individually in the appearance tab within the preferences by unchecking the "Use Legacy Vector" box. (It has to be empty.) Also, it is possible to opt-in on all wikis using the global preferences.
  • If you think this would be good as a default for all readers and editors of this wiki, feel free to start a conversation with the community and contact me.
  • On wikis where the changes are visible by default for all, logged-in users can always opt-out to the Legacy Vector. There is an easily accessible link in the sidebar of the new Vector.

Learn more and join our events[edit]

If you would like to follow the progress of our project, you can subscribe to our newsletter.

You can read the pages of the project, check our FAQ, write on the project talk page, and join an online meeting with us (27 January (Thursday), 15:00 UTC).

How to join our online meeting

Thank you!!

On behalf of the Wikimedia Foundation Web team, SGrabarczuk (WMF) (talk) 22:11, 24 January 2022 (UTC)[reply]

Ah. I had been wondering where these awful changes were coming from. I am glad there is an opt out feature. From Hill To Shore (talk) 22:26, 24 January 2022 (UTC)[reply]
Yeah, these changes have made interwiki navigation more difficult, thankfully the English-language Wikipedia doesn't use them now, but when I went to the French-language Wikipedia and Vietnamese-language WIkipedia I couldn't find language links anymore, only a box that they were "moved up" where I oddly found an ugly mobile-looking minimalistic interface. As someone who almost exclusively edits from a mobile device I would like to see the Mobile interface be more like the desktop interface, not vice versa. I already feel bad for the people that will join Wikimedia websites after these changes have been made standard. In the past few years I've seen several calls by people to make the GUI of Wikimedia websites "more minimalistic" because it currently looks "nostalgic", rather than seeing the current GUI as "a relic of the past" it is good to look at it as being more practical and easy to navigate while other websites have been updated to "hide" everything away in order to not clutter the interface for small screen users (PDA's, PDA phones, smartphones, iPhones, Tablets, Etc.), but we already have a separate mobile interface for smaller screens, I know that complaining about it won't actually change it and for me I won't see these changes because I opted out, but I don't see a practical reason why these changes were implemented as I don't see them actually improving "the desktop experience" for people. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:57, 25 January 2022 (UTC)[reply]

January 25[edit]

Doubts with the categorization of pastures and grasslands[edit]

I have been trying to categorize images of agricultural and livestock areas and I am getting confused especially with the categories: pasture, meadow and field. Can someone help me with this?

How would you classify the following photographs?

  • Private fenced farm that is used by grazing with cattle. ¿pasture or meadow?

  • Fenced private farm that is mowed. ¿pasture or meadow?

  • Communal or state-owned land where cattle are usually herded in summer. ¿Mountain pastures, meadow or field?

  • Private arable farms generally cultivated with cereals such as wheat, corn, etc. ¿farmland or Grain fields?

Juenti el toju (talk) 00:25, 25 January 2022 (UTC)[reply]

  • 1. Pasture, not likely to be used for hay production. (short grass) Enclosure is active (with wires) and is used to restrict cattle. Enclosures along public roads are for restricting acces to the public, not necessarily cattle management.
  • 2. Meadow: Clearly used for hay production. (long grass) Can also used for pasture, if cattle are in the picture
  • 3. Pasture. no enclosure and can only be used for seasonal pasture. With cattle it is obvious.
  • 4. Grain fields are a subclass of farmlands. In this picture the crop has been cut. Certainly not a other crops (potato, beet, salat, etc) leaving raw earth.Smiley.toerist (talk) 11:34, 25 January 2022 (UTC)[reply]

Rhine flood 1987?[edit]

Köningswinter flood 1987 6.jpg

I got eigth pictures of a floot on the Rhine. On slide film was developed in januari 1987 (1-4), the other with the same type of subject on march 1987(5-8). (see Category:Rhine floods by year) I tried to find on internet a more precise dat for the flood, but could not find anything for the year 1986 or 1987. There must some German documentation of all the floods on the Rhine.Smiley.toerist (talk) 11:20, 25 January 2022 (UTC)[reply]

It does not appear to have been any major flood in 1987 and the photos indeed do not show any significant flooding. Ruslik (talk) 12:17, 26 January 2022 (UTC)[reply]
Are you totally sure about the dating of the photos? There are reports about a flood (Hochwasser) of the rhine in 1987 in Austria and Switzerland. For 1986 there are documents about a flood in Bonn[2], which is just across the rhine river from Königswinter. --Túrelio (talk) 16:13, 26 January 2022 (UTC)[reply]
The flood in Bonn is to early. The pictures are are taken in the winter (no leaves). It could be december or november 1986, but certainly not earlier. In the dark winter period I dont take many pictures, I could take two months to fill a 36 pictures film but no longer. As the next film is developed in march, the pictures must be at the end of first film. I suspect it is a minor flooding, wich would happen quite often in Köningswinter along the riverfront.Smiley.toerist (talk) 15:21, 29 January 2022 (UTC)[reply]

Cory Doctorow post on "copyleft trolls" mentions Commons[edit]

"A Bug in Early Creative Commons Licenses Has Enabled a New Breed of Superpredator" ([3]):

"Upgrade on Upload: Anytime someone tries to upload a CC image with a pre-4.0 license to a repository like the Internet Archive, Wikimedia Commons, Thingiverse or Github, they should be asked if they are the creator, and, if so, should be prompted to upgrade the license to the current version;

Upgrade in Place: Every repository that hosts CC works that carry pre-4.0 licenses should send an email to every account holder urging them to opt into a process to upgrade them immediately to the latest license.

Warnings: Every repository that hosts CC works that carry pre-4.0 licenses should place a prominent warning on every page that includes these works, explaining that this work uses an outdated and disfavored license and that a failure to correctly attribute it could attract a $150,000 statutory damages awards."

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:13, 25 January 2022 (UTC)[reply]

argument kinda falls apart once you look at the details "So this is beyond copyleft trolling: they’re not threatening someone who made a small attribution error and was technically in violation of their license: rather, they sent repeated threats (I missed the first one) to someone who correctly attributed their client’s image." So yeah the validity of the issue isn't an issue. This is just Pixsy carpet bombing all uses. They don't need to look for license technicalities with that approach (heck they don't even need to own the copyrights if they can frighten enough people). Also I'm not sure I agree with doctorow's interpretation of the 30 day clause "For the avoidance of doubt, this Section 6(b) does not affect any right the Licensor may have to seek remedies for Your violations of this Public License." so you can still sue infringes for infringements up to that point. Even if the lack of warning means you decide its not worth trying to prove wilful infringement that's still a potential $30,000 per infringement. So for example a video with 89K views that nicks one of my images could still be sued for north of $2 billion (except we’re both in the UK so I'd have to settle for actual damages which is unlikely to be more than a couple of £100).
Really this boils down to the social question of how much enforcement is allowable. If its none then the license is essentially public domain. Even if we require warnings before asking for money the license is still functionally PD since re-users know most people won't bother. So if we want the license (and its virality) to mean anything we're kinda reliant on the psychopaths in the grass to give it teeth.Geni (talk) 17:23, 25 January 2022 (UTC)[reply]
That last part seems overly pessimistic to me. Creative Commons worked out and published some enforcement principles recently, which seem relevant here; I’ll quote the brief version:
  • The primary goal of license enforcement should be getting reusers to comply with the license.
  • Legal action should be taken sparingly.
  • Enforcement may involve monetary compensation, but should not be a business model.
And this part applies more specifically to Wikimedia Commons:

If you are a platform that accepts uploads of CC-licensed works by third parties, you can require uploaders to agree that they will enforce copyrights of their works in line with these principles, and you are encouraged to require 4.0 licenses for uploaded works.

So I don’t think rel[ying] on the psychopaths in the grass is a mindset we should adopt. Lucas Werkmeister (talk) 21:17, 27 January 2022 (UTC)[reply]
Cory mentions in his article Flickr-user Nenad Stojkovic, who seems obviously to be a customer/client of the despicable Copyleft trolls of Pixsy. Shouldn't we consider to ban all his images from Commons, as we have done and do with Marco Verch's images, in order not to expose re-users? --Túrelio (talk) 13:55, 26 January 2022 (UTC)[reply]
That seems appropriate. There's Photographs by Nenad Stojkovic and these search results. Thankfully there doesn't seem to be that many articles and such that would be impacted. — Huntster (t @ c) 15:35, 26 January 2022 (UTC)[reply]
Some thoughts
All files on Commons should contain license metadata. It will not help if an image is printed, but if the file is used on a website, then the file's metadata may satisfy the license requirements.
All files on Commons that impose license conditions beyond an accepted published license should be deleted. For example, some contributors us a CC-BY license but add that their name must be placed on the same page as the image. A CC-BY license lets the user choose a reasonable method of attribution.
Glrx (talk) 18:53, 27 January 2022 (UTC)[reply]
@Glrx, wrt your 1st statement: no, I don't think so, as the reader has no direct access to the metadata. Apart from the fact that many re-users strip metadata from images when they edit or downsize them.
Wrt your 2nd statement: that's an old issue. AFAIK it's consense on Commons that the licensor can ask for a placement of the credit near the image, but cannot demand/require it. The same for asking for a specimen/sample copy of print-products.
But all these subtleties are not the issue of the problem/case described in this thread. While it should go without saying that contributors to Commons can take legal action against infringers on a case-by-case basis to ensure their copyright is respected, the case presented in Cory's article is a systematic approach to intentionally financially exploit re-users. Commons/Wikipedia is misused by such people as a distribution platform for their activity. This should not be allowed, IMO. --Túrelio (talk) 20:20, 27 January 2022 (UTC)[reply]
@Túrelio:
If the file has metadata, then that metadata may offer protection against copyleft trolls because the attribution exists. If a user strips the metadata, then that user loses the possible protection. In general, stripping metadata is a bad idea.
If the user demands or requires the attribution (or any additional condition), then the file should be deleted. I know the difference between a request and a demand. Requirements beyond a standard license offer additional trip points for trolls.
Adding metadata is offered as a defense for those who might be caught in the troll's net, so it is on point. Glrx (talk) 20:58, 27 January 2022 (UTC)[reply]
Adding the metadata where none has been provided might be beneficial, but it has a lot of problems, including the risk of invisible metadata staying the same when visible metadata is corrected. Unless we enforce metadata that on its own satisfy the licence's requirements, then it does not protect reusers from copyleft trolls like those described in the column. It does provide some protection for/against careless users.
I think requiring attribution is fair, and there are cases where the form of attribution, such as including an institution, might be important. Requiring a byline is incompatible with the CC licences, as is any other requirement not explicitly allowed by the licence. This is a standard feature of free licences (otherwise somebody could add e.g. a requirement to pay $5,000 for each view).
–LPfi (talk) 09:57, 28 January 2022 (UTC)[reply]
What exactly do people mean by "metadata" here? "Metadata" can be anything other than the image itself. (A date is metadata. Arguably, even a meaningful filename is metadata.) It looks to me like people have something much more specific in mind, but have not said what. Are we talking about something embedded (e.g. via EXIF) or are we talking about something else? And exactly what data are we talking about? - Jmabel ! talk 15:43, 28 January 2022 (UTC)[reply]
I think the wording by Glrx clearly implies that they mean metadata included in the file itself, such as Exif. We do include much metadata on the file description page, so that would be nothing new, and if the filename were meant, it would have been mentioned explicitly. –LPfi (talk) 17:38, 28 January 2022 (UTC)[reply]
So this would involve a somewhat different solution for each file format? And what exactly would be the metadata in question, a correct copyright & license notice? - Jmabel ! talk 18:08, 28 January 2022 (UTC)[reply]
I suppose so, but the details would be complicated. In my understanding the Exif fields are not well-defined, at least not defined to be using any sensible character coding (I think they are assumed to be ASCII). And I think it is easy to argue that Exif is not a reasonable to the medium way to provide attribution at, say, a web page. Converting the file to a format without such metadata would lose it, without the reuser noticing. If trying to add the information to fields already present, it is easy to screw everything up. –LPfi (talk) 18:42, 28 January 2022 (UTC)[reply]
Yes, I mean metadata that is embedded in the file. If the file is just copied, the metadata will travel with it. Sadly, there are many different metadata formats, and even within a particular metadata vocabulary, there is often ambiguity about how to use the vocabulary. Consequently, applications that manipulate files with metadata may discard some or all of the metadata. Creative Commons' licenses have simple requirements. CC developed the Creative Commons Rights Expression Language (ccREL). Commons files could contain several ccREL statements. In particular, there could be a cc:attributionURL pointing to the Commons file description page which should have additional required information such as modifications to the original. Yes, it is easy to screw up, and many files on Commons have screwed up attribution. Glrx (talk) 19:34, 28 January 2022 (UTC)[reply]

January 26[edit]

Author[edit]

Is the author field always meant to contain the name of a human (except that case where the monkey took a photo) or can it contain the name of a photo studio? if the image is attributed to a studio rather than a person, should that be in the Source field? I have seen both, but I remember seeing in a discussion that it was only meant for the name of a human, so that a death date can be ascertained. --RAN (talk) 03:07, 26 January 2022 (UTC)[reply]

The author field can be used to attribute a work to something other than a specific person. The {{Creator}} template supports "workshop of", "circle of", "school of", "studio of", etc. In fact, the legal author of a work is not always a human, some jurisdictions support "work for hire" or corporate authorship. Under US copyright law when a work is made as a work for hire the author is not the individual who actually created the work, instead the entity that hired the individual is considered the author, and thus a corporation can be the legal author (see U.S. Copyright Office Circular 30). So, at least in the US, it is possible for a photo studio to be the legal author of the photos made by their employees. The chart at Commons:Hirtle chart shows how corporate authorship can affect copyright duration in the US. Some jurisdictions, particularly civil law jurisdictions such as France, have nothing like work for hire or corporate authorship, although under French law a corporation can be considered the author of a collective work if the corporation directs the creation of a collective work where the personal contribution of multiple authors is merged into the overall work and it is not possible to separate the work into pieces that can be individually attributed to the contributors. —RP88 (talk) 06:04, 26 January 2022 (UTC)[reply]
  • Thanks, cogently answered! --RAN (talk) 06:27, 26 January 2022 (UTC)[reply]

Non-sourced "classification" of non-living but present-day people and providing sources[edit]

Hello! Recently a debate has been brought to my attention: an editor have put a person (and images about him) into the "Gay people" category, and when another editor removed that and asked for a source the original editor rejected the request and a reverting war was started. (It was not a one-shot vandalism, more of an editor with an unreliable source and strong intent.) Apart from the lack of civilised behaviour the question was raised whether there is some policy or guideline about sourcing such "statements" about people on Commons? Since they're deceased the WMF Biography of Living Persons policy doesn't apply but in Wikipedias it's generally a base guideline that disputed facts shall be accompanied by reliable sources. Is there a Commons related policy around? I have failed to find one. Thanks! --grin ✎ 08:54, 26 January 2022 (UTC)[reply]

There is no such a category on Commons as "Gay people". Ruslik (talk) 12:13, 26 January 2022 (UTC)[reply]
Oh please! Notice the topic and skip commenting on my wording. There are a lot of categories of lgbt, jew, criminal, whatever categories, and I am confident that most people get the point of the question instead of trying to concentrate on a specific topic of (critique thereof). (Also if I wanted to link anything specific I would have done just that, but it is a general question, not a specific one.) grin ✎ 13:12, 26 January 2022 (UTC)[reply]
I think that when a fact is disputed, you add {{Fact disputed}} to the description page and start a discussion on the talk page. With "facts" that may be defamatory, I'd remove them and start the discussion. I think any disputed statements should be removed or stated to be disputed (unless there is convincing evidence – this is not a free card for trolls). You shouldn't put people in disputed categories, while a "people claimed to be" category or similar can be appropriate in certain cases. I don't think we have a guideline, so this is just common sense. –LPfi (talk) 10:55, 27 January 2022 (UTC)[reply]
So evidence to convince other editors should be on the talk page, However, if reusers are likely to mistrust the description, a link to the talk page, directly to the evidence or some other suitable page should probably be used ("see [[target|short description of link target]]"). –LPfi (talk) 11:02, 27 January 2022 (UTC)[reply]

"Disposable" files[edit]

i was checking Category:Media needing categories as of 6 June 2021 and found these files

Extended content

they are "used" on some frwv pages in the user namespace. i skimmed thru the pages. they seem to be some kind of assignments for a class in a master programme at a paris uni.

my conclusion is that the files were used for that one purpose only, like Category:Disposable goods. and frwv is being used like a free online postit host.

the problem left behind for Commons is, how to categorise these PNG files (if they should not be deleted)?

pinging@Solstag.--RZuo (talk) 08:56, 26 January 2022 (UTC)[reply]

I would categorise such files in Category:Wikiversity images, almost all files in it are included on frwv user pages.
In my opinion the files listet are within the scope since they are probably subpages of fr:v:Modélisation_des_Réseaux_(M1_SIREN,_2021) ---> fr:v:Modélisation_des_Réseaux_(M1_SIREN,_2021)/Activité_B.
There are links to about 25 user pages below (section Activités ), all of which also contain images for the project. GeorgHH • talk   14:54, 26 January 2022 (UTC)[reply]

Assistance would be useful.[edit]

I'd like to swap out any usage of User:Adam Cuerden in the author field of {{Information}} for Creator:Adam Cuerden, specifically because the Creator template allows me to handle some things related to British grants of copyright a bit more elegantly (You'll note I included a statement in it making the release, insofar as necessary, explicit. Anyone up for some botwork? It shouldn't cause any problems other than minor visual display ones in rare cases. Alternatively, I could try to update probably 1,000 files by hand, but I really don't want to. {{Artwork}} is much more finicky, so it's probably best to output that as a list instead for hand revision. Adam Cuerden (talk) 10:17, 26 January 2022 (UTC)[reply]

@Adam Cuerden: ✓ Done.   — Jeff G. ツ please ping or talk to me 20:04, 26 January 2022 (UTC)[reply]

Redesigning the file page ?[edit]

Anyone else feel like the file page needs a major redo ? Things I'd like to see:

  1. Horizontally center the image
  2. max-height and max-width the image to fit within the viewport and resize it based on browser viewport size
  3. Add some visual bordering of the image area. Possibly just dark gray ? Might be too strong.
  4. Remove the old Stockphoto Gadget (which I helped develop once)
  5. Add a new 'file toolbar' directly under each image (but above 'Original file'-line).
  6. Add 'share', 'download'/other resolutions and 'use' buttons into this toolbar, to replace stock photo gadget and make it part of core
  7. Move things like media viewer, 'rotate', panoramaviewer and other gadgets into this 'file toolbar'.
  8. Move file history into another tab, next to file information/structured data
  9. Move file usage into another tab, next to file information/structured data
  10. After all that is done, there is also a lot of work to be done around the file information and file license templates and logic, but that is far more complicated I think.

What are your thoughts on the file page design ? What would you like to see ? I'm just trying to gauge what ppl think, and if it is worth my time to mock up some things using a gadget. —TheDJ (talk • contribs) 12:58, 26 January 2022 (UTC)[reply]

  • @TheDJ: What is the goal here?
  • Also, when you say "File history" do you just mean the upload history? What is the advantage of "hiding" that behind a tab, rather than it always being easy to see just by scrolling? (Similarly for usage.) - Jmabel ! talk 16:40, 26 January 2022 (UTC)[reply]
I agree with Jmabel here. While some of these suggestions have definite merit, I don't see the point of hiding elements behind tabs. Are you worried about page length for some reason? Also, I would suggest the max-height/-width thing be optional, as some folks may still wish to limit bandwidth usage. The hardware folks may also take umbrage with the idea, since it would (I imagine) mean each image would have to be re-rendered server-side to the desired resolution often with each view request. — Huntster (t @ c) 17:15, 26 January 2022 (UTC)[reply]
goals:
  1. More focus on the image, in more skins and on more devices.
  2. Get rid of stockphoto, which just screams 2009 and hasn't been maintained in years
  3. Cleanup the area directly under the image, which is cluttered with all kinds of tools/gadgets and give each of them a proper home in a visually consistent way.
  4. Move things that no one but editors use out of sight for normal users. On a side note, the file/upload history is also problematic for google. Google images often features thumbnails from the history instead of the primary image in their image results. I haven't really figured out why. Anyway, virtually no one but editors/curators need this/cares about this.
  5. Overall, I want something that feels like it is about the image and what to do with it, instead of being a data dump ground. MediaWiki being a terrible image repository/host is one of the most frequent complaints I hear from non-Wikimedians. You only have to look once at a flick page to realize it could be so much better (no matter how much they f'ed up their business model)
@Huntster
  1. "hiding elements behind tabs" well, maybe it won't be for some users, maybe there'll be a toggle, maybe its based on usergroups or maybe I'll just collapse some of it. No idea exactly, other than that 99% of visitors shouldn't be confused with this extra 'internal' information.
  2. "as some folks may still wish to limit bandwidth usage" It has nothing to do with bandwith. It will be the same image there is now, it will just resize/become smaller where required.
  3. "each image would have to be re-rendered server-side to the desired resolution often with each view request" No, that isn't the plan.
Anyway, they are some ideas, and I think that after 14 years of standing still it is time we make some improvements, I feel more pain for having ever helped to have make StockPhoto gadget a reality every single day. And some of these things would be rather simple to implement if we put our minds to it (and i can bring it serverside eventually). —TheDJ (talk • contribs) 19:56, 26 January 2022 (UTC)[reply]
Could you make concept images of these ideas? I am not so sure if we should make the default interface more "consumer oriented" rather than "producer oriented" (not sure how else to differentiate between editors and non-editors), I have thought that the general layout of file pages can use improvements for years, but I like the idea of adding a "toolbar" and in general #6 seems like a good improvement. In fact, something like Microsoft's Ribbon interface might be wise to emulate. Though I'm not a fan of making the images bigger, though I could change my mind on it if the changes don't really break the editing interface for mobile users and the other options actually make it more "user-friendly". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:47, 26 January 2022 (UTC)[reply]
"Could you make concept images of these ideas?" I'm not good with photoshop, that's why i wanna make a gadget. But that is gonna take some time, so before i sink my precious time into this, a round of input. —TheDJ (talk • contribs) 00:10, 27 January 2022 (UTC)[reply]
TheDJ, 1) Perhaps there is a better way of sectioning off the data, but I still advocate leaving everything on the same page. 2 and 3) Unless you're suggesting loading the whole image each time the page is viewed, and then dynamically resizing that, then all the resizing is done server side. Doing that for a majority of page requests will add a significant load to our servers. No, it's not determined *how* large of a load, but I have to imagine it would be other than insignificant. All that said, I completely agree with the idea of revamping how tools, sharing, etc are displayed in a file toolbar. — Huntster (t @ c) 21:09, 26 January 2022 (UTC)[reply]
"then all the resizing is done server side." This is not true. we 'preselect' specific sizes serverside. That doesn't mean it is the only way images ever get sized. I think my 15 years of being a MediaWiki developer give me slightly better insight as to how all of this works. —TheDJ (talk • contribs) 23:57, 26 January 2022 (UTC)[reply]
It is very good and healthy to periodically bring this up. One thing I recommend is to consider possibly making the difference between uploader and author more apparent. I have uploaded many thousands of images, but am the author of almost none (save for a few restorations or derivative collages). Yet I've seen my user name "credited" outside of Wikimedia for public domain images I've merely uploaded. While this may speak more to the comprehension of reusers than the user-friendliness of Commons, anything that can improve the user end searching, displaying, and reusing process should be considered. On a related note: are there studies, surveys or reports that show how people actually use Commons? I mean besides the gnomes like me and others who volunteer our time to curating and improving the content. I'd hate to think it's a total waste of time, and third party feedback and metrics would allow better allocation of resources. --Animalparty (talk) 23:39, 26 January 2022 (UTC)[reply]
"the difference between uploader and author more apparent" Unfortunately this is very difficult as this distinction is not that well made by the pages themselves. However it is one of the reasons why I think filehistory (or worse, copy pasted import history) is problematic/unclear to most users. —TheDJ (talk • contribs) 00:19, 27 January 2022 (UTC)[reply]
And very badly done in the Upload Wizard, which asks who created the file, and says nothing about the work. Then we call people copyviolators, because they "claimed own work" for files they uploaded. I think that should be the place to start making the distinction between author of the original work, author of the derived work (or photo, regardless on whether it is a derived work legally), and the uploader. There may be several layers, so we should be careful with our wording. The information template doesn't make it easy to add this information (you need separate templates such as {{Photo}}, and you need to know how to find them), so some adding of fields or linking good documentation might be needed. –LPfi (talk) 11:11, 27 January 2022 (UTC)[reply]
I think that is a separate problem. Animalparty seems to know what they are doing and the file descriptions they create are correct. Its other ppl that are interpreting them incorrectly. —TheDJ (talk • contribs) 12:35, 27 January 2022 (UTC)[reply]
  • In the upload form "Date" could also be better described. For historic photos, new uploaders are confused as to whether you are asking for the date the photo was taken (1930), or the date the photo was scanned (the date in the metadata, 2012, that gets autoloaded), or the date it was uploaded to Commons (2022). I constantly see images nominated for deletion because the nominator is expecting the earliest date, but sees the current date. I also see a lot of nominations for Source=own_work, when someone takes a photo or scan of an artwork, and the nominator is expecting the source to be the name of the museum, not the creator of the uploaded photo, which is now a derivative work. All the previous examples are correct, just not the one expected by the nominator. We should be clearer which one is expected right in the form. --RAN (talk) 00:06, 29 January 2022 (UTC)[reply]
    • It is indeed a problem. It is a compulsory field and the user is supposed to click the date on a calender that shows the current month. That interface makes you assume a recent date is requested. Clicking the field to start writing something else (such as "before 1850") does not work, adding to the assumption you are supposed to use the calendar. {{Other date}} is not linked anywhere, and its documentation not that easy to grasp, not even is there any advice on the ISO 8601 form – a date of 10/11/12 is little use. –LPfi (talk) 20:30, 29 January 2022 (UTC)[reply]
  • For SVG files that display the "Render this image in [language dropdown]" (e.g., File:Map of Septimania in 537 AD.svg), state it may be possible to add translations with the SVG Translate tool and add a link to the application with the file queued up (e.g., translate file). Glrx (talk) 16:41, 29 January 2022 (UTC)[reply]

January 27[edit]

HotCat bugs[edit]

Hi, I'd like to report two bugs I often encounter when using HotCat:

three-step demonstration of the HotCat-bug
  • Second, there is an annoying tendency to change and then drop user-input categories, seemingly at random. Upon confirming the new HotCategorized categories with the "Save" button, it may happen that one of the new categories gets exchanged for another new category; which then leads subsequently to dropping the one that gets changed in the Edit dialog. This may or may not have something to do with the editing line still open (it gets closed automatically when you use the Save button). This bug has plagued me for months, but I couldn't reproduce it until today, in the case of the attached screenshot-series. Sorry that I cannot provide any technical insight into the problem. --Enyavar (talk) 14:18, 27 January 2022 (UTC)[reply]

January 28[edit]

Qusta ibn Luqa[edit]

Can someone help me over at File talk:Qusta ibn Luqa.jpg? That picture which is used in quite a few community wikis is very misleading. Thank you Xn00bit (talk) 23:52, 28 January 2022 (UTC)[reply]

See Template:Fact disputed. --Animalparty (talk) 05:03, 29 January 2022 (UTC)[reply]
Agree. I renamed it into File:Galenus (cropped).jpg, recategorized the image and removed it from the wikidata item. It disappeared due to that from several languages. Can you correct the remaining ones Xn00bit? Ellywa (talk) 06:55, 29 January 2022 (UTC)[reply]
@Ellywa Thank you! I'm sorry, I don't understand what you're requesting. The remaining ones of what, exactly? Xn00bit (talk) 11:51, 29 January 2022 (UTC)[reply]
I meant to say, the use of the image on Wikipedia articles in various languages. You can find these when you scroll to the bottom of the file page. This has been completely solved now. No action needed imho. Regards, Ellywa (talk) 12:13, 29 January 2022 (UTC)[reply]

January 29[edit]

Wich German station in 1979?[edit]

Germany rail 1979.jpg

It must be one of my earlist interrail trip where I reached Istanbul.Smiley.toerist (talk) 15:25, 29 January 2022 (UTC)[reply]

January 30[edit]

Template for expired UK published editions[edit]

I've been using {{PD-because}} with File:Flag of the United Kingdom.svg and the copyright link to present a published edition as public domain in the UK after 25 years of first publication and ineligible for copyright in the US. Perhaps that kind of a template similar to either {{PD-UKGov}} or {{PD-UK-unknown}} is long overdue. Any volunteers? --George Ho (talk) 03:03, 30 January 2022 (UTC)[reply]

Source[edit]

When someone scans with a scanner, or takes a photo with their iPhone of an object, isn't the object itself the "source", or am I wrong? I have been seeing deletion nominations based on the premise that you can't name the object itself as the source. I think people are tagging uploads because they are expecting to see a website listed, or a museum collection listed, not the object itself. See for example: File:Gobierno Civil. Plaza Temple.jpg --RAN (talk) 05:39, 30 January 2022 (UTC)[reply]

You do not need a documentary or URI source, no. A perfectly valid source is, "I photographed it". —Justin (koavf)❤T☮C☺M☯ 07:18, 30 January 2022 (UTC)[reply]
@Koavf: "I photographed it" or "I scanned it" is only suitable for the electronic image that is uploaded here. It does not address the copyright status of what appears in the image. If the object that appears in the image could be subject to copyright, the photographer/scanner has created a derivative work. We need to understand the background/source of the object to confirm that the photograph or scan has not been made in breach of copyright. If there is some other reason why the object does not retain copyright (such as through Commons:Freedom of Panorama) then that needs to be explained on the file page. From Hill To Shore (talk) 14:54, 30 January 2022 (UTC)[reply]
@Richard Arthur Norton (1958- ): This appears to be a photoshopped scanned postcard of a line drawing of a building drawn in Valencia, Spain circa 1920 to 1940. Without information about the lifetime of each copyright holder and the date and country of the architectural drawings and each image's first publication, how can we possibly determine whether or not the resulting image is PD?   — Jeff G. ツ please ping or talk to me 13:02, 30 January 2022 (UTC)[reply]

License of screenshots[edit]

Hello! If I created screenshot of free software on Android, I must use license of software? Can I choose license that doesn't match with license of software? I can't use free license for it because I did it in Android? — Preceding unsigned comment added by DustDFG (talk • contribs)

@DustDFG: , have you seen Commons:Screenshots and Commons:Derivative works yet? —Justin (koavf)❤T☮C☺M☯ 10:03, 30 January 2022 (UTC)[reply]
@DustDFG: Hi, and welcome. See also COM:SIGN.   — Jeff G. ツ please ping or talk to me 12:50, 30 January 2022 (UTC)[reply]

Re-coloured photographs[edit]

I found this photograph on Meta's Facebook which is derivative of a public domain photograph. As far as I can tell colouring in black and white photographs constitute new copyright, am I correct in thinking this? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:50, 30 January 2022 (UTC)[reply]

@Donald Trung: That depends on the TOO where the coloring was done.   — Jeff G. ツ please ping or talk to me 12:48, 30 January 2022 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=625928946"