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 104 36 Bastique 2024-10-04 21:17
2 Hosting HDR images as JPEG with gain map 0 0
3 How to change the text in a speedy deletion (GA1)? 6 3 ReneeWrites 2024-10-09 16:30
4 Publishers info in newspapers 11 6 Enhancing999 2024-10-04 12:33
5 Special:EditWatchlist timed out 11 5 ReneeWrites 2024-10-03 23:52
6 Help:Misinformation 6 5 Prototyperspective 2024-10-03 09:52
7 Template:No advertising 2 2 Prototyperspective 2024-10-03 10:00
8 Intersection category of gender, occupation, nationality and decade of birth 13 7 Prototyperspective 2024-10-07 12:06
9 What are these Arabic seals called? 3 2 Omphalographer 2024-10-07 02:11
10 Template:Cosplay at 3 2 Ellicrum 2024-10-05 23:02
11 Invitation to Participate in Wiki Loves Ramadan Community Engagement Survey 0 0
12 Wikidata infobox forcing Wikidata based DEFAULTSORT 21 7 Pigsonthewing 2024-10-07 10:51
13 Dashes in category names 13 7 Prototyperspective 2024-10-07 14:11
14 Uploading photos taken in a commercial establishment 11 5 Ineuw 2024-10-10 00:55
15 New reports: categories with only redcats & cats with only infobox cats 17 8 Nowakki 2024-10-10 04:30
16 Exhibition at the M.H. de Young Memorial Museum, 1932 2 2 Pigsonthewing 2024-10-09 16:14
17 OsmappBot uploads from the OpenStreetMap app 4 4 JohnCWiesenthal 2024-10-09 19:20
18 Category:Minority schools, etc. 2 2 Adamant1 2024-10-10 01:14
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.
Village pump in Sabah, Malaysia. [add]
Centralized discussion
See also: Village pump/Proposals   ■ Archive
Template: View   ■ Discuss    ■ Edit   ■ Watch
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 7 days.

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]

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]

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]

September 26

How to change the text in a speedy deletion (GA1)?

I have changed the meaning of GA1 to "Gallery page without at least two images or other media files" in Commons:Criteria for speedy deletion, but when I use this code in a gallery, the old text is used in the deletion, see for example Giusto Le Court. How can I change that text as well? I think it is hidden somewhere, but I cannot find the right place. This question was posed at Commons talk:Criteria for speedy deletion#How to change the text in a deletion?, but there was no answer, so I hope I have more luck here. JopkeB (talk) 14:43, 26 September 2024 (UTC)[reply]

It might be because the text hasn't been translated into other languages yet. It looks like the last update to other pages besides English was in May. That's the only thing I can think of though. --Adamant1 (talk) 16:04, 26 September 2024 (UTC)[reply]
@Adamant1: Where can I find those texts to be translated? JopkeB (talk) 05:21, 2 October 2024 (UTC)[reply]
@JopkeB: Template:Speedydelete/en, the Dutch subpage is here: Template:Speedydelete/nl. ReneeWrites (talk) 22:53, 6 October 2024 (UTC)[reply]
Thanks @ReneeWrites: but I do not think this is what I mean. This text is before the gallery page has been deleted. I am looking for the text after a gallery page has been deleted with reason GA1. See Giusto Le Court JopkeB (talk) 15:05, 9 October 2024 (UTC)[reply]
@JopkeB: that text is added by the admin who removed it. Sometimes they'll copy-paste the text you provided as the deletion reason and sometimes they put something else there. ReneeWrites (talk) 16:30, 9 October 2024 (UTC)[reply]

Publishers info in newspapers

We have a name for the masthead on page one, but what is that paragraph on page two that contains info on the publisher called? I want to direct people to where the copyright symbol is/isn't in various newspapers. RAN (talk) 17:59, 26 September 2024 (UTC)[reply]

Maybe the credit line or word mark depending on the situation? My money is on it being the credit line. It's hard to say without an example though. --Adamant1 (talk) 18:31, 26 September 2024 (UTC)[reply]
@Richard Arthur Norton (1958- ): w:Masthead (American publishing) or anything in the See also section there.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:02, 26 September 2024 (UTC)[reply]
It is a subset of "Front matter" (sometimes "front-matter" or "frontmatter"). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:49, 27 September 2024 (UTC)[reply]

