Commons:Village pump

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

Shortcut: COM:VP

↓ Skip to table of contents ↓       ↓ Skip to discussions ↓       ↓ Skip to the last discussion ↓
🌐 Village pumps for other languages
COMMONS DISCUSSION PAGES (index)
Welcome to the Village pump

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

 

Start a new discussion

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 import 2 2 JWilz12345 2022-07-12 05:23
2 Belgian FOP, non-commercial?? 18 6 Ghouston 2022-07-12 11:11
3 Files uploaded via Mobile app have wrong dates 20 8 Misaochan 2022-07-18 17:13
4 Propose statements for the 2022 Election Compass 1 1 Zuz (WMF) 2022-07-11 12:13
5 Two questions 2 2 De728631 2022-07-12 09:33
6 MP4 patents expiration date 9 4 Donald Trung 2022-07-16 06:38
7 How can I batch relicense my works already uploeaded to commons? 3 2 Raccoozzy 2022-07-14 12:07
8 Does the logo File:Super Mario party Logo.jpg exceed the COM:TOO Japan? 2 2 HyperGaruda 2022-07-13 07:59
9 Template:WLM India Wikidata ID 7 4 Jmabel 2022-07-16 17:42
10 Categorization help 5 2 Pigsonthewing 2022-07-14 18:40
11 File moving 5 3 Richardkiwi 2022-07-15 14:42
12 I seriously doubt that this is a photo is of the same person 1 1 Ezzex 2022-07-14 11:56
13 Problems with uploading files above 100 MiB 13 6 Aristeas 2022-07-16 08:26
14 Disable the NewUserMessage extension 7 3 GPSLeo 2022-07-15 12:58
15 Hidden links to sales sites in images 4 3 Arjayay 2022-07-16 12:38
16 Uploaded images' are displayed dark 4 3 Ineuw 2022-07-16 16:55
17 File:Анатолий Чубайс.jpg 4 2 Jmabel 2022-07-16 17:45
18 How would I best go about flagging images with obviously incorrect dates? 10 3 Richard Arthur Norton (1958- ) 2022-07-18 04:07
19 Uploads by Wikiped Meta and some related accounts 3 2 B25es 2022-07-17 18:54
20 About National Geographic maps 3 3 Jmabel 2022-07-17 18:59
21 Photo challenge May results 1 1 Jarekt 2022-07-18 01:52
22 Category renaming request 1 1 Ivangiesen 2022-07-18 12:34
23 National Resources Conservation Service Aerial Photography 1 1 Ivangiesen 2022-07-18 15:05
24 Tiktok 3 3 Ruslik0 2022-07-18 20:33
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 08[edit]

import[edit]

someone import this is now 30 years old iran pd https://en.wikipedia.org/wiki/File:Isfahan_government_logo.svg Baratiiman (talk) 14:41, 8 July 2022 (UTC)[reply]

