Commons: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/10. Please note:
Purposes which do not meet the scope of this page:
Search archives: |
| Legend |
|---|
|
|
|
|
|
| Manual settings |
| When exceptions occur, please check the setting first. |
 Thatched water pump at Aylsham, Norfolk [add] | |||||||||||||||
| |||||||||||||||
.jpg){kind=link}
 |
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days. |
October 24[edit]
Croptool and webp[edit]
Will Croptool be supporting webp files anytime soon? --RAN (talk) 17:53, 24 October 2023 (UTC)
- @Richard Arthur Norton (1958- ) webp. files are typically problematic: see cases like Commons:Deletion requests/Files uploaded by Milíkov1234 and Commons:Deletion requests/Files uploaded by Aacocao. JWilz12345 (Talk|Contrib's.) 23:14, 24 October 2023 (UTC)
- The deletions had to do with the lack of provenance of contemporary images, not the format they were stored in. Historical images still follow international copyright law, no matter what format they are stored in. --RAN (talk) 23:34, 24 October 2023 (UTC)
- I wouldn't bank on it. From what I understand, webp is a "baggy monster" of a standard, much like tiff. - Jmabel ! talk 00:34, 25 October 2023 (UTC)
- WebP is a good and clean image format which allows for highly efficient storage, using either lossy (like jpeg) or lossless (like png) encoding. TIFF is a container format that can contain a variety of image formats. WebP also uses a container format, which is Resource Interchange File Format, the same as avi and wav files. The problem with tiff files is mostly that they can contain a vary diverse variety of codecs. WebP just has two major codec algorithms. To call it baggy is really overstating the variance it allows.
- WebP is mostly not liked by consumers, because people are just so incredibly used to png and jpg being compatible with everything out there, that they don't want to use something that is slightly less compatible with other systems out there. It is however better than both png and jpg in terms of quality and in how much disk space it uses. It's mostly a problem of; people don't want to have to care about file formats. —TheDJ (talk • contribs) 19:56, 30 October 2023 (UTC)
- WebP is a fine format, but commons' support for it is poor. No EXIF data is shown for WebP images on commons, even if it exists. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 10:38, 1 November 2023 (UTC)
- I wouldn't bank on it. From what I understand, webp is a "baggy monster" of a standard, much like tiff. - Jmabel ! talk 00:34, 25 October 2023 (UTC)
- The deletions had to do with the lack of provenance of contemporary images, not the format they were stored in. Historical images still follow international copyright law, no matter what format they are stored in. --RAN (talk) 23:34, 24 October 2023 (UTC)
- @Richard Arthur Norton (1958- ) see https://de.wikipedia.org/wiki/Wikipedia:Reparatursommer#CropTool C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 12:38, 3 November 2023 (UTC)
Found Photos[edit]
This collection of found photos no doubt has much that cannot be used, but I'm sure there are some diamonds in there, if anyone familiar with US law around anonymous works has patience to sift for them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:41, 24 October 2023 (UTC)
- Some of the pictures have comments that help with identification. Quite an interesting collection indeed, but COM:HIRTLE doesn't look too promising for such mostly relatively recent photos. Most look like personal snapshots that were probably never published previously; in this case, if the first publication was on flickr (that is, in "2003 or later" as per the chart), they have a US protection term for "95 years from publication OR 120 years from creation, whichever expires first" if the author isn't known, otherwise 70 years after the death of author. I'm afraid that this looks like very few of these photos are in the public domain. Gestumblindi (talk) 20:31, 24 October 2023 (UTC)
- USA case law has sided with the concept that images found in the wild have been made public once they leave the custody of the creator. They do not need to appear in a magazine or a newspaper to be "made public". That would be up to 1989. After 1989 images no longer need to have a copyright symbol, and the year, and register a copy with the United States Copyright Office to be eligible for a copyright. --RAN (talk) 23:29, 24 October 2023 (UTC)
- I can't imagine how this differs from "I found it on the Internet". We have no way to know the possible prior publication history of any of these photos. - Jmabel ! talk 00:38, 25 October 2023 (UTC)
- Interesting collection. My guess is that the person probably bought them on eBay, but "bought on eBay photos" just doesn't have the same ring to it as "found photos" does. Regardless, I have to agree with Jmabel about how it's no different then "I found it on the Internet." Although one could argue maybe RAN has a point about actually found photos. Who knows if that extends to images that were likely purchased on eBay though. Plus it's always possible there's a copyright on the back of the photograph that we just don't have a way of knowing about or accounting for. --Adamant1 (talk) 13:35, 25 October 2023 (UTC)
- Up until 1989 you still had to register for a copyright (you has 5 years, up until 1994 to register for a 1989 copyright), as well as put the copyright symbol on the image. If you look through the copyright registration database, there are very, very few images. Almost all the registrations are for newspapers, magazines, and books. No one taking personal pictures would hire a lawyer to register their copyright, unless they were going to publish them in a magazine or book. --RAN (talk) 17:07, 28 October 2023 (UTC)
- It's more complicated than that. The owner of the Flickr account presumably does not own copyright on these, and probably has no real right to publish them. Presuming the Flickr posting is the first time they've been published, and regardless of whether this unauthorized publication on Flickr counts or not, I don't see why any of these would be PD. If it does count, then they are copyrighted until 95 years from publication OR 120 years from creation, whichever expires first. If it doesn't count, then they are still "unpublished" and would be copyrighted until 120 years from creation. So unless something here is from before 1903, I believe it would not be public domain. - 21:56, 28 October 2023 (UTC)
- & "found in the wild" presumably would not cover one print, made by (and kept by) the photogrpapher, that recently changed hands once on eBay, a yard sale, etc. - Jmabel ! talk 21:58, 28 October 2023 (UTC)
- RAN, I think that only holds if the images were published in some form previously; if the Flickr publication is the first, see Jmabel's comment - either copyrighted 95 years from publication (on flickr) or 120 years from creation. So I also think that Yann might have been over-enthusiastic by uploading images from the 1930's and 1950's, aren't these still protected if that is the case? The 1913 photo is probably fine, though. Gestumblindi (talk) 21:52, 1 November 2023 (UTC)
- I uploaded a few which should be OK, either old enough, or published without a notice: File:Two women with a car, 11-1936.jpg, File:Royal Blue Travel, St Helier, Jersey.jpg, File:Locomotive in Idaho Springs.jpg. Yann (talk) 17:26, 29 October 2023 (UTC)
- The steam locomotive is this same 2-8-0 still standing in Idaho Springs as a monument. [1] [2] Herbert Ortner (talk) 20:41, 1 November 2023 (UTC)
October 28[edit]
File overwriting is now limited to users with autopatrol rights[edit]
In September we decided to limit the overwriting of files to users with autopatrol rights. The reason was the huge amount of violations of the Commons:Overwriting existing files guideline.
The abuse filters to prevent users from overwriting files they did not originally uploaded are now active. Users who want to overwrite files uploaded by other users now need to request ether autopatrol rights or they can request an exception for a particular file. For this there is the page Commons:Overwriting existing files/requests. These file pages get the template {{Allow Overwriting}} that can only be placed by users with patrol rights.
Please report here or on the Commons:Administrators' noticeboard if you notice any problems with the new filters. GPSLeo (talk) 08:56, 28 October 2023 (UTC)
- @GPSLeo that's a welcoming development! This should prevent incidents like the infamous overwritings of political maps of Philippine provinces like File:Ph fil laguna.png. I am certain there are many more Philippine province maps that are still not yet reverted to their most recent decent versions. JWilz12345 (Talk|Contrib's.) 09:07, 28 October 2023 (UTC)
- Awesome. Since I've been reverting vandalism and doing minor tweaks and such to SVG files for the past two years, and now I can't do that, do I just need to apply for autopatrol and hope to get accepted for it? Donald Trung put in a really fantastic post detailing his issues with it, and then nobody interacted with it, which honestly has bothered me even more than the now apparent requirement to get autopatrol rights.
- I did a quick check of all the users that supported the resolution. Out of the past 500 file uploads of all of them (excluding reverts obv), only two (Tuvalkin and Glrx) do any SVG uploading, and both don't upload very complex files like flags or emblems (cf Trung discussing how SVGs like flags and emblems are going to be an issue now); so the users that supported this aren't the kind of people who will be affected by the type of decisions like updating the colors on a flag or updating it to match the actual constructed design. Right now, I'm currently trying to figure out what the proper colors of the South Sudanese flag are; if an update comes out, am I just now supposed to request to be able to update the file that I've been working on for the past month or to hope that I get accepted for autopatrol?
- I'm going to share two of Trung's points that never got countered or acknowledged because I feel like they're really important to the now-existing issue:
At the Graphics Lab there are a fairly number of WikiGraphists with no user rights that upload high quality SVG files, many of these users barely have any uploads and edits in general but the few edits they have consists of taking on requests and / or cleaning up SVG source codes (something which can only be done by overwriting files). Another issue is that if non-autopatrolled users can't overwrite their own files they might upload a similar file and then request deletion for the original, minor cropping or censoring faces, license plates, Etc. for privacy reasons are common examples here. Further regarding SVG files we could see situations where users will upload nearly identical SVG or even identically looking SVG files and then nominating the original for deletion over errors in the code ("Bad code") or over minor colouring issues that could've easily been fixed by overwriting.
The issue with the latter is that SVG files are the files that are most likely to be overwritten, edit warred over, and vandalised, so excluding them wouldn't make much sense either. If technically feasible we should limit new users overwriting files uploaded by others (namely users who aren't currently a part of a file's upload history), but we should also find a way to allow users without Autopatrol right to help with improving them. Sometimes non-Autopatrolled WikiGraphists overwrite a current coat of arms with a better version because the current one has a minor factual error. A look at "File:Flag of the Vatican City.svg" shows how many trusted Wikipedians without Autopatrol rights helped improve this image. Personally, I'd say that the best solution that would take the least time and introduce the least unnecessary workload would simply having a daily list of overwritten files by non-autopatrolled users showing the previous iteration of the file and the new iteration. I'm fine with a template to allow overwriting, but it would also be a lot of work to manually add them to uploads where they should be allowed. As this has already passed I'm only adding suggestions as this will affect flags and coats of arms which are commonly overwritten by Wikipedians with barely any Commonswiki edits.
- I feel like this is an incredibly nonsensical idea, and the lack of any actual acknowledgment or consideration of the issues from those who frequently work with detailed SVGs leaves me feeling genuinely very irritated about this change. NorthTension (talk) 21:19, 28 October 2023 (UTC)
- I had a look at the file overwrites and most of them violated the guideline. What would you propose to make people comply with the guideline that is not limiting that right to a certain group of users? You mentioned changes on flags and coats of arms. This was one of the main field of disputes and edit wars as people want to have their color version as the used version. GPSLeo (talk) 06:14, 29 October 2023 (UTC)
- Either Trung's idea or raising the number of days or edits for autoconfirms; that seems pretty simple.
- If anything ask him about it since I'm just voicing my great displeasure at a guy I seriously respect being completely ignored. NorthTension (talk) 14:09, 29 October 2023 (UTC)
- So as an SVG illustrator, the majority of all vandalism I see comes from reverting or spam uploads and not the overwriting of files; for example just yesterday this user reverts six files (one PNG) for no reason. While I almost constantly have been reverting files from vandalism and reporting sockpuppets of a user doing spam uploads, as far as I can tell none of this is covered under the autopatrol overwrite rights you set up because a bad actor can just continuously revert files back because this is primarily what vandals do anyways. NorthTension (talk) 12:03, 31 October 2023 (UTC)
- I had a look at the file overwrites and most of them violated the guideline. What would you propose to make people comply with the guideline that is not limiting that right to a certain group of users? You mentioned changes on flags and coats of arms. This was one of the main field of disputes and edit wars as people want to have their color version as the used version. GPSLeo (talk) 06:14, 29 October 2023 (UTC)
- Thanks GPSLeo! This is a very welcome change! Maybe now we won't have to deal with daily edit wars on SVG maps. Nosferattus (talk) 00:36, 29 October 2023 (UTC)
- Sorry -- am I reading this right? Is it now completely impossible for somebody to overwrite a file without having the autopatrol right on Commons specifically? Does this include things like Commons:CropTool? JPxG (talk) 04:40, 29 October 2023 (UTC)
- The crop tool was one of the main sources for bad file overwrites. Exceptions for single files are possible there is a page for requests. Commons:Overwriting existing files/requests GPSLeo (talk) 06:14, 29 October 2023 (UTC)
- this is horrrrrrrible. overwriting files is such a frequent thing here. and you're restricting it to, what, a quarter of people here? ltbdl (talk) 04:46, 29 October 2023 (UTC)
- We did as a we did not see an other solution the get rid of the huge amount of guideline violations. GPSLeo (talk) 06:14, 29 October 2023 (UTC)
- @Ltbdl better than letting vandalism go on the loose. Vandals like Yuiyui2001 (talk · contribs)'s vandalism of political maps of provinces of the Philippines (either thru their main account or their sockpuppets). Look how File:Ph fil bulacan.png's file history is mainly focused on vandalism and counter-vandalism. JWilz12345 (Talk|Contrib's.) 06:16, 29 October 2023 (UTC)
- can't you just protect that file? ltbdl (talk) 07:26, 29 October 2023 (UTC)
- We would have to protect a huge amount of files and then also would need to unprotect them on request. Therefore it is easier to just have all files protected and still having the possibility unprotect files. GPSLeo (talk) 07:58, 29 October 2023 (UTC)
- ah, so... protect every file instead of the small percentage of files that need protecting. lovely. ltbdl (talk) 09:02, 29 October 2023 (UTC)
- The problem of bad overwriting is not limited to maps and svg files. There are much more files affected by bad overwrites. Of course the current solution is not optimal but as long as we do not have other technical solutions like merge requests and also not enough people for patrolling this is the only solution to protect our project and the Wikis were the files are used. GPSLeo (talk) 09:34, 29 October 2023 (UTC)
- and also not enough people for patrolling
- really? ltbdl (talk) 10:05, 29 October 2023 (UTC)
- The problem of bad overwriting is not limited to maps and svg files. There are much more files affected by bad overwrites. Of course the current solution is not optimal but as long as we do not have other technical solutions like merge requests and also not enough people for patrolling this is the only solution to protect our project and the Wikis were the files are used. GPSLeo (talk) 09:34, 29 October 2023 (UTC)
- ah, so... protect every file instead of the small percentage of files that need protecting. lovely. ltbdl (talk) 09:02, 29 October 2023 (UTC)
- We would have to protect a huge amount of files and then also would need to unprotect them on request. Therefore it is easier to just have all files protected and still having the possibility unprotect files. GPSLeo (talk) 07:58, 29 October 2023 (UTC)
- Why not just ban the vandals? NorthTension (talk) 13:31, 29 October 2023 (UTC)
- can't you just protect that file? ltbdl (talk) 07:26, 29 October 2023 (UTC)
- hmm. Unless you want admins to spend a lot of time granting auto-patrolled to people we will probably need to find a way to extend it to people with autopatrolled on any project.Geni (talk) 05:33, 29 October 2023 (UTC)
Shouldn't files with the {{Current}} template be exceptions to this hard-rule? -- Veggies (talk) 07:04, 29 October 2023 (UTC)
- This would be possible but as {{Current}} can be added by everyone I would not suggest to do this. Instead the {{Allow Overwriting}} should be added additionally to {{Current}}. GPSLeo (talk) 08:01, 29 October 2023 (UTC)
- We could change it so that {{Current}} can only be added by those who can add {{Allow Overwriting}} (i.e. the uploader of the file and patrollers). Elli (talk) 20:55, 29 October 2023 (UTC)
I fully understand the reasons for this restriction, but I would like to apply to be grantet an exception to, from time to time, overwrite files I have uploaded. My contributions to Commons are (1) photos I have taken myself, and (immediately after uploading) used in articles on NL, (2) a number of graphs on economics, which are used in articles on NL, and which I would like to update from time to time. Please have a look at my contributions page (Special:Contributions/MartinD) for some recent examples. Please let me know how I should proceed. Kind regards, MartinD (talk) 11:36, 29 October 2023 (UTC)
- Hi @MartinD, looking at your user rights, your edits and uploads are already autopatrolled and therefore you will not be hindered by this change. @GPSLeo, am I correctly understanding the change? Ciell (talk) 11:45, 29 October 2023 (UTC)
Considering how significant of a change this is, it would have been great if people were actually notified outside of VP which is obviously only watched by v. active users, and I see a few problems with this:
- Admins are going to be inundated with autopatrol requests
- New users are going to be confused
- People will just upload new files now rather than overwriting.
It would have made much, much more sense to have autopatrol protection, where certain high-profile files could be protected with autopatrolled. Even better, we could have something like extended confirmed which would mean no need for admins to grant the right. I support the idea in principle, but it doesn't seem very fleshed out and will probably just backfire. Isochrone (talk) 07:25, 30 October 2023 (UTC)
- The SVG arguments are also a bit selective and are unfairly extrapolating to every file. Yes, we have some files that are targets for vandals, but as someone who mainly uploads complex SVG maps I find that the contributions of others (who rarely have autopatrolled) makes them much better for everyone.
- N.b. I was informed of this change offwiki but I am voting here on my own accord. Isochrone (talk) 07:35, 30 October 2023 (UTC)
- New users are not going to be confused at not having an option they never knew they had in the first place, or one they only rarely used. I would also wager that it's new users who cause the most issues with overwriting files they shouldn't be in the first place. That people will upload new files instead of overwriting existing ones doesn't seem to be a flaw but an intended consequence.
- I don't know how this decision will pan out in the long term, but I understand the reasoning behind it and I think it's worth giving a shot. ReneeWrites (talk) 12:06, 31 October 2023 (UTC)
- So for the flag of South Sudan, without a clearly defined shade that I'm still waiting for an email back from the US Embassy over this, should I just upload even more variations of different shades of blue and star positions? What happens when I finally get my request answered? NorthTension (talk) 12:10, 31 October 2023 (UTC)
- Use the talk page or request autopatrol rights.
- Worth mentioning that what Isochrone proposed (increasing extended-protection to more files to protect them against vandalism) would have led you to the same problem, with the same solutions. In my opinion the problem is with the millions of files that don't get that many eyeballs on them, by users that don't have thousands of constructive edits spanning back months or years. ReneeWrites (talk) 12:29, 31 October 2023 (UTC)
- I don't recall saying I supported Isochrome's proposal. NorthTension (talk) 12:30, 31 October 2023 (UTC)
- So for the flag of South Sudan, without a clearly defined shade that I'm still waiting for an email back from the US Embassy over this, should I just upload even more variations of different shades of blue and star positions? What happens when I finally get my request answered? NorthTension (talk) 12:10, 31 October 2023 (UTC)
Juanqianguo (talk · contributions · Statistics · Recent activity · block log · User rights log · uploads · Global account information)
looks like someone is challenging your new rule. is it possible to prevent reversion of file versions with abusefilter too?--RZuo (talk) 15:08, 30 October 2023 (UTC)
October 29[edit]
Parco della Villa Reale (Monza) or Monza Park[edit]
Good evening, I propose to rename the Parco della Villa Reale (Monza) page on Wikipedia Commons to Monza Park, so that any Wikipedia user can recognize it and understand the name, also due to the fact that many similar pages (Royal Park of the Palace of Caserta or Park of Versailles) are titled in English. Fefecece (talk) 17:46, 29 October 2023 (UTC)
- The better place to do this is at Categories for Discussion. To do this, go to Category:Parco della Villa Reale (Monza) where you can find the option to nominate it for discussion on the left side of the screen, under "Tools". ReneeWrites (talk) 11:58, 31 October 2023 (UTC)
Using the most common term when naming categories[edit]
Although I can't find the exact phrasing right now, Commons:Categories and general, established practice seems to lean towards using the most commonly used name for a particular subject as the name of it's corresponding category. Which is mostly fine. There seems to be an issues when an entity changes it's name where categories named after the original are quickly redirected and files are moved regardless of if they still use the older name. Again, this is mostly fine depending on the circumstances. Although it does seem to cause problems IMO when the subject of the files is still more commonly known using the older name and can be considered historically important in it's own right under that name. An example being Category:Fort Gordon, which was renamed a few months ago to Category:Fort Eisenhower. Leading to the previous category being redirected and a bunch of files referring to Fort Gordon being moved to Category:Fort Eisenhower.
Now I don't necessarily think that's the wrong move in other cases, but in this one "Fort Gordon" is clearly a historical important name in military history and there's plenty of instances where people will be searching for "Fort Gordon" to find files related to the historical base or wanting to organize files contain the name "Fort Gordon" instead of "Fort Eisenhower." So I think it's worth having categories for both. Since that option would be the less likely to cause potential issues. Plus, it just makes more sense to organize images related to Fort Gordon in a category for Fort Gordon. The original user who redirect the category to begin with @Koavf: seems to disagree though and instead thinks everything should be put in Category:Fort Eisenhower regardless. Since at least according to them having a separate category for Category:Fort Gordon would be creating two categories for the same subject.
Although I'm of the opinion that there is enough of a difference at least on Commons' end between the original historical Fort Gordon and what is now called "Fort Eisenhower" to justify two separate categories. I think @Koavf: 's main issue is that having two categories would conflict with the single Wikidata entry though. Which I can understand, but my issue is that a single category makes it harder for people to organize and find files related to "Fort Gordon." Especially since the name was so recently changed, most people probably don't know it happened yet, and everything is mostly still being referred to as Fort Gordon anyway. Plus, I just don't think how things are named on Commons should be dictated by Wikidata. I'd like to hear other opinions on the subject since we weren't able to agree about it and the guidelines aren't super clear either way about how to handle these types of situations. Adamant1 (talk) 20:01, 29 October 2023 (UTC)
- Certainly in either case there ought to be a category description that also gives the other name, much as we do for the much less loaded case of Category:Safeco Plaza (Seattle, Washington). - Jmabel ! talk 23:32, 29 October 2023 (UTC)
- wasnt this discussed just a few weeks ago: Commons:Village_pump/Archive/2023/10#Nagorno-Karabakh_village_name_categories_all_being_changed_into_Azerbaijani?--RZuo (talk) 15:08, 30 October 2023 (UTC)
- Their similar issues for sure. I wasn't exactly able to parse out what the consensus at the time was though. Except that forcing people to search for the old categories by deleting or redirect the new ones to them wasn't appropriate. That's not really what I'm suggesting though since my solution is to have categories for both the old and new name until the new one is it least common enough for people to search for it and organize files in the "correct" category. I'm also not in this to try and right great wrongs or axe grind either BTW. The name of the military base was just recently changed and I think it's to new for people to search for it or organize files under the new name. Plus the majority of files related to the base still refer to the old name, which I don't think could be said with the towns that had their names changed. So I don't think the conversations are really analogous or that anything from that conversation can be applied to this one. But if the name of base was changed to Fort Eisenhower a month ago, no one calls it that yet, and most of the files and file descriptions we have still refer it to as Fort Gordon then I don't see why we shouldn't keep Category:Fort Gordon at least for now until that changes. Again though, while also keeping Category:Fort Eisenhower so people can have the option of using either one if they want to. It's not like anything saying we have to or should get rid of a category the second there's a name change anyway. So I don't really see what the issue with keeping both for now until "fort Eisenhower" becomes more ubiquitous. --Adamant1 (talk) 00:19, 2 November 2023 (UTC)
October 30[edit]
Hi, Could anyone tell me where is this? I can't find any "St. Lemon" in USA. And may be also identify the car? Thanks, Yann (talk) 12:44, 30 October 2023 (UTC)
- Family Search genealogic records indicate a Patricia Ann Krabbenhompt born in 1932 who lived in Pima AZ in 1940 and a Patricia A Krabbenholf born in 1932 who lived in San Diego in 1950. I'm can't really get a good feeling of whether one of the women in the photo looks around 8 or 9 years old. But based on the southwestern USA looking rock formations in the photo, Pima Arizona could be a reasonable place to start looking. -- William Graham (talk) 17:17, 30 October 2023 (UTC)
- Visually, the rocks remind me a lot of the roads between San Diego and El Centro California. Specifically the rocky parts of Interstate 8 between Jacuma Springs and Ocotillo CA, but I am not an expert on geology or the entirety of the Interstate 8/the historic route. -- William Graham (talk) 17:35, 30 October 2023 (UTC)
- I was thinking Colorado or one of the other upper midwest states. There's four towns in the United Stated called Lemon but they are all on the east coast and don't like the place in the image. Maybe the in Idaho, but more then likely William Graham is correct it was probably taken in either California or Arizona. Otherwise New Mexico or Colorado would be mu third and forth guesses. --Adamant1 (talk) 18:34, 30 October 2023 (UTC)
- Update to that. Apparently there's a Mount Lemon in Arizona that use to be the location of a prison camp. So I think we have a winner. --Adamant1 (talk) 18:37, 30 October 2023 (UTC)
- Yeah, there is a North Prison Camp Road in the low elevations of en:Mount Lemmon near 32°20′09″N 110°43′21″W / 32.3357°N 110.7226°W that is now a camping/recreation trail area. And it's inside Pima County, Arizona and 65 miles as the crow flies from en:Pima, Arizona (the town is in Graham County). -- William Graham (talk) 21:10, 30 October 2023 (UTC)
- And the prison camp was established in 1939 and used prisoner labor to build the highway. https://www.nps.gov/parkhistory/online_books/anthropology74/ce18a.htm . -- William Graham (talk) 21:20, 30 October 2023 (UTC)
- Thanks a lot, great find! I added a category, but I will let you add a geolocation if you can. And what about the car? Yann (talk) 21:33, 30 October 2023 (UTC)
- The car looks like a Category:Ford Model 81A four door. I also scrubed through Google Street view I found what looks to be the location. [3] at 32°20′17″N 110°41′26″W / 32.337942559643°N 110.69060645725°W looking north. -- William Graham (talk) 21:49, 30 October 2023 (UTC)
- Nice! That's totally the same exact rock outcropping. --Adamant1 (talk) 21:51, 30 October 2023 (UTC)
- you should work for fbi or something lol.
- https://www.google.com/maps/place/32%C2%B020'16.6%22N+110%C2%B041'26.2%22W/@32.337505,-110.6906672,3a,90y,334.93h,98.95t/data=!3m6!1e1!3m4!1sqr7LDqBsMK-E1bkts9cMiw!2e0!7i16384!8i8192!4m5!3m4!8m2!3d32.3379444!4d-110.6906111!10e5?hl=en&entry=tts might be the same tree to the left of the car? RZuo (talk) 10:21, 31 October 2023 (UTC)
- The car looks like a Category:Ford Model 81A four door. I also scrubed through Google Street view I found what looks to be the location. [3] at 32°20′17″N 110°41′26″W / 32.337942559643°N 110.69060645725°W looking north. -- William Graham (talk) 21:49, 30 October 2023 (UTC)
- Thanks a lot, great find! I added a category, but I will let you add a geolocation if you can. And what about the car? Yann (talk) 21:33, 30 October 2023 (UTC)
- So "St." should read "Mt."? Enhancing999 (talk) 10:51, 31 October 2023 (UTC)
- Update to that. Apparently there's a Mount Lemon in Arizona that use to be the location of a prison camp. So I think we have a winner. --Adamant1 (talk) 18:37, 30 October 2023 (UTC)
- I was thinking Colorado or one of the other upper midwest states. There's four towns in the United Stated called Lemon but they are all on the east coast and don't like the place in the image. Maybe the in Idaho, but more then likely William Graham is correct it was probably taken in either California or Arizona. Otherwise New Mexico or Colorado would be mu third and forth guesses. --Adamant1 (talk) 18:34, 30 October 2023 (UTC)
- Amazing detective work, almost preternatural. You should be working on the Library of Congress Flickr Commons project to add context to their image collection. See: https://www.flickr.com/photos/library_of_congress/ Most are already loaded to our Commons but need context. See for instance this gentleman from 1924: File:Sesame LCCN2014717694.jpg which is probably a misspelling, it would be someone in the news or named on a ship manifest. See: E. Bornemann. --RAN (talk) 23:43, 30 October 2023 (UTC)
Car identification[edit]
Can anyone help please? Yann (talk) 21:47, 30 October 2023 (UTC)
- The truck is probably a Chevrolet 3100 as seen in Category:Chevrolet Advance-Design pickups. See also File:Chevrolet 3100 Pick up Truck 1949 - Flickr - exfordy.jpg. -- William Graham (talk) 22:33, 30 October 2023 (UTC)
October 31[edit]
Hi, This may be dated more precisely from the phone. When did this type of phone was in use? Yann (talk) 18:59, 31 October 2023 (UTC)
- Don´t know, ask the AI which made the picture. Alexpl (talk) 19:35, 31 October 2023 (UTC)
- According to the meta data it was converted from TIFF to JPEG on a Mac with Adobe Photoshop Lightroom in 2022. AIs don't usuaally create TIFF. That is more of a GLAM thing. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 13:25, 1 November 2023 (UTC)
- The image is from a well-known Flickr account that hosts "found" images (prints and transparencies). There is no reason to suppose it is AI generated. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 3 November 2023 (UTC)
- @Yann: I doubt that will be of much use to narrow the time frame. These came into use in the 19th century, but a few were still around when I was a child in the 1950s. - Jmabel ! talk 20:55, 31 October 2023 (UTC)
- @Alexpl: why do you think this was made by an AI? If it was, then the current PD template claims the wrong basis for PD. - Jmabel ! talk 20:55, 31 October 2023 (UTC)
- Not to speak for Alexpl, but it looks like she's holding a cell phone up to her ear. Even if that's not what it is, phone receivers from that time period weren't square blocks that were held perpendicular to the side of the head. At least not that I'm aware of. You'd have to hold it out longways away from the ear since the speaker was at the end of the receiver. --Adamant1 (talk) 21:21, 31 October 2023 (UTC)
- It is really difficult to see which form the speaker has because it is dark and there are lots of scratches that might be misleading. However, I wonder whether the PD license tag is correct. I have very little knowledge of U.S. copyright. But how can we know that the image was published between 1928 and 1977 in the U.S.? The source might very well be a private photo that was first published in 2023. The source photo was published on Flickr under a CC BY-NC license, which would not be helpful either. --Robert Flogaus-Faust (talk) 22:22, 31 October 2023 (UTC)
- Not to speak for Alexpl, but it looks like she's holding a cell phone up to her ear. Even if that's not what it is, phone receivers from that time period weren't square blocks that were held perpendicular to the side of the head. At least not that I'm aware of. You'd have to hold it out longways away from the ear since the speaker was at the end of the receiver. --Adamant1 (talk) 21:21, 31 October 2023 (UTC)
- With every upload to Commons in 2023, the burden to proof for authenticity should have been shifted to the uploader. Without sources, no upload. Btw. that is a "candlestick phone". Alexpl (talk) 21:48, 31 October 2023 (UTC)
- The triple portrait, in the presumably relevant era, would almost certainly have been the work of a professional. Presumably not a photobooth photo because who would have brought a phone into the photobooth for one of three shots? I'd be pretty comfortable with presuming publication at the time: remember that for that era in the U.S., even passing a copy to the subject of the photo without marking it as copyrighted is generally considered publication without copyright.
- Yes, I know it is a candlestick phone. As I say, they were still around (though rare) when I was young.
- It's hard to say definitively what she is holding because that part of the image is so dark, but the position of her hand is completely consistent with holding the trumpet of a candlestick phone. Compare File:Boyle Workman using a telephone.jpg. Again, why would you think an AI is more likely? - Jmabel ! talk 00:02, 1 November 2023 (UTC)
- We are given no reason to believe it is from "that era in the U.S." - or any era. Just because it´s in black&white is somewhat blurry and features an excessive amount of suspiciously uniformly scratchmarks, is no proof for an image to be "old" anymore. No provenance = no authenticity. Alexpl (talk) 07:14, 1 November 2023 (UTC)
- This is not AI-made. It is an old argentic print. From the dress, we can already say that this is from the first part of the 20th century, and the phone matches this. "Booth photograph" is mentioned in the metadata. RAN added "ca. 1915", but IMO it could be until 1940, although I am not an expert of fashion of that area. Yann (talk) 08:32, 1 November 2023 (UTC)
- We are given no reason to believe it is from "that era in the U.S." - or any era. Just because it´s in black&white is somewhat blurry and features an excessive amount of suspiciously uniformly scratchmarks, is no proof for an image to be "old" anymore. No provenance = no authenticity. Alexpl (talk) 07:14, 1 November 2023 (UTC)
- See: File:Genevieve-Clark-Bain.jpeg for a dated image from 1913, from the Library of Congress. While the telephone was used up until 1940 the clothes are from 1910 to 1915. --RAN (talk) 11:39, 1 November 2023 (UTC)
- OK, this style was started around 1915, but IMO it was worn until 1940 (again I am not an expert). Example: see the blonde here or this. Yann (talk) 15:47, 1 November 2023 (UTC)
- It is your upload, I trust your judgement, set the date to your preference. You might want to create a gallery of the images we are talking about at the image page, so others can see years from now. --RAN (talk) 22:22, 1 November 2023 (UTC)
November 01[edit]
blacklist sanity checking...[edit]
I just tried uploading an image from the flickr pages of the The GPA Photo Archive. Which asserts it "is maintained by the Bureau of Global Public Affairs of the United States Department of State, and comprises public-access photos intended for use by U.S. Missions overseas and other State Department entities."
How does a flickr user like this make the blacklist?
Here is the photo I tried to upload... https://www.flickr.com/photos/iip-photo-archive/49531802096/ Geo Swan (talk) 06:51, 1 November 2023 (UTC)
- Quoting completely for convenience:
- The GPA Photo Archive is maintained by the Bureau of Global Public Affairs of the United States Department of State, and comprises public-access photos intended for use by U.S. Missions overseas and other State Department entities.
- Photos may be used by staff of the Bureau of Global Public Affairs (GPA), U.S. embassies, consulates, American Spaces, and other U.S. mission offices, and distributed as warranted for use by non-USG organizations sanctioned by the embassy.
- Only non-commercial use is permitted. Credit line should read: GPA Photo Archive / photographer's name / original source. Example: GPA Photo Archive / Carol M. Highsmith / Library of Congress
- --Achim55 (talk) 07:05, 1 November 2023 (UTC)
- https://commons.wikimedia.org/w/index.php?title=Commons%3AQuestionable_Flickr_images%2FUsers&diff=prev&oldid=388937558 added by User:Pi.1415926535. RZuo (talk) 07:16, 1 November 2023 (UTC)
- "Only non-commercial use" would certainly qualify for the blacklist. - Jmabel ! talk 17:18, 1 November 2023 (UTC)
- This account grabs (usually free) files from other sources and reuploads them. Very often the license on flickr is incorrect; I have seen some of my CC-BY-SA files on the account listed as PD. Any file on this account should be uploaded from the original source instead. For example, the file that Geo Swan linked above is actually from the State Department - and is already on Commons from the original source. Pi.1415926535 (talk) 23:55, 1 November 2023 (UTC)
- "Only non-commercial use" would certainly qualify for the blacklist. - Jmabel ! talk 17:18, 1 November 2023 (UTC)
13 of the MOTD of November and 18 of the MOTD of December are OGG files without description text of anthems of small countries[edit]
I am only mentioning that, because I nominated two of my own files as MOTD for november and only now found out, that i had made the entrys for November 2024 in error. When I tried to correct that, I stumbled about this crowd of anthems. I really would like to have at least my webm file early in November this year and it would also be fine to have the flac file sooner than 1st of january. --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 09:42, 1 November 2023 (UTC)
Commons Gazette 2023-11[edit]
- Currently, there are 186 sysops.
- Overwriting other users' uploads is now limited to autopatrollers.
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) 10:25, 1 November 2023 (UTC)
Photographs prohibited - or not?[edit]
I found the following article, that illustrates a quite ominous case: https://www.bristolpost.co.uk/news/bristol-news/signs-banning-phones-cameras-public-8869080
In short, it is a report about signs that prohibit taking photographs at Temple Quay in Bristol. But the signs were erected by mistake. Only commercial photography shall be prohibited, they stated afterwards. The reason that this rather public area is owned by a private company. It also raises the question whether it is good that a private company owns that land, and can decide who can enter or not, and is a potential threat to the freedom of panorama in the UK, and limiting rights of the public. I wanted to share this, because it might be interesting for the readers here --PantheraLeo1359531 😺 (talk) 15:36, 1 November 2023 (UTC)
- I'm not sure this is a freedom of panorama issue. Freedom of panorama is about copyright. Even if the property owner can set rules which restrict people from taking photographs there (and even that seems to be in doubt), they don't gain any copyright in photos which get taken there in disregard of those rules. The situation is analogous to museums with house rules which prohibit photography; compare COM:CSM#MUSEUM. Omphalographer (talk) 20:35, 1 November 2023 (UTC)
- See also Category:Photography prohibition signs. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:17, 3 November 2023 (UTC)
- I was prevented from photographing the fountain in Trafalgar Square in England because commercial photography was prohibited there. On the same day and at the same location, I took pictures of a demonstration demanding the release of "Tommy Robinson". These images have been used by many websites around the world because it was a spontaneous demo that was almost not photographed by journalists, but it was very important because it was about essential things with grooming gangs, Facebook and streaming in courts. My pictures almost didn't exist. The fact that this is not a problem with copyright and FoP is irrelevant if such bans mean that pictures can't be taken in the first place. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:01, 4 November 2023 (UTC)
Hi, Another detective work needed here. May be the geolocation can be added? It seems there is a "Heath Ave" in Spokane, but no "Hath Ave". Or is it an abbreviation for Hatheway? Yann (talk) 16:27, 1 November 2023 (UTC)
- What is the basis to say that what appears to be a family photo "was published in the United States between 1928 and 1977"? Is there any evidence it was ever published before the Flickr upload (if not, then it won't be in the public domain until 2050). - Jmabel ! talk 17:23, 1 November 2023 (UTC)
- Fully agreed. Solid proof of actual publication is needed for these photos, and it is lacking so far. Pi.1415926535 (talk) 17:35, 1 November 2023 (UTC)
- Seeing the written text, this was sent to someone, which constituted publication at the time. See also COM:L#Old orphan works. Practically, there is zero chance that this is still under a copyright. Yann (talk) 20:45, 1 November 2023 (UTC)
- Fully agreed. Solid proof of actual publication is needed for these photos, and it is lacking so far. Pi.1415926535 (talk) 17:35, 1 November 2023 (UTC)
- Text is not Hath but 818 E 26th Ave, Spokane, WA. Looks like both houses are still there. Window pattern of next door seems to match. Glrx (talk) 18:44, 1 November 2023 (UTC)
- Good. Thanks a lot! Yann (talk) 20:45, 1 November 2023 (UTC)
- Maybe someone in WA could send the current residents a postcard with the short URL of the image? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:14, 3 November 2023 (UTC)
November 03[edit]
Problematic MOTD of today (3 November)[edit]
Hello, the MOTD file of today (Template:Motd/2023-11-03), File:Naked News anchor Marina Valmont speaking about German ePetition 157928 to remove social media apps from app shops in Germany if the social media company does not remove anti semitic posts in a timely manner.webm, seems problematic to me. It concerns a call to action to sign a petition (about banning certain social media from German app stores if they don't act on anti-semitism, which in the light of the current Israel/Palestine conflict does unfortunately have a political connotation) and has been authored, uploaded and made MOTD by the same user, User:C.Suthorn. The current file replaced the previous file, File:National Anthem of Dominica by US Navy Band.ogg (made MOTD by User:Q28), in this template yesterday night, with as argumentation a link to Commons:Administrators'_noticeboard/User_problems/Archive_106#Q28, which indeed touches MOTD uploads, but, given the small time window between upload, template change and today, this seems more like an excuse to bring this petition to light on the homepage than anything else. I can't revert this change, as it is currently included on the main page, but I do find this problematic and needs attention as soon as possible, as I'm sure this isn't the way these things are supposed to go, and this file is along Commons also shown on many other wikis. Pennenetui3000 (talk) 00:41, 3 November 2023 (UTC)
- I've also just posted this on the Administrators' Noticeboard. Pennenetui3000 (talk) 00:48, 3 November 2023 (UTC)
- And I responded there. Please don't scatter a discussion like this. In extreme cases (I don't even think it is one) it is appropriate to post on one project page like this pointing to discussion you have opened on another page. It is simply not appropriate to open the same discussion in two places. It almost guarantees unnecessary chaos. - Jmabel ! talk 04:50, 3 November 2023 (UTC)
- I am closing this as a duplicated discussion. Editors may wish to respond at Commons:Administrators' noticeboard#MAIN PAGE: Problematic MOTD of today (3 November). From Hill To Shore (talk) 07:49, 3 November 2023 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. --From Hill To Shore (talk) 07:49, 3 November 2023 (UTC) Have you experienced rotated upload previews ?[edit]
I'm looking for some experiences with rotated images. In Special:Upload and Special:UploadWizard we have some code that displays thumbnails before the upload is completed. When an image has a non-standard orientation (as indicated by EXIF), we have some Javascript which flips the thumbnail you see in this preview, so that it will match the proper orientation that you will also see after you complete the upload.
This was needed, because by default, browsers would NOT apply the orientation of the image, but the thumbnail engine of Wikimedia WOULD apply the correct orientation after upload. It turns out that somewhere in mid 2020 however, all browsers allegedly FLIPPED their default. Since that time they DO apply the EXIF orientation. If I understand things correctly, this would have led to the rotation being applied TWICE in these previews. For instance, you would see an upside down image in the upload preview, and then when the upload completes it would be right side up, or vice versa.
Have people been experiencing this ? There has been a report in phab:T338086, but considering how many cameras use this whenever you have images on the side, and how few complaints there have been so far, for something that essentially has been broken for most people since 2021, I'm wondering if I'm overlooking something. —TheDJ (talk • contribs) 09:49, 3 November 2023 (UTC)
- Definitely seen something like this in the crop tool, not sure I've seen it here. - Jmabel ! talk 19:53, 3 November 2023 (UTC)
Category:Files allowed to be overwritten by everyone[edit]
Can anyone explain; the use of this, on the face of it, spurious cat. Should it not be deleted along with its template? Broichmore (talk) 10:19, 3 November 2023 (UTC)
- It's the result of a very recent development on Commons, whereby user rights for overwriting files that the user themselves haven't uploaded have been limited to autopatrollers and admins in an attempt to curb vandalism. It used to be that all (non-protected) files could be overwritten by anyone, but (at least for now) that's no longer the case. See this discussion at the Village Pump. ReneeWrites (talk) 16:15, 3 November 2023 (UTC)
- What's so special about those files that they can be overwritten by anyone while other files can't be? --Adamant1 (talk) 16:20, 3 November 2023 (UTC)
- They're not really special, they're just files an autopatroller or admin has looked at and agreed to let a user overwrite it after filing a request at COM:OWR. ReneeWrites (talk) 16:51, 3 November 2023 (UTC)
- Hhhmm, maybe I'm misunderstanding something here but it sounds like a request is only meant to allow the person making it to overwrite the file, not everyone. So it seems like files from requests made on COM:OWR shouldn't be included in Category:Files allowed to be overwritten by everyone. Since again, the user making the request isn't "everyone" and their the one being given the permission. --Adamant1 (talk) 17:04, 3 November 2023 (UTC)
- Yeah, I think the template should be removed from files after it's been overwritten, though I haven't seen other editors do that (yet?). I'll shoot GPSLeo a question about it on his talk page, since he files so many of those requests. I don't think it's currently possible to give permission to just one person for just one file, though. ReneeWrites (talk) 17:45, 3 November 2023 (UTC)
- On the question why every user can overwrite these files despite only one user requested the right: This is simply because there is currently no possibility to do this in a different way. It might be possible to add the username to the template, but I think this is not needed as the person who did the requested overwrite would complain about and revert the bad overwrite done by other users. The template is also a workaround as there is no MediaWiki protection level for this. GPSLeo (talk) 19:13, 3 November 2023 (UTC)
- Yeah, I think the template should be removed from files after it's been overwritten, though I haven't seen other editors do that (yet?). I'll shoot GPSLeo a question about it on his talk page, since he files so many of those requests. I don't think it's currently possible to give permission to just one person for just one file, though. ReneeWrites (talk) 17:45, 3 November 2023 (UTC)
- Hhhmm, maybe I'm misunderstanding something here but it sounds like a request is only meant to allow the person making it to overwrite the file, not everyone. So it seems like files from requests made on COM:OWR shouldn't be included in Category:Files allowed to be overwritten by everyone. Since again, the user making the request isn't "everyone" and their the one being given the permission. --Adamant1 (talk) 17:04, 3 November 2023 (UTC)
- They're not really special, they're just files an autopatroller or admin has looked at and agreed to let a user overwrite it after filing a request at COM:OWR. ReneeWrites (talk) 16:51, 3 November 2023 (UTC)
- What's so special about those files that they can be overwritten by anyone while other files can't be? --Adamant1 (talk) 16:20, 3 November 2023 (UTC)