You can see the difference here: File:Masthead for the Desert Sentinel of Desert Hot Springs, California on April 21, 1977.jpg and File:Publisher information for the Desert Sentinel of Desert Hot Springs, California on April 21, 1977.jpg One possibility is "Staff masthead" per the link you showed . --RAN (talk) 19:23, 26 September 2024 (UTC)[reply]

w:Impressum notes some related terminology.
 ∞∞ Enhancing999 (talk) 09:02, 28 September 2024 (UTC)[reply]
Often, its in very small print, at the botton of the last page of an issue.-- Broichmore (talk) 16:49, 29 September 2024 (UTC)[reply]
It would be good to get some examples of that in each newspaper category. --RAN (talk) 22:57, 2 October 2024 (UTC)[reply]
  • @Enhancing999: I did find a copyright notice on the back page of several newspapers but in each case the copyright holder was the company taking out the full page ad on the back page of the paper, did you find any examples? --RAN (talk) 02:50, 4 October 2024 (UTC)[reply]
    When responding to your iniital question about the terminology/naming, I had a look at Commons categories as well, but they were hardly as detailed as Wikipedia. So there is some potential to improve our category tree in the field, possibly leading to discovery of more samples.
     ∞∞ Enhancing999 (talk) 12:33, 4 October 2024 (UTC)[reply]

September 27

Special:EditWatchlist timed out

Hi, I've tried editing my watchlist several times to clean it up, because it's too big, but every time it produces a Timed out error. Is there any way to overcome the error? Or perhaps an administrator could completely clean up my list. Thank you for your collaboration--JotaCartas (talk) 23:14, 27 September 2024 (UTC)[reply]

Editing your raw watchlist at Special:EditWatchlist/raw shouldn't time out. William Graham (talk) 23:28, 27 September 2024 (UTC)[reply]
thanks Graham, I've been trying for more than 15 minutes to edit raw watchlist, but it also gives a "page irresponsive" error. I've been an editor since 2009 (15 years with more than 1'500'000 editions)) and I've never cleared the watchlist, so it must be very large. Any help is welcome JotaCartas (talk) 23:50, 27 September 2024 (UTC)[reply]
OK, I stopped being lazy, and I'm going through the preferences, to see if I can find the solution. If nothing works, I'll ask for help here again, thank you any way JotaCartas (talk) 00:10, 28 September 2024 (UTC)[reply]
OK, Watchlist cleared, problem resolved, thanks and sorry for the trouble JotaCartas (talk) 00:22, 28 September 2024 (UTC)[reply]
This is not a trouble, it's a great question. I have the same problem. How did you resolve it? —Justin (koavf)❤T☮C☺M☯ 00:28, 28 September 2024 (UTC)[reply]
That also times out. —Justin (koavf)❤T☮C☺M☯ 00:27, 28 September 2024 (UTC)[reply]
Hi, I just cleared de watch list. Path: Preferences -> Watchlist tab -> Clear your watchlist button. That was my solution. The Watchlist is now completely empty, but I had more than 400,000 entries and the number of warnings I was receiving was becoming overwhelming, regards JotaCartas (talk) 00:39, 28 September 2024 (UTC)[reply]
Obrigado, amigo. —Justin (koavf)❤T☮C☺M☯ 00:53, 28 September 2024 (UTC)[reply]
you guys should also consider checking Special:Preferences#mw-prefsection-watchlist so that you dont collect another long list over time. RoyZuo (talk) 18:50, 28 September 2024 (UTC)[reply]
That page is a lifesaver (also I had no idea I had so many closed discussions on my watch list), easy to edit and loads fast as hell. ReneeWrites (talk) 23:52, 3 October 2024 (UTC)[reply]

September 28

Help:Misinformation

This is a new page on misinformation in Wikimedia projects, mainly about ways to mitigate it and practices it is currently being addressed on Commons. Secondarily, it also lists some Commons-relevant ways it Wikimedia projects may be used to mitigate misinformation and inaccuracies in the external world.

If you know of anything more to add, please do so.

