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]
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]
@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]
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 06
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]
Fun fact: the infobox is designed in such a way that it can be replaced by a new system when that becomes necessary - e.g., if infoboxes could be built into MediaWiki, or we migrate away from the category structure, since it's just a way of displaying the relevant information from Wikidata. With this issue, it's been great to see the discussion here, it seems no change is needed for now. Thanks. Mike Peel (talk) 22:15, 12 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]
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]
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]
Thats the best solution, the hyphen. Juts because Wikipedia has a preference for en dash) does not need to apply to us. I keep on saying we're a databank, names of cats should be as simple as possible and contain easily available on the keyboard. No need for affectations. Broichmore (talk) 12:40, 12 October 2024 (UTC)[reply]
Wikipedia's preference is not and has never been the main argument here; ReneeWrites only told us how they solved it over there and pointed out that "we do our own thing here." As for the keyboard layout, everyone already knows that the hyphen is easier to type. That argument has been addressed in several ways, yet noone seems to have anything to say in response to those objections. Simply reiterating the original argument obviously isn't going to convince anyone. Sinigh (talk) 13:06, 12 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.
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]
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 talk12:51, 8 October 2024 (UTC)[reply]
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.
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 ! talk20:51, 9 October 2024 (UTC)[reply]
Alright the question is simply which other format would be better and why? Currently this is only one link and doesn't even other data for other columns and people often dislike things at first they are not familiar with. Prototyperspective (talk) 21:48, 9 October 2024 (UTC)[reply]
If a list format would be better the page would be very large and I don't know if it causes other problems but one would have to scroll a lot. Without alphabetic sorting, a list format makes less sense. But I guess once the new version is sorted it could be easier to skim or skip over similarly named items if it was in a list format. Maybe there could be multiple columns so the page isn't so large. Prototyperspective (talk) 21:58, 9 October 2024 (UTC)[reply]
A wiki table (with one row for each category) would be easiest to work with. Even if the report itself isn't sorted, presenting it as a table will allow users to sort it themselves. Omphalographer (talk) 22:16, 9 October 2024 (UTC)[reply]
The report has been updated now. It has the same sorting as before (no ORDER BY SQL added) but now has a table format so it can be sorted alphabetically by clicking on the column header. Moreover, empty categories have been split off from the report. Prototyperspective (talk) 12:45, 12 October 2024 (UTC)[reply]
Pretty hard to figure out any kind of pattern in that list. Maybe a simple word count helps. I used that when the "uncategorized" reports were longer. It allows to fix several similar ones at once. Sample wordcount (some "words" are years or other numbers): from 7899, Fire 7879, Sanborn 7877, Insurance 7877, Map 7876, County 7525, in 1170, North 829, Oklahoma 681, Texas 572, Rhine-Westphalia 546, California 546, New 537, Pennsylvania 513, Washington 492, Missouri 464, of 382, 1911 356, 1909 346, Carolina 332, 1912 328, 1910 324, Ohio 317, Jersey 317, Montana 296, 1914 287, 1913 282, Oregon 281, Indiana 272, Kansas 271, 1921 266, 1908 256, 1915 255, 1920 245, 1916 245, 1922 242, Georgia 241, 1905 235, Florida 232, Virginia 222, Maine 219, City 218, by 212, South 207, 1904 203, 1917 194, 1901 190, 1900 180, Massachusetts 178, West 176, 1919 175. ∞∞ Enhancing999 (talk) 23:46, 7 October 2024 (UTC)[reply]
Thanks. At the next update it will be sorted alphabetically, maybe that helps. I noticed most of the Rhine-Westphalia cats do have categories but they have been set by a template by the first and only edit by XrayBot and I don't know how to best make such categories disappear from the report – one example for that would be to have a query show all cats included there that have a template set (which usually sets cats) so all of them could get a nulledit to remove all which do have a category from the report (that's just an example, I don't think that's readily possible). Prototyperspective (talk) 09:23, 8 October 2024 (UTC)[reply]
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.
@Adamant1: I spent like two weeks or so writing code for this. I don't really need anyone to do anything, except give me mass rename privilege for a selected number of files.
Isn't there a way to override borderline imbecile snowflakes, who have the power to vote, with the help of specially trained overlords who act in the interest of progress being made? Nowakki (talk) 12:30, 10 October 2024 (UTC)[reply]
I think people who refused the privilege back then were using about as many brain cells as you just did when you imagined you knew how to be of help. Nowakki (talk) 13:35, 10 October 2024 (UTC)[reply]
You're quite condescending, even more than Adamant1 here once again. I prefer you do not upload these files versus uploading them the way you did. Apply again with the info why you need these permissions. Prototyperspective (talk) 13:45, 10 October 2024 (UTC)[reply]
Yeah well, I find your attitude towards Nowakki rather patronizing myself. I don't think it really helps to go off about how they shouldn't have uploaded the files to begin with at this point. Different strokes for different folks I guess. I'm sure your the one who's in the right here though just because your acting more agitated about it then I am.
More on topic, the files have already been uploaded. So the question is what to do about it now. I'm a little fuzzy on the original details, but assuming this mainly (or only) has to do with uncategorized categories then I don't see what renaming the files would have to do with it. Someone could use User:Nowakki/test3 as a starting point to create the categories through a bot edit. Then the file names could hopefully be fixed in the future, but that's tangential to creating the categories. Or I assume it is. Someone can correct me if I'm wrong on that though. --Adamant1 (talk) 22:09, 10 October 2024 (UTC)[reply]
I'm not agitated at all and nowhere was I acting patronizingly or condescendingly towards Nowakki. I don't really care about this case at all. A user asked about it and I looked at the history page and pinged the respective user, then Nowakki said there's problems with renaming without any further details and I helpfully mentioned this can be done by requesting file-moving rights, that's all. Yes, the question is what to do about the files & cats now. The answer to your question of what file naming has to do it is that Nowakki wrote […] except give me mass rename privilege for a selected number of files. Prototyperspective (talk) 22:24, 10 October 2024 (UTC)[reply]
I think you were. We'll have to disagree though. But that's not all you said. You seem to have a real problem with being patronizing towards other users and then trying to weasel out of it by acting like everything you said was totally innocent and on topic when it wasn't. Regardless, I think the best way to deal with this is by doing a bot edit based on User:Nowakki/test3. But I have other things to do myself. So someone else is going to have to do it, but that would be my suggestion. I see you asked Nowakki to create a bot request. So at least we're in agreement about it. --Adamant1 (talk) 22:56, 10 October 2024 (UTC)[reply]
@Nowakki: Creating the categories is easy. Just got to find somebody to devise a scheme and write a bot. Could you please create a Bot work request with the details? and if you don't really need anyone to do anything, except give me mass rename privilege for a selected number of files could you please request these permissions? Thanks for your efforts so far. Prototyperspective (talk) 22:45, 10 October 2024 (UTC)[reply]
The Sanborn map collection needs to be fixed properly. If you fix the categories you are hiding an indicator that it is broken, which will make the real problem worse. I would therefore advise you to not touch it and move on.
You can copy+paste the above to where to redlink cats problem is being discussed, so they know that a fix is nontrivial and it will be fixed together with the underlying problem eventually. Nowakki (talk) 23:19, 10 October 2024 (UTC)[reply]
What about just up-merging the files to more general ones and deleting the categories their currently in outright then? Or conversely the files could just be mass nominated for deletion. That sounds like a less then optimal solution though lol. --Adamant1 (talk) 23:26, 10 October 2024 (UTC)[reply]
If you delete them now they might have to be downloaded again when somebody wants them. Therefore that should be not an option.
I'm a little hazy on the details, but from what I remember your proposal to rename the files was rejected. So that's clearly not an option. I don't think just leaving the categories as is really helps either. So what's your suggestion to deal with the issue aside from leaving the red links or renaming the files when that already failed? --Adamant1 (talk) 23:46, 10 October 2024 (UTC)[reply]
I only state my original proposition. You can proceed in any way you see fit. I would advise you to develop a scheme that make the sanborn map collection awesome and then implement it. Nowakki (talk) 23:50, 10 October 2024 (UTC)[reply]
The above discussion has gotten terribly convoluted. If there are things that one or more of the participants wish to see happen, could you please each state those, without a bunch of cross-talk? - Jmabel ! talk07:45, 11 October 2024 (UTC)[reply]
I think this short comment sums it up. I do not understand Nowakki's reply to it. It's unclear what is meant with needs to be fixed properly. And it's also unclear what is meant with I would advise you to develop a scheme that […]. If somebody understands what exactly needs to be done or is proposed please explain it briefly and if not I repeat my question for Nowakki to create a request with the explanation/details. Prototyperspective (talk) 09:37, 11 October 2024 (UTC)[reply]
You are right, the underlying issue has never been properly explained to you.
The filenames for map files prior to 1900 are bad. They were chosen by a not so brilliant coworker who came ahead of me.
The map files after 1900 have a better naming scheme.
If you think this is a cosmetic change, click on one of the files named "ind". The plate number and LOC sequential IDs don't match for the old scheme. It's broken. Suppose you were to run the index through OCR. With the old scheme, you need a separate database to map plate numbers to files. Unsustainable stupidity.
Alright, thanks for explaining! That was the missing info. If you requested file-mover permissions and it was declined that doesn't mean you can't apply again. I think it the permissions will be granted if you provide them with this info. If not, you could also check what else is required to get these permissions but I don't see why the request would fail so please request the file-moving permissions, afterwards you could make use of the mass rename tool and implement the filetitle changes. Prototyperspective (talk) 15:40, 11 October 2024 (UTC)[reply]
If I wanted file mover privileges I could have requested them at any time since January. I just came here to talk about stupidity. Nowakki (talk) 17:06, 11 October 2024 (UTC)[reply]
Agree. Not sure what the user is up to now when writing sth like that. What about throwing all of these Sanborn cats into a flat category (for now)? Also maybe they should be separated from the report (if they are in a flat category they wouldn't show up in it anymore anyway). Prototyperspective (talk) 12:42, 12 October 2024 (UTC)[reply]
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]
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
Interesting. I suggest you create a video demonstrating its features and put it on YouTube and also upload it here. Please enable users to add one or several categories with autocomplete similar to the Upload Wizard on this site (maybe the HotCat script could be used for that). Prototyperspective (talk) 16:21, 9 October 2024 (UTC)[reply]
I would recommend rewriting Public photography is forbidden in this country. to Public photography is restricted in this country. as all but five countries with freedom of panorama provisions grant permission for some works but not others. For example, the United States has freedom of panorama for architecture but not sculpture. JohnCWiesenthal (talk) 19:20, 9 October 2024 (UTC)[reply]
Looks very interesting and promising! Thank you for the work! It would be a nice addition if login and upload with Wikimedia account would be possible. That would also relieve you from the responsibility at least for uploads done through that way. --Marsupium (talk) 06:42, 11 October 2024 (UTC)[reply]
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):
@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.
HBCUs are very simple, because they are self-organized into an association.
I have no problem with the existence of any of these subcats. My issue is with the term "minority schools." Since you bring up Black Americans: would an African-American academy at the high-school level in Detroit (a city that is over 75% Black) be a "minority school"? And, again, why on a global basis are Jews and Armenians deems "minorities" (even though each has a country where they make up the majority) but Hungarians (the majority in Hungary, and an important minority in Romania, Slovakia, and elsewhere) are not? (All three are within about 20% of the same size populations.) - Jmabel ! talk12:51, 10 October 2024 (UTC)[reply]
My thoughts are that the term "Minority" is really poorly defined and that maybe "Ethnic schools" would be better and more precise, we can also use "Religious schools" where relevant Oxyman (talk) 03:59, 13 October 2024 (UTC)[reply]
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]
Yes, earthquakes in San Francisco area, a concern that I have expressed several times here, is only one of the risks that may affect Internet Archive. Fortunately, as Prototyperspective said, it seems that contents weren't affected, but if, as their only publicly available information says, they only have 2 production copies of each file (and no proper backups), some attack could possibly delete information completely (Archive stores so many files that a complete destruction due to an attack seems highly unlikely, though). I hope this event will help them to greatly improve their infrastructure, and to get the money they would need for that. I hope that the recent Archive's partnership with Google also helps with this. MGeog2022 (talk) 20:04, 10 October 2024 (UTC)[reply]
By the way, while WMF has much better resources and infrastructure than Internet Archive, absolute security does not exist, so this is a reminder that Commons media dumps are a real need (as well as true offline backups ready to be restored, both for media and for text content in all WMF wikis). MGeog2022 (talk) 20:26, 10 October 2024 (UTC)[reply]
Category slideshows
Does anyone understand why the UI to start a category slideshow uses such "mystery meat" navigation? Nothing obvious about the symbol at all. - Jmabel ! talk14:32, 10 October 2024 (UTC)[reply]
When using the deepcategory search operator it should detect self-categorization so it doesn't break. Until that is implemented, fixing self-categorization is especially needed (e.g. to enable it to always show results phab:T376440) but it's also a general problem if categories contain themselves (in these cases directly).
The report was empty / out of date for a long time but now MZMcBride (talk·contribs) updated it – thanks for that!
I worked on it until Ludwig_August_Fallon (default sorting not alphabetic sorting) except for year_in_India cats. Fixing these problems is usually quite simple – removing that category or replacing a template that sets the category with the categories. Sometimes one also needs to add other categories such as some taxonomic category. I requested on the talk page that it (a separate page / report) also shows categories that include themselves somewhere in their subcategories.
If this is done and with the two other reports announced above there would then be reports for nearly all issues with categories. After these have been solved to some extent what would remain are the issue of categories with just 1 file (debatable whether that's preferable over just categorizing the file like the cat), empty categories (see Quarry:query/7200 and many/most of them should be deleted), and mismatches between WMC and WP (mainly ENWP) categories which often means some cats of the WMC cat are missing and just need to be synced with WP.
--Prototyperspective (talk) 14:59, 10 October 2024 (UTC)[reply]
That would be great. It would only fail for categories that have themselves set via templates. If you neither create such a bot nor request one, I'll sooner or later propose one at Commons:Bots/Work requests. Some of these cats may benefit from human checking (because they lack cats) but that's not worth the time required and may get addressed via the mentioned category-mismatch detection that could implemented at some point. Prototyperspective (talk) 16:36, 10 October 2024 (UTC)[reply]
Thanks! I don't know what the query for it is and hope MZMcBride updates it again at some point. Categories that contain themselves in some subcategory are just as much of a problem (e.g. cause deepcategory to fail and are logically contradictory) but aren't included there. If somebody is interested in these or can adjust the query (which is it?) to also scan several layers of subcategories, please see the report's talk page. When it comes to templates I suggest people who added the template are pinged or it's asked about at the template's talk page – often the best solution is to comment out or remove the template and replace it with the categories that it automatically sets except of the self-categorizing cat. Prototyperspective (talk) 09:27, 11 October 2024 (UTC)[reply]
Not sure, maybe the templates can be fixed to do it more selectively.
Thanks for the link, I've seen it before but don't know where I found the link and forgot about it – however, that's just some code without any info on how to run it. Can it be run in the Quarry tool? Loops can be avoided by putting all the scanned categories in an array and the checking whether the category currently checked is in that array. If so, it would not look into subcategories of that category and show it as one of the categories that contain themselves. This way it would scan layer by layer and the number of layers to scan could be increased over time. Prototyperspective (talk) 12:20, 11 October 2024 (UTC)[reply]
FastCCI's cat path exampleGreat! So this is already solved? Could you please put that in a separate query instead of just in some revision of a query about something else and then put that in some report?
Putting it in a report on Commons is also useful for people here to find that query, not just for accessing the results and working on fixing the issues. When it comes to fixing the issues what is still needed is showing a categorization path per each item showing why the second category is located somewhere in the former like in the attached image. Do you think it would be possible to add a column for that in the query? It would also be relevant to this request for a new tool/gadget and this issue for petscan. Such is one of the most needed functionalities to improve categorizations and petscan often shows files that do not belong into categories without a way to find out why (examples in the two links). Prototyperspective (talk) 13:17, 12 October 2024 (UTC)[reply]
If you won't forget about it and keep track of all the relevant info and the query then that may be a good idea. I don't think there's an issue with putting it into a report if nobody finds it anyway. A categorization path is also needed for e.g. the two other things I linked and maybe that could be used there. Didn't you say the number of self-categorizations is way down now and the remaining ones are due to templates? In that case it seems like the problem is already solved: making template creators/writers aware of the problem on the template talk pages so the problem gets fixed at the template and/or simply commenting out the template on the respective pages to replace them with the other cats. If you mean the 7500 cats that contain themselves somewhere, I don't think a bot could correct [many of] these self-categorizations – it does need quick human checking and that is best done by enabling users to only need very little time per correction (quick succession editing) including displaying the necessary info of the categorization path. The optimal solution would be displaying the categorization path with each cat having an x button to remove the cat that caused the self-categorization but requiring the user to click the cat and remove it with a second click is also good. Prototyperspective (talk) 17:21, 12 October 2024 (UTC)[reply]
They are all pairs as the sample above (Category:(26)_Proserpina_symbols + Category:Persephone_symbols). Longer chains are not include (e.g. grandparent = child).
Oh too bad, I thought I checked some and it was not a direct self-categorization and also I don't understand then why the query shows so many results while the report only has a few hundred or so or 151 remaining ones. In that case maybe it does need a report with two columns with a button to directly remove the problematic cat on either cat directly, maybe this can can be done with some specific URL and the URL could be attached next to each wikilink. No other idea, e.g. I think even for your example case where it's quite obvious to a human it would be difficult to a bot (one that has some chance of getting developed). Prototyperspective (talk) 17:50, 12 October 2024 (UTC)[reply]
The 150 are just the ones that are self-categorizations (1 category involved, as your report above).
In the Upload Wizard there are separate fields for "Main subjects visible in this work" and "Category" (which possibly should read "Categories"). I wonder why it is necessary to have both. In what case would (or could) a "main subject visible" NOT be a category? ITookSomePhotos (talk) 17:59, 10 October 2024 (UTC)[reply]
Agree, it's duplication of work. I think categories should automatically sync to structured data if SD is to be used at all. However, note that a file may not depict some things that are in a category...however people also add depict statements for such things (e.g. when a video is only about sth but not depicting it) and there's also categories that are not about the contents in terms of what is being depicted such as Category:Videos without audio. Prototyperspective (talk) 18:50, 10 October 2024 (UTC)[reply]
It makes sense and I don't want to argue against it...I'd just like to leave a note about four things to consider:
people often set SD for depicts: the building (using that example)
when it has some depicts statements set the main thing depicted (door handle using that example) may not be in the SD while it's in the cats if cats are set in ca >95% of cases
the category could (often should) have a dedicated subcategory for pictures like that
the depicted thing can be inferred from the combination of categories set (e.g. close-up photos of door handles + building xy + other cats = pic depicts door handle of that building)
Note that I deliberately asked how a "main subject visible" would or could not be a category, and not the other way around. In the case of the door handle, still, my point holds. We would have to specify "door handle" twice, once as a category, and once as a depicted object, apparently redundantly. ITookSomePhotos (talk) 17:25, 11 October 2024 (UTC)[reply]
Though I guess the way things are set up now, if we only specified the categories, "door handle" and "building X", and no separate "subjects visible" information, then we would lose the information that "building X" is NOT visible. If this is important to capture, then I suppose in an ideal world we would specify visible objects once, and then have another field for "other categories". ITookSomePhotos (talk) 17:54, 11 October 2024 (UTC)[reply]
I suggest you use another plant identification tool instead of asking humans here. These tools could also be useful for suggesting categories and I think several work better for plants than Google Lens but I don't know if there's any that is free software. Prototyperspective (talk) 12:48, 11 October 2024 (UTC)[reply]
i believe we have enough images that represents what QR codes looks like. and also there is many more redundant files. right now, 358 files. i believe we should do something about this. Category:Raster quick response codes. we should make DR'd these redundant files. and, i didnt check, also, i believe there is plenty of advertisements out there. modern_primatඞඞඞ ----TALK17:58, 11 October 2024 (UTC)[reply]
Support. I'll go through these and open a batch DR later today. FWIW, you can decode most of these by pasting the image URL into Zxing - much easier than scanning them off the computer screen. Omphalographer (talk) 19:03, 11 October 2024 (UTC)[reply]
As it is becoming evident that some submitted files do infringe on sculptural copyrights due to lack of FoP in their countries (I nominated some myself), is it appropriate to create tracking categories of deletion requests concerning WLM-2024-related files?
In this way, organizers may be able to reassess their rules for future competitions and some may even try the stepping stones to reform their copyright laws. We may no longer be able to categorize those of past contests due to the deleted files not being visible to non-sysops like me.
@Adamant1@GPSLeo on a second thought, I think it won't help much. With little to no initiatives of various Wikimedia chapters and local user groups as well as unwillingness of several countries to permit full exposure of their public spaces in commercially-available media, I don't think we can expect improvements in copyright laws very soon. Even the U.S. architectural FoP is not immune to criticism, albeit from a small sector composed of some architects and lawyers who are critical of the 1990 AWCPA as having deprived architects the right to control the U.S. public's images of U.S. buildings. Expect some "unsurprising surprises" on FoP statuses of some countries. Withdrawing my categorization proposal, to reduce some stress on my part. JWilz12345(Talk|Contrib's.)06:24, 12 October 2024 (UTC)[reply]
Organisation logo to Commons
I uploaded a logo and it is stored locally on the English Wikipedia (en:File:Linpra logo.png).
I'd like to upload it to Commons with the same rationale as logos from Volvo, Ikea, Saab and others.
How do I upload it to Commons?
I don't see any documentation of the threshold of originality for Lithuania. Does someone have something? For the U.S. it should be OK. - Jmabel ! talk16:20, 12 October 2024 (UTC)[reply]
From a technical point of view, of course you could, but that doesn't make the copyright status in Lithuania any clearer. - Jmabel ! talk20:11, 12 October 2024 (UTC)[reply]
There is no Freedom of Panorama for sounds Does somebody have info on that? Videos of live music would be useful often and also there are several/many videos of such which if they aren't free would need to be deleted (example). I am trying to find wich music band was playing Use the Wayback Machine when it's functional – if they don't have the relevant page archived and other archival websites like archive.today and the Google Cache don't have neither and Web search engines don't show anything for relevant searches then you're probably out of luck but I don't see any problem with that since it's unlikely to be a very notable band where a photo is much needed and I think most such bands already have some photos on WMC. Prototyperspective (talk) 12:22, 12 October 2024 (UTC)[reply]
A band playing not permanent and therefore definitely not covered by FOP in most regions as FOP requires works to be permanent in public space. For cases like bell installations it could be a difficult question. GPSLeo (talk) 11:22, 13 October 2024 (UTC)[reply]
Thanks for the info. I wonder about the music but I think it can't be copyrighted if it's played in a public space. Nevertheless, I don't know if a concert etc is a public space in regards to whether videos of the live music can be uploaded under CCBY. Prototyperspective (talk) 11:45, 13 October 2024 (UTC)[reply]
Change in editing behaviour for keyboard shortcuts?
I've probably missed an announcement, but now if I try to copy something with command-C I get ''Italic text'', and if I paste something with command-V I get <sup>Superscript text</sup> - any pointers to where this changed, and how to disable it? Thanks. Mike Peel (talk) 22:10, 12 October 2024 (UTC)[reply]
With more investigation, this seems to be related to my keyboard overlay - if I switch to querty, it works fine, but with dvorak, it isn't. Weird. (I becomes C and > becomes V with dvorak, so the keyboard shortcuts then make sense...) Thanks. Mike Peel (talk) 16:44, 13 October 2024 (UTC)[reply]
Seems plausible. The linked web site has a footer which states Музыка, тексты и изображения сайта распространяются по лицензии Creative Commons BY-SA 4.0. Next question is whether it's in scope; I can't help but notice that the artist doesn't have an article on any Wikipedia. Omphalographer (talk) 01:53, 13 October 2024 (UTC)[reply]
The video ends with the arrival in a small train stop. A have been checking the stations in the en:Kyūdai Main Line article, but not finding it. Nearly all the bigger stations have a footbridge and this one does not. There is a Japanese text, but I am not certain that this the station name. Is there a handy way the extract an image from a video? I can do a print screen, but I am not certain this is the best way. (I am not used to working with videos). Is there an Japanese/English speaking forum, where I can ask the question? Unfortunatly OpenRailmap does not have an translate function. Smiley.toerist (talk) 08:29, 13 October 2024 (UTC)[reply]
Note: It will be lower resolution than the video if one does not click Original file first as described in the cat. This may be irrelevant in many cases but when uploading stills to WMC the stills shouldn't be lower-quality than the video. Prototyperspective (talk) 11:10, 13 October 2024 (UTC)[reply]
If you like specifying train stations, this video (among several others) shows many of them. Maybe some of the places and villages shown could also be identified but I wonder about which use-cases that has, at least in the current form. Prototyperspective (talk) 20:27, 13 October 2024 (UTC)[reply]
Is there any Help/Commons page about empty categories? I'd like to ask if these are noindexed and if not propose that they are made noindexed. Moreover, at some point it may be good to discuss what to do about empty categories created over e.g. 2 years ago of which there seem to be many. --Prototyperspective (talk) 11:14, 13 October 2024 (UTC)[reply]
With this usable photo, the description is pure advertising. This is something I come across more often. What to do? Leave it as it is or reduce the text in this case to “Machu Picchu”? Wouter (talk) 17:43, 13 October 2024 (UTC)[reply]
This is common in YouTube video descriptions which are abused for all kinds of spam and junk as well. Ranked:
A meaningful description "Tourists posing on steps at Machu Picchu in 2023"
I often do photo editing on low-quality images and upload better versions (corrected exposure, etc). For example, File:Admiralty Centre Tower 2 (adjusted).jpg Is there an easy way to do this? Its a pain to have to manually go through the upload wizard, copy over the original author, license, description, generate a new file name with "(adjusted)" stuffed into the original name, etc. It seems like some bit of javascript could do all of this with one click. Does such a thing exist? — Preceding unsigned comment added by RoySmith (talk • contribs) 19:52, 13 October 2024 (UTC)[reply]
Others might be able to point you to a better tool, but the Basic Upload Form in Special:Upload might be useful for you. You can copy the entire description from one file and paste it here. This should almost definitely save you some clicks. Rubýñ(Scold)20:25, 13 October 2024 (UTC)[reply]
While these candidates have been ranked through the vote, they still need to be appointed to the Board of Trustees. They need to pass a successful background check and meet the qualifications outlined in the Bylaws. New trustees will be appointed at the next Board meeting in December 2024.
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)
.png/220px-FastCCI_Commons_gadget_showing_why_a_file_is_erroneously_categorized_into_a_category_(category-tree).png)
.png)
Done - Commons:Deletion requests/Files in Category:Raster quick response codes. I've included the decoded content of most of the images. Omphalographer (talk) 03:17, 12 October 2024 (UTC)
Thank you.! modern_primat ඞඞඞ ----TALK 05:42, 12 October 2024 (UTC)
.jpg){kind=link}
_-_OsmAPP_(4).JPG){kind=link}
.svg){kind=link}
.jpg){kind=link}