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/2023/05.

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

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Wrong deletion 40 14 Jmabel 2023-05-31 18:36
2 Should we adopt the proposed Child Protection policy? 23 9 Red-tailed hawk 2023-06-03 14:44
3 Berlin transit icons 5 2 Minoa 2023-05-29 06:56
4 FileExporter problem? 3 1 JWilz12345 2023-05-29 07:12
5 AI and the decision not to participate 8 4 THSlone 2023-06-04 19:19
6 License reviews 15 6 RZuo 2023-06-04 18:49
7 Legality of Indian maps 4 3 Jmabel 2023-06-02 15:10
8 Map from Le monde diplomatique 3 2 Semsûrî 2023-06-02 07:37
9 Category:Photographs by Alisdare Hickson 6 3 Jmabel 2023-05-29 23:10
10 How to handle sources that are dead links 7 4 LPfi 2023-06-02 07:34
11 Notification of DMCA takedown demand — Java logo 1 1 JSutherland (WMF) 2023-05-30 23:21
12 Pixabay photo dates 2 2 Jmabel 2023-05-31 17:53
13 Template help needed 4 3 Jarekt 2023-06-01 02:58
14 AI generated media competition 12 5 Jmabel 2023-06-02 18:20
15 Commons Gazette 2023-06 4 4 Multichill 2023-06-01 18:51
16 Notification of DMCA takedown demand — Kempes en Valencia 1 1 JSutherland (WMF) 2023-06-01 17:34
17 Flickr Foundation adopts Flickr2Commons 26 16 C.Suthorn 2023-06-04 07:39
18 SyntaxError: invalid assignment left-hand side 2 2 Ruslik0 2023-06-01 19:54
19 Big gap for structured_data 6 4 Nurg 2023-06-04 23:02
20 Photographing glass 2 2 Jmabel 2023-06-02 21:31
21 Photo challenge April results 1 1 Jarekt 2023-06-02 19:26
22 Category:Surnames (flat list) 7 4 Jmabel 2023-06-03 15:01
23 Can anyone detect a studio name? 2 2 Abzeronow 2023-06-03 20:37
24 File:IMG-20230603-WA0005.jpg 1 1 CX Zoom 2023-06-03 08:30
25 Issue about Template:Lle 3 3 Multichill 2023-06-03 18:08
26 Let uploaders see what metadata is present as they're uploading 3 3 LPfi 2023-06-04 16:55
27 Campaign editing help 1 1 Klein Muçi 2023-06-04 08:47
28 Johnrogershousemay2020.webp 2 2 Jmabel 2023-06-04 15:03
29 Continuation of Commons:Village pump/Archive/2023/05#About Category:Uses of Wikidata Infobox with no image 3 2 JopkeB 2023-06-05 04:53
30 Công ty TNHH Điện Lạnh CNC Hà Nội 0 0
31 Văn hóa công ty 0 0
32 Sứ mệnh và tầm nhìn 0 0
33 Hồ sơ năng lực 0 0
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
Village pump and gaslight at a meeting place in the village of Amstetten, Germany. [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.

May 11[edit]

Wrong deletion[edit]

Today, User:Jameslwoodward deleted Data:Ncei.noaa.gov/weather/Montpelier.tab and Data:Ncei.noaa.gov/weather/Juneau.tab without any valid reason and without any notice. Both sites are U.S. weather stations, both state capitals, and are corroborated by at least two sources. All data are owned by NOAA and are in the public domain. --Fumikas Sagisavas (talk) 06:31, 11 May 2023 (UTC)Reply[reply]

This appears to be related to Commons:Deletion requests/Files found with Data:Ncei.noaa.gov/weather. MKFI (talk) 06:34, 11 May 2023 (UTC)Reply[reply]
@Fumikas Sagisavas: The DR refers to COM:SCOPE. Could you please elaborate how these data tables fit into the scope of this project? I think the problem might be that since the data namespace was launched in 2016 we apparently hadn't much discussion about this. As we are a media archive, something like Data:NewYork.map is surely within scope but I fail to see why we should keep tables with weather data. Thinks like that are probably better hosted at Wikidata. --AFBorchert (talk) 07:11, 11 May 2023 (UTC)Reply[reply]
Because these data will be directly used as data charts on Wikipedia, but due to technical reasons, it is currently only possible to upload weather data data on shared resources and not on Wikidata. Fumikas Sagisavas (talk) 07:22, 11 May 2023 (UTC)Reply[reply]
If it is at Commons, it has to fit into COM:SCOPE. Technical reasons like other projects do not support that yet are not sufficient to place something at Commons. --AFBorchert (talk) 07:44, 11 May 2023 (UTC)Reply[reply]
Actually technical reasons might be enough, see COM:INUSE: "It should be stressed that Commons does not overrule other projects about what is in scope. If an image is in use on another project (aside from use on talk pages or user pages), that is enough for it to be within scope." In any case if these files are used and they can't be reasonably hosted in other projects I believe we could adjust COM:Scope to allow them. MKFI (talk) 08:14, 11 May 2023 (UTC)Reply[reply]
I agree. If there is a big class of such files we should probably have a more thorough discussion, but rather seeking a solution than just keeping them off Commons. Until that, I don't think we should delete them on scope grounds. –LPfi (talk) 08:38, 11 May 2023 (UTC)Reply[reply]
As far as I can tell, the data sets in question are very much in line with how the Data: namespace was intended to be used.
The whole Data: namespace was basically introduced through the backdoor before it was ready to be integrated with the rest of Commons. We still don't have any good way to organize it (no categories, no SCD), is does not seem to exist in the documentation and we never properly discussed how it fits in with existing policies (or if we did, the results of those discussions did not trickle down to the actual policy pages).
So +1 to having a thorough discussion. To Do:
  1. Re-visit the old discussions, and refresh our collective memory on plans, intentions and predicted problems
  2. Do some research on how the namespace is actually being used today
  3. Discuss what's good and bad about this
  4. Figure out how that does or does not work with existing policies and adjust policies if necessary
  5. Delete what is not covered by the new policies.
Bonus: Poke developers until they finish what they started.
Do we have something like a Commons:WikiProject data namepace where we could make a plan? El Grafo (talk) 12:08, 11 May 2023 (UTC)Reply[reply]
Note that d:Wikidata:WikiProject Tabular data exists in the Wikidata community space, for discussions re using the Commons tabular data for data not well suited to Wikidata (ie most tabular data). Any ongoing discussions here should probably give that group a courtesy ping. Jheald (talk) 19:11, 23 May 2023 (UTC)Reply[reply]
  • Pictogram voting comment (orange).svg Comment I don't necessarily have an issue with files containing tabular data being hosted on Commons myself. What I don't like is that .tab files are editable, at least from what I've seen aren't sourced to the original file or website where the information came from, and contain no summary information. Which IMO goes against the guidelines. Also, at least in the case of weather data, the information is added to Wikipedia articles manually anyway. So I don't really see what the difference is between someone entering the data into the Wikipedia article from the original source themselves and it being uploaded here first and then transferred to Wikipedia. Except entering the data here first turns Commons into a buffer zone where the information can't and/or isn't going to be sourced, summarized, corrected, Etc. Etc. There's no reason this information can't just be added to whatever Wikipedia article it's going to be used in and they can deal with the sourcing issues, verify that it's correct, fix the information if it isn't, Etc. Etc. on their end. I don't think that's our job or within the projects scope though. That said, if .tab files couldn't be edited and contained summaries/sources, cool. I don't think they should be hosted on Commons until then though. --Adamant1 (talk) 14:55, 11 May 2023 (UTC)Reply[reply]
  • @Adamant1: this is a wiki, everything is editable. Making content uneditable is simply against the entire purpose of the project. Just because we don't provide ready-made tools to modify images does not mean that they are immutable. Sourcing for files is needed for copyright reasons but we don't require citations to verify map accuracy. Data files do have both summary descriptions and source parameter - if the editor did not fill them then that may be a reason for deletion. MKFI (talk) 10:39, 12 May 2023 (UTC)Reply[reply]
@MKFI: There's clearly a difference between someone editing an image using desktop software or the crop tool and uploading a new version of it versus having an "article" that information can be added to in real-time. One still treats Commons like a media repository, and the just recreates Wikipedia with a .tab or whatever at the end of the URL. You can argue about semantic, but editable "page" of tabular data is simply using Commons like Wikipedia. Otherwise there's zero point in having the distinction. As to the rest of what you said, I said the .tab files should have sources. Not that each individual data point in the file needs to citated to something. I'm sure you get the difference. As to if the tab files are sourced or not, they haven't been from what I've seen and at least with the .tab files uploaded by Fumikas Sagisavas there was pushback when I asked for them. Either that, or the files were sourced to a page that didn't contain the file. I have yet to see a .tab file that's sourced to the actual URL where the file came from, probably because the information is added to the file manually from different pages, which again is why they are just glorified Wikipedia articles. --Adamant1 (talk) 17:21, 12 May 2023 (UTC)Reply[reply]
@Adamant1: The fact that with Commons you need to use a desktop image editing software is a technical limitation, a flaw we should try correct. It is certainly not the model to aspire for. Trying to make Commons more like Wikipedia is very much desirable. Commons is simply a common storage place to support the different Wikipedias; it does not mean that we should be different from them except when needed for a file-centric project. MKFI (talk) 18:57, 12 May 2023 (UTC)Reply[reply]
  • Re: "Commons is simply a common storage place to support the different Wikipedias," I disagree vehemently, and if that were to become a limitation on our scope I would immediately resign from the project. - Jmabel ! talk 20:07, 12 May 2023 (UTC)Reply[reply]
  • Not only that, but User:MKFI, have you heard of Wikivoyage, Wikiversity, Wiktionary, etc.? Inform yourself. -- Ikan Kekek (talk) 19:47, 15 May 2023 (UTC)Reply[reply]
  • I used "Wikipedia" here to refer to all Wikimedia projects and intended it as a reason to expand our scope, not limit it. While all projects are independent, our decisions affect others more than most but I feel we are sometimes too insular. MKFI (talk) 19:51, 15 May 2023 (UTC)Reply[reply]
  • Use "Wikimedia" if you want people to understand you. But in fact, Commons:Project scope is broader than that: "Wikimedia Commons is a media file repository making available public domain and freely-licensed educational media content (images, sound and video clips) to all. It acts as a common repository for all Wikimedia projects, but the content can be used by anyone, anywhere, for any purpose." And making Commons more like Wikipedia could be problematic in several ways, notably including scope but also fair use (unless Commons changes its policy on that, which I doubt we'll see). In which ways do you want to make it more like Wikipedia? -- Ikan Kekek (talk) 20:00, 15 May 2023 (UTC)Reply[reply]

@Jameslwoodward: Why have these contested unilateral deletions not yet been undone? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:45, 22 May 2023 (UTC)Reply[reply]

The consensus at Undeletion Requests was that data tables are out of scope, so they were not restored. .     Jim . . . (Jameslwoodward) (talk to me) 20:03, 22 May 2023 (UTC)Reply[reply]
@Jameslwoodward: are you sure that's an informed consensus? What, then, is :Data space for? - Jmabel ! talk 00:10, 23 May 2023 (UTC)Reply[reply]
Further: Commons:Undeletion_requests/Archive/2023-05#Data:Ncei.noaa.gov/weather/Montpelier.tab that "consensus" appears to consist of one person. So Pinging @Yann, if this is out of scope, what, then, is :Data space for? - Jmabel ! talk 00:14, 23 May 2023 (UTC)Reply[reply]
IMO, there are 2 issues with these pages, as mentioned earlier: there is no source for these tables, and we can't check if they are faithful or not. Then they could easily be implemented in the respective Wikipedia where they should be check for accuracy and suitability. Last but not least, no one except Jim gave an opinion on UDR. Yann (talk) 08:14, 23 May 2023 (UTC)Reply[reply]
I also note that I have been on Wiki for a long time and have several hundred thousand actions as an Admin and I have never seen anything in the Data: space before this. I'd like to draw your attention to Commons:File_types#Data_files which makes it clear that we do not support the Data file type. Perhaps we should, but that's not a question we can answer here. .     Jim . . . (Jameslwoodward) (talk to me) 13:46, 23 May 2023 (UTC)Reply[reply]
Your lack of awareness is no ground for deletion. There is nothing on that page to support your assertion "we do not support the Data file type"; on the contrary, it says that "data in JSON format in the dedicated Data: namespace" is supported. What is not supported are database file types (emphasis mine). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 23 May 2023 (UTC)Reply[reply]
@Jameslwoodward: Link, please. I note also that the disputed flies are the subject of an open deletion discussion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:03, 23 May 2023 (UTC)Reply[reply]

The discussion is open because I did not have the endurance to delete the files, one at a time since our other mechanisms do not work for data files. While my lack of awareness is certainly not grounds for deletion, it is strongly indicative that this file type very unusual. .     Jim . . . (Jameslwoodward) (talk to me) 14:16, 23 May 2023 (UTC)Reply[reply]

I think Commons:File types#Tabular data clearly shows that the file is of a type regarded as in scope, so any out-of-scope statement should be complemented by a discussion on why these files, as opposed to other .tab files, aren't in scope. As deleting files supposedly uploaded to be used, is disruptive, we should undelete these now, pending a discussion on and codification of the scope of the data namespace. –LPfi (talk) 17:46, 23 May 2023 (UTC)Reply[reply]
time for desysop.--RZuo (talk) 12:40, 27 May 2023 (UTC)Reply[reply]
@RZuo: assuming you mean of Jameslwoodward, keep in mind that your comment didn't ping him. That's a pretty strong proposal to go without a notification. - Jmabel ! talk 16:16, 27 May 2023 (UTC)Reply[reply]
@Jameslwoodward: I requested a link. You have failed to provide one. Please do so ASAP. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:22, 28 May 2023 (UTC)Reply[reply]
Sorry, I don't understand. You said, "link please", but I don't understand what you want a link to. More broadly, it is clear that this question has generated a lot of heat. I don't feel strongly about the issue, so please resolve it in whatever way the consensus want. .     Jim . . . (Jameslwoodward) (talk to me) 19:35, 29 May 2023 (UTC)Reply[reply]
@Jameslwoodward: No; you don't get to opt out of your responsibilities like that. You have unilaterally deleted files while there is an ongoing and unresolved deletion debate. You have been challenged over that, so you should restore them at least until that debate is concluded. The link I wanted was to where, you claimed, "The consensus at Undeletion Requests was that data tables are out of scope". No-one can find any such consensus, so we need a link to verify that your claim is true. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:14, 29 May 2023 (UTC)Reply[reply]
@Jameslwoodward: it looks to me like your basis for deletion amounted to, "I think we shouldn't have 'Data' space because tabular data don't belong on Commons" or "I think we shouldn't use 'Data' space because tabular data might get messed up without anyone noticing" or "I was completely unaware of 'Data' space and didn't know Commons handled tabular data". If that was the case, then certainly these should be undeleted. 'Data' space is certainly under-documented, but it isn't as if it was created by mistake or against consensus. This is very like someone deciding that Commons shouldn't have sexual imagery, or Commons shouldn't have materials that some particular government doesn't like: an opinion that has nothing like consensus behind it should not carry the weight of policy simply because an admin happens to hold that opinion.
If there is some specific reason this particular data set is problematic, that might be another matter, but I haven't seen any statement to that effect. And even then, we tend to approach things like that with {{Fact disputed}} etc., not with deletion. It looks to me like these should be undeleted. I would rather see that resolved here by you agreeing to it, but if you won't then I guess I'll start a formal undeletion process, where I suppose we will have to rehash what has been written here. - Jmabel ! talk 22:49, 29 May 2023 (UTC)Reply[reply]

The UnDRs are at Commons:Undeletion_requests/Archive/2023-05#Data:Ncei.noaa.gov/weather/Montpelier.tab and the next one after it. Note that both were open for more than the usual 24 hours and that I commented on one and had nothing to do with the other. .     Jim . . . (Jameslwoodward) (talk to me) 13:58, 31 May 2023 (UTC)Reply[reply]

@Yann: I believe this was wrongly decided (by you). I'm asking you to reconsider. The statement that tabular data should be somewhere other than Commons seems to me to completely wrong: this is exactly what Data: space is for. - Jmabel ! talk 17:48, 31 May 2023 (UTC)Reply[reply]
@Jmabel: Please create another UDR. I won't oppose undeletion, and if there is a consensus I will undelete them. Yann (talk) 18:04, 31 May 2023 (UTC)Reply[reply]

@Jameslwoodward, Fumikas Sagisavas, MKFI, AFBorchert, LPfi, El Grafo, Jheald, Adamant1, Ikan Kekek, Pigsonthewing, Ooligan, Yann, and RZuo: New UDR is at Commons:Undeletion requests/Current_requests#Data:Ncei.noaa.gov/weather/Montpelier.tab_and_Data:Ncei.noaa.gov/weather/Juneau.tab - Jmabel ! talk 18:36, 31 May 2023 (UTC)Reply[reply]

May 17[edit]

Should we adopt the proposed Child Protection policy?[edit]

I noticed recently that Commons:Child protection is still marked as a draft policy, despite having been in the works for several years. I'd like to start a discussion here with the goal of making it an actual policy on Commons. The policy, as written, is eminently reasonable, serves as a reasonable baseline for child protection, and would help to bring us in line with child protection policies adopted on several other Wikimedia wikis (such as MetaWiki and EnWiki). — Red-tailed hawk (nest) 14:58, 17 May 2023 (UTC)Reply[reply]

I'm in favor of approving this policy, but there is one thing that's glaringly absent from it: a statement that everyone who violates it will be reported to Wikimedia Legal. Should we add that? Why or why not? -- Ikan Kekek (talk) 18:47, 17 May 2023 (UTC)Reply[reply]
I think this is just a summary of other guidelines they are already in place. The "Advice for younger editors" could be advises to all people on the internet. Many of the cases mentioned on the page are not a reason of a infinite block they are cases for T&S and global bans. T&S is currently not even mentioned on the page. If we think we need something like this we should create a general Commons:Privacy and security advises page. GPSLeo (talk) 19:24, 17 May 2023 (UTC)Reply[reply]
I think that would be a wise addition, so I've added that here. — Red-tailed hawk (nest) 20:24, 17 May 2023 (UTC)Reply[reply]
How do we figure out which material is considered obscene? The page already says that CSA is against the ToS (obviously) so i figure out the obscene part refer to something else Trade (talk) 21:33, 17 May 2023 (UTC)Reply[reply]
Since we operate in the United States, it would be by applying the Miller Test. I don't anticipate this being an issue we would encounter; genuinely obscene material is going to be out-of-scope, so we'd be deleting it already. The sorts of obscene images that are prohibited by that test cannot have non-trivial literary, artistic, political, or scientific value, and I think that educational media is going to almost always meet one of those.
Frankly, I'm struggling to come up with an example of something that's possibly in educational scope, not covered under CSAM, and also obscene under U.S. law. The closest I can come up with is a video taken by a rapist of them actively brutally raping some non-child being uploaded for use in an article about rape to demonstrate an example of what violent rape looks like—and I think WMF would have to delete it anyway because of applicable law (as well as... ya know... basic human decency, or absent that the Commons:Photographs of identifiable people policy). And even that example feels like a bit of a stretch. — Red-tailed hawk (nest) 02:07, 18 May 2023 (UTC)Reply[reply]
Might wanna add this into the policy page Trade (talk) 15:11, 18 May 2023 (UTC)Reply[reply]
And, for what it's worth, the ToU prohibits Posting or trafficking in obscene material that is unlawful under applicable law, so I don't think that this is introducing anything new. — Red-tailed hawk (nest) 02:10, 18 May 2023 (UTC)Reply[reply]
  1. The proposed policy says: "Those affected should contact an admin by email". I have had very bad experiences with this, when I emailed an admin i really trusted. This should be deleted and perhaps replaced by contacting VRT, where at least several admins can look at it, which is a certain protection against a malicious admin.
  2. It contains a list of things a child can do to not get harrassed. Somehow I had expected a list of things that commons and the community do to protect children (for example implementing a direct message system, that does not expose email addresses by design).

--C.Suthorn (@[email protected]) (talk) 07:07, 18 May 2023 (UTC)Reply[reply]

May i ask what happened regarding the admin you emailed? Trade (talk) 15:12, 18 May 2023 (UTC)Reply[reply]
Them turned out to be a friend of another well connected user who was later globally locked because of another incident. C.Suthorn (@[email protected]) (talk) 19:45, 18 May 2023 (UTC)Reply[reply]
The other options that we would have would be:
  1. "Those affected should email the Commons oversight team at [email protected]",
  2. "Those affected should email the Commons information team at [email protected]",
or some combination of the two.
Do either of these stand out as better to you, C.Suthorn? My hunch would be toward pointing towards the oversighters (who are vetted for this sort of sensitive information a bit more closely than admins or random VRT members are), but the problem is that there's typically a good bit of lag between an email being received and an oversight action being taken. — Red-tailed hawk (nest) 04:44, 19 May 2023 (UTC)Reply[reply]
If there is no suitable group and no suitable email address, a suitable group can be set up and an appropriate email address can be created. For example "[email protected]"? C.Suthorn (@[email protected]) (talk) 05:55, 19 May 2023 (UTC)Reply[reply]
Sitting on this a bit more, I think the solution to this would be to try to have more oversighters. This sort of stuff involves the same level (or greater) trust than the other things that get suppressed, so having more people vetted for that purpose would probably be the optimal way forward. In emergencies, Stewards can act, but I don't think that they are going to want to be taking on this stuff (CC: AntiCompositeNumber and DerHexer, Jon Kolbert, who appear to be the only Commons admins who are also Stewards from what I can see). There aren't a shortage of people who are trustworthy enough to perform oversight tasks; the bigger issue is persuading people to run. — Red-tailed hawk (nest) 03:24, 20 May 2023 (UTC)Reply[reply]
@Red-tailed hawk: I have made use of the oversight tool as an emergency action once as there was private information linked to from a public channel in IRC and no local OSer available. I do not have access to the Commons oversighters VRT queue so I do not know what the turnaround is for a response there. I think a step in the right direction would be allow stewards to have access to that queue and amend the Oversight policy on Commons to include language similar to what is included on Wikidata's oversight policy which states "Stewards can perform local oversighting in emergencies, during crosswiki oversighting, or if there are no local oversighters available." That way, requests can be handled promptly even if there is no local oversight immediately available. Jon Kolbert (talk) 00:30, 27 May 2023 (UTC)Reply[reply]
@Jon Kolbert As far as I know, there is not a VRT queue, but instead a mailing list. And I don't think a local change is needed to allow Stewards to "perform local oversighting in emergencies, during crosswiki issues, or if there are no local oversighters available", as this is explicitly allowed by the global policy, but I'll update the information page anyways (we have no local oversight policy).
Also, I would add legal-reports@wikimedia.org to the list of people to contact. —‍Mdaniels5757 (talk • contribs) 21:51, 29 May 2023 (UTC)Reply[reply]
The oversighters currently use a google group. I agree that adding [email protected] would be prudent. — Red-tailed hawk (nest) 13:20, 1 June 2023 (UTC)Reply[reply]
@Jon Kolbert and Mdaniels5757: I've made some tweaks to the proposal today that incorporate some of the suggestions in this VP thread. — Red-tailed hawk (nest) 14:44, 3 June 2023 (UTC)Reply[reply]
No, i don't think that policy is needed here specifically as its already covered under Wikimedia Foundation's own Terms of Use.. It was something worth discussing a decade back but since WMF started hiring more employees including litigators and lawyers, there is no need for it..--Stemoc 17:30, 18 May 2023 (UTC)Reply[reply]
Just my two cents, but it seems like putting the cart before the horse to have special policies for protecting children when there aren't even basic civility guidelines in place that are being inforced. Let the WMF deal with it if it's something serious, but that's already happening from what I've seen and admins aren't dealing with more minor stuff in the meantime anyway. It would be weirdly discriminatory if they were only dealing with civility issues or harrasement if either one involved children but not anyone else. --Adamant1 (talk) 18:49, 18 May 2023 (UTC)Reply[reply]
I agree that we need to work on getting COM:CIVILITY to policy status and actually enforcing civility norms. I think that's orthogonal to this discussion, though, and I don't see making progress on one as blocking progress on the other. — Red-tailed hawk (nest) 04:30, 19 May 2023 (UTC)Reply[reply]
Just today a user was warned for copyvio despite my ban request being for posting pornography of a woman without her consent. No amount of policy will matter if admins don't actually read the block requests. Trade (talk) 00:19, 22 May 2023 (UTC)Reply[reply]
I agree that better enforcement across the board is needed for these sorts of things. — Red-tailed hawk (nest) 14:23, 3 June 2023 (UTC)Reply[reply]

May 22[edit]

Berlin transit icons[edit]

I am exploring the possibility of refreshing the U-Bahn and S-Bahn icons (located here and here respectively), but I have run into an issue where the colours in the BVG website, S-Bahn website and VBB map are inconsistent. The following table contains the hexadecimal values from my research into three sources: the BVG website, the S-Bahn website, and the VBB map:

Mode and line colours
Line BVG (web) DB (web) VBB (map)
Modes[1][2][3]
Regio
 
be1414
 
e10a17
 
e2001a
S-Bahn
 
45935d
 
007238
 
008d4f
U-Bahn
 
115d91
 
1e6ab2
 
0066ad
Tram
 
be1414
 
cc151a
 
e2001a
Bus
 
95276e
 
a01c7d
 
a5027d
Ferry
 
528dba
 
0099d6
 
009bd5
S-Bahn[4][2][3]
S1
 
bc6194
 
eb588f
 
da6ba2
S2/25/26
 
457236
 
047939
 
007734
S3
 
115d91
 
026597
 
0066ad
S41
 
a0542e
 
aa3c1f
 
ad5937
S42
 
af6223
 
ba622d
 
cb6418
S45/46/47
 
bc9144
 
ca8539
 
cd9c53
S5
 
ee771e
 
ea561c
 
eb7405
S7/75
 
8c6dab
 
764d9a
 
816da6
S8/85
 
7dad4c
 
4fa433
 
66aa22
S9
 
701c28
 
951732
 
992746
U-Bahn[4][2][3]
U1
 
7dad4c
 
7dad4c
 
7dad4c
U2
 
da421e
 
da421e
 
da421e
U3
 
16683d
 
2e937d
 
16683d
U4
 
f0d722
 
f0d722
 
f0d722
U5/55
 
7e5330
 
7e5330
 
7e5330
U6
 
8c6dab
 
8c6dab
 
8c6dab
U7
 
528dba
 
528dba
 
528dba
U8
 
224f86
 
224f86
 
224f86
U9
 
f3791d
 
f3791d
 
f3791d
Fare zones[4][2][3]
A
 
be5a00
 
fba71d
 
bd5a00
B
 
008291
 
1a9c9f
 
008291
C
 
5a821e
 
8dc73f
 
5a821e

I am aware that the U-Bahn line icon colours were changed by Teo.raff in 2020, in response to Berliner_Verkehrsbetriebe § Farben. However, I am minded to contest the changes because they are notably darker and desaturated, especially with the U7 icon. However, I have problems trying to find the Basiselemente (CD-Manual), as referenced in the German article. I wonder if anyone can help me find that because (1) I may look at using the Pantone hexadecimal values instead from the colour book that I happen to have, and (2) I don't know if the Basiselemente gives those exact hexadecimal values that the website uses. --Minoa (talk) 03:49, 22 May 2023 (UTC)Reply[reply]

@Minoa So what? Sometimes in life there is not a single correct answer for something and that's OK. Suggest to watch this video on "the" American flag and embrace the chaos. El Grafo (talk) 08:18, 23 May 2023 (UTC)Reply[reply]
@El Grafo: Understood, although the discovery of the VBB handbook means I am close to answering my own question, with the choice between RGB and CMYK yet to be decided due to lack of time for now. ;-) Either way, I will be documenting the sources and my colour selection process. --Minoa (talk) 22:46, 24 May 2023 (UTC)Reply[reply]
@Minoa That one seems like an easy one: CMYK only really makes sense for professional printing. Or main target audience will almost exclusively view our media on some form of screen, which is RGB. Go for RGB. El Grafo (talk) 07:48, 25 May 2023 (UTC)Reply[reply]

29 May update[edit]

I am pleased to inform readers that I have started the process of modernising the transit icons (see {{Berlin transit icons}}), starting with the S-Bahn: I have recreated the icons straight from the TransitLinie fonts that I happen to have, just like what I did with the Standard set of the New York City Subway bullets. A video of an old rollsign from the DBAG Class 476 allowed me to expand the S-Bahn icon set.

@El Grafo: I accept your recommendation that the colours should be VBB's RGB values, apart for U7, which will use VBB's colour for the Fähre (since they were meant to use the same colour). --Minoa (talk) 06:56, 29 May 2023 (UTC)Reply[reply]

References

  1. ↑ CSS Stylesheet (Modes) (CSS). Berliner Verkehrsbetriebe (16 May 2023). Archived from the original on 21 May 2023. Retrieved on 21 May 2023.
  2. ↑ a b c d CSS Stylesheet. S-Bahn Berlin. Deutsche Bahn (30 April 2023). Archived from the original on 21 May 2023. Retrieved on 21 May 2023.
  3. ↑ a b c d "Farben Liniensignets" in (in German) (6 May 2022) Handbuch VBB-Richtlinien Fahrgastinformation (May 2022 ed.), Berlin: Verkehrsverbund Berlin-Brandenburg, pp. 8,11,135
  4. ↑ a b c CSS Stylesheet (Lines) (CSS). Berliner Verkehrsbetriebe (16 May 2023). Archived from the original on 21 May 2023. Retrieved on 21 May 2023.

FileExporter problem?[edit]

Lately I'm experiencing slowdown in image file transfers, especially when transferring User:Patrickroque01's tons of local enwiki photos to Commons using FileEx/Importer tool. I've suffered a major error while transferring his File:Saint Stephen The Protomartyr Church Ligao (San Esteban, Ligao, Albay; 04-16-2023).jpg to Commons. The error message reads "Import failed. Failed to commit operations". But after forcefully reloading/refreshing, the message claims the file exists here. Yes it exists, but the photo or the thumbnail versions cannot be downloaded. Kindly check the photo file. I'm not sure if it is a problem of FileEx/Importer tool or a problem of my network provider or my phone's browser app which tends to slow down when accessing most of Wikimedia Commons. JWilz12345 (Talk|Contrib's.) 11:59, 22 May 2023 (UTC)Reply[reply]