I think many more files here need the {{Accuracy}} template, a dedicated place to discuss accuracy disputes was needed, a dedicated info page for readers confused about files with misinfo here was needed, the warning about Accuracy issues should also be displayed in the MediaViewer, and something that puts new version file overwrites under more scrutiny (like showing up in Wikipedia Watchlists) could be useful.
--Prototyperspective (talk) 17:33, 28 September 2024 (UTC)[reply]

You have my full support. IMO, we should have no truck with any items derived from en:Artificial intelligence. This is step one, in the process. Broichmore (talk) 19:21, 28 September 2024 (UTC)[reply]
What this got to do with AI? Trade (talk) 20:03, 30 September 2024 (UTC)[reply]
I'd love to see more stringent rules around user created "flags" and coats of arms. I'm not sure just adding the {{Accuracy}} template is adequate there in most cases, but then it's also not that easy to just have the images deleted either due to the gaps in the guidelines around the subject. Really that goes for other types of misinformation to. The project really lags behind in moderating and mitigating it compared to other sites. --Adamant1 (talk) 20:26, 28 September 2024 (UTC)[reply]
  • Better to delete fan made flags and COAs for real places. I am fine with fictional flags for fictional places and people if marked properly. --RAN (talk) 23:24, 2 October 2024 (UTC)[reply]
    Agree. I think the point would be whether or not that should be added to this page. I don't know if such flags are speedily deleted (G1 / G3?) but maybe there should be a discussion about that – if I would come across a fan flag for a real place made I would tag it for speedy deletion except if it's some kind of cultural phenomenon such as people in that place actually using that flag or an Internet phenomenon in which case the description or title would need to inform about that instead of suggesting it's the actual flag.
    Very brief info on how such things are dealt with would be good to add to this page. Prototyperspective (talk) 09:52, 3 October 2024 (UTC)[reply]

Template:No advertising

This text seems helpful to advise corporate accounts that try to add texts (almost any) at Commons. I used it the other day and read (or re-read) it.

The part about "Uploading of company logos, press images," could probably be improved. Currently it reads "in order to advertise or use them only in promotional material on other wikis is also prohibited, and such images will be deleted if they are found to violate our policies."

If either are properly licensed, wouldn't these generally be useful?
 ∞∞ Enhancing999 (talk) 20:59, 28 September 2024 (UTC)[reply]

Good point, the better place to ask about it would probably be the template talk page. However, it actually reads Uploading of company logos, press images, and the like in order solely to advertise or use them in promotional material on other wikis. I think it makes sense but may get understood so some clarification that uploading logos and press images could be useful and that the account should not add it to a Wikipedia article but at most ask about it on the talk page. It doesn't seem like an important change since probably ~90% of such media can't be used for anything but advertising with there e.g. also being nonadvertising photos of the product and logos probably also won't get uploaded more often if this template was changed (I don't know where it's used but it's probably not even read before upload anyway). Prototyperspective (talk) 10:00, 3 October 2024 (UTC)[reply]

October 02

Intersection category of gender, occupation, nationality and decade of birth

There're these categories https://commons.wikimedia.org/w/index.php?search=intitle:%22born+in+the%22&sort=create_timestamp_asc e.g. Category:Actresses from the United States born in the 1990s. is it necessary?--RoyZuo (talk) 18:02, 2 October 2024 (UTC)[reply]

Probably not. If I had my way there would just be flat lists or metacats of actors and actresses by name. Minus the whole "by birth" thing since it's totally pointless trivia. More so with "by decade of birth." I'd almost argue the same for "by nationality" to BTW. --Adamant1 (talk) 18:17, 2 October 2024 (UTC)[reply]
  • It doesn't make it easier to find someone, it makes it more difficult, unless accompanied by a flat list that contains all the entries. If we made searching in Wikidata easier, we would not need these intersection lists. --RAN (talk) 23:22, 2 October 2024 (UTC)[reply]
