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]
Support further development - I think that the potential for abusing AI is something we have to address, but I am going to kindly ask that the details of the proposal should be developed further. Therefore, I support further development of this proposal into a draft policy or something like that. --Minoa (talk) 10:35, 16 October 2024 (UTC)[reply]
Upload wizards capacity
I note in this AI discussion that the upload wizard asks the question of is it ai generated, so its possible that appending to file names or adding a template to identify AI generated media could be relatively easy to do automatically at upload. with a high degreee of consistance 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]
October 07
New reports: categories with only redcats & cats with only infobox cats
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]
Updated the reports. Down to 1965 now after Sanborn maps cats (thanks Enhancing999 for that) as well as empty cats (separate report) have been taken care of. The one with only infobox categories now has 4364 items (but so far didn't have the empty cats get deleted).
Second was also updated and is at 4106 but it's probably better to cut down on the report of cats with only redcats because the cats with only Infobox cats can be solved via some tool/script that syncs their categories with ENWP. Prototyperspective (talk) 21:02, 20 October 2024 (UTC)[reply]
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]
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]
@Prototyperspective – Thanks for the feedback. I think I could design a TextField with Commons category search. It will take some time though. Also good idea with the video. I will do it once I have the redesigned dialog ready :-)
@Marsupium – Thanks for the kind words. I think for Wikimedia users, I can provide a link to the official upload tool, there is already an option in OsmAPP to add wikimedia_commons photo in the Edit section of any feature, eg. here: https://osmapp.org/way/7645354/edit .. the upload dialog makes it only easier for OSM users to contribute to Commons. Zbytovsky (talk) 08:15, 16 October 2024 (UTC)[reply]
Category:Minority schools 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]
"Ethnic schools" wouldn't cover Swedish-speaking schools in Finland, as they are based on language (language choice for some of the pupils), not ethnicity. Swedish-speakings Finns, most of whom attend those schools, are still a minority (arguably an ethnic one) on the country level, although not in all towns. I think minority schools would be an adequate category for the schools, at least for schools in areas where Finnish is the majority language. Whether inclusion is based on country level or something else needs to be told, and one might have to go to individual schools for including subcategories (unless there are suitable subcategories, such as Minority schools in Sweden or Jewish minority schools – a naming scheme should be decided on). –LPfi (talk) 09:48, 20 October 2024 (UTC)[reply]
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 threshold is much lower at Commons than at Wikipedia for some categories of media. Do we have an abundance of contemporary music? If not, then musicians do not have to be that famous to be in scope. We should even have samples of amateur music of different genres from different countries, if possible. Only when we have redundancy for some categories, we should heighten the threshold for them (usable quality should be required from the start, and some level of representativity, but not much more). –LPfi (talk) 10:01, 20 October 2024 (UTC)[reply]
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]
I used the last modified time parameter of the original MP4 file, to add the correct time. I have added the start location. Is there a format to indicate the start and end location of a video? I have experimented with timetext in Dutch. Can I add the English text or is a completely different timetext necessary?Smiley.toerist (talk) 11:42, 14 October 2024 (UTC)[reply]
It does not work for the start position. You have to use a predifined location (item), not dump location coordinates. The destination point use gives a warning. Smiley.toerist (talk) 12:37, 14 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]
The web inspector should be able to tell you if a page has the noindex command in the head of the page. I personally think noindex is overused and breaks the way google updates their indexes to a degree that makes if very difficult to change the page back to being indexed, and as such should not be used on pages that frequently change and where people have an expectation that the page should show up in indexes quickly once the no index command is removed. —TheDJ (talk • contribs) 12:26, 14 October 2024 (UTC)[reply]
Okay but then there is a problem with the many empty categories. I doubt that is a reason why Google (and DuckDuckGo) barely index category pages (and media) of WMC but I think we should leave them as little plausible reason as possible. Prototyperspective (talk) 12:34, 14 October 2024 (UTC)[reply]
I just found many categories with only infobox categories are either:
What is best done there? Should anything be done about the former? If not I wonder why there are only so few of these – do they maybe miss a cat for disambiguation pages? Is something needed or existing that adds an image automatically to a category if it's added to the corresponding Wikidata item if it's not in any subcat of it? I don't know how these images were added to the items, if people add them directly to the items via upload, maybe that tool needs a change so it's also categorized. Prototyperspective (talk) 15:10, 15 October 2024 (UTC)[reply]
Disambiguation categories are fine. An infobox may be a bit excessive there, but the interwiki link from Wikidata is important, so it is linked to parallel disambiguations in other WMF wikis.
For the ones with an image in the Infobox, my first thought is, "So why the hell isn't this image (and possibly others) in the category?" I'd probably see whether the category can be filled in with some content. And given appropriate parent categories. - Jmabel ! talk19:18, 15 October 2024 (UTC)[reply]
Some of the empty cats with images in infobox have the image in some equivalent category, for example in the same cat that is not misspelled. Other than that, it could be a good subject for discussion whether it would be better to have the image added to create a 1-image-category (over-categorization?) or just leave the image in the cats it's in and delete the empty cat for the time being (or if it varies when to do what). Here a separate report may also be best but one could also leave the main report unchanged and check the remaining bluelinked empty categories so people can see what's best case by case. Prototyperspective (talk) 20:25, 15 October 2024 (UTC)[reply]
What to do with advertising in the description?
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.
Copyright question regarding document from "Memory of the People" (pamyat-naroda.ru)
Hi all,
I've uploaded a PDF document to Wikimedia Commons that I downloaded from the Russian "Memory of the People" website (pamyat-naroda.ru). This document details the World War II service record of my grandfather, Georgiy Pavlovich Osipov, and includes information about his unit, awards, and activities during the Siege of Leningrad.
The "Memory of the People" website states the following copyright information:
Правообладателем ИС «Память народа», включая входящие в ее состав программы для ЭВМ, электронные банки (базы) данных, включающие электронные копии архивных документов, является Российская Федерация в лице Министерства обороны Российской Федерации (далее – Правообладатель).
Собственниками архивных документов, электронные копии которых размещены в ИС «Память народа», является Российская Федерация (в части документов, предоставленных российскими государственными архивами, государственными органами и организациями), а также иностранные государственные архивы и иные организации, предоставившие электронные копии этих документов.
Правообладателями аудиовизуальных произведений, предоставленных Российским государственным архивом кинофотодокументов и размещенных на сайтах ИС «Память народа», являются авторы этих произведений.
Оператором сайтов ИС «Память народа» (далее – Оператор) является Министерство обороны Российской Федерации, либо уполномоченная им организация.
Все сервисы, а также информационный контент, предоставляемые сайтами ИС «Память народа», являются государственными информационными услугами, оказываемыми бесплатно.
Обязательным условием использования документов с сайта в изданиях, связанных с историей Великой Отечественной войны, является ссылка на сайт.
English Translation:
Legal Information
The copyright holder of the "Memory of the People" information system, including the computer programs, electronic data banks (databases) containing electronic copies of archival documents, is the Russian Federation, represented by the Ministry of Defense of the Russian Federation (hereinafter referred to as the Copyright Holder).
The owners of the archival documents, electronic copies of which are posted in the "Memory of the People" information system, are the Russian Federation (with respect to documents provided by Russian state archives, state bodies, and organizations), as well as foreign state archives and other organizations that provided electronic copies of these documents.
The copyright holders of audiovisual works provided by the Russian State Archive of Film and Photo Documents and posted on the websites of the "Memory of the People" information system are the authors of these works.
The operator of the websites of the "Memory of the People" information system (hereinafter referred to as the Operator) is the Ministry of Defense of the Russian Federation or an organization authorized by it.
All services, as well as information content provided by the websites of the "Memory of the People" information system, are state information services provided free of charge.
A mandatory condition for the use of documents from the website in publications related to the history of the Great Patriotic War is a reference to the website.
My understanding is that the website considers its services and content to be state-provided information freely available, but requires attribution.
Could someone please advise on the most appropriate license to use? At this point of time, I gave it CC-BY-4.0. I want to ensure full compliance with copyright law and Wikimedia Commons guidelines. Any guidance would be greatly appreciated.
These documents were created during Great Patriotic War (1941-1945), so Creative Commons licenses did not exist at that time. Since Russia is heir of Soviet Union, general rules for government-created documents are applicable. --EugeneZelenko (talk) 14:34, 14 October 2024 (UTC)[reply]
I created in Wikidata a new item d:Q130530281 as a subclass of d:Q117075694. I wil use the SDC script to move Commons files to the new item. However there are files such as File:Tramway de Gand - Enmarchement de la rame PCC 34 (6034).JPG where d:Q117075694 was used. Can I later check for files with both tram and train items?Smiley.toerist (talk) 12:57, 14 October 2024 (UTC)[reply]
It is a private company and if not violating the law, they can do whatever (...) they want. If they choose to ignore stuff on commons - that´s fine. Alexpl (talk) 20:02, 14 October 2024 (UTC)[reply]
I was not saying it's illegal. That may be fine according to law. I wonder if it's fine to Commons that users' contributions are just blacked out and not available to people. Prototyperspective (talk) 21:39, 14 October 2024 (UTC)[reply]
Huge filesizes for photos are a cost factor when it comes to processing and are almost never worth it anyway. I dont blame them from not wanting photos with the megabytes in the three digits to show up, whenever somebody types in a generic searchterm. Alexpl (talk) 14:13, 15 October 2024 (UTC)[reply]
This seems offtopic. 1. Most files on WMC are not many MBs large and this is not about some particular few large files. 2. It only shows gstatic thumbnails in Google Search, not the whole image, and it's the same for DDG and other search engines. It's absurd to argue that Google's storage or processing would have notable issues that out of the millions of indexed website makes WMC one whose media is not findable. You can of course defend anti-WMC practices – despite that I don't understand why Commons contributors could be supportive of that – but this point does not make sense, partly because this isn't about the <0.1% of WMC files that are large image files to begin with. Prototyperspective (talk) 14:33, 15 October 2024 (UTC)[reply]
I said it seems offtopic and I did notdismiss the comment but address it comprehensively. When I say it seems offtopic that is for example because I may have misunderstood it and/or the user may want to clarify how it would be ontopic. I do wonder why you're so super sensitive about me using the word offtopic. The user did say something but did not explain how it relates to this subject and clarifying that with clear language is I think more constructive than beating around the bush. Prototyperspective (talk) 16:41, 15 October 2024 (UTC)[reply]
There is a commercial interest in steering the search results to commercial and social websites. These generate clicks, not the commons. I do have the impression that Google is much more interested in SDC of files than the Commons categories. Every effort should be made to fill in the P:P180. Google certainly uses the labels in Wikidata as datafeed for the search engines. Also used for educating the translation software.Smiley.toerist (talk) 10:12, 15 October 2024 (UTC)[reply]
Wikipedia itself is indexed rather highly on Google search results though. And it does index images that are used in Wikipedia articles, but this treatment isn't extended to the other Wikimedia projects. (I can't speak for other media files however). ReneeWrites (talk) 18:26, 15 October 2024 (UTC)[reply]
Yes Wikipedia is, but not Commons, the second largest Wikimedia project with a type of content that lots of people are interested in, watch and search for (media of all kinds). It does not index any video on here (at least in my tests I could not find any so far even when searching for the exact title) and images I think are only indexed when they're used in Wikipedia articles and even then often missing from the main results. One part of the proposal is systematic tests/investigations so there is some data on this. I think overall the indexing is pretty bad even when one is searching for a subject that WMC has lots of high quality contents and other image results that are shown are fairly low-quality. One could also focus on the videos. Prototyperspective (talk) 20:32, 15 October 2024 (UTC)[reply]
Google often indexes images that are not in a Wikipedia article. I find plenty if I do specifically an image search. But it doesn't tend to list pages that are mainly an image in its general results, so Commons image pages often don't show in the result if you do a general Google search. - Jmabel ! talk05:11, 16 October 2024 (UTC)[reply]
Rarely it does, but indexing a random tiny subset of files doesn't change anything about the issue and only makes it harder to notice this. I did not find plenty of images for prior searches I did where I then either used an image not from WMC despite that I know WMC has at least as good images well-organized or used the WMC search. Again, investigations are the first step of what is proposed so maybe you could share your searches. Images certainly shouldn't show up in the general search results (well nearly always) – I made it clear that this is about the Images and Videos tabs of these sites...only when it comes to category pages is this about the general search results. I currently don't have many good examples. Things I searched for (those may not be the best examples) I think included roughly Rivers from space and Algae blooms from space and Satellite picture of cities at night. This is not about Google&DDG not indexing any files on WMC. Please let me know if that should be clearer in the proposal. It is about them indexing only very few images (and those are not even the most relevant or best) when it should be many (e.g. in searches where WMC has lots of good-organized files), not showing nearly all categories in the results and not indexing any videos. Maybe it should be clearer that isn't necessarily all Google's fault – the investigations may reveal things Wikimedia community & tech could do to improve its inclusion in external search results – however such steps depend on investigations and don't mean step 2 & 3 are invalid, other things could follow up on that step in addition and shape these two. Prototyperspective (talk) 11:30, 16 October 2024 (UTC)[reply]
Yes, that's the kind of investigations I'm proposing are done large scale and in systematic ways (and well visibly e.g. published in diff) so we can identify cases that are well indexed, find out why, and identify cases that should be well-indexed but aren't and so on.
It could be that it's at the top because it contains a long descriptive category description – which most cats however don't really need because the category title is self-explanatory – as well as an infobox with all sorts of data. It's not unlikely also because there's few other websites with info on that subject, especially not recent ones that are linked from other pages. As a result of findings like your example, one could for example conduct tests (and/or check the theory via the dataset) whether it's the company's name in the description that caused the cat to show up this high or the description and consider things like adding category-descriptions (partly automatically via WP article leads and/or Wikidata item description). An open letter doesn't have to be as provocative and confrontational as the title of this thread, one could nicely ask Google & Co to improve their results by considering specific things or identified requested changes. Relevant to that is that Google & Co heavily make use of Wikimedia content in all sorts of ways but this isn't about fairly giving back (some media attention however could be due to that and reference that): it would be about them improving their search results for everyone so it shows media or pages that the person searching would likely find useful (e.g. via considering how many files and how many Wikipedia-used files are contained in the category). (When it comes to videos however it seems like purposeful exclusion.) Prototyperspective (talk) 08:24, 18 October 2024 (UTC)[reply]
Google clearly does take these images into account. I looked up a handful of terms:
Google Images searches
hubble extreme deep field (1 top result from WMF projects)
pando tree (2 top results from WMF projects)
tokyo tower (2 top results from WMF projects)
african renaissance monument (2 top results from WMF projects)
burj khalifa (2 top results from WMF projects)
gutenberg bible (2 top results from WMF projects)
ka'ba (7 top results from WMF projects)
michelangelo david (3 top results from WMF projects)
mount denali (3 top results from WMF projects and 1 from Wikiwand, which mirrors Wikipedia)
keyboard (0 top results from WMF projects. In this case, it gave me stores near me to buy keyboards, which makes perfect sense, if you ask me.)
hurricane milton (1 top result from WMF projects)
vladimir putin (1 top result from WMF projects)
mitochondrion (1 top result from WMF projects)
october revolution (2 top results from WMF projects)
northern lights (0 top results from WMF projects)
train (3 top results from WMF projects)
barcelona (1 top result from WMF projects)
mesopotamia (2 top results from WMF projects)
If you narrow your search to CC images, you get more from Flickr and Commons:
Google Images searches - Narrowed to Creative Commons
hubble extreme deep field (4 top results from WMF projects)
pando tree (4 top results from WMF projects)
tokyo tower (4 top results from WMF projects)
african renaissance monument (6 top results from WMF projects)
burj khalifa (7 top results from WMF projects)
gutenberg bible (4 top results from WMF projects)
ka'ba (5 top results from WMF projects, decreased)
michelangelo david (6 top results from WMF projects)
mount denali (3 top results from WMF projects)
keyboard (4 top results from WMF projects)
hurricane milton (1 top result from WMF projects)
vladimir putin (4 top results from WMF projects)
mitochondrion (16(!) top results from WMF projects)
october revolution (1 top result from WMF projects, decreased)
northern lights (3 top results from WMF projects)
train (4 top results from WMF projects)
barcelona (2 top results from WMF projects)
mesopotamia (5 top results from WMF projects)
I don't believe there even is a problem. Sure, results from WMF projects are only 1 or 2 in many cases, but:
it's not like there was any other site that did have a majority of the top results
you can improve them by searching for CC content
Wikipedia was almost always in the results, even if they didn't have a majority in the top images (which there's no reason it should, might I add). I can't say the same about other results I saw, like Britannica, NatGeo, Adobe Stock, etc.
Google is showing results from Wikipedia, Commons, and even smaller projects like Wikispecies and Wikivoyage, at times .I wouldn't put it past them that they're prioritizing commercial and social sites that run Google Ads (purely speculation from my part, don't take my word for it), but I find it hard to believe that they're straight up censoring, shadowbanning, or otherwise limiting results from WMF projects. Rubýñ(Scold)17:21, 15 October 2024 (UTC)[reply]
I haven't repeated all the searches to test this, but with the ones I did I only got 1 result from WMF, and it was the image in the infobox of the Wikipedia article about the subject. ReneeWrites (talk) 20:29, 15 October 2024 (UTC)[reply]
I personally use Ecosia to search things and I often just type in something in Ecosia rather than search it here because I am too lazy to use the convoluted Wikimedia internal search method (yes, using external websites to find something is oftentimes easy than the internal "search" engines on Wikimedia websites), but I noticed that in the past few months Ecosia has been suppressing non-Wikipedia Wikimedia websites more, now, this seems to coincide with the switch where Ecosia now mixes in Google Search search results with those from Microsoft Bing, before this change Ecosia exclusively used Microsoft Bing and while I've used Microsoft Bing as my main search enginge since 2011~2012'ish, I switched to Ecosia a couple of years ago (after I saw one of their advertisements on Google YouTube) and I occasionally compare it with Google Search and other search engines. Judging by the fact that Google Search suppresses Wikimedia Commons and Microsoft Bing does this to a lesser extent I assume that this likely is a deliberate choice by those companies. But it could probably also be something internal at Wikimedia websites as all non-article space pages at Wikipedia are also excluded from search engines (meaning that someone cannot find any Wikipedia policy pages unless someone looks for them within Wikipedia, which I've always found to be a rather odd choice).
Now, we know that Google Search, Microsoft Bing, Ecosia, DuckDuckGo, Yahoo! Search, Etc. all heavily rely on Wikidata, perhaps linking all Wikimedia Commons category pages with Wikidata items might help integrate this website better with search engines, if you think about it, the exclusion of the Wikimedia Commons is exclusively the exclusion of the Wikimedia Commons, I have no trouble finding results from the Wiktionary or Wikivoyage, which probably means that the integration between Wikidata and other Wikimedia websites helps them. Now, I know that "SEO" is considered "a curse word among Wikimedians", but if we want the Wikimedia Commons to show up in search results we most likely do need to link to Wikidata and properly use redirects, alternative titles, translations, Etc. in a way that makes sense. For example, if you search for alternative titles on Wikipedia you get them, like "Communist Germany" in a search enginge you'll find the DDR because "Communist Germany" is a redirect at Wikipedia. Meanwhile, we tend to have highly specific titles and redirects are typically deleted. But my guess is that the main culprit is the lack of Wikidata integration at the Wikimedia Commons, I wonder if files with more optimised structured data also show up in search engine results more as these are dependent on Wikidata items. Alternatively, we could compare if categories with or without Wikidata integration show up more in internet search enginges. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 18:52, 19 October 2024 (UTC)[reply]
Thanks for this interesting info contribution.
Comparing indexing results between search engines like so and across time (especially after algorithms were reported to be changed albeit it's often probably not announced) could help identify causes and potential mitigation measures.
I never noticed or thought about search engines not indexing policy and meta pages of Wikimedia sites (nonWMC), if so that's also I think something that would be good to be changed if possible. For example, new editors or readers may search for these with a search engine instead of the internal one. If they searched for a meta/help pages on Commons it's often quite possible they can't find it because they don't show up in the search results even when in the MediaSearch' Categories and Pages tab (issue #8 here).
[Google & Co] all heavily rely on Wikidata that good integration with Wikidata is a cause for SE indexing or good indexing and that improving that integration are two hypotheses that could be tested. I do not think this is the case much because category pages that are linked to Wikidata items also do not show up and only a tiny sub < 0,01% of files are used in Wikidata items or usable there while most items are somewhere underneath a category that is linked to Wikidata item. I think 'it's not linked to a Wikidata item' or 'it doesn't have structured data depicts statements' would be not much more than false excuses (not necessarily deliberate) for not indexing and I don't see why it would rely on / require it / why it should be expected. Moreover, some categories should probably be well-indexed without being linked to a Wikidata item or linking such would be inappropriate or at least can't be done at scale(?) – e.g. Category:Drone videos with lots of organized content can't even be found in DuckDuckGo when searching for drone videos wiki (btw I think it should also show up high for searches like free drone videos). The linked proposal however is interesting but I have doubts this can be done both at scale and affects the SE much. Data suggesting such as has any significant effect is also missing. So I don't think it would solve this, e.g. videos on WMC still don't show up in the videos tab and many large categories are already linked.
and properly use redirects, alternative titles, translations, Etc. in a way that makes sense Agree. One option is to sync ENWP redirects of items to WMC so WMC has the same redirects [ie a tool for doing so]. Another is Adding machine translated category titles and this could also be implemented via redirects and be extended to category descriptions. This however is another case that I don't think should be required for the pages to show up in search results but only improve them. It's possible that this would solve this even if it shouldn't be that way due to how pages are ranked. Note that this may require that the category page is an actual url with an actual title and not not the same url with some Javascript dynamically changing the title depending on the user language. Another option of creating redirects of translated titles – Category:Tiere (de; only plural form not singular) currently redirects to Category:Animals – can't be done at scale and may cause issues (such as HotCat autocompletes).
In any case such comparison data would be great even if it's just a small factor (I doubt it's the main culprit for the plural indexing issues).
From everything I've been able to tell, Google does index pages in "Commons" space. For example, do a Google search on "structured data commons" (no quotes). - Jmabel ! talk16:43, 20 October 2024 (UTC)[reply]
Yes, this is known, e.g. the intro already is about "most" files, not "all" files as well as results' ranking/findability. I've yet got to see a WMC video in the videos tab however. Prototyperspective (talk) 16:46, 20 October 2024 (UTC)[reply]
October 15
Admin action rational
I wonder how much explanation we should expect from admins for their admin actions.
Supposedly, an admin should be able to explain which policy they applied when the delete content from Commons. It's fairly obvious when the content is deleted due to copyright issues, but less so, in other case.
His question probably relates to deleting unnecessary empty categories that will not be filled in the foreseeable future. To be fair, I would like to inform admin @Yann about this ongoing discussion. Lukas Beck (talk) 14:29, 15 October 2024 (UTC)[reply]
@Enhancing999: If an Admin is doing something wrong, then certainly they should be held accountable. On the other hand, if a user is doing something wrong (like trying to keep empty categories without good reason), then they should be held accountable. — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:29, 15 October 2024 (UTC)[reply]
Up to a point. But if I had to give a detailed explanation tying every action I took back to policy, I would not get much done. Most of the time, it should be clear on the surface. For example, if I correct a misspelled category name, I'm probably not going to cite a specific policy to say why. - Jmabel ! talk05:15, 16 October 2024 (UTC)[reply]
Not by default, but when asked about it, shouldn't you be able to explain that category names are to be spelled in English per our policy on categories (insert link), that the word is written without the letter "y" as can be found in Wiktionary (insert link), and thus you fixed a typo, applied this or that part of speedy deletion policy (insert link) after the stated delay (insert link). The detailed explanation would be almost the same for thousands of admin actions.
Jeff: your comment appears to be off-topic. Please discuss CSD with Yann on their user page. The question here isn't about a particular action of Yann. ∞∞ Enhancing999 (talk) 21:39, 15 October 2024 (UTC)[reply]
Generally admins don't give rationales for their actions. Nor do I think they should in a lot of cases because it would just get in the way of them doing their jobs. Deleting empty categories being one instance where it's totally pointless and would just needlessly slow things down. Probably with something like blocks they can and should do a better job explaining the reasoning behind it though. I don't think the default block message is really helpful or gets at the issue that led to the block in a lot of, if not most, cases. And the person who is blocked risks having their talk page access restricted or the length of the block getting extended if they ask for clarification about it. Which just seems like a bad way to go about things. Although I don't really see it changing either though. There doesn't really need to be a policy based reason for anything admins do in most cases anyway and it's not like they are (or ever will be) held accountable for anything either. --Adamant1 (talk) 00:51, 16 October 2024 (UTC)[reply]
I'm a big believer in holding admins accountable for questionable actions, but it is no secret that Commons has some fairly severe issues with backlogs. Requiring detailed explanations in situations where the reason is obvious places an undue burden on admins. If asked, they should of course provide at least a basic explanation but requiring it upfront in all cases seems needlessly burdensome. Just Step Sideways (talk) 22:13, 19 October 2024 (UTC)[reply]
This page requested cropped images, which I created from the source image. However, the system penalizes if I try to add the new images to the page.
Below are the source image and cropped images:
Love American Style cast 1973.JPG - Wikimedia Commons
Love American Style cast 1973.middle.jpg
Love American Style cast 1973.1.jpg
For the last image, I uploaded several versions which you can see at my uploads.
@Starlighsky: You don't say what page (or even what website) you want these added to. The latter two are not very good photos, they are tiny, I would certainly hesitate to add them to (for example) a Wikipedia article. And "the system penalizes" is unclear. Is this something you were asked not to do? If so, you certainly should not encourage someone else to do it on your behalf. - Jmabel ! talk05:21, 16 October 2024 (UTC)[reply]
Here is the site: File:Love American Style cast 1973.JPG - Wikimedia Commons
We use reverse image searches pretty often, mainly for determining if a new upload exists elsewhere on the web, but also for looking for 3rd party usage of the files we host. It looks like Google is deprecating its reverse image search in favor of Lens. What are people using as a substitute? I never got particularly good results with TinEye... — Rhododendritestalk | 14:08, 16 October 2024 (UTC)[reply]
I get good results with TinEye and use a browser extension so that one only needs to right click the image to reverse search it. I think it would be better if bots/scripts did the reverse searches. Don't know what you mean with the Google issue – it can still reverse search, maybe click on "Find image source" at the top. I don't think there are other options – they would be on https://imgops.com/. Prototyperspective (talk) 15:40, 16 October 2024 (UTC)[reply]
If I am performing a due diligence search to see if anyone is claiming to be the creator, or if a for profit archive like Getty is claiming an active copyright on an image I use both. I like that Tineye tells how many images it searched. --RAN (talk) 14:39, 17 October 2024 (UTC)[reply]
IP edit edit confirmation
There is a proposal to test if requiring anon users to confirm their edits by clicking the edit button again and showing a warning to avoid accidental edits can reduce the amount of bad edits. There is currently a consensus to test this but with only three people involved Commons:Village pump/Proposals#Simple edit confirmation. There was also the question on numbers of bad edits. I created a tool that shows how many edits are marked as reverted also compared to the patrolled edits that shows the potential high numbers of unseen bad edits [1]. GPSLeo (talk) 16:55, 16 October 2024 (UTC)[reply]
UploadWizard gives author as "[[User:Example|Example]]"
UploadWizard has started between 16:42 and 18:41 UTC today in my uploads to put the whole wikitext syntax again as the label of the link for the author, e.g. here. In wikitext this is: [[User:Example|[[User:Example|Example]]]]. Other files uploaded with UploadWizard at Special:NewFiles seem not to be concerned. Do you know if this is a known bug? --Marsupium (talk) 19:30, 16 October 2024 (UTC)[reply]
Applications for the committees open on 16 October 2024. Applications for the Affiliations Committee close on 18 November 2024, and applications for the Ombuds commission and the Case Review Committee close on 2 December 2024. Learn how to apply by visiting the appointment page on Meta-wiki. Post to the talk page or email cst@wikimedia.org with any questions you may have.
I did the requested cropping for File:Love American Style cast 1973.JPG - Wikimedia Commons
The cropped images are in the links for the respective images requested on the file page.
If someone has access to the technology to improve the cropped images, that would be great. Starlighsky (talk) 00:44, 17 October 2024 (UTC)[reply]
@Starlighsky: There is no way to "improve" a low-res image. AI can use it as a basis for something that is essentially fictional, but that is no longer a documentary image. - Jmabel ! talk08:31, 17 October 2024 (UTC)[reply]
Which Commons has plenty of, there's no rule against uploading upscaled versions of historical photos here. But the English Wikipedia would not allow such an image to be used to illustrate an article (per en:MOS:IMAGES), if that was Starlighsky's intention. Belbury (talk) 08:43, 17 October 2024 (UTC)[reply]
Of course, it's doubtful that people will want to have this discussion, but I'm going to try anyway. If Commons is truly a separate website and not simply subservient to Wikidata or Wikipedia, why should we host extremely low-res files solely to satisfy a POV held by Wikidata and/or Wikipedia editors that subjects be illustrated in isolation rather than in the context of uploaded photos? The default resolution on Wikipedia is 220 pixels wide. It doesn't take a PhD to figure out that when you crop an image to a lesser resolution, it's absolutely going to look like shit. Yet, that's been going on for years. Should we establish a deletion criteria for these crops when suitable replacements are uploaded and they become practically useless? RadioKAOS / Talk to me, Billy / Transmissions 17:57, 17 October 2024 (UTC)[reply]
Commons has two roles: as a public-facing media repository in its own right, and as the shared media repository for WMF sister projects. Probably half the content we host makes sense only for the first purpose (e.g. no sister project is ever going to care what a particular streetcorner in Seattle looked like in 1894), 5-10% makes sense only for the second (e.g. Wikidata needs an illustration for an item, but no really good photo is available; someone has a chart that makes sense only in the context of a particular WikiBooks article), and the remainder at least potentially makes sense for both. The second role is why we have the rule that any file that is legitimately in use on any sister project is automatically in scope, and should be deleted only if there is an issue about rights. - Jmabel ! talk07:43, 18 October 2024 (UTC)[reply]
Automatic detection of potentially problematic domains in UploadWizard
Mockup of a potential message for problematic external source
You are encouraged to take a look at the project page, and to evaluate the current workflow.
We have also a request for feedback for you: we are considering adding a user alert during the upload process if a problematic external source is detected in the file. On the right, we are sharing some potential designs for the alert. We welcome community feedback about how it is phrased and whether it may be useful.
Before I change it, perhaps someone else could offer their opinion or confirmation that the image File:Isle of Portland from north.jpg is reversed. It does seem that way to me, but OTOH it has been the lead image on the Wikipedia "Isle of Portland" page for well over a year, and I am surprised that no one would have noticed it, so just in case I am somehow getting totally confused ... ITookSomePhotos (talk) 20:50, 17 October 2024 (UTC)[reply]
Your confusion is completely understandable. IMO, you won’t be the last. I know Portland well, and it gave me pause. If I were you, I'd consider leaving a confirmation on the image's talk page confirming the orientation. You could also put in camera co-ordinates, as a suggestion. Broichmore (talk) 11:06, 19 October 2024 (UTC)[reply]
October 18
Genuine historical images relegated to art
This is one of my pet peeves. We have images, which pre-date publication of clear and informative printed photographs. IMO, they're correctly catted as Category:History of El Callao.
They could as easily have been put into a new, and perhaps superfluous category, of Historical images of El Callao. Instead, they have been transferred into a new category, entitled El Callao in art.
Apparently, it’s been decided to do away with such cats, as Historical images of El Callao, in favour of ‘’History of El Callao’’. I’ve no idea, how, that came about.
Surely it's simple to understand that only an image, by for example Van Gogh or any other abstract artist, of a location, is appropriate to put in an art cat. Whereas, views of buildings, battle scenes, or anything before useable photographs, are not art as such, they were never made as art pieces by the artist/s (sic) at the time. These images, in the main. were copied by from sketches made on the spot, or early Daguerreotypes.
Not a single image in El Callao in art is actually ‘’art’’, as opposed to a historical record (of the time)!
This is, as faulty as our habit of, creating a category such as USS Foo (ship, 2024), where ship is mentioned twice in the same cat name. We need to change the policy on both. Broichmore (talk) 13:38, 18 October 2024 (UTC)[reply]
I agree that many of the images in "El Callao in art" serve as important historical records, but they also hold artistic value, even if they weren't created as artistic pieces in the way we use that phrase today. Rather than debating whether they count as art, it might be more practical to categorize them in both "El Callao in art" and "El Callao in the xth century" categories, rather than getting into the weeds with a debate that is going to involve a lot more images than just the ones in that category. If someone gives you trouble for that (like by removing the "xth century" categories) you can argue that they count as historical records, but the "art" debate is a completely separate matter from that. ReneeWrites (talk) 14:40, 18 October 2024 (UTC)[reply]
More junk data being added to 'depicts' statements
I thought we had stopped the automatic addition of vague and irrelevant "tags" as values for depicts (P180) when we turned off the WMF's benighted Tagging Tool and reverted most of its edits, but apparently not. This has been going on for months, it seems. I just removed a load of nonsense values from an image and replaced them with the value for the item describing the actual subject. They were added by the bot in August 2023.
The bot approval - dated 2021 - says "depicts (P180) - What do we see in the photo. This based on the [[tags and on the reverse geocoding of the object coordinates". Separate SDC properties for tags exist.
The conversions are apparently handled by the list at User:GeographBot/Tags - but this includes some very problematic pairs, suggesting, for example, that a Geography tag of cross should be interpreted as depicting cross (Q40843) - a "geometrical figure". But the tag is most likely to be used on images depicting a Christian cross (Q392371) ("symbol of Christianity") or a Celtic cross (Q229788) ("Christian cross superimposed on a circle"). Another entry suggests that images might depict Ordnance Survey (Q548721) ("organisation that creates maps of Great Britain"). Another that images tagged as "standing+stone" depict menhir (Q193475) - a subclass of standing stones. Anything tagged "town hall" will be said to depict Rathaus (Q543654) - which is unique to German speaking countries. Odd, given that the entire Geograph corpus consists solely of images from the UK.
I do not believe there has ever been community consensus expressed that tag values should be used in P180 (I have asked previously, more than once, and have never been furnished with evidence). Such behaviour needs to stop, or be stopped; and the values moved or removed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits18:53, 18 October 2024 (UTC)[reply]
It looks like the old BG-n babel boxes were moved to bitmap-n to solve the collision with the language code for Bulgarian when using {{#babel}}, but the same was never done for the AF-n audio file babel boxes and their collision with Afrikaans.
I thought I was being smart by creating redirects, e.g. Audio-4 as a template that redirects to AF-4, and it looked like I was. It now displays just fine if you use {{#babel|audio-4}}!
Then I realized I might've made a huge error in doing so...because it didn't add the categories, but then I realized that neither {{Babel}}nor{{#babel}} will add you to any of the "file format" categories that aren't a spoken language in the first place!
It seems every user page I checked under Category:Audio file editors either had the category manually added or used a tool like HotCat or AWB when BG→bitmap happened.
It looks like Category:Audio file editors was last edited before the BG-n -> bitmap-n move was made, and it (erroneously) recommends using {{Babel|BG-n}} over {{#babel|BG-n}} when {{#babel|bitmap-n}} will work fine now.
And {{Babel}}'s own page says that it is deprecated and {{#babel}} should be used instead...
¯\_ ⍨⃝_/¯
Although there are only six users total in the AF-n categories and I could likely implement any change entirely by hand in a few minutes, I don't want to make a mess of things, at least without asking for input first. -αβοοδ (talk) 19:25, 18 October 2024 (UTC)[reply]
Category:Stores is a redirected to Category:Shops. So the differences probably don't matter even if there are any to begin with. Personally, I've always found putting everything having to do with retail selling in a category for shops to be a little weird. But it is what it is. So Category:Toy stores should probably just be a redirect unless your willing to relitigate the whole thing more generally. --Adamant1 (talk) 06:51, 19 October 2024 (UTC)[reply]
12 Public domain images from an archived page at archive.org, which I uploaded. I was was unable to specify the web-address/origin of the uploaded images, due to the current version of the website being banned. I can't even put the address here for you to look at because
"The text you wanted to publish was blocked by the spam filter. This is probably caused by a link to a forbidden external site. The following text is what triggered our spam disallow list: turismo-prerromanico.es."
How to handle a widespread hoax flag used as official flag?
Fake joke flag
This troll Martini-flag has nothing to do with Saint-Martin. It's not used on the island. It's a well played booze and word joke. It's funny to see that the joker or marketeer who made this fictional flag rotated the Sint-Maarten flag 90°, just like the Dutch and French flag are rotated, and modeled it after a Martini cocktail. I hope you do see that the glass is low on liqor but still has an olive in it. Of course this must mean that the whole nation is drunk and possibly hung over?
Too few involved users = Wikisupport for the troll
Not so funny is the naming on Wikimedia and widespread use on Wikipedia, of the liqor flag as the or as a Saint-Martin flag. That's similar to replacing the US Stars and Stripes by a Coors flag and then editing (templates on) 1001 pages to deliver the joke. I suspect that would be considered offensive and vandalising. Probably the changes would be corrected very fast, as there are many of our users that salute the US flag on a dayly basis.
Meanwhile the "look at this funny drunken nation"-flag spread onto nearly a 1000 pages. I've just removed the flag from the Dutch wiki, including an EU navigation template with all the official flags of the EU... That's what you get when the name of the flag seems official, and users expect Commons to uphold the same reference based quality checks as Wikipedia. It would not surprise me, if "we" had a significant part in spreading this joke of a flag to the flag-shops of the world.
How to solve this and learn from it?
I've read a whole series of pages to see where this problem would fit. On several specific pages you can post simple problems, like the talk page which has no traffic whatsoever, or action pages to simply rename, delete or ... This complex problem transcends them, it is not a simple to do action or policy, more like a whole project. I'm new here, so I wonder how we discuss these complex problems and break them into simple steps like these:
removing all the above flags and flagmaps, except for the first one.svg, to break up the troll relation with Saint-Martin;
renaming the pranksterflag as such: Martini cocktail joke flag.svg (remove the StM reference from the name);
uploading the official French flag in the old namespace, as it would solve most of the problems on the 1001 pages in one go;
using the cocktail flag as an example and reminder on Commons that we should check sources before posting an image ¿is this policy?
...
Do you think this flag is offensive to Saint-Martin inhabitants? Do we have policies to deal with this complex kind of problems? If not, what can we do to solve the problem? How would you reach out to 50? different language Wikipedias? Are there joke categories or pages that would embrace the Martini flag? ...?
Flags that are in fact used on Saint-Martin
Official flags that are used at the border monument, or used to in the past.
border
EU
FR
NL
Ant.nl
StM.nl
On the streets you can see the local government logo and the before 2010 Coat of Arms, the new one is used in local government documents.[2][3]
Another flag that is visable on local photos is a political island unity flag.
The flag maps absolutely need to go; I've just nominated them for deletion. The educational value of flag maps is marginal at best; if we're going to have these images at all, they should only be based on official flags.
The other flags should, at most, be consolidated to a single image with a filename which makes it very obvious that it's a joke. Official-sounding filenames like File:Flag of Saint Martin.png are part of the problem here; they invite editors to assume that the flag has official status (particularly since the same naming scheme is used for real national flags). Omphalographer (talk) 22:39, 19 October 2024 (UTC)[reply]
I had thought about nominating some pretty dubious "flag maps" for deletion awhile ago but they were all in use on other projects and the creator of a DR can't usually remove images involved in it from other projects without people on here crying foul about involved editing or whatever. There really needs to be solution to that though or I don't imagine these types of fake images will ever be dealt with to any meaningful degree. I don't think it's an issue of there being to few users to deal with it though. There's plenty of people on here who are against Commons hosting these kinds of files. It's more the bad faithed personal attacks and obfuscation from the other side that tends to happen when someone nominates in use files for deletion or tries to remove them from other projects before doing so. The same usually goes for the uploaders BTW. They also tend to obfuscate and derail DRs having to do with their uploads. So there's really no point in bothering. --Adamant1 (talk) 04:20, 20 October 2024 (UTC)[reply]
Categorization is another thing to think about. This one for example somehow ended up in subcategories of Category:Proposed flags. I think that category tree should be used for flags that were actually somewhat seriously proposed to become an official flag of something, not merely fictional/parody flags like these? The Category description offers no guidance on this. --El Grafo (talk) 08:39, 20 October 2024 (UTC)[reply]
To some extent, any content can be used for jokes. We can't really edit Wikipedia on behalf of users there.
Totally agree about the Category:Proposed flags. I get in a little tiff with a user once because they thought user created flags should go in the category. Kind of a weird opinion really, but I don't think the category should include user created flags that haven't been proposed anywhere outside of a Wikimedia project. --Adamant1 (talk) 11:33, 20 October 2024 (UTC)[reply]
With the Upload Wizard. You enter the license all the images will share in the first screen. In the second screen where you enter the summary and categories (and depicts statements, etc.), enter this information for the top image, then below there's a drop-down menu (closed by default) to "Copy information to other uploads". ReneeWrites (talk) 01:14, 20 October 2024 (UTC)[reply]
Usage of "on Wikipedia" header for subjects that have multiple Wikipedia articles
To give an example Category:Photography. Maybe it's just me, but that large of an infobox just seems needlessly obtuse and pointless. Especially considering people can find links to Wikipedia articles from Wikidata if they want to. IMO it's not really useful to have a link on our end to every single Wikipedia article having to do with photography though even if some of the articles might be worth linking to. As it just gets in the way of people finding images and categories related to the topic. Thoughts? Adamant1 (talk) 05:21, 20 October 2024 (UTC)[reply]
Both the {{On Wikipedia}} template and the cluster of "sister" ({{Sisterwiktionary}}, {{Sisterwikiversity}}, etc) templates below that seem unnecessary given that the Wikidata infobox automatically displays links to any associated projects in the user's preferred language. This may have been necessary before interwiki links were centralized at Wikidata, but it isn't anymore. Omphalographer (talk) 06:46, 20 October 2024 (UTC)[reply]
Agreed, these are remnants of days gone past. Nowadays, they just add additional clutter and make the user experience less consistent across different pages. I think they can be weeded out without much concern. El Grafo (talk) 08:23, 20 October 2024 (UTC)[reply]
Actually it displays the term in multiple languages which the infobox doesn't. For photography, this isn't particularly interesting beyond the F/PH question. ∞∞ Enhancing999 (talk) 10:45, 20 October 2024 (UTC)[reply]
The infobox automatically translates terms like these to the user's preferred language. If I read the page in English it has "animal" at the top, but if I change my language setting to Dutch, it changes to "dier", and so on. ReneeWrites (talk) 12:25, 20 October 2024 (UTC)[reply]
That's a monolingual approach. Depending on the topic, the preferred language may change. I would generally want to see English and Portuguese descriptions on anything related to Portugal or Brazil. ∞∞ Enhancing999 (talk) 12:28, 20 October 2024 (UTC)[reply]
We were talking about both the template and the infobox. Enhancing999 said he wanted two languages, and defended the use of a template that adds hundreds without filtering them out, because the infobox only does one at a time. That is wildly excessive. ReneeWrites (talk) 15:06, 20 October 2024 (UTC)[reply]
"photography" is obviously pointless as a category name to look for, as it's implied in almost all categories. Besides, the word isn't really any different every language. ∞∞ Enhancing999 (talk) 17:10, 20 October 2024 (UTC)[reply]
Agree and I have already removed such from several categories. Category:Animals is one example where I removed it. Btw, it doesn't seem like it led to a drop in pageviews. The Wikipedia articles of various languages are already linked in the sidebar / the language panel and so redundant in terms of links. When it comes to descriptions and titles for categories in other languages (to make the cat understandable, findable in external search engines, and findable in the internal search engine when for some reason searching in another language), see Wish:Add machine translated category titles on WMC. In short I think all of these boxes should be removed since the Wikipedia links are already in the panel and it clutters the page while pushing its content down. Prototyperspective (talk) 10:47, 20 October 2024 (UTC)[reply]
Well good point. It's a link to a wishlist proposal to be precise. However, a) the motivation and need for it to be implemented would increase if problematic workarounds are abandoned instead of kept which inhibit truly addressing this b) such large headers aren't that useful for that purpose because it's hard to spot your own language text among the many links there and most categories miss these headers. Prototyperspective (talk) 10:59, 20 October 2024 (UTC)[reply]
(a) Yeah, it's true that things that have a half way working community solution might be less likely to be fixed then matters where we just let it be not working, afterall Wikimedia has paid staff for just that part. I doubt we should remove working approaches just for that.
(b) isn't there a feature that highlights that? Personally, I think these are more useful in cases where the language is less known (to me) or the terminology a bit obscure. ∞∞ Enhancing999 (talk) 11:06, 20 October 2024 (UTC)[reply]
Isn't the language thing a none issue if the Wikidata infobox automatically displays links to any associated projects in the user's preferred language anyway? I really don't understand what purpose a list of articles in different languages serves at that point. Especially considering as Prototyperspective points out it's impossible to find an article for any given language in the list anyway. --Adamant1 (talk) 11:12, 20 October 2024 (UTC)[reply]
Other than the layout being suboptimal, it displays actual translations, sometimes more than one (sample: Esperanto/eo). The links are secondary. ∞∞ Enhancing999 (talk) 12:07, 20 October 2024 (UTC)[reply]
The language panel isn't really a substitute. For English language only users, it might be sufficient, but it doesn't really support our multilingual website for other languages. ∞∞ Enhancing999 (talk) 12:18, 20 October 2024 (UTC)[reply]
Apart from all the other things wrong with this, it's manually populated, which is just silly. I've removed it from Category:Photography, along with the duplicative sister- project templates (incusing one linking it to, er, Category:Photography!). We should probably consider a script to mass remove them from categories and galleries; then delete them. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits11:16, 20 October 2024 (UTC)[reply]
I started doing this for some existing instances of sisterlinks and noticed a couple of other category page cleanups which should perhaps be performed concurrently:
Placing templates in a standard order to achieve a consistent appearance.
Would be good if somebody did that and probably the place to request this would be Commons:Bots/Work requests. Probably something should be done to increase the number of people able to and engaged in creating in Commons bots since there's already a fair amount of requests there + a number of archived unsolved requests. Prototyperspective (talk) 19:51, 20 October 2024 (UTC)[reply]
It's a good initiative. I think it would be helpful to first establish what the actual template order should be and what is and isn't suitable for category descriptions before we start initiating a mass editing campaign. Wikipedia has an elaborate manual of style but Commons does not (though I think we could copy a few pages from there). The upside to having established policies is that it leads to clear guidelines, uniformity, and avoids conflict and edit warring. ReneeWrites (talk) 19:56, 20 October 2024 (UTC)[reply]
The alternative to the "sister links" templates is the existing list of links in {{Wikidata infobox}}, as well as the automatically generated interwiki links in the sidebar ("In other projects" / "In Wikipedia"). Manually maintaining a local duplicate of these links is unsustainable. Omphalographer (talk) 20:48, 20 October 2024 (UTC)[reply]
For sister links, Wikidata Infobox might be an alternative. Maybe it can be enhanced to point to other languages. The sidebar doesn't seem to work in general. ∞∞ Enhancing999 (talk) 20:56, 20 October 2024 (UTC)[reply]
It's unclear what or how you think it should be improved. I recently listed 11 issues for MediaSearch and its underlying search algo that is also used in the prior SpecialSearch that you link to here. I think it should show some results of the category you linked to because e.g. it contains the word "work" that you searched for multiple times in its categories, description etc combined with the other terms you searched for. I also think the Commons search should be improved, and one issue that I listed there relevant to your case here is that files in use in mainspace on some or several Wikipedias would be good to display high up in the search results and several/many files in the cat you linked are used. The files in the search results are also used but files in the cat you linked aren't even displayed on the next few pages (or scrolling down in MediaSearch). Prototyperspective (talk) 18:41, 20 October 2024 (UTC)[reply]
Use of "opaque" background request template on photographic images
Hi,
I'm looking for some feedback upon whether or not it is considered reasonable to apply the {{Opaque}} template specifically to an image that was originally a photograph taken against a white background. This template states
"This image was uploaded with an opaque background where it should have been transparent. If possible, please upload a PNG or SVG version of this image, derived from a non-JPEG source so that it has an alpha channel and no compression artifacts (or with existing artifacts removed). If it is not possible to obtain a cleaner version then consider creating a new, derivative, image with the background removed, while leaving this image alone; use templates such as {{Retouched picture}} and {{Derivative versions}} as appropriate; then ignore the rest of these requests."
koavf (talk·contribs) applied this to of one of my images here (which was in turn propagated to a cropped derivative).
An image that was taken as a photograph with no inherent transparency "should" have been uploaded with a transparent background? Really? Are you arguing that every such image "should" have been manually (and painstakingly) worked on to do this before upload? Because that's the only way you're going to get that from a regular photograph.
I reverted the change on both versions, but on the derivative copy, my reversion was undone by Koavf with the argument that
"It's totally valid to have a photographic element extracted from its background to have a transparent one and it's totally normal in a lot of bitmap formats such as PNG. It's not possible with JPEG, that's true, but the photo could be embedded in PNG and have the background removed."
This misses the point. There's a big difference between effectively arguing that it would be *nice* to have a version of this image with a transparent background and (mis-)using a template that states that it "should" have been uploaded like that in the first place.
To me, it seems obvious that this template was intended for images where transparency *already* inherently existed and could be restored from the source, or where it could easily be applied by re-rendering.
"If you [Koavf] are willing to do the hard work [emphasis added here] of Photoshopping it to (convincingly) remove the background yourself, and upload that version as a borderless PNG version under a different filename, please feel free to do so."
The hint clearly wasn't understood or taken. And Koavf didn't, of course, get round to doing themselves the "hard work" they seemed to take for granted the uploader would be magically able to do.
Regardless, by that logic, one could slap this template on countless JPEGs of objects photographed shot against a white background, and it would just end up being similarly pointless and inappropriate clutter because there's no inherent transparency in photographs, and no simple way to add it. If you *want* someone to do that, please don't misuse {{Opaque}} for that reason.
Agree when it comes to photos. However, I have to add that there's now AI tools to easily and quickly remove backgrounds so maybe it actually makes sense to add them now since a few months or in the near future. Search for hugging face remove background to find some Web tools to do so. Maybe something could be done there. The large template seems unwarranted in such a cases however. Prototyperspective (talk) 20:46, 20 October 2024 (UTC)[reply]
@Prototyperspective: Even if that were the case- and there is a place for that- I would disagree with the misuse of the {{Opaque}} template for that purpose.
I'd also disagree that such versions *should* be uploaded- or expected- as the "original" rather than as a derivative and modified version (and clearly marked as such), if only for reasons of veracity. Multicherry (talk) 21:07, 20 October 2024 (UTC)[reply]
Entirely unreasonable. {{Opaque}} is clearly intended to be applied to non-photographic images (like logos or diagrams) which were "generated" with a matte background, and where it's possible for the creator of the image to losslessly regenerate the image from source data without that background. It is not applicable to photos. Omphalographer (talk) 20:56, 20 October 2024 (UTC)[reply]
I don't like the phrasing of the template. It's almost accusatory, like the person who uploaded the image it's applied to made a mistake. But it's used on various .jpg files (files that don't support transparency), where it basically serves as a request for a .png version to be made where the subject is isolated from its background. In that sense I don't think the template was mis-applied, but the wording should be fixed so a request for a derivative version doesn't read like an insult to the original. ReneeWrites (talk) 21:26, 20 October 2024 (UTC)[reply]
For each item in this report there is a flaw in the categorization somewhere creating a categorization loop. This may also be a problem for search results and the deepcategory search operator that can be used to show or search files across a category's subcategory branches.
It is easiest to find a category that should be removed for page 1 where one can simply remove the direct self-categorization. In this example one would remove category "Fungi of Italy" on category "Fungi of Italy". In later pages it's not necessarily more difficult to identify a miscategorization somewhere in the cat-path than in earlier pages. In some cases, a new category is needed or a change in a category description (from where one could link to a category). The same report also exists for Wikipedia categories.
SD0001 who ran the code said Due to the sheer volume of data involved, even the initial step to fetch the list of all subcategory associations from the database was failing both on Toolforge bastions and on the Toolforge kubernetes cluster. I then spun up a 16-core, 32 GB RAM instance on Cloud VPS, and there it all worked out! So the report probably can't be updated frequently. Maybe it could be possible to make it rescan the cats of a particular page and then update just that page but for now it doesn't seem so. Thus, if you work on this report a lot, it would be good to coordinate with other users, for example by removing/striking items from the report if you solved them or making a post on the talk page which page(s) you work on. Prototyperspective (talk) 21:36, 20 October 2024 (UTC)[reply]
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)
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)
Support further development - I think that the potential for abusing AI is something we have to address, but I am going to kindly ask that the details of the proposal should be developed further. Therefore, I support further development of this proposal into a draft policy or something like that. --Minoa (talk) 10:35, 16 October 2024 (UTC)
link to a category
Done with phab:T377656. --Marsupium (talk) 15:51, 19 October 2024 (UTC)
border
EU
FR
NL
Ant.nl
StM.nl
