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
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/2024/10.

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

# 💭 Title 💬 👥 🙋 Last editor 🕒 (UTC)
1 Proposal: AI generated images must be clear they're AI in the file name 107 38 Minoa 2024-10-16 10:35
2 Hosting HDR images as JPEG with gain map 0 0
3 New reports: categories with only redcats & cats with only infobox cats 45 9 Enyavar 2024-10-21 10:09
4 OsmappBot uploads from the OpenStreetMap app 6 5 Zbytovsky 2024-10-16 08:15
5 Category:Minority schools, etc. 5 4 LPfi 2024-10-20 09:48
6 Change in editing behaviour for keyboard shortcuts? 3 1 Mike Peel 2024-10-15 08:45
7 Category:Meanna 5 4 LPfi 2024-10-20 10:01
8 Page about empty categories? 8 4 Prototyperspective 2024-10-15 20:25
9 Moving from one data item to another in SDC 3 2 Smiley.toerist 2024-10-15 17:46
10 Google's semi-censorship of Wikimedia Commons must end 22 9 Prototyperspective 2024-10-20 16:46
11 Admin action rational 16 7 Just Step Sideways 2024-10-19 22:13
12 Collecting encouragement and support 1 1 RoyZuo 2024-10-15 17:25
13 Need Help Add Image to Page 4 2 Starlighsky 2024-10-16 11:05
14 Link a file in a <gallery> to a Category 3 2 JotaCartas 2024-10-16 11:51
15 Best practices for reverse image search 3 3 Richard Arthur Norton (1958- ) 2024-10-17 14:39
16 IP edit edit confirmation 1 1 GPSLeo 2024-10-16 16:55
17 UploadWizard gives author as "Example" 5 2 Sannita (WMF) 2024-10-22 08:49
18 Seeking volunteers to join several of the movement’s committees 1 1 Keegan (WMF) 2024-10-16 23:07
19 Needing help with a requested cropping. 7 4 Jmabel 2024-10-18 07:43
20 Automatic detection of potentially problematic domains in UploadWizard 1 1 Sannita (WMF) 2024-10-17 17:11
21 Has this image been reversed? 5 3 Broichmore 2024-10-19 11:06
22 Genuine historical images relegated to art 2 2 ReneeWrites 2024-10-18 14:40
23 More junk data being added to 'depicts' statements 2 2 RoyZuo 2024-10-20 14:30
24 AF-n Audio File Babel Boxes 1 1 -αβοοδ 2024-10-18 19:25
25 {{cl|Toy shops}} and {{cl|Toy stores}} 3 2 トトト 2024-10-19 07:10
26 How should I indicate the source of these images 6 4 Enhancing999 2024-10-19 19:27
27 How to handle a widespread hoax flag used as official flag? 14 8 Ellywa 2024-10-22 22:14
28 Special:Upload 4 4 Jmabel 2024-10-20 17:00
29 Usage of "on Wikipedia" header for subjects that have multiple Wikipedia articles 34 7 Enhancing999 2024-10-20 20:56
30 Close discussion 1 1 Микола Василечко 2024-10-20 10:27
31 Improve search? 2 2 Prototyperspective 2024-10-20 18:41
32 Use of "opaque" background request template on photographic images 15 5 Koavf 2024-10-21 19:46
33 New report: Category cycles 5 2 Prototyperspective 2024-10-22 20:58
34 Photo challenge August results 1 1 Jarekt 2024-10-20 22:12
35 Template:Commons Archive 4 3 Koavf 2024-10-21 21:02
36 Question about images with serial but non destructive watermarks 3 2 LucaLindholm 2024-10-22 22:54
37 Accusation about "vandalizing" without giving reasons 2 2 Commander Keane 2024-10-22 22:20
38 Non-deletion decision File:19-23-038-davis.jpg 7 4 Glrx 2024-10-22 20:58
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.
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.

September 11

Proposal: AI generated images must be clear they're AI in the file name

Now these are being used for a good purpose (reporting on the misuse of AI at en:Wikipedia:Signpost) so please don't just nominate them for deletion, but look at these filenames:

File:Amoeba moving.jpg File:Leukocytes.jpg

Now I've moved them to File:AI genetated image of... - but that's just actively setting people up to use semi-believable illustrations that have no scientific accuracy, and then making it relatively hard to catch what happened.

Should we be somewhat stricter about filenames for AI? There's cases where I think it matters less than these, but the capacity to mislead is high. Adam Cuerden (talk) 10:01, 11 September 2024 (UTC)[reply]

Oh, there's also File:Cancer cell.jpg, now File:AI generated image of a cancer cell.jpg which is not used anywhere, and looks ridiculously misleading. That's just the AI giving the cell its own tumor. Actually, maybe that should be in that article about misleading AI Adam Cuerden (talk) 10:05, 11 September 2024 (UTC)[reply]
File names for AI generated images not indicating that's what they are is definitely an issue. There's no reason there shouldn't be some indication in the file name that an image is AI generated. I think it would be in alignment with the changes to guideline on how to name files that was passed recently to. Regardless, file names should be as descriptive as possible and I can't see why that information shouldn't be included in the file name. --Adamant1 (talk) 11:02, 11 September 2024 (UTC)[reply]
An alternative would be to add a tag to the media without requiring files to be moved or named with that in the title from the start. Just like any NSFW image has an indicator for that on sites like reddit. It would be shown on all files in Category:AI-generated images either at the end of the file-title or e.g. within a corner of the thumbnail. I think adding that automatically would be better. However, when uploading the file using the Upload Wizard and checking made with AI one could also automatically append (AI-generated) or (made using AI) to the file-title. Prototyperspective (talk) 11:29, 11 September 2024 (UTC)[reply]
Is it really misleading if people cant be arsed to even read the template? Trade (talk) 11:30, 11 September 2024 (UTC)[reply]
The template only shows on the file page. And even there it doesn't look very different from other common license templates which people only interested in the content usually probably don't look at either and many files like the linked examples don't even have these templates. Prototyperspective (talk) 12:47, 11 September 2024 (UTC)[reply]
 Support The file name and caption are the first things you see when you select an image that's used on Wikipedia for better viewing, right before you click through to the file's own page. For most people it'll probably be the only information they'll see. This information is absolutely important enough that it should be mentioned in the file name. ReneeWrites (talk) 13:03, 11 September 2024 (UTC)[reply]
 Support per ReneeWrites. I agree that having AI generated marked in the file name will give Wikipedia users much more transparency on the provenance of files. William Graham (talk) 15:36, 11 September 2024 (UTC)[reply]
 Oppose. Nice idea, but I prefer templates that can be translated and add properties. Latin letters in a filename are not a good clue in other scripts. We may have endless rename requests. File naming hacks are also not systematic; we do not routinely encode other properties in filenames. Glrx (talk) 15:47, 11 September 2024 (UTC)[reply]
At the same time, an actively misleading filename is a problem. They are not leucocytes (for example. They don't even look much like cells. AI is very good at creating images that look like they're plausible depictions but really aren't, they just ape the - for lack of a better word - art style of real scientific illustrations, coloured electron microscope depictions, and so on. Adam Cuerden (talk) 16:05, 11 September 2024 (UTC)[reply]
we do not routinely encode other properties in filenames - We routinely use naming systems like "Flag of [Country]" for other types of files. Using filenames to make important disclosures about the origin of files isn't a huge leap. Omphalographer (talk) 19:11, 11 September 2024 (UTC)[reply]
@Omphalographer, Well said. -- Ooligan (talk) 17:11, 12 September 2024 (UTC)[reply]
  •  Support Update with caveat: my support is for this idea in principle, with the understanding that we would need an additional discussion about implementation to cover things like wording. — Rhododendrites talk |  12:32, 12 September 2024 (UTC) This is a good idea, and in line with the spirit of many off-wiki policies proposed for AI content. It also doesn't preclude a template. The question, though, is what label/language should be used. It would need to be something someone wouldn't choose accidentally for a non-AI image. Also, documentation for this rule would need to be clear that we're talking about media that is produced through generative AI models (as opposed to, say, a scientific visualization in which machine learning was used somewhere in the process). — Rhododendrites talk |  16:10, 11 September 2024 (UTC)[reply]
    I wouldn't be too concerned about language necessarily. If the filename is not in a language people speak, they're much more likely to check the decription. We don't need a perfect solution, just an improvement. Adam Cuerden (talk) 16:14, 11 September 2024 (UTC)[reply]
  • Comment - This is a good idea, but it needs refinement. Besides Rhododendrites's caveat's above, I think it should only apply to images which depict something in a realistic manner. There's not much point requiring this for something like File:Portrait of a Unicorn.png. Otherwise, I would only support it as a recommendation, not a requirement. Nosferattus (talk) 18:21, 11 September 2024 (UTC)[reply]
    I'd say there's a class of images where it matters less. But a human-made illustration probably has some effort to get key aspects, whatever those might be. AI just tries to get something that looks like other images with similar key words, and might miss out important bits that a human wouldn't. Honestly, as a general rule, the higher the likelihood it'd be used on Wikipedia, the more that's an issue. Adam Cuerden (talk) 19:34, 11 September 2024 (UTC)[reply]
    Agreed on Nosferattus' conditional support: images that can be mistaken for something else, should be marked, and the filename is the most obvious place to do so. By the way, this also applies to photoshop fabrications of "real life flower elfs" etc. And from a filemover perspective: We are supposed to only rename files that are realistically going to be kept. Is there even a rationale to keep misleading non-scientific AI illustrations? I mean, beyond illustrating how you can't trust AI illustrations? --Enyavar (talk) 00:01, 13 September 2024 (UTC)[reply]
    Aye. These couple are useful to illustrate the problem, but we certainly don't need more. Adam Cuerden (talk) 15:22, 14 September 2024 (UTC)[reply]
     Oppose for now, unless proposal is substantially modified to address concerns above. Nosferattus (talk) 16:53, 15 September 2024 (UTC)[reply]
  •  Support, as we should use any (and all) means to achieve maximum transparency for re-users about the non-authenticity of AI-generated images. --Túrelio (talk) 18:27, 11 September 2024 (UTC)[reply]
  •  Support: I don't see any downside. One remark, though: like everything else on Commons, this should not be restricted to English, and I don't imagine I would recognize something if it were marked in Chinese as AI. How do we intend to deal with the multilingual aspect of this? - Jmabel ! talk 19:32, 11 September 2024 (UTC)[reply]
    As I said above, I think that perfection isn't needed. If it's labelled in Chinese, as long as the whole filename is in Chinese, Anglosphere people will presumably go to the description. They might not for one that has a plausible English filename. Adam Cuerden (talk) 19:37, 11 September 2024 (UTC)[reply]
    Yep. In a Czech file name, the warning should be in Czech, and in a Japanese file name, in Japanese - tailored to the native languages these images are likely to get used for. And if I'm that determined to use a cool image with Tamil filename in the German WP, I the user must make sure to understand the filename and description. (GTranslate exists.) --Enyavar (talk) 00:10, 13 September 2024 (UTC)[reply]
  •  Support: Let´s do it. Transparency first. Alexpl (talk) 20:11, 11 September 2024 (UTC)[reply]
 Support as a general idea. Would this extend to AI-upscaled images, which can get very strange at the deep end? Belbury (talk) 20:39, 11 September 2024 (UTC)[reply]
How do I unsee that image?! Omphalographer (talk) 22:58, 11 September 2024 (UTC)[reply]
Extremely disturbing heh Bedivere (talk) 04:49, 12 September 2024 (UTC)[reply]
 Comment from a filemover. If you want to apply this requirement to files after upload, you should amend Commons:File renaming to make it clear that lacking a statement of AI-generation in the filename is good cause for renaming. Either by adding a new numbered criterion or by finding a way to shoehorn it into an existing one (2 or 3, I'd guess). --bjh21 (talk) 21:01, 11 September 2024 (UTC)[reply]
@Bjh21: You could argue, in clear cases like the ones I mentioned earlier, it's already covered by 2, since they aren't actually pictures of (say) leukocyctes, but I agree that adding an example would help. Adam Cuerden (talk) 20:40, 12 September 2024 (UTC)[reply]
@Adam Cuerden: I think you mean 3 (obvious error), and I agree that would cover clear cases like those. But there are other cases that I don't think would be covered, like File:White generic hatchback.png or File:Wikimedia LGBT+ graphic illustration 1.png. --bjh21 (talk) 21:48, 12 September 2024 (UTC)[reply]
Fair. Adam Cuerden (talk) 10:01, 13 September 2024 (UTC)[reply]
It'd be nice to expand criterion 2 to allow adding information about the non-factual nature of an image in general (e.g. AI generated images, simulations, reenactments, historical reconstructions, artistic representations, etc). Omphalographer (talk) 22:40, 13 September 2024 (UTC)[reply]
Aye. Certainly in the spirit of, but explicitly permitted never hurt. Adam Cuerden (talk) 15:23, 14 September 2024 (UTC)[reply]
 Support, probably difficult to enforce though given the backlogs of other bad file names needing renaming (screenshot, whatsapp, etc). Gnomingstuff (talk) 22:28, 11 September 2024 (UTC)[reply]
 Support AI generated images must have "AI" in the file name as a principle, perhaps even better would be "AI generated", which is more clear. And always at least in Latin letters. Yes, the backlog might be a problem, but we can start now for new uploads. --JopkeB (talk) 05:12, 12 September 2024 (UTC)[reply]
What do people think about when uploading the file using the Upload Wizard and checking made with AI one could also automatically append (AI-generated) or (made using AI) to the file-title? (No replies on that above or on the idea of a tag displayed dynamically next to the file-title and in the thumbnail.) I think doing something automatically and in a standardized way would be better than just requiring this which many uploaders will not follow up on. Prototyperspective (talk) 10:49, 12 September 2024 (UTC)[reply]
Given that the Upload Wizard already asks about AI tools, I think it would be appropriate for it to ensure that uploads using them follow whatever policy arises from this discussion. --bjh21 (talk) 17:26, 12 September 2024 (UTC)[reply]
 Support. on top of this, if we need to rename these files, i suggest requiring the new name to begin with " «AI generated» " or " ~AI generated ". this will make them appear behind all ascii letters when sorted alphabetically. RoyZuo (talk) 13:58, 12 September 2024 (UTC)[reply]
If you want to change where something sorts, I think it's better to do it using {{DEFAULTSORT}} rather than by requiring a particular pattern in the filename. --bjh21 (talk) 15:46, 12 September 2024 (UTC)[reply]
@Bjh21, Can we do both? -- Ooligan (talk) 16:47, 12 September 2024 (UTC)[reply]
@Ooligan: I can't see why you would want to, but you certainly can. --bjh21 (talk) 17:23, 12 September 2024 (UTC)[reply]
this is just an idea that can be done with no extra cost, when the file will be renamed anyway. RoyZuo (talk) 20:50, 12 September 2024 (UTC)[reply]
Probably doable through the AI templates. Something like {{DEFAULTSORT:«{{BASEPAGENAME}}}} Adam Cuerden (talk) 21:05, 12 September 2024 (UTC)[reply]
Please no. This makes file names unnecessarily difficult to type - most keyboards don't have «» keys, and ~ is difficult to find on many mobile devices. The goal is to label these files, not to make them difficult to use. Omphalographer (talk) 22:53, 12 September 2024 (UTC)[reply]
Agreed. DEFAULTSORT is the better solution for de-prioritizing AI images. ReneeWrites (talk) 07:23, 13 September 2024 (UTC)[reply]
+3. Adding special characters to file names should be banned. --Adamant1 (talk) 07:42, 13 September 2024 (UTC)[reply]
It really depends on the meaning of "Special", lest we ban, say, Korean file names, or accents. We have French filenames with French-style quotes in them, and we shouldn't change those. At the same time, we have default sort; let's not make it a policy to name AI images File:💩AI generated💩 Foobar.jpg Adam Cuerden (talk) 10:03, 13 September 2024 (UTC)[reply]
That's not really what I'm talking about. I don't think arbitrary putting brackets in file names is useful though. Maybe circle brackets, but «» or ~. If for no other reason then most keyboards don't have them to begin with. I'm also super annoyed by file names with emojis them though. They should 100% be banned. I'd be totally fine with requiring people put (AI generated image) at the end of a file name though. --Adamant1 (talk) 10:50, 13 September 2024 (UTC)[reply]
Aye, merely trying to avoid bad policy coming out of this. Should we append characters at the start of filenames to deprioritise them? No. That's a job for {{DEFAULTSORT}}. But «» are the standard quotes used in French, so we shouldn't ban their use, lest we require bad French. I'm a little bit of a stickler for trying to avoid policy for one situation that screws up other situations. Adam Cuerden (talk) 15:38, 14 September 2024 (UTC)[reply]
Keep it simple. Just put "AI" infront of the filename. Those who want to know more can check the summary / category of a file for details. Alexpl (talk) 11:06, 13 September 2024 (UTC)[reply]
Please rather put it at the end of the filename. Moreover, "AI" is ambiguous and also included in many other files, so again I'd suggest (AI-generated) or (made using AI) and this could be appended to the initial file-titles automatically in the Upload Wizard. Prototyperspective (talk) 11:24, 13 September 2024 (UTC)[reply]
the thing is, if you prepend filenames with A, it's counterproductive to your aim (discouraging use of ai files as illustrations) because then all the ai files will occupy the front rows in categories (unless you add defaultsort of a super "late" unicode to the ai template). RoyZuo (talk) 18:34, 16 September 2024 (UTC)[reply]
  •  Comment Why do we even accept AI generated images to begin with? Most of them are misleading, useless for Wikipedia articles, fake-y look as standalone content, and can be barely trusted. AI images should only be limited to very specific scenarios, otherwise we end up with a bunch of superheros holding the Commons logo, which we can all agree is largely a set of very interesting trademark violations and not consistent with community practices. Moreover, there have been recently a number of court cases around copyright infringement for several of these AI companies, so I'm concerned that we can't distinguish the provenance from different models that may or may not be trained on infringing datasets. We have no idea how this is going to be regulated.
Scann (talk) 00:12, 17 September 2024 (UTC)[reply]
No thing such as "infringing datasets" exist Trade (talk) 20:42, 20 September 2024 (UTC)[reply]
 Support it is misleading when the filename implies a photo or similar Immanuelle ❤️💚💙 (please tag me) 14:05, 25 September 2024 (UTC)[reply]
 Oppose File names should not be used like this; the proper way is to use multilingual templates. Thuresson (talk) 20:52, 4 October 2024 (UTC)[reply]
templates are good too. modern_primat ඞඞඞ ----TALK 18:28, 11 October 2024 (UTC)[reply]

Working out changes

I'm sensing pretty widespread support, so let's plan out what would need changed:

  1. Commons:File renaming: #2 gains "To identify AI generated works" with a possible more general version of "to point out major manipulations" (colourization, etc). This is explicitly allowed to be in any language.
  2. Commons:AI-generated media notes that the AI-generation must be mentioned in the filename, ideally in the same language as the rest of the filename.
  3. File upload wizard appends "AI generated" if the AI creation option is ticked, with the option to change this after, but with a note saying that identifying AI art in filenames is important. Alternatively, this can just be a soft prompt, that suggests a new filename, but doesn't require. (Similar to others where you can click "ignore and upload file anyway)
  4. Possibly, {{PD-algorithm}} and similar can be edited to add a {{DEFAULTSORT}} to move AI works lower in categories.

Have I missed anything, and anyone have suggestions? Adam Cuerden (talk) 19:55, 14 September 2024 (UTC)[reply]

I think #4 should either not be implemented or be for files in Category:AI misgeneration. Images shouldn't be sorted by how they were produced but by by where the user is expecting to find them / looking for them or generally the relevance and quality of the image as it relates to the category concept, not the method/techniques used to produce it. You may have missed an addition to Commons:File naming. Prototyperspective (talk) 20:40, 14 September 2024 (UTC)[reply]
Added File naming, and you're probably right about #4. Wanted to pull all the suggestions made, but that may be too much (if nothing else, AI image categories wouldn't do the headers for first letter of filename). Adam Cuerden (talk) 11:44, 15 September 2024 (UTC)[reply]
#3 and #4 are terrible ideas. #3 will cause uploader confusion, filename conflicts, language issues, etc. This needs to be done by humans, not machines. #4 will also be confusing as no one will expect {{PD-algorithm}} to mess with the sorting. Plus it's just unneeded and potentially unhelpful, as there may be other reasons an AI-generated file needs to be sorted in a particular way. Nosferattus (talk) 17:05, 15 September 2024 (UTC)[reply]
I don't think they're terrible ideas, but I don't think these two are needed. We're not inundated with such a flood of AI-generated images being uploaded to Commons that these couldn't be done by hand, and a lot more people have filemover rights than admin rights, so this wouldn't add to the backlog of issues needing admin attention. ReneeWrites (talk) 09:46, 16 September 2024 (UTC)[reply]
Okay. Then let's focus on points 1, 1b, and 2. For 1b, I'm thinking (under "Clear")
"Where an image, either through method of creation or modifications, might mislead, this should be noted in the filename. This includes AI generation, colourization of a photograph, turning a sepia image black and white, upscaling an image, and other things that might not be immediately obvious. Simple, minor fixes do not need to be noted."
Too much? Adam Cuerden (talk) 10:56, 16 September 2024 (UTC)[reply]
This discussion is about AI, and I think we should stick with that. I've seen way too many discussions get killed the moment they gain any traction because people keep attaching stuff to it that is tangentially related that no consensus was reached on. ReneeWrites (talk) 15:22, 16 September 2024 (UTC)[reply]
Okay. Let's get this implemented, and any further additions can be discussed on the talk pages after? Adam Cuerden (talk) 17:41, 16 September 2024 (UTC)[reply]
1a:  Support "To identify AI generated works" sounds good to me.
1b:  Comment I think it would be more at home under "Descriptive", specifically the subheader "Correct". There's nothing particularly unclear about the filename "Cancer cell.jpg", but it leaves out a lot of pretty crucial context that makes it pretty misleading.
I'd like to propose this change: Correct – The name should describe the file's content and convey what the subject is actually called. Inaccurate names for the file subject, although they may be common, should be avoided. The title given to a work of art by the artist that created it is considered appropriate, even if the name has nothing to do with what is depicted (for example, many works of Dadaism). The name should also be free of obvious errors, such as misspelled proper nouns, incorrect dates, and misidentified objects or organisms. Users are allowed to upload "unidentified" or "unknown" organisms but such files may be renamed upon identification. AI-generated images must disclose this fact in the file name.
It's tempting to include a bit on the rationale as to why, but none of the other examples have that either, they simply state what is policy. So I think addressing this with just one line that's clear and unambiguous is both pragmatic and in line with how the rest is written. ReneeWrites (talk) 15:50, 16 September 2024 (UTC)[reply]
Sounds good. Adam Cuerden (talk) 17:42, 16 September 2024 (UTC)[reply]
Made a slight adjustment to the wording. A lot of the file names on Commons made with Dall-E or Midjourney have that in their file name, which should also cover this base. ReneeWrites (talk) 08:42, 17 September 2024 (UTC)[reply]
Could maybe move it a sentence later to keep the talk about organisms together. Adam Cuerden (talk) 09:43, 17 September 2024 (UTC)[reply]
Good idea, I moved the sentence. ReneeWrites (talk) 11:17, 17 September 2024 (UTC)[reply]
Okay. If no-one else has suggestions after a couple days, let's bring 1, 1b (with your text), and 2 together, ping everyone involved in the original discussion, and implement. Secondary ideas can be considered after that. Adam Cuerden (talk) 17:21, 17 September 2024 (UTC)[reply]
May be worth a clear call on whether AI upscaled photos should fall under "AI generated" for all this, given their similar potential for being misleading when the viewer doesn't realise that an AI was involved (eg. File:2Pac Passport (cropped).jpg, where one Wikipedia editor was pleased to find what they described as a "free-use authentic high quality photograph" of the subject on Commons, but no, it's just an upscale of an old and extremely low quality passport photo). Belbury (talk) 12:58, 25 September 2024 (UTC)[reply]
It's not AI-generated, it's AI-upscaled which is very different. It needs separate templates and categories which also warn the user about issues like potential inaccuracies. Prototyperspective (talk) 13:35, 25 September 2024 (UTC)[reply]
It's different, but if there's going to be a policy change on naming and negative-boosting AI content, we should be clear whether that also applies to AI upscaling or whether it doesn't apply to it at all. Some users already (very understandably) tick "I generated this work using an artificial intelligence tool" when uploading an AI-upscaled image, causing it to be incorrectly filed as {{PD-algorithm}} with no human authorship. Belbury (talk) 14:17, 25 September 2024 (UTC)[reply]
I think when this is checked the Upload Wizard should show another checkbox about whether img2img (an input image) was used or whether upscaling was used. If the former is checked, the user should enter some url to the input image(s). If the latter, it would add the template for AI upscaled image. Prototyperspective (talk) 14:21, 25 September 2024 (UTC)[reply]
  •  Support further development - I think that the potential for abusing AI is something we have to address, but I am going to kindly ask that the details of the proposal should be developed further. Therefore, I support further development of this proposal into a draft policy or something like that. --Minoa (talk) 10:35, 16 October 2024 (UTC)[reply]