Seems ok now (or so?). I'll tag the enwiki copy for speedy deletion any way. JWilz12345 (Talk|Contrib's.) 13:05, 24 May 2023 (UTC)Reply[reply]
Pictogram voting info.svg Info
another photo by Patrickroque01 (talk · contribs) suffered this failed importation problem while I'm trying to transfer the local file to Commons: File:Dalakit Beach, Pacific waves (Catarman, Northern Samar; 04-27-2023).jpg. JWilz12345 (Talk|Contrib's.) 07:12, 29 May 2023 (UTC)Reply[reply]

May 24[edit]

AI and the decision not to participate[edit]

I had been about scanning and uploading my old photos of unusual places to Wikimedia Commons, but then I decided not to. Why? The immediate and unresolved problems of AI-based images: wholesale licensing theft. I have my doubts about this getting resolved any time soon due to the piratical nature of tech CEOs. THSlone (talk) 00:58, 24 May 2023 (UTC)Reply[reply]

  • How is looking at your image, stealing it? They don't store a copy of your image, the AI just looks at it, an stores an impression of it. Just like me being inspired by a Jackson Pollock painting to copy his style. And if you don't store them here, they will probably be tossed in the garbage in one or two more generations. No one will remember who you were, and why the images were important to you. Sites like Flickr are threatening to delete once you stop paying, Google just announced all your cloud storage will be deleted if you don't log in for two years. --RAN (talk) 04:20, 24 May 2023 (UTC)Reply[reply]
    • Richard Arthur Norton, About 10 (ten) years ago Google used to delete your cloud content after 9 (nine) months, the irony is that while Moore's law's demise meant that computing power hasn't grown exponentially, computer storage technology is still on an exponential curve. This means that despite computer storage becoming cheaper companies offer less of it and will delete your files more, my guess is that the AI training software doesn't need stored files anymore as people upload a lot of files to services like Meta's Facebook, Google's YouTube, and Bytedance's TikTok. My guess is that the Wikimedia Commons isn't a large source for AI training to begin with either. Plus as storage becomes cheaper less donation money is needed by the WMF to maintain the Wikimedia Commons.
      Uploading old photographs from the pre-smartphone era also allows a period in history to be preserved that I think a century from now people will be cursing at us for not having preserved as much of it.
      This is also why I'm for direct co-operation with SmugMug for us to import freely licensed images from Flickr, it's clear that a lot of data will be destroyed and nobody is doing anything to preserve so many files of historical value. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:15, 24 May 2023 (UTC)Reply[reply]
  • Twitter also announced they will begin deleting inactive accounts. --RAN (talk) 12:11, 24 May 2023 (UTC)Reply[reply]
    • Richard Arthur Norton, I wonder if the Internet Archive is planning on doing anything with that or if Elon Musk is willing to work together with the Internet Archive. I am convinced that 50 (fifty) or a hundred (100) years from now the Internet Archive will become one of the Wikimedia Commons' biggest source of content, though future generations will curse us for preserving so little. I really hope that OP will change their mind on not wanting to upload, AI will train regardless. Plus humans also train their creativity by looking at existing works, I've never heard of an art school where they never look at an existing piece of art, but for robots we somehow consider it "stealing" to simply look at our works for inspiration.
      To be fair, even Andy Warhol wasn't exempt from this. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:38, 28 May 2023 (UTC)Reply[reply]
      • If generative AI was just looking at text and images, it wouldn't be a problem as far as I'm concerned. It is doing much more than that by creating new text and images from pirated text and images, what is known as derivative work in copyright jargon. There are already lawsuits regarding copyright theft from generative AI.[2] Lawsuits based on Creative Commons licensing would seem to be harder to enforce than copyright. I'm more inclined to upload my images for the common good than I am doing what amounts to free labor for tech companies and their affiliated billionaires. THSlone (talk) 00:33, 30 May 2023 (UTC)Reply[reply]
        • @THSlone: just out of curiosity: does this mean you will no longer put images online anywhere? Because I don't see how images on Commons are more subject to this than others. For that matter, the same can be said of writing text online. - Jmabel ! talk 18:57, 30 May 2023 (UTC)Reply[reply]
          • I hadn't uploaded my own personal photographs to the Commons mainly because it's time consuming scanning them in and I have to invest in a slide scanner for this sole purpose. Right now, they are not on the Web. The likelihood of fueling generative AI, pushed it over into why bother? THSlone (talk) 19:19, 4 June 2023 (UTC)Reply[reply]