A commercial databank, wouldn't go to this level. We actually only need the Actors name here, Equity demands that names are unique, as it is.
Other websites do it better. Wikipedia is where people are going to look for this kind of info, not here. I suppose computers search progs will use Wikidata. Wikidata gives us a detailed infox already.
Main cats are flat cats, by definition. In this case the name of the actor. As an aside, I would be in favour of a rule that states we shouldn’t have more than 4 levels to any main cat. In this case the main cat being People. Broichmore (talk) 13:49, 4 October 2024 (UTC)[reply]
4 levels seems a little extreme but it's a good suggestion in general. There's some pretty cavernous category structures out there and most of this stuff is better off in infoboxes or otherwise stored on Wikidata's end anyway. With people specifically, most of the time we already know the person's gender from their first name. So it seems kind of pointless to have categories for it. Plus there's a risk of it getting really pointless and obscure depending on the situation. --Adamant1 (talk) 18:48, 4 October 2024 (UTC)[reply]
Separate issue, but how do you feel about categories for other biographical metadata like Category:Births by location (e.g. Category:Births in Fairbanks, Alaska) or Category:Deaths by year? These, too, feel like situations where Commons categories are being misused as a sort of Wikidata-lite to describe people, rather than classifying media. For instance, the aforementioned "Births in Fairbanks, Alaska" contains categories of images of people who were born in Fairbanks, not images of people being born in Fairbanks. Omphalographer (talk) 22:59, 4 October 2024 (UTC)[reply]
I've always thought it was weird that categories for "births" contain images of and categories for people who have already been born. I assume a lot of them are added through templates though. So I'm not really sure there's anything that can be done to fix the issue. That's assuming there would even be a consensus to deal with it to begin with. But if it were me I'd confine categories for "births" to actual images of the birthing process and/or babies being born. But then who knows where the sub-categories would go in that case. "People by birth location" maybe? Or just completely ditch the whole scheme as meaningless trivia outright. --Adamant1 (talk) 23:13, 4 October 2024 (UTC)[reply]
I consider those unnecessary cats too.
also same thing for the deaths by causes, buildings by height Category:123-meter-tall structures, bridges by length Category:3.1-kilometer bridges... RoyZuo (talk) 14:55, 6 October 2024 (UTC)[reply]
Commons:Categories for discussion/2024/10/Category:Births by location and Commons:Categories for discussion/2024/10/Category:Structures by height --Adamant1 (talk) 19:51, 6 October 2024 (UTC)[reply]

Category:Miss Elizabeth is categorized under Category:Miss (surname) due to {{Wikidata Infobox}}, which is far from the most boneheaded thing I've seen emanating from WI. And some of you still think it's a good idea to let Wikidata hijack our category structure simply because you could never be bothered to do any of the hard work yourself? Excuse me while I go somewhere and laugh my balls off. RadioKAOS / Talk to me, Billy / Transmissions 23:23, 6 October 2024 (UTC)[reply]

