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:
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.
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).
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:
SpBotarchives 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:
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]
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]
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]
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. — Rhododendritestalk | 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). — Rhododendritestalk | 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]
We shouldn't be mass changing file titles without a compelling reason. It just generally causes chaos. I think files being factually misleading is a compelling reason, but otherwise, I'm not convinced. Nosferattus (talk) 16:57, 15 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]
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 ! talk19: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]
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]
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]
I believe that ALL substantially manipulated or fabricated images, that might be misunderstood as "real", should be very clearly marked. It shouldn't depend only on whether someone decides or rules that the fabrication method was "AI". ITookSomePhotos (talk) 21:37, 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]
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]
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.jpgAdam 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]
The examples people have brought up in support or as examples in this discussion include "AI generated", not just AI. Edit: Except for Alexpl's comment. ReneeWrites (talk) 14:22, 13 September 2024 (UTC)[reply]
Support When images are used internally editors know to check the filepage, when outside people reuse the images they are usually not aware of the info on the files page. We have had people reusing images without complying to the terms of the license by naming the creator. I would like to see (AI generated) the way we use "(cropped)" in file names. --RAN (talk) 18:06, 13 September 2024 (UTC)[reply]
Ooh, that's a good point - if a user saves an image from Commons (or another wiki) to their computer, for instance, there's a decent chance that its file name will remain intact as a warning. A template on the file's talk page certainly won't. Omphalographer (talk) 18:13, 13 September 2024 (UTC)[reply]
Strong oppose no no no, file names shouldn't be used for that. This opens up Pandora's box for controversial subjects. This should be in the file description, not in the name. Multichill (talk) 12:53, 15 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.
Comment I generally think templates and/or structured data are a better way to do this, and more multilingual-friendly. But I'm not opposed to also requiring it in file names if the community agrees on that (and I will anyway include in the filename of any AI files I upload myself). Noting that I have made a related proposal below: #Proposal: de-prioritise AI images in searchthe wub"?!"15:09, 19 September 2024 (UTC)[reply]
Support this would prevent problems with AI images being mistaken for real ones, and I really don’t see how this could potentially be harmful. Dronebogus (talk) 11:13, 24 September 2024 (UTC)[reply]
I'm sensing pretty widespread support, so let's plan out what would need changed:
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.
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.
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)
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."
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]
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]
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]
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 Gnangarra01:06, 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]
@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]
@Trade: The problem with {{PD-algorithm}} is that it's also used on images that have been modified by AI, not generated that way. Really there should be two separate templates depending on if the image is AI generated or just modified by AI. {{PD-algorithm}} doesn't really make sense in the later instance anyway. --Adamant1 (talk) 18:25, 2 October 2024 (UTC)[reply]
However it should be possible to de-prioritise such images by adding Template:PD-algorithm (which all AI generated images are supposed to be tagged with) to MediaWiki:Cirrussearch-boost-templates. I would suggest a ranking of 50%, which would rank AI files below most other files, but above those nominated for deletion or otherwise tagged as low quality/superseded.
Example of a search for "animal" (cluttered with many old book scans crowding out already badly prioritized images)
Strong oppose Images made using some AI tools should either not be deboosted or only files in Category:AI misgeneration should be sorted to be further down in general: images shouldn't be sorted by how or by which techniques and tools they were produced but 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. Additionally, this functionality only incentivizes people to hide the fact they used AI to make an image which we should encourage people to specify. There are many cases where AI images are some of the best for the concept searched for and they should be shown fairly high up in such cases, especially when they're in use. The example search results look like that because nearly all images for a useful Wikibook used rhino images. They indeed should not show high up there (for this search term) but that doesn't mean all AI images should be downranked in general. Some other improvements to the search results should be made that are not specific to AI...for example only showing used images high up if they are used on Wimedia items (like Wikipedia articles) that are actually related to the search term. I will attach a screenshot that shows how bad the search results often are, this is a general issue and lots of other media crowd out useful media. Some other issues include that it often shows very outdated charts at the top when there are more up-to-date charts. This is just some discrimination of the use of a novel tool to produce often high-quality useful images but not a reasonable effective measure to actually improve the search results. Prototyperspective (talk) 15:06, 19 September 2024 (UTC) Added screenshot --Prototyperspective (talk) 15:27, 19 September 2024 (UTC)[reply]
" or only files in Category:AI misgeneration should be sorted to be further down in general" I added that a whole month ago already Trade (talk) 18:25, 20 September 2024 (UTC)[reply]
Instead we could have a filter that excludes AI images. Moreover, these aren't a problem here the example given is one of very very few cases where the results are indeed cluttered by AI images. Third, again the tools and techniques used for producing an image is not the important part...rather whether it's high-quality, useful and relevant to the search term. I don't see this problem on Image search engines but I also don't know what (and how) you searched for. What's next – downranking images made or edited with Photoshop or Krita?Prototyperspective (talk) 11:00, 20 September 2024 (UTC)[reply]
Neutral I'm not sure this is the answer to dealing with the problems caused by AI images. I think another proposal for putting "AI generated" in file names of AI generated artwork would be a better solution. Since it's not so much where the images show up in search results, but that people often don't know the images are AI generated to begin with. People can still accidently get an AI generated image if they are pushed down in the search results. What we need is better ways to clearly identify and deal with AI generated artwork to begin with. I feel like it's mostly a curation issue at this point though. --Adamant1 (talk) 00:32, 20 September 2024 (UTC)[reply]
Why discriminate against the use of one particular tool? I don't see any rationale there only that you apparently want to continue to subjectively semi-censor images made with a tool you apparently don't like. Prototyperspective (talk) 11:02, 20 September 2024 (UTC)[reply]
AI generated artwork isn't a tool, its a specific type of art. Stop trying to act like we're just discussing Microsoft Paint every time this comes up. Its getting rather tendentious. --Adamant1 (talk) 11:08, 20 September 2024 (UTC)[reply]
It's the AI tool. One can use the result and edit it in Krita/Photoshop or create a draft and use an AI tool to improve it via img2img. AI-generated art is a type of art that makes use of these tools, similar to photography by definition makes use of cameras or paintings characteristically make use of paintbrushes. The level of involvement of the human is often far lower than in manual paintings. I doubt people voting here have much experience with prompting around for a few hours to get an image to look nearly exactly like you want it to or seen cases where AI images are the most illustrative. Stop trying to act like it's not discrimination against one particular novel tool (or art-technique/artform). Prototyperspective (talk) 11:18, 20 September 2024 (UTC)[reply]
Don't get me wrong, I'm not acting like it isn't singling out a specific type of art. It has to be due to the nature of the thing. "Artwork" isn't the problem here. AI generated artwork is. You know as well as do that no one is uploading personal drawings of cells made in Photoshop and trying to pass them off as actual images. Let alone that anyone will be fooled by said images like they clearly are for AI generated artwork. Your just being disingenuous and choosing to ignore the issue instead of admiting that AI artwork has its own problems that inherently don't exist with other artforms. --Adamant1 (talk) 11:31, 20 September 2024 (UTC)[reply]
drawings of cells made in Photoshop and trying to pass them off as actual images Delete these. There is an ongoing proposal about requiring their file titles to specify they are AI-generated and that seems like not a bad idea. There also are templates and categories by which people can see that the file is AI made even if that's not in the file description where this info should be and usually is. You didn't address the points made but if that helps: yes AI artwork have their own problems and I never said otherwise. One could even think about downranking AI images for search terms where the user likely looks for actual depictions and not artwork. For example, when searching for "animals" all art media and AI-generated media could be downranked and images featured in WP articles broadly about animals like such as the collage images upranked. Prototyperspective (talk) 11:53, 21 September 2024 (UTC)[reply]
Comment I'm not sure if nobody else has noticed this or people have noticed but simply haven't commented, but the vast majority of the Javan rhinoceroses generated by the AI prompts aren't Javan rhinoceroses, but black or white rhinoceroses. ReneeWrites (talk) 08:38, 21 September 2024 (UTC)[reply]
The search results for that are also littered with AI generated images (Rhinoceros sondaicus). And search takes multiple things into account (descriptions, file names, metadata) so searching for both should yield similar results. One is not more correct than the other. ReneeWrites (talk) 10:50, 21 September 2024 (UTC)[reply]
Doesn't that just illustrate a quirk of MediaSearch that displays images not categorized as "Rhinoceros sondaicus" also ? Compare with Special:Search linked above.
In general, we might be blaming "AI" for defects of our search engine due to our naming conventions for categories and files about "Javan rhinoceroses". The correct approach would be to fix the search engine for the general issue. ∞∞ Enhancing999 (talk) 11:06, 21 September 2024 (UTC)[reply]
They are categorized as rhinoceros sondaicus, specifically Category:Rhinoceros sondaicus in art. Thinking on this a bit more, I don't think de-prioritizing search results would fix the issue at hand. These are simply not images of Javan rhinoceroses, even if the prompt called for those to be generated. ReneeWrites (talk) 16:38, 21 September 2024 (UTC)[reply]
Comment Also please consider all the unintended consequences like if a logo of some project or tool was made using AI (as is the case for several Wikimedia projects) it wouldn't be shown at the top when searching for the project name even if it's the actual logo (and this was just one example). Also before considering this please consider that artistic and illustration workflows are involving to substantially incorporate AI-generation and we'd be indiscriminately semi-censoring lots of media (that at times is quite high-quality or relevant to whatever the user searched for) – so please see this example workflow video of an AI tool integrated into Photoshop. I think it should probably be required watching especially for people who don't have a lot of experience with using these tools and and in their personal experience didn't come across many media created using them that could be useful. Prototyperspective (talk) 12:12, 21 September 2024 (UTC)[reply]
Why don't you and Jeff include any explanation and don't address any of the points raised? What about the issue of it hiding the logos of projects etc when searching for these? Why are you suddenly in favor of indiscriminate (semi) censorship – I'd like to understand and think decisions should be based on sound well-thought through rationales. Prototyperspective (talk) 22:09, 21 September 2024 (UTC)[reply]
If some illustration uses some AI images because there are no good free ones it would get censored. If people make media in relation to politics we'd be be doing political (semi) censorship like China seems to do it – it's a big social problem if a large proportion of diverse media on all sorts of things is suddenly indiscriminately semicensored here or anywhere else. I doubt you have seen the video I linked and neither replying nor providing any rationale or addressing any points shows how this is about ignorance, not anything thought through and possibly some emotional knee-jerk reaction because voters simply don't like the use of AI tools for whatever personal reasons. I think Wikimedia projects are generally oriented towards rationality and reason, not subjective opinion vote counts. The AI images people have uploaded here so far are below average but that may change and there's many cases where these are very relevant for various search terms.
@Borvan53: you used an AI tool to create what seems to be the first and high-quality image of a palantir which is a trope of fantasy fiction and used in several Wikipedia articles – what do you think about this proposed policy that would hide your image from the search results even when searching for "palantir"? @TatjanaClimate and S. Perquin: @Milena Milenkovic (VMRS), Fuzheado, and JPxG: you created some logos using AI tools, what do you think of this proposal that would hide in the search results such when searching for the name of the project/… for which the logo is used or related search terms? @Raresvent: An AI image of your prompting is a quite good illustration of post-apocalyptic art, what do you think of moving it far down in the search results for that search term? Prototyperspective (talk) 23:33, 22 September 2024 (UTC)[reply]
Oppose There is already the template {{PD-algorithm}}. It is mandatory. AI images will be more and more common, and our thinking must be focused about their quality. Should I mention that I worked a couple of hour to generate the image of the Palantir ? First trials gave everything but a Palantir. Borvan53 (talk) 06:51, 23 September 2024 (UTC)[reply]
I was not saying you need one, just asking for one. Moreover, the linked policy suggests when discussing proposals people if possible shouldn't just leave a vote to be counted but also e.g. address points raised.
@Adamant1: , I am allowed to ask relevant people to participate in relevant discussions and lots of people did this elsewhere on WMC. I think comments that do not address any critical points & questions and have no rationale should be ignored, you think people affected by this proposal should be ignored so we disagree on that. Most contributors do not check VP here, which is frequented by a very small fraction of users, but also most users probably don't want AI images to be semi-censored or would like to have policy-discussions to be based on sound reasoning. These users may provide some further insights and I made transparent how they are related to it. If that wasn't okay then where is a policy that prohibits doing so and why can other users do this over and over in other discussions without any issues? Prototyperspective (talk) 08:53, 23 September 2024 (UTC)[reply]
Sure, Perspective. There's a difference between that and pinging specific people who you know will take your position because they have uploaded AI generated artwork before though. Otherwise I could give a crap, but if your ping people who are clearly going to have a particular position about it then 100% your just canvasing at that point. Especially since you did it half way through the discussion and when there was more support for it then not. So it's pretty obvious that's what you were doing. --Adamant1 (talk) 08:59, 23 September 2024 (UTC)[reply]
Again, I never seen any policy that prohibits that which may be because Wikimedia was originally meant to have discussions based on reasons rather than votecounts but if one such exists please link it and if not you could propose one. Secondly, again many other users including admins did the same in other discussions such as DRs and they didn't transparently show how these users relate to the subject which is my third point: I made this transparent so everyone can contextualize their comments, explanations, and votes. Affected good-faith long-standing users are I think certainly users that should be involved in proposal discussions and we may disagree on that. I also think in politics that people who are affected by policy decisions should have a say and we may disagree on that as well. Fifth, you and others could also invite users but I think the small number of users who frequent this VP board have much of an overlap with the strongest opponents of AI tools in media production. It may indeed be a problem if I did that early in the discussion rather later one or without making their relation to the subject transparent. Prototyperspective (talk) 09:36, 23 September 2024 (UTC)[reply]
Comment Take the example of the project of biological expertise/palaeontology that takes bones of early humans or dinosaurs and tries to add muscles, tendons and hair to figure out what the actual human/animal looked like. Are the results in the category of AI generated images? - R. J. Mathar (talk) 19:05, 22 September 2024 (UTC)[reply]
I don't know if deprioritizing them across all searches the best way to do this, but I think there absolutely has to be some way to choose to exclude them from a search. JPxG (talk) 23:47, 22 September 2024 (UTC)[reply]
A filter for AI images is a separate proposalA filter the user can enable to exclude AI media is a separate idea and was proposed by the same user elsewhere. I think I would support that as well and it's one reason why I put so much effort into categorizing AI images into the AI-generated media subcats which should now contain virtually all of these. Prototyperspective (talk) 23:52, 22 September 2024 (UTC)[reply]
Oppose I don’t particularly care for AI art; but AI art is not overwhelming Commons by a long shot. Often times AI is used for illustrating fanciful concepts, where it is not inherently better or worse than human art. And it’s highly unlikely to get ranked highly among depictions of mundane subjects that likely have featured, valued, or good images. So this, to me, reads like “AI is bad but we can’t ban it (at least not yet) so let’s quietly suppress it”. It feels kind of sneaky and manipulative, like Generic Big Tech Inc. manipulating what users see for generic sinister purposes. Dronebogus (talk) 12:16, 24 September 2024 (UTC)[reply]
I noticed recently that there's a special icon that can be added to valued images when their being used in galleries. It wouldn't help with this particular issues per se, but maybe having a little icon in the corner of every image that is AI generated so people will at least know that's what their looking at would help. It should be that hard to implement either. Although I suspect people could and would make the same arguments against something like that they normally do. But whatever. There should be something to indicate an image was generated by AI. The trick is to make it as inconspicuous as possible while still making it clear enough that people will notice it. --Adamant1 (talk) 12:23, 24 September 2024 (UTC)[reply]
Do we accept category pages which end with text like "Should you choose to perform actions before asking questions, your chances of getting detailed and polite answers will not be high."?
Regarding the 1st question: IMO they don't. The page should be modified or rewritten w/o personal attacks like "vandals", or be deleted (surely they can then recreate it on Russian WV, where there are no guidelines). --A.Savin21:49, 21 September 2024 (UTC)[reply]
I'd just delete both. About the page, the whole idea that someone should notify them before nominating an image of a monument for deletion is just laughable on it's face. The same goes for most of the other content on there. With the template, it seems to add a warning to everything it's added to saying "this template and pages using it are maintained by the Russian WLM team. Please read the guidelines before making any changes that can affect the monuments database!" Which is at least overly confrontational, if not totally pointless. It appears that their whole numbering system for "cultural heritage monuments" is a personal thing created by the Russian WLM team to. So I don't think it should be associated with the categories, images, or anything else on Commons. Especially if it's just going to be used as a way for Russian users to control things related to Russia on here. --Adamant1 (talk) 05:38, 22 September 2024 (UTC)[reply]
Well, this is the only database for Russian monuments. Nothing else exists at this level. Deleting the template would mean either (i) a lot of uploads of files without categories which nobody would notice; or (ii) we just stop WLM, which is the only source of files for Commons for most of these monuments. In the ideal world, the users would categorize the files properly, or it would be freedom of panorama for monuments in Russia, or Russia would become a civilized country and remove all these monuments to Lenin etc from the protection lists, but none of this is likely to happen in our lifetime. Ymblanter (talk) 06:27, 22 September 2024 (UTC)[reply]
@Ymblanter: The Russian cultural heritage register has their own numbering system that has nothing do with the one from WLM Russia and there's already a property for it on Wikidata, P5381. So the database on WLM Russia's end serves no meaningful purposes what-so-ever outside of allowing them to control things related to Russian monuments. Regardless, there's no reason why they can't just drop the pointless intermediate numbering system and go with the exiting, official one from the Russian cultural heritage register. There's certainly nothing requiring them to use their own personal numbering system for monuments though and I'd argue it goes against the guidelines anyway. --Adamant1 (talk) 06:35, 22 September 2024 (UTC)[reply]
I am sorry but you do not know what you are talking about. The Russian cultural heritage register is so incomplete that it is almost useless. 90% of the monuments would have no number if we go with the official register. Ymblanter (talk) 06:47, 22 September 2024 (UTC)[reply]
Where did I say they were exact copies of each other or that the official list was as extensive as the one from WLM Russia? I could create my own numbering system for something right now that would include more things then an official list. That's besides the point though and has nothing to do with the merits of letting me use my own system on here. At the end of the day this is a media repository. That's it. It's not a database of monuments. Wikidata and Wikipedia exists for that purpose.
I'm not even saying they should get rid of the database. I'm just saying the template and the fact that they are using as a way to control things is inappropriate, totally pointless, and goes against the guidelines. I could give a crap if us not allowing for it causes them to take their ball and go home. That's not on us. They can always create a Wikidata property for it and add the information through infoboxes if the system is that useful. But it's totally pointless to have the numbering system as a template that gets added to specific categories. Things like that are exactly what Wikidata and infoboxes exist for. A lot of the monuments need to be documented better on Wikidata anyway. This is a perfect opportunity. --Adamant1 (talk) 07:04, 22 September 2024 (UTC)[reply]
I think turning the numbering system into a Wikidata property that can be added to infoboxes instead doing it through a template that's added to categories is perfectly clear. Your just being insincere about it. --Adamant1 (talk) 07:16, 22 September 2024 (UTC)[reply]
I uploaded this photographs, and it very hard to complain all unwritten rules for descript a cultural heritage. There is both category for building, category for code of building, some photographs lay in both categories, some in one of them. Then suddenly i learned that category for number - is not category, is looks like category, but not category, and i was not able to put it into subcategory. Later i found that i should manualy add name of newly created category of building in wikivoyage table, even table has wikidata id for building, and wikidata has commons category entered, it is not enough.
I am overwhelmed, and do not undersnand, how i should descripts photos. Why
I have rewritten the page in the light of the above discussion. However, I note that it includes a numbered bullet point, saying:
Categories by ID are automatically added by our templates and adopt simple names Category:WLM/ID and Category:WLE/ID for cultural heritage and natural sites, respectively. These categories are not created as pages, but added to all WLM/WLE images, which is sufficient for generating galleries of images with a given monument ID. Example here. Such galleries are linked from our lists of natural sites and cultural heritage under the name "галерея". These numbered categories are vital for sorting images and finding images with a given ID. If you are unhappy about red links generated by these categories, propose a better way of finding an image based on monument ID.
Unfortunately, this recipe is not implemented via the MediaWiki API, so the result will not be machine-readable. Destroying the WLM/xxx categories will break several tools on Toolforge and possibly some external applications. Olksolo (talk) 15:31, 23 September 2024 (UTC)[reply]
It is reasonable to allow some time for transition, so that such tools can be modified, before the categories are deleted. It would not be reasonable to use those to insist that the categories cannot be deleted or redirected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits16:16, 23 September 2024 (UTC)[reply]
@Olksolo: I think the difference there is that the categories contain sub-categories for the ships and aircraft. Like if I go to Category:IMO 1000021 it contains Category:Montkaj (ship, 1995). Which is how it should be. The same can't be said here though. If you go to Category:WLM/2500622000 it just contains images that are also in Category:Pogranichnaya Street 2, Vladivostok. Which isn't how it should be. Also, what qualifies as a "cultural heritage monument" in Russia seems to be completely arbitrary and based on the personal opinions of WLM Russia members. Whereas IMO numbers are officially recognized and used by the International Maritime Organization among other organizations. Any number system we use on here should at least be semi-official and agreed on outside of small group of users though. I don't think we should allow for any user created numbering or categorization systems regardless of if it's by WLM Russia or anyone else. --Adamant1 (talk) 16:11, 23 September 2024 (UTC)[reply]
But you are mistaken.10-digit numbers of cultural heritage sites were officially used from 2004 to at least 2011. The "cultural heritage site passports" available in online sources often use 10-digit numbers (not the modern 15-digit ones).For example, look at the cultural heritage site passport on the website of the Ministry of Culture of the Russian Federation: [1] (documents from the Russian ministry may not be available if you are not in Russia, then a copy is [2]). At the very top of the page is not the modern 15-digit number, but the 10-digit one — 0300000170.For objects managed by the WLM Russia team, there are official documents on the cultural heritage status. Olksolo (talk) 16:37, 23 September 2024 (UTC)[reply]
I thought Ymblanter had said that the list from WLMs has more items in it then the official government one. If that's the case then they came up with the designation at least for the monuments that don't have official numbers associated with them. --Adamant1 (talk) 16:47, 23 September 2024 (UTC)[reply]
The problem is that not all cultural heritage sites with cultural heritage status are included in the official register. This work has been carried out by the ministry for several years with varying success. The peculiarity of bureaucracy in Russia is that this work will never be completed. But somehow it is necessary to identify cultural heritage sites with official status that are not included in the official register. WLM Russia Team has expanded the old 10-digit numbering scheme to identify such objects. Of the 223,374 cultural heritage sites supported by WLM Russia Team, approximately 45,000 are an extension of the old numbering. Olksolo (talk) 17:24, 23 September 2024 (UTC)[reply]
In an ideal world, when each cultural heritage site would have its own Wikidata Entity, this might be true. But now, out of more than 200,000 Russian cultural heritage sites, only about 70,000 have a Wikidata Entity. And the question of whether a Wikidata Entity should be created for all of these cultural heritage sites is still open. Olksolo (talk) 17:34, 23 September 2024 (UTC)[reply]
Any of them that have categories on Commons can and probably should have Wikidata items. If for no other reason then to track the artists and copyrights. --Adamant1 (talk) 17:48, 23 September 2024 (UTC)[reply]
There is a further issue. We have, for example a category Category:WLM/1010021052; note the Wiki Loves Monuments ID (P2186) used on Wikidata is RU-1010021052
(note the "RU-" prefix). Not only does this make them harder to match, but implies that there may be a "1010021052" monument in other countries' lists; so the Commons name is not guaranteed to be uniquely identifying.
And, if a Wikidata item is not found, or the Wikidata item is not linked to a category, or the Wikidata item is linked to a "WLM/1010021052" style category, write to a log file.
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.)
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)?
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]
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]
@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]
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]
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]
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]
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]
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."
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]
September 29
Why?
I want to upload a file, but I can't. It's saying that February 2, 2024 (content creation date) does not match the license (I read somewhere this is in the public domain in US). But the website (This one) is in US and was published on February 2 2024 (the article in the link). That doesn't make sense! — Preceding unsigned comment added by Susbush (talk • contribs) 14:09, 29 September 2024 (UTC)[reply]
Content which was published eight months ago is not in the public domain in the US (or anywhere) unless the author has explicitly placed it in the public domain. I see no indication that this would be the case for the images or text on the rss.com web page you linked. Omphalographer (talk) 20:27, 29 September 2024 (UTC)[reply]
September 30
Image not displaying at correct resolution?
I re-uploaded a better version of this image as the previous one was tiny and very low res:
It seems to have uploaded OK, but when I view it in the Media Viewer, or from one of the pages it's linked to, it seems to display the old image. Is that just me? Thanks for any help! --Gilgongo (talk) 18:05, 30 September 2024 (UTC)[reply]
did you try com:purge and clear your browsers' cache or change a browser?
Thanks - I didn't know about com:purge. That seems to have fixed it I think. And yes, I'll look at trying to make an SVG, although right now I've no idea how to. Gilgongo (talk) 21:36, 30 September 2024 (UTC)[reply]
This is clearly far from the Paris-Gare de Lyon. When I check for the first road crossing the rails overhead is Boulevard Poniatovsky see: permalink. And I see no other roadcrossing beyond this point (I checked up to Villeneuve Saint-Georges). Unless the photographer used a drone I am stumped.Smiley.toerist (talk) 20:29, 30 September 2024 (UTC)[reply]
Sorry, I did not notice the location. And the openrailwaymap is a bit misleading as it suggest that the road is underneath. However, this is an very busy urban motorway, where it is not posible to stop. Maybe the traffic was at a standstil.Smiley.toerist (talk) 20:42, 30 September 2024 (UTC)[reply]
The green building. This is the dépôt des TGV porte de Charenton, the bridge is the Bd Poniatowski, Boulevards des Poniatowski. map link, 48.830034083169316, 2.397604208926646. Your train is between the Boulevards des Marechaux, and the Boulevards Peripherique.
In September 2024, 1 sysop and 1 bureaucrat were elected; 5 sysops and 1 oversighter were removed. Currently, there are 179 sysops, 7 bureaucrats and 3 oversighters.
Very slow, about 1 edit per second. Up until recently and since “forever” it was lightning fast, able to edit all 200 files in a cat page in a couple seconds. To whom or what should we thank for this improvment, and what reasons were given for that thankfulness? -- Tuválkin✉✇00:48, 2 October 2024 (UTC)[reply]
I was wondering why it's been slow lately. Totally handicapping it just because the site crashed once seems a little ridiculous though. --Adamant1 (talk) 05:03, 2 October 2024 (UTC)[reply]
According to a comment from a WMF worker it brought the site down more than ten times and was causing problems consistently. A comment from a different volunteer pointed out it brought down all Wikis for 10-30 minutes at a time. The current state of Cat-a-lot is the result of an emergency fix, but whatever improved version takes it place will have to abide by the API guidelines that it previously ignored. ReneeWrites (talk) 09:40, 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]
"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 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]
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]
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.
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.DarwinAhoy!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.--DarwinAhoy!14:36, 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]
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. DarwinAhoy!15:53, 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. 🙄 DarwinAhoy!17:12, 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 ! talk09:42, 7 October 2024 (UTC)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 17:56, 6 October 2024 (UTC)
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 ! talk06: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.
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]
Uploading photos taken in a commercial establishment
I taken 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.
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]
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)
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)
.svg/15px-Pictogram_voting_comment_(orange).svg.png)
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)
Strong oppose no no no, file names shouldn't be used for that. This opens up Pandora's box for controversial subjects. This should be in the file description, not in the name. Multichill (talk) 12:53, 15 September 2024 (UTC)
Neutral I'm not sure this is the answer to dealing with the problems caused by AI images. I think another proposal for putting "AI generated" in file names of AI generated artwork would be a better solution. Since it's not so much where the images show up in search results, but that people often don't know the images are AI generated to begin with. People can still accidently get an AI generated image if they are pushed down in the search results. What we need is better ways to clearly identify and deal with AI generated artwork to begin with. I feel like it's mostly a curation issue at this point though. --Adamant1 (talk) 00:32, 20 September 2024 (UTC)
.jpg)
.jpg)
.jpg){kind=link}
This section is resolved and can be archived. If you disagree, replace this template with your comment. Prototyperspective (talk) 17:56, 6 October 2024 (UTC)