License reviews[edit]

Hi, Manual license review obviously doesn't scale. We have files waiting reviewing for more than 2 years. Couldn't we have a bot reviewing licenses for files from YouTube and Vimeo, like we have for Flickr? Yann (talk) 19:26, 24 May 2023 (UTC)Reply[reply]

Actually there was a bot, supposed to be replaced by another bot, which stopped working more than one year ago. I could run it myself. The bot master is not active, but has anyone a copy of the code? Yann (talk) 20:04, 24 May 2023 (UTC)Reply[reply]
@Yann I looked into this a while ago, and could not find the code. Eatcha did not reply to email either. I actually (just before seeing your comment) had requested a list of Toolforge tools for which Eatcha was owner phab:T337432, so one or both of us could hopefully adopt the tools per policy. Hopefully it was on Toolforge like some of their other tools! —‍Mdaniels5757 (talk • contribs) 20:10, 24 May 2023 (UTC)Reply[reply]
i've been wanting to reform the youtube bot review process for a long time. instead of letting a bot review files by itself, i think it should be done like this:
  1. the bot reviews a file (whose source=youtube) only to verify the given youtube link is youtube-cc-by. this puts the file into a category "files reviewed by youtubebot pending human reviews".
  2. a human would check if the commons file does actually come from that youtube link, and pass it. then the file is put into a category "files reviewed by youtubebot and reviewer".