So fix it! (Which I just did.) Commons doesn't exist in a vacuum; we shouldn't duplicate work being done by other Wikimedia projects. Omphalographer (talk) 23:39, 6 October 2024 (UTC)[reply]
"So fix it" = existing in a vacuum. I wouldn't even mention it if it weren't representative of a much bigger problem. As I hinted in the other discussion, I really hate mentioning examples because it ALWAYS provides an excuse for the other person to dwell on the example and ignore the big picture. RadioKAOS / Talk to me, Billy / Transmissions 02:57, 7 October 2024 (UTC)[reply]
Strongly agree with Omphalographer. We should minimize time and effort required as well as deduplicate work. For example, I think there could be a bot that suggests categories for Commons categories if the cats differ between WMC and WP so both are in sync (they don't have to be the same but often cats here miss some valid useful cats). Just saying "So fix it" would indeed be a case of existing in a vacuum, it would be a good point but that's not all the user said and elaboration of what the "much bigger problem" would be is missing. I could make an actual argument there for your case but I don't know if that's what you mean(?): Wikidata items may have inaccurate data and its items are less well maintained in the sense of watched for vandalism or flawed edits. An argument against that is that people here can see this flawed cat in the category page, they don't see the change in their Watchlist, but they can edit the Wikidata item if they notice it's flawed and also inaccurate data in the few (imo too few) fields that the infobox auto-adds to categories aren't that common. The main argument against this point is a potential solution: scripts that check for difference that likely need manual checking such as when a (surname) category set on an item differs from the category's first word, or items that have "Miss (surname)" where the first word differs and so on [a comprehensive ruleset could be developed]. Prototyperspective (talk) 12:06, 7 October 2024 (UTC)[reply]

October 05

What are these Arabic seals called?

I've seen a number of images similar to these pop up while attempting to categorize new uploads - they appear to be stylized representations of a name, but I'm not sure what that's called. Is there a standard name and/or category for this type of image? Omphalographer (talk) 20:40, 5 October 2024 (UTC)[reply]

I would assume Category:Arabic calligraphy and Category:Islamic calligraphy. Jonteemil (talk) 00:53, 7 October 2024 (UTC)[reply]
I mean the seals in particular. While those categories do contain a number of images of this type, they're general to all Arabic calligraphy, not this specific form. Omphalographer (talk) 02:11, 7 October 2024 (UTC)[reply]

Template:Cosplay at

Hi everyone, if we use the template concerned, there are automatically in the Category:Cosplay by event the different years for each event, which is duplicated with the sub-templates. Is it possible to modify the main template to limit the number of categories? Ellicrum {bablute [...]} 22:37, 5 October 2024 (UTC)[reply]

I really dont get why we cant just only include the categories without years Trade (talk) 22:47, 5 October 2024 (UTC)[reply]
It wouldn't be a problem if we added the categories manually, but it would be a shame not to be able to optimize the template in question. --Ellicrum {bablute [...]} 23:02, 5 October 2024 (UTC)[reply]

October 06

Invitation to Participate in Wiki Loves Ramadan Community Engagement Survey

Dear all,


We are excited to announce the upcoming Wiki Loves Ramadan event, a global initiative aimed at celebrating Ramadan by enriching Wikipedia and its sister projects with content related to this significant time of year. As we plan to organize this event globally, your insights and experiences are crucial in shaping the best possible participation experience for the community.

To ensure that Wiki Loves Ramadan is engaging, inclusive, and impactful, we kindly invite you to participate in our community engagement survey. Your feedback will help us understand the needs of the community, set the event's focus, and guide our strategies for organizing this global event.

Survey link: https://forms.gle/f66MuzjcPpwzVymu5

Please take a few minutes to share your thoughts. Your input will make a difference!

Thank you for being a part of our journey to make Wiki Loves Ramadan a success.


Warm regards,

User:ZI Jony 03:19, 6 October 2024 (UTC)

Wiki Loves Ramadan Organizing Team

Wikidata infobox forcing Wikidata based DEFAULTSORT

The {{Wikidata Infobox}} template seems to impose an (anglosaxonic?) DEFAULTSORT ordering on categories of people based on Wikidata, without broad discussion with the community and completely messing up a number of categories. Example: Category:Male politicians of São Paulo, try to find Category:Professor Fernando there, even if you know his real full name. It's impossible. Not only he is not know by his full name, and we are expecting an A-Z order of category names, but even if you happen to know his full name, someone added a surname on Wikidata that doesn't even exist in Portuguese. Shouldn't this Wikidata DEFAULTSORT imposition be removed or at least "opt-in" for that template? Pinging @Mike Peel: , who develops the tool. Darwin Ahoy! 14:16, 6 October 2024 (UTC)[reply]

Pinging @Animalparty: who also noticed this problem some years ago. This situation seems to be lingering here for long, I wonder why it hasn't been fixed yet with a simple opt-in policy for that automatic Wikidata based DEFAULTSORT ordering, instead of forcing it everywhere and causing a mess.-- Darwin Ahoy! 14:36, 6 October 2024 (UTC)[reply]

You can disable its DEFAULTSORT.
wdib is used millions of times. obviously its practical solution is going by "opt out" instead of "opt in". RoyZuo (talk) 14:50, 6 October 2024 (UTC)[reply]
@RoyZuo The problem is not WDIB, just the Wikidata based defaultsort "feature". Darwin Ahoy! 15:07, 6 October 2024 (UTC)[reply]
You can just add defaultsort and the bot then de-activates the infobox based sorting. That the default is English comes from category names being in English.
 ∞∞ Enhancing999 (talk) 14:51, 6 October 2024 (UTC)[reply]
@Enhancing999 people names in Portuguese "being in English"? 🤔 Darwin Ahoy! 15:05, 6 October 2024 (UTC)[reply]
Is there are particular category where the outlined approach isn't working?
 ∞∞ Enhancing999 (talk) 15:06, 6 October 2024 (UTC)[reply]
@Enhancing999 Basically all the Lusphone people categories, like Category:Male politicians of São Paulo Darwin Ahoy! 15:07, 6 October 2024 (UTC)[reply]
I checked Category:Eliseu Gabriel: seems ok.
 ∞∞ Enhancing999 (talk) 15:11, 6 October 2024 (UTC)[reply]
@Enhancing999 It isn't, Gabriel is one of his given names, not a surname. Good example of why this shouldn't be enabled by default. Darwin Ahoy! 15:28, 6 October 2024 (UTC)[reply]
It just means it was incorrectly set up at Wikidata (which you seem to have fixed). How about Category:José Pires do Rio? Or should all be under first names?
 ∞∞ Enhancing999 (talk) 15:48, 6 October 2024 (UTC)[reply]
Yes, it was incorrectly set up in Wikidata, that's why it was barely findable in that system. Now that I fixed it adding his surname Pieri he is impossible to find there, unless you know that rather obscure information. And please stop picking singular cases among the almost 100 which are there, obviously some of them would be correct, while many others will not. That one you brought now has the sorting key "Pires", so it's not even an appropiate example as it's not using that automated DEFAULTSORT. DEFAULTSORT key is the name the person is generally known for, in that case "Pires do Rio". There's no general rule related to using given names, surnames or pseudonyms for teh defaultsort. Darwin Ahoy! 15:53, 6 October 2024 (UTC)[reply]
Well, there doesn't seem to be a clearcut rule, so you will have to set DEFAULTSORT if needed.
 ∞∞ Enhancing999 (talk) 16:39, 6 October 2024 (UTC)[reply]
If there is no rule, it never should have been implemented by default, instead of bringing this additional burden to the community here. 🙄 Darwin Ahoy! 17:12, 6 October 2024 (UTC)[reply]
The default MediaWiki rule for categories doesn't seem to be any better.
 ∞∞ Enhancing999 (talk) 17:30, 6 October 2024 (UTC)[reply]
@Enhancing999 And we have been adapting it for more than 20 years. What was the point of changing that to something else equally bad? Darwin Ahoy! 17:56, 6 October 2024 (UTC)[reply]
I doubt it was available before Commons nor at the beginning of Commons: nostalgia, eh?
In any case, you can still use it. The infobox is getting somewhat old too, maybe time for a new system?
 ∞∞ Enhancing999 (talk) 19:22, 6 October 2024 (UTC)[reply]

I've had a lot of issues with DEFAULTSORT myself. It really shouldn't be the default, but then that would kind of defeat the purpose of the whole thing. So maybe it should just be axed? There's no reason people can't, or shouldn't, sort categories whatever way they want to without it being imposed on them through a template though. --Adamant1 (talk) 20:47, 6 October 2024 (UTC)[reply]

If adding the DEFAULTSORT template manually overrides the Infobox's DEFAULTSORT, I don't really see what the issue is. Most casual or novice editors won't think to add the template themselves (and even experienced editors sometimes forget to, i.e. me). In the vast majority of cases it does its job correctly and the few instances where it didn't it can be fixed manually. The alternative is having to add it manually to all categories. ReneeWrites (talk) 09:28, 7 October 2024 (UTC)[reply]

It seems to me entirely natural that the Wikidata rule that, given the right data, is correct well upwards of 95% of the time (98% would not surprise me), is used by default. Just so long as we can override, which we can, that's fine. - Jmabel ! talk 09:42, 7 October 2024 (UTC)[reply]

Per ReneeWrites and Jmabel, the status quo is fine. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:51, 7 October 2024 (UTC)[reply]

October 07

Dashes in category names

Sinigh and I disagree about dashes in category names, especially for dates. I favor the ISO/IEC 646 character known as the hyphen-minus. He favors "–" (which I copy-pasted here, I'm not certain of the code point and I'm headed out the door in about 2 minutes). Our discussion so far can be found at https://commons.wikimedia.org/w/index.php?title=User_talk:Sinigh&oldid=934116270. Probably further discussion should continue here, not there. Other opinions sought, because we each have a decent rationale, but are unlikely to convince the other. - Jmabel ! talk 06:00, 7 October 2024 (UTC)[reply]

En dash indicates a range, so 1800–1885 would be correct. This is as far as I can tell the norm on Commons for both category and file names. The universal hyphen/minus sign is used in category names that don't indicate a date range, see for example every entry here: Category:Days by day. ReneeWrites (talk) 06:31, 7 October 2024 (UTC)[reply]
Category names should use hyphen/minus sign, not en/em dashes. Per Commons:Categories#Category names policy "Basic English characters (ISO/IEC 646) are preferred over national variants or extension character sets (for instance, 'straight' apostrophes over 'curly'), where reasonable." Category names should be something that can normally be typed with a keyboard and should not use extension characters where there is no need. Hyphen is perfectly understandable range sign. MKFI (talk) 06:37, 7 October 2024 (UTC)[reply]
The policy says "where reasonable", which affords flexibility, and its use for ranges is not only completely reasonable but also grammatically correct. The en dash serves a specific purpose that is universally recognized and does not introduce ambiguity, which is why most English-language style guides will call for the en dash to be used in this way. That it can't be found on most keyboards seems to be the only real argument against it, and I find it completely unconvincing. ReneeWrites (talk) 09:25, 7 October 2024 (UTC)[reply]
I agree, especially since it's very common to use Commons:HotCat for categorizing, so the optimal solution is "Title with en dash" and "Category redirect with hyphen". I appreciate that it is somewhat cumbersome to input en dashes, but they are typographically and semantically correct and while HotCat or similar tools are certainly not mandatory, they can easily resolve the issue for those who really care. —Justin (koavf)❤T☮C☺M☯ 09:34, 7 October 2024 (UTC)[reply]
I just wish to point out that I believe typeability is generally a valid concern, so I don't take issue with the basic premise of the discussion. But I only agree to the extent that I'm certain this could have been a real problem. My main objection, however, is that it seems very unlikely that the range dash (or hyphen) will ever be typed. To clarify, the original examples were Category:Hendrik Koolwijk (1800–1885) and Category:Iraqi Army in the Gulf War (1990–1991), which made me wonder: When is anyone ever going to type full category titles like those? And if they were to, when would they actually have to?
If typeability is indeed relevant here, I don't see why it is only considered important when it comes to the dash, while diacritics and language-specific characters derived from the Latin alphabet are preferred. Don't they, more often than not, cause an arguably worse version of same perceived problem?
"Title with en dash" and "Category redirect with hyphen" sounds like good strategy, and hopefully it's also an acceptable compromise. From that point of view, it's actually quite convenient that categories with range hyphens often already exist.
Sinigh (talk) 09:59, 7 October 2024 (UTC)[reply]
I hope this will be accepted as a compromise too. I know Commons isn't Wikipedia and we do our own thing here, but I do find it useful to look at how things are done on Wikipedia when an issue like this crops up (one that's not Commons-specific, I mean) on how they've dealt with it, and "Title with en dash, redirect with hyphen" is the compromise they settled on as well. ReneeWrites (talk) 10:12, 7 October 2024 (UTC)[reply]
If I understand it correctly the short summary of what this is about is whether the - or – character should be used. If there is some decision either way I think this should be in some guidance page where it's also clarified where each character is to be used as well as a bot/script that automatically moves categories accordingly. Additionally, it would be best if not needed that a technical change is implemented that makes HotCat autocompletes with – show up when using the more common minus - character. This is a broad subject and also affects for example Wikipedia lists which sometimes intermingle both. If there is a code issue or proposal about the autocompletes showing up, please link it here. Prototyperspective (talk) 11:57, 7 October 2024 (UTC)[reply]
Agreed on documentation and to be clear, HotCat will correct/autocomplete any category redirect, either those that use standard MediaWiki syntax (i.e. "#redirect[[:Category:Foo]]") or by using {{Catredirect}}. —Justin (koavf)❤T☮C☺M☯ 12:07, 7 October 2024 (UTC)[reply]
To clarify: I meant that it should show the autocomplete without requiring there to be a redirect with the same name but a different hyphen character. E.g. always whenever there is a – between numbers show this cat in the autocompletes even if the user entered a minus - despite of there not being a redirect. Maybe it's not really needed because that character usually comes only near the end of a cat title, this would be needed if sometimes this is near the start of a cat title. Prototyperspective (talk) 12:13, 7 October 2024 (UTC)[reply]
That would still be a brilliant addition, though. Would it even be possible to automatically redirect searches whenever someone (understandably) types a hyphen where the dash goes? I mean, sort of like the way searches aren't case sensitive, could they also not be hyphen/dash sensitive? Only when needed, of course, i.e. if there actually is a category with a dash where the person types a hyphen. Sinigh (talk) 13:34, 7 October 2024 (UTC)[reply]
It is possible, the question is how difficult it would be and what the best way to implement it would be. In any case, it probably needs a code issue for HotCat. Prototyperspective (talk) 14:11, 7 October 2024 (UTC)[reply]
Can we use a character that is found on keyboards without requiring to use the alt key?
 ∞∞ Enhancing999 (talk) 12:51, 7 October 2024 (UTC)[reply]

