This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
@RZuo: : That's an easy addition to the daily routine of my bot, which scans all new uploads and is approved to perform general updates. I would prefer the template approach: So change to: {{From Youtube|VVf9IrVGHSo}}. Could you please give an example file that I can use for testing? Schlurcher (talk) 08:27, 21 June 2023 (UTC)
@RZuo: : Done The search is now empty. I've also added this to the daily routine of my bot that scans all new uploads. So this will also be fixed prospectively. Best regards. Sidenote: These type of request are usually better placed at Commons:Bots/Work requests which I have on my watchlist, I found it here only by chance. --Schlurcher (talk) 07:18, 23 June 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --Schlurcher (talk) 07:18, 23 June 2023 (UTC)
Deletion / delinking of bogus files
https://commons.wikimedia.org/w/index.php?title=Commons:Administrators%27_noticeboard/User_problems&oldid=772344694#User:Reywas92 this discussion brings up a recurrent problem (which i have also experienced quite often). even if misuse of bogus files is evident, users have to go to every single wiki to manually remove all usage before such files could be deleted because of COM:INUSE. even after all that has been done, often it's not guaranteed to have such files successfully deleted. as such, personally, i often let such files be and dont care even if i see hoaxes or something obviously wrong.
some rules should be established to enable deletion or at least delinking of files that have been proved bogus/fictional with strong evidence. RZuo (talk) 22:39, 8 June 2023 (UTC)
RZuo, I think that this is a good idea in principle, I'd also say that we need to have a policy that fictional flags should only be placed in categories like "Fictional flags of X" and then removed from other categories. Often fictional flags are attributed to real sources, so it wouldn't make sense to delete them as they do have an educational value, but they shouldn't be used in contexts where they might misinform the readers. I think that we should probably also have an additional policy that states that these flags should have "Alleged", "Proposed", "Misattributed", or "Fictional" in their titles. This would clear up confusion. Let's say someone who doesn't know anything about flags but does know a lot about military history sees "Fictional flag of Blablaland " added to an article they would immediately remove it, but a fictional flag that isn't market as fictional will commonly fly under the radar. Several list of flags at Wikipedia also contain lists of fake flags and explains why they're false, so deletion isn't the answer but we should be able to make sure that such files aren't used in contexts where they spread misinformation. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:47, 8 June 2023 (UTC)
i think it can be simplified this way: if a file is used to make a false claim, then such usage is bogus. for example, using a fake flag to explain the concept of a fake flag is justified, but using a fake flag as a real national flag would be bogus.--RZuo (talk) 23:04, 8 June 2023 (UTC)
"Often fictional flags are attributed to real sources" Are we looking at the same files? The vast majority of fictional flags i see are pretty much the authors own creation Trade (talk) 00:14, 9 June 2023 (UTC)
The term "proposed" implies that there have been organized efforts to get the flag recognized as official. I will be very careful with how it's used in titles Trade (talk) 00:15, 9 June 2023 (UTC)
Here are several issues that shouldn't get mixed up, although they might be intertwined.
We might want to allow renaming of a file to include a note on it being bogus by some definition (a list of suggested wordings is useful).
I don't think a bogus file should be overwritten with a correct one. Combining different files in the same file history is very confusing. The suggestion reminds me of the Union Jack and Tricolor discussions and edit wars. In cases like the example given, use a redirect if there is disagreement on which flag is correct – or always, as such disagreement may surface later on some detail, or the official flag may be changed and some uses will be for the historic one.
Proving something bogus "with strong evidence" is problematic. Usually, for contested files, there is an edit war between persons who all think there is strong evidence their way. Better mark the file as disputed.
Allowing "unlinking" a file is suggested. I assume that is meant to mean that we from Commons would go to projects in languages we don't know and remove the file. This is very much against the spirit of INUSE, and very problematic.
Instead, we could create a script that makes a note on any page using the file (translated, with a good edit summary), run when {{Fact disputed}} is added to a file description page. Leave the rest to the individual project.
A guideline on categories for fictional flags could be useful, but this doesn't help with disputed flags, and I assume there might be problems with the "only" wording (cf the discussion on sexual images).
point 4: a troll doesnt need to speak a language before s/he puts a file on a wiki in that language. s/he can also claim any level of proficiency in that language but it's impossible to verify. then other users are fucked. you dont speak that language; you cant find anyone who can speak that language so you cannot verify the troll's claim of proficiency; in the end you cannot do anything about the file put up on a deserted wiki.
this is not fiction. how many scots speakers are there in the world? 100k? but how many years went by before en:Scots_Wikipedia#Controversy was busted? how many more languages have fewer speakers than scots but have their wikis?
then there're those wikis that fell into the hands of a small group of trolls.
in the end, commons just becomes a haven of self-promoting / spamming trolls, as the current rules stand. RZuo (talk) 11:01, 9 June 2023 (UTC)
That's a problem with deserted wikis. On the other hand, a file that is shown only in a deserted wiki and on Commons probably doesn't get that many views. Having a few thousand odd out-of-scope images isn't that big a problem. I assume they drown in similar images not uploaded by trolls that just nobody has found and nominated for deletion. If Wikipedia in w:Akan has a bogus Hawaiian flag, bad for monolingual Akan speakers, but not really what Commons should worry about. A troll adding such images all over will soon get banned and I suppose stewards could revert their edits. –LPfi (talk) 05:20, 10 June 2023 (UTC)
obviously this user had no experience. i call that bullshit.
i literally reported a vandal, who created a dozen garbage pages using machine translation in a small wiki, to meta. stewards just dont care. the only way to get anything fixed is to wait until someone, who does speak that language and become active at wikipedia, appears.
trolls can roam free and hold out in any small wiki without proper administration (including wikis that only have crooked sysops). say they add a fake flag to a small wiki and enwp. on enwp it's easy to handle it, but they dont vandalise there so they dont get blocked, but on the small wiki they keep putting the file up and saying users attempting to remove it know nothing about blah blah blah. stewards seeing two sides arguing would just throw their hands up and leave.
commons as a repository for all wikis are constantly affected by these problems in small wikis. i could literally hijack any one, prop up an article about a microstate in new york city, upload flags and symbols and categorise them under cat:New York City. anyone attempting to get rid of the hoaxes has to first deal with the small wikis. nyc is easy for explaining why those things are hoaxes, but imagine swapping nyc with any less know places in countries that have very few wiki users. here is a case that happened on a big wiki: Commons:Deletion requests/Files uploaded by 折毛.
as the current rules are, i have no interest in fixing anything even when i see blatant problems, because i know the existence of many users ready to defend bullshit they have no idea about makes it impossible to get anything done. one doesnt even need to look far for real examples of what i say: en:List of active separatist movements in Asia has plenty of fake stuff. RZuo (talk) 12:16, 10 June 2023 (UTC)
Modify Special:Upload to mention bigChunkedUpload.js
if someone wants to overwrite a file with something bigger than 100 MB, there's no info on the page about how, except importing it from a url which has a higher limit of 4 GB.
Is there a reason why this tool is not a gadget? I think we should make it a gadget first and then mention it on that page. GPSLeo (talk) 05:36, 10 June 2023 (UTC)
Not sure about referencing a user script, but it should reference Commons:Chunked uploads, or Commons:Upload Wizard (which does not have the 100MB limitation), or link to Commons:Maximum file size for further information. The "Upload file" link in the sidebar does go directly to the wizard, so the link you have is more for the original interface which had more limitations. But sure, pointers to alternatives should be mentioned there, I think. Carl Lindberg (talk) 15:54, 10 June 2023 (UTC)
"if someone wants to overwrite a file".
User:Rillke/bigChunkedUpload.js is the only solution i know of for this kind of upload. if mediawiki has something, ofc it should link there, but afaik it doesnt. RZuo (talk) 22:11, 10 June 2023 (UTC)
I would be very hesitant to change the meaning of a longstanding template. Yes, it's a redirect but that doesn't mean it isn't used, or that people won't add it in the future without noticing the change. I'd urge creating an entirely new template. - Jmabel ! talk16:13, 11 June 2023 (UTC)
The problem isn't that inexperienced users were not claiming a free license for MP3s they were uploading, it's that, in fact, they were overwhelmingly (maybe 80%?) uploading copyvios for which they were making bogus claims of "own work" and offering ostensible CC licenses to work they didn't own. - Jmabel ! talk03:34, 4 June 2023 (UTC)
There could be a point in not inducing any extra generation loss, but let's be real: there's not much audiophile goodness in a typical MP3 for us to want to preserve anyways. And you probably won't hear the difference with Opus. Artoria2e5contribs14:47, 12 June 2023 (UTC)
remove *.png and/or *.svg when identical *.jpg file exists
Occasionally, I have found that some *.jpg files in Commons are duplicated by identical *.svg or *.png files - or both. The most recent example is: File:ETTON_XIMENES.svg and File:Ettore_Ximenes_signature.png (signatures of the Italian sculptor Ettore Ximenes), both of which are duplicates of File:Ettore_Ximenes_signature.jpg, which is in the appropriate Category:Signatures_of_sculptors_from_Italy. I would just request deletion of the duplicates myself, except that I don't really know if there is some good reason for having *.svg or *.png duplicates. If they're not deleted, then I think they should be placed in the Signatures_of_sculptors_from_Italy Category, but as of now, that seems unnecessary. Please help me understand why *.png or *.svg duplicates might be useful, or let me know that they can be deleted without worry. Thanks in advance.
Seauton (talk) 18:35, 9 June 2023 (UTC)
I think the issue is less that the duplicates are actively useful than that the cleanup after removing them wastes time & effort, and is especially arduous because a redirect across file types is impossible. - Jmabel ! talk22:25, 9 June 2023 (UTC)
Dealing with multiple files types of the same image is a mostly unnecessary hassle all around. It would be cool if we could reign it in, but I don't see enough people supporting us doing so. I know at least when I've nominated duplicate images with different file types for deletion the images were just kept. So it's a less a matter of if duplicates or useful or not and more that no one is going support the duplicates being deleted. Let alone any kind of policy against people uploading them in the first place. Although if there was an actual proposal who knows. There probably needs to be one instead of just nominating individual duplicates for deletion though. --Adamant1 (talk) 01:04, 10 June 2023 (UTC)
According to official policy, files with different extensions are not "duplicate" files but rather "redundant" files. They should not be deleted without discussion. COM:DUPE
A file that has been around for a while should not be deleted. There may be off-wiki links to it.
Files that have been around for a while and have a history should be saved to preserve that history.
The files you point to are visually different. The original JPEG has a dark background in its initial upload and currently a white background. The initial upload is also a different signature, so I'd revert to the original image with the dark background. The PNG has a transparent background. The SVG is poorly cropped but otherwise visually similar to the PNG. Its size is substantially smaller. After reasonable cropping, it might be the preferred image of the three.
files with different extensions are not "duplicate" files but rather "redundant" files. How come the first template mentioned in the section of the policy for hiw to deal with Redundant files is for duplicate images then? At least going by the description of that template it seems like it's a distinction without a purpose since all it says that it can be used for "files that are exactly the same or scaled down." Which could really be either a duplicate, redundant, or both depending on how you want read into it. I don't see anywhere in the policy where it explicitly says files with different extensions aren't duplicates though and it's not like they are mutually exclusive either. Something can be both a duplicate and redundant or visa versa. Again depending on how you want to read into the policy.
Files that have been around for a while and have a history should be saved to preserve that history. Does the policy actually say that anywhere or is it just one of things that's "true" because people say it is? --Adamant1 (talk) 01:31, 10 June 2023 (UTC)
If they are the same file type, we can change to a redirect and nothing is lost. As I remarked above, you can't do that with different file types. - Jmabel ! talk14:56, 10 June 2023 (UTC)
.png files are lossless; .jpg files are lossy, and .svg files are vector and can scale up much better. They all have different uses and strengths and are not duplicates -- and almost always not redundant. In many cases we host both a .tiff and .jpg version of a file (see e.g. Category:TIFF images with categorized JPGs); the same can also be true of .png and .jpg -- they are not duplicate or redundant despite being the same image. In particular, you would never want to remove a lossless (or vector) version in favor of a lossy format like .jpg. See {{Compressed version}} and {{Archival version}} (more for photographic images). PNG and TIFF (and SVG) can be transparent, jpg cannot, which is often a consideration for things like signatures, if you need to place them on different color backgrounds. There probably are some cases though -- such as a .png or .jpg generated from an .svg; that is pretty much a duplicate. If an .svg is simply a wrapper around a bitmap and not a true vector, then there's no point to it either -- the bitmap should be the uploaded file. A .jpg version of say a logo would often be redundant if we have a sharp .png version of the same, though. But, if the .jpg had been in use in other projects in the past, keeping it can help preserve page history so often tagging with {{Superseded}} is better than deletion.
The reason why redundant mentioned at the top of COM:DUPE is that it was the most common misuse of "duplicate" -- which is a speedy deletion reason, and thus more rigid. If you believe that files are redundant, they need to go through regular deletion where you make the argument as to why (e.g. why the file format differences which usually matter don't in that particular case, if that is the redundant aspect). Deleting files does not save any disk space; you are trying to make an argument why nobody (on any project, or even off-wiki) would really ever need access to the redundant versions again. For signatures, it could even be helpful to have scans of different signatures from the same person, to get an idea of what variations there are etc. Carl Lindberg (talk) 15:39, 10 June 2023 (UTC)
I don't necessarily have an issue with "duplicate" images in cases like TIFFs that have an accompanying JPEG file. What I'm not a fan of though is when people act like it's an across the board hard and fast rule that applies in every situation when it clearly isn't and doesn't. You can't even nominate a duplicate image of the same file type for deletion without it being kept because "duplicates are fine" or whatever. Also, the fact that you can't redirect images of different files types should be dealt with by filing a bug report. That shouldn't stop people from being able to nominate redundant images for deletion if they just happen to be different file types though. Same goes for the whole thing about how thumb nails are less blurry for JPEG images then other image formats. Both should be dealt with on the software side, or if not completely ignored.
At the end of the day who cares if a thumb nail is slightly blurry? The important thing is that we don't have categories and files that are a hassle to deal with because there's a ton of redundant images. Otherwise where's the limit? There's like what, 5 main file formats for images. That doesn't include the hundreds of less popular ones. I'm sure they all have their pros and cons. Should we allow people to upload the same image in 15 different file formats or whatever just because they all have their pros and different use cases? Obviously not. So, I think we should at least draw the line somewhere. I think the cases you mentioned where the images are redundant is good, but it should really go further then that. People should also be required to have a better justification for uploading redundant images then the fact that they are essentially impossible to delete. --Adamant1 (talk) 04:25, 11 June 2023 (UTC)
Loads of people care if a thumbnail is blurry -- that goes right to how good Wikipedia articles look. JPGs are preferred for photographic type images there, as they scale better/faster/smaller. "Redundant" is an argument; if others disagree on the DR then files will usually be kept. It's easy to default to keeping, since that harms almost nothing. We don't need a PNG version of a TIFF file -- those are both lossless formats, and would be a duplicate. But there are purposes for different file formats in many/most cases, such as the one under discussion. Returning differently typed data for a file extension is a very bad idea -- MIME types etc. are often based on those, and changing the type of data returned by a URL itself is a bug, and a really bad idea. You'd have to change every bit of Internet software to not assume what type of data they are dealing with by looking at the file extension or MIME type, and instead examine the data to see what type of image it is (not always possible anyways).
The general philosophy is "more is better" -- there is no limit. The entire goal of Commons is trying to provide works for other people to use, in whatever circumstance they have. Giving people more options is our purpose. If you need to create further subcategories to make a larger one manageable, then go ahead. And one particular file is never made harder to deal with by the fact there are other similar ones. Files do get deleted for redundancy reasons, but you need good arguments -- clearly someone else did not think they were redundant, since they took time to upload them in the first place, and you are telling them their effort was worthless. You need to convince others of your argument, not be annoyed they disagree with you, since "redundant" can be very subjective. Sometimes the reason can be even subtler -- a smaller version of the same image, but with a less restrictive license, is also not redundant. Carl Lindberg (talk) 13:31, 11 June 2023 (UTC)
Loads of people care if a thumbnail is blurry -- that goes right to how good Wikipedia articles look...JPGs are preferred for photographic type images there, as they scale better/faster/smaller. That's why I said I was fine with TIFF images that have "redundant" JPEG files associated with them. At the end of the day it's still something that should ultimately be dealt with on the software side though regardless since it's not inherent to TIFF files that thumb nails of them are blurry. This isn't Wikipedia either and at the end of the day the effects the blurriness has on our end is extremely minimal. Not to say Wikipedia doesn't matter, but policies shouldn't be dictated by other projects. Nor should people who just want to organize files without it being a hassle have to forgo their feelings about it just because images from Commons are sometimes (really more like rarely if ever, but whatever) on Wikipedia and they prefer non-blurry thumbnails.
The general philosophy is "more is better" -- there is no limit. That can be the "philosophy", but it comes at the cost of the time and effort of people who are actually putting the work into organizing images. Same goes for your comment that I'm acting like the effort of people who upload redundant images is worthless by saying there should be limits. That attitude and them uploading the files to begin with treats the people who are actually organizing the files (which most of the time isn't the uploader BTW) like their time and energy doesn't matter. Or at least matters way less some uploading multiple images of the same exact thing. Personally, I don't think it's an either or thing, which is why I said I'm fine with JPEGs of TIFF files. I just think there should be reasonable rails put on it so no one's time is wasted. It's ridiculous to act like an uploaders efforts are inherently more then that of other users though. At the end of the this is a repository of freely licensed media. Nothing about that necessities us pandering to every possible niche use case out there or preferences of every random uploader who can't handle it if their personal needs aren't 100% pandered to. We do need people to organize the files though and it clearly makes that job harder to do in the meantime though. Uploaders can suck it up and only upload one or two images of the same subject. People who organize the images can't just magically create more time or energy to do their job. Nor should they be forced to just so we can pamper uploaders. --Adamant1 (talk) 20:03, 11 June 2023 (UTC)
At least SVG as a vector format is a totally different format which should be preferred e.g. for logos and similar things because of the easy and high-quality scaling it allows. Gestumblindi (talk) 11:45, 11 June 2023 (UTC)
Is anyone seriously advocating for doing that outside of maybe with images of logos assuming it's even a thing in that case? --Adamant1 (talk) 22:43, 11 June 2023 (UTC)
Oppose First in general: JPG, SVG and PNG have different use cases and potentials, none of them are innately ideal for images. SVG and PNG are optimal for "clear" graphics; JPG is great for photos. TIFF is good for lossless raw data, especially photos. In the actual case presented in the initial proposal, the SVG has ideal resolution and minimal file size. The PNG in this case doesn't make good use of the strengths of a PNG, i.e. minimization of the color palette: it could be made even smaller than the JPG, with for example just 8 colors. I can agree and Support as a general rule to not keep three files with the same content around, but there can't be a general rule that one file type is best. Keep the best two, is my suggestion. --Enyavar (talk) 14:09, 12 June 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --RZuo (talk) 19:29, 7 July 2023 (UTC)
VR Media on Commons?
As far as I know, Commons does not support virtual reality videos yet (such as this). Who should I pitch the proposal to host VR videos on Commons to? What technical limitations are there?
Proposal to create a centralised hub for Wikimedia Foundation (WMF) content, discussions, developments, office actions, communications, Etc. for the Wikimedia Commons.
I would like to propose the creation of a Wikimedia Foundation (WMF) village pump to simplify communications from and to the Wikimedia Foundation at the Wikimedia Commons, link to WMF-related discussions elsewhere, and centralise discussion about the WMF and its actions at the Wikimedia Commons.
I remember a few years ago a lot of Wikimedia Commons users being surprised by the rolling out of a number of SDC features like file captions because they weren't aware of the discussions that were occurring since 2014.
This idea would not be unprecedented as at the English-language Wikipedia there currently already is a WMF village pump, in fact the Wikimedia Commons largely mirrors the English-language Wikipedia's village pumps:
Except for the fact that we don't have a WMF village pump. Perhaps a WMF village pump could be used as a central hub for communicating developments from the WMF and getting community feedback. Ideally, the top of this WMF village pump would direct people to various pages like WMF support for Commons, SDC, WikiLegal for Commons, DMCA take-down notices, Etc.
TL;DR: Create a central hub for WMF activities, developments, and discussions at the Wikimedia Commons that people can add to their watchlists to easily be aware of the scattered developments of the WMF, use this hub to direct people to relevant WMF activities, developments, and discussions which are occurring elsewhere at the Wikimedia Commons.
What this proposal isn't'".
This proposal isn't an idea to force the WMF to communicate their ideas through only one page, rather that page would serve as a hub where they (or other volunteers) could notify the community about developments at pages like the SDC, WikiLegal, tools, Etc. but in a central (highly visible) hub in a central community space.
This proposal isn't to suggest that we unify all these discussions in one (1) central place, rather that there is a central hub where users could be notified of ongoing discussions and developments elsewhere related to the WMF, this could also include WMF discussions at the Meta-Wiki and other wiki's that concern the Wikimedia Commons.
Oppose There is not so much traffic on the Village pump that we need to move some content away. The Village pump technical already does not really work due to low traffic. If we want something separate it should be a general board for announcements like en:Wikipedia:Wikipedia Signpost or de:Wikipedia:Kurier. --GPSLeo (talk) 09:38, 3 June 2023 (UTC)
Support, this makes a lot of sense, as I often read about WMF developments but I don't know where to find them. I knew about structured data but didn't know that they had documentation and a discussion page. --SeichanGant (talk) 19:06, 3 June 2023 (UTC)
Support I wasn't solid on the idea at first but Donald Trung clarifying the purpose of board after the intial proposal leads me to believe its a useful idea. --Adamant1 (talk) 01:10, 4 June 2023 (UTC)
Perhaps it would also be wise to be a large disclaimer on the top of the village pump that it's not a WMF-run page but a community-run page, I think that the top of the page should probably just be an easy way to navigate to various specific pages of the WMF at the Wikimedia Commons. The English-language Wikipedia's version has the text "The WMF section of the village pump is a community-managed page. Editors or Wikimedia Foundation staff may post and discuss information, proposals, feedback requests, or other matters of significance to both the community and the foundation. It is intended to aid communication, understanding, and coordination between the community and the foundation, though Wikimedia Foundation currently does not consider this page to be a communication venue.", I think that this could be largely copied. Note that although the WMF doesn't acknowledge it as a communication venue, it seems that many WMF staff do watch it and sometimes post replies, something like this just greatly simplifies communications. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:57, 3 June 2023 (UTC)
@GPSLeo: , I'd argue that the issue isn't traffic, rather it's a lack of having a central place where people could be directed to the right places, nor are any of these places in a highly visible community page, this means that if something happens on one (1) WMF-related page these developments often don't reach the wider community until they have already been discussed by the small number of volunteers who were aware of it.
The issue isn't the quantity of watchers, it is rather the accessibility of these discussion to casual users who don't go out of their way to search every WMF related development, so when a discussion they find relevant to them does show it they might not be aware of it. The village pump should probably remain the main place for DMCA notices and the like, but it is quite rare for people to link every ongoing WMF discussion, this is also why several pages which could require more eyes (like the WikiLegal discussions) don't get much attention, most people don't even know that they are occurring. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:44, 3 June 2023 (UTC)
Then I misunderstood your proposal because of using the term "village pump". It is more like a "WMF announcement archive". But I still think that if we create something new we should make a combined page with WMF announcements and community announcements. GPSLeo (talk) 09:51, 3 June 2023 (UTC)
GPSLeo, This is why I suggested basing it on the English-language Wikipedia's WMF village pump, because it is largely a central hub for bringing up discussions relevant to that Wiki on specific pages, plus it is a place where developments by the WMF are announced, but it's not the place where they are discussed, rather people can find the relevant discussion pages elsewhere. In practice you often see "Please see a discussion over at X" or "New developments at Y". Now we have several scattered WMF pages and Commonswiki relevant discussions at the Meta-Wiki and other websites, but these aren't centrally placed. Occasionally we see announcements at the main village pump, but apparently not everything gets announced. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:56, 3 June 2023 (UTC)
If the page would be community run, it would still not receive notifications on more than some of the discussions. I think watchlisting the pages where the discussions actually happen (or pages that get notifications on them) is a more reliable route. A list of such pages, linked from the village pump header, could be useful. I am afraid the suggested page would just be one more page to watch, and one more page that misses many important discussions. My other concern is that there are too many discussions going on on too many pages, for anybody to keep track of them. –LPfi (talk) 09:55, 3 June 2023 (UTC)
LPfi, This page would exist specifically to simplify that by having a central hub where all these developments are listed and where people are linked to the relevant pages, the WMF village pump would contain a list / an overview of WMF pages at the top and direct people to relevant pages. As village pumps are highly visible pages newbies and users who don't request "meta-pages" could easily discover them. This page would supersede the need of keeping dozens of pages in your watchlist as long as volunteers add notifications here (which is already a proven model at Enwiki). — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:00, 3 June 2023 (UTC)
Simplified explanation of its usefulness: I realised that I didn't really articulate why such a place would be useful, a central page would be able to direct people to the relevant pages and notify them of new discussions, it would not divert discussion away from the main VP or any current WMF pages, rather it will be a directory of all these pages (preferably at the top), and it will notify users of any ongoing discussions. This would mean that if there is a discussion about SDC in one page, a new technical feature or tool support in another, and a request for community feedback about a policy in another one does not need to have each and every page in their watchlist, rather developments and discussions would all be listed in one central place to direct people to the correct venues.
Even if we had a navigational template fo "WMF topics" that would list all these pages one would still need to click on every individual page (and then sometimes even click "Talk" / "Discussion") to find if new discussions, announcements, or developments would be occuring. This page would allow for a singular notification hub for anything Commonswiki-related that the WMF does (even on the Meta-Wiki which wouldn't normally show up here). The main reason for this proposal is to reduce complexity in accessibility and increase community engagement with the WMF by letting anyone interested know where and when developments occur. I understand why the term "village pump" can be kind of misleading in this regard, but I'm just following the precedent set by the English-language Wikipedia and it would also be a good way to allow people to ask miscellaneous questions about the WMF. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:20, 3 June 2023 (UTC)
How about a centralized discussion template instead of a village pump page? I don't see the need to have a central discussion page on top of existing discussion pages, but "direct people to various pages like WMF support for Commons, SDC, WikiLegal for Commons, DMCA take-down notices, Etc" might be a good idea. I think there can be a specialized Template:Centralized discussion, which is not a discussion page, but a curated list of pointers to pages where discussions are ongoing. whym (talk) 02:50, 4 June 2023 (UTC)
Reading through this discussion about the potential creation of a WMF Village Pump for Wikimedia Commons has been enlightening. Your thoughtful insights highlight a shared commitment to improving our community's communications and transparency.
In light of this, I thought bringing up an existing resource that shares similar objectives would be beneficial: the WMF Support for Commons page. This page was created as a hub for updates and discussions related to the Foundation's activities and support for Wikimedia Commons. It's a resource with potential that could be further developed with your help.
What if we took some of the ideas expressed here and applied them to enhancing the WMF Support for Commons page? If we pooled our collective insights and efforts, we could potentially evolve this page into an even more effective hub for all WMF-related content, discussions, and developments.
I encourage each of you to visit the page and consider how your ideas could shape its future. How can we make it more accessible, more engaging, and more informative?
Udehb-WMF, in that case it might be wise to withdraw this proposal for now then, as I was under the (false) impression that that page was only a hub for the 2023-2024 projects by the Wikimedia Foundation (WMF). I will continue to add different suggestions there then. I'll draft a way to make that page (and other WMF pages) more visible through community portals then. -- — Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:25, 6 June 2023 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Question What's the use case for this? Are there actually users that should not be able to upload files, but should be able to edit the rest of Commons? The only reasons I could think of for blocking uploads is if someone didn't understand copyright or was uploading files for an abusive purpose, and neither bodes well for their continued presence on this project. The Squirrel Conspiracy (talk) 22:57, 21 June 2023 (UTC)
It's not uncommon for users to mass-upload files with no curation (OOS/copyvio mixed in, poor filenames/descriptions/categorization, etc). While usually done in good faith, it's a significant behavioral issue that causes a great deal of work for other editors and diminishes the quality of files available on Commons. Blocking from upload would stop the problematic uploads, while allowing them to properly curate the files (and, hopefully, re-earn the trust to be allowed to upload again). Pi.1415926535 (talk) 23:36, 21 June 2023 (UTC)
Support There are some people who have a habit of uploading duplicates without checking, but do an incredibly good job at copyright patrolling or being WikiGnomes that fix typos in the file namespace. Having this tool would allow us to more narrowly tailor our blocks to address problematic but good-faith editors who are productive in some areas but are disruptive with their file uploads. There isn't really anything admins lose from having this option (we are going to retain the ability to issue sitewide blocks or partial blocks from the file namespace), so I think that we will be made better off having this option than not. — Red-tailed hawk(nest)02:26, 23 June 2023 (UTC)
Support seems similar to partial blocks on Wikipedia. Blocks should be preventative and incremental. Just because someone’s an incompetent uploader doesn’t automatically mean they can’t do basic maintenance editing. Dronebogus (talk) 22:53, 23 June 2023 (UTC)
Support This seems like a reasonable stop gap when it comes to dealing with duplicate images compared to just outright blocking otherwise productive users for doing something that is mostly benign in the grand scheme of things. --Adamant1 (talk) 01:55, 24 June 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Time to recommend Opus over Vorbis
This is posted to VPP for higher traffic. When this discussion is done, please kindly drop a pointer to the archive at Commons Talk:File types.
Commons:File types#Ogg (audio) currently still states "vorbis is the preferred audio codec for the Ogg container", even though it acknowledges that Opus is better. We should really just get the recommendation changed. Like:
<!--T:58-->
Opus is the '''preferred''' audio codec for the Ogg container. Please use the file type '''oga''' to upload audio files in Ogg Opus format.<ref group="Note" name="xiphwiki">The Xiph.Org Foundation recommends using <code>.ogg</code> as the extension for Ogg Vorbis audio files, <code>.oga</code> for Ogg FLAC audio, <code>.ogv</code> for Ogg Theora video, and <code>.opus</code> for Ogg Opus audio per [https://tools.ietf.org/html/rfc5334 RFC 5334] and [https://www.rfc-editor.org/rfc/rfc7845.html RFC 7845]. See also [https://wiki.xiph.org/index.php/MIME_Types_and_File_Extensions MIME Types and File Extensions - XiphWiki].</ref>
<!--T:59-->
Opus is supported by MediaWiki ([[phab:T42193]], [[phab:T53313]]) since 2014. The format has excellent quality and low algorithmic delay. File extension: <code>.opus</code>. It automatically switches between speech and music-optimized modes and is able to combine the two. [[:en:FLAC|FLAC]] is for general audio and is lossless (quality is preserved), but current file size caps prevent its use for anything but short clips. In most cases, Opus should be used, using Xiph recommended settings.<ref group="Note" name="xiphopusrec">See [https://wiki.xiph.org/Opus_Recommended_Settings Opus Recommended Settings].</ref>
<!--T:60-->
Existing audio in other free codecs (such as Speex and Vorbis), but present in an Ogg container, should '''not''' be converted to Opus or FLAC to avoid {{w|generation loss}}.
<!--T:61-->
Note that with FLAC, a [[#FLAC|native container format exists (see below)]].
If your output file has the extension <code>.flac</code>, it is likely using the native container format.
If you like to embed it into an ogg container, this can be done with [[:en:ffmpeg|ffmpeg]] using the command line <code>ffmpeg -i InputFile.ext -acodec flac out.oga</code> or <code>flac ./input.wav -8 --ogg -f ./output.oga</code>.<ref group="Note" name="xiphwiki"/>
<!--T:62-->
It is also useless to put data in a non-free format into a free container like Ogg: you get a file, which, while requiring that a player support the free container, still requires that it support the non-free codec.
Opus is now mandatory in browsers that do WebRTC (see Opus_(audio_format)#Browser_support), so there should be no concern about compatibility whatsoever (in fact, YouTube uses Opus; oh and we transcode, so there can't be an issue at all). The bit in Commons:File_types#Ogg_Theora_(video) about browser support in 2012 will also need updating.
Support @Artoria2e5 Thanks for bringing this up. You probably won't get much feedback here either, given how under-developed anything relating to non-image media is on Commons. Unless someone actually comes up with a counter argument, I'd suggest you just go ahead and do what needs to be done. El Grafo (talk) 14:22, 28 June 2023 (UTC)
So this has come up recently with some symbols I've been uploading, where I can't speak or write Japanese, but I do have the term that describes the symbol. Since they're Japanese in origin, including a basic explanation Japanese would make sense.
However, the issue is that with Japanese kanji and other Chinese character based written languages, you can convey the name of object in as little as two or three characters.
For example: "Directional Arrow" in Japanese, is only 2 characters: " 矢印 ".
So the uploader stops you from uploading until you push it over 5 characters.
I understand why this minimum exists for most languages, but it doesn't work with Chinese character based languages, like Chinese, Japanese, Korean, Vietnamese.
Considering you have a drop down where you select the language, is it possible to set it up where if you select one of the Chinese character based languages that it lowers the threshold to like 2 or 3?
(Note: I think the phrase to describe these writing systems in broad, non specific terms, is 'Chinese character based/derived', however I'm not positive. Apologies if I've misspoken in describing it.) The Navigators (talk) 01:26, 13 June 2023 (UTC)
"Directional arrow" is a pretty lousy description in any case. This definitely doesn't apply to Vietnamese, which is written in the Latin script and has been pretty exclusively for 70 years.--Prosfilaes (talk) 02:34, 13 June 2023 (UTC)
Won't disagree that it's not the world's greatest, but it's a superior description to absolutely no description at all.
(I'm not an expert on which languages are currently using this writing style. Vietnamese listed among language that used them on the English article on Chinese characters. Honestly, only one I'm really concerned with is Japanese, as that's the one I've had an issue with. However I'm aware that Japanese isn't the only language using that writing style.--The Navigators (talk) 02:44, 13 June 2023 (UTC)
As to the directional arrow argument - it would be allowed in English and probably all latin script languages. Not allowing it in Chinese and other languages that have similar scripts is discriminatory. --Kritzolina (talk) 20:20, 15 June 2023 (UTC)
I'm definitely open to allowing more flexibility for Chinese and other derivative scripts. Directional arrow as stated above is somewhat lacking as far as a description goes, but I could conceive of a usecase for a good description in Chinese or Japanese that only uses three characters so Weak support. Abzeronow (talk) 18:38, 13 June 2023 (UTC)
As a name (of the object or the depicted person) might fit in the three characters, such a description is better than nothing, and if you don't know the language, that might be all you can write, so yes, I think I support the proposal. A warning might still be due, as proposed in the phabricator ticket, as native speakers should be able to give a more thorough description. An easy way to implement this is to count bytes instead of characters, as the UTF-8 coding (which the WMF sites use) of any such character is 3–5 bytes. –LPfi (talk) 19:15, 13 June 2023 (UTC)
Yeah, I wouldn't have an any objections to retaining/including a warning instructing to use a better/more detailed description. Or only lower the character limit when another language description is present, so that it still pushes native speakers to make a better description when it's the only language on the upload. (I don't know much about the coding of any of this, so I have no idea the difficulty in setting up the latter idea, why I went for a more simple solution, but no objection to it being a conditional item.)
Related, for the remarks about "directional arrow" (矢印) being overly vague, it was the most recent example I'd done when I wrote the request and knew it was an issue. Other examples of things where this issue appears in Japanese, are 'fire extinguisher' (消火器), 'emergency exit' (非常口), 'exit' (出口), 'telephone' (電話).-- The Navigators (talk) 02:21, 14 June 2023 (UTC)
Should this be closed as a consensus for this proposal has been reached or should this remain open longer in case anyone else wishes to comment? Abzeronow (talk) 18:43, 29 June 2023 (UTC)
I think the consensus is pretty clear. Two kanji/ideographs should be the minimum for the relevant languages. - Jmabel ! talk22:18, 29 June 2023 (UTC)
Policy change proposal: allow free depictions of copyrighted characters/fictional elements
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Basically I believe that we should allow free files that depict copyrighted characters (IE Fleischer's public domain Superman files, etc). My arguments are as follows:
Nothing about the file is copyrighted, except for an idea the notion that Superman is copyrighted in this context is based on the notion that an idea is copyrightable.. Basically, in the case of Fleischer's Superman, the cartoon is free, the version of the character is free, and the depiction is free. This means that the only thing that could possibly be copyrighted is the idea of Superman, IE this is a derivative work of an idea/concept. And as we know, ideas cannot really be copyrighted.
While the courts have upheld copyright for fictional characters, Commons practice has deviated from the courts in cases where we disagree, such as how COM:COSTUME says that the Commons community rejects the WMF's view on costumes in favor of a more lenient view based on our interpretation of the law. In this case I suggest we interpret the law based on the rule that ideas and concepts cannot be protected by copyright.
While files depicting fictional characters may have their commercial usability limited, Commons does allow files that cannot be used commercially in all contexts, such as cosplay and trademarked logos. If you used File:Spiderman and child.jpg in some commercial contexts, you could be sued, but Commons ignores that.
We could easily include a tag that informs users that the reuse of the file may have some legal constraints, as we do with template:costume and template:trademarked.
In conclusion: free depictions of "copyrighted" fictional characters should be allowed on Commons based on the facts that ideas cannot be copyrighted, we have rejected legal precedent before based on more lenient interpretations of the law, and that we do allow certain files that have limited commercial usability. Di (they-them) (talk) 21:04, 27 June 2023 (UTC)
Just a side thing, but it seems like you contradict yourself in the proposal. For instance at the top you say "Nothing about the file is copyrighted except for an idea", but then later on you comment "I suggest we interpret the law based on the rule that ideas and concepts cannot be protected by copyright." So can ideas be protected by copyright or not? --Adamant1 (talk) 21:21, 27 June 2023 (UTC)
@Adamant1: I meant to say that the notion that Superman is copyrighted in this case is based on the notion that ideas can be copyrighted. Thanks for pointing that out, I have edited my original message. Di (they-them) (talk) 21:32, 27 June 2023 (UTC)
Your argument about trademarks is wrong. The files you cite can be used for commercial purposes, but they can't be used when violating the trademark (for logos) or for claiming something on behalf of the creator. That's quite a difference. Yann (talk) 21:28, 27 June 2023 (UTC)
They can be used for commercial purposes, but their commercial usage is limited by relevant laws. This is the same case as public domain images of Superman etc. Di (they-them) (talk) 21:32, 27 June 2023 (UTC)
Oppose. "It is clear that when cartoons or movies are copyrighted, a component of that copyright protection extends to the characters themselves, to the extent that such characters are sufficiently distinctive." Warner Bros. Entm't, Inc. v. X One X Prods., 644 F.3d 584, 597 (8th Cir. 2011) (citing 7th Circuit and 9th Circuit cases). Although you say "Commons practice has deviated from the courts in cases where we disagree", the example you provide does not appear to be departure from law (as decided by multiple U.S. Courts of Appeals), but rather from a nonbinding WMF legal statement and advisory Copyright Office guidance. I am aware of no wholesale departure on Commons from legal rules decided by multiple courts of appeals. This should not be the first. —Mdaniels5757 (talk • contribs) 22:08, 27 June 2023 (UTC)
Oppose you aren’t discussing ideas of characters (whatever that means), you’re discussing concrete depictions (i.e. moving images depicting Superman). The whole argument is therefore moot. Dronebogus (talk) 23:06, 27 June 2023 (UTC)
Oppose There's no such thing as a "free file that depicts copyrighted characters", because the copyrighted characters make it unfree, see COM:DW, so there's simply no base for this proposal. You can't copyright the idea of, say, "a superhuman character" (which may be depicted in a way that doesn't look like Superman), but the specific, copyrighted character of Superman is a different thing. By the way, copyright protection is different from trademark protection. Gestumblindi (talk) 23:25, 27 June 2023 (UTC)
Oppose That might work for a character in a novel, but for a character that was in graphical form to begin with, anything close enough to be identifiably that character is going to infringe copyright. There could be a fair-use defense for parody (e.g. Mad Magazine's early Superduperman), but Commons doesn't accept images on that basis either. - Jmabel ! talk00:29, 28 June 2023 (UTC)
@Jmabel: That's true: You can depict your own vision of the character Harry Potter from the novels, like File:Harry Potter.jpg - but you can't copy the familiar appearance of a still copyrighted character from a graphic novel. Gestumblindi (talk) 10:16, 28 June 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Allow photos taken inside of train stations or tunnels in Germany
The freedom of panorama rules in Germany only cover photos taken from public accessible places. The status of train stations is disputed as there is not court decision on that question. As deleting all photos showing interiors of train stations or underground stations would highly impact articles on Wikipedia and as many stations are also cultural heritage monuments we should keep them until there is a clarification on that question. GPSLeo (talk) 19:50, 15 June 2023 (UTC)
I'd say allow, but probably tag them so that they can easily be deleted at one fell swoop if there is ever clarification and it goes against having them. - Jmabel ! talk20:13, 15 June 2023 (UTC)
As already mentioned on my talk page, this discussion has already been going on in the past few days. The fact is that the German panorama freedom does not apply to interior shots. Some may question whether subway stations count as interior shots, but even then we would have to delete the images (precautionary principle). I don't see why we should flout our own rules just because the images have been accepted to date. Lukas Beck (talk) 20:32, 15 June 2023 (UTC)
@GPSLeo: What difference to the law does it make that the train stations are "cultural heritage monuments"? As far I know objects are designed cultural heritage monuments by local "cultural authorities" who don't own the copyrights to the objects they designate and the designation has zero effect on the copyright status of the work. --Adamant1 (talk) 21:40, 15 June 2023 (UTC)
Oppose For three reasons. 1. The guidelines for Germany make it clear that shots of building interiors in Germany are not covered by FOP. Train stations "might" (and it's a big might) be covered because they are semi-public, but the problem is that experts agree places where accesses is it all restricted to the public aren't legally considered public spaces. So there's no grounds for train stations to be covered by FOP what-so-ever. Otherwise we might as well allow images taken in-side of churches, stores, Etc. Etc. At that point why even have guidelines about it?
2. I don't buy the idea that there should be a special exception for "cultural heritage monuments" in Germany because the designation is given by local "cultural authorities" who aren't legal bodies and it doesn't effect the copyright status of the works. In the meantime there's plenty of modern objects created by living artists in Germany that are designated as "cultural monuments" by local authorities. There's zero evidence that those artists gave up their copyright to the work in the process.
3. Plenty of regional historical societies designate objects of local interest as culturally important. I'm sure images of a lot of copyrighted public works in most countries can be used in Wikipedia. What's so special about Germany or German "monuments" (the word is meaningless misnomer in this context BTW) that warrants there being a special exception to the rules just for German train stations? Really, why not just allow for images of otherwise copyrighted works in general if they can be used in Wikipedia articles? Honestly, this whole thing reeks of the same German centric nonsense that occurred with the recent proposal for categories of German political parties. Which not surprisingly was started by the same user and went absolutely no where. At the end of the day there's zero legitimate reason to allow for images of artwork in German train stations. German users just have a unique issue with following the guidelines for some reason. So they think there should be special exceptions to everything for Germany. --Adamant1 (talk) 21:40, 15 June 2023 (UTC)
I'm a lot less concerned with keeping images of art than happens to be inside a German train station than with general interior shots of the stations. Even for the U.S., where F.O.P. is generally far weaker than in Germany, we allow equivalent photos. - Jmabel ! talk22:02, 15 June 2023 (UTC)
I don't really see what the difference is. At least IMO there's way more chance of a living artist suing over an image of their artwork in a train station being used in a commercial book then say the architect of the building suing someone for uploading images of a random wall in the same train station. You should look through some of the images of the stations in Germany. A lot of them are pretty generic. To the point that only locals would probably know what station it is or where exactly the image was taken if it weren't for file summaries and whatnot. Like compare these two images of the same train station, File:U-Bahnhof Steinstraße 3.jpg and File:Fußgängerunterführung Steinstraße, Mosaik von Walter Siebelist.jpg. Obviously there's much more chance of there being a legal issue with the second image then there is with the first one. The first one is barely even identifiable and there's nothing copyrightable about it anyway. --Adamant1 (talk) 22:10, 15 June 2023 (UTC)
I mentioned the cultural heritage monuments to show the importance of having these photos. It could also be relevant if you weight the interests of the architect against the freedom of press. As it is highly important we should not apply the precautionary principle but risk the legal proceeding like we did in many other cases in the past. GPSLeo (talk) 06:19, 16 June 2023 (UTC)
You might have a valid point, but Commons isn't the press. Also, I'd probably agree with you about weighing the legal risks if the Wikimedia Foundation wasn't already sued and lost in Germany over Commons hosting images of stamps. I don't think it's worth the risk in light of that and how inconsistent the German court system seems to be, which at least from my reading of things tends to be way more finicky when it comes to FOP then anything else. There was also a court case a few years ago where someone was sued in Germany and lost for commercially using an image of a train. So there's already legal precedent there when it comes to things related to trains, train stations, and the like. Granted I don't remember if the image of the train was taken in a train stations, but I don't think it matters. The Regardless, one failed law suite on our side in the German courts should really be enough. We aren't here to test the boundaries of copyright laws. I already asked on L. Beck's talk page, but why can't the images just be uploaded to German Wikipedia since (I assume) they would qualify as fair use due to being included in articles? --Adamant1 (talk) 07:01, 16 June 2023 (UTC)
And neither does a lot of other Wikipedias (German Wikipedia allows "fair use" for a limited class of images that are free by German law, or something like that).
Anyway, we don't host images unless they are free, even if they are valuable. It is not about WMF: they are quite safe as long as they take down files as soon they are asked to. The problem is with somebody publishing a book and being sued over it. Destroying the edition is costly regardless of whether they get some formal penalty.
Well that's a bummer. Not really surprising though. Regardless, I still think it's worth erring on the side of caution even if the WMF will probably be fine either way. Like the precautionary principle says "the copyright owner will not mind/should be pleased that we have disseminated their work" and similar arguments aren't a valid reason to keep works that might otherwise be copyrighted. --Adamant1 (talk) 08:08, 16 June 2023 (UTC)
Support If the law is ambiguous, we should take the more permissive side. It is not our duty to interpret the law more strictly than the courts do. We don't need to be more royal than the kings. Yann (talk) 11:22, 16 June 2023 (UTC)
Interpret it how you will, but at least according to the Act on Copyright and Related Rights Section 59(1) "It is permitted to reproduce, distribute and make available to the public works located permanently on public paths, roads or open spaces. In the case of buildings, this authorization only extends to the façade." Interiors of train stations, underground or otherwise, clearly aren't building facades. So at least going by the Act on Copyright and Related Rights it doesn't seem like there's any ambiguity what so ever about this. If nothing else there at least needs to be some kind of clarification about how the proposal jives with the law if it passes so people don't just continue to nominate images of train station interiors for deletion because the law says they aren't covered by freedom of panorama. --Adamant1 (talk) 14:07, 16 June 2023 (UTC)
I am going to be Neutral on this. While I stand by my opinion generally, I don't know enough about the details of German law to take a side. Yann (talk) 19:19, 18 June 2023 (UTC)
As I just noted in the other discussion, no one is trying to or suggesting we delete "all" images taken inside of tunnels. Just ones containing works of art that are still covered by copyright. So your broadening the scope of the discussion to something that is a non-issue. Although that also goes for the original proposal. Again, to repeat what I said in the other discussion, the hyperbolic fear mongering about what exactly is being nominated for deletion isn't really helpful and if anything, just makes the discourse around the whole thing way more contentious then it needs to be. Really, it's not surprising that German users would come right out of the gate looking for a confrontation considering the amount of catastrophizing going on around this. No one is nominating "all" images of train stations or tunnels for deleted. Nor is anyone suggesting we do such a thing either. So at the end of the day this proposal is a solution to a non-exiting problem, just like your last one about category names BTW ;) --Adamant1 (talk) 22:09, 17 June 2023 (UTC)
Promotional pictures for WMDE-WikiCon 2022
Guys, define "tunnel" and "inside". Do you need to pass a physical door? Must a place be lockable to be "semi-public", whatever that would be? Do passways under bridges count as tunnels? Is any artwork under a roof now verboten? The suggested policy sounds like after deleting all graffiti and murals younger than 150 years from the France, US, Taiwan and South Africa, busy censors seek to find inroads on German FoP. Train stations are public places and people who delete photos of publicly installed train station artwork are jerks. --Enyavar (talk) 23:42, 17 June 2023 (UTC)
You clearly haven't read the discussions around this, including this one, or what the law says. If you did you'd know that the distinction between public versus private when it comes to images of building interiors doesn't matter. It can still be a "public place" and not qualify for freedom of panorama if that place is the interior of a building. To quote from the law for at least the second time in this discussion ""It is permitted to reproduce, distribute and make available to the public works located permanently on public paths, roads or open spaces. In the case of buildings, this authorization only extends to the façade." Nothing about that sentence says that images of building interiors are covered by freedom of panorama as long as they are public buildings. Making this about if the building is public or not is just a convenient way to deflect from the actual reason the images are being nominated for deletion. No one is nominating the images for deletion based on the buildings not being public places though.
As to what constitutes a building interior, that's an extremely simple question to answer just by looking at the images. No one who is being good faithed about this is going to argue that images like this one are of the exterior façade of the tunnel and/or train station where it was taken. --Adamant1 (talk) 01:17, 18 June 2023 (UTC)
I don't really know if I agree with that last statement. Having lived in cities where pedestrian underpasses under streets are pretty common (London, Bucharest) people don't generally think of entering those passages as "going indoors," and as far as I know that has never really been tested in a German court of law. - Jmabel ! talk03:28, 18 June 2023 (UTC)
I could be wrong but I'm pretty sure the tunnel in the image that I provided a link to isn't just a random pedestrian passage going under a street or whatever. If you look at images in the same categories there's clearly a stairway going down to an underground train station of which the tunnel is a major part of. It's not really clear where the stairs and/or tunnel ends and the train station begins either. Although I agree that random short underpasses going from one side of a road to the other aren't "buildings", but no one is nominating images of those types of passageways for deletion and they aren't what I'm talking about.
Regardless though there's clearly a point where a tunnel is either a building itself or a part of one. And I think the tunnel in the image I linked to would qualify as one of those things since there are stairs leading down it and it connects to the train station. There's also multiple signs with the name of the train station on them before the stairs to BTW. So I don't see how anyone can argue the tunnel and station have nothing to do with each other. Sure though, if the "tunnel" is a random 10 foot long path going under a road then an image of it is probably fine. The issue comes in when the passageway is either a building in it's own right or a part of one. --Adamant1 (talk) 06:00, 18 June 2023 (UTC)
It's not really clear where the stairs and/or tunnel ends and the train station begins either: Ymmd, really. Come to Hamburg and check it yourself. You will see it, you will hear it, you will even smell it. And before that you might read something about Hamburg's concept of becoming an automotive city in the 1950's and 1960's and what the meant to pedestrians. NNW16:31, 18 June 2023 (UTC)
Oppose expanding our characterization of FOP in Germany to include all buildings that are train stations. I'm coming here after a note was left on my talk page regarding a related deletion. The underlying law specifically states It is permitted to reproduce, distribute and make available to the public works located permanently on public paths, roads or open spaces. In the case of buildings, this authorisation only extends to the façade.. In German (which bears the weight of official law), the bolded part comes out to Bei Bauwerken erstrecken sich diese Befugnisse nur auf die äußere Ansicht, with die äußere Ansicht being making it clear that the law protects only reproductions of the building from the outside. COM:PRP guides: where there is significant doubt about the freedom of a particular file, it should be deleted. And, there is significant doubt about taking photographs of the interiors of buildings that also happen to be train stations in light of the text of the underlying law.We have a duty to re-users to ensure that our photos are genuinely free to re-use. We should not be uploading photos to Commons and labeling them as free to re-use if the only basis for doing so is a sweeping and novel understanding of fair use in Germany that is dubious in German courts. For the sake of re-users, we cannot host images and endorse broad re-use in a manner that may very well violate the relevant copyrights. — Red-tailed hawk(nest)14:30, 18 June 2023 (UTC)
The sentence Bei Bauwerken erstrecken sich diese Befugnisse nur auf die äußere Ansicht/ In the case of buildings, this authorisation only extends to the façade is misinterpreted here. It does mean, that the interior of a building is not automatically FOP, only because the exterior is. That makes sense, if the interior is not a public space, e.g. you should not take a picture through a window. However, as long as the interior is a public space then the general FOP rule applies. If anyone is aware of a final judgement in Germany which says otherwise, then please quote that here. Until then for me a clear SupportWikipeter-HH (talk) 09:44, 26 June 2023 (UTC)
Oppose. First, I have trouble with the terminology. To me, there are different types of train stations. There are monsters such as Penn Station where I am inside a building and go through doors to get to enclosed tracks. King St. is a modest station, but it is a building with doors and an interior; I walk out some doors to the open platforms. The wooden station for my home town was torn down, and now the stop is just a parking lot, some fences and automatic gates, some fare machines, and an open-sided shelter. Building interiors are not "public paths, roads, or open spaces." Maybe open-air platforms are an "open space". Maybe a roofed-over train platform is also an "open space". Second, I went to Commons:Copyright rules by territory/Germany. Germany apparently uses strict interpretation: something photographed from the street is OK, but something photographed from a balcony above the street is not. I need a much clearer definition of "public path" and "open space" to conclude that a train station platform or interior is legal. For now, why shouldn't the platform be treated like that balcony rather than the street? A public space may be private property, but there must be a "dedication to the public". "Dedication" is even less clear. Museum interiors are not included. What if the train station is owned by the state? That does not help me: consider a museum owned by the state. Third, the Commons article specifically states, "Against this backdrop, many academic and extra-judicial commentators argue that publicly accessible station halls, subway stations, and departure halls fall short of the "public" requirement because they are not in the same way dedicated to the public as streets, ways, or public open spaces." [Emphasis added.] That raises significant doubt. Yes, I would like to keep interior station shots, but that desire does not trump the doubt that such shots are free of copyright. Glrx (talk) 17:30, 18 June 2023 (UTC)
In the US, "open space" is land that has limited development. Think parks that may have some limited development such as picnic areas and restrooms. A train platform would not be "open space". Glrx (talk) 14:02, 26 June 2023 (UTC)
Support The actual terms in German distinguish between buildings (Gebäude) and structures (constructions, Bauwerke) in general. Tunnels, bridges, piers, open bus station roofs or garden shacks are the latter, but not the former. The cited law (UrhG §59) applies to "Bauerke", which thus includes bridges and tunnels. A streetside graffiti below a bridge could thus be construed as "inside"... or not. The paragraph in question is extremely short and unspecific, so it requires a lot of interpretation and analysis, which was apparently attempted here. I'm not saying to know better than other people here or there, just that we should not implement uninformed rules that generally prohibit street art, when Germany is one of the few countries in the world where public street art is allowed to be photographed for Commons. (On another note: This entire category tree is liable for deletion, for all photos in it younger than 1928 and without the proper VRT notice.) --Enyavar (talk) 20:52, 18 June 2023 (UTC)
Graffiti in the United States are usually in the public domain if created before 1985, as they lack a copyright notice. Yann (talk) 21:12, 18 June 2023 (UTC)
Just to add to that at least from what I've seen none of the images being nominated for deletion have been for streetside graffiti or whatever. Not to mention artwork in a train station obviously isn't "street art" to begin with either. So your vote is based on something that isn't even happening and has nothing to do with this even if it was. As a side to that, the rules about it aren't in anyway uniformed. As I and others like Glrx have pointed out several times already the guideline is based on the analysis of many academic and extra-judicial commentators who all seem to agree that publicly accessible station halls, subway stations, departure halls, tunnels, and passageways probably aren't covered by freedom of panorama. If you want to argue they are wrong, cool, do that then. It's extremely bad faithed to act like the guideline was invented whole cloth out of thin air based on the personal opinions of a few users though. It has 102 references for a reason. The one for the part of the guideline that your referring to cites like 7 different sources by legal experts. So in no way is that part of the guideline based on anyone's personal, uninformed opinions. --Adamant1 (talk) 22:02, 18 June 2023 (UTC)
Oppose a blanket permission per COM:PCP. As per the really thorough presentation in de:Panoramafreiheit#Kriterium_„öffentlich“ (in German) by Pajz - see the expansive footnote no. 76 - it is a matter that's disputed in German law commentaries, and per COM:PCP, we should err on the side of caution. So, I would continue on a case-by-case basis, asking these questions: 1) Does the depicted interior pass the threshold of originality? If it's, for example, just a plain wall with a station sign, there is no issue, we don't need FoP. 2) If the threshold of originality (in German: Schöpfungshöhe) is passed (that is, creative architecture, or sculptures, or things like murals), is it still protected? The architect or interior designer of old train stations could have died more than 70 years ago, then it's also no problem. Only if the depicted interior is likely to pass the threshold of originality and is still protected, I think we have to apply PCP and delete. Gestumblindi (talk) 15:09, 19 June 2023 (UTC)
@Gestumblindi The whole discussion here is caused by some user(s) here raising deletion requests en masse without the due consideration according to your point 1). If you are able to stop that we would be much better off. Wikipeter-HH (talk) 09:58, 26 June 2023 (UTC)
Support It seems insane to me, to delete all pictures of a certain kind, as long as we haven't had one clear decision by a court. By the way, the existence of all this pictures might help arguing in court.Haemmerli (talk) 21:45, 23 June 2023 (UTC)
Not our job to change the law, doesn’t matter what we think of it. I personally hate German FOP for making it seem like you have unlimited freedom then making you follow these inane technicalities, but I’m still opposing this below. Dronebogus (talk) 23:05, 23 June 2023 (UTC)
Oppose we, as a hard rule, should follow countries’ moronically byzantine copyright laws to the letter, and in ambiguous cases default to either reliable sources or assuming something is copyrighted by default. Otherwise what happens is Wikimedians decide they get to interpret the law as they see fit, which is what happened with the ongoing Eiffel Tower lightingmassacree and what is going to happen here. Dronebogus (talk) 23:00, 23 June 2023 (UTC)
Oppose per Gestumblindi: A blanket permission like the proposed one does not make sense here given the circumstances. That does not mean that we have to delete everything that shows a German train station from the inside. Threshold of originality, de minimis, and copyright expirations still exist. It'll just have to be decided case-by-case. --El Grafo (talk) 07:54, 26 June 2023 (UTC)
There is broad majority to not accept photos of tunnels and train stations in Germany if they are not public domain or dedicated as public streets. We should write this to COM:FOP Germany. I would suggest the following wording:
"Because of the unclear legal status of photos taken at public areas they are not public streets of paths in terms of the state street law(Landesstraßengesetz) or similar laws are not accepted on Commons. If freedom of panorama is not needed because they are eligible for copyright or the copyright expired they are accepted."--GPSLeo (talk) 14:08, 23 July 2023 (UTC)
I think your proposed wording is a bit hard to understand. Here's an alternative proposal: "As the applicability of freedom of panorama inside of train stations and metro tunnels is disputed, per COM:PCP Commons accepts such images only if they either show nothing copyrighted (expired term of protection or below threshold of originality), or if they depict an officially designated public street or path as per state street law (Landesstraßengesetz)."
That is a good suggestion, I edited it a bit "The applicability of freedom of panorama inside of train stations and metro tunnels or similar places is disputed. Per COM:PCP Commons accepts such images only if they either show nothing copyrighted (expired term of protection or below threshold of originality), or if they are taken from an officially designated public street or path as per state street law (Landesstraßengesetz) or similar." Maybe we could also add: "Deletion requests with deletions based on this should be categorized in Category:German FOP cases/deleted - tunnels and train stations, that they could become undeleted if there are new decisions or laws." GPSLeo (talk) 17:20, 30 July 2023 (UTC)
There is a small legal review on that problem ordered by Wikimedia Germany File:2023-07-28 Vermerk Panoramafreit in U-Bahnhöfen.pdf. The text supports the conclusion that photos of train stations do not fall under the FOP. Based on this I would suggest to change the text from above to: "The freedom of panorama in unlikely to apply to the inside of train stations and metro tunnels or similar places. Therefore Commons accepts such images only if they either show nothing copyrighted (expired term of protection or below threshold of originality), or if they are taken from an officially designated public street or path as per state street law (Landesstraßengesetz) or similar." --GPSLeo (talk) 15:11, 9 August 2023 (UTC)
I haven't read the Landesstraßengesetz, so please in laypeople's terms: Where is the boundary between a train station (no FOP) and the street (FOP)? Essen-Kupferdreh is a typical case of an S-Bahn station, where graffiti artwork is displayed (see the cat). None of my photos were taken on the platform, but a few are from the staircase directly connected to the streets, as well as from under the viaduct, which means under the "roof" of the station but just a step away from the sidewalk where I have to assume FOP must apply. The category also contains a few images that show the whole ensemble. Other train stations are entirely open without buildings, but have designated pathways leading from/to the station, so once I enter the pathway from the street, I am technically inside a train station. Shouldn't we specify "inside of train station buildings"? --Enyavar (talk) 16:38, 9 August 2023 (UTC)
That is an additional problem. You would have to look if there is a public dedication (Widmung) or if there is a usage right (Wegerecht) in the land register(Grundbuch). This problem was not the goal in this short review. If we request this WMDE might also take a look on this problem. GPSLeo (talk) 17:09, 9 August 2023 (UTC)
So the proposed policy is "we may assume that the public space outside of train station buildings enjoys FOP unless proven wrong with cadastral evidence"? --Enyavar (talk) 17:24, 9 August 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --Schlurcher (talk) 07:18, 23 June 2023 (UTC)
Done The search is now empty. I've also added this to the daily routine of my bot that scans all new uploads. So this will also be fixed prospectively. Best regards. Sidenote: These type of request are usually better placed at Commons:Bots/Work requests which I have on my watchlist, I found it here only by chance. --Schlurcher (talk) 07:18, 23 June 2023 (UTC)
.jpg){kind=link}
Oppose First in general: JPG, SVG and PNG have different use cases and potentials, none of them are innately ideal for images. SVG and PNG are optimal for "clear" graphics; JPG is great for photos. TIFF is good for lossless raw data, especially photos. In the actual case presented in the initial proposal, the SVG has ideal resolution and minimal file size. The PNG in this case doesn't make good use of the strengths of a PNG, i.e. minimization of the color palette: it could be made even smaller than the JPG, with for example just 8 colors. I can agree and 
Support as a general rule to not keep three files with the same content around, but there can't be a general rule that one file type is best. Keep the best two, is my suggestion. --Enyavar (talk) 14:09, 12 June 2023 (UTC).svg){kind=logo}
Question What's the use case for this? Are there actually users that should not be able to upload files, but should be able to edit the rest of Commons? The only reasons I could think of for blocking uploads is if someone didn't understand copyright or was uploading files for an abusive purpose, and neither bodes well for their continued presence on this project. The Squirrel Conspiracy (talk) 22:57, 21 June 2023 (UTC)
Weak support. Abzeronow (talk) 18:38, 13 June 2023 (UTC)
Neutral on this. While I stand by my opinion generally, I don't know enough about the details of German law to take a side. Yann (talk) 19:19, 18 June 2023 (UTC)
_04.jpg)