@Baratiiman see [1], for your information. JWilz12345 (Talk|Contrib's.) 05:23, 12 July 2022 (UTC)[reply]

July 10[edit]

Belgian FOP, non-commercial??[edit]

Apparently, the ManagingIP article on Belgian FOP claims the Belgian FOP, which was introduced in 2016, "non-commercial."

"According to the provision, FOP duly authorises the reproduction and communication to the public of works protected by a copyright, but said reproduction and communication to the public should not affect the normal exploitation of the work, nor cause an unjustified prejudice to the author. This limitation intends to create a good balance between the purpose of the freedom of panorama on the one hand, and the author's rights on the other hand. This limitation notably narrows the exception to non-commercial purpose, as confirmed by the preparatory discussions of the Parliament. It means that any third party cannot invoke the FOP to commercially exploit reproductions of works located in a public area or communicate it to the public without the author's consent."

Is this the real meaning of Belgian FOP clause of: "the reproduction and public communication of visual, graphic or architectural artwork intended to be placed permanently in public places, providing that it concerns the reproduction or communication of the work as it is and that said reproduction or public communication does not affect the normal exploitation of the work and does not unreasonably prejudice the legitimate interests of the author"? Perhaps Wikimedians from Belgium should clarify this. JWilz12345 (Talk|Contrib's.) 01:22, 10 July 2022 (UTC)[reply]

This may be the reason why SABAM still has the guts to restrict free culture uses of the famous Atomium of Brussels. See https://atomium.be/copyright (now claims Belgian FOP is non-commercial). JWilz12345 (Talk|Contrib's.) 02:00, 10 July 2022 (UTC)[reply]
@JWilz12345: If this is true, we should restore {{NoFoP-Belgium}} and delete {{FoP-Belgium}}, many photos of buildings and sculptures, other public arts in Belgium. Ox1997cow (talk) 03:38, 10 July 2022 (UTC)[reply]
@Ox1997cow clarification from Belgian Wikimedians is needed first before making any immediate conclusions. JWilz12345 (Talk|Contrib's.) 03:51, 10 July 2022 (UTC)[reply]
@JWilz12345: I think it's good to have a discussion here too. Ox1997cow (talk) 03:59, 10 July 2022 (UTC)[reply]
Anyway, who are Belgian Wikimedians? Ox1997cow (talk) 04:02, 10 July 2022 (UTC)[reply]
@Ox1997cow that is what I call to every Wikipedian / Wikimedian editor, user, contributor, and photographer from Belgium in general sense. Wikimedia itself is composed of WikiCommons, all Wikipedias, and other wiki-sites managed by Wikimedia Foundation, like Wikivoyage and Wiktionary. I call Wikimedia "Wikimedia-verse" or "Wikimedia universe." JWilz12345 (Talk|Contrib's.) 04:07, 10 July 2022 (UTC)[reply]
@JWilz12345: "Wikipedian" was a typo. I want to see Belgian Wikimedians who know Belgian copyright laws well. Ox1997cow (talk) 04:10, 10 July 2022 (UTC)[reply]
@Ox1997cow no, Wikipedian refers to one who is a regular contributor or user of a particular Wikipedia. Since Wikipedia is the most-recognized site of all under "Wikimedia-verse," there has been a tendency to call everyone involved in "Wikimedia-verse" as Wikipedian even if Wikimedian is a more proper term. Nevertheless let's focus on the Belgian law. JWilz12345 (Talk|Contrib's.) 04:38, 10 July 2022 (UTC)[reply]
@JWilz12345: I see. Ox1997cow (talk) 06:30, 10 July 2022 (UTC)[reply]
@AnneJea, Taketa, Sam.Donvil, and Geertivp: FoPbelgium has been nominated for deletion for being non-commercial only. --C.Suthorn (talk) 05:52, 10 July 2022 (UTC)[reply]
The clause was mentioned in the discussion back in 2016 when the FoP law was introduced. It apparently wasn't considered a show-stopper. Commons:Village_pump/Copyright/Archive/2016/07#Freedom_of_Panorama_in_Belgium. --ghouston (talk) 11:58, 10 July 2022 (UTC)[reply]
Ghouston is right. The Belgian Copyright Act, Art. XI 190 is clear. Please don't waste your time on old discussions. Vysotsky (talk) 14:59, 10 July 2022 (UTC)[reply]
@Vysotsky: however, both the ManagingIP article (apparently contributed by a Belgian lawyer as per the author info) and the SABAM management of Atomium seem to disagree that Belgian FOP allows commercial exploitations of works in public space. Or does the so-called lawyer missed an important point in parliamentary discourse back then? JWilz12345 (Talk|Contrib's.) 15:48, 10 July 2022 (UTC)[reply]
Of course they disagree: they earn their money in the field of copyright. And no, the lawyer didn't miss an important point: she just framed the law in a way more suited to (supposed) copyright owners. Vysotsky (talk) 16:01, 10 July 2022 (UTC)[reply]
Just because this was discussed in 2016, does not mean it was thoroughly and conclusively discussed and that we should dismiss new insights made afterwards. The key part of the clause seems to be ...geen afbreuk doet aan de normale exploitatie van het werk... / ...ne porte pas atteinte à l’exploitation normale de l’œuvre... ("...does not affect the normal exploitation of the work..."). Let's say Atomium inc. sells postcards. If someone else takes a picture of the Atomium per FoP and starts selling it as postcards too, they are competing with Atomium's own postcards, thus affecting Atomium's exploitation. --HyperGaruda (talk) 07:25, 11 July 2022 (UTC)[reply]
The conditions are mentioned in the template. It's not unusual that works published under FoP have restrictions that wouldn't be present in purely freely licenced works. E.g., the condition in Dutch FoP that an object must be depicted as it appears in its public location, or unclear status of derivative works (e.g., you probably can't use photos of a statue to make a copy of the original statue without violating the copyright). --ghouston (talk) 09:54, 11 July 2022 (UTC)[reply]
I searched the web whether Atomium has started legal action, but I did not find anything. Just wait until they do (which I assume they will not, because the FoP is clear). They could easily write a letter to the legal dept of the Wikimedia Foundation without any cost. Still they claim you should pay, per their website. (@Ghouston: By the way, "Dutch" refers to a language, common to a part of Belgium and the Netherlands. If you talk about "Dutch FoP" you will probably mean to say "FoP in the Netherlands, but we can understand, like we understand "Holland" as a pars pro toto for the Netherlands. The low countries have a complex geographic history... our language was even spoken in the Northern part of France, the Flanders area) Ellywa (talk)
en:Dutch, it's idiomatic in English for it to refer to the Netherlands, as well as the language. --ghouston (talk) 11:11, 12 July 2022 (UTC)[reply]

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)[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?[2] Some features of the app might be less stable with older Android versions, especially those with smaller shares nowadays.[3] 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]
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]

Two questions[edit]

  1. How do I remove From Wikimedia Commons, the free media repository posted bellow my nick on my user page?
  2. Is there a way to organize my list of created categories via A-Z template, akin to this sr.wiki version?

Ty. — Sadko (words are wind) 12:58, 11 July 2022 (UTC)[reply]

Hello. I don't know how the table with your articles and categories was created at the Serbian Wikipedia, but I can answer your first question. The string "From Wikimedia Commons..." comes with the skin you are using to view the Commons website. You can change the general appearance in Special:Preferences → "Appearance", where the MonoBook skin for example does not show the Wikimedia Commons credit in that particular place. However, there is no way to remove just that line of text and keep your current skin. De728631 (talk) 09:33, 12 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]

How can I batch relicense my works already uploeaded to commons?[edit]

Hello everyone, I want to relicense some of my works to CC BY, which were previously licensed under CC BY-SA. How can I do it except modify them one by one? --Raccoozzy (Talk) 14:28, 12 July 2022 (UTC)[reply]

You can do that with VFC (Visual File Change). Enter your user name to get a list of your uploads, than choose replace text from the drop down box. However you should not replace the license, but add the new one as a service to existing reusers. --C.Suthorn (talk) 14:40, 12 July 2022 (UTC)[reply]
Thank you, I'll try the VFC.--Raccoozzy (Talk) 12:07, 14 July 2022 (UTC)[reply]

Does the logo File:Super Mario party Logo.jpg exceed the COM:TOO Japan?[edit]

(TOO = Threshold of originality)

Nintendo has not licensed the logo under the CC licence (and it's unlikely they will licence their images under CC licence), but I'm not sure if it exceeds COM:TOO Japan or not. Do you think the lamp dots on the "Super" text exceed the Japanese TOO? Stylez995 (talk) 16:46, 12 July 2022 (UTC)[reply]

Given the examples at COM:TOO Japan (in particular the cup noodles with the wavy line through the text), I'm leaning toward below TOO. If File:Super Mario party Logo.jpg is to be kept, it will need the {{PD-textlogo}} "license" instead of its current CC license. --HyperGaruda (talk) 07:59, 13 July 2022 (UTC)[reply]

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]

Categorization help[edit]

I'm going to categorize File:7876Balete Drive Quezon City Landmarks 47.jpg to something more specific to the image subject, to at least make Category:Balete Drive less "crowded." While it may seem a fence, PropertyCasualry360 says otherwise: According to Merriam-Webster Online, a fence is “a barrier intended to prevent escape or intrusion or to mark a boundary; especially such a barrier made of posts and wire or boards.” A wall is “1a: a high, thick masonry structure forming a long rampart or an enclosure chiefly for defense —often used in plural; b: a masonry fence around a garden, park or estate; c: a structure that serves to hold back pressure (as of water or sliding earth); 2: one of the sides of a room or building connecting floor and ceiling or foundation and roof; 3: the side of a footpath next to buildings.” If this is not a fence, then maybe a wall, but what is the most suited category for this (perimeter/outdoor) wall? JWilz12345 (Talk|Contrib's.) 02:03, 14 July 2022 (UTC)[reply]

Whatever "fence" category you add, the image still belongs in Category:Balete Drive. Or were you thinking of "Fences on Balete Drive" as a subcategory? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:58, 14 July 2022 (UTC)[reply]
@Pigsonthewing: I don't think letting it remain on the category supposedly for the road itself is good in the long term. It causes overpopulation to the category. The road segment adjacent to this structure is File:7876Balete Drive Quezon City Landmarks 45.jpg itself. It is one of the uploads of the infamous uploader Judgefloro (talk · contribs), and doesn't even depict the road itself. But I find it useful, and I think of categorizing it based on the structure is the best way to help slightly depopulate the road category (but raising its quality based on image content). JWilz12345 (Talk|Contrib's.) 16:38, 14 July 2022 (UTC)[reply]
Likely category is Category:Walls in the Philippines as it also includes File:Banga National HS Field SoCo td (2019-12-18) 02.jpg. Perhaps I have found a suitable category for it. JWilz12345 (Talk|Contrib's.) 16:45, 14 July 2022 (UTC)[reply]
Arbitrarily removing images from valid categories, or moving them to orthogonal categories, is not how we deal with overpopulation of categories; indeed to so so is damaging to the project. In any case, even with the image included, Category:Balete Drive has just 296 members; hardly a bothersome quantity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:40, 14 July 2022 (UTC)[reply]

File moving[edit]

A lot of renames give an error. Sometimes it works, when I rename it manually. One time I got this error: "[38511fb1-6b46-40bb-b0fe-bb5e17bea810] 2022-07-14 11:09:46: Fatale fout van type "Wikimedia\Rdbms\DBQueryError"" Does anyone else have problems with renaming? Some files go easy, some not. - Richardkiwi (talk) (talk) 11:13, 14 July 2022 (UTC)[reply]

I also experienced such errors when moving files, I guess since yesterday. Most times I get this error message: “An unknown error occurred in storage backend "local-swift-eqiad".” IMHO the problem seems not to be related to specific files – most times if I try again the renaming works, sometimes it doesn’t. Can I do anything to help with fixing this problem? --Aristeas (talk) 17:02, 14 July 2022 (UTC)[reply]
Richard's issue was a "Lock timeout exceeded" issue. During the request there was no swift issues reported, so its probably unrelated. We've had occasional issues with lock timeouts when moving files for a long time now (I have no idea if its actually a deadlock, or if lock contention is just slow) so this is not really a new issue I think. On the other hand, maybe it was previously fixed, I'm not sure, which could mean something new happened. Looking at logs, there was 19 lock timeouts related to file moves on commons (many for the same file) in the last 15 days (And 1 on en wikipedia). Possibly its just a one off issue, or there was something weird about the file - so i suppose wait and see if it continues to happen. As for helping fix things - in cases where there is a sudden spike in an error that is not new, better flagging it to devs can be helpful, for example by filing tasks in phabricator since the people with the power to fix these things only read VP pages rarely. If you're not sure if an issue should be filed as a phab task, or if anyone is already working on it, you can also ask on #wikimedia-tech irc channel (That said, don't be afraid of politely filing tasks in phab even if you are not sure. If something shouldn't have a task or already has one, it will just be closed which is no big deal). That said, Aristeas: if you're interested in directly contributing to the technical side of Wikimedia websites, let me know, and I can connect you with resources depending on what skills you have and where your interests lie. Bawolff (talk) 05:04, 15 July 2022 (UTC)[reply]
Thank you very much for your comment and help, Bawolff! As far as I can tell file moving seems to work flawless again, so the problem seems to be fixed. That’s great! Richardkiwi, does it work for you again, too?
Thank you also for the information and advise about reporting such technical issues, Bawolff. Next time when such a things happens (and persists for a while) I will try to file a reasonable phabricator task.
I fear that contributing to the technical side of Wikimedia websites is not something I could do; I am fluent in Python (and somewhat in C++, PHP, JavaScript and some more exotic programming stuff), but I have neither any experience in handling big databases nor with all these tools which are used today for handling issues etc. ;–) But thank very much you for your responsiveness and offer!
All the best, --Aristeas (talk) 13:43, 15 July 2022 (UTC)[reply]
No problems anymore with renaming. Great! = Richardkiwi (talk) (talk) 14:42, 15 July 2022 (UTC)[reply]

I seriously doubt that this is a photo is of the same person[edit]

I don't think this photo[4] is of former CNN-host Riz Khan. It's probably another person with the same name. Ezzex (talk) 11:56, 14 July 2022 (UTC)[reply]

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]

Disable the NewUserMessage extension[edit]

Its not very useful to use the NewUserMessage extension to automatically welcome newly-created accounts due to possible:

  • Spam/vandalism-only accounts
  • Long-term abuse (LTA)
  • Unacceptable usernames

So I think anyone may vote here to remove the NewUserMessage extension and instead use {{subst:Welcome}} to manually welcome new users. 105.106.72.151 12:22, 15 July 2022 (UTC)[reply]

Per community consecus, Meta has also removed the NewUserMessage extension for the simillar reasons above. 105.106.72.151 12:33, 15 July 2022 (UTC)[reply]
Prove it. We have welcomed new users for at least a decade.   — Jeff G. ツ please ping or talk to me 12:35, 15 July 2022 (UTC)[reply]
Welcoming a user that is not a vandal or spammer manually after days of registration is better. 105.106.72.151 12:36, 15 July 2022 (UTC)[reply]
Do you want to take on the burden of doing that over 10 million times in the course of 14 years like User:Wikimedia Commons Welcome, and SieBot before that? We have consensus for installing the extension recorded at Commons:Administrators' noticeboard/Archive 9#mw:Extension:NewUserMessage. Also, proposals belong at COM:VPP.   — Jeff G. ツ please ping or talk to me 12:45, 15 July 2022 (UTC)[reply]
See Special:Version and you will see that this is an extension. 105.106.72.151 12:52, 15 July 2022 (UTC)[reply]
With the current development of the Growth tools I think there will be an alternative to the bot message in the future. While waiting for this we can keep the current way as it is not a huge problem and worked for a long time. --GPSLeo (talk) 12:58, 15 July 2022 (UTC)[reply]

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 [5] [6] 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]

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]

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]

July 18[edit]

Photo challenge May results[edit]

Kitchenware: Entries • Votes • Scores
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: Entries • Votes • Scores
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]

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]

Tracked in Phabricator
Task T298684

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]

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