Upload wizards capacity

I note in this AI discussion that the upload wizard asks the question of is it ai generated, so its possible that appending to file names or adding a template to identify AI generated media could be relatively easy to do automatically at upload. with a high degreee of consistance Gnangarra 01:06, 17 September 2024 (UTC)[reply]

This was mentioned a couple of times, but there is currently not enough support (or opposition) to reach a consensus on this. ReneeWrites (talk) 09:42, 17 September 2024 (UTC)[reply]
I'd say that's probably something to bring up after the policy changes go through. Though I am surprised a template isn't already auto-added. Adam Cuerden (talk) 17:20, 17 September 2024 (UTC)[reply]
{{PD-algorithm}} is already added to any upload where this box is ticked, in addition to the licence template specified by the uploader.
It's worth remembering that some users tick this box in error, fairly regularly. Any additional effects of ticking it will require additional steps of cleanup in that minority of cases. Belbury (talk) 13:46, 19 September 2024 (UTC)[reply]
 Support both suggestions, specially the automated AI template placement which should already be there. Darwin Ahoy! 10:47, 18 September 2024 (UTC)[reply]
Pinging @Sannita (WMF) Darwin Ahoy! 13:30, 19 September 2024 (UTC)[reply]
@DarwIn I already relayed the idea of adding automatically a template, if I remember correctly something is already added. Anyway, if there is community consensus to add a(nother) specific template, I can relay this too and discuss it with the team. It's going to take some time anyway. Sannita (WMF) (talk) 13:47, 19 September 2024 (UTC)[reply]
Yes, {{PD-algorithm}} is already automatically added when the checkbox in UploadWizard is selected. I tested today by uploading this image. the wub "?!" 15:12, 19 September 2024 (UTC)[reply]

AI enhancement/improvement/upscaling

I've started a discussion that is marginally related to this topic at Commons_talk:AI-generated_media#AI_enhancements/improvements/upscaling, which may or may not depend on this outcome. Bastique ☎ appelez-moi! 21:17, 4 October 2024 (UTC)[reply]

September 23

Hosting HDR images as JPEG with gain map

The tools for creating and displaying High Dynamic Range (HDR) images are starting to mature. HDR displays can render much brighter highlights than before, which leads to a big qualitative improvement in an image. Software for HDR production, and web-browser support, are becoming wide-spread. (Note that this is distinct from the tone-mapped HDR images you may have seen for the past decade or so.)

This post is partly a response to User:Hym3242 and User:PantheraLeo1359531 in Commons:Village pump/Archive/2024/08#Can I upload bt2020nc/bt2020/smpte2084(PQ) HDR AVIF images to commons and use them in wikipedia articles?. I was wondering the same thing, so I uploaded a couple files to see how well Commons would support them. They are formatted as JPEG with a gain map. The promise of this format is that it is backward-compatible with systems that process and serve standard JPEG. The base image is a JPEG, usable on any device. HDR information is inserted in the file as metadata. In the worst case HDR metadata is lost, resulting in a standard image. In the best case HDR metadata is preserved, the end-user has an HDR-capable display and web browser, and the image looks great.

My test results are at Category:HDR gain-mapped images. Both images survived the process of uploading and rendering previews. HDR metadata was stripped from preview images, but preserved in the original uploads. If you have a newish HDR screen and a compliant web browser, the originals of this house and this church will appear brighter than usual. The effect on the house is subtle, limited to where sunlight hits white paint. The effect on the church is more dramatic: the windows should appear much brighter than the rest of the interior.

Most users of Commons images will see one of the smaller standard files, so for now the benefits of publishing this sort of content are limited. Are there any downsides to publishing it on Commons?

This post isn't marked as a proposal, because hosting these images on Commons works already. At a later date, when the standards are settled and the hardware is widely available, it would be nice to preserve HDR metadata in the generated preview images. — Preceding unsigned comment added by Semiautonomous (talk • contribs) 23:51, 23 September 2024 (UTC)[reply]

October 07

New reports: categories with only redcats & cats with only infobox cats

I just set up these two new reports as an addendum to Special:UncategorizedCategories.

  1. Commons:Report UncategorizedCategories with redcats (Quarry:query/86864, 10583 items)
    categories that have only nonexisting categories set (redlinks)
  2. Commons:Report UncategorizedCategories with only infobox categories (Quarry:query/86867, 4475 items)
    categories that only have meta categories set by the Wikidata infobox like Category:Uses of Wikidata Infobox

The request for these reports to get updated by a bot instead of manually is here at Commons:Bots/Work requests.

