Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

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

Please note:


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

Purposes which do not meet the scope of this page:


Search archives:


 
Water pump next to the church in the town center of Doel. Doel, Beveren, East Flanders, Belgium. [add]
Centralized discussion
See also: Village pump/Proposals • Archive

Template: View • Discuss  • Edit • Watch
# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Files uploaded via Mobile app have wrong dates 28 8 Whym 2022-07-21 09:48
2 MP4 patents expiration date 9 4 Donald Trung 2022-07-16 06:38
3 Template:WLM India Wikidata ID 7 4 Jmabel 2022-07-16 17:42
4 File moving 5 3 Richardkiwi 2022-07-15 14:42
5 Problems with uploading files above 100 MiB 13 6 Aristeas 2022-07-16 08:26
6 Disable the NewUserMessage extension 7 3 GPSLeo 2022-07-15 12:58
7 Hidden links to sales sites in images 4 3 Arjayay 2022-07-16 12:38
8 Uploaded images' are displayed dark 4 3 Ineuw 2022-07-16 16:55
9 File:Анатолий Чубайс.jpg 6 3 Jmabel 2022-07-21 16:46
10 How would I best go about flagging images with obviously incorrect dates? 10 3 Richard Arthur Norton (1958- ) 2022-07-18 04:07
11 Uploads by Wikiped Meta and some related accounts 4 2 Robert Flogaus-Faust 2022-07-22 20:13
12 About National Geographic maps 5 4 Yann 2022-07-20 13:48
13 Photo challenge May results 1 1 Jarekt 2022-07-18 01:52
14 Category renaming request 3 2 HyperGaruda 2022-07-19 06:30
15 National Resources Conservation Service Aerial Photography 1 1 Ivangiesen 2022-07-18 15:05
16 Tiktok 5 3 DragonflySixtyseven 2022-07-19 14:37
17 Movement Strategy and Governance News - Issue 7 1 1 Zuz (WMF) 2022-07-18 22:54
18 Another small improvement to MediaSearch 4 2 Sannita (WMF) 2022-07-22 08:12
19 Ukrainian Govt image upload blocked 3 2 Bjh21 2022-07-22 00:13
20 Finding unlinked images 1 1 Ineuw 2022-07-20 04:16
21 Renaming Category:Toaru Majutsu no Index to Category:A Certain Magical Index, which is currently used as a redirect page 1 1 Centcom08 2022-07-20 10:43
22 Logos 7 2 Jeff G. 2022-07-22 21:03
23 Distribution of files from categories by years 5 3 MasterRus21thCentury 2022-07-21 06:10
24 ERROR IN UPLOAD WIZARD 4 3 GPSLeo 2022-07-20 19:24
25 Announcing the six candidates for the 2022 Board of Trustees election 1 1 Zuz (WMF) 2022-07-20 19:20
26 Maps with Crimea shaded as Russian: Please provide rationale for non-deletion 8 6 GPSLeo 2022-07-21 18:17
27 Move requests 3 3 Jeff G. 2022-07-21 21:09
28 File:Cleveland Municipal Stadium last game played in the stadium December 17, 1995.jpg 2 2 Jmabel 2022-07-22 17:51
29 Can I change the date of an image? 2 2 Bjh21 2022-07-22 19:16
Legend
  • In the last hour
  • In the last day
  • In the last week
  • In the last month
  • More than one month
Manual settings
When exceptions occur,
please check the setting first.
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

July 11[edit]

Files uploaded via Mobile app have wrong dates[edit]

Many of the files uploaded via Mobile app have wrong dates. I have corrected some manually but things are getting out of hands. Please creat a bot which automatically corrects these dates, preferably based on the Upload Wizard engine. --トトト (talk) 01:29, 11 July 2022 (UTC)[reply]