Uploading photos taken in a commercial establishment

I took these photos of an old Heidelberg printing press at a commercial establishment. Removed any identification of the location, but didn't ask for permission. I want to upload them as PD, but unsure of their copyright status.

— Ineuw talk 06:48, 7 October 2024 (UTC)[reply]

I'm not an expert on this, but my assumption is that it's fine to post these. The focus of these images is the printing press, which isn't copyrighted, and the commercial establishment it's placed in would fall under de minimis as it's barely visible. I would not post the third picture however, and I would crop out the sign at the top of the first. You can use the information on that sign (by paraphrasing or summarizing) but I assume the text itself is copyrighted and can't be copied or posted in full. ReneeWrites (talk) 09:51, 7 October 2024 (UTC)[reply]
Also as a non-expert, maybe you could be concerned that the text in some of these is copyright-able, so you may want to crop that out. Seems like a pretty small concern, but better safe than sorry. Edit conflict-y: I agree with Renee—Justin (koavf)❤T☮C☺M☯ 09:59, 7 October 2024 (UTC)[reply]
There is no need to remove location details. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:43, 7 October 2024 (UTC)[reply]
Indeed. Keep the location details, they are relevant. - Jmabel ! talk 16:51, 7 October 2024 (UTC)[reply]
Thanks for all the comments. I also noticed the first photo with some possible identification. But, I doubt that the establishment would object to the promotion. My concern is acceptability on the Commons. BTW, I already removed a lot of identifying information. As for location details, what does that mean? The 3rd photo with the 1985 date is meaningless. It's when the company folded.— Ineuw talk 12:51, 8 October 2024 (UTC)[reply]
You said "Removed any identification of the location". Don't. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:20, 9 October 2024 (UTC)[reply]