flickrbot can review files by itself because it verifies whether commons copy is identical to flickr copy, but it's obviously not feasible for youtubebot to do that.
"files reviewed by youtubebot pending human reviews" is less urgent than the current "licence review needed", because at least the given youtube link would be verified to be ccby. it doesnt matter if the licence would be changed later. the only problem would be if the video disappears before a human reviews it. then we can review the files on a case-by-case basis to decide if evidence is sufficient to establish the authenticity of the files. RZuo (talk) 22:48, 24 May 2023 (UTC)Reply[reply]
In my experience of reviewing files from YouTube, reviewing could be tedious but we need to endure that. Not all freely-licensed YouTube videos are decent. They may look decent at first but later on one may find third-party content that the YouTube author incorporated in their video. That third-party content may come from unfree sources like screenshots from ABS-CBN newscasts or citizens' video shots that were not originally from the YouTube author but the author just included them in their video. JWilz12345 (Talk|Contrib's.) 00:37, 25 May 2023 (UTC)Reply[reply]
@Yann: Last time we discussed this (Commons:Village_pump/Archive/2023/04#103,857_unreviewed_files) I did a suggestion on how to split up the work to make it more manageable. I was told this is a really bad idea and didn't feel like spending any energy on this anymore. I can just assume that user hasn't learned yet that the wiki way is to eat an elephant one bite at a time and for that the work needs to be bite sized so more people help out a little. Multichill (talk) 13:34, 25 May 2023 (UTC)Reply[reply]
Category:Files moved to Commons requiring review is split up by date. is that bite-sized enough for you? now is 2023, but the oldest subcat is Files moved to Commons requiring review as of 29 April 2008‎ (28 F) from 15 years ago. notably, that subcat was created at 20:11, 5 March 2009‎ by BotMultichillT.
https://commons.wikimedia.org/w/index.php?title=File:Arash_Arabasadi_-_.@VOANews_HalftimeShow_is_about_to_start_at_SuperBowlLII.webm&diff=prev&oldid=398248932 added the file to "Twitter videos review needed" (which is small enough with only 13 files), but 3 years after this edit and 5 years after upload it remains unreviewed.
shifting files around in maintenance cats only make some users feel good, but doesnt actually help with shortening the queue. RZuo (talk) 15:17, 25 May 2023 (UTC)Reply[reply]
Category:Files requiring license review sorted by user name has 1k gallery pages, but the review process was obviously not sped up even with this aid. RZuo (talk) 16:14, 25 May 2023 (UTC)Reply[reply]
  • My guess is that WMF is waiting for AI to become intelligent enough to handle these reviewing tasks. Maybe 10 years later? If an AI-fortied bot can do all the tedious tasks, why humans do the same things spending their precious time? --トトト (talk) 14:57, 25 May 2023 (UTC)Reply[reply]
A video clip I uploaded from Youtube have has been deleted today. The author changed the license before it is to be reviewed here, I think. If the LicenseReviewerBot had been active, this must have been prevented. Sad to see a quality media being deleted, and I fear that people will become reluctant to upload medias from Youtube in the future. --トトト (talk) 15:53, 1 June 2023 (UTC) 0〔tekst gecorrigeerd. --トトト (talk) 17:11, 1 June 2023 (UTC)〕Reply[reply]
dont write shorts url. use this kind of link instead https://www.youtube.com/watch?v=VVf9IrVGHSo . RZuo (talk) 16:03, 1 June 2023 (UTC)Reply[reply]
  • Thank you for the new URL. I've requested undeletion of the file. --トトト (talk) 16:54, 1 June 2023 (UTC)Reply[reply]
https://commons.wikimedia.org/w/index.php?title=File:ANA_LABORDETA_2008.jpg&diff=prev&oldid=766959842 took me quite some time to find the actual webpage. is this effort to find the source worthwhile? or should we just send this to DR and let the uploader fix it properly? RZuo (talk) 16:12, 25 May 2023 (UTC)Reply[reply]
https://commons.wikimedia.org/w/index.php?title=File:Marian_Anderson_christens_the_liberty_ship_Booker_T._Washington.jpg&diff=prev&oldid=660337341
reviewer User:Howcheng adding an empty LR template to a pd file. ¯\_(ツ)_/¯ RZuo (talk) 18:49, 4 June 2023 (UTC)Reply[reply]

May 26[edit]

Legality of Indian maps[edit]

This discussion about the legality of Indian maps seems like it might be relevant to Commons: w:Wikipedia:Neutral point of view/Noticeboard#Communications from government of India to Wikimedia Foundation regarding content about maps depicting the borders of India. –Novem Linguae (talk) 12:30, 26 May 2023 (UTC)Reply[reply]

It seems a letter from Indian authorities was sent to WMF, mostly concerning maps at Wikipedia and Wikimedia Commons. Did we get a notice other than this?
The point is that it is illegal in India to use other borders than those India think are the correct ones (there are claims on the Pakistani and Chinese borders). The Indian authorities threatened to close down Wikipedia, but they seem to be quite understanding now that there was a dialog. There is still a list of maps where they would like warnings or disclaimers and links to official maps (in captions or on file description pages, as appropriate, I assume). Some in the en-wp community think that even that is unsustainable, as there are other similar disputes around the world, others think warnings are due on some of the maps.
At one stage, it seemed one could get a consensus, where only some files remained problematic, but at some point the more "fundamentalist" wing got more vocal. Seems not much has happened in the discussion lately.
The question for Commons, it seems, is whether to have a template to warn that a map may be illegal in India. Stating the fact that some of the borders are disputed may be a good thing to do, and a template could have a well thought-out wording translated to at least the most relevant languages, but I don't like big warning templates, and when it is about one countries (possibly unreasonable) claims, such a warning seems inappropriate (giving them undue weight).
–LPfi (talk) 06:51, 2 June 2023 (UTC)Reply[reply]
I think we should have a warning template. It should indicate that borders in this area (the relevant portion of the borders of India, Pakistan and China) are disputed, and that in India (and possibly others?) it is illegal to use a map that does not conform to India's claims.
The template should be on all maps of this area, not only the ones that India doesn't like.
Question: does Pakistan or China have parallel laws?
Question 2: does this mean that historical maps are banned in India (e.g. a map of the British Raj) or only maps that claim to show the situation after some date (and, if so, what date?). - Jmabel ! talk 15:10, 2 June 2023 (UTC)Reply[reply]
Jmabel ! talk 15:10, 2 June 2023 (UTC)Reply[reply]
(The issue is covered also in The Signpost issue of 5 June 2023: Wikipedia Signpost § Indian map dispute. –LPfi (talk) 09:21, 5 June 2023 (UTC))Reply[reply]

May 28[edit]

Map from Le monde diplomatique[edit]

This file File:Yezidi populated area.png had no source which I therefore had to find and add. However, I am still uncertain about the copyright of the map as I could not find any info on it on mondediplo.com. Assuming the site is an ofshoot of lemonde.fr, I also checked that site and the what I found was [3] which states:

Not to infringe the rights of a third party - Not to post, record or transmit copyrighted material, unless they can guarantee they have obtained the permission of the rights holder and can provide proof of this.

The map is listed under public domain which is incorrect or are we to assume the uploader has received permission from creator? Semsûrî (talk) 10:37, 28 May 2023 (UTC)Reply[reply]

I don't think you can release things to the public domain in EU, so unless the map is from a source that is exempted from copyright protection, that classification seems erroneous. Things either are or are not in the public domain – a permission from the author doesn't change that status. –LPfi (talk) 07:28, 2 June 2023 (UTC)Reply[reply]
I see. Well the file has now been deleted so I guess my suspicions were correct. Semsûrî (talk) 07:37, 2 June 2023 (UTC)Reply[reply]

Category:Photographs by Alisdare Hickson[edit]

This is an extension of Commons:Deletion requests/Files found with "roguenation.org", which was resolved as having a strong consensus to keep, but to rewrite the captions for neutrality. (They also need some category work and {{Taken on}}.) We have a bunch of excellent photographs here, but they were uploaded with very polemical descriptions. User:Ikan Kekek and I have now been through the bulk of them. Typical cleanup has been along the lines of [4]. It turns out that there are more photos in Category:Photographs by Alisdare Hickson that didn't get included in that deletion request and which have similar issues. Help in cleaning those up would be greatly appreciated. This has been a lot of work, but the images are definitely worth saving. - Jmabel ! talk 21:57, 28 May 2023 (UTC)Reply[reply]

I'll have a look when I can, and any other help would definitely be appreciated. Thanks, Jmabel. -- Ikan Kekek (talk) 06:31, 29 May 2023 (UTC)Reply[reply]
Maybe we should have a template for image descriptions that needs to be "neutralized" or what else you wanna call it? Trade (talk) 12:22, 29 May 2023 (UTC)Reply[reply]
@Trade: Fine with me. & that should place the file in a maintenance cat.
Keep the template simple, something like "The file description may need to be rewritten for neutrality (NPOV)." - Jmabel ! talk 14:57, 29 May 2023 (UTC)Reply[reply]

Further status: all of the ones in Commons:Deletion requests/Files found with "roguenation.org" are now handled. - Jmabel ! talk 22:51, 29 May 2023 (UTC)Reply[reply]

For the more general issue, I've now created {{NPOV}}. Someone is welcome to enhance it with date tracking, multi-lingual approach, etc. I've kept it very simple for now. It places files in the new maintenance category Category:Files needing neutral descriptions. - Jmabel ! talk 23:10, 29 May 2023 (UTC)Reply[reply]

May 29[edit]

How to handle sources that are dead links[edit]

Lately I've been noticing a good amount of sources for files that are either dead links or pages that don't contain the file. So what exactly, if anything, should be done in those cases? I guess there's a "dead link" template, but at least from what I've seen they just sit there for years without being dealt with. The other option would trying to find a backup of the page on the Way Back Machine, but it wouldn't allow for someone to view or download the original file anyway. Not to mention I find a backup of a website on there as it is. And I assume just deleting the links would be looked down on, even if it's technically "correct." So I'm wondering what other options there are, if any, to deal with dead links or pages that don't contain the files besides the ones I've already mentioned. Thanks. Adamant1 (talk) 07:58, 29 May 2023 (UTC)Reply[reply]

It depends. Were the picture verified before the URL died? Trade (talk) 12:13, 29 May 2023 (UTC)Reply[reply]
No clue. I assume so. Otherwise I don't know why the uploader would have added it as a source. I guess that is something to consider though. --Adamant1 (talk) 14:54, 29 May 2023 (UTC)Reply[reply]
We ask for a source, so it is natural that the user provides a link. The upload wizard doesn't give much advice on what link to choose and some sites don't make it easy to get a good link. The uploader is not requested to prevent link rot. I assume some links are checked in connection with new upload patrolling, otherwise they may or may not survive until somebody happens to check them.
I think one should leave the link, unless one finds a good one to substitute. Somebody might be able to deduce something from the original, and not everybody studies the history to find the replaced link. Adding an archive link (or adding a comment on the original site) does no harm though, and may save the file in the future.
If the link looks like a plausible source, we should assume good faith and not delete as "source missing". If we have reason to assume there might be problems, then we have a problem, but that's when to try to handle them.
–LPfi (talk) 08:55, 31 May 2023 (UTC)Reply[reply]
If the link looks like a plausible source, we should assume good faith Your free to disagree, but I just see dealing with dead links (however that's done) as part of the basic task of maintaining a good media repository. So in no is fixing a dead link (again, however we do that) an assumption of bad faith. It's not like I've claimed the links are dead because the uploader intentionally linked to bad URL. I just don't dead links are helpful. Like look it this way, say there's an image that is hard to identify or that the person looking at the image wants to find out more information about, but the source is a 401 error. Sure, we could just leave it so no one cries foul about how the person who fixes is being bad faithed or whatever, but how exactly does that help anyone? The whole point in having a source is so people can find out more information about the file and confirm the license of the image if they want to. So in the best of cases dead links are a wash, in the worst case they get in the way of people using the summary field how it was intended. Especially if there is a large number of dead links. Again, it's just a basic maintenance issue that would be worth dealing with if there's a good way to. I never said it was anything more than that, but it's still a problem nonetheless. --Adamant1 (talk) 09:35, 31 May 2023 (UTC)Reply[reply]
I'm basically with LPfi here: if you can give an updated link (or an archive link), great. Otherwise, mark the link as dead, but don't delete it. - Jmabel ! talk 17:51, 31 May 2023 (UTC)Reply[reply]
The key is "Somebody might be able to deduce something from the original [link]", even the outsider interested in the file, who might not know how to research the file history. LPfi (talk) 07:34, 2 June 2023 (UTC)Reply[reply]

May 30[edit]

[edit]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the WMF office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.

The takedown can be read here.

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#Java logo. Thank you! Joe Sutherland (WMF) (talk) 23:21, 30 May 2023 (UTC)Reply[reply]

May 31[edit]

Pixabay photo dates[edit]

Is there a way to tell when a photo posted to Pixabay was taken? The site seems to show only the date that it was posted to the site and the date that it was reviewed and approved by an administrator. Pixabay doesn't seem to preserve exif/metadata either so there are no hints there. For example, all I can guess about this photo was that it was taken sometime before July 19, 2016. --Denniscabrams (talk) 16:51, 31 May 2023 (UTC)Reply[reply]

Template help needed[edit]

I deleted Category:Most populous cities of the world per Commons:Categories for discussion/2023/02/Category:Most populous cities of the world. Now Template:Most populous cities of the world needs to be modified to not use Category:Most populous cities of the world, but I can't work out how to do this. - Jmabel ! talk 17:56, 31 May 2023 (UTC)Reply[reply]

@Jmabel: I think this did it. Pi.1415926535 (talk) 01:23, 1 June 2023 (UTC)Reply[reply]
Thanks! Sadly, it looks like someone also added Category:Most populous cities of the world overtly to a bunch of categories. Can't use VFC to remove it from categories. Anyone have any ideas for removing this efficiently? - Jmabel ! talk 02:32, 1 June 2023 (UTC)Reply[reply]
Pictogram voting keep-light-green.svg Fixed with Cat-a-lot. --Jarekt (talk) 02:58, 1 June 2023 (UTC)Reply[reply]

June 01[edit]

AI generated media competition[edit]

I was thinking about proposing Commons:Photo challenge for AI generated media, but I would like to use it for some ways to positively impact Commons and Wikimedia movement in general, or at the minimum shape the content in such a way as to minimize chances that many entries will be deleted. So the images would have to be within Commons scope, should not infringe on copyrights (no Disney characters). Some use cases where AI generated images could be useful:

  • images of Coats of arms based on public domain definitions (blazons)
  • images depicting hard to get subjects like displays of different human emotions, like anxiety,
  • images of different generic mythical, fantasy characters, D&D characters or some other characters have copyrighted specific renditions but which can be described in generic terms, like "wizards", "elves", "warlocks", "druids", etc.
  • images of Science fiction topics, like view of Saturn moons and rings from Saturn surface or rock-climbing robot from one of w:Stanisław Lem stories
  • images of celebrities, for whom we do not have good photographs. Can this be done without copyright infringement?
  • depictions of stigmatized topics, like w:Childhood obesity or Depression

Inviting various participants of AI related discussions and photo challenge discussions: @Kritzolina, Nosferattus, Jmabel, Yann, King of Hearts, Trade, and 1989: . Any thoughts about above use cases or about other AI friendly use cases? Jarekt (talk) 01:13, 1 June 2023 (UTC)Reply[reply]

  • I'd be very hesitant on the celebrities, unless your goal is to see how many DR fights we can start. - Jmabel ! talk 01:22, 1 June 2023 (UTC)Reply[reply]
  • This was already debated many times, and no, images created by AI are usually not copyright violations (except a few specific cases). I tried to create images of personalities with AI for which we don't have images, but it didn't work (I chose Michel Audiard, a prominent figure on the French cultural scene, for which we don't have a good portrait, except one with a dubious license). Either they are famous people for which we already have many free images, or they are not so known people, and there aren't enough examples for an AI to create something resembling. Yann (talk) 02:59, 1 June 2023 (UTC)Reply[reply]
  • @Donald Trung: The software is not all. One also needs to submit a coherent prompt, and then to choose the best images, and then reiterate the process until the desired result. Yann (talk) 19:14, 1 June 2023 (UTC)Reply[reply]
What are our guidelines on user-made art, such as depicting happiness, or obesity, or various celebrities? Fan art seems to be allowed, but otherwise I assume they are mostly deemed to be out of scope. Would they be seen as in scope if done well enough? I haven't seen such discussions, other than DRs on low-quality stuff. –LPfi (talk) 19:30, 1 June 2023 (UTC)Reply[reply]
@LPfi: , We do no have guidelines yet. Commons:AI generated media is a good start but it mostly concentrates on unacceptable cases. Category:AI generated images is full of interesting experiments which might only be usefull at demonstrating various AI engines, otherwise they are likely out of scope. I am searching for use cases where AI generated images would make positive impact. I assume that good quality user generated depictions of happiness, obesity, or various celebrities would be as welcome as user created photographs, provided that images are not clearly derivative of known copyrighted photographs, are good quality. We might need to create some additional guidelines or policies. For example, Commons:Photographs of identifiable people might need to be updated to cover issues with AI generated images. I am not sure where those future discussions will end up but I assume that we should have policy against AI depictions of identifiable people which would would be embarrassing to those people or which are depict some broadly defined falsehood or misinformation. At the same time images in the gallery at the top seem OK to me. --Jarekt (talk) 20:09, 1 June 2023 (UTC)Reply[reply]
The problem is that art by users a priori is out of scope and I don't know of any discussion on this. A photo of "happiness" would likely be deleted as unused personal image, and a painting on the theme would be deleted as "art by non-notable artist". It is a bit odd that the discussion on those categories of media should be discussed via the AI-generated equivalents, and equally odd if an image is in scope if generated by AI but not if painted by a user – except, of course, where the in-scope rationale is about showing AI use.
I think this discussion is good to have, but I would like participants to consider also the traditional techniques. Would this competition be a way to get illustrations of happiness etc., or to showcase AI? In the former case there is no reason to discriminate against "non-notable artists" – and we may get (or already have?) a problem with works by non-notable AI artists.
–LPfi (talk) 07:03, 2 June 2023 (UTC)Reply[reply]
LPfi, I feel like user generated media, be it a photograph, painting or AI generated image are in scope or out of scope based on what they are showing and is what they are showing "educational" or not. So yet another portrait of unknown person is likely to be out of scope, while depiction of a person, an object, organism, a place, a clothing or architecture style for which we have an article should be in scope no matter if it is a photo, painting or AI generated image. I do not think we discriminate against "non-notable artists", it is just that "non-notable artists" works are judged based on the content (and is it useful for us) while notable artist's works are in scope no matter the subject. I think the same criteria should apply to AI generated images. As for the monthly photo challenge, we do 2 topics for 2 challenges per month which have to be constrained somehow and my idea was to constrain it to AI generated images only, but I would like to create guidelines to minimize number of out-of-scope or copyright-violation entries. --Jarekt (talk) 17:37, 2 June 2023 (UTC)Reply[reply]
I think Jarekt has that right. - Jmabel ! talk 18:20, 2 June 2023 (UTC)Reply[reply]

Commons Gazette 2023-06[edit]

Staff changes[edit]

In May 2023, 1 sysop was elected; 1 checkuser was removed. Currently, there are 184 sysops and 4 checkusers.

Election:

Removal:

Edited by RZuo (talk).

Commons Gazette is a monthly newsletter of the latest important news about Wikimedia Commons, edited by volunteers. You can also help with editing! --RZuo (talk) 09:04, 1 June 2023 (UTC)Reply[reply]

RZuo, thank you for writing the Commons Gazette, while I don't really engage with it, I do read it, so I'd like you to let you know that it is very much appreciated. Keep up the good work. Face-smile.svg -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:48, 1 June 2023 (UTC)Reply[reply]
@RZuo I would suggest adding 2 FOP-related things for the Gazette: that FOP now exists in Timor-Leste/East Timor since the effectivity of their first copyright law in late May 2023, and Ukraine finally introduces freedom of panorama but with a non-profit condition unsuitable for Commons. JWilz12345 (Talk|Contrib's.) 13:27, 1 June 2023 (UTC)Reply[reply]
@RZuo: you never responded to my comment about the usage of staff so I changed it in this version. You reverted me without any explanation. Can you please explain yourself? Multichill (talk) 18:51, 1 June 2023 (UTC)Reply[reply]

Notification of DMCA takedown demand — Kempes en Valencia[edit]

In compliance with the provisions of the US Digital Millennium Copyright Act (DMCA), and at the instruction of the Wikimedia Foundation's legal counsel, one or more files have been deleted from Commons. Please note that this is an official action of the Wikimedia Foundation office which should not be undone. If you have valid grounds for a counter-claim under the DMCA, please contact me.

The takedown can be read here.

Affected file(s):

To discuss this DMCA takedown, please go to COM:DMCA#Kempes en Valencia. Thank you! Joe Sutherland (WMF) (talk) 17:34, 1 June 2023 (UTC)Reply[reply]

Flickr Foundation adopts Flickr2Commons[edit]

I've just received an email newsletter from the Flickr Foundation (aka Flickr.org; the non-profit arm of Flickr.com), which includes the paragraph (emboldening and links in original)):

We've partnered with the Wikimedia Foundation to adopt a tool called Flickr2Commons. We want to look after it and extend its features with the long term in mind. Keep your eyes open for "Flickypedia", which we plan to re-release towards the end of the year.

Does anyone know more about this "adoption", or what Flickypedia is? Or why this community was apparently not informed directly? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:18, 1 June 2023 (UTC)Reply[reply]

is f2c the first tool adopted by an established organisation?
sounds like a positive development. flickr foundation seems way better than the lame WMF.--RZuo (talk) 19:36, 1 June 2023 (UTC)Reply[reply]
The email is available online (IA snapshot). — Sam Wilson ( Talk • Contribs ) … 04:56, 2 June 2023 (UTC)Reply[reply]
Great news Captain America but the issue that they really need to fix is the updating of their current creative commons licences (still stuck on 2.0) and the addition of more licenses such as OGL and Crown Copyright and allowing users to create their own licences using their own choices as template, might be useful if WMF worked with Flickr in doing this, might also help us improve issues elating to Flickrwashing in the future.... Stemoc 05:44, 2 June 2023 (UTC)Reply[reply]
The "allowing users to create their own licences" sounds problematic. We don't want a zillion of vague "free" licences that may not guarantee the freedoms we want. They should instead introduce a smooth process to add Commons-, Gnu- and CC-approved free licences (with caveats about the restricted CC ones). –LPfi (talk) 07:10, 2 June 2023 (UTC)Reply[reply]
You could e-mail them at "[email protected]" (as is listed on their homepage) and then air your concerns there. Perhaps nobody who works with copyright ©️ there has really engaged with them outside of a small bubble. Perhaps you could suggest something as "Change allowing your own license to How do you want to be attributed? so re-users aren't confused and know how to credit the photographers in a way they find desirable". License fragmentation will only make the already complex intellectual property landscape 🌆 only more complex. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:41, 2 June 2023 (UTC)Reply[reply]
  • Kind of odd how they write "In collaboration with flickr.com, we launched the first redesign of the main Flickr Commons page since 2008." As if the Flickr Foundation is an entity completely separate from SmugMug, though I assume that they do this for legal reasons as they might be separate "legal persons" / "judicial persons" for legal reasons. What strikes me as odd is the entry "The groundbreaking Flickr Commons program will be sustained and supported by the Foundation. Our work will prioritise supporting smaller cultural organisations with tools, practice, and community to develop deeper public engagement with their photography collections." (Copyright: © 2023 Flickr Foundation Foundation, subject to a Creative Commons Attribution 4.0 International License.) which essentially acts as if they created a groundbreaking and innovative idea... In 2008, meanwhile the Wikimedia Commons was launched in 2004. But this further proves to me that in the eyes of most of the world "The Wikimedia Commons does not exist", I wrote before about how when people look for free image sources they rarely list this website and even a large amount of users here think that media files here only exist to serve Wikipedia and other Wikimedia websites rather than the world. I also noticed that a lot of government and GLAM institutions have accounts over at Flickr but I can't think of that many here, the Swiss National Library comes to mind an institution which has 32,100 contributions here as of writing this and a few German museums. Anyhow, the Flickr2Commons tool is in bad need of being adopted and the software needs regular maintenance (just like a lot of other tools here), I just find it sad that the Wikimedia Foundation (WMF) isn't willing to bring this level of support to the Wikimedia Commons. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 07:57, 2 June 2023 (UTC)Reply[reply]
  • “I just find it sad that the Wikimedia Foundation (WMF) isn't willing to bring this level of support to the Wikimedia Commons.” +1. Seeing the number of bugs and technical issues, Commons really needs more maintenance and development time and manpower from the WMF. Yann (talk) 08:16, 2 June 2023 (UTC)Reply[reply]
I read through issues Phabricator sometimes just for the heck of it and I'm always surprised by how much it's neglected even on there. I assume the comment above about how most people either don't know this site exists or if they do are under the false impression it's an extension of Wikipedia probably has a lot to do with it. I've definitely found that to be true the few times I've discussed Commons with people IRL. I don't think the WMF did or does a good job of clearly differentiating it from Wikipedia like they do with Wikidata. Since it's clearly a separate, unique product compared to Wikipedia and Commons even though it interacts with both of them. --Adamant1 (talk) 08:39, 2 June 2023 (UTC)Reply[reply]
I've asked a member of Wikimedia Germany (WMDE), an organisation I think is technically as beneficial as the Wikimedia Foundation (WMF) for a number of Wikimedia websites like Wikidata, and they've brought up that they will discuss adding more support, but I don't think that Wikimedia Germany (WMDE) will bring much support here until Wikidata is developed to a level where it doesn't need much maintenance and is easily useable by basically any website (which could take years), the Flickr Foundation stepping in here is actually a good thing, maybe it might be wise to ask if they could establish like some sort of "liaison office" or something at the Wikimedia Commons for communications between us and to them. Likewise, we're not aware of any discussions between the Wikimedia Foundation (WMF) and the Flickr Foundation because the former doesn't really publish all of its external communications online (due to a lack of transparency).
Flickr has 60.000.000+ daily users, we have 40,779 active users (Users who have performed an action in the last 30 days). To me it makes sense that GLAM organisations and governments prefer to publish there, but I think that increased co-operation between us and the Flickr Foundation could be mutually beneficial and I'm glad that the Flickr Foundation acknowledges that (even if this website itself is largely neglected by the WMF).
Unrelated, but I was thinking of organising some outreach to developer communities, perhaps there are people who'd love to contribute to the technical capabilities of Wikimedia websites but aren't even aware that they could contribute as volunteers. If we remain an insular community we won't see much growth beyond the capabilities of the current volunteers. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:33, 2 June 2023 (UTC)Reply[reply]
I do not think that Flickr has 60 Million files uploaded every day. I think the daily users are the page visits. Commons has around 35 Million page visits per day. GPSLeo (talk) 14:25, 2 June 2023 (UTC)Reply[reply]
Hi Donald - just to be clear, the Flickr Foundation is a separate formal, legal organization from Flickr Inc (and SmugMug) and does not share engineering resources. It is also not governed directly by either of those companies, though we do have a company representative on our board (which we are absolutely fine with and welcome). We worked the design and engineering group at the company to improve the Flickr Commons page that lives on flickr.com, as we are not able to change the core Flickr codebase directly. I hope that clears up why we called that work a collaboration?
I also don't think it's unreasonable to claim that Flickr Commons was a groundbreaking program when it launched. In particular, its use of the "no known copyright restrictions" assertion borrowed from the Library of Congress allowed a lot of our cultural organizations around the world to release photographs they previously may have kept hidden due to unknown or undocumented provenance.
I think the less we see WMC and Flickr Commons as competing, and the more we try to collaborate between the two platforms, as we hope to do by adopting the Flickr2Commons software, the better off we'll all be. Ukglo (talk) 14:34, 2 June 2023 (UTC)Reply[reply]
Ukglo, thank you for your reply.
I very much agree with the idea that Flickr and the Wikimedia Commons aren't competitors, the goal of both websites is share visual information and make it shareable, though the Wikimedia Commons requires these media resources to have educational value and also allows for books and audio as well as other non-visual works to be uploaded.
But thank you for clearing up the difference between the Flickr Foundation and SmugMug, I mistakenly believed that the Flickr Foundation was just a subsidiary of SmugMug but now I know that it is a separate entity. And in light of what you wrote regarding the Flickr Commons I must agree with calling it groundbreaking, especially since Flickr has a better outreach to GLAM and government organisations than the Wikimedia Foundation has, so a lot of valuable archival materials found on Flickr aren't found anywhere else on the internet, my personal opinion regarding this is that the Wikimedia Commons should be "an extra back-up" for these valuable files to maximise the chances that future generations will have access to them. We had a wonderful user called "Fæ" (who is also active contributing to Flickr - Desktop) who did a lot of work in this area. I am looking forward to see a closer relationship between the Flickr Foundation and the Wikimedia Commons in the future. Face-smile.svg— Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:42, 2 June 2023 (UTC)Reply[reply]
Hello! I’m George, Executive Director at the Flickr Foundation. I’m really glad to see there’s interest in this work. The Flickr Foundation wants to adopt a tool that’s useful for both Flickr and WP communities and figure out how to care for it in the long term. I have met Magnus Manske and Frank Schulenberg to talk about it, and we’re looking forward to connecting with the wider community when our project kicks off. The WMF folks suggested we create an on-wiki page for the project so that’ll be a good spot to say hi if you’re interested. Ukglo (talk) 14:28, 2 June 2023 (UTC)Reply[reply]
Ukglo, perhaps there could be a page like "Commons:Flickr Foundation" with subpages like "Commons:Flickr Foundation/Flickypedia" and the latter can also have subpages for documentation (of the software development), feedback / bug report, Etc. While another page named something like "Commons:Flickr Foundation/Outreach could be for direct communications to and from the Flickr Foundation with the Wikimedia Commons concerning its partnership with the community.
I'd also suggest creating specific "in role" Wikimedia SUL accounts for Flickr Foundation staff like "User:John Doe (Flickr Foundation)" and "User:Jane Doe (Flickr Foundation)" or using your on-wiki names like "User:Ukglo (Flickr Foundation)" and then work together with the Wikimedia Foundation (WMF) to blacklist potential bad actors from registering names with such accounts unless they are certified staff, though I'm not sure to what extent this partnership will be, but such accounts could be easily identifiable as Flickr Foundation staff and I've seen some Wikipedian-in-residence accounts name themselves with the name of the institution they work for / with when acting in the role of a Wikipedian-in-residence.
I think that if such consensus exists the community here could create those pages and make it easy to maintain and interact with for your foundation. Lay out a red carpet, as you will. Face-smile.svg— Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:07, 2 June 2023 (UTC)Reply[reply]
@Donald Trung That sounds really great! I know the WMF folks are keen to be involved in the project pages' config, so I'll make sure they've seen your suggestions here. Ukglo (talk) 09:28, 3 June 2023 (UTC)Reply[reply]

oh good, I guess? at least it gets improved. SeichanGant (talk) 19:07, 3 June 2023 (UTC)Reply[reply]

Response from the Wikimedia Foundation[edit]

Thanks for your candid discussions about the Flickr Foundation’s announcement of their partnership with the Wikimedia Foundation. The Flickr Foundation is a newly created 501(c)(3) dedicated to “preserving our shared visual commons for future generations.” It is exciting that they have prioritized collaboration with the Wikimedia movement for this mission.

As previewed in our 2023-24 annual plan, we’re supporting the Flickr Foundation to explore a simpler Wikimedia Commons contribution experience for their photographers and cultural institutions. One of their first proposals is to maintain the Flickr2Commons tool, originally developed by Magnus Manske. ('Flickypedia' is the name they have given to the re-release of this tool.) They consulted Magnus and he is supportive.

It has been challenging for Wikimedia volunteers to maintain all of the essential tools for Commons and we’re happy that one of our open culture allies, the Flickr Foundation, would like to ‘adopt’ this important tool as part of their wider preservation effort.

Alongside this technical work, the Flickr Foundation will be researching the reuse impact of the images that have already traveled from Flickr to Wikimedia. They will also be reviewing their licenses and examining how they transfer to other platforms. The often-discussed issue of ‘license laundering’ or ‘Flickr washing’ is one of the central questions they plan to address. Consultation with the Wikimedia Commons community will be an important part of this process.

We want to reassure you that the Wikimedia Foundation remains committed to supporting and developing Wikimedia Commons. In 2023-24, our product teams will be developing more reliable and usable metrics for Commons and improved moderation workflows on Commons. You can follow that work on the WMF support for Commons page, where we’ll also post updates on the Flickr Foundation collaboration.

Please continue to share your ideas, concerns, and questions—we are here to listen, learn, and take action. We value your engagement and look forward to continued collaboration. Udehb-WMF (talk) 14:14, 2 June 2023 (UTC)Reply[reply]

@Udehb-WMF @Ukglo: How about this: Flickr creates a way to import license templates from commons.wikimedia. If acflickr user wants them "own" license, the user can create a newicense template at commons.wikimedia and if it conforms to the standardscof a free license, it can be imported to Flickr.
+: how about Flickr adopts not only flickr2commons, but also video2commons and croptool? C.Suthorn (@[email protected]) (talk) 15:41, 2 June 2023 (UTC)Reply[reply]
Not sure if this is the right discussion to discuss this, but I actually have an idea for "Flickr2Commons Black" / "Flickypedia Black" where trusted users could override the Flickr license-washing blacklist for uploaders who use wrong licenses and add the proper licenses. For example Flickr user "Manhhai" has 141,005 photos on Flickr! of Vietnamese history but he's blacklisted here because he uploads files with wrong licenses, for example he lists them as freely licensed when they're not or "Copyright ©️ - All rights reserved" when they are in the public domain. Because of this literally tens of thousands of public domain images of Vietnamese history cannot be imported to the Wikimedia Commons, but if a "Flickr2Commons Black" / "Flickypedia Black" exists where Wikimedia Commons users with proven knowledge of copyright ©️ could add proper licenses (for example "{{PD-Vietnam}}" for photographs published before 1948 in the case of this uploader) then this could go through a separate process and a human would have to review them rather than a bot. This feature would only be exclusive to users who request access to it and explain which albums they want to import and why they are incorrectly licensed and which licenses they would add and then that specific user would be whitelisted for specific Flickr accounts / albums. Or should something like this be proposed at the proposals village pump? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:14, 2 June 2023 (UTC)Reply[reply]
@Udehb-WMF: If you get to talk with the Flickr folks again, can you tell them that the nicest thing they could do for Wikimedia Commons would be to get Flickr to update their ancient Creative Commons 2.0 licenses to the current 4.0 licenses? The 2.0 licenses have lots of problems and are much easier to use for copyright trolling. The 4.0 licenses came out 10 years ago, so it's ridiculous that Flickr still doesn't use them. Nosferattus (talk) 05:03, 3 June 2023 (UTC)Reply[reply]
Thanks for all these suggestions - let's make sure they're migrated to the project pages we're planning to set up as we build out the adoption project. (I am inexperienced with having detailed discussions in the Wikiverse UIs, so please excuse me as I get situated.) Ukglo (talk) 09:34, 3 June 2023 (UTC)Reply[reply]
@Ukglo Commons.wikimedia is supposed to contain exactly one copy of each media file (defined by its message digest hash). But duplicates are uploaded (200 in the last 8 hours). Most duplicates come from flickr2commons. f2c duplicate check ist based on the filename, not the message digest. That is probably the most urgent issue with f2c. C.Suthorn (@[email protected]) (talk) 07:39, 4 June 2023 (UTC)Reply[reply]
Thanks! That's helpful to know. Let's make sure it's noted in our project page once it's up. Do you know if/how it's possible for an external service to ping the message digest? Ukglo (talk) 11:22, 5 June 2023 (UTC)Reply[reply]
I'm sorry but there appear to be more than two things under discussion here, and some of the PR language isn't clear.
The announcement is about a tool that WMF editors developed in-house to transfer Flickr photos to Wikimedia Commons. It shall be renamed "Flickypedia". So far so good?
Flickr, or its Foundation, also runs a Commons with an exclusive membership, such as libraries and archives. While the Foundation has made this announcement, I can't discern any direct link to Flickr Commons, so far. Flickypedia, née Flickr2Commons, has been a tool to feed into Wikimedia Commons only, and not Flickr Commons.
A few things are unclear at this point:
  • the term "adoption" is not really defined, so since Flickr2Commons is GPL-2.0+, is it safe to assume that this means "we're taking over development, support and maintenance without a fork"?
  • does Flickr intend to extend the software tool to transfer images from their partners to Flickr Commons as well? Judging from the move to remove "Commons" branding, that may be a "no".
Elizium23 (talk) 20:44, 3 June 2023 (UTC)Reply[reply]
Thanks for these questions - it's really helpful to hear what's confusing so we can clarify our PR!
  1. Flickr Commons is a program that started in the flickr.com universe in 2008. The new Flickr Foundation (flickr.org) has taken over managing it now, even though the content published into it will still live on flickr.com. "Managing it" means looking after the members, encouraging growth. It's not directly connected into Flickypedia, or the concept of it, although we've heard again and again that it's difficult for Flickr Commons member institutions when their Flickr photos are hoovered into the Wikimedia Commons because they lose track of them and/or it's another place they have to watch/manage/maintain. As the Flickr Foundation, we're very interested in the concept of "content mobility" in general - as in, how can we know/watch/listen for activity that happens on digital copies of the same image, and report back?
  2. Adoption - good question! Honestly, I hadn't thought that far! I'd imagined that it would be a fork, as there will be some people out there who may be happy using Flickr2Commons and don't want to change(?). Or, perhaps we could do a "programmed retirement" of Flickr2Commons. Or, we could just fork, rename and be done with it. Which is better for the community, do you think?
  3. Extend to "transfer from their partners" - Sorry, I'm not 100% sure what you mean by this... but, for the first few iterations of Flickypedia, I have in mind that the transmission would only be from Flickr into WM Commons, so "partners" would need to publish to Flickr first... is that what you meant?
Ukglo (talk) 11:30, 5 June 2023 (UTC)Reply[reply]

SyntaxError: invalid assignment left-hand side[edit]

I get the red warning box on ever page load with the message "SyntaxError: invalid assignment left-hand side". Did I broke something through my userscript, is there a gadget broken or is there a general MediaWiki bug and everyone gets this error? --GPSLeo (talk) 19:09, 1 June 2023 (UTC)Reply[reply]

I do not get such an error. You can try disabling scripts in your common.js file. Ruslik (talk) 19:54, 1 June 2023 (UTC)Reply[reply]

June 02[edit]

Big gap for structured_data[edit]

big gap

Big gap for structured_data when you click on it from any entry. The gap is between the header and the listed data, it wasn't this way yesterday. Anyone else see it? --RAN (talk) 00:15, 2 June 2023 (UTC)Reply[reply]

Not sure what you're talking about. You should always provide an example. Multichill (talk) 18:33, 2 June 2023 (UTC)Reply[reply]
It is on every Wikidata entry, just look at anyone. --RAN (talk) 23:24, 2 June 2023 (UTC)Reply[reply]
I see it too. I see a large area of white space in two places. When on the 'File info' tab, below 'Metadata' and before Categories. When on the 'Structured data' tab, it is immediately below the tab headings. I have noticed it under the 'File info' tab for a few days, I think. Nurg (talk) 22:29, 2 June 2023 (UTC)Reply[reply]
I use Monobook with cats on top and cannot see that gap anywhere — sorry guys… -- Tuválkin ✉ ✇ 01:33, 3 June 2023 (UTC)Reply[reply]
My usual browser is Chrome on Windows 10 Home version 22H2, and usual skin is Vector Legacy. I get the large white space with Vector Legacy, Vector (2022), and MonoBook. I tried Edge browser and get the same when logged out and when logged in (Vector Legacy). But, when I try Firefox, the problem does not happen, neither when logged out nor when logged in. I am on the latest versions of Chrome and Firefox. Nurg (talk) 23:02, 4 June 2023 (UTC)Reply[reply]

Photographing glass[edit]

Vintage vinegar bottle

I had difficulty photographing this etched glass bottle; in the end I resorted to taking it outside and using natural light.

In the absence of professional studio equipment, how else could it be photographed? Do we have a dedicated noticeboard or other page for exchanging photography tips? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:56, 2 June 2023 (UTC)Reply[reply]

In my experience, mainly a matter of lighting, and sometimes lens filters (especially a polarizing filter, sometimes just a "sky" filter). No generic answer, but those are the variables to play with. - Jmabel ! talk 21:31, 2 June 2023 (UTC)Reply[reply]

Photo challenge April results[edit]

Looking up: Entries • Votes • Scores
Rank 1 2 3
image Pylon 1402-0112.jpg 0519 -France - Nice - Corner Rue de l'Abbaye and Rue Saint Vincent - looking up - HDR - VP.jpg Ballonwettbewerb.jpg
Title Pylon of high-voltage
line crossing Elbe
River at Hetlinger Schanze
near Hamburg, Germany		 Street corner in Nice's old town Ballonwettbewerb
Author Mozzihh Virtual-Pano Mensch01
Score 13 12 12
Baby farm animals: Entries • Votes • Scores
Rank 1 2 2
image NU-Akt15 Deichschaf-mit-Lamm.jpg Baby-Bauernhoftiere 004 2017 06 27.jpg Baby alpacas of a Quechua Family (Huaman Quispe farm) - Alpacas bebes - Paqucha uña Nuñoa llaqtamanta - Huaman Quispe farm.jpg
Title Sheep with lamb, lying on a dyke, which
they graze as dyke sheep for erosion
control, Schleswig-Holstein, Germany		 Poitou donkey foal (Equus asinus)
in the Lüneburg Heath Wildlife Park		 Baby alpacas of a Quechua Family
(Huaman Quispe farm) - Alpacas bebes -
Paqucha uña Nuñoa llaqtamanta
Author Lusi Lindwurm F. Riedelio Elwinlhq
Score 16 13 13

Congratulations to Mozzihh, Virtual-Pano, Mensch01, Lusi Lindwurm, F. Riedelio and Elwinlhq. -- Jarekt (talk) 19:26, 2 June 2023 (UTC)Reply[reply]

June 03[edit]

Category:Surnames (flat list)[edit]

What is the difference between Category:Surnames (flat list) and Category:Surnames? Both are alphabetized lists. RAN (talk) 00:11, 3 June 2023 (UTC)Reply[reply]

Paging @JotaCartas, who's been busy with page moves and mass-adds. Elizium23 (talk) 01:55, 3 June 2023 (UTC)Reply[reply]
Oh, I see, a flat_list has no subcategories, so is a true list of all surnames. Very good idea. Kudos to JotaCartas for using his valuable time on this project. --RAN (talk) 02:14, 3 June 2023 (UTC)Reply[reply]
Is this a work-in-progress, then? They seem to currently have the same content; Category:Aas (surname) has subcats Category:Monrad-Aas (surname) and Category:Wessel-Aas (surname) and yet they're all included in both the flat list, so will these latter types be weeded out of the hierarchical version? Elizium23 (talk) 02:28, 3 June 2023 (UTC)Reply[reply]
Definitely work in progress. Should presumably end up parallel to Category:Ships by name (flat list) and Category:Ships by name. - Jmabel ! talk 04:30, 3 June 2023 (UTC)Reply[reply]
I confess. I created the "Surnames (flat list)" without getting any consensus (my first mistake). It was very helpful in helping me to populate "Surnames" category with about 105,000 missing surnames (red links). After that I deleted it (my second mistake?). Later, someone "recreated" the category and instead of removing about 160,000 members, I populated it with all the members of Category "Surnames". So both categories are now identical. Really, I'm not sure if we should change the "Surnames" category to be a "normal" category, so I will not take any further action for the time being, unless some meaningful consensus is reached
In fact, even if the "Surnames" category only keeps "orphan" surnames (without any other categorization), that would leave about 160,000 members out of 200,000. Also, the only valid subcategories are within "Surnames by Language", as nearly all others have been contested. Moreover, the "by language" categorization is recurrently contested, so I think the 160.000 number is unlikely to go down. Thanks and sorry for the big mess I created here. --JotaCartas (talk) 11:20, 3 June 2023 (UTC)Reply[reply]
FWIW, I think it's the flat list that is most useful. If we want to turn into a flat list, fine with me, but obviously not if we want to keep any of the subcats that are not simply surnames. If we want to keep Category:Surnames (flat list), fine, and then the ships are the obvious model. - Jmabel ! talk 15:01, 3 June 2023 (UTC)Reply[reply]

Can anyone detect a studio name?[edit]

https://upload.wikimedia.org/wikipedia/commons/archive/0/08/20230603020117%21Ulrich_Willamowitz_1908_appox.jpg RAN (talk) 02:09, 3 June 2023 (UTC)Reply[reply]

The text in lower right says "jegliche nachbildung verboten" - any reproduction prohibited. Abzeronow (talk) 20:37, 3 June 2023 (UTC)Reply[reply]

File:IMG-20230603-WA0005.jpg[edit]

The file name indicates that it is not actually an own work, but is received via WhatsApp. I'm not sure appropriate licensing is used here. It is cascade protected because it is visible on English Wikipedia main page In The News. Ping @BishnuCharanSahoo1963. —‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:30, 3 June 2023 (UTC)Reply[reply]

Issue about Template:Lle[edit]

{{Lle}} has some issues. When I use {{subst:lle}}, it outputs language links in disorder and removes some links such as Japanese and Portuguese. This is very inconvenient for users. --TKsdik8900 (talk) 08:54, 3 June 2023 (UTC)Reply[reply]

@TKsdik8900: I'd suggest looking through the template history and pinging the users who have done significant work on the template. Otherwise, it would be sheer dumb luck for anyone knowledgeable to see this. - Jmabel ! talk 15:05, 3 June 2023 (UTC)Reply[reply]
@TKsdik8900: I looked at your edit history and I see you worked on Template:Speedynote/lang. I used the template.
It's not disordered, just not ordered by language code, but by language name instead, but you already knew that
When I use the template I see both Japanese and Portuguese, the two Chinese variants (zh-hans & zh-hant) do get lost. I looked into the code: Warning: This page contains too many expensive parser function calls. It should have less than 500 calls, there are now 564 calls. So the last 64 languages are silently dropped. Multichill (talk) 18:08, 3 June 2023 (UTC)Reply[reply]

Let uploaders see what metadata is present as they're uploading[edit]

When someone uploads a file, there is a warning: "Personal data: EXIF metadata in this file may contain location or other personal data automatically added by your camera. Learn more about how to edit or remove EXIF metadata." This implies the file the user is uploading contains such identifying metadata and that a privacy-minded user would be better off not uploading that file ... when in fact that file may not actually contain any identifying metadata. After it's been uploaded, the File: page has a collapsed box at the bottom listing the metadata, which is often just the image resolution or other non-identifying things. Can we show users this metadata information at some point during the upload process, so they can a) decide "oh, that's fine, dots-per-inch data is not identifying" and not be scared off from uploading the file, and/or b) notice when a file does have identifying metadata and go use one of the linked Exif removal tools on it before uploading it? -sche (talk) 16:33, 3 June 2023 (UTC)Reply[reply]

That would be possible for example in the UploadWizard before the publish stage. The metadata is stored in a field in the database and it actually gets sent to the client after assembling. The client only needs to actually display it (and maybe some formating from JSON to pretty).
Cave: The metadata entry in the file description page does NOT show all metadata that was uploaded. AND: The selection of displayed metadata fields differs by file type! C.Suthorn (@[email protected]) (talk) 16:51, 3 June 2023 (UTC)Reply[reply]
I very much support the suggested change, or something along the same lines. The warning is very confusing. When I in fact have tried to remove the metadata (using "exiv2 delete") I still get the warning. The natural interpretation is that my tool was deficient and some metadata is left. Is this the case?
I think the tool should identify some common non-identifying fields and leave out the warning if only those are listed. For fields such as location, camera model and copyright owner, it should note their presens and link to a discussion on privacy risks. For unknown text fields it could list the content (with a similar link), for unknown binary fields it should note their presence and link to a discussion (the discussion links could be to a single page, with the categories clearly identified, as sections or otherwise).
–LPfi (talk) 16:55, 4 June 2023 (UTC)Reply[reply]

June 04[edit]

Campaign editing help[edit]

Can a well-accustomed campaign editor help me in properly utilizing the beforeActive, whileActive and afterActive arguments? I've read this page but I still don't feel confident enough and I'm looking for someone to give me an actual example in one of my already created campaigns so I can replicate that in other ones later. Thank you in advance! Face-smile.svg— Klein Muçi (talk) 08:47, 4 June 2023 (UTC)Reply[reply]

Johnrogershousemay2020.webp[edit]

Johnrogershousemay2020.webp is the only upload and the only edit of a user to english wikipedia. It is used in the John Rogers article and in the webp article in many languages. It is also used as an example webp image in websites all over the internet. It comes without Exif data and has the typical dimensions of an image from the web, not from a camera. Nevertheless the user claims it as own work. Either it is actually a free image, that was promoted as webp example image and found its way to wikipedia. In that case, the attribution of the file has to be corrected. Or it is a COPYVIO and has made its way from wikipedia all over the internet and needs to be deleted. Because of the large numnber of uses in the internet, I cannot know how to find out and what to do. C.Suthorn (@[email protected]) (talk) 10:56, 4 June 2023 (UTC)Reply[reply]

Convenience link: File:Johnrogershousemay2020.webp. - Jmabel ! talk 15:03, 4 June 2023 (UTC)Reply[reply]

Continuation of Commons:Village pump/Archive/2023/05#About Category:Uses of Wikidata Infobox with no image[edit]

@Richard Arthur Norton (1958- ) and Jmabel: Continuation of Commons:Village pump/Archive/2023/05#About Category:Uses of Wikidata Infobox with no image: I get complaints about this solution: an error in red appears on Wikipedia pages with an infobox like the one on w:nl:Thomas de Keyser (now resolved by reversing my edit on d:Q932263; see d:Talk:Q932263 for details). Do you know another solution? JopkeB (talk) 15:52, 4 June 2023 (UTC)Reply[reply]

@JopkeB: I've never seen the error, and since the only example you give me is one that is now fixed, I have no idea what the error would look like. That said: sounds like a problem in the template, not the data. - Jmabel ! talk 20:34, 4 June 2023 (UTC)Reply[reply]
@Jmabel: Thanks for your reaction and diagnosis. I have asked for an update of the template on the Dutch Wikipedia and hope this problem will be solved soon. JopkeB (talk) 04:53, 5 June 2023 (UTC)Reply[reply]

June 05[edit]

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