Here's my piece of advice, do not use the Wikimedia Commons mobile app, simply use the mobile version of the MediaWiki Upload Wizard whenever you're on a mobile device. I tried the mobile app a few times and it completely misrepresents what content can be hosted here (it says that only own works are allowed, despite the fact that free works in the public domain exist), it messes with your uploads, and it's not user-friendly at all.
Meanwhile the website works just like the website. Sure there are quite a lot of things that the website does better for desktop users that mobile users don't get, but at least it's functional. I'm convinced that a lightweight web-wrapper would probably make for a better mobile app than the one we have now. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:56, 11 July 2022 (UTC)[reply]
Thank you for your advice. I have notified a user to do so. Why doesn't WMF stop this application from using ? A crap app bringing a mess to the community should be demolished as soon as possible. --トトト (talk) 15:49, 12 July 2022 (UTC)[reply]
Greetings, thank you for your heads-up. I will definitely look into this carefully. A quick glance shows that the dates are correct in several of my updates - but as I say, I will definitely look at this carefully. Again many thanks, Daderot (talk) 16:03, 12 July 2022 (UTC)[reply]
The app uses an exif date, but if there are more dates than one, it may chose the wrong one ("digitized at" - may be the date of fotography. "last edited at", ...). A foto taken with the smartphone will normally not have different dates. C.Suthorn (talk) 16:41, 12 July 2022 (UTC)[reply]
It seems that the app uses the upload date, but claims it is the EXIF date. Is that what you mean? For my purposes, the app is much easier to use than the website from my phone. There seem two things that should be done: 1) fix the app; 2) write the bot described above to correct the erroneous info in commons. Probably many people use the app, so a bot would be much better than hand corrections. cheers, Daderot (talk)
Generally I agree with you. But if nobody fixes it, nor develops a bot for the correction, nothing changes. I myself cannot creat such a bot. Why didn't WMF do anything until now? --トトト (talk) 12:08, 13 July 2022 (UTC)[reply]
Can we have a link to any other file with the same problem, preferably uploaded by a different user? The files reported above were uploaded using an old app ("3.1.1~1c9267ca0" - this dates back to September 2021). This might suggest that the particular version had a bug, but it's also possible that that the two were using the same version might be coincidence. Having more data points would help debugging it. whym (talk) 11:07, 14 July 2022 (UTC) (EDIT: As apparent from comments made by others below, my comment here was a bit misleading. Sorry about that. I was under the impression that the latest release would be 4.x. It is not, although the latest beta release is. whym (talk) 09:48, 21 July 2022 (UTC))[reply]
Pictogram voting info.svg Info Two files I have encountered are via 3.1.1~1c9267ca0.
So, how about this one?
Why a photo taken on 9 July 2022 16:24 (JST, +UTC 9:00) should be in Category:Photographs taken on 2022-07-10? It doesn't make sense. --トトト (talk) 10:11, 15 July 2022 (UTC)[reply]
Pictogram voting info.svg Info File:Archibasis oscillans male 10.jpg via 2.13.2~757c7b008, much older version.
--トトト (talk) 10:20, 15 July 2022 (UTC)[reply]
Thank you for the examples. If someone consistently experiences the problem and other people don't (I personally don't), it is likely to be a problem dependent on devices and other conditions of the phone and the operating system. As a former developer working on the app, I'd like to see what I can do, but this kind of problems can be difficult to deal with, even just to reproduce without having the same device. whym (talk) 14:07, 17 July 2022 (UTC)[reply]
Hi, but this version is the one you'll get on the google play store till now (I really know that because I regularly have to de- and reinstall because of another bug causing complete hanging between uploads). But I also did use the Beta version in the past without success. I can try any version of course. Perhaps it's of help to know that it's the German language version here --Subbass1 (talk) 12:30, 17 July 2022 (UTC)[reply]
Update (edited): the language version is not the issue, but the saving date: if the pictures were edited and stored before uploading, that date will wrongly be used although the exif capture date regularly remains on the files. That really should be fixed asap. ---Subbass1 (talk) 12:45, 17 July 2022 (UTC)[reply]
@Subbass1 What version of Android are you using?[1] Some features of the app might be less stable with older Android versions, especially those with smaller shares nowadays.[2] My phone is Android 12 and the app is 4.0.1~66f8f97d0 (beta version installed from Play Store), and I don't seem to experience the same problem. Also, if you are using a custom camera app, that might be the issue. whym (talk) 14:00, 17 July 2022 (UTC)[reply]
I'm using Andoid 12 and tried both the beta and the normal one you get on the play store. No difference. No custom camera app. And I doubt that timezone is the problem. As I wrote: the app seems to use the saving date (after edits/modifications), although the capture date is still present. Language version/setting also doesn't make a difference. I'm not sure, I think in my very first beginning it was ok (with another phone), but the most of my 15000 files uploaded with the app (huh!) show this problem, mostly it's a thing of a few days, nevertheless. Besides fixing it - yes, it would be a good idea to program a bot to correct it. Add: For editing I use Google Photos. --Subbass1 (talk) 20:45, 17 July 2022 (UTC)[reply]
Thanks for the investigation! Could you please link to one of the files that you uploaded with the beta version, that showcases the problem? I just wanted to check that you were getting v4.0 on beta (as opposed to an older version, which occasionally lingers for a while due to Play Store cache etc issues). Misaochan (talk) 17:13, 18 July 2022 (UTC)[reply]
I don't remember the exact files uploaded with the beta, sorry, that's why I just reinstalled the beta (joining the beta programm on play store), but without success, it regularly quitted completely when calling the settings page, sorry. My last upload (non-beta) is a completely unchanged/-edited picture which was saved not before today, the date is correct here, cause capture and saving date match. The problem only appears (but that's the normal case here) if there are some edits were made online on google photos and so the saving date differs from the capture date. (I then save it locally for "overall view" reasons, but that's not related to this bug (although I know that the quality degrades with every JPG saving) --Subbass1 (talk) 05:33, 19 July 2022 (UTC)[reply]
We hoped that this hypothesis (saving date vs capture date) would be correct, so one of our volunteers managed to test it. Unfortunately his results don't seem to quite match that. Would greatly appreciate anyone's input in that GitHub issue as we try to figure out the cause.Misaochan (talk) 04:26, 19 July 2022 (UTC)[reply]
Thanks fo the GitHub hint, will follow that. I still think that it's capture/saving-related. If these are different (means you edited afterwards), the saving date will be picked up (german: "Speicherzeitpunkt"). --Subbass1 (talk) 06:17, 19 July 2022 (UTC)[reply]
All the examples come with three date fields in the exif. Exception is one file with only one day date difference, that may be timezone difference. The other have the "correct" and "incorrect" date in exif. --C.Suthorn (talk) 17:00, 17 July 2022 (UTC)[reply]
Pinging @Syced: , as an app developer, iirc. --Subbass1 (talk) 11:49, 18 July 2022 (UTC)[reply]
Thanks all for your feedback! I just tried uploading something and it seems that dates are fine, in particular it is not using upload time, but indeed some of my recent uploads with the same smartphone and timezone have the issue. The app is open source, anyone is very welcome to check what could be the issue and post findings on the ticket, I believe this can be fixed once we find out where exactly the problem is, thanks all! Syced (talk) 14:36, 18 July 2022 (UTC)[reply]
@Syced I really don't know what you tried to prove with that upload
?
C.Suthorn (talk) 15:29, 18 July 2022 (UTC)[reply]
Is there a way to find out if any of the uploads with wrong dates were uploaded with v4.0.0 or later? The reason I'm asking is that there are actually two main versions of the app on the Play Store at the moment - the v3.1 version in production and the v4.0 version in beta. v4.0 has been out for a while and we have 3000+ beta users (compared to 7000+ production users), so if this problem is common, it should have been encountered in v4.0 if it exists there. So if it doesn't exist on v4.0, then it sounds like the quickest way we can try to fix the problem would be to push v4.0 to production ASAP. We were initially holding back to try and fix a few remaining bugs in beta, but this issue should take priority, so we will just do a quick release to production in that case. But first we need to know if v4.0 has the same problem.
Sorry for the inconvenience, Android is unfortunately a very difficult platform to target due to the large number of different devices and different OS versions, unlike iOS, and also we are run mostly by a few volunteers and part-timers. We tried a few fixes, but none of the core developers have been able to reproduce the problem, so it has been difficult to ascertain whether our fixes worked. Best, Misaochan (talk) 16:30, 18 July 2022 (UTC)[reply]
No reason for a sorry.. Unfortunately I for myself can't test it at the moment, because the beta doesn't work here at all at the moment (quits by calling the settings page, Android 12, latest update pack for One Plus 9) --Subbass1 (talk) 06:02, 19 July 2022 (UTC)[reply]
Hm, could you submit a crash report for that please? Once it crashes, it should prompt you to send the report to us. Also, not to minimize the Settings issue, but so we can continue work on this problem... is it not possible to try an upload without going to Settings? Misaochan (talk) 10:19, 19 July 2022 (UTC)[reply]
I did hours ago. And ok, it could be possible to use for testing without changing settings. Will try. I guess the date bug itself is tracked down already and will be fixed shortly. Thanks for all your work! --Subbass1 (talk) 18:49, 19 July 2022 (UTC)[reply]
Update: We are currently working with a few people who can reproduce the bug on our GitHub issue tracker. Please note that there actually may be a temporary increase in the number of files with erroneous dates as we are all actively trying to trigger the bug in order to determine the cause and solution. Apologies for that, there is no other option as the Commons beta cluster functions differently in this regard, so we have to try on production Commons. We hope it will pay off in the long run once we can actually solve it. Misaochan (talk) 10:39, 19 July 2022 (UTC)[reply]

MP4 patents expiration date[edit]

The "MPEG-4 Part 14" (also known as "MP4") format was released in October 2001, as far as I know US patents expire 20 (twenty) years after publication. But assuming that they got some crucial patents that stay in force until Late 2022 and early 2023 would that mean that the Wikimedia Commons could then finally host ".MP4" files?

Or is it a lot more complicated than that? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:02, 11 July 2022 (UTC)[reply]

According to Meta-wiki page (m:Have the patents for MPEG-4 Visual expired yet?), the mp4 patents haven't expired yet. If unsure, call your legal expert. --George Ho (talk) 23:42, 11 July 2022 (UTC)[reply]
It is more complicated. ".mp4" is a container format and a camera developer could decide to create his own video or audio encoding and only publish the decoder, but not the encoder, as free software. In that case the MediaWiki-Software would accept some ".mp4"-files, but reject others. Most uploaders would not understand, why this is happening and how to fix (i.e they have to transcode a stream in the file) it. --C.Suthorn (talk) 09:19, 12 July 2022 (UTC)[reply]
C.Suthorn, Well, that doesn't sound like a copyright-related restriction. Can't someone theoretically do that for any file type? -- Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:01, 14 July 2022 (UTC)[reply]
Basically only for container filetypes. In the case of .mp4-files recently HEVC-encoding has been added by smartphone companies. WEBM is also a container format, but is has been created to only include streams with a free format. --C.Suthorn (talk) 17:12, 14 July 2022 (UTC)[reply]

Going over all the reasons for banning MP4 uploads to the Wikimedia Commons I realised something, the "non-free" part isn't a lack of freedom restricting copying, it is a lack of freedom because it's patented proprietary software. This is essentially "a non-copyright restriction" and not an issue of letting re-users copy whatever they want. Non-copyright restrictions are explicitly allowed under the rules of the Wikimedia Commons specifically because a lot of them never expire (think trademarks). If new patented encoders can always be made by new companies but that these videos can still be played on other media players made by unrelated companies, then how would the patented underlying software matter to the encoded content?

I genuinely don't see why we have been shooting ourselves in the foot for decades now over non-copyright restrictions. MP4 is the industry standard and even with all the patents on it basically everyone uses it as the de facto standard because the restrictions placed on it neither harms educational re-use, it doesn't prevent others from altering MP4 content, nor does it prevent people from using MP4 commercially, so what is being restricted here? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:00, 14 July 2022 (UTC)[reply]

To edit a mp4-file you need to reencode it. mp4-decoders are free, mp4-encoders can be free or not. WM phiosophy says, that everything needed to create an entity at MW (article, file, script) has to be free (while a jpg can be created with Photoshop, you can use Gimp instead) --C.Suthorn (talk) 17:12, 14 July 2022 (UTC)[reply]

@Donald Trung: See Commons:Village_pump/Proposals/Archive/2019/11#Proposal 2: Allow uploading of MP4 files, only provide transcoded Webm files to download/stream. Nosferattus (talk) 03:47, 16 July 2022 (UTC)[reply]

Nosferattus, which at the time was overwhelmingly accepted, so why isn't it implemented?;There are tonnes of educational videos not being uploaded to the Wikimedia Commons today purely because that proposal which was overwhelmingly voted for wasn't ever implemented. -- Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 06:38, 16 July 2022 (UTC)[reply]

July 12[edit]

Template:WLM India Wikidata ID[edit]

Template:WLM India Wikidata ID forces every image into the main category for the building being pictured. For example, this image is fixed into Category:Taj Mahal even though it is another subcategory, and this one is fixed into Category:Red Fort. You literally cannot diffuse those main categories and in theory since every image within the Taj Mahal category structure could use the template the main category would contain every image inside it and be unmanageable. Does this make sense? There are 4600 transclusions and for a number I saw, the building is the only category so this will require a manual duplicate categorization before we remove this from the template. I don't think this template is alone in doing this. Ricky81682 (talk) 22:46, 12 July 2022 (UTC)[reply]

{{Kenya Monument}} has the same issue.
There probably should be an argument that lets you override this "automagic" categorization. - Jmabel ! talk 02:34, 13 July 2022 (UTC)[reply]
The template's maintainers probably won't see what you've posted here. Either ping them, or, better, post in its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:31, 13 July 2022 (UTC)[reply]
@Pigsonthewing Already did that. Yeah, it's a larger issue I can see. I just wanted to see if the principle issue was problematic to anyone else. Ricky81682 (talk) 19:17, 13 July 2022 (UTC)[reply]
It's long standing practice to never use templates to add topic (non-hidden) categories. New users not aware of this practice discover the magic of templates and introduce it again.
I've cleaned it up many times before. A bot can directly add the template. In this case replace "{{WLM India Wikidata ID|Q9141}}" with "{{WLM India Wikidata ID|Q9141}}[[Category:{{subst:#invoke:Wikidata|formatStatementsE|item=Q9141|property=p373}}]]" (slightly more complicated to get the new category at the bottom).
After it updated all files, the offending category logic can be removed from the template. Multichill (talk) 21:33, 14 July 2022 (UTC)[reply]
@Ricky81682: ✓ Done the bot added the categories directly and I removed the template based categorization.
@Jmabel: are you sure about {{Kenya Monument}}? Looking at the source it only adds a hidden tracker category. Multichill (talk) 15:18, 16 July 2022 (UTC)[reply]
@Multichill: You're right, I was wrong. - Jmabel ! talk 17:42, 16 July 2022 (UTC)[reply]

July 14[edit]

Problems with uploading files above 100 MiB[edit]

Hey dear Wikimedians,

since the 12th July 2022 (I guess), I have trouble with uploading files larger than 100 MiB. It seems to be a database error. Do you have those problems, too?

Thank you and greetings, --PantheraLeo1359531 😺 (talk) 15:42, 14 July 2022 (UTC)[reply]

@PantheraLeo1359531: I suggest using User:Rillke/bigChunkedUpload.js (doc at User talk:Rillke/bigChunkedUpload.js).   — Jeff G. please ping or talk to me
Error occurred in BigChunkedUpload
@Jeff G.: Unfortunately, this creates the same error. Seems to be a server-side error :( --PantheraLeo1359531 😺 (talk) 16:13, 14 July 2022 (UTC)[reply]
Right now I have problems uploading 20MB files. So far all were re-uploaded at a second attempt. I guess something is not stable at the moment. Ymblanter (talk) 16:26, 14 July 2022 (UTC)[reply]
I uploaded 144MB File:Experience the world's first ski descent of K2 with Andrzej Bargiel.webm earlier today, with one retry.   — Jeff G. please ping or talk to me 16:33, 14 July 2022 (UTC)[reply]
20220713 21 13 52-Fehler in Datenbank "local-swift-eqiad".png
20220714 15 36 38-Assistent zum Hochladen von Dateien – Wikimedia Commons.png
Hm, that's weird :o. I have some other errors like these. Do also larger files work at your upload process? --PantheraLeo1359531 😺 (talk) 16:35, 14 July 2022 (UTC)[reply]
I got a similar, probably the same problem: Uploading a new version of a file (far below 100 MB) I get the error message: “An unknown error occurred in storage backend "local-swift-eqiad".” I already got the same error message several times today when I tried to rename some files. Hm, sounds rather serious … and blocks me, as I wanted to upload a bunch of improved and new photos :–(. Is there anything I can do to help to fix this? Best, --Aristeas (talk) 16:59, 14 July 2022 (UTC)[reply]
Supplement: On a second try the upload worked, but I am still concerned as these error messages sound (for a non-expert like me) like a serious problem. --Aristeas (talk) 17:30, 14 July 2022 (UTC)[reply]
I am actually positivly impressed, that the Upload Wizard now shows meaningful error messages. I did no longer believe something like that would happen.
I am also experiencing errors with uploads, mostly the assembling stage fails. But with retrying I can upload 3.9GiB files. --C.Suthorn (talk) 17:37, 14 July 2022 (UTC)[reply]

In logs, I definitely see a large spike in swift errors starting 16:00 UTC july 12. I filed phab:T313102 Bawolff (talk) 23:10, 14 July 2022 (UTC)[reply]

Tim Starling just restarted the server in question. Hopefully that fixes things. Bawolff (talk) 00:45, 15 July 2022 (UTC)[reply]
@Bawolff: Maybe you can take a look into phab:T309094. Upload has three stages: Upload, Assembling, Publishing. During uploading you can get information from the API (info, warning, error, code fields and uploadprogress), during assembling and publishing polling the API only returns "assembling" or "publishing". There could be returned a progress information in percent and there could be returned additional information (assembling stage: "actually assembling the chunks", "reading metadata from file", "analyzing for embedded URLs or malicious data"; publishing stage: "moving the uploaded file", "inserting/updateing database table XY"). Then users could actually give meaningful error reports to developers. C.Suthorn (talk) 06:32, 15 July 2022 (UTC)[reply]
I've tested with some files I wanted to upload, now it works smooth for me. Thank you :D --PantheraLeo1359531 😺 (talk) 15:07, 15 July 2022 (UTC)[reply]
For me it seems to work fine again, too. Thank you very much, Bawolff! --Aristeas (talk) 08:26, 16 July 2022 (UTC)[reply]

July 15[edit]

Hidden links to sales sites in images[edit]

I noticed that when hovering over the top RH corner of File:Kiara Advani snapped promoting 'Bhool Bhulaiyaa 2'(6).jpg a hidden button called "visual search" appears - which, when clicked, takes me to a sales site. Assuming that we should not be linking to sales sites, please could this be removed?, and any other similar links also removed. Thank you - Arjayay (talk) 12:53, 15 July 2022 (UTC)[reply]

Doesn't happen for me. @Arjayay: can you be more specific about the environment you are running in (browser, OS, skin)? - Jmabel ! talk 14:43, 15 July 2022 (UTC)[reply]
Could be an Edge thing, if it looks anything like this. I use Firefox and this also does not happen for me. --HyperGaruda (talk) 07:40, 16 July 2022 (UTC)[reply]
Thanks Jmabel and HyperGaruda - it turns out to be an "Edge-thing", rather than anything on the commons image - it was the first time I'd seen it, and, having turned it off, it should be the last - thanks again - Arjayay (talk) 12:38, 16 July 2022 (UTC)[reply]

Uploaded images' are displayed dark[edit]

What process creates the various pixel sizes for download? Is it an app that reduces the image when clicked to display? Please note my comment about the displayed size and the original. The uploads are not displayed properly. Please see this original and this screen shot All images appeared darkened. — Ineuw talk 18:35, 15 July 2022 (UTC)[reply]

This is probably because the low-resolution image was uploaded as a .png. See Commons:File_types: "On Wikipedia... PNG thumbnails are not sharpened, but JPEG thumbnails are. For more complicated images, such as photographs, engravings, and such, PNG displays an inferior thumbnail." In my experience PNG often distorts color as well as quality in thumbnails, and I generally only use PNG for rather simple line work or signatures needing transparent background, e.g. here or here (and I'm not even sure the first example is warranted). I think images from Internet Archive/Google Books are almost always better uploaded as JPG, although there might be some good reasons to use PNG for files originally created as such. --Animalparty (talk) 18:55, 15 July 2022 (UTC)[reply]
i dont think this is a sharpening issue. Looks more like a gamma issue or something to do with colour profiles. Maybe https://phabricator.wikimedia.org/T106516 Bawolff (talk) 12:05, 16 July 2022 (UTC) p.s. the image is not dark for me on my phone.[reply]
Thanks for the clarifications. It's very interesting, especially about .png rendering. — Ineuw talk 16:55, 16 July 2022 (UTC)[reply]

File:Анатолий Чубайс.jpg[edit]

Whether these edits [3] [4] can be considered reasonable or should they be reverted? --Xunks (talk) 21:44, 15 July 2022 (UTC)[reply]

  • @Xunks: Seems weird, but since it was marked for speedy deletion anyway, and the time had expired, it's all pretty much moot. - Jmabel ! talk 03:56, 16 July 2022 (UTC)[reply]
    • The problem is the file is still in use in several projects, and it should either be deleted or returned to its original state. And, in my opinion, the initiative of a repeatedly blocked user on unauthorized shadow deletion deserves an administrative assessment. --Xunks (talk) 05:35, 16 July 2022 (UTC)[reply]
      • It should be deleted, but for some reason when I try to delete it, it fails. I believe others have tried as well, hence the current text. - Jmabel ! talk 17:45, 16 July 2022 (UTC)[reply]
        What's the reason why it should be deleted? No reason has been stated in the speedy deletion template, nor in the deletion request discussion. There was a "no permission since", but nothing about why the information on the page isn't sufficient. –LPfi (talk) 15:39, 21 July 2022 (UTC)[reply]
        • I'm not the one who tagged it, but I'm pretty doubtful on the claim of "own work" by a user with no other uploads, and no edits other than adding this image to articles in numerous Wikipedias immediately after uploading it. - Jmabel ! talk 16:46, 21 July 2022 (UTC)[reply]

July 16[edit]

How would I best go about flagging images with obviously incorrect dates?[edit]

Hello! I have noticed an alarmingly widespread problem of files whose dates (and resulting placements in categories) are obviously incorrect. Just take this one single category as an example, which features photographs which obviously were not taken in January. How would I best go about flagging images like these? —VulpesVulpes42 (talk) 16:48, 16 July 2022 (UTC)[reply]

Actually, the problem seems to be so widespread that it may be worth considering a way to flag entire categories like that as well. —VulpesVulpes42 (talk) 17:00, 16 July 2022 (UTC)[reply]
Typically, a bogus January 1 date is an "overprecise" date where all that was really known was the year. I'd just change 2003-01-01 to 2003. - Jmabel ! talk 17:48, 16 July 2022 (UTC)[reply]
@Jmabel: Thank you. But what about files where the years are wrong as well? —VulpesVulpes42 (talk) 19:32, 16 July 2022 (UTC)[reply]
@VulpesVulpes42: are they things you can correct or things you need to flag for someone else to correct? Can you give an example? - Jmabel ! talk 19:43, 16 July 2022 (UTC)[reply]
@Jmabel: I suppose that I could correct some of the dates myself, or at the very least replace the incorrect dates with more honest statements such as "Unknown date". The problem is that this issue is so widespread that it would probably take quite a long time to manually go through all affected files. —VulpesVulpes42 (talk) 19:57, 16 July 2022 (UTC)[reply]
@VulpesVulpes42: Using (for example) VFC to change the date is exactly as easy/hard as using it to add a tag, no? Admittedly, I don't know exactly what you are running into, I'm just thinking of similar stuff I've run across. - Jmabel ! talk 22:20, 16 July 2022 (UTC)[reply]
FWIW, though, you could create an appropriate subcat of Category:To be checked to mark files that need review on this basis. - Jmabel ! talk 22:22, 16 July 2022 (UTC)[reply]
@Jmabel: Alright, thank you for your helpful input. —VulpesVulpes42 (talk) 05:54, 17 July 2022 (UTC)[reply]
  • The entire Bain Collection we store, is marked as "1900" even though they start in 1910 and the current tranche released by the LOC is at 1924 at Flickr Commons. --RAN (talk) 04:07, 18 July 2022 (UTC)[reply]

Uploads by Wikiped Meta and some related accounts[edit]

This morning I moved File:Daniel Adam Beadini, English Wikipedia File, 01.06.2022.jpg uploaded by User:Wikiped Meta from Category:Nature of Switzerland by month to Category:Daniel Beadini. This image can be also found on Mr. Beadini's Instagram account. Then I found that essentially all uploads of this user seem to be material about Mr. Beadini looking promotional, with bad categorization or uncategorized, and without any personality warnings. In addition, there is some derivative work of printed matter (non-free?), such as File:Daniel Adam Beadini - Daniel Adam Beadini Gym.jpg. There is even a file File:Missionary Daniel Beadini in his office in Zurich Seebach, Interview New York Times 17.07.2021.jpg. User:Anton Berger and User:Sir Daniel Adam Beadini uploaded similar material. Is all of this acceptable? This is clearly far from my area of expertise. By the way, there is a Wikipedia article sq:Daniel Adam Beadini with many contributions by "Sir Daniel Adam Beadini", "Anton Berger" and some IPs. The latest one is from "Wikiped Meta". --Robert Flogaus-Faust (talk) 14:33, 16 July 2022 (UTC)
Note: I moved this here from the copyright section because it may concern different things than copyright. Sorry. --Robert Flogaus-Faust (talk) 17:03, 16 July 2022 (UTC)[reply]

I've seen a few photos and I have found one that is promotional (it's something in German saying "¡Apúntate a mi gimnasio!" or something like that, just a piece of advertisement) for what I think there's a something to say "Delete".
Another one, the one you metioned about a missionary in Zürich, I don't know if the person there is a missionary or if the picture was taken in Zürich; I see a man with a beard and I've categorised it as Men with beards. I couldn'i find a category about men with ties, so I didn't categorised it into.
A third photo are two men in a bar or so. No categories applied yet. Category:Unkonown fellows in the World? B25es (talk) 18:54, 17 July 2022 (UTC)[reply]
Alright, thanks. I know that categorization is awful, but most of the images show Mr. Beadini. I suppose that I'll try to categorize some of the images and look up how to file deletion requests for the green flyers or posters. --Robert Flogaus-Faust (talk) 20:13, 22 July 2022 (UTC)[reply]

July 17[edit]

About National Geographic maps[edit]

Appreciated community:

I've noticed that there are maps from National Geographic uploaded to Commons. I wanna know if there are restrictions for uploading maps of National Geographic to Commons. I also want to know if there's any problem if I upload a map of National Geographic with watermark.

Thanks in advance, greetings from Colombia and God bless you. Babelia (talk) 18:12, 17 July 2022 (UTC)[reply]

Would you mind to giva an example, please? I've never popped into any of them. B25es (talk) 18:30, 17 July 2022 (UTC)[reply]
A lot of older National Geographic maps, some as late as 1963, are here because they have fallen out of copyright. @Babelia: do you have any examples more recent than that? I would suspect that any such would not belong here. - Jmabel ! talk 18:59, 17 July 2022 (UTC)[reply]
Appreciated Jmabel: in regards to your request of examples of post-1963 National Geographic maps posted in Commons, I found a relatively recent map (exact year not provided) of Los Angeles, talking about ethnicity in the city.
By the way, thanks for answering my question.
Greetings from Colombia and God bless you. Babelia (talk) 13:39, 20 July 2022 (UTC)[reply]
The license of this file is probably wrong. However it may accepted on Commons under either {{PD-USgov}} or {{PD-CAgov}}. Yann (talk) 13:48, 20 July 2022 (UTC)[reply]

July 18[edit]

Photo challenge May results[edit]

Kitchenware: EntriesVotesScores
Rank 1 2 3
image Alexanderwerk kitchen scale 1910-1920 sm.jpg Preserving jar opener - patended by Havolit - 1950s 2022-05-27 (focus stack).jpg Asando cuy.jpg
Title Alexanderwerk kitchen weight
scale circa 1910-1920
Preserving jar opener - wood,
metal, plastic - patented by
Havolit, manufactured in 1950s
Asando cuy a la brasa a la puerta
de una tienda en Baños (Ecuador)
Author Mariojan photo Franz van Duns Saldeplata
Score 7 5 5
Asian gardens: EntriesVotesScores
Rank 1 2 3
image Water reflection of Kinkaku-ji Temple with a tree on a rock in the pond, Kyoto, Japan.jpg Arakurayama Sengen Park - Japan.jpg Hakone 20220507 174848.jpg
Title Water reflection of Kinkaku-ji
Temple with a tree on a rock
in the pond, Kyoto, Japan
Arakurayama Sengen Park, Asama,
Fujiyoshida, Yamanashi, Japan
Rhododendron garden, Japan
Author Basile Morin Otto Domes Ka23 13
Score 17 9 8

Congratulations to Mariojan photo, Franz van Duns, Saldeplata, Basile Morin, Otto Domes and Ka23 13. -- Jarekt (talk) 01:52, 18 July 2022 (UTC)[reply]

Category renaming request[edit]

Hello! As per the Commons:Rename a category guide, I am posting here to jumpstart a discussion on renaming (and thereby merging) two categories. The two categories are Category:Athens, Georgia and Category:Clarke County, Georgia. Athens (as per the wikipedia page) is a consolidated city-county, which means Athens is the same as Athens-Clarke County. There is no point to have the category Clarke County containing the category Athens, Georgia, because they are the same. I would like to effectively merge the two categories and their associated subcategories and files. While it wouldn't make much difference if Athens, Georgia or Athens-Clarke County, I would propose to follow the naming convention of the other counties in Georgia, i.e. to use Athens-Clarke County. As that would make the most sense for that kind of categorization. I open to other suggestions to help solve this organization problem.--Ivangiesen (talk) 12:34, 18 July 2022 (UTC)[reply]

@Ivangiesen: en:w:Bogart, Georgia and en:w:Winterville, Georgia seem to be part of Clarke County, but not of Athens though. --HyperGaruda (talk) 06:28, 19 July 2022 (UTC)[reply]
Oops, I see this discussion is best held at Commons:Categories for discussion/2022/07/Category:Athens, Georgia. --HyperGaruda (talk) 06:30, 19 July 2022 (UTC)[reply]

National Resources Conservation Service Aerial Photography[edit]

Hello all, I am interested in categorizing/adding aerial pictures from the Soil Conservation Service (SCS) (currently the National Resources Conservation Service) for Clarke County, Georgia. I tried looking through the NRCS category, the Clarke County category and the Georgia category to no avail. I am pretty new here, where should I start if I am looking to reach out to my library about adding their collection to wikicommons? Is this even appropriate? Thank you in advance.--Ivangiesen (talk) 15:05, 18 July 2022 (UTC)[reply]

Tiktok[edit]

Can the content of a Tiktok video be CC-licensed?

Related question: can the image at a specific timestamp in the Tiktok video be CC-licensed? "This screenshot at mm:ss is available per CC-BY-SA; the rest is not" ? DS (talk) 17:54, 18 July 2022 (UTC)[reply]

Related question: May the image (screenshot) of a TikTok video be CC-licensed if it is cropped, edited to remove identifiable icons, etc., from the app? ProfGray (talk) 19:26, 18 July 2022 (UTC)[reply]
A screenshot can be licensed of course as any other still image. On the other hand cropping and removal of icons does not result in creation of a derivative work as the modifications would lack originality. So, in the latter case the modified image cannot be licensed separately from the initial image. Ruslik (talk) 20:33, 18 July 2022 (UTC)[reply]
So, removal of TikTok's app-specific icons or design are not necessary, as long as there's sufficient consent by the TikTok creator of the image (i.e., the video from which the screenshot is taken)? Thanks. ProfGray (talk) 09:25, 19 July 2022 (UTC)[reply]
Sorry, rephrase. a) Does TikTok Corporation present creators with the option of applying the CC license to any content posted on the TikTok platform? b) If so, can a creator specify that the license applies only to a given image within the video, and not to the rest? DS (talk) 14:37, 19 July 2022 (UTC)[reply]

Movement Strategy and Governance News - Issue 7[edit]

Movement Strategy and Governance News
Issue 7, July-September 2022Read the full newsletter


Welcome to the 7th issue of Movement Strategy and Governance News! The newsletter distributes relevant news and events about the implementation of Wikimedia's Movement Strategy recommendations, other relevant topics regarding Movement governance, as well as different projects and activities supported by the Movement Strategy and Governance (MSG) team of the Wikimedia Foundation.

The MSG Newsletter is delivered quarterly, while the more frequent Movement Strategy Weekly will be delivered weekly. Please remember to subscribe here if you would like to receive future issues of this newsletter.

  • Movement sustainability: Wikimedia Foundation's annual sustainability report has been published. (continue reading)
  • Improving user experience: recent improvements on the desktop interface for Wikimedia projects. (continue reading)
  • Safety and inclusion: updates on the revision process of the Universal Code of Conduct Enforcement Guidelines. (continue reading)
  • Equity in decisionmaking: reports from Hubs pilots conversations, recent progress from the Movement Charter Drafting Committee, and a new white paper for futures of participation in the Wikimedia movement. (continue reading)
  • Stakeholders coordination: launch of a helpdesk for Affiliates and volunteer communities working on content partnership. (continue reading)
  • Leadership development: updates on leadership projects by Wikimedia movement organizers in Brazil and Cape Verde. (continue reading)
  • Internal knowledge management: launch of a new portal for technical documentation and community resources. (continue reading)
  • Innovate in free knowledge: high-quality audiovisual resources for scientific experiments and a new toolkit to record oral transcripts. (continue reading)
  • Evaluate, iterate, and adapt: results from the Equity Landscape project pilot (continue reading)

Other news and updates: a new forum to discuss Movement Strategy implementation, upcoming Wikimedia Foundation Board of Trustees election, a new podcast to discuss Movement Strategy, and change of personnel for the Foundation's Movement Strategy and Governance team. (continue reading)

Zuz (WMF) (talk) 22:54, 18 July 2022 (UTC)[reply]

July 19[edit]

Another small improvement to MediaSearch[edit]

Hello everybody! The Structured Data engineering team wants to share with the community another small improvement to MediaSearch: since yesterday, you can get an image suggestion (with a confidence score) for a particular image, by looking up its relevant Wikidata item.

In order to do so, you just have to type custommatch:depicts_or_linked_from=Qxxx in the search mask, where Qxxx is the Qid number of the subject you're looking for.

As an example, custommatch:depicts_or_linked_from=Q146 will return you pictures tagged as depicting cats, custommatch:depicts_or_linked_from=Q144 images depicting dogs, custommatch:depicts_or_linked_from=Q2934 images depicting goats, and so on.

I am here in case you have any questions or requests for more information. -- Sannita (WMF) (talk) 08:51, 19 July 2022 (UTC)[reply]

@Sannita (WMF): How do I see the scores? I am just seeing the normal image results without any scores here. Also, do you know if it is possible to produce this type of query in the API? Thanks! Dominic (talk) 16:40, 19 July 2022 (UTC)[reply]
@Dominic You should be able to see the scores, even though they are just a way to guess how much the image is relevant to the topic... I'll do more investigation about it. Anyway, yes, you can produce the query in the API if you want. Sannita (WMF) (talk) 11:04, 21 July 2022 (UTC)[reply]
@Dominic The score appears in the JSON version of the search, you'll see the _score item that will tell you the relevancy score. I misread the original message from the dev and thought it was visible in the usual interface, my bad. Sannita (WMF) (talk) 08:12, 22 July 2022 (UTC)[reply]

July 20[edit]

Finding unlinked images[edit]

I linked these approx. 1000 images to the matching Wikisource project, but I may have missed linking some. Is there a way to find unlinked images in the categories (volumes 1 to 4). — Ineuw talk 04:16, 20 July 2022 (UTC)[reply]

Renaming Category:Toaru Majutsu no Index to Category:A Certain Magical Index, which is currently used as a redirect page[edit]

Hello! I'm planning to rename the current Category:Toaru Majutsu no Index to Category:A Certain Magical Index because the latter is more appropriate in line with the English title license by the English publisher Yen Press for the light novel. Unfortunately, Category:A Certain Magical Index is currently a redirect page so I'm wondering if the two category pages can switch their places? Thank you so much for your time reading this! Centcom08 (talk) 10:43, 20 July 2022 (UTC)[reply]

Logos[edit]

How re-create logo for Commons? Example. There is description that it was "Vectorised" so what? Eurohunter (talk) 16:46, 20 July 2022 (UTC)[reply]

@Eurohunter: Vectorized SVG logos scale better.   — Jeff G. please ping or talk to me 17:28, 20 July 2022 (UTC)[reply]
@Jeff G.: How to do that? What program to use? I assume he took it from actual video cover and "cleaned" it around (how?) or he created it from scratch (how?)? Eurohunter (talk) 17:32, 20 July 2022 (UTC)[reply]
@Eurohunter: Please see COM:SVG.   — Jeff G. please ping or talk to me 18:49, 20 July 2022 (UTC)[reply]
@Jeff G.: Do you mewan Help:SVG#Convert it? If I press Shift+Alt+B then I can hear error sound. There is no option such as "Trace Bitmap". I think it's not related to Inkskape. Eurohunter (talk) 19:28, 20 July 2022 (UTC)[reply]
@Jeff G.: Do you use Inkscape? Do you know how to undo one move instead of whole few steps if you use Bezier tool? Eurohunter (talk) 17:52, 22 July 2022 (UTC)[reply]
@Eurohunter: No, sorry.   — Jeff G. please ping or talk to me 21:03, 22 July 2022 (UTC)[reply]

Distribution of files from categories by years[edit]

Hello! In March, Wikimedia Commons administrator Butko began modifying some site templates to organize Wikimedia Commons files into child categories. For example, photographs of several departments were sorted by years - the Presidents of Russia, Azerbaijan and Ukraine, the governments of Poland, Russia, Moscow, Tatarstan, the Russian Ministry of Defense, the State Duma and the Federation Council, the Senate of Poland, RIA Novosti, etc. On July 14, I made a request to bot growers, but user Multichill rolled back the edits. What would you say about this? MasterRus21thCentury (talk) 18:44, 20 July 2022 (UTC)[reply]

FYI: Discussion was here - Commons:Bots/Work requests#Distribution of media files by years --Butko (talk) 18:54, 20 July 2022 (UTC)[reply]
Butko, К сожалению, пришлось вынести на общий форум из-за отсутствия ответов с 16 июля. Кроме того, на общем форуме больше участников, которые могут высказать своё мнение по этому поводу и разрешить данный спор. MasterRus21thCentury (talk) 19:40, 20 July 2022 (UTC)[reply]
Templates should only add a hidden tracking category and shouldn't be used to add topic categories, see also the previous topic at #Template:WLM_India_Wikidata_ID. You shouldn't be mixing tracker and topic categories like you're doing at Category:Mos.ru, 2022. The things I'm saying here are long established practices that might even be documented somewhere. Multichill (talk) 21:12, 20 July 2022 (UTC)[reply]
This is somewhat different - at the Federal Archives of Germany, the photos are distributed by year, but with a duplicate in the general category, where there are more than 85 thousand photos. MasterRus21thCentury (talk) 06:10, 21 July 2022 (UTC)[reply]
That shouldn't have been done either, fixed.
You and Butko have absolutely no community consensus to re-introduce the system of automatic categorization based on templates. So don't revert me and don't ask Butko to do it. Multichill (talk) 09:41, 23 July 2022 (UTC)[reply]

ERROR IN UPLOAD WIZARD[edit]

Hello.

When I want to upload a file with this, I have this error message : [9c798435-10e0-40ca-8267-17ee3b691ea1] 2022-07-20 18:50:39: Erreur fatale de type « Error ».

Why ?

Regards.

--ComputerHotline (talk) 18:53, 20 July 2022 (UTC)[reply]

Mine reads as follows:
Internal error
[cfa31650-998d-4c3a-9770-82d7f8b790b9] 2022-07-20 18:55:43: Fatal exception of type "Error"
  — Jeff G. please ping or talk to me 18:56, 20 July 2022 (UTC)[reply]
Yes. --ComputerHotline (talk) 19:06, 20 July 2022 (UTC)[reply]
This is not UploadWizard bug. There is a server problem affecting all uploads. The workaround is just trying to upload the file again then it works most the times. --GPSLeo (talk) 19:24, 20 July 2022 (UTC)[reply]

Announcing the six candidates for the 2022 Board of Trustees election[edit]

Hi everyone,

The Affiliate Representatives have completed their voting period. The selected 2022 Board of Trustees candidates are:

You may see more information about the Results and Statistics of this Board election.

The Affiliate organizations selected representatives to vote on behalf of the Affiliate organization. The Affiliate Representatives proposed questions for the candidates to answer in mid-June. These answers from candidates and the information provided from the Analysis Committee provided support for the representatives as they made their decision.

Please take a moment to appreciate the Affiliate Representatives and Analysis Committee members for taking part in this process and helping to grow the Board of Trustees in capacity and diversity. These hours of volunteer work connect us across understanding and perspective. Thank you for your participation.

Thank you to the community members who put themselves forward as candidates for the Board of Trustees. Considering joining the Board of Trustees is no small decision. The time and dedication candidates have shown to this point speaks to their commitment to this movement. Congratulations to those candidates who have been selected. A great amount of appreciation and gratitude for those candidates not selected. Please continue to share your leadership with Wikimedia.

What can voters do now?

Review the results of the Affiliate selection process.

Read more here about the next steps in the 2022 Board of Trustee election.

Best,

Movement Strategy and Governance

This message was sent on behalf of the Board Selection Task Force and the Elections Committee

Zuz (WMF) (talk) 19:20, 20 July 2022 (UTC)[reply]

Maps with Crimea shaded as Russian: Please provide rationale for non-deletion[edit]

Several maps created by user Stasyan117, where Crimea is shaded as Russian, has been suggested deleted. I sympathise with why they have been nominated for deletion, since Crimea is Ukrainian and occupied, whilst the author of the map (who by their own account “lives in Russia”), has shaded Crimea as belonging to the occupier.

The maps may therefore easily be perceived as Russian propaganda. That's what they look like to me, and presumably to other readers too, since there have been deletion suggestions.

Currently, even just a single map (Map of Russia - Moscow Oblast.svg) is used across 18 language editions of Wikipedia, and on some of the editions on several articles, e.g., on 32 articles on the Czech version. As such, this single map alone may be perceived as poisoning rather a large number of Wikipedia articles with pro-Russian, anti-Ukranian propaganda.

Under the current circumstance of active warfare between the nations, why are these maps allowed to be kept? Isn't Wikipedia supposed to be neutral and fact-based? Bjornte (talk) 21:24, 20 July 2022 (UTC)[reply]

  • Pinging @Stasyan117.
  • Usually in cases of disputes like this, Commons remains neutral: we can host multiple maps giving different versions of the same thing. The different Wikipedias (etc.) can then choose which to use. But there can be some issues about how the description says what the map represents.
  • @Bjornte: I'm assuming this is about File:Map of Russia - Moscow Oblast.svg, File:Map of Russia - Tver Oblast.svg, and File:Map of Russia - Kabardino-Balkaria.svg.
  • It is possible that we may want somehow to indicate on maps of Russia from recent years whether they represent the generally internationally recognized borders or includes territories that Russia itself claims, but to which its claims are not generally recognized. Or someone could create maps that "shade" disputed territories differently. Similar issues exist many places in the world (e.g., quite near there, the breakaway Transistrian portion of Moldova). You might look to examples like that for how it is handled for other countries. I've never looked very deeply into it. It is always useful in a case where there is any dispute for the description of a map to indicate whose view of the matter it represents. - Jmabel ! talk 22:42, 20 July 2022 (UTC)[reply]
    • Yes, a map, drawing, photograph or other media item that is a lie belongs in Commons as a record of someone lying. We can of course say it's a lie or that it's the POV of the mistaken side of a controversy or some such thing, but the documentary evidence of the lying ought to remain. This definitely includes maps that falsely claim someone else's territory. Jim.henderson (talk) 22:59, 20 July 2022 (UTC)[reply]
@Bjornte: I think the simplest answer to your question is "Commons is not Wikipedia". Where Wikipedia tries to find a single "Neutral Point of View", Commons' approach is to host files that allow for any reasonable point of view to be depicted. "Crimea is currently occupied by Russia" is such a reasonable point of view. We also have a rule, COM:INUSE, that says that files that are in use on other Wikimedia projects are treated as being useful, so they're not deleted even if they're factually inaccurate.
Fundamentally, Commons believes that editorial matters, including which version of a map to use, are a matter for each Wikipedia to determine, and shouldn't be imposed on Wikipedias by Commons. Commons is here to serve the Wikipedias (and other projects), not to control them. This means that if you want your favourite Wikipedia to stop using a particular map, the place to make this happen is on that Wikipedia. --bjh21 (talk) 11:16, 21 July 2022 (UTC)[reply]
Commons should make it obvious when a file depicts a disputed view. In this case the files aren't useful for Commons per se, as they aren't made by an entity of interest, such as the Russian government, but by a single contributor, whose views we aren't interested in documenting. Still, if any project thinks they are worthwhile, it is not up to Commons to think otherwise. –LPfi (talk) 16:03, 21 July 2022 (UTC)[reply]

In general every map needs to include in the description whether the map shows the de jure or de facto status of the borders. In this case we can just write "de facto" in the description and upload another version with the "de jure" status. What file is the better one to be used always depends on the use case. As one example for travel planning de facto maps are much more important than de jure maps. --GPSLeo (talk) 16:13, 21 July 2022 (UTC)[reply]

Stating "de facto" isn't enough, as it isn't obvious what the difference is. Would Mariupol be "de facto" Russian as of today? Would Donetsk be (some claim the government is a puppet one)? The same with "de jure". I assume that as soon as Russia declared the Crimea Russian, it is "de jure" Russian – according to Russian jurisdiction. How many countries need to recognise Kosovo before it is de jure independent? Editors and readers of Wikipedia need to see by a glance at the description page that a file may be problematic. –LPfi (talk) 16:26, 21 July 2022 (UTC)[reply]
The de jure status is defined be the UN. An occupation is no de facto state because it does not have regular executive structures. But of course what "de facto" means also depends on the usage of the map. The explanation why some areas are included in the map and some are not should be explained in the description. But a short description only saying "XYZ with de facto borders" is no reason for deletion. --GPSLeo (talk) 18:17, 21 July 2022 (UTC)[reply]

July 21[edit]

Move requests[edit]

Hi, not particularly familiar with all the workings on Commons, I just see how some things here affect WP. I'm looking to have Category:492d Bombardment Group (United States Army Air Forces) moved to "Category:492nd Bombardment Group (United States Army Air Forces)", and the associated pages there moved as well. Would also like to see this applied to any other pages with numbers ending in "2d" and "3d", instead of the correct ordinals of "2nd" and "3rd". Thanks - wolf 19:53, 21 July 2022 (UTC)[reply]

@Thewolfchild: Where are you getting these spellings?   — Jeff G. please ping or talk to me 21:09, 21 July 2022 (UTC)[reply]

July 22[edit]

File:Cleveland Municipal Stadium last game played in the stadium December 17, 1995.jpg[edit]

This image was uploaded by User:Escapedtowisconsin in 2008. They also uploaded a higher-resolution version of the photo on Flickr, but not under a compatible license. More recently, User:Angelgreat uploaded the higher-quality version over the older file. Was this an acceptable action, or is the newer upload a copyright violation? User:Escapedtowisconsin hasn't been active for many years, so we can't easily ask them. - Eureka Lott 16:02, 22 July 2022 (UTC)[reply]

  • As I understand it, unless someone is explicit about licensing only the lower-resolution version of an image, we presume that the license also applies to higher resolutions. - Jmabel ! talk 17:51, 22 July 2022 (UTC)[reply]

Can I change the date of an image?[edit]

浅草寺境内 露天風景(羽子板市).jpg

For example the image on the right is certainly not from 1899. All other images uploaded by the same user (User Uploads) have the same date. Am I allowed to simply change it to the date of upload? --Lupe (talk) 18:43, 22 July 2022 (UTC)[reply]

@Lupe: In general I wouldn't just assume that the upload date is the date the photo was taken. Better to put {{other date|?}} to mark the date as unknown, or maybe {{other date|<|2015-04-23}} to indicate it was taken before some date. In some cases you might be able to get a good date from the Exif metadata at the bottom of the page and stick that it {{Exif date}}. In this case, though, the "Date and time of data generation" is unknown, which is a bit odd. You could assume that the "Date and time of digitising" is also the time when the photo was taken, though I wouldn't. --bjh21 (talk) 19:16, 22 July 2022 (UTC)[reply]
30.12.1899 is OLE automation date ("Excel date") start point and was likely autogenerated when the EXIF "Date and time of data generation" is unknown. That date can certainly be removed, or like Bjh21 says you can use {{other date|<|2015-04-23}}. MKFI (talk) 07:16, 23 July 2022 (UTC)[reply]

July 23[edit]