We are talking about two different concerns. Please clarify.— Ineuw talk 17:50, 9 October 2024 (UTC)[reply]

Are we? What concern are you talking about? Do not remove details of the location from your images or their metadata. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:11, 9 October 2024 (UTC)[reply]
Thanks for the much appreciated clarification. In that case, I will let them know.— Ineuw talk 18:43, 9 October 2024 (UTC)[reply]
I am soon uploading the unedited originals, as well as some additional close-ups. Thanks again.— Ineuw talk 00:55, 10 October 2024 (UTC)[reply]

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)[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]
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]
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]

October 08

Exhibition at the M.H. de Young Memorial Museum, 1932

Hi, I am looking for the catalog of the exhibition at the M.H. de Young Memorial Museum, San Francisco, 1932, by the Group f/64, or at least a list of artworks. Any idea? In newspaper reports? This would help finding copyright status for these notable pictures. Thanks, Yann (talk) 14:03, 8 October 2024 (UTC)[reply]

Try asking at en:WP:RX and/ or en:WP:REFDESK/H. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:14, 9 October 2024 (UTC)[reply]
Viriditas has got this information. en:Talk:Group_f/64#Exhibition_catalog. Thanks a lot! Yann (talk) 10:38, 10 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]

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]

October 10

Internet Archive attacked

Hi, I just learned that Internet Archive has been attacked, and suffered a security breach: [1]. :((( We rely a lot on IA for various reasons, and that's very sad. Yann (talk) 10:36, 10 October 2024 (UTC)[reply]

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