I requested the Quarry query here so a big thanks to Matěj Suchánek who implemented it. (Collaboration like this makes everyone more productive and saves time as well as making each one's expertise/skills/knowledge more fruitful.)

In previous discussions about uncategorized categories I clarified multiple times that these categories are also missing categories or have issues but don't yet have a report where they show up. What I did not know at first is that this could be solved via a Quarry query and what the place to request such queries is.

Most of the categories on these reports need some work. So if you're interested in helping out please take a look, especially if you already have experience with cutting down the Special:UncategorizedCategories list. You can add /Page_1 to the two report links if you want to see only a small sample of the first 500 items.

Lots of work needed there. Probably, the list will not grow back as quickly as the entirely uncategorized cats in UncategorizedCategories.

--Prototyperspective (talk) 17:12, 7 October 2024 (UTC) edited wl--Prototyperspective (talk) 21:00, 20 October 2024 (UTC)[reply]

Thanks for putting this together! Any chance it could be formatted as a table instead of a comma-separated list? That'd make it a lot easier to work with. Omphalographer (talk) 22:28, 7 October 2024 (UTC)[reply]
I thought so at first but then found it would be easier if one was able to see just as many items as possible in one view. One can see lots of links without having to scroll around. The link color changes once you visited the pages so e.g. row-numbers don't add anything. A table would be useful if there were more columns....maybe at some point there could be additional columns that show e.g. whether a category only has 1 file (or the count of files) but I currently don't see how that would be useful (if anything that could go into a separate report page). Is there any reason you'd prefer a table? It wouldn't be difficult to convert it to a table but I don't see what advantage it would have. Maybe you mean a table with multiple columns but only these wikilinks instead of a one-column table but then I wouldn't see the difference to the current format. One thing that may be useful is a page with raw URLs so one can open many of these in new tabs at once (select and drag onto a tab or right click->open in new tabs). Prototyperspective (talk) 22:36, 7 October 2024 (UTC)[reply]
There's one way a table format may be useful: making it possible to sort these alphabetically. However, the query could be changed to order the categories that way without losing the advantages of the comma separated list which I think only needs ORDER BY page_title DESC in the query (probably will be done before the next report update). Prototyperspective (talk) 22:43, 7 October 2024 (UTC)[reply]
I, for one, find the current format very off-putting (but thank you for doing this at all).
It's OK if we have a format that doesn't end up showing everything in one view while there is so much to show. People will whittle down the list pretty quickly, in my experience, and it can be re-run periodically. It doesn't matter if not everything is in front of people at once while the content is still voluminous; it's a lot more important for this sort of task that what is in front of us is sane to skim. - Jmabel ! talk 20:51, 9 October 2024 (UTC)[reply]
Alright the question is simply which other format would be better and why? Currently this is only one link and doesn't even other data for other columns and people often dislike things at first they are not familiar with. Prototyperspective (talk) 21:48, 9 October 2024 (UTC)[reply]
If a list format would be better the page would be very large and I don't know if it causes other problems but one would have to scroll a lot. Without alphabetic sorting, a list format makes less sense. But I guess once the new version is sorted it could be easier to skim or skip over similarly named items if it was in a list format. Maybe there could be multiple columns so the page isn't so large. Prototyperspective (talk) 21:58, 9 October 2024 (UTC)[reply]
A wiki table (with one row for each category) would be easiest to work with. Even if the report itself isn't sorted, presenting it as a table will allow users to sort it themselves. Omphalographer (talk) 22:16, 9 October 2024 (UTC)[reply]
The report has been updated now. It has the same sorting as before (no ORDER BY SQL added) but now has a table format so it can be sorted alphabetically by clicking on the column header. Moreover, empty categories have been split off from the report. Prototyperspective (talk) 12:45, 12 October 2024 (UTC)[reply]
Pretty hard to figure out any kind of pattern in that list. Maybe a simple word count helps. I used that when the "uncategorized" reports were longer. It allows to fix several similar ones at once. Sample wordcount (some "words" are years or other numbers): from 7899, Fire 7879, Sanborn 7877, Insurance 7877, Map 7876, County 7525, in 1170, North 829, Oklahoma 681, Texas 572, Rhine-Westphalia 546, California 546, New 537, Pennsylvania 513, Washington 492, Missouri 464, of 382, 1911 356, 1909 346, Carolina 332, 1912 328, 1910 324, Ohio 317, Jersey 317, Montana 296, 1914 287, 1913 282, Oregon 281, Indiana 272, Kansas 271, 1921 266, 1908 256, 1915 255, 1920 245, 1916 245, 1922 242, Georgia 241, 1905 235, Florida 232, Virginia 222, Maine 219, City 218, by 212, South 207, 1904 203, 1917 194, 1901 190, 1900 180, Massachusetts 178, West 176, 1919 175.
 ∞∞ Enhancing999 (talk) 23:46, 7 October 2024 (UTC)[reply]
Thanks. At the next update it will be sorted alphabetically, maybe that helps. I noticed most of the Rhine-Westphalia cats do have categories but they have been set by a template by the first and only edit by XrayBot and I don't know how to best make such categories disappear from the report – one example for that would be to have a query show all cats included there that have a template set (which usually sets cats) so all of them could get a nulledit to remove all which do have a category from the report (that's just an example, I don't think that's readily possible). Prototyperspective (talk) 09:23, 8 October 2024 (UTC)[reply]
  • Updated the reports. Down to 1965 now after Sanborn maps cats (thanks Enhancing999 for that) as well as empty cats (separate report) have been taken care of. The one with only infobox categories now has 4364 items (but so far didn't have the empty cats get deleted).
Prototyperspective (talk) 09:39, 15 October 2024 (UTC)[reply]
Second was also updated and is at 4106 but it's probably better to cut down on the report of cats with only redcats because the cats with only Infobox cats can be solved via some tool/script that syncs their categories with ENWP. Prototyperspective (talk) 21:02, 20 October 2024 (UTC)[reply]

Sanborn maps categories

Looking at the Sanborn categories, it appears someone ran a script to dump content on the site and then walked away from it. Why is it anyone else's responsibility to clean up their messes for them? RadioKAOS / Talk to me, Billy / Transmissions 13:45, 8 October 2024 (UTC)[reply]
You can use this report to ask the respective people. e.g. @Nowakki:
Also when it comes to files like those in Category:Sanborn Fire Insurance Map from Syracuse, Onondage County, New York, 1911, Volume 2 I have suggested that instead of dumping 110 niche files 1911 onto WMC that clutter search results and putting them into categories, it would be better if one instead uploads one document/PDF file. Prototyperspective (talk) 14:34, 8 October 2024 (UTC)[reply]
I uploaded the files with the intent of creating the most best collection of sanborn maps anywhere.
Not only did i fail to find a single person with the slightest enthusiasm for it, but i encountered a number of obstacles. At first i tried to slalom around and through the stupidity, but it was going to be a long process of grinding through ever more peanut brainery, so i started a vote to give me the necessary authority to shove it aside and to flip the switch on the bureaucrats (of which i conversed with a total of at least 5, who were all not talking to each other) in one stroke of genius. I lost the vote, so i pulled the plug on the enterprise. As a bonus, i witnessed a bunch of people who most be on probation or something, manually rename 20000 files, because nobody writes scripts for them, and i learned that commons cannot reliably rename files and the ticket is 10 or so years old (i think there was more than one ticket in that general problem domain). It is not possible to work on a data-mega-center on complex issues if the number of people with a problem solving attitude hovers around 0%. Nowakki (talk) 18:05, 8 October 2024 (UTC)[reply]
@Nowakki: Hi, Your intend is good, but your working process isn't. 1. You shouldn't count on anyone else to fix problems you created with your uploads. 2. You should have start slowly, only uploading a few dozens or hundreds of files, and check if everything was OK before uploading gazillions of files, where the problems have overcome you. Yann (talk) 20:19, 8 October 2024 (UTC)[reply]
Nobody cared about sanborn maps until they suddenly started caring in the middle of the upload campaign. Even after the debate was over involving more than 5 people, at no point did a person appear who was in charge of these maps. I can compensate for lack of leadership with initiative, but if you don't want my sanborn power-user setup, then you don't want it. Nowakki (talk) 20:43, 8 October 2024 (UTC)[reply]
I run into similar issues myself sometimes where people criticize and attack me for doing things that are supposedly controversial. But it's almost impossible to know what is or isn't going to trigger any of the over sensitive snowflakes on here or otherwise cause a controversy until after the fact. There's really no way what-so-ever to know before doing something what random nonsense is going to be an issue or otherwise cause problems though. And good luck getting anyone who throws a fit about it to actually help you fix the issue. Which 100% they should if their the ones making an issue out of it to begin with. More on topic, is there a reason that a bot can't just add parent categories to the ones for Sanborn maps? --Adamant1 (talk) 23:35, 9 October 2024 (UTC)[reply]
Creating the categories is easy. Just got to find somebody to devise a scheme and write a bot.
I had something in the making like so: User:Nowakki/test3 for the city-level category pages, which i presume all the redcats are pointing to. Nowakki (talk) 04:30, 10 October 2024 (UTC)[reply]
@Adamant1: I spent like two weeks or so writing code for this. I don't really need anyone to do anything, except give me mass rename privilege for a selected number of files.
Isn't there a way to override borderline imbecile snowflakes, who have the power to vote, with the help of specially trained overlords who act in the interest of progress being made? Nowakki (talk) 12:30, 10 October 2024 (UTC)[reply]
It is a simple and straightforward process to request filer mover permissions which enables you to use the massrename tool. Prototyperspective (talk) 13:11, 10 October 2024 (UTC)[reply]
I think people who refused the privilege back then were using about as many brain cells as you just did when you imagined you knew how to be of help. Nowakki (talk) 13:35, 10 October 2024 (UTC)[reply]
You're quite condescending, even more than Adamant1 here once again. I prefer you do not upload these files versus uploading them the way you did. Apply again with the info why you need these permissions. Prototyperspective (talk) 13:45, 10 October 2024 (UTC)[reply]
Somebody should step in and clear a way through the bureaucratic bloat. Then it will be a team effort. Nowakki (talk) 14:05, 10 October 2024 (UTC)[reply]
Yeah well, I find your attitude towards Nowakki rather patronizing myself. I don't think it really helps to go off about how they shouldn't have uploaded the files to begin with at this point. Different strokes for different folks I guess. I'm sure your the one who's in the right here though just because your acting more agitated about it then I am.
More on topic, the files have already been uploaded. So the question is what to do about it now. I'm a little fuzzy on the original details, but assuming this mainly (or only) has to do with uncategorized categories then I don't see what renaming the files would have to do with it. Someone could use User:Nowakki/test3 as a starting point to create the categories through a bot edit. Then the file names could hopefully be fixed in the future, but that's tangential to creating the categories. Or I assume it is. Someone can correct me if I'm wrong on that though. --Adamant1 (talk) 22:09, 10 October 2024 (UTC)[reply]
I'm not agitated at all and nowhere was I acting patronizingly or condescendingly towards Nowakki. I don't really care about this case at all. A user asked about it and I looked at the history page and pinged the respective user, then Nowakki said there's problems with renaming without any further details and I helpfully mentioned this can be done by requesting file-moving rights, that's all. Yes, the question is what to do about the files & cats now. The answer to your question of what file naming has to do it is that Nowakki wrote […] except give me mass rename privilege for a selected number of files. Prototyperspective (talk) 22:24, 10 October 2024 (UTC)[reply]
I think you were. We'll have to disagree though. But that's not all you said. You seem to have a real problem with being patronizing towards other users and then trying to weasel out of it by acting like everything you said was totally innocent and on topic when it wasn't. Regardless, I think the best way to deal with this is by doing a bot edit based on User:Nowakki/test3. But I have other things to do myself. So someone else is going to have to do it, but that would be my suggestion. I see you asked Nowakki to create a bot request. So at least we're in agreement about it. --Adamant1 (talk) 22:56, 10 October 2024 (UTC)[reply]
@Nowakki: Creating the categories is easy. Just got to find somebody to devise a scheme and write a bot. Could you please create a Bot work request with the details? and if you don't really need anyone to do anything, except give me mass rename privilege for a selected number of files could you please request these permissions? Thanks for your efforts so far. Prototyperspective (talk) 22:45, 10 October 2024 (UTC)[reply]
The Sanborn map collection needs to be fixed properly. If you fix the categories you are hiding an indicator that it is broken, which will make the real problem worse. I would therefore advise you to not touch it and move on.
You can copy+paste the above to where to redlink cats problem is being discussed, so they know that a fix is nontrivial and it will be fixed together with the underlying problem eventually. Nowakki (talk) 23:19, 10 October 2024 (UTC)[reply]
What about just up-merging the files to more general ones and deleting the categories their currently in outright then? Or conversely the files could just be mass nominated for deletion. That sounds like a less then optimal solution though lol. --Adamant1 (talk) 23:26, 10 October 2024 (UTC)[reply]
If you delete them now they might have to be downloaded again when somebody wants them. Therefore that should be not an option.
You are thinking of ways to hide indicators of a problem. To me that is a character flaw. Nowakki (talk) 23:43, 10 October 2024 (UTC)[reply]
I'm a little hazy on the details, but from what I remember your proposal to rename the files was rejected. So that's clearly not an option. I don't think just leaving the categories as is really helps either. So what's your suggestion to deal with the issue aside from leaving the red links or renaming the files when that already failed? --Adamant1 (talk) 23:46, 10 October 2024 (UTC)[reply]
I only state my original proposition. You can proceed in any way you see fit. I would advise you to develop a scheme that make the sanborn map collection awesome and then implement it. Nowakki (talk) 23:50, 10 October 2024 (UTC)[reply]

The above discussion has gotten terribly convoluted. If there are things that one or more of the participants wish to see happen, could you please each state those, without a bunch of cross-talk? - Jmabel ! talk 07:45, 11 October 2024 (UTC)[reply]

I think this short comment sums it up. I do not understand Nowakki's reply to it. It's unclear what is meant with needs to be fixed properly. And it's also unclear what is meant with I would advise you to develop a scheme that […]. If somebody understands what exactly needs to be done or is proposed please explain it briefly and if not I repeat my question for Nowakki to create a request with the explanation/details. Prototyperspective (talk) 09:37, 11 October 2024 (UTC)[reply]
You are right, the underlying issue has never been properly explained to you.
User:Nowakki/test3
hover over the links in the right column.
The filenames for map files prior to 1900 are bad. They were chosen by a not so brilliant coworker who came ahead of me.
The map files after 1900 have a better naming scheme.
If you think this is a cosmetic change, click on one of the files named "ind". The plate number and LOC sequential IDs don't match for the old scheme. It's broken. Suppose you were to run the index through OCR. With the old scheme, you need a separate database to map plate numbers to files. Unsustainable stupidity.
The index page should be generated for each city when the above issue has been resolved. Nowakki (talk) 11:41, 11 October 2024 (UTC)[reply]
Alright, thanks for explaining! That was the missing info. If you requested file-mover permissions and it was declined that doesn't mean you can't apply again. I think it the permissions will be granted if you provide them with this info. If not, you could also check what else is required to get these permissions but I don't see why the request would fail so please request the file-moving permissions, afterwards you could make use of the mass rename tool and implement the filetitle changes. Prototyperspective (talk) 15:40, 11 October 2024 (UTC)[reply]
If I wanted file mover privileges I could have requested them at any time since January. I just came here to talk about stupidity. Nowakki (talk) 17:06, 11 October 2024 (UTC)[reply]
@Nowakki: Not a very productive thing to do. There is not a lot we can do with "I'd rather have my grievance than a solution." - Jmabel ! talk 06:07, 12 October 2024 (UTC)[reply]
You need at least a few people who can do what you perceive to be an impossible feat. Nowakki (talk) 06:47, 12 October 2024 (UTC)[reply]
Agree. Not sure what the user is up to now when writing sth like that.
What about throwing all of these Sanborn cats into a flat category (for now)? Also maybe they should be separated from the report (if they are in a flat category they wouldn't show up in it anymore anyway). Prototyperspective (talk) 12:42, 12 October 2024 (UTC)[reply]
Or remove them from the report, then they don't show up in the report. Nowakki (talk) 12:55, 12 October 2024 (UTC)[reply]
My 2 cents: When it comes to categorizing, I would prefer that Sanborn maps are sorted into cats as follows: Most importantly capsuled in their own categories, always. --> Otherwise, they clutter any categories they are placed in, and are difficult to handle. These are mass-produced cadastral building plans in such a detailed scale that people would not really even classify them as "maps" under some definitions.
  • Sanborn maps by states (e.g. Category:Sanborn maps of Maine (or Category:Sanborn maps of Essex County, Massachusetts, if there are sufficient numbers per County) --> This ensures that Sanborn maps are differentiated by the states for those who want to search for them by state overview, but they still don't clutter the direct "Maps of Maine" categories.
  • Old maps of Uvw County, Xyz-State (e.g. Category:Old maps of Franklin County, Maine (unless there are sufficient numbers to warrant a "Sanborn maps of Uvw County, see above) --> This ensures that they can be found as reference material for each county that got coverage.
  • Whatever exists: Location (e.g. Category:Farmington, Maine for "Sanborn Fire Insurance Map from Farmington, Franklin County, Maine") or more detailed: "Cat:Maps of Farmington, Maine" or ideally: "Cat:Old maps of Farmington, Maine" --> This ensures that they can be readily found for the actual community they were created for.
What we don't need is e.g. File:Sanborn Fire Insurance Map from La Grange, Oldham County, Kentucky. LOC sanborn03193 002-1.jpg being placed as "1895 maps of Kentucky": Because it is not a "map of Kentucky" (this is a map of Kentucky! - similarly, this is not a 1827 map of Tibet (just incidentally showing a white border region with that label) and this is not a 1784 map of the world (despite showing a patch of Earth in 1784)). So, inserting Sanborn maps in the year-maps-of-Kentucky is a disservice to the users because in those categories one would expect finding actual maps that show all or at least a considerable part of Kentucky in the time. Not glorified building plans. Sure, in cases where there are no alternative categories available, users have to improvise in some way. But we do have subcategories on the County and Township levels for the United States. Make use of them. --Enyavar (talk) 10:09, 21 October 2024 (UTC)[reply]

October 09

OsmappBot uploads from the OpenStreetMap app

Hi wikipedians!

I am creating an open-source app for browsing OpenStreetMap – the OsmAPP. You can access it at osmapp.org. One of main features of OsmAPP is showing a side panel with information on any clicked map feature or POI. This includes showing photos from many available sources, which is mainly from connected Wikipedia articles, Wikidata entries and directly linked Wikimedia Commons images (see eg. this page).

This connection naturally led me to think about making upload possible as well, as this could benefit both projects – supply Commons with real world images under correct license, and add photos to various map features in OpenStreetMap.

After a year of effort (the wiki api is quite challenging 😃), I have the upload script ready. I asked for the permission to make a test run, which succeeded (OsmappBot contributions). Now I would like to ask broader public about your opinions, and ideas how to make the most of it for Wikimedia Commons.

Regarding Freedom of panorama – the Upload dialog would warn users if the specifc country forbids public photos of buildings etc. I can't add the specific {{FoP-country}} templates programatically (that would need a AI object recongnition), but I will review uploaded images manually and add it if needed. OsmAPP doesn't have many users, I expect only handful of uploads per month. Mind that, this is not an import bot, it rather uploads images on behalf of logged in OSM users, any change I make to the bot will only affect future uploads.

Standard upload dialog
FoP in effect when uploading in countries from this list

Looking forward to your ideas and opinions 🙂 Zbytovsky (talk) 10:05, 9 October 2024 (UTC)[reply]

@Zbytovsky: Sounds interesting. Taking File:Hammertalwand (Climbing Crag) - OsmAPP (4).JPG as an example, the most striking thing is that the image lacks categories. Also, the structured data lacks as "depicts" statement, and the coordinates are not clickable. What if the volume exceeds your capability (or availability) to review? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:12, 9 October 2024 (UTC)[reply]
Interesting. I suggest you create a video demonstrating its features and put it on YouTube and also upload it here. Please enable users to add one or several categories with autocomplete similar to the Upload Wizard on this site (maybe the HotCat script could be used for that). Prototyperspective (talk) 16:21, 9 October 2024 (UTC)[reply]
I would recommend rewriting Public photography is forbidden in this country. to Public photography is restricted in this country. as all but five countries with freedom of panorama provisions grant permission for some works but not others. For example, the United States has freedom of panorama for architecture but not sculpture. JohnCWiesenthal (talk) 19:20, 9 October 2024 (UTC)[reply]
Looks very interesting and promising! Thank you for the work! It would be a nice addition if login and upload with Wikimedia account would be possible. That would also relieve you from the responsibility at least for uploads done through that way. --Marsupium (talk) 06:42, 11 October 2024 (UTC)[reply]
@Prototyperspective – Thanks for the feedback. I think I could design a TextField with Commons category search. It will take some time though. Also good idea with the video. I will do it once I have the redesigned dialog ready :-)
@JohnCWiesenthal – thanks, will do!
@Marsupium – Thanks for the kind words. I think for Wikimedia users, I can provide a link to the official upload tool, there is already an option in OsmAPP to add wikimedia_commons photo in the Edit section of any feature, eg. here: https://osmapp.org/way/7645354/edit .. the upload dialog makes it only easier for OSM users to contribute to Commons. Zbytovsky (talk) 08:15, 16 October 2024 (UTC)[reply]

Category:Minority schools, etc.

Category:Minority schools came to my attention when User:Elkost added it as a parent of Category:Jewish schools and my immediate reaction was, "What about a cheder in Israel (where Jews are not a minority)? We had a bit of a discussion and both agree that this area of categorization needs more thought than it has had, and more than just he and I can bring to it. In particular (some of this per our discussion, some not):

  • Right now, Category:Minority schools includes Category:Minority schools in Bulgaria, Category:Armenian schools, Category:Jewish schools, and Category:Sami schools. Category:Armenian schools seems a particularly odd inclusion, because it, in turn, includes Category:Schools in Armenia, most of which presumably serve the ethnic Armenian majority there.
  • @NeverDoING: as creator of Category:Minority schools, can you explain your intention and, in particular, the intended criteria for inclusion in this category?
  • Quoting myself, rather than try to word this again from scratch: There are also Japanese and Korean schools in the U.S., American schools in practically every major city of the world, French schools in Spain, Romania, and who knows where else, etc. I'm not sure how we should handle these all, but the emphasis on minority seems wrong to me. Also, there is some sort of distinction to be made between (for example) a Japanese school in the U.S. that focuses entirely on people of Japanese ancestry and one where non-Japanese might study aspects of language and culture as well. I don't think any of this has been well thought through. Plus "Jewish" especially raises the issue of religious vs. ethnic. For example, a cheder is a very different matter than a Jewish day school that teaches a broad curriculum. Analogously, but not a school: the 92nd Street Y in Manhattan is emphatically culturally Jewish, and equally emphatically secular.

Jmabel ! talk 21:04, 9 October 2024 (UTC)[reply]

@Jmabel: What do you think about something like Category:Historically black colleges and universities it relates to this? Surely if it's fine to have a category for historically black colleges and universities then the same would (or at least should) apply for schools having to do with other minority groups. --Adamant1 (talk) 01:14, 10 October 2024 (UTC)[reply]
HBCUs are very simple, because they are self-organized into an association.
I have no problem with the existence of any of these subcats. My issue is with the term "minority schools." Since you bring up Black Americans: would an African-American academy at the high-school level in Detroit (a city that is over 75% Black) be a "minority school"? And, again, why on a global basis are Jews and Armenians deems "minorities" (even though each has a country where they make up the majority) but Hungarians (the majority in Hungary, and an important minority in Romania, Slovakia, and elsewhere) are not? (All three are within about 20% of the same size populations.) - Jmabel ! talk 12:51, 10 October 2024 (UTC)[reply]
My thoughts are that the term "Minority" is really poorly defined and that maybe "Ethnic schools" would be better and more precise, we can also use "Religious schools" where relevant Oxyman (talk) 03:59, 13 October 2024 (UTC)[reply]
"Ethnic schools" wouldn't cover Swedish-speaking schools in Finland, as they are based on language (language choice for some of the pupils), not ethnicity. Swedish-speakings Finns, most of whom attend those schools, are still a minority (arguably an ethnic one) on the country level, although not in all towns. I think minority schools would be an adequate category for the schools, at least for schools in areas where Finnish is the majority language. Whether inclusion is based on country level or something else needs to be told, and one might have to go to individual schools for including subcategories (unless there are suitable subcategories, such as Minority schools in Sweden or Jewish minority schools – a naming scheme should be decided on). –LPfi (talk) 09:48, 20 October 2024 (UTC)[reply]

I'm going to speak up again because this doesn't seem anywhere near resolution: I think the concept of "minority schools" is a mess. There are ethnic schools, there are religious schools, there are language-specific schools, etc. They are more or less the same thing whether the group involved is a majority or a minority in a gien place. E.g., a Chinese-language school in Richmond, British Columbia, a place with an ethnic Chinese majority is not at all deeply different than one in a different part of the Vancouver area where Chinese are a minority. - 23:24, 22 October 2024 (UTC)

October 12

Category:Meanna

Could someone verify if we are actually allowed to host all these files or do i have to start a DR?--Trade (talk) 23:37, 12 October 2024 (UTC)[reply]

Seems plausible. The linked web site has a footer which states Музыка, тексты и изображения сайта распространяются по лицензии Creative Commons BY-SA 4.0. Next question is whether it's in scope; I can't help but notice that the artist doesn't have an article on any Wikipedia. Omphalographer (talk) 01:53, 13 October 2024 (UTC)[reply]
Would you mind doing license review of the files in the category? Trade (talk) 03:32, 13 October 2024 (UTC)[reply]
I tried to write the article - but they removed - because for them not enough of weight. Still have a draft https://ru.wikipedia.org/wiki/Участник:Vitaly_Zdanevich/Meanna Vitaly Zdanevich (talk) 17:56, 17 October 2024 (UTC)[reply]
The threshold is much lower at Commons than at Wikipedia for some categories of media. Do we have an abundance of contemporary music? If not, then musicians do not have to be that famous to be in scope. We should even have samples of amateur music of different genres from different countries, if possible. Only when we have redundancy for some categories, we should heighten the threshold for them (usable quality should be required from the start, and some level of representativity, but not much more). –LPfi (talk) 10:01, 20 October 2024 (UTC)[reply]

October 14

Google's semi-censorship of Wikimedia Commons must end

Please see meta:Community Wishlist/Wishes/Do something about Google & DuckDuckGo search not indexing media files and categories on Commons. I think we can and should do something about Google not indexing most files (including all videos) and category pages on Commons. Prototyperspective (talk) 15:42, 14 October 2024 (UTC)[reply]

It is a private company and if not violating the law, they can do whatever (...) they want. If they choose to ignore stuff on commons - that´s fine. Alexpl (talk) 20:02, 14 October 2024 (UTC)[reply]
I was not saying it's illegal. That may be fine according to law. I wonder if it's fine to Commons that users' contributions are just blacked out and not available to people. Prototyperspective (talk) 21:39, 14 October 2024 (UTC)[reply]
Huge filesizes for photos are a cost factor when it comes to processing and are almost never worth it anyway. I dont blame them from not wanting photos with the megabytes in the three digits to show up, whenever somebody types in a generic searchterm. Alexpl (talk) 14:13, 15 October 2024 (UTC)[reply]
This seems offtopic. 1. Most files on WMC are not many MBs large and this is not about some particular few large files. 2. It only shows gstatic thumbnails in Google Search, not the whole image, and it's the same for DDG and other search engines.
It's absurd to argue that Google's storage or processing would have notable issues that out of the millions of indexed website makes WMC one whose media is not findable.
You can of course defend anti-WMC practices – despite that I don't understand why Commons contributors could be supportive of that – but this point does not make sense, partly because this isn't about the <0.1% of WMC files that are large image files to begin with. Prototyperspective (talk) 14:33, 15 October 2024 (UTC)[reply]
This is not the first time I have seen you try to dismiss comments with which you disagree as "off topic", when they are not. Please do not so that. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:46, 15 October 2024 (UTC)[reply]
I said it seems offtopic and I did notdismiss the comment but address it comprehensively. When I say it seems offtopic that is for example because I may have misunderstood it and/or the user may want to clarify how it would be ontopic. I do wonder why you're so super sensitive about me using the word offtopic. The user did say something but did not explain how it relates to this subject and clarifying that with clear language is I think more constructive than beating around the bush. Prototyperspective (talk) 16:41, 15 October 2024 (UTC)[reply]
There already is a thumbnail for every file here anyway so not even any need to create any anew. Prototyperspective (talk) 15:30, 15 October 2024 (UTC)[reply]
See also meta:Talk:Community Wishlist/Wishes/Do something about Google & DuckDuckGo search not indexing media files and categories on Commons. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:41, 14 October 2024 (UTC)[reply]
There is a commercial interest in steering the search results to commercial and social websites. These generate clicks, not the commons. I do have the impression that Google is much more interested in SDC of files than the Commons categories. Every effort should be made to fill in the P:P180. Google certainly uses the labels in Wikidata as datafeed for the search engines. Also used for educating the translation software.Smiley.toerist (talk) 10:12, 15 October 2024 (UTC)[reply]
Wikipedia itself is indexed rather highly on Google search results though. And it does index images that are used in Wikipedia articles, but this treatment isn't extended to the other Wikimedia projects. (I can't speak for other media files however). ReneeWrites (talk) 18:26, 15 October 2024 (UTC)[reply]
Yes Wikipedia is, but not Commons, the second largest Wikimedia project with a type of content that lots of people are interested in, watch and search for (media of all kinds). It does not index any video on here (at least in my tests I could not find any so far even when searching for the exact title) and images I think are only indexed when they're used in Wikipedia articles and even then often missing from the main results. One part of the proposal is systematic tests/investigations so there is some data on this. I think overall the indexing is pretty bad even when one is searching for a subject that WMC has lots of high quality contents and other image results that are shown are fairly low-quality. One could also focus on the videos. Prototyperspective (talk) 20:32, 15 October 2024 (UTC)[reply]
Google often indexes images that are not in a Wikipedia article. I find plenty if I do specifically an image search. But it doesn't tend to list pages that are mainly an image in its general results, so Commons image pages often don't show in the result if you do a general Google search. - Jmabel ! talk 05:11, 16 October 2024 (UTC)[reply]
Rarely it does, but indexing a random tiny subset of files doesn't change anything about the issue and only makes it harder to notice this. I did not find plenty of images for prior searches I did where I then either used an image not from WMC despite that I know WMC has at least as good images well-organized or used the WMC search. Again, investigations are the first step of what is proposed so maybe you could share your searches. Images certainly shouldn't show up in the general search results (well nearly always) – I made it clear that this is about the Images and Videos tabs of these sites...only when it comes to category pages is this about the general search results. I currently don't have many good examples. Things I searched for (those may not be the best examples) I think included roughly Rivers from space and Algae blooms from space and Satellite picture of cities at night. This is not about Google&DDG not indexing any files on WMC. Please let me know if that should be clearer in the proposal. It is about them indexing only very few images (and those are not even the most relevant or best) when it should be many (e.g. in searches where WMC has lots of good-organized files), not showing nearly all categories in the results and not indexing any videos. Maybe it should be clearer that isn't necessarily all Google's fault – the investigations may reveal things Wikimedia community & tech could do to improve its inclusion in external search results – however such steps depend on investigations and don't mean step 2 & 3 are invalid, other things could follow up on that step in addition and shape these two. Prototyperspective (talk) 11:30, 16 October 2024 (UTC)[reply]
@Prototyperspective: Colourpicture Publishers. There isn't that many results to begin with, but maybe it's at the top because the category has a description that contains the companies name in it? --Adamant1 (talk) 01:21, 18 October 2024 (UTC)[reply]
  • Yes, that's the kind of investigations I'm proposing are done large scale and in systematic ways (and well visibly e.g. published in diff) so we can identify cases that are well indexed, find out why, and identify cases that should be well-indexed but aren't and so on.
It could be that it's at the top because it contains a long descriptive category description – which most cats however don't really need because the category title is self-explanatory – as well as an infobox with all sorts of data. It's not unlikely also because there's few other websites with info on that subject, especially not recent ones that are linked from other pages. As a result of findings like your example, one could for example conduct tests (and/or check the theory via the dataset) whether it's the company's name in the description that caused the cat to show up this high or the description and consider things like adding category-descriptions (partly automatically via WP article leads and/or Wikidata item description). An open letter doesn't have to be as provocative and confrontational as the title of this thread, one could nicely ask Google & Co to improve their results by considering specific things or identified requested changes. Relevant to that is that Google & Co heavily make use of Wikimedia content in all sorts of ways but this isn't about fairly giving back (some media attention however could be due to that and reference that): it would be about them improving their search results for everyone so it shows media or pages that the person searching would likely find useful (e.g. via considering how many files and how many Wikipedia-used files are contained in the category). (When it comes to videos however it seems like purposeful exclusion.) Prototyperspective (talk) 08:24, 18 October 2024 (UTC)[reply]
Google clearly does take these images into account. I looked up a handful of terms:
Google Images searches
  • hubble extreme deep field (1 top result from WMF projects)
  • pando tree (2 top results from WMF projects)
  • tokyo tower (2 top results from WMF projects)
  • african renaissance monument (2 top results from WMF projects)
  • burj khalifa (2 top results from WMF projects)
  • gutenberg bible (2 top results from WMF projects)
  • ka'ba (7 top results from WMF projects)
  • michelangelo david (3 top results from WMF projects)
  • mount denali (3 top results from WMF projects and 1 from Wikiwand, which mirrors Wikipedia)
  • keyboard (0 top results from WMF projects. In this case, it gave me stores near me to buy keyboards, which makes perfect sense, if you ask me.)
  • hurricane milton (1 top result from WMF projects)
  • vladimir putin (1 top result from WMF projects)
  • mitochondrion (1 top result from WMF projects)
  • october revolution (2 top results from WMF projects)
  • northern lights (0 top results from WMF projects)
  • train (3 top results from WMF projects)
  • barcelona (1 top result from WMF projects)
  • mesopotamia (2 top results from WMF projects)

If you narrow your search to CC images, you get more from Flickr and Commons:

Google Images searches - Narrowed to Creative Commons
  • hubble extreme deep field (4 top results from WMF projects)
  • pando tree (4 top results from WMF projects)
  • tokyo tower (4 top results from WMF projects)
  • african renaissance monument (6 top results from WMF projects)
  • burj khalifa (7 top results from WMF projects)
  • gutenberg bible (4 top results from WMF projects)
  • ka'ba (5 top results from WMF projects, decreased)
  • michelangelo david (6 top results from WMF projects)
  • mount denali (3 top results from WMF projects)
  • keyboard (4 top results from WMF projects)
  • hurricane milton (1 top result from WMF projects)
  • vladimir putin (4 top results from WMF projects)
  • mitochondrion (16(!) top results from WMF projects)
  • october revolution (1 top result from WMF projects, decreased)
  • northern lights (3 top results from WMF projects)
  • train (4 top results from WMF projects)
  • barcelona (2 top results from WMF projects)
  • mesopotamia (5 top results from WMF projects)

I don't believe there even is a problem. Sure, results from WMF projects are only 1 or 2 in many cases, but:

  1. it's not like there was any other site that did have a majority of the top results
  2. you can improve them by searching for CC content
  3. Wikipedia was almost always in the results, even if they didn't have a majority in the top images (which there's no reason it should, might I add). I can't say the same about other results I saw, like Britannica, NatGeo, Adobe Stock, etc.
Google is showing results from Wikipedia, Commons, and even smaller projects like Wikispecies and Wikivoyage, at times .I wouldn't put it past them that they're prioritizing commercial and social sites that run Google Ads (purely speculation from my part, don't take my word for it), but I find it hard to believe that they're straight up censoring, shadowbanning, or otherwise limiting results from WMF projects. Rubýñ (Scold) 17:21, 15 October 2024 (UTC)[reply]
I haven't repeated all the searches to test this, but with the ones I did I only got 1 result from WMF, and it was the image in the infobox of the Wikipedia article about the subject. ReneeWrites (talk) 20:29, 15 October 2024 (UTC)[reply]
  • I personally use Ecosia to search things and I often just type in something in Ecosia rather than search it here because I am too lazy to use the convoluted Wikimedia internal search method (yes, using external websites to find something is oftentimes easy than the internal "search" engines on Wikimedia websites), but I noticed that in the past few months Ecosia has been suppressing non-Wikipedia Wikimedia websites more, now, this seems to coincide with the switch where Ecosia now mixes in Google Search search results with those from Microsoft Bing, before this change Ecosia exclusively used Microsoft Bing and while I've used Microsoft Bing as my main search enginge since 2011~2012'ish, I switched to Ecosia a couple of years ago (after I saw one of their advertisements on Google YouTube) and I occasionally compare it with Google Search and other search engines. Judging by the fact that Google Search suppresses Wikimedia Commons and Microsoft Bing does this to a lesser extent I assume that this likely is a deliberate choice by those companies. But it could probably also be something internal at Wikimedia websites as all non-article space pages at Wikipedia are also excluded from search engines (meaning that someone cannot find any Wikipedia policy pages unless someone looks for them within Wikipedia, which I've always found to be a rather odd choice).
Now, we know that Google Search, Microsoft Bing, Ecosia, DuckDuckGo, Yahoo! Search, Etc. all heavily rely on Wikidata, perhaps linking all Wikimedia Commons category pages with Wikidata items might help integrate this website better with search engines, if you think about it, the exclusion of the Wikimedia Commons is exclusively the exclusion of the Wikimedia Commons, I have no trouble finding results from the Wiktionary or Wikivoyage, which probably means that the integration between Wikidata and other Wikimedia websites helps them. Now, I know that "SEO" is considered "a curse word among Wikimedians", but if we want the Wikimedia Commons to show up in search results we most likely do need to link to Wikidata and properly use redirects, alternative titles, translations, Etc. in a way that makes sense. For example, if you search for alternative titles on Wikipedia you get them, like "Communist Germany" in a search enginge you'll find the DDR because "Communist Germany" is a redirect at Wikipedia. Meanwhile, we tend to have highly specific titles and redirects are typically deleted. But my guess is that the main culprit is the lack of Wikidata integration at the Wikimedia Commons, I wonder if files with more optimised structured data also show up in search engine results more as these are dependent on Wikidata items. Alternatively, we could compare if categories with or without Wikidata integration show up more in internet search enginges. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:52, 19 October 2024 (UTC)[reply]
Thanks for this interesting info contribution.
  • Comparing indexing results between search engines like so and across time (especially after algorithms were reported to be changed albeit it's often probably not announced) could help identify causes and potential mitigation measures.
  • I never noticed or thought about search engines not indexing policy and meta pages of Wikimedia sites (nonWMC), if so that's also I think something that would be good to be changed if possible. For example, new editors or readers may search for these with a search engine instead of the internal one. If they searched for a meta/help pages on Commons it's often quite possible they can't find it because they don't show up in the search results even when in the MediaSearch' Categories and Pages tab (issue #8 here).
  • [Google & Co] all heavily rely on Wikidata that good integration with Wikidata is a cause for SE indexing or good indexing and that improving that integration are two hypotheses that could be tested. I do not think this is the case much because category pages that are linked to Wikidata items also do not show up and only a tiny sub < 0,01% of files are used in Wikidata items or usable there while most items are somewhere underneath a category that is linked to Wikidata item. I think 'it's not linked to a Wikidata item' or 'it doesn't have structured data depicts statements' would be not much more than false excuses (not necessarily deliberate) for not indexing and I don't see why it would rely on / require it / why it should be expected. Moreover, some categories should probably be well-indexed without being linked to a Wikidata item or linking such would be inappropriate or at least can't be done at scale(?) – e.g. Category:Drone videos with lots of organized content can't even be found in DuckDuckGo when searching for drone videos wiki (btw I think it should also show up high for searches like free drone videos). The linked proposal however is interesting but I have doubts this can be done both at scale and affects the SE much. Data suggesting such as has any significant effect is also missing. So I don't think it would solve this, e.g. videos on WMC still don't show up in the videos tab and many large categories are already linked.
  • and properly use redirects, alternative titles, translations, Etc. in a way that makes sense Agree. One option is to sync ENWP redirects of items to WMC so WMC has the same redirects [ie a tool for doing so]. Another is Adding machine translated category titles and this could also be implemented via redirects and be extended to category descriptions. This however is another case that I don't think should be required for the pages to show up in search results but only improve them. It's possible that this would solve this even if it shouldn't be that way due to how pages are ranked. Note that this may require that the category page is an actual url with an actual title and not not the same url with some Javascript dynamically changing the title depending on the user language. Another option of creating redirects of translated titles – Category:Tiere (de; only plural form not singular) currently redirects to Category:Animals – can't be done at scale and may cause issues (such as HotCat autocompletes).
  • In any case such comparison data would be great even if it's just a small factor (I doubt it's the main culprit for the plural indexing issues).
Prototyperspective (talk) 20:03, 19 October 2024 (UTC)[reply]
From everything I've been able to tell, Google does index pages in "Commons" space. For example, do a Google search on "structured data commons" (no quotes). - Jmabel ! talk 16:43, 20 October 2024 (UTC)[reply]
Yes, this is known, e.g. the intro already is about "most" files, not "all" files as well as results' ranking/findability. I've yet got to see a WMC video in the videos tab however. Prototyperspective (talk) 16:46, 20 October 2024 (UTC)[reply]

October 15

Admin action rational

I wonder how much explanation we should expect from admins for their admin actions.

Supposedly, an admin should be able to explain which policy they applied when the delete content from Commons. It's fairly obvious when the content is deleted due to copyright issues, but less so, in other case.

If they can't detail based on which policy they acted, their conduct appears irrational.
 ∞∞ Enhancing999 (talk) 12:40, 15 October 2024 (UTC)[reply]

@Enhancing999: Is there a particular action which concerns you?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:42, 15 October 2024 (UTC)[reply]
It's a general question.
 ∞∞ Enhancing999 (talk) 13:44, 15 October 2024 (UTC)[reply]
His question probably relates to deleting unnecessary empty categories that will not be filled in the foreseeable future. To be fair, I would like to inform admin @Yann about this ongoing discussion. Lukas Beck (talk) 14:29, 15 October 2024 (UTC)[reply]
@Enhancing999: I already told you 5 times that we don't keep empty categories. That's the rationale used for deletion. Yann (talk) 15:15, 15 October 2024 (UTC)[reply]
Yann: Please avoid off topic comments in discussions.
 ∞∞ Enhancing999 (talk) 15:21, 15 October 2024 (UTC)[reply]
@Enhancing999: That was directly on point.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:24, 15 October 2024 (UTC)[reply]
Jeff G. Maybe you could rephrase it in a way to answer the general question I asked above.
 ∞∞ Enhancing999 (talk) 20:38, 15 October 2024 (UTC)[reply]
@Enhancing999: If an Admin is doing something wrong, then certainly they should be held accountable. On the other hand, if a user is doing something wrong (like trying to keep empty categories without good reason), then they should be held accountable.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:29, 15 October 2024 (UTC)[reply]
Let me rephrase the question: can we expect from an admin that the explain their action in terms of the policy they applied?
 ∞∞ Enhancing999 (talk) 21:32, 15 October 2024 (UTC)[reply]
Up to a point. But if I had to give a detailed explanation tying every action I took back to policy, I would not get much done. Most of the time, it should be clear on the surface. For example, if I correct a misspelled category name, I'm probably not going to cite a specific policy to say why. - Jmabel ! talk 05:15, 16 October 2024 (UTC)[reply]
Not by default, but when asked about it, shouldn't you be able to explain that category names are to be spelled in English per our policy on categories (insert link), that the word is written without the letter "y" as can be found in Wiktionary (insert link), and thus you fixed a typo, applied this or that part of speedy deletion policy (insert link) after the stated delay (insert link). The detailed explanation would be almost the same for thousands of admin actions.
Imagine you'd repeat <We don't use "Y"> on questions about each aspect instead, wouldn't that be somewhat irrational?
 ∞∞ Enhancing999 (talk) 08:59, 16 October 2024 (UTC)[reply]
@Yann: Right, this is why we have COM:CSD#C2.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 16:23, 15 October 2024 (UTC)[reply]
Jeff: your comment appears to be off-topic. Please discuss CSD with Yann on their user page. The question here isn't about a particular action of Yann.
 ∞∞ Enhancing999 (talk) 21:39, 15 October 2024 (UTC)[reply]
Generally admins don't give rationales for their actions. Nor do I think they should in a lot of cases because it would just get in the way of them doing their jobs. Deleting empty categories being one instance where it's totally pointless and would just needlessly slow things down. Probably with something like blocks they can and should do a better job explaining the reasoning behind it though. I don't think the default block message is really helpful or gets at the issue that led to the block in a lot of, if not most, cases. And the person who is blocked risks having their talk page access restricted or the length of the block getting extended if they ask for clarification about it. Which just seems like a bad way to go about things. Although I don't really see it changing either though. There doesn't really need to be a policy based reason for anything admins do in most cases anyway and it's not like they are (or ever will be) held accountable for anything either. --Adamant1 (talk) 00:51, 16 October 2024 (UTC)[reply]
  • I'm a big believer in holding admins accountable for questionable actions, but it is no secret that Commons has some fairly severe issues with backlogs. Requiring detailed explanations in situations where the reason is obvious places an undue burden on admins. If asked, they should of course provide at least a basic explanation but requiring it upfront in all cases seems needlessly burdensome. Just Step Sideways (talk) 22:13, 19 October 2024 (UTC)[reply]

October 16

See this about an ice mixture that was patented: File:Alfred Ingvald Naess (1877-1955) in The Pittsburgh Post of Pittsburgh, Pennsylvania on February 25, 1914.jpg I am hoping someone can find the patent mentioned. --RAN (talk) 00:43, 16 October 2024 (UTC)[reply]

Need Help Add Image to Page

This page requested cropped images, which I created from the source image. However, the system penalizes if I try to add the new images to the page. Below are the source image and cropped images:

Love American Style cast 1973.JPG - Wikimedia Commons

Love American Style cast 1973.middle.jpg

Love American Style cast 1973.1.jpg

For the last image, I uploaded several versions which you can see at my uploads.

I definitely need your help. Starlighsky (talk) 03:42, 16 October 2024 (UTC)[reply]

Convenience links: File:Love American Style cast 1973.JPG, File:Love American Style cast 1973.middle.jpg, File:Love American Style cast 1973.1.jpg. Jmabel ! talk 05:17, 16 October 2024 (UTC)[reply]
@Starlighsky: You don't say what page (or even what website) you want these added to. The latter two are not very good photos, they are tiny, I would certainly hesitate to add them to (for example) a Wikipedia article. And "the system penalizes" is unclear. Is this something you were asked not to do? If so, you certainly should not encourage someone else to do it on your behalf. - Jmabel ! talk 05:21, 16 October 2024 (UTC)[reply]
Here is the site: File:Love American Style cast 1973.JPG - Wikimedia Commons
The site mentions the iamges that are requested for cropping. Starlighsky (talk) 11:05, 16 October 2024 (UTC)[reply]

"In Wikimedia Commons, the <gallery> tag doesn't support direct linking of images to specific categories" answer from chatGPT. Is that true ?

How can I overcome this limitation ? The galery in cause is Conjunto da Avenida dos Aliados. --JotaCartas (talk) 07:01, 16 October 2024 (UTC)[reply]

  • link to a category
    link to a category

—TheDJ (talk • contribs) 11:33, 16 October 2024 (UTC)[reply]

thanks, it is working well JotaCartas (talk) 11:51, 16 October 2024 (UTC)[reply]

We use reverse image searches pretty often, mainly for determining if a new upload exists elsewhere on the web, but also for looking for 3rd party usage of the files we host. It looks like Google is deprecating its reverse image search in favor of Lens. What are people using as a substitute? I never got particularly good results with TinEye... — Rhododendrites talk |  14:08, 16 October 2024 (UTC)[reply]

I get good results with TinEye and use a browser extension so that one only needs to right click the image to reverse search it. I think it would be better if bots/scripts did the reverse searches. Don't know what you mean with the Google issue – it can still reverse search, maybe click on "Find image source" at the top. I don't think there are other options – they would be on https://imgops.com/. Prototyperspective (talk) 15:40, 16 October 2024 (UTC)[reply]
  • If I am performing a due diligence search to see if anyone is claiming to be the creator, or if a for profit archive like Getty is claiming an active copyright on an image I use both. I like that Tineye tells how many images it searched. --RAN (talk) 14:39, 17 October 2024 (UTC)[reply]

IP edit edit confirmation

There is a proposal to test if requiring anon users to confirm their edits by clicking the edit button again and showing a warning to avoid accidental edits can reduce the amount of bad edits. There is currently a consensus to test this but with only three people involved Commons:Village pump/Proposals#Simple edit confirmation. There was also the question on numbers of bad edits. I created a tool that shows how many edits are marked as reverted also compared to the patrolled edits that shows the potential high numbers of unseen bad edits [1]. GPSLeo (talk) 16:55, 16 October 2024 (UTC)[reply]

UploadWizard gives author as "[[User:Example|Example]]"

Tracked in Phabricator
Task T377656

UploadWizard has started between 16:42 and 18:41 UTC today in my uploads to put the whole wikitext syntax again as the label of the link for the author, e.g. here. In wikitext this is: [[User:Example|[[User:Example|Example]]]]. Other files uploaded with UploadWizard at Special:NewFiles seem not to be concerned. Do you know if this is a known bug? --Marsupium (talk) 19:30, 16 October 2024 (UTC)[reply]

Hi @Marsupium, this should not be the correct way UW should be working. Can I ask you to please report this bug on Phabricator and then ping me back? If you want, I can help you in filing it. Let me know. Sannita (WMF) (talk) 16:57, 17 October 2024 (UTC)[reply]
✓ Done with phab:T377656. --Marsupium (talk) 15:51, 19 October 2024 (UTC)[reply]
@Marsupium Thank you, I'll put it soon on the dev's desk, and I hope I'll let you know asap. Sannita (WMF) (talk) 10:07, 20 October 2024 (UTC)[reply]
@Marsupium The bug should be solved now, can you please confirm it is? Sannita (WMF) (talk) 08:49, 22 October 2024 (UTC)[reply]

Seeking volunteers to join several of the movement’s committees

Each year, typically from October through December, several of the movement’s committees seek new volunteers.

Read more about the committees on their Meta-wiki pages:

Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.

For the Committee Support team,


-- Keegan (WMF) (talk) 23:07, 16 October 2024 (UTC)[reply]

October 17

Needing help with a requested cropping.

I did the requested cropping for File:Love American Style cast 1973.JPG - Wikimedia Commons The cropped images are in the links for the respective images requested on the file page. If someone has access to the technology to improve the cropped images, that would be great. Starlighsky (talk) 00:44, 17 October 2024 (UTC)[reply]

@Starlighsky: There is no way to "improve" a low-res image. AI can use it as a basis for something that is essentially fictional, but that is no longer a documentary image. - Jmabel ! talk 08:31, 17 October 2024 (UTC)[reply]
Which Commons has plenty of, there's no rule against uploading upscaled versions of historical photos here. But the English Wikipedia would not allow such an image to be used to illustrate an article (per en:MOS:IMAGES), if that was Starlighsky's intention. Belbury (talk) 08:43, 17 October 2024 (UTC)[reply]
Thanks Starlighsky (talk) 12:24, 17 October 2024 (UTC)[reply]
Wikicommons provides access to Croptool from Tool Forge (https://croptool.toolforge.org), but I am not able to use it on my system. Starlighsky (talk) 12:26, 17 October 2024 (UTC)[reply]

Of course, it's doubtful that people will want to have this discussion, but I'm going to try anyway. If Commons is truly a separate website and not simply subservient to Wikidata or Wikipedia, why should we host extremely low-res files solely to satisfy a POV held by Wikidata and/or Wikipedia editors that subjects be illustrated in isolation rather than in the context of uploaded photos? The default resolution on Wikipedia is 220 pixels wide. It doesn't take a PhD to figure out that when you crop an image to a lesser resolution, it's absolutely going to look like shit. Yet, that's been going on for years. Should we establish a deletion criteria for these crops when suitable replacements are uploaded and they become practically useless? RadioKAOS / Talk to me, Billy / Transmissions 17:57, 17 October 2024 (UTC)[reply]

Commons has two roles: as a public-facing media repository in its own right, and as the shared media repository for WMF sister projects. Probably half the content we host makes sense only for the first purpose (e.g. no sister project is ever going to care what a particular streetcorner in Seattle looked like in 1894), 5-10% makes sense only for the second (e.g. Wikidata needs an illustration for an item, but no really good photo is available; someone has a chart that makes sense only in the context of a particular WikiBooks article), and the remainder at least potentially makes sense for both. The second role is why we have the rule that any file that is legitimately in use on any sister project is automatically in scope, and should be deleted only if there is an issue about rights. - Jmabel ! talk 07:43, 18 October 2024 (UTC)[reply]

Automatic detection of potentially problematic domains in UploadWizard

Mockup of a potential message for problematic external source

As part of our work to improve the current user experience with UploadWizard, we are working on a way to automatically detect external links when a media is uploaded on Commons through UploadWizard, in order to facilitate their evaluation by the community.

Per community suggestion, we already investigated the effect of external links on the likelihood of deletion of an image in phab:T369273, identifying a number of potentially problematic domains.

You are encouraged to take a look at the project page, and to evaluate the current workflow.

We have also a request for feedback for you: we are considering adding a user alert during the upload process if a problematic external source is detected in the file. On the right, we are sharing some potential designs for the alert. We welcome community feedback about how it is phrased and whether it may be useful.

We hope to receive your feedback here or on the project's talk page. Thanks in advance! Sannita (WMF) (talk) 17:11, 17 October 2024 (UTC)[reply]

Has this image been reversed?

Before I change it, perhaps someone else could offer their opinion or confirmation that the image File:Isle of Portland from north.jpg is reversed. It does seem that way to me, but OTOH it has been the lead image on the Wikipedia "Isle of Portland" page for well over a year, and I am surprised that no one would have noticed it, so just in case I am somehow getting totally confused ... ITookSomePhotos (talk) 20:50, 17 October 2024 (UTC)[reply]

It's correct, compare this image Broichmore (talk) 12:25, 18 October 2024 (UTC)[reply]
Oh yes, sorry, I made the mistake of thinking ... well, never mind, just being an idiot. Thank you both for taking the time to look at it. ITookSomePhotos (talk) 14:45, 18 October 2024 (UTC)[reply]
Your confusion is completely understandable. IMO, you won’t be the last. I know Portland well, and it gave me pause. If I were you, I'd consider leaving a confirmation on the image's talk page confirming the orientation. You could also put in camera co-ordinates, as a suggestion. Broichmore (talk) 11:06, 19 October 2024 (UTC)[reply]

October 18

Genuine historical images relegated to art

This is one of my pet peeves. We have images, which pre-date publication of clear and informative printed photographs. IMO, they're correctly catted as Category:History of El Callao. They could as easily have been put into a new, and perhaps superfluous category, of Historical images of El Callao. Instead, they have been transferred into a new category, entitled El Callao in art.

Category: El Callao in the 19th century, does exist, and would have been preferable.

Apparently, it’s been decided to do away with such cats, as Historical images of El Callao, in favour of ‘’History of El Callao’’. I’ve no idea, how, that came about.

Surely it's simple to understand that only an image, by for example Van Gogh or any other abstract artist, of a location, is appropriate to put in an art cat. Whereas, views of buildings, battle scenes, or anything before useable photographs, are not art as such, they were never made as art pieces by the artist/s (sic) at the time. These images, in the main. were copied by from sketches made on the spot, or early Daguerreotypes.

Not a single image in El Callao in art is actually ‘’art’’, as opposed to a historical record (of the time)!

This is, as faulty as our habit of, creating a category such as USS Foo (ship, 2024), where ship is mentioned twice in the same cat name. We need to change the policy on both. Broichmore (talk) 13:38, 18 October 2024 (UTC)[reply]

I agree that many of the images in "El Callao in art" serve as important historical records, but they also hold artistic value, even if they weren't created as artistic pieces in the way we use that phrase today. Rather than debating whether they count as art, it might be more practical to categorize them in both "El Callao in art" and "El Callao in the xth century" categories, rather than getting into the weeds with a debate that is going to involve a lot more images than just the ones in that category. If someone gives you trouble for that (like by removing the "xth century" categories) you can argue that they count as historical records, but the "art" debate is a completely separate matter from that. ReneeWrites (talk) 14:40, 18 October 2024 (UTC)[reply]

More junk data being added to 'depicts' statements

Goathland, Julian Park Farm

Do you want to know what "historic site (Q1081138)" looks like? Or the village of Egton (Q4394967)? See the above picture! According to User:GeographBot, that's what this image depicts.

I thought we had stopped the automatic addition of vague and irrelevant "tags" as values for depicts (P180) when we turned off the WMF's benighted Tagging Tool and reverted most of its edits, but apparently not. This has been going on for months, it seems. I just removed a load of nonsense values from an image and replaced them with the value for the item describing the actual subject. They were added by the bot in August 2023.

We currently have over 415,000 images with P180=Q1081138.

The bot approval - dated 2021 - says "depicts (P180) - What do we see in the photo. This based on the [[tags and on the reverse geocoding of the object coordinates". Separate SDC properties for tags exist.

The conversions are apparently handled by the list at User:GeographBot/Tags - but this includes some very problematic pairs, suggesting, for example, that a Geography tag of cross should be interpreted as depicting cross (Q40843) - a "geometrical figure". But the tag is most likely to be used on images depicting a Christian cross (Q392371) ("symbol of Christianity") or a Celtic cross (Q229788) ("Christian cross superimposed on a circle"). Another entry suggests that images might depict Ordnance Survey (Q548721) ("organisation that creates maps of Great Britain"). Another that images tagged as "standing+stone" depict menhir (Q193475) - a subclass of standing stones. Anything tagged "town hall" will be said to depict Rathaus (Q543654) - which is unique to German speaking countries. Odd, given that the entire Geograph corpus consists solely of images from the UK.

I do not believe there has ever been community consensus expressed that tag values should be used in P180 (I have asked previously, more than once, and have never been furnished with evidence). Such behaviour needs to stop, or be stopped; and the values moved or removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:53, 18 October 2024 (UTC)[reply]

@Multichill. RoyZuo (talk) 14:30, 20 October 2024 (UTC)[reply]

AF-n Audio File Babel Boxes

It looks like the old BG-n babel boxes were moved to bitmap-n to solve the collision with the language code for Bulgarian when using {{#babel}}, but the same was never done for the AF-n audio file babel boxes and their collision with Afrikaans.

I thought I was being smart by creating redirects, e.g. Audio-4 as a template that redirects to AF-4, and it looked like I was. It now displays just fine if you use {{#babel|audio-4}}!

Then I realized I might've made a huge error in doing so...because it didn't add the categories, but then I realized that neither {{Babel}} nor {{#babel}} will add you to any of the "file format" categories that aren't a spoken language in the first place!

It seems every user page I checked under Category:Audio file editors either had the category manually added or used a tool like HotCat or AWB when BG→bitmap happened.

It looks like Category:Audio file editors was last edited before the BG-n -> bitmap-n move was made, and it (erroneously) recommends using {{Babel|BG-n}} over {{#babel|BG-n}} when {{#babel|bitmap-n}} will work fine now.

And {{Babel}}'s own page says that it is deprecated and {{#babel}} should be used instead...

¯\_ ⍨⃝_/¯

Although there are only six users total in the AF-n categories and I could likely implement any change entirely by hand in a few minutes, I don't want to make a mess of things, at least without asking for input first. -αβοοδ (talk) 19:25, 18 October 2024 (UTC)[reply]

October 19

Category:Toy shops and Category:Toy stores

Category:Toy stores is currently a subcategory of Category:Toy shops. What is the difference between these two categories? --トトト (talk) 05:27, 19 October 2024 (UTC)[reply]

Category:Stores is a redirected to Category:Shops. So the differences probably don't matter even if there are any to begin with. Personally, I've always found putting everything having to do with retail selling in a category for shops to be a little weird. But it is what it is. So Category:Toy stores should probably just be a redirect unless your willing to relitigate the whole thing more generally. --Adamant1 (talk) 06:51, 19 October 2024 (UTC)[reply]

How should I indicate the source of these images

12 Public domain images from an archived page at archive.org, which I uploaded. I was was unable to specify the web-address/origin of the uploaded images, due to the current version of the website being banned. I can't even put the address here for you to look at because

"The text you wanted to publish was blocked by the spam filter. This is probably caused by a link to a forbidden external site. The following text is what triggered our spam disallow list: turismo-prerromanico.es."

An example of what I'm trying to give a source for, File:Beatus Emilianense - page 130r.jpg.

I will try to show you the source page in a different way: to see the original page, put a period between prerromanico and es:

https://web.archive.org/web/20100929110253/http://turismo-prerromanico es/ARTERURAL/MINIATURA/BEMILIANENSE-BN/BEMILIANENSEficfrn.htm

Links to images are beneath the photo on the right side, top.

Should I forgo giving the specific address these came from? Any suggestions? Jacqke (talk) 11:07, 19 October 2024 (UTC)[reply]

@Jacqke: The license should be {{PD-Art|PD-old-100-expired}}. I fixed some of your files. Please do the rest. Yann (talk) 11:17, 19 October 2024 (UTC)[reply]
Will do. Thank you. I need to change many that I've loaded recently Jacqke (talk) 15:46, 19 October 2024 (UTC)[reply]
@Jacqke and Yann: I suspect what I did here is about as well as we can do. - Jmabel ! talk 14:33, 19 October 2024 (UTC)[reply]
That looks good. Thank you! Jacqke (talk) 15:47, 19 October 2024 (UTC)[reply]
nowiki works too.
 ∞∞ Enhancing999 (talk) 19:27, 19 October 2024 (UTC)[reply]

How to handle a widespread hoax flag used as official flag?

Fake joke flag

This troll Martini-flag has nothing to do with Saint-Martin. It's not used on the island. It's a well played booze and word joke. It's funny to see that the joker or marketeer who made this fictional flag rotated the Sint-Maarten flag 90°, just like the Dutch and French flag are rotated, and modeled it after a Martini cocktail. I hope you do see that the glass is low on liqor but still has an olive in it. Of course this must mean that the whole nation is drunk and possibly hung over?

Too few involved users = Wikisupport for the troll

Not so funny is the naming on Wikimedia and widespread use on Wikipedia, of the liqor flag as the or as a Saint-Martin flag. That's similar to replacing the US Stars and Stripes by a Coors flag and then editing (templates on) 1001 pages to deliver the joke. I suspect that would be considered offensive and vandalising. Probably the changes would be corrected very fast, as there are many of our users that salute the US flag on a dayly basis.

But here we have only a few users from Saint Martin, like this anonymous who complains about the troll flag: File talk:Flag of Saint-Martin (fictional).svg and asks for deletion. They get just one kitty you just don't like it-reply that sweeps the problem under the rug. The one "Active user" from the Saint Martin work group cannot reply, because he's permanently blocked... And this old 2008 threat Commons:Deletion requests/Image:Flag of Saint-Martin (local).svg sings the great song of indifference, protest is futile. Even the as unreliable tagged en:WP:FOTW Flags of the World website is more critical then us, by calling it a dubious flag.

Meanwhile the "look at this funny drunken nation"-flag spread onto nearly a 1000 pages. I've just removed the flag from the Dutch wiki, including an EU navigation template with all the official flags of the EU... That's what you get when the name of the flag seems official, and users expect Commons to uphold the same reference based quality checks as Wikipedia. It would not surprise me, if "we" had a significant part in spreading this joke of a flag to the flag-shops of the world.

How to solve this and learn from it?

I've read a whole series of pages to see where this problem would fit. On several specific pages you can post simple problems, like the talk page which has no traffic whatsoever, or action pages to simply rename, delete or ... This complex problem transcends them, it is not a simple to do action or policy, more like a whole project. I'm new here, so I wonder how we discuss these complex problems and break them into simple steps like these:

  1. removing all the above flags and flagmaps, except for the first one.svg, to break up the troll relation with Saint-Martin;
  2. renaming the pranksterflag as such: Martini cocktail joke flag.svg (remove the StM reference from the name);
  3. uploading the official French flag in the old namespace, as it would solve most of the problems on the 1001 pages in one go;
  4. using the cocktail flag as an example and reminder on Commons that we should check sources before posting an image ¿is this policy?
  5. ...

Do you think this flag is offensive to Saint-Martin inhabitants? Do we have policies to deal with this complex kind of problems? If not, what can we do to solve the problem? How would you reach out to 50? different language Wikipedias? Are there joke categories or pages that would embrace the Martini flag? ...?

Flags that are in fact used on Saint-Martin

Official flags that are used at the border monument, or used to in the past.

  • border
    border
  • EU
    EU
  • FR
    FR
  • NL
    NL
  • Ant.nl
    Ant.nl
  • StM.nl
    StM.nl

On the streets you can see the local government logo and the before 2010 Coat of Arms, the new one is used in local government documents.[2][3]

Another flag that is visable on local photos is a political island unity flag.

Discussion

I've posted the above. Let's talk here? Groetjes, Peter (talk) 22:27, 19 October 2024 (UTC)[reply]

Hoo boy, what a mess.
The flag maps absolutely need to go; I've just nominated them for deletion. The educational value of flag maps is marginal at best; if we're going to have these images at all, they should only be based on official flags.
The other flags should, at most, be consolidated to a single image with a filename which makes it very obvious that it's a joke. Official-sounding filenames like File:Flag of Saint Martin.png are part of the problem here; they invite editors to assume that the flag has official status (particularly since the same naming scheme is used for real national flags). Omphalographer (talk) 22:39, 19 October 2024 (UTC)[reply]
Nobody ever takes any file talk page complaints by IPs seriously unfortunately Trade (talk) 01:05, 20 October 2024 (UTC)[reply]


I had thought about nominating some pretty dubious "flag maps" for deletion awhile ago but they were all in use on other projects and the creator of a DR can't usually remove images involved in it from other projects without people on here crying foul about involved editing or whatever. There really needs to be solution to that though or I don't imagine these types of fake images will ever be dealt with to any meaningful degree. I don't think it's an issue of there being to few users to deal with it though. There's plenty of people on here who are against Commons hosting these kinds of files. It's more the bad faithed personal attacks and obfuscation from the other side that tends to happen when someone nominates in use files for deletion or tries to remove them from other projects before doing so. The same usually goes for the uploaders BTW. They also tend to obfuscate and derail DRs having to do with their uploads. So there's really no point in bothering. --Adamant1 (talk) 04:20, 20 October 2024 (UTC)[reply]

Categorization is another thing to think about. This one for example somehow ended up in subcategories of Category:Proposed flags. I think that category tree should be used for flags that were actually somewhat seriously proposed to become an official flag of something, not merely fictional/parody flags like these? The Category description offers no guidance on this. --El Grafo (talk) 08:39, 20 October 2024 (UTC)[reply]

To some extent, any content can be used for jokes. We can't really edit Wikipedia on behalf of users there.
Obviously, our file names shouldn't imply that it is or was an official flag. This was renamed in 2014 already, so Wikipedia's should have had time to sort it out.
 ∞∞ Enhancing999 (talk) 11:28, 20 October 2024 (UTC)[reply]
Cleaned-up the file description page of the png version asked it to be renamed: Special:Permalink/946887090. Instead of updating the filenames on other wikis, one could consider delinking it there.
 ∞∞ Enhancing999 (talk) 11:45, 20 October 2024 (UTC)[reply]
Totally agree about the Category:Proposed flags. I get in a little tiff with a user once because they thought user created flags should go in the category. Kind of a weird opinion really, but I don't think the category should include user created flags that haven't been proposed anywhere outside of a Wikimedia project. --Adamant1 (talk) 11:33, 20 October 2024 (UTC)[reply]
@Ætoms you uploaded the svg one. @Fry1989 you reverted a png version. Other uploaders don't appear to have been active in 2024.
 ∞∞ Enhancing999 (talk) 12:25, 20 October 2024 (UTC)[reply]
In the one case where I could find a way to remove it, I was promptly and kindly advised to not remove the flag from a "Flag of St Martin" page, because it is "clearly labelled fictional and so there is no need to remove it". 🤯 --Enyavar (talk) 19:52, 22 October 2024 (UTC)[reply]

However, this template-shit looks really bad to me. When I first saw this I thought it just needs some diligent work to revert it, but quick reversion is impossible if you cannot revert changes. The flag has been spammed into all projects via some undetectable template... or something. The code in the projects says [[File:Flag of Saint-Martin (local).svg]] ( ✓ good!) and the rendered content for that very code then shows . Has this magic trick been done in Wikidata, in Commons, or in each project separetely with a template? How does this even work? However it was done, right now it seems to me like a really heinous way of project sabotage. --Enyavar (talk) 19:52, 22 October 2024 (UTC)[reply]

I think something was cached. I purged that page and the martini flag has disappeared. Omphalographer (talk) 20:05, 22 October 2024 (UTC)[reply]
Huh. I force-reloaded the page a few times (usually solves similar issues), and my problem with it was also already there yesterday, so I hadn't considered a stuck cache. Thanks, that makes it much much less heinous. Does that mean we have to manually purge all 900+ pages where the flag is still cached-in-use, or is an administrative action possible? --Enyavar (talk) 21:45, 22 October 2024 (UTC)[reply]
Wouldn't it be better to make redirects to a correct file rather then renaming? This will avoid all manual replacements. Ellywa (talk) 22:14, 22 October 2024 (UTC)[reply]

October 20

Special:Upload

What's the best way to make a bulk upload using the same Summary, License and Categories across all images?--Trade (talk) 01:03, 20 October 2024 (UTC)[reply]

With the Upload Wizard. You enter the license all the images will share in the first screen. In the second screen where you enter the summary and categories (and depicts statements, etc.), enter this information for the top image, then below there's a drop-down menu (closed by default) to "Copy information to other uploads". ReneeWrites (talk) 01:14, 20 October 2024 (UTC)[reply]
While the above is good for up to around 50 images at a time (and can be repeated by selecting "upload more images" for a second batch, etc), if by "bulk upload" User:Trade means many more than that, then Com:Pattypan or Com:OpenRefine are good alternates. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:34, 20 October 2024 (UTC)[reply]
And if it's not enormous, and the Upload Wizard does not quite produce what you want, ping-ponging with Special:Upload can also be quite effective. - Jmabel ! talk 17:00, 20 October 2024 (UTC)[reply]

Usage of "on Wikipedia" header for subjects that have multiple Wikipedia articles

To give an example Category:Photography. Maybe it's just me, but that large of an infobox just seems needlessly obtuse and pointless. Especially considering people can find links to Wikipedia articles from Wikidata if they want to. IMO it's not really useful to have a link on our end to every single Wikipedia article having to do with photography though even if some of the articles might be worth linking to. As it just gets in the way of people finding images and categories related to the topic. Thoughts? Adamant1 (talk) 05:21, 20 October 2024 (UTC)[reply]

Both the {{On Wikipedia}} template and the cluster of "sister" ({{Sisterwiktionary}}, {{Sisterwikiversity}}, etc) templates below that seem unnecessary given that the Wikidata infobox automatically displays links to any associated projects in the user's preferred language. This may have been necessary before interwiki links were centralized at Wikidata, but it isn't anymore. Omphalographer (talk) 06:46, 20 October 2024 (UTC)[reply]
Agreed, these are remnants of days gone past. Nowadays, they just add additional clutter and make the user experience less consistent across different pages. I think they can be weeded out without much concern. El Grafo (talk) 08:23, 20 October 2024 (UTC)[reply]
Agreed. ReneeWrites (talk) 09:32, 20 October 2024 (UTC)[reply]
Actually it displays the term in multiple languages which the infobox doesn't. For photography, this isn't particularly interesting beyond the F/PH question.
 ∞∞ Enhancing999 (talk) 10:45, 20 October 2024 (UTC)[reply]
The infobox automatically translates terms like these to the user's preferred language. If I read the page in English it has "animal" at the top, but if I change my language setting to Dutch, it changes to "dier", and so on. ReneeWrites (talk) 12:25, 20 October 2024 (UTC)[reply]
That's a monolingual approach. Depending on the topic, the preferred language may change. I would generally want to see English and Portuguese descriptions on anything related to Portugal or Brazil.
 ∞∞ Enhancing999 (talk) 12:28, 20 October 2024 (UTC)[reply]
The template on "Photography" showed more than 100 different languages. On "Animals" it was more than 300. ReneeWrites (talk) 12:55, 20 October 2024 (UTC)[reply]
? The comment was about the infobox. Prototyperspective (talk) 14:25, 20 October 2024 (UTC)[reply]
We were talking about both the template and the infobox. Enhancing999 said he wanted two languages, and defended the use of a template that adds hundreds without filtering them out, because the infobox only does one at a time. That is wildly excessive. ReneeWrites (talk) 15:06, 20 October 2024 (UTC)[reply]
"photography" is obviously pointless as a category name to look for, as it's implied in almost all categories. Besides, the word isn't really any different every language.
 ∞∞ Enhancing999 (talk) 17:10, 20 October 2024 (UTC)[reply]
Agree and I have already removed such from several categories. Category:Animals is one example where I removed it. Btw, it doesn't seem like it led to a drop in pageviews. The Wikipedia articles of various languages are already linked in the sidebar / the language panel and so redundant in terms of links. When it comes to descriptions and titles for categories in other languages (to make the cat understandable, findable in external search engines, and findable in the internal search engine when for some reason searching in another language), see Wish:Add machine translated category titles on WMC. In short I think all of these boxes should be removed since the Wikipedia links are already in the panel and it clutters the page while pushing its content down. Prototyperspective (talk) 10:47, 20 October 2024 (UTC)[reply]
I think you are assuming Commons is an English language website. It isn't.
 ∞∞ Enhancing999 (talk) 10:48, 20 October 2024 (UTC)[reply]
I don't know why you take this comment to suggest that instead of the exact opposite. Prototyperspective (talk) 10:51, 20 October 2024 (UTC)[reply]
Replacing a working solution with a link to a wishlist entry (possibly existing for 20 years) results in the opposite you might intend.
 ∞∞ Enhancing999 (talk) 10:55, 20 October 2024 (UTC)[reply]
Well good point. It's a link to a wishlist proposal to be precise. However, a) the motivation and need for it to be implemented would increase if problematic workarounds are abandoned instead of kept which inhibit truly addressing this b) such large headers aren't that useful for that purpose because it's hard to spot your own language text among the many links there and most categories miss these headers. Prototyperspective (talk) 10:59, 20 October 2024 (UTC)[reply]
(a) Yeah, it's true that things that have a half way working community solution might be less likely to be fixed then matters where we just let it be not working, afterall Wikimedia has paid staff for just that part. I doubt we should remove working approaches just for that.
(b) isn't there a feature that highlights that? Personally, I think these are more useful in cases where the language is less known (to me) or the terminology a bit obscure.
 ∞∞ Enhancing999 (talk) 11:06, 20 October 2024 (UTC)[reply]
Isn't the language thing a none issue if the Wikidata infobox automatically displays links to any associated projects in the user's preferred language anyway? I really don't understand what purpose a list of articles in different languages serves at that point. Especially considering as Prototyperspective points out it's impossible to find an article for any given language in the list anyway. --Adamant1 (talk) 11:12, 20 October 2024 (UTC)[reply]
There are no links involved in p's sample nor does the infobox display any of that.
 ∞∞ Enhancing999 (talk) 11:17, 20 October 2024 (UTC)[reply]
Looking at Category:Animals there's links to other projects in the infobox under the images of animals, right above the section for audio. So I'm not really sure what your talking about. --Adamant1 (talk) 11:27, 20 October 2024 (UTC)[reply]
I was referring to what P. removed.
 ∞∞ Enhancing999 (talk) 11:29, 20 October 2024 (UTC)[reply]
? these were links and the language panel has these links (hundreds thereof). Prototyperspective (talk) 11:58, 20 October 2024 (UTC)[reply]
Other than the layout being suboptimal, it displays actual translations, sometimes more than one (sample: Esperanto/eo). The links are secondary.
 ∞∞ Enhancing999 (talk) 12:07, 20 October 2024 (UTC)[reply]
1. You said no links involved which is what I referred to 2. The language panel also displays actual translations (indeed just one which is the page title). Prototyperspective (talk) 12:14, 20 October 2024 (UTC)[reply]
Good point. I had looked at the diff only.
The language panel isn't really a substitute. For English language only users, it might be sufficient, but it doesn't really support our multilingual website for other languages.
 ∞∞ Enhancing999 (talk) 12:18, 20 October 2024 (UTC)[reply]
Apart from all the other things wrong with this, it's manually populated, which is just silly. I've removed it from Category:Photography, along with the duplicative sister- project templates (incusing one linking it to, er, Category:Photography!). We should probably consider a script to mass remove them from categories and galleries; then delete them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:16, 20 October 2024 (UTC)[reply]
I started doing this for some existing instances of sisterlinks and noticed a couple of other category page cleanups which should perhaps be performed concurrently:
Anyone interested in making a project out of this? Omphalographer (talk) 19:09, 20 October 2024 (UTC)[reply]
Would be good if somebody did that and probably the place to request this would be Commons:Bots/Work requests. Probably something should be done to increase the number of people able to and engaged in creating in Commons bots since there's already a fair amount of requests there + a number of archived unsolved requests. Prototyperspective (talk) 19:51, 20 October 2024 (UTC)[reply]
It's a good initiative. I think it would be helpful to first establish what the actual template order should be and what is and isn't suitable for category descriptions before we start initiating a mass editing campaign. Wikipedia has an elaborate manual of style but Commons does not (though I think we could copy a few pages from there). The upside to having established policies is that it leads to clear guidelines, uniformity, and avoids conflict and edit warring. ReneeWrites (talk) 19:56, 20 October 2024 (UTC)[reply]
Oh, absolutely. The first step in the project would be establishing consensus on what changes should be made. Omphalographer (talk) 20:33, 20 October 2024 (UTC)[reply]
I don't think {{En}} should be converted to {{Multilingual description}}.
 ∞∞ Enhancing999 (talk) 20:26, 20 October 2024 (UTC)[reply]
What's to be the alternative to {{Sisterwiktionary}}, {{Sisterwikiversity}}?
 ∞∞ Enhancing999 (talk) 20:37, 20 October 2024 (UTC)[reply]
With regard to {{En}}, the table at Template:Multilingual description#Other multi-lingual templates disagrees. It describes single-language templates like {{En}} as "deprecated" and recommends that they only be used on file description pages.
The alternative to the "sister links" templates is the existing list of links in {{Wikidata infobox}}, as well as the automatically generated interwiki links in the sidebar ("In other projects" / "In Wikipedia"). Manually maintaining a local duplicate of these links is unsustainable. Omphalographer (talk) 20:48, 20 October 2024 (UTC)[reply]
Weird, depending on how one reads Template:Multilingual description#Other multi-lingual templates it shouldn't be used even for file description pages.
For sister links, Wikidata Infobox might be an alternative. Maybe it can be enhanced to point to other languages. The sidebar doesn't seem to work in general.
 ∞∞ Enhancing999 (talk) 20:56, 20 October 2024 (UTC)[reply]

Close discussion

Please close this discussion. Микола Василечко (talk) 10:27, 20 October 2024 (UTC)[reply]

Improve search?

I was looking for Category:We Can Do It but i didnt remember the exact slogan. https://commons.wikimedia.org/w/index.php?search=work+poster+women or "work poster women war" doesnt really help, but google can understand it better and give the wp link as the top result.

this makes me think that commons search should be improved. RoyZuo (talk) 18:26, 20 October 2024 (UTC)[reply]

It's unclear what or how you think it should be improved. I recently listed 11 issues for MediaSearch and its underlying search algo that is also used in the prior SpecialSearch that you link to here. I think it should show some results of the category you linked to because e.g. it contains the word "work" that you searched for multiple times in its categories, description etc combined with the other terms you searched for. I also think the Commons search should be improved, and one issue that I listed there relevant to your case here is that files in use in mainspace on some or several Wikipedias would be good to display high up in the search results and several/many files in the cat you linked are used. The files in the search results are also used but files in the cat you linked aren't even displayed on the next few pages (or scrolling down in MediaSearch). Prototyperspective (talk) 18:41, 20 October 2024 (UTC)[reply]

Use of "opaque" background request template on photographic images

Hi,

I'm looking for some feedback upon whether or not it is considered reasonable to apply the {{Opaque}} template specifically to an image that was originally a photograph taken against a white background. This template states

"This image was uploaded with an opaque background where it should have been transparent. If possible, please upload a PNG or SVG version of this image, derived from a non-JPEG source so that it has an alpha channel and no compression artifacts (or with existing artifacts removed). If it is not possible to obtain a cleaner version then consider creating a new, derivative, image with the background removed, while leaving this image alone; use templates such as {{Retouched picture}} and {{Derivative versions}} as appropriate; then ignore the rest of these requests."

koavf (talk · contribs) applied this to of one of my images here (which was in turn propagated to a cropped derivative).

An image that was taken as a photograph with no inherent transparency "should" have been uploaded with a transparent background? Really? Are you arguing that every such image "should" have been manually (and painstakingly) worked on to do this before upload? Because that's the only way you're going to get that from a regular photograph.

I reverted the change on both versions, but on the derivative copy, my reversion was undone by Koavf with the argument that

"It's totally valid to have a photographic element extracted from its background to have a transparent one and it's totally normal in a lot of bitmap formats such as PNG. It's not possible with JPEG, that's true, but the photo could be embedded in PNG and have the background removed."

This misses the point. There's a big difference between effectively arguing that it would be *nice* to have a version of this image with a transparent background and (mis-)using a template that states that it "should" have been uploaded like that in the first place.

To me, it seems obvious that this template was intended for images where transparency *already* inherently existed and could be restored from the source, or where it could easily be applied by re-rendering.

In a previous message on Koavf's talk page, I noted politely but pointedly that

"If you [Koavf] are willing to do the hard work [emphasis added here] of Photoshopping it to (convincingly) remove the background yourself, and upload that version as a borderless PNG version under a different filename, please feel free to do so."

The hint clearly wasn't understood or taken. And Koavf didn't, of course, get round to doing themselves the "hard work" they seemed to take for granted the uploader would be magically able to do.

Regardless, by that logic, one could slap this template on countless JPEGs of objects photographed shot against a white background, and it would just end up being similarly pointless and inappropriate clutter because there's no inherent transparency in photographs, and no simple way to add it. If you *want* someone to do that, please don't misuse {{Opaque}} for that reason.

Please let me know what you think. Multicherry (talk) 20:35, 20 October 2024 (UTC)[reply]

Agree when it comes to photos. However, I have to add that there's now AI tools to easily and quickly remove backgrounds so maybe it actually makes sense to add them now since a few months or in the near future. Search for hugging face remove background to find some Web tools to do so. Maybe something could be done there. The large template seems unwarranted in such a cases however. Prototyperspective (talk) 20:46, 20 October 2024 (UTC)[reply]
@Prototyperspective: Even if that were the case- and there is a place for that- I would disagree with the misuse of the {{Opaque}} template for that purpose.
I'd also disagree that such versions *should* be uploaded- or expected- as the "original" rather than as a derivative and modified version (and clearly marked as such), if only for reasons of veracity. Multicherry (talk) 21:07, 20 October 2024 (UTC)[reply]
Entirely unreasonable. {{Opaque}} is clearly intended to be applied to non-photographic images (like logos or diagrams) which were "generated" with a matte background, and where it's possible for the creator of the image to losslessly regenerate the image from source data without that background. It is not applicable to photos. Omphalographer (talk) 20:56, 20 October 2024 (UTC)[reply]
@Omphalographer: My point exactly, thank you. Multicherry (talk) 21:07, 20 October 2024 (UTC)[reply]
"one could slap this template on countless JPEGs of objects photographed shot against a white background". So? There's a lot to do. This is a media repository with an extremely broad scope and we could plausibly have... 100 billion pieces of media? Just because that's a tall order that we're not likely to ever fulfill, does that mean we should give up? I just don't even understand this line of reasoning. —Justin (koavf)❤T☮C☺M☯ 22:37, 20 October 2024 (UTC)[reply]
@Koavf: - You're still missing- or ignoring- the main point that has been stated multiple times. Please go back and read what I already said elsewhere in this discussion, especially here.
Again, the problem is that you're misusing a template whose wording makes clear that it isn't intended for cases where one would like the background manually removed, it's for ones where the background *should* be removed.
Whether or not it would make sense to plaster a wish for background removal on every single white-background-image (and my personal feeling is that it would just be clutter because no-one will have time to do that vast majority), it certainly shouldn't be done via the misuse of the {{Opaque}} template, which covers a different use case.
If there's no existing way of requesting such edits in a more appropriate manner, IMHO a new template or mechanism should be created. Multicherry (talk) 18:24, 21 October 2024 (UTC)[reply]
You are making up stuff about what Template:Opaque/doc says. I have yet to see a usage of {{Opaque}} that is inappropriate. —Justin (koavf)❤T☮C☺M☯ 18:27, 21 October 2024 (UTC)[reply]
@Koavf: That's precisely what this discussion was started to clarify. Several others in this thread (myself included) disagree with you.
But let's go with your assumption that you *were* using the template correctly and that it accurately reflects what you want to say- namely that that I "should" have uploaded a photograph with transparancy pre-applied.
Really? Do you imagine I have a magic camera that automatically does that? Or are you suggesting the onus is on me to manually apply transparency to an image where it never existed in the first place?
I'm not saying that particular photograph is especially great, or that I spent that much time taking it, but it's still irritating to see someone slap wording on it telling me I "should" have uploaded it with transparency applied when I already spent time taking the photo and they haven't done anything.
Or maybe that's not what you meant, and that's only how it comes across because the wording was never written with that usage in mind?
Multicherry (talk) 18:54, 21 October 2024 (UTC)[reply]
Could you please stop with the hysterics? No, I don't think you have magic. It's fine to upload an image with one format or border or cropping or whatever and then modify it to add another. This happens all the time and doesn't require magic. No one is saying that you should have done anything: I'm saying that a modified version of the image would be best. —Justin (koavf)❤T☮C☺M☯ 19:09, 21 October 2024 (UTC)[reply]
"Hysterics"? No. You can read that "magic" comment as irritated sarcasm if that wasn't already as obvious as it should have been.
Regardless... if what you were actually saying- or rather, what you wanted to say- was "that a modified version of the image would be best", well... that's not what the template says. Which is the point I was trying to make. Multicherry (talk) 19:35, 21 October 2024 (UTC)[reply]
If you could please stop saying one thing and then rewording it as another and also rewriting what I say, that would be nice. —Justin (koavf)❤T☮C☺M☯ 19:46, 21 October 2024 (UTC)[reply]
Agree with Multicherry. Prototyperspective (talk) 18:55, 21 October 2024 (UTC)[reply]


I don't like the phrasing of the template. It's almost accusatory, like the person who uploaded the image it's applied to made a mistake. But it's used on various .jpg files (files that don't support transparency), where it basically serves as a request for a .png version to be made where the subject is isolated from its background. In that sense I don't think the template was mis-applied, but the wording should be fixed so a request for a derivative version doesn't read like an insult to the original. ReneeWrites (talk) 21:26, 20 October 2024 (UTC)[reply]

@ReneeWrites: As you note, misusing {{Opaque}} in that context gives it an irritatingly accusatory and entitled tone, and I don't think that was ever the intention.
The reason it comes across badly is because it *is* being "mis-applied" for something it wasn't meant for.
It clearly *wasn't* written to be used as a "request for a .png version". As Omphalographer (talk · contribs) noted, it was intended for cases where it would be easy for the uploader losslessly obtain or create a transparent version.
I don't think it should be reworded. If a "transparency request" template is needed, a new one should be created for that distinctly different purpose (assuming there isn't a suitable candidate already).
What we *shouldn't* be doing is slathering the {{Opaque}} template all over images where it doesn't make sense.
Multicherry (talk) 21:49, 20 October 2024 (UTC)[reply]

New report: Category cycles

Thanks to SD0001 there is now a report for categories that contain themselves somewhere in their subcategories: Commons:Database reports/Category cycles.

For each item in this report there is a flaw in the categorization somewhere creating a categorization loop. This may also be a problem for search results and the deepcategory search operator that can be used to show or search files across a category's subcategory branches.

Here's a small sample:

It is easiest to find a category that should be removed for page 1 where one can simply remove the direct self-categorization. In this example one would remove category "Fungi of Italy" on category "Fungi of Italy". In later pages it's not necessarily more difficult to identify a miscategorization somewhere in the cat-path than in earlier pages. In some cases, a new category is needed or a change in a category description (from where one could link to a category). The same report also exists for Wikipedia categories.

SD0001 who ran the code said Due to the sheer volume of data involved, even the initial step to fetch the list of all subcategory associations from the database was failing both on Toolforge bastions and on the Toolforge kubernetes cluster. I then spun up a 16-core, 32 GB RAM instance on Cloud VPS, and there it all worked out! So the report probably can't be updated frequently. Maybe it could be possible to make it rescan the cats of a particular page and then update just that page but for now it doesn't seem so. Thus, if you work on this report a lot, it would be good to coordinate with other users, for example by removing/striking items from the report if you solved them or making a post on the talk page which page(s) you work on. Prototyperspective (talk) 21:36, 20 October 2024 (UTC)[reply]

Nice, maybe the 7000 small cycles (parent=child) could be listed separately?
 ∞∞ Enhancing999 (talk) 21:41, 20 October 2024 (UTC)[reply]
They are on page 1 (starting at 津まつり → Copyright (C) 八幡の笛木) up to page 15 (ending at Selve (Unternehmerfamilie) → Hermann Dietrich Selve) so they're already separate.
However, it would be best if one could update specific parts of the reports individually. I think a straightforward way for that would be rescanning cat links on a particular page and updating that page and I asked whether that's possible on the talk page where the report was requested. Maybe it's also possible to make it scan all categories again for parent=child category-cycles but I think that would run longer etc than simply checking a list of cat-links. I don't know though, maybe it would actually be easier to implement that if not yet possible / or only that is possible with the current code. Prototyperspective (talk) 21:52, 20 October 2024 (UTC)[reply]
In any case, they are still at Quarry:history/87030/938798/910988.
 ∞∞ Enhancing999 (talk) 21:53, 20 October 2024 (UTC)[reply]
Awesome. It looks like some of the single cycle categories are that way because of templates. Any idea what to do in those cases? (I assume you can't just remove said category from the templates code for something like that). unsigned by Adamant1 (talk)
It varies: often the template parameters need to be changed. In some cases the template itself may need to be edited in which case one can ask on its talk page and/or remove (or comment out) the template to replace it with just the remaining categories. In the case of Category:1559 sculptures in Italy with Template:StatuesItalyCat, the template was made for statues cats but is also used for sculptures cats causing this problem. There the solution I think would be to remove the cat or ideally to create either a new template for sculptures (such may already exist and only be adjusted for Italy) or add a parameter to the existing cat. I think people going through that report could ask the people who added the template and/or created the template to fix this problem instead of fixing it themselves.
However, a template for this purpose may already exist so maybe if some people have a good handle of such navigation templates they could take a look at those items which appear many times in these reports and fix the underlying template issues of them (such as those {year} sculptures cats). --Prototyperspective (talk) 20:58, 22 October 2024 (UTC)[reply]

Photo challenge August results

Dust: Entries • Votes • Scores
Rank 1 2 3
image
Title Mustangs in Colorado, USA, ǃ971 Dusty Billiard Table, former Pozzuolo
del Friuli barracks, Ferrara, Italy		 The Milky Way with cosmic dust
Author Foeniz Nicola Quirico Zwiebackgesicht
Score 13 10 7
Spices: Entries • Votes • Scores
Rank 1 2 3
image
Title The Christmas spices star anise, cinnamon and cloves Chili peppers at the market in Santanyí Blüte mit Safranfäden
Author F. Riedelio F. Riedelio Tetraeder
Score 17 6 6

Congratulations to Foeniz, Nicola Quirico, Zwiebackgesicht, F. Riedelio and Tetraeder. -- Jarekt (talk) 22:12, 20 October 2024 (UTC)[reply]

Template:Commons Archive

A few months ago I noted that the link in Template:Commons Archive is a 404 error.

It still seems broken. Does anyone know why? If permanently shut down the template should get updated wording, it appears on over 200 file description pages. Commander Keane (talk) 23:08, 20 October 2024 (UTC)[reply]

Per my understanding of https://phabricator.wikimedia.org/T306064 and https://wikitech.wikimedia.org/w/index.php?title=Nova_Resource:Commonsarchive&action=edit&redlink=1 and my generally hazy memory, Commons Archive was deleted. The files there were mirrored at Internet Archive, which is an issue for now, as the site is experiencing some catastrophic issues. —Justin (koavf)❤T☮C☺M☯ 02:14, 21 October 2024 (UTC)[reply]
Internet Archive is back up; the contents of this archive can be retrieved (with some effort) from [4]. Omphalographer (talk) 20:19, 21 October 2024 (UTC)[reply]
Thanks. Fixed the link. —Justin (koavf)❤T☮C☺M☯ 21:02, 21 October 2024 (UTC)[reply]

October 22

Question about images with serial but non destructive watermarks

I know that there is the "Graphics Village Pump" that may be more suitable for this question, but I think that this issue is more general and may be discussed even here (and even because here there are more users that can see and answer. XD)

There are some guidelines about watermarks on images, but those are not official policies of Commons (and I hope that they don't become part of them)

There are archives that put their watermarks even in a serial way, over the commonly one in a corner. These are ratherly non-destructive and sometimes even "invisible" due to the nature of the historical photo. How should we handle this particular case?

The images in particular I'm talking about are something like this ([5]) and this ([6]), from the huge archive "Istituto Luce" from Italy, with tons and tons of PD photos waiting only to be uploaded, and another one called EBAD (Italy has a particular law, that distinguishes between "creative" and "non-creative photos", the second ones being the ones from natural and everyday society and events... at least with the object not in a particular "position" and things like that; for those "non creative" photos the copyright is only 20 years after being taken, that is to say that all the 'non creative' photos shot in Italy until 1975 can be directly uploaded here on Commons, a great deal)... the only problem being that there are those serial watermarks on it. Here in Italy they love putting tons of watermarks even on perfectly PD photos and on entire historical archives... they think they can still profit from them, scaring ignorant people... but they still didn't know about us Commoners.

There have been some discussion about this (even in the discussion page of the guidelines theirselves) and I have even talked to some experienced users here, like the italian @Ruthven: (who still pointed to those guidelines).

In general, I (and the the other users in the guideline's discussion page) believe that PD and free-license photos should be uploaded regardless of their quality and how they are "adorned": we simply put the Template:watermark and simply hope that in future we will be able to find the same photo without those watermarks.

What do you think about it (even about those images that I linked specifically)?

Thanks alot for your attention, it is important. --LucaLindholm (talk) 11:45, 22 October 2024 (UTC)[reply]

Hi, I checked the two links you provided, but I think it would be good if you also linked to the previous discussions you had. I'm sceptical about the Italian law claims (it says here: "use very carefully" with regards to "non-creative photos"). But in my following opinion I am mostly disregarding possible Copyright concerns, as the topic is watermarks here.
Now, the link to Luce, labeled [5], is in my opinion a highly destructive way of watermarking. The watermarking pattern covers the entirety of the image: if all images from that archive look like that I don't see why Commons should host these basically unusable files.
The Ebad watermark [6] is big and flashy and possibly distracting when used to illustrate an encyclopedic article... but it's not as bad as the other one, as long as it doesn't cover important features of the images. Users would be able to crop an image for their purposes if needed.
Yet, unmarked images would be preferable. To get those, I would assume that one could ask the archives directly (via GLAM contacts etc.) to kindly give access to non-watermarked versions for Commons uploads. There are benefits for them too: Just look at other big contributors like Rijksmuseum, Eran Laor, LoC, Polonia and Gallica: uploads from these institutions have big templates with the contributor's logo that link everyone to the original files: that shows providence properly, gives prestige back to the institution and makes watermarking fairly unnecessary. That's my reason for wondering why the archives insist on watermark-only images? Oh, and in case that we haven't asked for such permission yet, we should: The reaction tells us whether Commons/Wikimedia could get into trouble if we just rip the watermarked stuff from their pages without asking. If we "rob" them now, that makes future collaboration more difficult. The archives would also warn us away from stuff that might still be copyrighted for whatever reason. --Enyavar (talk) 21:21, 22 October 2024 (UTC)[reply]
-------------------------
@Enyavar
Ok, so we have to proceed first by contacting them, confirming what @Ruthven said. So how should we do that? What is a "GLAM" contact? Who should do that? I'm still not expert on this.
Yeah I know it's an embarrassing way to watermark, but here in Italy they want to speculate on everything, profiting about the fact that people is very ignorant about their own rights (Ruthven may know it well, being him Italian too).
Let's see, so, if we can contact these archives and bring so much more value to our good Commons portal. :)
The EBAD one is little and unknown... we may persuade them in a fast and easy way.
The "Luce" one, instead, is perhaps the second most important and big archive in Italy and most of all, it is the most famous, being particularly linked to the fascist Italy and the first half of the 20th century in general. It is well guarded and won't give away anything in a easy way.
I suggest to start with the EBAD (Eboli Archivio Digitale, main page: [7]), what's the next step? -- LucaLindholm (talk) 22:54, 22 October 2024 (UTC)[reply]

Accusation about "vandalizing" without giving reasons

A. Savin accuses me of "vandalizing" without giving any reasons. I don't know what this person means, I did'nt vandalize anything. What should I do? Could it be that someone has broken into my account and is doing nonsense under my name/pseudonym? And how could I check on this?Hornstrandir1 (talk) 13:28, 22 October 2024 (UTC)[reply]

All contributions made by your account can be seen at Special:Contributions/Hornstrandir1, there will be a "Contributions" link somewhere at the top of the interface when you are logged in so you can find the page easily. Check the edits there for nonsense from a break in.
If you don't understand a warning, discuss it. I see you already have on your talk page. Reasons have been given. Keep in mind that "vandalizing" can be used as a broad term with varying understandings. Commander Keane (talk) 22:20, 22 October 2024 (UTC)[reply]

Non-deletion decision File:19-23-038-davis.jpg

Commons:Deletion requests/File:19-23-038-davis.jpg Creuzbourg (talk) 13:33, 22 October 2024 (UTC)[reply]

The uploader claims copyright, although he is only the photographer. No statement of original author (painter) exists. This is a newly made painting Creuzbourg (talk) 18:41, 27 July 2024 (UTC)

Keep Attribution fixed. Keep if "made public" in 1959. --RAN (talk) 00:08, 28 July 2024 (UTC)

Kept: no valid reason for deletion. --Sadads (talk) 01:18, 22 October 2024 (UTC)

The uploader is only the photographer; still claims to be copyright holder. The painting is presented by Georgia Division by the United Daughters of the Confederacy in 1959. When did the artist lose copyright to the photographer?

Creuzbourg (talk) 13:36, 22 October 2024 (UTC)[reply]

@Creuzbourg, hasn't the file page been updated to fix your issue? Now the author is George Mandus, photographer is Dsdugan and licence is PD. Commander Keane (talk) 18:46, 22 October 2024 (UTC)[reply]
(e/c)
The licensing information for the file is inadequate. It does need to show that the painting (and the frame) has a free license.
If the painting were published in 1959, then COM:Hirtle leads many places. Published without a copyright notice would put the image in the public domain. The plaque on the frame does not have a copyright notice. If there were a copyright notice somewhere else, then there would need to be a renewal 28 years after publication. That would need to be checked.
This topic should have been brought up on Commons:Village pump/Copyright.
(talk) 18:52, 22 October 2024 (UTC)[reply]
@GlrxThank you for your reply. Shall I move the matter to: Commons:Village pump/Copyright? I do not understand how the photographer becomes the copyright owner, and believe that the image should be deleted. Creuzbourg (talk) 20:05, 22 October 2024 (UTC)[reply]
I can edit the license so it's more clear. The license stated is for the photograph as this is a 3D work with frame. Abzeronow (talk) 20:17, 22 October 2024 (UTC)[reply]
Ordinarily, George Mandus (the painter) would have a copyright to his work. In many circumstances, a photographer making a photograph of someone else's work has a copyright on his derivative work. That copyright does not negate the original artist's work. In this case, the File page adequately described the photographer giving a free license to the derivative work, but there must also be a free license for the underlying painting. A faithful photographic copy of a 2D painting usually does not qualify for a derivative work copyright.
Moving this topic to the copyright page would be good. The contributors there understand the issues far better than I. Glrx (talk) 20:58, 22 October 2024 (UTC)[reply]

October 23

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