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/09.
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.
August 29
Category descriptions
I'd like to establish some community consensus on what constitutes an appropriate amount/use of category descriptions. Categories that have to do with North Brabant often have large, self-referential descriptions with all manner of interwiki linking and use of external linkage that is not appropriate, for example Category:Geertruidenberg or Category:Heusden, North Brabant, or any of the places linked in the template above. Compare that to famous cities like Category:London or Category:Chicago, which have minimal descriptions by comparison.
Then there's subcategories. Category:Van Goghkerkje mentions it's at the Vincent van Goghplein 1, 4881 DG Zundert in the municipality of Zundert in the province of North Brabant in the south of the Netherlands. This information is then repeated in almost every single subcategory, including the metacat Category:Van Goghkerkje by year.
Category:Streets in Geertruidenberg mentions in the category description that this subcategory is for pictures of streets in the municipality Geertruidenberg in the province of North Brabant in the south of in the Netherlands. Category:Nature of Bergen op Zoom mentions in the category description that this subcategory is for pictures of nature and nature reserves in and around Bergen op Zoom in the province of North Brabant in the south of in the Netherlands. The category Category:Geography of Moerdijk mentions in the category description that this subcategory is for pictures of the geography in de gemeente Moerdijk in the province of North Brabant in the south of in the Netherlands.
Thousands of categories are like this, almost exclusively those in North Brabant. I'd like to start cleaning these up, but before I do I want to establish community consensus on where the line is drawn when something turns excessive so I know what to trim and what to keep.
My opinion is this:
No repeating of information that can be found in the category name ("The category "Streets of Geertruidenberg" is for pictures of streets of the municipality of Geertruidenberg...")
No repeating of information that can be found in an infobox
No repeating of information that can be found in a parent category
No external linking to personal websites, or other sites that would not be considered reliable sources on other Wikiprojects
Maybe we miss something, but both Category:London and Category:Chicago currently have tons of category description, most can be found elsewhere, compared to Category:Van Goghkerkje. The later mentions an essential point that seems odd to mention without including a basic description before including stating the category name in the description itself.
Not sure how Category:Geography of Moerdijk can be compared negatively to Category:Chicago except when there is some bias involved. Stating the topic in local language(s) is fairly important.
Category:Chicago seems relatively bad as it has a large seal image in the center. It mentions "largest city in Illinois," which is marginally helpful.
I was comparing the categories of Geertruidenberg and Heusden with those of London and Chicago, the latter of which have very succinct descriptions. London's is just one line of text. This is not about the navigation templates.
I think that at least the street description makes sense, because I often treat subcategories of streets as "address-like" categories, so if there's an image of a house at "Peace Avenue 24" I might put the image of that into the "Category:Peace Avenue". But the description makes it sound as if only images of the actual road would belong into that category. Nakonana (talk) 20:55, 16 September 2024 (UTC)[reply]
@Nakonana: Buildings on a street definitely belong in the category for the street. Keep in mind: this is not about ontology, it is about helping users find things. - Jmabel ! talk19:26, 17 September 2024 (UTC)[reply]
It is possible that "24 Peace Avenue" is a protected (historic) building and therefor in many WP languager versions notable enough to get its own article. Therefor photographer might put pictures of this buulding in its own subcategory for users to enable viewing more pictures on the bulding that might be in the article. It would be unfriendly to lead them into a category in which also pictures of other buildings-not-24-Peace-Avenue are contained. Matthiasb (talk) 12:40, 22 September 2024 (UTC)[reply]
@Matthiasb: of course if there is a reason to create a subcat, we should, and photos of that building belong in the subcat. But Nakaona was suggesting that perhaps images of buildings on a street would not to in any category related to the street at all, and that the street category should just be for pictures of the street as such, which is certainly not how it should work. - Jmabel ! talk21:29, 22 September 2024 (UTC)[reply]
There seem to be two types of descriptions (maybe one more popular than others), for a sample Category: "ABC":
1. "ABC" is a ..
2. This category is about media/photos/images related to/about "ABC", a ..
Personally, I prefer (1.), but 2. is not uncommon.
Content-wise, there are three types of descriptions about "ABC":
I agree with Ymblanter, wikidata supplies this info.
In the case, of all things North Brabant wikidata may be insufficient. I more than suspect, what you have here is an editor set in their ways since 2008, who finds Wikidata impenetrable, or even superfluous and persists without it. The cats are cluttered, I agree, and few (if any), will use these links. However, there’s no harm done here.
After all, this is supposed to be a project that anyone can edit.
I've beaten this drum about over complication, before, and I contribute to Wikidata (4000 edits), and it falls on deaf ears.
There's too much of high tech people here, making subject matter complicated and difficult to edit. I'm still waiting for Category:Gartenlaube (Magazine)'s open architecture to be restored. All new uploads there, are incompatible with the established closed off format.
Even today I discovered a source template for a major library that is no longer viable, because the library changed its catalog system rendering our source template into a link to an enormous pile of link rot. I fail to understand how people, make templates or such, then not put in place the mechanisms for continuous maintenance, or just walk away from them. Broichmore (talk) 13:21, 29 August 2024 (UTC)[reply]
I think I disagree with some premises here. Respectively, to the bullet list of opinions given by User:ReneeWrites:
Don't forget the multilingual aspect of this. Repeating the category name in other languages can be very useful.
I get what you say about the infobox, but sometimes a tight piece of prose is easier to skim quickly.
Not everyone will be navigating down the hierarchy. I think it would be ridiculous, for example, for someone navigating up from a village to have to navigate many, many layers up the hierarchy to find out what country it is in.
I could perfectly well accept the last point, with one possible exception: on topics where there is a serious limitation on commercially available material, it can be useful to have a link to a trove of NC content on (for example) Flickr. Not sure whether that is even an exception, maybe more of a clarification.
I'd also add: I think somewhat longer than usual descriptions are often useful for topics not likely to get a Wikipedia article. Example: Category:Court in the Square.
Further: the main problem with the subcats of Category:Van Goghkerkje is that there are this big batch of "by year" categories, mostly with one or two photos, and with little or no differences from year to year to suggest that is a useful way to subcat this. - Jmabel ! talk14:03, 29 August 2024 (UTC)[reply]
Re. "the multilingual aspect" - surely that should be handled by Wikidata? Wikidata already has extensive support for multilingual desriptions of entities, and those descriptions should get pulled in by the Wikidata infobox. Writing those descriptions locally on Commons shouldn't be necessary. Omphalographer (talk) 19:16, 29 August 2024 (UTC)[reply]
Regarding 4, I think this is a good point and a good way to add nuance to the topic. I'm not against removing all external links, though I didn't really clarify what I meant with "personal websites", and I think the exception you mention is reasonable. The website in particular I was thinking of was https://breda-en-omgeving.nl/ which you can find linked numerous times in the categories above (6 times in Geertruidenberg, 7 times in Heusden, as well as many other categories linked in the navigation template at the top). I'll also ping @Prototyperspective: because this is relevant to a thread below. ReneeWrites (talk) 11:45, 30 August 2024 (UTC)[reply]
Support ReneeWrites opinion about it. Although I think Jmabel makes some good points, but I don't see them as mutually exclusive or applicable in every situation. Just to give an example from Jmabel's comment, don't forget the multilingual aspect of this, I'd say it depends on the topic of the category and what level down it is. For instance if we're talking about shoes and the person is browsing through Category:Shoes to find images of them then I don't think it's necessary or helpful to have the word "shoes" translated into every single language possible just because this is a multilingual project or whatever. It's a pretty good bet that most users know what a shoe looks like and has heard the word in English before. So there's zero reason to translate it or to have a description, in English or any other language. "Shoes are things you wear on your feet." No really? We don't need that in English, let alone 10 other languages.
Maybe you'll say that's a bad example since the category for shoes doesn't have a description to begin with though. But there's plenty of categories for extremely obvious universally known subjects out there that have totally pointless descriptions in multiple languages. So essentially I agree with ReneeWrites opinion about it. Although I think Jmabel makes a few good points, but multilingual thing shouldn't be a free pass to create descriptions that are otherwise totally pointless for whatever reason. --Adamant1 (talk) 17:22, 29 August 2024 (UTC)[reply]
@Adamant1: Again, though, you are assuming they got there by following the category tree from a more abstract category. They could just as easily have arrived from a category on an individual photo. - Jmabel ! talk18:51, 29 August 2024 (UTC)[reply]
@Jmabel: Sure, but if someone gets to Category:Shoes from an individual photo of something that's not a shoe then there's other problems involved that categories having descriptions or not has nothing to do with. The only way to deal with people confused about where they are in the category structure at any given time is to categorize images properly. You can't make up for or fix that by putting "chaussure" at the top of a category. --Adamant1 (talk) 18:59, 29 August 2024 (UTC)[reply]
@Adamant1: "other problems involved" Well, yes. And if they are, for example, a Chinese-speaking editor, it would be useful if they don't have to to running way up the category hierarchy to work out that it was an error.
Some of this can be solved if there is a corresponding Wikidata item, but the more narrow the category, the less likely to have a Wikidata item, so the more important mere translation of the category name may be. - Jmabel ! talk19:53, 29 August 2024 (UTC)[reply]
@Jmabel: I don't even disagree with that, which is why the used an extremely general topic like shoes as an exmple. It's certainly a different thing altogether the further down in the categories some goes. I'm not sure what the solution to that is but I still think ReneeWrites' proposal still makes sense with broader topics. Maybe there could be a cavit to it about how to handle categories for more obscure topics though. --Adamant1 (talk) 20:00, 29 August 2024 (UTC)[reply]
More so, they could be a logged-out user who doesn't see any categories displayed at the bottom of the page, because the display of categories is something you need to activate in your settings after you've created an account. Or they could be inexperienced in navigation the Wikimedias. They might not know how to access Wikidata for more information on the subject (because how would a non-Wikipedian know that you need to click that number that starts with the letter Q to get to a page from which you can access the relevant Wiki article in different languages?). Or the non-Wikipedia is someone who's accessing Commons via mobile browser where the Wikidata Infobox is almost completely useless because it only lists the information that is in Wikidata's parameter "instance of" or "occupation" but is otherwise just empty. Nakonana (talk) 21:07, 16 September 2024 (UTC)[reply]
Comment Generally agree except for the point 4. For example a link to a github repo may not be a reliable source at WP but still relevant and useful in a category about the software without a Wikidata infobox. Another problem is that several links in the Wikidata item don't show up in the infobox and something should be done about it there instead of adding a link also to official website (example: links to mediawiki.org in the "Multilingual sites"). Another caveat is that I don't know how Web search engine indexing works and that "No repeating of information that can be found in a parent category" is ambiguous – if you mean useful info that is not self-explanatory should be excluded in a category just because it's already in the parent category then I disagree (e.g. people may have gone directly to that cat from search results or a file instead of having seen the parent cat earlier). Prototyperspective (talk) 19:46, 29 August 2024 (UTC)[reply]
I don't think Github is a very good example. A Github page isn't a personal website, and it's perfectly acceptable to use as a source on Wikipedia (there's even a template for it: Template:GitHub). Github can't be used as a source to establish notability however. ReneeWrites (talk) 08:03, 30 August 2024 (UTC)[reply]
I think it's a good example because it illustrates well how websites considered nonreliable can be very appropriate and useful to have there. You agree that it can be appropriate so it's evidently a good example. That Wikipedia template is about external links, not references. I think it's used sometimes as a reference when the article subject is the software but it's not generally considered reliable. There are more possible examples like a category about some small organization linking to the organization's website and so on. There are many more cases where some website that would be considered unreliable would be very useful so at a minimum one would need to change that part, especially be considered reliable sources on other Wikiprojects, but I think it may be best if this point was removed or turned into a recommendation about what is usually (instead of always) the case. I'm still unsure what is meant with repeating info already in parent cat. However, I haven't seen any cases of such anyway but it doesn't seem like a good requirement. Prototyperspective (talk) 10:22, 30 August 2024 (UTC)[reply]
Support Most of what has been said before. Thanks for starting this discussion. Maybe the four points of ReneeWrites just need some nuance. My remarks:
This does not concern only categories about the province of North Brabant, but for many location categories of the Netherlands. I have seen many of those descriptions elsewhere too.
For me they are redundant and annoying, but I am not the target group: perhaps to occasional visitors they might give useful information, especially if they are foreigners.
To limit obvious redundant information: No repeating of information that can be found in an infobox. But then there should be a Wikidata infobox. For subcategories like "in" categories (for countries, "streets in" and so on) and years, there usually are no, and should not be either (except for when there is a Wikipedia article).
I prefer "ABC" is a .. as well. The shorter, the better.
I agree with Jmabel: Repeating the category name in other languages can be very useful. Ever since I discovered in an English discussion about a Dutch subject that a Dutch participant had trouble discussing in English, I translate categories about the Netherlands into Dutch (unless there is a Wikidata item or it is a "by" category). And sometimes there is more explaning to do because the English word has no equivalent in Dutch (see for instance Category:Estates in the Netherlands) or the English word looks like a Dutch one, but means something else.
So in general:
Every topic category should have either a Wikidata item or a description. Exceptions: if the category name is about a universally known subject (like "shoes"). In case of doubt: add a description in English, other languages are allowed too.
No repeating of information that can be found in a corresponding Wikidata infobox.
If there is no Wikidata item: Add descriptions to categories for countries that are not native-English speaking countries, preferably in their native language.
Keep descriptions as short as possible. Add a link to the corresponding Wikipedia article in the native language if that is appropriate (especially in case of country categories). You may add links to other relevant websites that you trust if there is no Wikidata item and the website is within the scope of Commons (no avertising, and so on).
Repeating of information that can be found in the category name ("The category "Streets of Geertruidenberg" is for pictures of streets of the municipality of Geertruidenberg...") should be avoided as much as possible. But sometimes it can be useful, even in this case: Geertruidenberg is a municipality AND a populated place. It is good to know for which one the category is (though it would be better to have it in the category name).
BTW, if anyone wants to see a good example of major overkill when it comes to a category description check out Category:Louvre Museum - Room 185 and scroll down past the infobox. I assume everyone here would agree that something like that is way to excessive. --Adamant1 (talk) 05:49, 31 August 2024 (UTC)[reply]
Not only is that wildly excessive, it seems like an unreliable basis for categorization. The museum can reorganize their collection; Commons shouldn't have to shuffle a bunch of categories around (or argue about what objects used to be where) when that happens. Omphalographer (talk) 06:15, 31 August 2024 (UTC)[reply]
Category instructions
There are descriptions, but sometimes instructions are also usefull. Examples: Category:Rail vehicle doors: Please place images of closed train doors only if they are prominent. All passenger trains photografed from the side have train doors. There are subcategories for open doors. Other example: Category:Rail vehicle sliding-plug doors: The door slides outside the vehicle by closing is pulled in at the last moment inside (plug). There is no supporting structure outside the dooropening and a closed door is flush with the vehicle surface. animation and rail door systems. This category is sorted by country. (Spain and Sweden under the letter 'S'). Train material door types can be determined as soon as there are enough good examples of 'open' doors to classify. In the Commons the definition of train doors is broader than in the NL article nl:Treindeur. Outside doors not used by passengers are excluded (for example drivers or loading doors) or aisle doors.Smiley.toerist (talk) 13:45, 6 September 2024 (UTC)[reply]
Coordinates
I just want to add one aspect or make it clear as it is already contained in No repeating of information that can be found in an infobox. Object coordinates should not be added to categories / should be consolidated and removed, if any. --Herzi Pinki (talk) 22:32, 6 September 2024 (UTC)[reply]
@Herzi Pinki: can you point me to anywhere that was decided as policy? Last I remember this being discussed (a few years ago) the opposite conclusion was reached: that it was useful to have Commons and Wikidata both contain location information, because the duplication was very useful in identifying possible vandalism, since a bot would notice the discrepancy, allowing for easy review. There could well have been a change, but if so I missed it. - Jmabel ! talk14:04, 7 September 2024 (UTC)[reply]
No, nothing has changed. We don't trust. But I just wanted to point out that as a consequence of the above No repeating of information that can be found in an infobox, this will also affect the policy on coordinates. best --Herzi Pinki (talk) 14:40, 7 September 2024 (UTC)[reply]
The above is discussion is a bit odd, because it says that and people agree that including samples that do exactly the opposite. Go figure. Except when it's translated into Dutch. So local languages are ok, except Dutch.
Actually, it's a mistaken assumption about coordinates that the infobox offers the same. Some users might find some parts of it, most don't that see that. I think we discussed it before. Obviously, we could integrate coordinates better in the interface. ∞∞ Enhancing999 (talk) 20:03, 7 September 2024 (UTC)[reply]
The Wikidata Infobox information is not visible to mobile users. The coordinates from an object location template, however, are visible in mobile browser. The whole Wikidata Infobox things just doesn't work for mobile users, and if I remember correctly, most users are mobile users? So we shouldn't rely too much on that infobox. Nakonana (talk) 21:17, 16 September 2024 (UTC)[reply]
If indeed Wikidata Infobox doesn't work for mobile users, that would be a clincher to keep the geocoordinates explicitly on the category page. - Jmabel ! talk19:28, 17 September 2024 (UTC)[reply]
If you want to check it out, here is a category that has the object location template in addition to the Wikidata Infobox template with coordinates. I checked with Firefox mobile browser and a Chromium based mobile browser, and the only visible coordinates are the one of the object location template. Nakonana (talk) 21:37, 17 September 2024 (UTC)[reply]
It looks as though this is a deliberate behavior - Module:Wikidata Infobox#L-218--L-220 intentionally hides infobox rows on mobile devices unless it's specifically directed to show them. Want to start a discussion on its talk page about changing that?
As an aside, the combination of the Wikidata infobox and the object location template is really unpleasant on desktop. The object location creates a horizontal "wall" across the page which pushes all of the category contents below the infobox, which can make the page look empty if the infobox is large. Omphalographer (talk) 23:35, 17 September 2024 (UTC)[reply]
How does one specifically direct it to show the rows as a user? The infobox only has a "collapse" button, but no "expand" button. It would certainly be helpful if one would at least have the option to expand the infobox on mobile. Nakonana (talk) 00:22, 18 September 2024 (UTC)[reply]
I would appreciate a typical sample image for each subcategory to ease correct assignment to subcategories. Of course not for standard subcategories like 'Views of', 'Nature of', 'Buildings in', etc. This should be done by marking an image of the subcategory in a suitable way (by a dedicated cat, by QI?) and done automatically when generating the category pages. best --Herzi Pinki (talk) 18:13, 9 September 2024 (UTC)[reply]
Maybe there could be a gadget that shows an image when hovering the subcat (for longer than 0.2 s). However, I think showing four images instead of just one would be best. For categories that are linked to a Wikidata item, selecting a typical representative fairly high-quality is simple: the one(s) that are set in the image property of the item. However there are many categories without Wikidata item (or with item but no image set there). In regards to your use-case however, the category title should be fairly self-explanatory so I think the use of that would be quite limited (but this and other potential usecases could still be useful enough for having some gadget that enables that). Prototyperspective (talk) 20:25, 9 September 2024 (UTC)[reply]
Don't take this the wrong way, but what's the ultimate end game here and how exactly does it relate to the topic of the discussion, "category descriptions"? Because I really fail to see the connection between that and your suggestion for a gadget that shows an image when hovering the subcat. I don't think anything ReneeWrites said in their original comment would be negated or effected by your idea. --Adamant1 (talk) 00:58, 10 September 2024 (UTC)[reply]
Open the category in a mobile browser and see the difference between how helpful the Creator template is in contrast to the quite useless Wikidata Infobox. Nakonana (talk) 21:22, 16 September 2024 (UTC)[reply]
That seems like something that should be resolved regardless of if there's creator templates in categories or not, but at least IMO creator templates are totally pointless and just get in the way when they are being used in categories. I don't think that's what they were created for either. So should really just be gotten rid of. Sucks for mobile users sure, but if I were to guess most mobile users don't find images through categories anyway since they don't show up on mobile to begin with. There's no point in having a feature for a non-exiting costumer. Especially if its screwing up everyone else's experiences in the meantime. --Adamant1 (talk) 21:40, 16 September 2024 (UTC)[reply]
Categories do show up for mobile users who are logged in. And the Creator templates does show up for mobile users who are not logged in, too. The infobox doesn't show up no matter whether logged in or not. Ultimately, it's just that the Wikidata Infobox template should be adjusted to work for mobile users. That would definitely render the Creator template redundant, and also solve other problems. Nakonana (talk) 22:14, 16 September 2024 (UTC)[reply]
No, I haven't, I'm not familiar with Wikimedia venues to report stuff. But I think that they are already aware of the issue because the infobox you currently see is actually the improved one. IIrc, a few months ago, there was no infobox at all when using mobile browser. Now there's at least an incomplete one. Nakonana (talk) 23:31, 16 September 2024 (UTC)[reply]
Well at least it sounds like their working on it then. It would suck if we decided something now based on the infoboxes not showing up if their just going to fix it at some point. --Adamant1 (talk) 00:50, 18 September 2024 (UTC)[reply]
September 07
20@ Wikimedia COMMONS
🎉 HAPPY #20 BIRTHDAY WIKIMEDIA COMMONS & COMMUNITY !
(not as widely popular or loved as Wikipedia or Wikidata,
but hopefully worth fixing, updating and making sustainable,
if not advancing where no media server has gone before)
We really should mention this on the homepage and we should have had birthday-related media spotlighted. This reminds me of when we hit 100 million files and no one really seemed to care. :/ —Justin (koavf)❤T☮C☺M☯15:35, 7 September 2024 (UTC)[reply]
Is it too late to temporarily change the logo and maybe have it link to somewhere? Is there any press reporting about this like they do for Wikipedia anniversaries? Prototyperspective (talk) 21:41, 13 September 2024 (UTC)[reply]
It would be nice to celebrate a few anniversary days or weeks, even if starting after the actual anniversary day.
not as widely popular or loved as Wikipedia or Wikidata: I think it's because most people don't realize that the vast majority of images in Wikipedia actually belong to Commons. Wikipedia wouldn't be what it is without its media. If all projects were viewed as a single whole (almost all media in Commons, even if not used in any article, can be viewed as an extension of some Wikipedia article, and the same for any citation in Wikiquote, any book in Wikisource, any contributor-made book in Wikibooks, any travel guide in Wikivoyage, etc), Commons and other projects would probably be much more noticed. I am not against each project's own personality, but I am against any kind of rivalry between them. If it was better for the Wikimedia ecosystem and the dissemination of knowledge, I'd have no problem if Commons was renamed to "Wikipedia Media Repository" and Wikisource to "Wikipedia Library", for example. MGeog2022 (talk) 11:06, 14 September 2024 (UTC)[reply]
Don't think there's any kind of rivalry between them. Zblace I think WM Commons is far more popular and used way more than Wikidata. I'm interested in real usecases of Wikidata beyond linking Wikipedia articles and the infoboxes but for WMC there's lots of use-cases such as people coming here to find images for their videos (often starting on Google Images due to which addressing it not properly indexing most media here is a key problem and I wonder why noone is addressing it except for a user writing this proposal). Prototyperspective (talk) 11:47, 14 September 2024 (UTC)[reply]
Yes, I was surprised when reading that Wikidata was more popular than Commons. I doubt Wikidata has many direct human readers, but maybe it's popular to get machine-readable information with automatic systems. MGeog2022 (talk) 12:22, 14 September 2024 (UTC)[reply]
If you or somebody else knows of any applications (not for demo purposes but actually used), please let me know. It can't be used to get data about studies (far more incomplete than OpenAlex & ScienceOpen) or books (Anna's Archive) or foods (see this and OpenFoodFacts or propriety MyFitnessPal) or films (eg IMDB) or music (MusicBrainz etc) or chemical ingredients (CodeCheck) or anything else where data repositories are currently used in society. Prototyperspective (talk) 12:27, 14 September 2024 (UTC)[reply]
@Zblace: What a wonderful citation. I'll complete it:
«Space: the final frontier. These are the voyages of Wikimedia Commons. Its twenty-year mission: to explore strange new worlds, to seek out new files and new contents, to boldly go where no media server has gone before.»
«Spazio, ultima frontiera. Eccovi i viaggi di Wikimedia Commons durante la sua missione ventennale, diretta all'esplorazione di strani, nuovi mondi, alla ricerca di altre forme di file e di contenuti, fino ad arrivare là dove nessun media server è mai giunto prima.»
Is there some policy about how book scans are to be handled? I think it would be best if books and similar literature were uploaded as one PDF document rather than as many scattered separate image files.
This way one can easily download or read them / go through pages and they don't clutter search results or require subcategories for just one literature item. For scans already uploaded, a bot could convert them into PDF files. One can also embed single PDF pages like an image on Wikipedia so there's not really any disadvantage to converting them to document files. Exampleexample. --Prototyperspective (talk) 17:22, 7 September 2024 (UTC)[reply]
How about we leave them as the projects that are using them are uploading them? One may be able to embed single PDF pages, but I don't know how, and it's hard to find the appropriate illustration pages. Not to mention that PDFs use compression, and if the originals were PNGs, converted to JPEG2000 for the PDF, and then converted to JPG for Commons, that makes worse final images than directly working with the original scans.--Prosfilaes (talk) 18:19, 7 September 2024 (UTC)[reply]
I described several reasons why not to keep them as people and projects upload them. Moreover, they could change how they upload them. Scans of one page of a book are nearly never used on a Wikimedia project and when they are used often having the full book available at the page would be much better and useful. How to embed a specific page of a PDF is described here: Help:PDF#Page. As for quality they could be converted without loss of quality and it doesn't have to be PDF files if there is something better. Prototyperspective (talk) 18:24, 7 September 2024 (UTC)[reply]
With a command that converts losslessly. Maybe ImageMagick's convert ./page*.png ./output.pdf already converts losslessly and somebody should check if that is the case. Prototyperspective (talk) 13:20, 8 September 2024 (UTC)[reply]
I am not against merging into a pdf or djvu file, but as pointed out previously book illustrations can be used by other projects as well as the title page to illustrate the Wikidata entry. --RAN (talk) 20:51, 7 September 2024 (UTC)[reply]
Can one not specify the page of a PDF document on Wikidata for the image/cover property? Maybe that functionality can be added. Then people could also upload the cover or a particular image separately rather than uploading a whopping 300 files for one book. That is also useful because the title can be more descriptive and here is an example of an image from a PDF file that is used on Wikidata...it's much better than having the image just as some whole-page generically titled document scan image. Prototyperspective (talk) 21:04, 7 September 2024 (UTC)[reply]
As far as I'm aware, the default thumbnail for PDF/DjVu documents is always a thumbnail of the first page. Which is a shame; there are a lot of books where that page is a Google Books notice, or an image of a badly damaged cover. Being able to override that with a thumbnail of the title page would be a huge improvement. Omphalographer (talk) 21:33, 7 September 2024 (UTC)[reply]
@Prototyperspective: I feel like the benefits of something like this would depend on the subject of the book. Like if its mainly or only text, cool. Convert it into a PDF and get rid of the JPEGs. There's of books with photographs or illustrations of historical subjects and places where it makes sense to have individual images. And not just for other projects but in general. Its kind of redundant to have individual images for books that are purelu text though but I think they are easier to transcribe for other projects that way. But I'd still argue its pointless (if not against the guidelines and /or goals of the project) to have jpegs of individual pages that are purely text on our end. --Adamant1 (talk) 21:22, 7 September 2024 (UTC)[reply]
I tend to agree with the idea that it should just one file, but PDF support hasn't really gotten better. It's actually somewhat broken and even the WMF person in charge of Commons has no idea if or when it's going to be fixed. ∞∞ Enhancing999 (talk) 21:49, 7 September 2024 (UTC)[reply]
Weak oppose Maybe for type-written works it makes sense to only have a PDF, but for hand-written it's often really useful to have higher-resolution files and if they were combined into PDFs the PDFs could be quite large. A small example could be something like this where it's often useful to be able to zoom right in on a letter to better see the pen strokes etc. It's also more likely that people preparing PDFs will end up with trusting whatever their scanner software gives them and by doing so be throwing away information that we'd rather keep (e.g. postmarks on letters). I wonder if more could be done with the search system and structured data to make it easier to exclude individual scans? SamWilson04:47, 8 September 2024 (UTC)[reply]
Maybe a Wikidata property for scan quality or something that could be used to push bad quality PDFs and images down in the search results? I've been wanting something like that for awhile now to suppress crappy scans of postcards from the search results. --Adamant1 (talk) 05:02, 8 September 2024 (UTC)[reply]
Good call. I didn't know that existed. Although the "for original size" thing seems a little needless, but whatever. I don't see why it wouldn't work. --Adamant1 (talk) 05:26, 8 September 2024 (UTC)[reply]
If you have poorly printed pages, where OCR does not work, pdf is not an usefull format. For the Category:Journal de Bruxelles, I scan most pages, two at a time folded open. I have a standard naming principle for the files. In Wikisource the pages have to be manualy typed over as the OCR does not work. A lot of work, but a usefull result.Smiley.toerist (talk) 11:16, 8 September 2024 (UTC)[reply]
Comment I've been working on Category:Helix (newspaper). If these had been PDFs, I'd have had to extract files for almost every page to document them decently. Yes, there are probably times whe PDFs are best, but it's not a universal. - Jmabel ! talk12:15, 8 September 2024 (UTC)[reply]
Comment something I find suboptimal with individual pages is that {{Book}} doesn't really seem to be adapted for it. Also, when actually using elements from a page, one generally needs to do another crop just for that part. In the end, that part and the original page might end up categorized for that content. ∞∞ Enhancing999 (talk) 13:23, 8 September 2024 (UTC)[reply]
Remember nothing actually gets deleted, so we are not saving any space. We also have had the case where a page was missing, a page was out of order, or a page was upside down in the pdf, and we had to recompile the file. Perhaps if all the individual pages were in a folder there would be less clutter once the pdf was created. --RAN (talk) 18:01, 8 September 2024 (UTC)[reply]
It's not about space but about clutter. It also causes misleading upload stats and clutter the UploadedFiles page. The main issue is the clutter in the search results and from views that e.g. combine categories. The many subcategories are also clutter. Then it's also hard to download the file and a main problem is that it's hard to read a document if it's in dispersed pages instead of in one document. And I think this also applies to old 1800s drawings of organisms which are not really useful anymore, not what people look for, and for which there are now high-quality photos & illustrations. If an image is needed one can specify the page of the PDF or extract an image (that is different from a whole page) from it. Prototyperspective (talk) 18:21, 8 September 2024 (UTC)[reply]
This also applies to old 1800s drawings of organisms which are not really useful anymore, not what people look for, and for which there are now high-quality photos & illustrations. I strongly disagree with this. You have made the common mistake of assuming that what you find useful or interesting is what other people also find useful or interesting, and what you find irrelevant or annoying is what other people also find irrelevant or annoying. For some users of the Commons, "old 1800s drawings of organisms" are in fact more useful than modern photographs, and individual page scans are more useful than PDFs, especially if PDFs of the same public domain documents are already widely available from Google Books, Internet Archive, Hathi Trust, and other repositories. We all use the resources here differently, and the specific resources you like to use and the way you like to use them are not universally shared. There may be good reasons to consider changing the way that multipage documents are handled, but generalizations about "what people look for" based solely on your own preferences are not among them. Crawdad Blues (talk) 20:00, 8 September 2024 (UTC)[reply]
No, I did not make this mistake – maybe I have made this mistake of not clarifying which of my statements are a statement of opinion/argumentation. It's not surprising that there are users who think so since there are users who upload such images particularly as separate pages and with that sentence I was addressing an earlier comment arguing it would be good to do so for images that contain images. These users are very few and I have yet to see any actual usefulness case / application of such images. It's great that we have them on WMC, but I don't see why having them in separate scans would be reasonable. Please make a survey or look at pageviews or explain specific use-cases with examples if you think what I said is wrong. Prototyperspective (talk) 20:17, 8 September 2024 (UTC)[reply]
(With such images I was referring to separate pages as scanned page image files, not whether or not these files are on WMC.) This proposal is mainly about documents with text that include images, not documents which contain only drawings as a page. I think an example of a WMC search that shows mostly scans of a few books and burying what most users are looking for is needed to illustrate what I mean. Here's a bad but maybe still useful example: if you search for "animal" there is an undue number of scans from Category:The animal kingdom, arranged after its organization, forming a natural history of animals, and an introduction to comparative anatomy (1834) at the top instead of higher-quality drawings/artworks and photos (like the collages at the very top). They can be useful but often inaccurate unreliable 1834 drawings are usually not what the user can use for any of the purpose such as adding them to a WP article or illustrating the species. These images (the book) are still useful and it's worse for other searches. Prototyperspective (talk) 20:35, 8 September 2024 (UTC)[reply]
I agree with Crawdad Blues: images of images from books (and other documents), like drawings, prints and photographs, should stay and be images: one in a file. Then they are easy to reuse and then end users do not have to go through the upload process, but can directly use the file. For a type-written, printed book that primarely is about text: yes, then a PDF file is easier, for searching within the text and to leafing through it. JopkeB (talk) 05:17, 9 September 2024 (UTC)[reply]
It depends a lot on each specific case, but, if uploading a new book, I think PDF is the best option. If the book contains images that are interesting in their own right, they should be uploaded as separate files (or even be left for another user who is specially interested to upload them, if you don't have time for it). For already uploaded books, I think that existing images should not be deleted, but creating a new PDF book can be a good idea.
I think Commons, for some cases, can be a good book deposit/library, in addition to Wikisource (with OCR or some freely licensed or public domain original PDF books, you can even have machine-readable PDF books in Commons with relatively little effort, while migrating their content to Wikisource can be a really big work in many cases). MGeog2022 (talk) 10:51, 10 September 2024 (UTC)[reply]
You cannot migrate PDFs to Wikisource for the reason that you can't upload any files at Wikisource. (As in: there is not an upload page at all). Wikisource does not host any files. It's Commons what is intended to be used. Matthiasb (talk) 07:12, 17 September 2024 (UTC)[reply]
while migrating their content to Wikisource can be a really big work in many cases: by this, I'm talking about converting them to wiki format. In those cases that converting them to wiki at Wikisource is too much work, the full book could be hosted at Commons as a single PDF file, even if it (its content, not the PDF file as such) is never migrated to Wikisource. MGeog2022 (talk) 13:15, 17 September 2024 (UTC)[reply]
Oh, I understand. For this case the different language versions perhaps have different policies. I don't know about other than the German WS. In the German WS we differ between texts which are digitized available. Some users collect any link to GB, IA, (university) libraries, Haithi Trust where a scanned work by a German language author is available wether it's a PDF or some other file format. When a user wants to transcribe a text a copy of the original at commons is requested so that other can verify and correct the transcription. A reader-only would not use commons but the original link to Google Books, Internet Archive and the like, of if the transcription is complete, rather to the transcprited version at WS since it might be better to read than a possibly bad scan. See for ex. s:de:Justinus Kerner showing both cases. Matthiasb (talk) 22:44, 19 September 2024 (UTC)[reply]
Well, I was talking about the case that the user wants to upload the public domain or freely licensed book to Wikimedia, but without converting its full content to wiki format. Maybe we aren't a host for PDF books if they aren't to be converted to wiki format at Wikisource, and Internet Archive is the right place for uploading and viewing PDF books. I don't know the exact Commons policy on this. MGeog2022 (talk) 12:58, 20 September 2024 (UTC)[reply]
Oppose Strongly opposing. If such PDFs would be converted one (the person converting it) would have to make sure that each and every Wikisource page would work as before. If we have 300 pages in the PDF that makes 300 pages on WS to be changed. I am not sure about wether they are needed to be modified only on one place; this Wikisource techniques/syntaxes are quiet obscure to my though I am taking part in the project. So what would be achieved? Editing tenthousands of Wikisource pages to reduce the number of PDF files for several ten thousands whereas we are hosting 120 million files on Commons? Produces lot of server load for nothing. --Matthiasb (talk) 07:02, 17 September 2024 (UTC)[reply]
Not this proposal. I don't think you're voting on what is proposed here – at least it seems like that from your rationale. This is about people uploading at times hundreds of images instead of one PDF file to WMC. It doesn't have to do with Wikisource. Those images are not used in Wikisource if that's what you mean. Prototyperspective (talk) 09:52, 17 September 2024 (UTC)[reply]
I think so. If one finds a PDF file on GB or in internet archive or a haithi trust he will keep this PDF together. We not need to diskuss that. There is a difference if the user does the scan himself. Fox example my scanner is capable to scan several pages in a row but never ever I would scan 300 pages in a row. The phone might ring or another interruption would occur. There is no chance to get more than 20 pages or so in a row in one PDF with my Canon. And after the scanning, I don't have the software to combine it and if I had my hardware won't make it due to hardware restrictions. My machine is about ten years old, you understand. Or I even have another image file format, jpg or tiff. Matthiasb (talk) 22:01, 19 September 2024 (UTC)[reply]
Nonsensical. Really absurd at this point. Just use some software to combine images into a PDF file which also works on very old PCs. Takes a minute maybe and you don't necessarily have to do it yourself. That's better than cluttering the search results here for example. Prototyperspective (talk) 10:38, 20 September 2024 (UTC)[reply]
Weak support If a complete book scan of x-dozen up to some x-hundred single text pages gets uploaded, and is not in use for Wikisource (!), then I think that all the pages can be collated into a single PDF, which can then replace the single-page scans. Note that my opinion states "can", not "should". It depends on the intended use case and the interest that gets placed on a book. If all single-page-scans remain contained in their intended scan-category, I have no problem with them being loose, not bound. Also, I checked the first example in the OP again: yes, these are single-page scans, but only of the 37 illustrated pages from a 200-page book. For a PDF, we need to have all pages; while the ones in the category should have the text clipped away, to make the images usable as illustrations (Edit, upon rereading, this point was also made by Adamant1, so I support that opinion). On another hand, if PDF-conversion means OCR treatment is simpler, then I'll strongly support this. --Enyavar (talk) 13:45, 20 September 2024 (UTC)[reply]
September 10
Proposal for a path forward for bringing together folks with a stake in Commons’ future
While at Wikimania, I was able to spend time with folks who participate in and contribute to Commons. I attended the Photowalk community session, where we had a lovely and rainy meander along a brick lined city walkway, where we saw lots of iconic buildings and neighborhoods in Katowice, as well as a lovely park and views of trains and city life. I also was able to sit down with 10 people attending Wikimania who I’d previously met and talked with me about Commons, or who had discussed my recent comments on-wiki about the future of Commons and some of the big challenges and questions we face and need to tackle together.
In that meeting, I spent a lot of time listening to perspectives and the challenges that technical contributors, photographers, organizers, GLAM advocates and individuals just representing themselves each see as we try to determine what next steps to take.
I asked the group to help me think about what comes next, and how to work together to bring the many parts of Commons together in a meaningful way, so that we can start to make some important decisions together. Any choice we make will involve tradeoffs – of attention, time and resources. And I’d like us to all be able to do that with as much information as we can bring together and put on a shared table as possible.
Some of the perspectives I heard included:
The Wikimedia Commons Query Service doesn’t work very well and needs focus.
Wiki Loves contests attract a lot of attention, but haven’t been optimized for getting new contributors. Things like licenses, templates and other complexities might be significant barriers to new contributors. Other sites don’t have such complex workflows and maybe attract new folks much more easily.
Each time a project starts and ends, we lose important knowledge because we don’t have continuity across projects or anyone really working to ensure that we have continuity over time.
Some projects focus on small batch uploads, and other projects focus on doing very large batch uploads. The disconnect in approach and goals may be problematic when trying to prioritize where we focus attention and effort, particularly from the WMF.
We don’t have clarity about which tools should be used for producing, reusing, finding and reporting photos, and some tools that have been made don’t have enough functionality to be truly useful and to replace older tools.
There's a tension between admins and patrollers asking for more things to prevent vandalism, but also campaign creators who want lower barriers to entry. We also have the tech communities with needs for APIs, Commons embedders who would like different features on other projects, and yet more needs from photographers user groups, GLAM professionals, and external reusers. We asked: how could we go about helping these folks see each other, and help everyone understand some of the tradeoffs involved in supporting such a complex project?
In listening to each other, people remarked that they could see how different people’s perspectives were, and also that there were perspectives not represented in the room. We spent some time trying to name them, and discussed what a good next step might be to try and help one another come to some conclusions about how to best prioritize the limited resources of the Foundation, and how best to ask for help from the whole of our movement.
As a result of this discussion, several people suggested that regular meetings that helped to surface and then explore the challenges we now face among Commons contributors and users would be really helpful, with the intention that this will lead us to identify key strategic trade offs.
We have a wide variety of tools ranging from very specific to very general, and we have many sub-communities with different needs and agendas. The Foundation and contributors all need to understand this landscape in order to plot a way forward together.
So my proposal for the next year or so is to start having monthly forums, where we pose some of the big questions around Commons, and come together as a community. I think this will involve a live discussion as well as on-wiki discussions to get to the heart of some of the big tradeoffs and questions that we all need to face together.
I am committed to finding a better way of supporting Commons, and I see the need to get to a shared goal and a timeframe for achieving a clear set of things. And I will need help from all of you to identify the most important problems to solve, which ones not to solve right now, and then the right kinds of solutions for supporting a vibrant Commons into the future.
@SDeckelmann-WMF, maybe some things I said in my comment here are of interest to you when requesting resources for Commons at WMF. Maybe some improvements to Commons can be seen as secondary, but Commons as a whole in no way is so. Unlike other WMF projects (all of them important as they are), Commons content is continuously shown in Wikipedia articles themselves, so Commons is, in some way, truly part of Wikipedia, without question. MGeog2022 (talk) 11:18, 14 September 2024 (UTC)[reply]
I'm definitely interested in participating in monthly forums. I would suggest that rather than have them at the same time of day each time, we might want have them at different times of day from one month to another and post the schedule very publicly, because Commons is such a globe-spanning project, and any time of day we picked is going to be very inconvenient for a significant number of people who might like to participate. - Jmabel ! talk15:56, 16 September 2024 (UTC)[reply]
Hi, My main general worry is that Commons workload is increasing, and there are new legal, technical, and social challenges, but there is no increase in the number of people to maintain this all. Specially the number of administrators is decreasing. The challenges include AI-generated images, new kinds of media (Commons:Project scope/Allowable file types: 3D rendering, video was marginal, but is now mainstream, etc.), the huge complexity to understand, document and maintain the legal information, etc. Commons is in a way victim of its success. People confuse Commons with social media. It was a small project nobody really cared, and it seems to have become the place to advertise companies and people. We now delete as many out-of-scope content and selfies as copyright violations. The formers were just a small percentage of deletions a few years back. I have suggested several times a recruitment campaign for admins and patrollers. The WMF could help organize crash courses on copyright. Moreover I think more people would volunteer if they feel supported by the WMF in one way or another (better tools, less bugs, fast answer to technical issues, etc.). Yann (talk) 17:41, 16 September 2024 (UTC)[reply]
Thank you, @SDeckelmann-WMF for putting forward this proposal. The Wikimedia communities, and not the least the Wikimedia Commons community, have plenty of different workflows, priorities and purposes. Putting all our brains together we'll probably find common ground, identify recurring needs and come up with well-informed proposals for improvements. In my mind, a clarity on the different positions of the different stakeholders is already a useful first step. – Susanna Ånäs (Susannaanas) (talk) 19:00, 18 September 2024 (UTC)[reply]
I was in the Wikimania meeting and just wanted to add one of my takeaways. Part of the challenge for the WMF are, as alluded to above, the diverse stakeholders who rely on Commons and often have different or even conflicting priorities. Selena said that, once we can identify stakeholder groups, if those groups come together to produce a list of priorities (features, fixes, etc.), someone at the WMF will go through the lists and respond to each item -- what can be done, what needs more information, and what won't be done for reasons xyz. To me, that commitment was the most noteworthy action item for the community. So we have to figure out these stakeholders and then those stakeholders need to self-organize and produce a list. Maybe a good use of the first monthly meeting is to brainstorm stakeholder groups. — Rhododendritestalk | 21:46, 16 September 2024 (UTC)[reply]
I think this is a little bit short-sighted. "Stakeholders" or even hypothetical organized groups thereof often don't have much insights into and experience with Wikimedia software. They don't have an inside view of what could be possible, what may be very useful and so on. I'm not saying that this wouldn't be valuable, just that this would only be half of the equation if at all. Be aware that with "stakeholders" that's random people somewhere in the world using Wikimedia Commons to find media for their educational YouTube video, some teacher looking for materials, a Wikimedia contributor looking for some image to use in some poster, a Wikipedian looking for media to include in a new article, and some journalist looking for an image to use in low-budget news article. Nearly none of these are organized and most would probably not provide well thought through proposals.
Furthermore, there actually already is a list of priority features and fixes – there could be more and some are included in the current Community Wishlist but I don't see any justification for it not getting considered deeply by the WMF: Commons:Requests for comment/Technical needs survey. I don't think the key problem or bottleneck is 'unclear wishes', 'conflicting priorities' or any of that sort. The problem is a lack of will in increasing capacity for implementing any of widely requested features such as via more funding for development and/or a banner campaign to get more volunteer developers engaged. Monthly talks may be useful but I suspect it would likely overall be a waste of time with little productive things coming out of it – in the end more time spent on things other than actually implementing things. Once there is some ongoing work on implementing things and some capacity, one could still have monthly talks for the time when well-known issues have been solved. @ Yann to reduce workload one could start by implementing bots that automatically identify likely copyvios or likely vandalism and similar things (like auto-addition of inferrable categories) which is another thing that requires some will for technical development. Prototyperspective (talk) 22:54, 16 September 2024 (UTC)[reply]
I was in many of those meeting at Wikimania,at @Ymblanter: yes video was discussed and identified as a choke point that we WMF support to work on. Firstly was the need to make reviewing, identifiing, and address issues within recordings much easier with support tools. The secondpart of that was once there were working tools was to look at formats and ease of putting videos under a free license. We are also challenge in who has what rights, audio tracks, interpretations of content, this really is complex area that needs its own skill set our saving grace is that video isnt as popular as it could be within other sister projects so the demand isnt there but its on the horizon as more people are becoming familiar with creating videos. @Prototyperspective: Commons and other sister projects attract people who dont have technical skills those people have skills that are equally important in creating Commons. So yes you are right we of the nontechnical incling dont know the capabilities of the software, or any limitation but we do know what we'd like to see possible in the future across many other areas excluding stakeholders for any reason isnt the solution either. Selena is engaging in meaningful way and useful way to ensure tated he WMF knows what commons is, where commonalities of people who are building differents part exist, where there are gaps in capacity. Commons has for sometime lacked a large cohort of software developers who were attracted away to other more recently created sister project. I agree Bots that flag potential copyright vios would help and speed the processes up especially as some of them quack when given the standard duck test, and image search tools like Tinyeye & Google already exist, my question would be whats stoppping someone creating such a bot now? Commons was created as a space saver for the servers ensuring that we didnt need 300 copies of the same file and that as better media file come along everyone can benefit from them. Withit every new idea was just tacked on, anything "media" was put here now we have lots of little pockets that are known only to different stakeholders it not until we get hit with a major issue like WikiZero created that these start to cross over. I think a monthly meeting at differing times or multiple times as Selena is proposing is a good starting to point to find every one of those little pockets, and bringing potential solutions like a copyright duck bot dont get lost but rather brought to a more public sphere where they can be created and in such away that the WMF can flag them as a critical tool which regardless of the creator is maintained long after the developer has moved on to other projects. Gnangarra00:48, 17 September 2024 (UTC)[reply]
I'd love to join a meeting (particularly if one is held at WCNA next month)! My perspective is primarily one of a Wikipedian who uses Commons images, and my top priority currently is collaborating with the WMF on the Upload Wizard improvements. Sdkbtalk01:39, 20 September 2024 (UTC)[reply]
Here are some thoughts from my side, I was also at the meeting at Wikimedia. I like the idea to have a meeting on a regular basis. But such a meeting has one problem: At such a meeting there are often some interest groups over represented and some groups are not represented. And such a meeting can never be the place to make final decisions. That is the main problem that we do not have good process as community to make decisions. Proposals on Commons:Village pump/Proposals often to not have enough participation to be a good legitimization. If voting on proposals does not work to make decisions we should think about delegating certain decisions to a certain group of users they are elected and with quotas of certain interest groups. For the meeting maybe a solution could be the make an agenda for the meeting that focuses on the topics of a certain group. I also want to say something on one specific point: "There's a tension between admins and patrollers asking for more things to prevent vandalism, but also campaign creators who want lower barriers to entry." I think this is not really a problem. Most campaigns are organized by a group of active users giving guidance to new users and check the content uploaded in the campaign. Therefore the patrolling is done by the campaign organizers and no patrolling by admins or other patrollers is needed. And if people read the word "photo contest" they are aware that they are only allowed to upload their own works. In the last years of Wiki Loves Earth in Germany we did not have a single copyright violation uploaded by participants. There are problems with campaigns using the Commons:ISA Tool as not all organizers made a quality check. GPSLeo (talk) 06:10, 20 September 2024 (UTC)[reply]
I don't want to point fingers but there's certainly been a lot of copyright violations coming from certain Wiki Loves Monuments events over the last couple of years. Although I agree your general point that more active users can give guidance to the less active ones in those situations, but it seems like they just don't care or aren't willing to in a lot of cases. I've certainly seen people who run Wiki Loves Monuments events from certain countries act rather ambivalent about it before. So it seems like there's a general sentiment that it's not on them to moderate people who participate in their events, which I guess I can understand. As they are mainly concerned with getting people to participate and it's easy to turn people off from doing that. But it does create a lot of needless hassle on our end. At this point I just see it at the cost of doing business, but it would be good if there was a more long-term solution then expecting users to sift through other people's uploads for copyright violations every time there's an event. Maybe things like better training or a guideline saying that they have to review files for copyright violations before uploading them would help though. Who knows. --Adamant1 (talk) 07:00, 20 September 2024 (UTC)[reply]
But these copyright violations are related to lack of freedom of panorama and not false own work claims they are very common by users uploading photos while editing a Wikipedia article. GPSLeo (talk) 15:27, 20 September 2024 (UTC)[reply]
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. RZuo (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). RZuo (talk) 18:34, 16 September 2024 (UTC)[reply]
The examples people have brought up in support or as examples in this discussion include "AI generated", not just AI. Edit: Except for Alexpl's comment. ReneeWrites (talk) 14:22, 13 September 2024 (UTC)[reply]
Support When images are used internally editors know to check the filepage, when outside people reuse the images they are usually not aware of the info on the files page. We have had people reusing images without complying to the terms of the license by naming the creator. I would like to see (AI generated) the way we use "(cropped)" in file names. --RAN (talk) 18:06, 13 September 2024 (UTC)[reply]
Ooh, that's a good point - if a user saves an image from Commons (or another wiki) to their computer, for instance, there's a decent chance that its file name will remain intact as a warning. A template on the file's talk page certainly won't. Omphalographer (talk) 18:13, 13 September 2024 (UTC)[reply]
Strong oppose no no no, file names shouldn't be used for that. This opens up Pandora's box for controversial subjects. This should be in the file description, not in the name. Multichill (talk) 12:53, 15 September 2024 (UTC)[reply]
Comment Why do we even accept AI generated images to begin with? Most of them are misleading, useless for Wikipedia articles, fake-y look as standalone content, and can be barely trusted. AI images should only be limited to very specific scenarios, otherwise we end up with a bunch of superheros holding the Commons logo, which we can all agree is largely a set of very interesting trademark violations and not consistent with community practices. Moreover, there have been recently a number of court cases around copyright infringement for several of these AI companies, so I'm concerned that we can't distinguish the provenance from different models that may or may not be trained on infringing datasets. We have no idea how this is going to be regulated.
Comment I generally think templates and/or structured data are a better way to do this, and more multilingual-friendly. But I'm not opposed to also requiring it in file names if the community agrees on that (and I will anyway include in the filename of any AI files I upload myself). Noting that I have made a related proposal below: #Proposal: de-prioritise AI images in searchthe wub"?!"15:09, 19 September 2024 (UTC)[reply]
Support this would prevent problems with AI images being mistaken for real ones, and I really don’t see how this could potentially be harmful. Dronebogus (talk) 11:13, 24 September 2024 (UTC)[reply]
I'm sensing pretty widespread support, so let's plan out what would need changed:
Commons:File renaming: #2 gains "To identify AI generated works" with a possible more general version of "to point out major manipulations" (colourization, etc). This is explicitly allowed to be in any language.
Commons:AI-generated media notes that the AI-generation must be mentioned in the filename, ideally in the same language as the rest of the filename.
File upload wizard appends "AI generated" if the AI creation option is ticked, with the option to change this after, but with a note saying that identifying AI art in filenames is important. Alternatively, this can just be a soft prompt, that suggests a new filename, but doesn't require. (Similar to others where you can click "ignore and upload file anyway)
I think #4 should either not be implemented or be for files in Category:AI misgeneration. Images shouldn't be sorted by how they were produced but by by where the user is expecting to find them / looking for them or generally the relevance and quality of the image as it relates to the category concept, not the method/techniques used to produce it. You may have missed an addition to Commons:File naming. Prototyperspective (talk) 20:40, 14 September 2024 (UTC)[reply]
Added File naming, and you're probably right about #4. Wanted to pull all the suggestions made, but that may be too much (if nothing else, AI image categories wouldn't do the headers for first letter of filename). Adam Cuerden (talk) 11:44, 15 September 2024 (UTC)[reply]
#3 and #4 are terrible ideas. #3 will cause uploader confusion, filename conflicts, language issues, etc. This needs to be done by humans, not machines. #4 will also be confusing as no one will expect {{PD-algorithm}} to mess with the sorting. Plus it's just unneeded and potentially unhelpful, as there may be other reasons an AI-generated file needs to be sorted in a particular way. Nosferattus (talk) 17:05, 15 September 2024 (UTC)[reply]
I don't think they're terrible ideas, but I don't think these two are needed. We're not inundated with such a flood of AI-generated images being uploaded to Commons that these couldn't be done by hand, and a lot more people have filemover rights than admin rights, so this wouldn't add to the backlog of issues needing admin attention. ReneeWrites (talk) 09:46, 16 September 2024 (UTC)[reply]
Okay. Then let's focus on points 1, 1b, and 2. For 1b, I'm thinking (under "Clear")
"Where an image, either through method of creation or modifications, might mislead, this should be noted in the filename. This includes AI generation, colourization of a photograph, turning a sepia image black and white, upscaling an image, and other things that might not be immediately obvious. Simple, minor fixes do not need to be noted."
This discussion is about AI, and I think we should stick with that. I've seen way too many discussions get killed the moment they gain any traction because people keep attaching stuff to it that is tangentially related that no consensus was reached on. ReneeWrites (talk) 15:22, 16 September 2024 (UTC)[reply]
1a: Support "To identify AI generated works" sounds good to me.
1b: Comment I think it would be more at home under "Descriptive", specifically the subheader "Correct". There's nothing particularly unclear about the filename "Cancer cell.jpg", but it leaves out a lot of pretty crucial context that makes it pretty misleading.
I'd like to propose this change: Correct – The name should describe the file's content and convey what the subject is actually called. Inaccurate names for the file subject, although they may be common, should be avoided. The title given to a work of art by the artist that created it is considered appropriate, even if the name has nothing to do with what is depicted (for example, many works of Dadaism). The name should also be free of obvious errors, such as misspelled proper nouns, incorrect dates, and misidentified objects or organisms. Users are allowed to upload "unidentified" or "unknown" organisms but such files may be renamed upon identification. AI-generated images must disclose this fact in the file name.
It's tempting to include a bit on the rationale as to why, but none of the other examples have that either, they simply state what is policy. So I think addressing this with just one line that's clear and unambiguous is both pragmatic and in line with how the rest is written. ReneeWrites (talk) 15:50, 16 September 2024 (UTC)[reply]
Made a slight adjustment to the wording. A lot of the file names on Commons made with Dall-E or Midjourney have that in their file name, which should also cover this base. ReneeWrites (talk) 08:42, 17 September 2024 (UTC)[reply]
Okay. If no-one else has suggestions after a couple days, let's bring 1, 1b (with your text), and 2 together, ping everyone involved in the original discussion, and implement. Secondary ideas can be considered after that. Adam Cuerden (talk) 17:21, 17 September 2024 (UTC)[reply]
May be worth a clear call on whether AI upscaled photos should fall under "AI generated" for all this, given their similar potential for being misleading when the viewer doesn't realise that an AI was involved (eg. File:2Pac Passport (cropped).jpg, where one Wikipedia editor was pleased to find what they described as a "free-use authentic high quality photograph" of the subject on Commons, but no, it's just an upscale of an old and extremely low quality passport photo). Belbury (talk) 12:58, 25 September 2024 (UTC)[reply]
It's not AI-generated, it's AI-upscaled which is very different. It needs separate templates and categories which also warn the user about issues like potential inaccuracies. Prototyperspective (talk) 13:35, 25 September 2024 (UTC)[reply]
It's different, but if there's going to be a policy change on naming and negative-boosting AI content, we should be clear whether that also applies to AI upscaling or whether it doesn't apply to it at all. Some users already (very understandably) tick "I generated this work using an artificial intelligence tool" when uploading an AI-upscaled image, causing it to be incorrectly filed as {{PD-algorithm}} with no human authorship. Belbury (talk) 14:17, 25 September 2024 (UTC)[reply]
I think when this is checked the Upload Wizard should show another checkbox about whether img2img (an input image) was used or whether upscaling was used. If the former is checked, the user should enter some url to the input image(s). If the latter, it would add the template for AI upscaled image. Prototyperspective (talk) 14:21, 25 September 2024 (UTC)[reply]
Upload wizards capacity
I note in this AI discussion that the upload wizard asks the question of is it ai generated, so its possible that appending to file names or adding a template to identify AI generated media could be relatively easy to do automatically at upload. with a high degreee of consistance Gnangarra01:06, 17 September 2024 (UTC)[reply]
{{PD-algorithm}} is already added to any upload where this box is ticked, in addition to the licence template specified by the uploader.
It's worth remembering that some users tick this box in error, fairly regularly. Any additional effects of ticking it will require additional steps of cleanup in that minority of cases. Belbury (talk) 13:46, 19 September 2024 (UTC)[reply]
@DarwIn I already relayed the idea of adding automatically a template, if I remember correctly something is already added. Anyway, if there is community consensus to add a(nother) specific template, I can relay this too and discuss it with the team. It's going to take some time anyway. Sannita (WMF) (talk) 13:47, 19 September 2024 (UTC)[reply]
COM:MYWORK says: Usually, stating that it is a selfie will suffice if that is really the case, though in some cases you may be asked for additional evidence.
I have stated that there is no reason to ask for additional evidence because (1) it very much is really the case that the photograph is a selfie, (2) there is no reason to ask for additional evidence relative to any given case of a user uploading a selfie from a pseudonymous account, which is the default and expected scenario, (3) there is mild circumstantial evidence (yes, mild evidence, but there is no evidence to the contrary as far as I can tell) that the uploader specifically is the subject and the author (explained on the linked talk page).
So there is no reason that this should be the case when additional evidence is requested.
Under these circumstances, as the tag is controversial, I believe that it is time for a COM:DR discussion to finally determine if additional evidence is genuinely needed or not. When one user considers the permission to be missing and another the permission to be present (present insofar as the uploader who is the author added the CC BY-SA 4.0 license at the time of the upload), surely the way to resolve the disagreement is a deletion discussion. However, instead of substantively discussing, one file mover threatens that they will delete the file, which they technically can accomplish using a combination of actions that they are technically privileged to as a file mover, but in terms of the deletion policy, it would be improper for them to so.
I admit that I could be wrong about how this should be handled, and I could be missing some fact or circumstance, in which case I apologize. I tried talking on that talk page, and one contributor supported the view that this is a legitimate own work selfie, but there is no dialogue and the file is simply heading for deletion as if the talk page had never existed. Therefore, I ask for a community review of this situation, and my suggested resolution is to remove the tag and start a deletion discussion.—Alalch E. (talk) 01:27, 15 September 2024 (UTC)[reply]
It looks like a selfie. The question for me would be if she is the same person who uploaded it. Probably not. That can easily be dealt with though by having her or them send permission to the Volunteer Response Team. Although even at that point there would still scope/PROMO issues. But they probably don't matter since she's a politician. The more important thing is verifying that her and uploader are the same person or that they have permission to upload the image if they aren't her. --Adamant1 (talk) 02:03, 15 September 2024 (UTC)[reply]
There are no scope issues because the pic is perfectly functional as illustration for her Wikipedia articles, and is being used so in various languages without issue. About the same person question: I really don't see why "probably not". What's the reason for suspicion? Alalch E. (talk) 02:12, 15 September 2024 (UTC)[reply]
I meant as far as it being uploaded purely for promotional purposes. Which I don't think images get a pass on if they are being used on other projects. Especially if the image is of the person who uploaded and their the one's who added it to their own Wikipedia article. As to why I don't think the uploader is the same person, different names and the fact that the selfies are available on other websites. It's immaterial though. They should still be required to send VRT permission for the image anyway. Especially since again, the image is already out there on other places. What's your evidence that it was just uploaded from another website by a random PR person for Sanija Ameti or something? --Adamant1 (talk) 05:14, 15 September 2024 (UTC)[reply]
If possible, as that would solve the issue. However, to delete a file that is in scope (which I assume this clearly is, be it uploaded for promotional reasons or not), there needs to be serious doubt about the copyright. There may be, but "some suspicion" is not enough for deletion, and thus not for requiring VRT. Was the image on the internet before it was uploaded? –LPfi (talk) 09:16, 20 September 2024 (UTC)[reply]
The Supreme Court of India has demanded that the WMF remove references to the victim of the recent rape and murder in Kolkata. [1] There seems to be an emerging consensus on Wikipedia to remove the name, not necessarily because of the court case, but just for general sensitivity reasons. There are a bunch of files in "Category:2024 Kolkata rape and murder" that either state the name explicitly in the file name ([2]), or the name is visible in the image [3]. Not really sure what should be done about this. On English Wikipedia, the WMF asked the community to make its own decision on the matter. [4] Is there a consensus on file deletion/redaction as a response to non-copyright related court requests? Hemiauchenia (talk) 22:06, 17 September 2024 (UTC)[reply]
It's kind of an odd thing so I might be wrong, but it seems like there's really only two options here. Either we redact the name or delete the images. I do wonder what stops people from just re-adding the name or uploading new files that contain it in the future though. Since the amount of media related to her is probably essentially endless, or will be once this is all said and done. Compare that to Wikipedia where there's only one or two articles that can easily be edited and locked.
So I guess my point is that realistically nothing can ultimately be done about it on Commons. Otherwise it's just going to be an endless game of Whac-A-Mole. Which I don't think is a good use of anyone's time. Especially considering her name is already out there to begin with. Are we seriously going to waste the time and energy enforcing something like that when anyone can get her just by doing a basic Google Search? Screw that. I don't think we should allow the WMF to do it either. Since it isn't a copyright issue. They can't just censor things on Commons because of an ill conceived, unenforceable court order. --Adamant1 (talk) 01:29, 18 September 2024 (UTC)[reply]
Yes. In addition, yielding to the Indian Supreme Court opens a Pandora box about pressure from from external organizations and people, for reasons other than copyright. Yann (talk) 19:10, 18 September 2024 (UTC)[reply]
In general, I think we should delete the names of rape victims from Commons. In this particular case, it's unclear if this can be done here if dozens of images include the name on signs. ∞∞ Enhancing999 (talk) 09:38, 21 September 2024 (UTC)[reply]
I support renaming files and removing the name from descriptions as general courtesy/sensitivity; it isn't harmful or difficult to rename files. Commenters above have pointed out that it isn't a perfect solution, but it's a step in the right direction. I agree with Jeff G. that the WMF is best suited to handle a legal-based deletion decision, as they do DMCA. Consigned (talk) 09:51, 21 September 2024 (UTC)[reply]
September 18
Categorization of old maps, by year (another round)
I was again asked about what the prevailing consensus is, when categorizing old maps. I asked before in 2021/12 and 2024/03 but maybe I misunderstood the outcomes, so let me rephrase it in a much shorter way:
The general attitude I took home beforewas that old maps should be categorized (=grouped) by the depicted location. A bunch of old maps gets grouped into "Old maps of X", and only if there are enough old maps of X, the "Old" category gets split up. Depending on the contents, either by (sub-)location again, or by century/decade. In short: Old maps get categorized by the displayed location first and foremost, the creation date is less important.
Now here is the argument. - Tl;dr: Is ":Cat:1892 maps of <country>" really obligatory?
As far as I know, there is no reason why for example this Old map of Exeter should also be assigned the "Category:1884 maps of the United Kingdom", just so that it's 'properly' categorized by year also. In my opinion, that practice leads to overcat, especially since a map of Exeter is not really the same as a map of the UK.
The other day, I re-evaluated the contents of the category "1892 maps of Boston", which contained a mixture of maps that showed various locations located in the greater area of Boston: Maps of Larger Boston and surroundings, tram maps, aerial maps, detail crops, building plans, suburb maps and so on. I sorted this eclectic collection into different, more meaningful groups and locations: "1890s bird's eye maps of Boston", "Details of 1890s maps...", "1890s maps of Boston and environs" and so on. Five maps from 1892 did not fit into these groupings, and these I upmerged into Category:1890s maps of Boston. Preferably in my opinion, the maps of Boston should eventually get sorted further by suburbs and quarters: The location has priority when grouping files together. User:Pi.1415926535 has a different opinion and states that all maps (of Boston, but also in general) should get assigned a Creation-year-category, as in Category:1892 maps of Boston. His reasoning is that this would be "probably justifiable", and that these categories have all been created some years ago already.
I have multiple reasons to not favor by-year-categorization of maps: Unlike photographs, the creation of maps is a more fuzzy process, which is another reason why I don't think most maps should even be categorized by year. Another thing is that there are only 3 "1892 maps of Massachusetts", compared to 38 "Category:1890s maps of Massachusetts: By-year-categorization is atomizing the content.
So, I'm interested in reading a fuller argument by Pi in favor of these by-year map categories; and/or learn about the community consensus: Are "Maps-by-year" an integral/obligatory part of the category tree, or are they ultimately expendable? --Enyavar (talk) 00:20, 18 September 2024 (UTC)[reply]
Support Getting rid of "by year" categories for images of maps. I have some experience with maps and cartography more broadly. Generally it's nearly impossible to tell the specific year a map was created in. Most of the time what people mean is the publication date, but even then it's purely based on that specific publication of the map. Maps can, and often are, republished multiple times over decades though. Especially older ones. So a "by year" category will usually be wrong, if not also totally pointless because no one looks for maps that way. Usually they find maps based on the subject. Like "maps of the Southern Pacific Railroad." Not "1953 maps of whatever." I don't there's enough images in most cases to justify "by year" categories in most cases anyway and at least from what I've seen the community seems to be going in a different direction with things then categorizing every single image in a "by year" category for it's own sake. --Adamant1 (talk) 02:31, 18 September 2024 (UTC)[reply]
Seconding this. Maps aren't photographs; they aren't created at a specific instant in time, nor do they represent the world as it existed (or was perceived) at a single time either. The general historical period in which a map was created is, of course, still important, but the exact year is not. Omphalographer (talk) 20:49, 18 September 2024 (UTC)[reply]
It is rare when we need to need map categories for a place down to a single year; mostly useful when we have a large set of maps from a particular year, and even then the particular map set may be a more useful category than something about the year as such. - 06:46, 18 September 2024 (UTC)
I agree that year categories for maps are often not extremely useful, but decade and century are. Without a point in time, even if approximate, a map is mostly useless. OTOH, what means "old"? A 2005 map is old? I support getting rid of vague terms such as "old maps" and "historical images" (thankfully gone, now, at last!!) which have very subjective limits, and replacing them with the century & decade categories. Only in rare occasions one doesn't know which century is a map from, and those very rare cases can happily stay in the main category. DarwinAhoy!10:31, 18 September 2024 (UTC)[reply]
@DarwIn: I don't have time to look for something to cite, but the meaning of "old" for maps has come up before: more than 50 years old, with the proviso that there are a few places that have changed so much so fast that we need to special-case them. - Jmabel ! talk19:58, 18 September 2024 (UTC)[reply]
Hi Darwin, Jmabel, Category:Old maps defines Old maps, check out {{Old maps meaning}} Thanks to this definition, if you have 15 old maps of a town, from 5 different centuries, you do not need to establish 5 different century-categories that each only hold 2-4 files. And even better: undated maps or those which were created "between 1650 and 1750" can actually get categorized. (That is not the topic here, but needed to be explained apparently) --Enyavar (talk) 18:59, 19 September 2024 (UTC)[reply]
I objected to Enyavar removing files from the subcategories of Category:Maps of Massachusetts by year, and similar by-year categories for Boston, without any discussion to establish consensus. These categories were long-established and well-populated (typically 5-20 maps per year). Most of the maps being moved have their dates well-established either by a date on the map itself or by the contents. More significantly, Enyavar has not been properly upmerging categories, so basic information is being removed. For example, File:Boston Street Map, 1871.jpg (which has the date printed on the map itself) is currently not in any subcategories of Category:1871 in Boston nor Category:1871 maps - even though it is a map of Boston clearly dated 1871! @Adamant1: If someone is specifically looking for a map from that year (which is a very common use case for historical research), they would not be able to find that map through the most obvious category trees. Pi.1415926535 (talk) 20:02, 18 September 2024 (UTC)[reply]
@Pi.1415926535: I'm not going to claim it applies to every file of a map on here but from what I've seen most of them have the year in the file name. So I don't really see how people can't find them by year if their in decade categories instead. Its tangential, but tend to act like categories are the only, or most important, way to find images when there's others that work perfectly fine depending on the situation. There's nothing wrong with people having to read files names to find information about a file sometimes. That's what they exist for. --Adamant1 (talk) 23:40, 18 September 2024 (UTC)[reply]
Disagreeing with User:Adamant1 here. Navigating the category hierarchy should be one way to find things. It should be usable independent of search. Relevant categories should be used, even if the information is in the title or description. Similarly, the fact that something is in the title is not normally a reason to leave it out of the description. - Jmabel ! talk05:15, 19 September 2024 (UTC)[reply]
The fact that something is in the title is not normally a reason to leave it out of the description. Where did say that? I have zero issue with repeating facts in the description that are already in the file name. Since their inherently suppose to be descriptions. There's no reason to turn category names into a complete listing of everything related to a file though and I don't think it's necessarily important or useful to repeat facts that already in the file names. Otherwise it just gets to obtuse.
Like realistically how many times does there need to be a specific word on a page before it just becomes needless duplication? There's file names, category names, descriptions, section headers, infoboxes, Etc. Etc. Seriously does anyone think that Category:Tom Cruise isn't a category for images of Tom Cruise? You (and by that I mean the developers) are just treating users like their stupid children who can't read and need their hands held at every turn. It's just garbage UX design regardless. --Adamant1 (talk) 05:25, 19 September 2024 (UTC)[reply]
@Adamant1: I think you might have misinterpreted my comment. The main problem isn't finding maps in categories that they are in - it's that the maps aren't in the category trees whatsoever. For the example I gave - which is just one of hundreds of maps recently recategorized by Enyavar - it has been completely removed from two of the three most obvious category trees. A user looking through those category trees would not be able to find that map. Pi.1415926535 (talk) 17:33, 19 September 2024 (UTC)[reply]
Any users who use the category system at all, should know enough about the workings of time and space, to check the surrounding categories and not give up immediately. There is no 1819 map of Luxembourg? Well, have you checked "19th-century maps of Luxembourg", or "1810s maps of Belgium"? If you search for anything, you usually don't have much to choose from anyway: there was never a "1762 maps of Boston"-category, but the "1760s maps of Boston" has a map of just a few years later. --Enyavar (talk) 18:59, 19 September 2024 (UTC)[reply]
Oppose I'm not sure if users misunderstood or will misunderstand this to be about year categories for maps which are e.g. useful to find uses of outdated datagraphic maps (like a world map of number of automobiles per capita per country where it matters whether it's year 2000 or 2020). Second reason and specifically re old maps: not sure if I understood the proposal correctly but the years are very useful there as well such as for context. People in the past didn't know or have maps of the whole Earth in the past and accuracies also vary by date. It's key contextual information and I don't see any reason to remove it which seems like an unprecedented removal of useful information. Prototyperspective (talk) 11:56, 19 September 2024 (UTC)[reply]
Hi, this is only about old maps, not maps from the 21st century. Nor are we talking about any information getting removed from file descriptions, that would be horrible. This is about keeping decade-categories like "1890s-produced maps" and not picking apart the content artificially by single years. And anyway, maps should get categorized by location first, rather than by the production year. This one here is much better categorized as a "19th-century maps of Jefferson County, NY|1835 maps" (with the year in the sorting key, there), instead of "1835 map of the United States". --Enyavar (talk) 18:59, 19 September 2024 (UTC)[reply]
So your proposal is that old maps should only be organized by decade and not by year? Maybe that makes sense and maybe something like see also links could be used to address the issue raised by Pi.1415926535 where the files are missing in category trees where people may look for them. In any case I think the proposal should be clearer. Also files should be in all main category trees where they belong into, not just one and then removed from the parent due to OVERCAT and missing in the other. Prototyperspective (talk) 19:47, 19 September 2024 (UTC)[reply]
This was less of a proposal for some new rule, more the wish for clarification that this general categorization principle still applies (I provided links to the previous discussions). And also, this is not a hard rule either, there are several cases of categorizing maps where the year is indeed critical. But I think that Pi's concerns can be adressed if I add the respective "<year> in <location>" category to the respective files. Best, --Enyavar (talk) 04:41, 20 September 2024 (UTC)[reply]
Strong oppose Maps by year is useful as I have uploaded some historical maps that clearly show the situation as it was in a particular year. By Decade just fills up categories where By Year is more manageable. Abzeronow (talk) 17:12, 19 September 2024 (UTC)[reply]
Hi, which historical maps are you referring to here? Please check your own upload File:Iowa, Primary Road System, 1928.jpg, which you sorted into "Category:1920s maps of Iowa" instead of creating a new "1928 maps of Iowa" for the single file to rattle around in. Furthermore, if you take the whole current content from that decade in Iowa, you find a total of two 1920s maps of Iowa, and a bunch of 1920s detail maps of singular counties and building plans, which actually should be categorized into "... maps of Winnebago County, Iowa" etc., instead of cluttering the 1920s maps of Iowa. --Enyavar (talk) 18:59, 19 September 2024 (UTC)[reply]
I disagree somewhat. A map with a specific year, is usually made for a specific incident, usu, a battle. Therefore it's already filed in the battle category, which comes with a year. Most developed countries old maps, were decades in the making, and names don't change often. Filing by decade is almost superfluous for Europe. Hoewver countries mapped for the first time by explorers and invaders, are the exception to that. India for example is a nightmare of name changing, still going on today.
It's against the rules to file in multiple cats, but perhaps maps should be an exception. They were expensive, and would have been used over decades by individuals (authors) in India, where names and spelling were in perpetual flux. Filing by any date is an arbitrary process here, if I want to research South Carolina in 1838, I would look at an 1866 map first, and then go backwards. Filing by year is by publication date. I'd be happy by decade as a compromise. Broichmore (talk) 12:04, 20 September 2024 (UTC)[reply]
Comment Just for the 1880s: Maps were published in advance, like in 1882 for 1883. Maps were reprinted in 1912 with amendments for 1883. Maps from 1910 were drawn upon in 1916 to show the tram situation in 1888. Maps were printed in 1886 to show the situation in 1880. Simplified maps were printed 1881 in Paris, London, New York and Leipzig into reknowned world atlases, and who knows which originals were used from which dates. We have maps created in 1882 showing Boston in 1814. There are 1884 maps of West Roxbury, a town that was annexed by Boston just eight years prior, and that qualifies as a different location than "Boston" when it comes to "Maps of...". The construction plans for Pleasure Bay from 1884 is signed "December 1883". A lot of maps were published year after year in the same layout with just minimal changes (and thus, should probably get categorized by the publisher+layout, not the year). Those are just some examples why the exact year doesn't matter for the map category while an indication of century or decade still makes sense. Cases where the exact year of a map matters, are rare (but, like with Category:1775 maps of Boston) they exist. @Jmabel: , thanks for the clarification above, "Navigating the category hierarchy should be one way to find things". I've started to add the relevant years to the Boston maps where the year apparently matters - but with the "<year> in Boston" scheme, and not "<year> maps of Boston". --Enyavar (talk) 15:42, 21 September 2024 (UTC)[reply]
@Enyavar: maps should generally be categorized, if possible, by the date they ostend to show; obviously, information is not gathered in an instant, so it is common for ostensibly "current" maps to show the prior year. They can also be categorized as "works" from the year in which they were made. - Jmabel ! talk15:58, 21 September 2024 (UTC)[reply]
I still maintain that maps should rather generally be categorized by the location they ostend to show, and subcategorized by dates only if really necessary. Otherwise, we get stuff like this magnificent 1848 map of Asia (precise year, location as imprecise as possible) and atomized categories like Category:1856 maps of Toronto. But I don't object to categories as "works from year" or "year in". --Enyavar (talk) 17:31, 21 September 2024 (UTC)[reply]
September 19
MM/DD/YYYY vs DD/MM/YYYY recognition
There is an example in
https://commons.wikimedia.org/wiki/File:Zoo_Heidelberg,_Sumatra-Tiger.jpg
where the "Created" tag in the page says it was created on 7 December 2024
(that means: in the future) and clicking on the "More details" we find that the
Exif data are interpreted as 12 July 2024 (which is nice/ok) and that the Date
is 12.07.2024 (which is the most common European way of writing DD.MM.YYYY)
So there is some sort of ambiguity or bug that toggles days and months
in between these formats.
--13:42, 19 September 2024 R. J. Mathar
while it's definitely a bug of the mediaviewer, pattypan should also be modified so that users dont input dates in strange formats instead of iso yyyy-mm-dd.--RZuo (talk) 13:53, 19 September 2024 (UTC)[reply]
Meanwhile the uploader has changed his 1000+files affected to the ISO YYYY-MM-DD format, so the example of the Sumatra tiger I gave above is now showing a correct/coherent date in the preview and in the EXIF/"More details". - R. J. Mathar (talk) 18:48, 22 September 2024 (UTC)[reply]
However it should be possible to de-prioritise such images by adding Template:PD-algorithm (which all AI generated images are supposed to be tagged with) to MediaWiki:Cirrussearch-boost-templates. I would suggest a ranking of 50%, which would rank AI files below most other files, but above those nominated for deletion or otherwise tagged as low quality/superseded.
Example of a search for "animal" (cluttered with many old book scans crowding out already badly prioritized images)
Strong oppose Images made using some AI tools should either not be deboosted or only files in Category:AI misgeneration should be sorted to be further down in general: images shouldn't be sorted by how or by which techniques and tools they were produced but by where the user is expecting to find them / looking for them or generally the relevance and quality of the image as it relates to the category concept, not the method/techniques used to produce it. Additionally, this functionality only incentivizes people to hide the fact they used AI to make an image which we should encourage people to specify. There are many cases where AI images are some of the best for the concept searched for and they should be shown fairly high up in such cases, especially when they're in use. The example search results look like that because nearly all images for a useful Wikibook used rhino images. They indeed should not show high up there (for this search term) but that doesn't mean all AI images should be downranked in general. Some other improvements to the search results should be made that are not specific to AI...for example only showing used images high up if they are used on Wimedia items (like Wikipedia articles) that are actually related to the search term. I will attach a screenshot that shows how bad the search results often are, this is a general issue and lots of other media crowd out useful media. Some other issues include that it often shows very outdated charts at the top when there are more up-to-date charts. This is just some discrimination of the use of a novel tool to produce often high-quality useful images but not a reasonable effective measure to actually improve the search results. Prototyperspective (talk) 15:06, 19 September 2024 (UTC) Added screenshot --Prototyperspective (talk) 15:27, 19 September 2024 (UTC)[reply]
" or only files in Category:AI misgeneration should be sorted to be further down in general" I added that a whole month ago already Trade (talk) 18:25, 20 September 2024 (UTC)[reply]
Instead we could have a filter that excludes AI images. Moreover, these aren't a problem here the example given is one of very very few cases where the results are indeed cluttered by AI images. Third, again the tools and techniques used for producing an image is not the important part...rather whether it's high-quality, useful and relevant to the search term. I don't see this problem on Image search engines but I also don't know what (and how) you searched for. What's next – downranking images made or edited with Photoshop or Krita?Prototyperspective (talk) 11:00, 20 September 2024 (UTC)[reply]
Neutral I'm not sure this is the answer to dealing with the problems caused by AI images. I think another proposal for putting "AI generated" in file names of AI generated artwork would be a better solution. Since it's not so much where the images show up in search results, but that people often don't know the images are AI generated to begin with. People can still accidently get an AI generated image if they are pushed down in the search results. What we need is better ways to clearly identify and deal with AI generated artwork to begin with. I feel like it's mostly a curation issue at this point though. --Adamant1 (talk) 00:32, 20 September 2024 (UTC)[reply]
Why discriminate against the use of one particular tool? I don't see any rationale there only that you apparently want to continue to subjectively semi-censor images made with a tool you apparently don't like. Prototyperspective (talk) 11:02, 20 September 2024 (UTC)[reply]
AI generated artwork isn't a tool, its a specific type of art. Stop trying to act like we're just discussing Microsoft Paint every time this comes up. Its getting rather tendentious. --Adamant1 (talk) 11:08, 20 September 2024 (UTC)[reply]
It's the AI tool. One can use the result and edit it in Krita/Photoshop or create a draft and use an AI tool to improve it via img2img. AI-generated art is a type of art that makes use of these tools, similar to photography by definition makes use of cameras or paintings characteristically make use of paintbrushes. The level of involvement of the human is often far lower than in manual paintings. I doubt people voting here have much experience with prompting around for a few hours to get an image to look nearly exactly like you want it to or seen cases where AI images are the most illustrative. Stop trying to act like it's not discrimination against one particular novel tool (or art-technique/artform). Prototyperspective (talk) 11:18, 20 September 2024 (UTC)[reply]
Don't get me wrong, I'm not acting like it isn't singling out a specific type of art. It has to be due to the nature of the thing. "Artwork" isn't the problem here. AI generated artwork is. You know as well as do that no one is uploading personal drawings of cells made in Photoshop and trying to pass them off as actual images. Let alone that anyone will be fooled by said images like they clearly are for AI generated artwork. Your just being disingenuous and choosing to ignore the issue instead of admiting that AI artwork has its own problems that inherently don't exist with other artforms. --Adamant1 (talk) 11:31, 20 September 2024 (UTC)[reply]
drawings of cells made in Photoshop and trying to pass them off as actual images Delete these. There is an ongoing proposal about requiring their file titles to specify they are AI-generated and that seems like not a bad idea. There also are templates and categories by which people can see that the file is AI made even if that's not in the file description where this info should be and usually is. You didn't address the points made but if that helps: yes AI artwork have their own problems and I never said otherwise. One could even think about downranking AI images for search terms where the user likely looks for actual depictions and not artwork. For example, when searching for "animals" all art media and AI-generated media could be downranked and images featured in WP articles broadly about animals like such as the collage images upranked. Prototyperspective (talk) 11:53, 21 September 2024 (UTC)[reply]
Comment I'm not sure if nobody else has noticed this or people have noticed but simply haven't commented, but the vast majority of the Javan rhinoceroses generated by the AI prompts aren't Javan rhinoceroses, but black or white rhinoceroses. ReneeWrites (talk) 08:38, 21 September 2024 (UTC)[reply]
The search results for that are also littered with AI generated images (Rhinoceros sondaicus). And search takes multiple things into account (descriptions, file names, metadata) so searching for both should yield similar results. One is not more correct than the other. ReneeWrites (talk) 10:50, 21 September 2024 (UTC)[reply]
Doesn't that just illustrate a quirk of MediaSearch that displays images not categorized as "Rhinoceros sondaicus" also ? Compare with Special:Search linked above.
In general, we might be blaming "AI" for defects of our search engine due to our naming conventions for categories and files about "Javan rhinoceroses". The correct approach would be to fix the search engine for the general issue. ∞∞ Enhancing999 (talk) 11:06, 21 September 2024 (UTC)[reply]
They are categorized as rhinoceros sondaicus, specifically Category:Rhinoceros sondaicus in art. Thinking on this a bit more, I don't think de-prioritizing search results would fix the issue at hand. These are simply not images of Javan rhinoceroses, even if the prompt called for those to be generated. ReneeWrites (talk) 16:38, 21 September 2024 (UTC)[reply]
Comment Also please consider all the unintended consequences like if a logo of some project or tool was made using AI (as is the case for several Wikimedia projects) it wouldn't be shown at the top when searching for the project name even if it's the actual logo (and this was just one example). Also before considering this please consider that artistic and illustration workflows are involving to substantially incorporate AI-generation and we'd be indiscriminately semi-censoring lots of media (that at times is quite high-quality or relevant to whatever the user searched for) – so please see this example workflow video of an AI tool integrated into Photoshop. I think it should probably be required watching especially for people who don't have a lot of experience with using these tools and and in their personal experience didn't come across many media created using them that could be useful. Prototyperspective (talk) 12:12, 21 September 2024 (UTC)[reply]
Why don't you and Jeff include any explanation and don't address any of the points raised? What about the issue of it hiding the logos of projects etc when searching for these? Why are you suddenly in favor of indiscriminate (semi) censorship – I'd like to understand and think decisions should be based on sound well-thought through rationales. Prototyperspective (talk) 22:09, 21 September 2024 (UTC)[reply]
If some illustration uses some AI images because there are no good free ones it would get censored. If people make media in relation to politics we'd be be doing political (semi) censorship like China seems to do it – it's a big social problem if a large proportion of diverse media on all sorts of things is suddenly indiscriminately semicensored here or anywhere else. I doubt you have seen the video I linked and neither replying nor providing any rationale or addressing any points shows how this is about ignorance, not anything thought through and possibly some emotional knee-jerk reaction because voters simply don't like the use of AI tools for whatever personal reasons. I think Wikimedia projects are generally oriented towards rationality and reason, not subjective opinion vote counts. The AI images people have uploaded here so far are below average but that may change and there's many cases where these are very relevant for various search terms.
@Borvan53: you used an AI tool to create what seems to be the first and high-quality image of a palantir which is a trope of fantasy fiction and used in several Wikipedia articles – what do you think about this proposed policy that would hide your image from the search results even when searching for "palantir"? @TatjanaClimate and S. Perquin: @Milena Milenkovic (VMRS), Fuzheado, and JPxG: you created some logos using AI tools, what do you think of this proposal that would hide in the search results such when searching for the name of the project/… for which the logo is used or related search terms? @Raresvent: An AI image of your prompting is a quite good illustration of post-apocalyptic art, what do you think of moving it far down in the search results for that search term? Prototyperspective (talk) 23:33, 22 September 2024 (UTC)[reply]
Oppose There is already the template {{PD-algorithm}}. It is mandatory. AI images will be more and more common, and our thinking must be focused about their quality. Should I mention that I worked a couple of hour to generate the image of the Palantir ? First trials gave everything but a Palantir. Borvan53 (talk) 06:51, 23 September 2024 (UTC)[reply]
I was not saying you need one, just asking for one. Moreover, the linked policy suggests when discussing proposals people if possible shouldn't just leave a vote to be counted but also e.g. address points raised.
@Adamant1: , I am allowed to ask relevant people to participate in relevant discussions and lots of people did this elsewhere on WMC. I think comments that do not address any critical points & questions and have no rationale should be ignored, you think people affected by this proposal should be ignored so we disagree on that. Most contributors do not check VP here, which is frequented by a very small fraction of users, but also most users probably don't want AI images to be semi-censored or would like to have policy-discussions to be based on sound reasoning. These users may provide some further insights and I made transparent how they are related to it. If that wasn't okay then where is a policy that prohibits doing so and why can other users do this over and over in other discussions without any issues? Prototyperspective (talk) 08:53, 23 September 2024 (UTC)[reply]
Sure, Perspective. There's a difference between that and pinging specific people who you know will take your position because they have uploaded AI generated artwork before though. Otherwise I could give a crap, but if your ping people who are clearly going to have a particular position about it then 100% your just canvasing at that point. Especially since you did it half way through the discussion and when there was more support for it then not. So it's pretty obvious that's what you were doing. --Adamant1 (talk) 08:59, 23 September 2024 (UTC)[reply]
Again, I never seen any policy that prohibits that which may be because Wikimedia was originally meant to have discussions based on reasons rather than votecounts but if one such exists please link it and if not you could propose one. Secondly, again many other users including admins did the same in other discussions such as DRs and they didn't transparently show how these users relate to the subject which is my third point: I made this transparent so everyone can contextualize their comments, explanations, and votes. Affected good-faith long-standing users are I think certainly users that should be involved in proposal discussions and we may disagree on that. I also think in politics that people who are affected by policy decisions should have a say and we may disagree on that as well. Fifth, you and others could also invite users but I think the small number of users who frequent this VP board have much of an overlap with the strongest opponents of AI tools in media production. It may indeed be a problem if I did that early in the discussion rather later one or without making their relation to the subject transparent. Prototyperspective (talk) 09:36, 23 September 2024 (UTC)[reply]
Comment Take the example of the project of biological expertise/palaeontology that takes bones of early humans or dinosaurs and tries to add muscles, tendons and hair to figure out what the actual human/animal looked like. Are the results in the category of AI generated images? - R. J. Mathar (talk) 19:05, 22 September 2024 (UTC)[reply]
I don't know if deprioritizing them across all searches the best way to do this, but I think there absolutely has to be some way to choose to exclude them from a search. JPxG (talk) 23:47, 22 September 2024 (UTC)[reply]
A filter for AI images is a separate proposalA filter the user can enable to exclude AI media is a separate idea and was proposed by the same user elsewhere. I think I would support that as well and it's one reason why I put so much effort into categorizing AI images into the AI-generated media subcats which should now contain virtually all of these. Prototyperspective (talk) 23:52, 22 September 2024 (UTC)[reply]
Oppose I don’t particularly care for AI art; but AI art is not overwhelming Commons by a long shot. Often times AI is used for illustrating fanciful concepts, where it is not inherently better or worse than human art. And it’s highly unlikely to get ranked highly among depictions of mundane subjects that likely have featured, valued, or good images. So this, to me, reads like “AI is bad but we can’t ban it (at least not yet) so let’s quietly suppress it”. It feels kind of sneaky and manipulative, like Generic Big Tech Inc. manipulating what users see for generic sinister purposes. Dronebogus (talk) 12:16, 24 September 2024 (UTC)[reply]
I noticed recently that there's a special icon that can be added to valued images when their being used in galleries. It wouldn't help with this particular issues per se, but maybe having a little icon in the corner of every image that is AI generated so people will at least know that's what their looking at would help. It should be that hard to implement either. Although I suspect people could and would make the same arguments against something like that they normally do. But whatever. There should be something to indicate an image was generated by AI. The trick is to make it as inconspicuous as possible while still making it clear enough that people will notice it. --Adamant1 (talk) 12:23, 24 September 2024 (UTC)[reply]
This is a new page to request categorizations of files. Some people have some time but may not know many or more things to do while some are drowning in potential tasks or aren't using sophisticated/time-efficient ways (like cat-a-lot + SpecialSearch) to implement them or would implement them in suboptimal ways (like not creating subcategories when these would be due). It could be quite constructive to bring these together there so people looking for things to do can (also) go there and find a task they're interested in by which they can contribute to WMC.
I added several of my categorization-todos as examples. The page also includes a section for categories missing many items. A user going to such a category may think this is all there is on WMC for that subject when only the category has not yet been populated properly or is missing many files.
--Prototyperspective (talk) 16:40, 19 September 2024 (UTC)[reply]
I've split the page into 3 levels of difficulty – this allows this to be a resource for both new and experienced contributors and enables new users to not waste time trying to implement difficult tasks without knowing e.g. tools (like cat-a-lot and SpecialSearch with search operators) needed to implement them. In addition, there is a section for categories missing many files. Registering requests there also enables people to follow up on how a request was solved so it can be implemented again in the future / the category be maintained using the method used to populate it. I have far more categorization tasks in my notes so I didn't put everything there and of course rather try to categorize things myself instead of just noting which categorizations are very incomplete there. Prototyperspective (talk) 09:27, 23 September 2024 (UTC)[reply]
The Wikimedia Foundation will switch the traffic between its data centers. This will make sure that Wikipedia and the other Wikimedia wikis can stay online even after a disaster.
All traffic will switch on 25 September. The switch will start at 15:00 UTC.
Unfortunately, because of some limitations in MediaWiki, all editing must stop while the switch is made. We apologize for this disruption, and we are working to minimize it in the future.
A banner will be displayed on all wikis 30 minutes before this operation happens. This banner will remain visible until the end of the operation.
You will be able to read, but not edit, all wikis for a short period of time.
You will not be able to edit for up to an hour on Wednesday 25 September 2024.
If you try to edit or save during these times, you will see an error message. We hope that no edits will be lost during these minutes, but we can't guarantee it. If you see the error message, then please wait until everything is back to normal. Then you should be able to save your edit. But, we recommend that you make a copy of your changes first, just in case.
Other effects:
Background jobs will be slower and some may be dropped. Red links might not be updated as quickly as normal. If you create an article that is already linked somewhere else, the link will stay red longer than usual. Some long-running scripts will have to be stopped.
We expect the code deployments to happen as any other week. However, some case-by-case code freezes could punctually happen if the operation require them afterwards.
I somehow doubt that the Taliban asked Commons user Falerístico to design their coat of arms for them. Any idea if there is a more suitable license we can use?--Trade (talk) 22:13, 20 September 2024 (UTC)[reply]
advocate for nudism - not true: It is a protest in support of human rights as expressed in the UN declaration of human rights, the Istanbul convention, German constitution and German AGG law. And there is no nudity.
disturbing or offending - yes, there are people offended by the thought of equal rights for man and women
not educational - what? of course it is educational
So: when did Commons change it rules to allow only public domain content on the main page. Why are depictions of protests in support of human rights not allowed? and in what way is such a depiction not educational?
you could at least film with a tripod or a gimbal, and cut out the irrelevant parts like the first 1 min of this video, then it's something more worthy. RZuo (talk) 18:02, 21 September 2024 (UTC)[reply]
Seconding this. While MOTD, unlike POTD, doesn't require that content be featured (in large part because Commons:Featured media is not a particularly active process!), it should go without saying that files selected for MOTD should be of exceptional quality and should have self-evident educational value. This file isn't up to that standard. Omphalographer (talk) 23:41, 21 September 2024 (UTC)[reply]
I meant that apparently it's also not CCBY (public domain in the broader sense)
It does advocate for nudism, in this case for women to show their bare breast. I did not say there is nudity.
disturbing or offending was not the reason in itself. For very controversial files things should be in a neutral and reasonable manner when put onto the Main page. This is not a place to advocate your 'free the tits' opinions or however one calls it and this applies to other subjects but especially when things are quite controversial which results in people being repelled from WMC. Moreover, it is not about equal rights – seeing bare breast has generally different effects depending on sex, that is a neurological fact and of course varies with sexuality and there probably are also women turned on a lot by bare men's breast etc.
This is not a protest about in support of human rights even if you think or claim so. Nothing about is explanatory or truly educational. It does document an event and is slightly educational but it does not belong on the Main page. It's also not featured media. In which way is that educational? Compare this to videos explaining notable problems such as challenges facing the world's oceans or how something works or high-quality video of ecosystems/nature etc.
It's licensed CC-BY-SA-4.0, which is an acceptable license for both Commons generally and the front page specifically. It's not in the public domain, but files don't have to be in the public domain for them to be eligible for MOTD. It just so happens that a lot of media files that end up front-paged are PD. Everything else is a matter of opinion. The Free the nipple campaign is a legitimate campaign within the broader modern feminist movement, regardless of how you feel about the points it tries to get across or the methods they employ in doing so.
That being said, I do agree with RZuo's arguments that the media file itself is not of very high quality (footage is not stabilized, and the video was not edited to cut out the footage where nothing is really happening). ReneeWrites (talk) 18:16, 21 September 2024 (UTC)[reply]
I strongly disagreee with "footage where nothing is really happening". Of course there is. And no it does not "advocate for nudism". About "frequent obstrution of cars": It would falsify the situation to remove the cars. The file has a problem: audio and video are out of sync, but I am fixing that, i will upload a fixed revision by 18th. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 19:15, 21 September 2024 (UTC)[reply]
I was referring to the template that says This image is not public domain. Please respect the copyright protection. It may only be used according to the rules mentioned here (or with an individual permission by the creator). This specifically excludes use in social media, if applicable terms of the licenses listed here not appropriate. so it seems like there are some additional restrictions, this may be wrong so maybe strike point 1 of 4.
The Free the nipple campaign is a legitimate campaign within the broader modern feminist movement, regardless of how you feel about the points it tries to get across or the methods they employ in doing so And? Are we now including activist videos of any type on the Main page so editors can advocate any bizarre fringe ideas they have on the very frontpage with little to no educational value etc? It doesn't belong there for many reasons and I elaborated on why while trying to keep it short. Prototyperspective (talk) 19:21, 21 September 2024 (UTC)[reply]
@Jeff G.: Not to speak for Prototyperspective but by fringe I assume they meant that the whole "free the nipple" thing is on the border or outer edges of the feminist movement. Which for all intents and purposes is the case. "Freeing the nipple" as it were isn't a part of regular, every day feminist discourse. Breast feeding in public maybe, but then it's not really inherently about "freeing the nipple" anyway. --Adamant1 (talk) 10:50, 22 September 2024 (UTC)[reply]
I suspect there's a misunderstanding around "This specifically excludes use in social media". Rather than adding additional restrictions for social media, I believe they're providing less restrictive attribution requirements for social media; on the linked page it says "At Social Media Sites only it is sufficient to use only the QR code inserted in the media file or near the associated media file". @C.Suthorn: can you confirm? Consigned (talk) 10:55, 22 September 2024 (UTC)[reply]
Indeed, on Social Media I offer this option for an easier attribution, that I am OK with. The template on the page on the other hand is only a clarification, because there are people who think, that everything on the internet is in the public domain. The same text (template) is also used by other users. C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:12, 24 September 2024 (UTC)[reply]
I'm not going to weigh into the whole thing about if a nipple campaign is a fringe idea or not since I think it's just bait for concern trolling on C.Suthorn's end and doesn't really matter in the grand scheme of things anyway, but I totally agree with RZuo and ReneeWrites about the low quality of the video. At the end of the day the frontpage should only have media that fits a certain standard and the video clearly doesn't meet it. I suggest this just be left there instead of needlessly turning it into an off-topic debate about what makes something "fringe" or not. --Adamant1 (talk) 05:18, 22 September 2024 (UTC)[reply]
Low-quality shaky cam video like this would only qualify for MOTD if it showed something momentous. This doesn't. I'm pretty comfortable in saying that at least 90% of what I've uploaded at Category:Videos by Joe Mabel is higher quality than that, maybe 100%, and I'm honestly not sure whether any of what I've uploaded would be good enough for me to advocated it for MOTD. - Jmabel ! talk21:40, 22 September 2024 (UTC)[reply]
@Prototyperspective: no, free licensed content is not "public domain in the broader sense". It is precisely "free-licensed". In particular, in countries where there is no requirement to attribute public-domain content, you can still be sued for using a CC-BY file without attribution. - Jmabel ! talk21:40, 22 September 2024 (UTC)[reply]
1. I don't think men with gynecomastia have the same or similar psychological-neurological effects on men as women's bare breasts on men. 2. I think they already do but this is somewhat offtopic: 3. This is not about whether the file is on WMC or whether that activism and its methodology make sense but whether such a file belongs on the Main page. 4. Jmabel, you're right...public domain is not the right term for what I meant with "public domain" there even when broadly speaking. Prototyperspective (talk) 12:13, 23 September 2024 (UTC)[reply]
Having a CC-BY-SA license is not a justifiable reason for removing content on the Main Page. It's a free license. Just wanted to address the original statement so that people who read this will see an answer without the hullaballoo about of the content of the video. Bastique☎ appelez-moi!21:37, 23 September 2024 (UTC)[reply]
(random headline)
Demonstrations and protests often take place on a regular basis, and this probably also applies to the Free The Nipple demonstration in Berlin at the Brandenburg Gate. So it is only a matter of time before there is a video that meets the technical requirements expressed here. I consider the issue to be an important one (I have already pointed out that the UN, EU and Germany are clearly in favour of equal rights) and reject the arguments ofdisturbing, offensive, nudism and fringe. So if there is a video with the desired technical requirements, I will post it on MOTD. If there is a formalised procedure at the time that applies to all MOTD (for example, a vote in which there are more approvals than rejections), I will of course adhere to it (and I am already curious whether there will still be audio files in OGG format with national anthems of micronations played listlessly by a US military band on the main page, where the lyrics are not sung, nor included as subtitles, on the file description page, or in the article about the national anthem, and the article also does not explain the history and meaning of the anthem (I.E. there are no double standards applied.)). --C.Suthorn (@Life_is@no-pony.farm - p7.ee/p) (talk) 08:39, 24 September 2024 (UTC)[reply]
These audio files were added by a user who is not blocked. They could be removed whenever they are replaced by something else. Yann (talk) 09:15, 24 September 2024 (UTC)[reply]
i dont think these low quality videos of unimportant events are comparable to music played by a professional military band. RZuo (talk) 14:17, 24 September 2024 (UTC)[reply]
I don't think recordings of scripted material that are inherently repeatable and uploaded from elsewhere are nearly as important as user-made videos of modern events.--Prosfilaes (talk) 17:50, 24 September 2024 (UTC)[reply]
Do we accept category pages which end with text like "Should you choose to perform actions before asking questions, your chances of getting detailed and polite answers will not be high."?
Regarding the 1st question: IMO they don't. The page should be modified or rewritten w/o personal attacks like "vandals", or be deleted (surely they can then recreate it on Russian WV, where there are no guidelines). --A.Savin21:49, 21 September 2024 (UTC)[reply]
I'd just delete both. About the page, the whole idea that someone should notify them before nominating an image of a monument for deletion is just laughable on it's face. The same goes for most of the other content on there. With the template, it seems to add a warning to everything it's added to saying "this template and pages using it are maintained by the Russian WLM team. Please read the guidelines before making any changes that can affect the monuments database!" Which is at least overly confrontational, if not totally pointless. It appears that their whole numbering system for "cultural heritage monuments" is a personal thing created by the Russian WLM team to. So I don't think it should be associated with the categories, images, or anything else on Commons. Especially if it's just going to be used as a way for Russian users to control things related to Russia on here. --Adamant1 (talk) 05:38, 22 September 2024 (UTC)[reply]
Well, this is the only database for Russian monuments. Nothing else exists at this level. Deleting the template would mean either (i) a lot of uploads of files without categories which nobody would notice; or (ii) we just stop WLM, which is the only source of files for Commons for most of these monuments. In the ideal world, the users would categorize the files properly, or it would be freedom of panorama for monuments in Russia, or Russia would become a civilized country and remove all these monuments to Lenin etc from the protection lists, but none of this is likely to happen in our lifetime. Ymblanter (talk) 06:27, 22 September 2024 (UTC)[reply]
@Ymblanter: The Russian cultural heritage register has their own numbering system that has nothing do with the one from WLM Russia and there's already a property for it on Wikidata, P5381. So the database on WLM Russia's end serves no meaningful purposes what-so-ever outside of allowing them to control things related to Russian monuments. Regardless, there's no reason why they can't just drop the pointless intermediate numbering system and go with the exiting, official one from the Russian cultural heritage register. There's certainly nothing requiring them to use their own personal numbering system for monuments though and I'd argue it goes against the guidelines anyway. --Adamant1 (talk) 06:35, 22 September 2024 (UTC)[reply]
I am sorry but you do not know what you are talking about. The Russian cultural heritage register is so incomplete that it is almost useless. 90% of the monuments would have no number if we go with the official register. Ymblanter (talk) 06:47, 22 September 2024 (UTC)[reply]
Where did I say they were exact copies of each other or that the official list was as extensive as the one from WLM Russia? I could create my own numbering system for something right now that would include more things then an official list. That's besides the point though and has nothing to do with the merits of letting me use my own system on here. At the end of the day this is a media repository. That's it. It's not a database of monuments. Wikidata and Wikipedia exists for that purpose.
I'm not even saying they should get rid of the database. I'm just saying the template and the fact that they are using as a way to control things is inappropriate, totally pointless, and goes against the guidelines. I could give a crap if us not allowing for it causes them to take their ball and go home. That's not on us. They can always create a Wikidata property for it and add the information through infoboxes if the system is that useful. But it's totally pointless to have the numbering system as a template that gets added to specific categories. Things like that are exactly what Wikidata and infoboxes exist for. A lot of the monuments need to be documented better on Wikidata anyway. This is a perfect opportunity. --Adamant1 (talk) 07:04, 22 September 2024 (UTC)[reply]
I think turning the numbering system into a Wikidata property that can be added to infoboxes instead doing it through a template that's added to categories is perfectly clear. Your just being insincere about it. --Adamant1 (talk) 07:16, 22 September 2024 (UTC)[reply]
I have rewritten the page in the light of the above discussion. However, I note that it includes a numbered bullet point, saying:
Categories by ID are automatically added by our templates and adopt simple names Category:WLM/ID and Category:WLE/ID for cultural heritage and natural sites, respectively. These categories are not created as pages, but added to all WLM/WLE images, which is sufficient for generating galleries of images with a given monument ID. Example here. Such galleries are linked from our lists of natural sites and cultural heritage under the name "галерея". These numbered categories are vital for sorting images and finding images with a given ID. If you are unhappy about red links generated by these categories, propose a better way of finding an image based on monument ID.
Unfortunately, this recipe is not implemented via the MediaWiki API, so the result will not be machine-readable. Destroying the WLM/xxx categories will break several tools on Toolforge and possibly some external applications. Olksolo (talk) 15:31, 23 September 2024 (UTC)[reply]
It is reasonable to allow some time for transition, so that such tools can be modified, before the categories are deleted. It would not be reasonable to use those to insist that the categories cannot be deleted or redirected. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits16:16, 23 September 2024 (UTC)[reply]
@Olksolo: I think the difference there is that the categories contain sub-categories for the ships and aircraft. Like if I go to Category:IMO 1000021 it contains Category:Montkaj (ship, 1995). Which is how it should be. The same can't be said here though. If you go to Category:WLM/2500622000 it just contains images that are also in Category:Pogranichnaya Street 2, Vladivostok. Which isn't how it should be. Also, what qualifies as a "cultural heritage monument" in Russia seems to be completely arbitrary and based on the personal opinions of WLM Russia members. Whereas IMO numbers are officially recognized and used by the International Maritime Organization among other organizations. Any number system we use on here should at least be semi-official and agreed on outside of small group of users though. I don't think we should allow for any user created numbering or categorization systems regardless of if it's by WLM Russia or anyone else. --Adamant1 (talk) 16:11, 23 September 2024 (UTC)[reply]
But you are mistaken.10-digit numbers of cultural heritage sites were officially used from 2004 to at least 2011. The "cultural heritage site passports" available in online sources often use 10-digit numbers (not the modern 15-digit ones).For example, look at the cultural heritage site passport on the website of the Ministry of Culture of the Russian Federation: [5] (documents from the Russian ministry may not be available if you are not in Russia, then a copy is [6]). At the very top of the page is not the modern 15-digit number, but the 10-digit one — 0300000170.For objects managed by the WLM Russia team, there are official documents on the cultural heritage status. Olksolo (talk) 16:37, 23 September 2024 (UTC)[reply]
I thought Ymblanter had said that the list from WLMs has more items in it then the official government one. If that's the case then they came up with the designation at least for the monuments that don't have official numbers associated with them. --Adamant1 (talk) 16:47, 23 September 2024 (UTC)[reply]
The problem is that not all cultural heritage sites with cultural heritage status are included in the official register. This work has been carried out by the ministry for several years with varying success. The peculiarity of bureaucracy in Russia is that this work will never be completed. But somehow it is necessary to identify cultural heritage sites with official status that are not included in the official register. WLM Russia Team has expanded the old 10-digit numbering scheme to identify such objects. Of the 223,374 cultural heritage sites supported by WLM Russia Team, approximately 45,000 are an extension of the old numbering. Olksolo (talk) 17:24, 23 September 2024 (UTC)[reply]
In an ideal world, when each cultural heritage site would have its own Wikidata Entity, this might be true. But now, out of more than 200,000 Russian cultural heritage sites, only about 70,000 have a Wikidata Entity. And the question of whether a Wikidata Entity should be created for all of these cultural heritage sites is still open. Olksolo (talk) 17:34, 23 September 2024 (UTC)[reply]
Any of them that have categories on Commons can and probably should have Wikidata items. If for no other reason then to track the artists and copyrights. --Adamant1 (talk) 17:48, 23 September 2024 (UTC)[reply]
There is a further issue. We have, for example a category Category:WLM/1010021052; note the Wiki Loves Monuments ID (P2186) used on Wikidata is RU-1010021052
(note the "RU-" prefix). Not only does this make them harder to match, but implies that there may be a "1010021052" monument in other countries' lists; so the Commons name is not guaranteed to be uniquely identifying.
And, if a Wikidata item is not found, or the Wikidata item is not linked to a category, or the Wikidata item is linked to a "WLM/1010021052" style category, write to a log file.
Hi, having seen some DRs recently related to copyright violations coming from Fandom, which has a CC-BY-SA disclaimer that only applies to text, I created a guide to re-using Fandom content here: Commons:Fandom files.
Please take a look, and go ahead and make any improvements. The primary goal is to try to clear up the misconception that images from Fandom are automatically CC-BY-SA.
This might be better as a subheading on Commons:Problematic sources; I don't think it needs to be a policy, since it's largely a summary of facts. Some details that I'd focus on are:
Some Fandom wikis use CC-BY-NC or -ND licenses for textual content, which are incompatible with Wikimedia licensing. (And don't ask me how a -ND license is supposed to work on a wiki.) Comments posted on Fandom wiki pages are not freely licensed at all.
Fandom does not take any steps to verify licenses on uploaded images. Even if a specific image on a Fandom wiki is specifically claimed to be freely licensed (which should appear under "more info" when viewing that image), users importing that content to Commons should take appropriate steps to ensure that license is accurate. Images which don't specifically show a license in the file view should be assumed to be non-free.
The description of Category:Photovoltaic power stations (on roofs) says "Photovoltaic solar panels (photovoltaic power stations) on roofs." -> Even if there is the mentioning of "power stations" in the description I think this category is meant to contain typical installations on residential buildings as well ("Solar cell panels on roofs" is a sub-category of it, for example). BUT Category:Photovoltaic power stations (on roofs) is a sub-category of Category:Photovoltaic power stations which is described as a large-scale photovoltaic system (which means big ground-mounted systems in most cases). So something has to change. P170 (talk) 12:27, 22 September 2024 (UTC)[reply]
I wouldn't consider roof solar panels to be Photovoltaic power stations. Most of the time whatever power they generate is passed down to a power station in the garage or something. --Adamant1 (talk) 12:31, 22 September 2024 (UTC)[reply]
To make a concrete suggestion: I am in favor of renaming Category:Photovoltaic power stations (on roofs) to Category:Rooftop photovoltaic systems and placing it in a new Category:Photovoltaic systems. The latter category should also include Category:Photovoltaic power stations. I have already consulted with the creator of Category:Photovoltaic power stations (on roofs), and he confirmed that he meant ordinary rooftop systems and supports my proposal. Similarly, the same approach should be taken with categories for facade PV, balcony PV, etc. --P170 (talk) 19:13, 23 September 2024 (UTC)[reply]
Correct. Per w:Power station, a power station is "an industrial facility for the generation of electric power". A "photovoltaic power station" is a large-scale facility whose primary purpose is generating solar power, not a set of solar panels which are incidentally installed on a building. Omphalographer (talk) 21:00, 23 September 2024 (UTC)[reply]
I'm aware of that and that's what the topic is about. Again my suggestion: 1 Photovoltaic systems 1.1 Photovoltaic power stations 1.2 Rooftop photovoltaic systems 1.2.1 Solar cell panels on roofs. If you omit 1.2 it would be inconsistent because 1.1 is about a whole system und your 1.2 (my 1.2.1) is not. P170 (talk) 15:59, 24 September 2024 (UTC)[reply]
How would the use of 1.2 and 1.2.1 differ? For instance, what would be an example of a photo which belongs in "rooftop photovoltaic system" but not "solar cell panels on roofs"? Omphalographer (talk) 19:16, 24 September 2024 (UTC)[reply]
Normally we use {{Other versions}} rather than delete/redirect if they are not exactly the same, but in this case the former file is such low quality that I literally cannot imagine anyone preferring it. Yes, it should be deleted and replaced with a hard redirect. - Jmabel ! talk21:45, 22 September 2024 (UTC)[reply]
@Strakhov It's very common to create a redirect to a replacement after a file is deleted. I think this is mostly automatic when {{Duplicate}} is used, but I often find myself creating redirects by hand when I've asked for files to be deleted by other means. As Help:File redirect explains, creating a redirect when the first file still exists won't work properly: uses of the first file name will still return the first file. If you really wanted to keep the first file around, I suppose you could rename it and then update the resulting redirect, though I don't think that's really covered by any criterion of Commons:File renaming. --bjh21 (talk) 21:19, 23 September 2024 (UTC)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 12:18, 26 September 2024 (UTC)
The problem is that most of these AI-generated images don't depict Javan rhinoceroses but white rhinoceroses, a different species entirely. (White rhinos have 2 or 3 long, sharp, curved horns, while Javan rhinos have only 1 short, blunt horn.) With there being an estimated 76 Javan rhinos left, there is limited media available for this critically endangered species compared to their more common and famous cousins. (These AI-generated images are stylized/anthropomorphized, so I'm not too worried about people mistaking them for the real deal. However, even as stylized representations they remain inaccurate because they don't capture the defining characteristics of the species.)
A potential solution could be to re-generate these images with a more general "Rhino" prompt rather than mentioning a specific species. This would be a significant undertaking however, as it would affect over 100 images, and the Wikibooks project is currently managed by one person. Given this, are there other suggestions from the community? ReneeWrites (talk) 12:53, 23 September 2024 (UTC)[reply]
The prompts for these was "Javan rhinoceros", so it would still be somewhere in the file (file name, description, or metadata). If the person who uploaded them is okay with the Javan part being scrubbed from the images that would probably be the easiest solution though. ReneeWrites (talk) 13:12, 23 September 2024 (UTC)[reply]
I don't think it's in the metadata. At least from what I've seen it's mostly in the file names and/or descriptions. Mainly the file names though. --Adamant1 (talk) 13:15, 23 September 2024 (UTC)[reply]
Yeah, the problem we found above is that to find "Javan rhinoceroses" on Commons, one should search for "Rhinoceros sondaicus", not "Javan rhinoceroses".
The second problem was that some AI pictures are prominently searchable as "Javan rhinoceroses" (contrary to files for animals which are under "Rhinoceros sondaicus") or indirectly as "Rhinoceros sondaicus" and that these don't represent either. Special:Search/"Rhinoceros sondaicus" gives good results.
I think a way to improve this is:
categorize AI generated images appropriately, whatever the prompt was used. If they are "rhinos in art" (or by AI), they shouldn't be in "Javan rhinoceroses in art" (or by AI).
OK, thanks , i think about the same, but i am not very expert in templates (not at all) . Maybe the creator of them can give some help, thanks JotaCartas (talk) 21:54, 23 September 2024 (UTC)[reply]
The tools for creating and displaying High Dynamic Range (HDR) images are starting to mature. HDR displays can render much brighter highlights than before, which leads to a big qualitative improvement in an image. Software for HDR production, and web-browser support, are becoming wide-spread. (Note that this is distinct from the tone-mapped HDR images you may have seen for the past decade or so.)
My test results are at Category:HDR gain-mapped images. Both images survived the process of uploading and rendering previews. HDR metadata was stripped from preview images, but preserved in the original uploads. If you have a newish HDR screen and a compliant web browser, the originals of this house and this church will appear brighter than usual. The effect on the house is subtle, limited to where sunlight hits white paint. The effect on the church is more dramatic: the windows should appear much brighter than the rest of the interior.
Most users of Commons images will see one of the smaller standard files, so for now the benefits of publishing this sort of content are limited. Are there any downsides to publishing it on Commons?
This post isn't marked as a proposal, because hosting these images on Commons works already. At a later date, when the standards are settled and the hardware is widely available, it would be nice to preserve HDR metadata in the generated preview images. — Preceding unsigned comment added by Semiautonomous (talk • contribs) 23:51, 23 September 2024 (UTC)[reply]
September 24
Are AI system capabilities of "Reading comprehension" higher than humans?
I very much doubt / disagree with that. I think this is another case of AI hype which doesn't seem to be a first for OWID.
The chart only says "Reading comprehension", and not for example "Measures of reading comprehension according to organization X" / test Y or anything of that sort. This is why I added {{Factual accuracy}} with the optional short explanation (there's lots of more sources for that) Testing for "Language understanding" and "Reading comprehension" is flawed and AI as of 2024 is not on or above human level for at least these. Many sources like this support that it's flawed. However Alenoach (talk·contribs) removed it arguing on the talk page GLUE and SQuAD are widely accepted as benchmarks for evaluating language understanding and reading comprehension. Even if that was the case, that chart does not say something like "according to GLUE and SQuAD measures" but is absolute so I think template would be warranted even if the user was right. Also see the other measures where "AI" is allegedly above human performance or approach it. Moreover, there's many tests that would suggest otherwise and these are not included or considered here so the accuracy is still disputed.
Moreover, I'd be interested if there is a place better suited to discuss accuracy issues like this or some project here otherwise engaged with accuracy issues with media on WMC such as working on identifying more of these. I don't know of a better place to ask and this could be closed and archived if solved or if a better place is found. --Prototyperspective (talk) 00:02, 24 September 2024 (UTC)[reply]
For information, here was my comment on the talk page:
I removed the "factual accuracy" because GLUE and SQuAD are widely accepted as benchmarks for evaluating language understanding and reading comprehension. These benchmarks are not perfect and have limitations, but they offer objective metrics to assess AI models in these areas. The linked article is quite opinionated, rejecting the idea that LLMs aim for truth and arguing that they merely "bullshit" (despite truthfulness being one of the goals of RLHF). And the article does not challenge the validity of GLUE or SQuAD as benchmarks for these specific tasks.
My impression is that the linked article is more of a philosophical essay that contends that LLMs really don't care about truth. This is a controversial claim, but even assuming this were true, are there major language understanding or reading comprehension benchmarks on which the latest frontier models have poor results compared to humans? On the other hand, I agree with you that it's a problem that the name of the tests isn't directly in the graph. Perhaps I could try to make a derived version based on the SVG, which would present it in a format like "SQuAD 1.1 (reading comprehension)" rather than "Reading comprehension", that would be more precise. Alenoach (talk) 00:57, 24 September 2024 (UTC)[reply]
The 2024 AI Index actually has a very similar graph, and doesn't mention Kiela et al.Similar image from the 2024 AI index It contains less information, but can be a good replacement to the image from Our World in Data if needed. Alenoach (talk) 18:05, 24 September 2024 (UTC)[reply]
Note that this is not about the particular source, there's many sources that support this (some examples: 1234567).
Even if some points of Alenoach were good and the recently added file description mitigated the problem a bit, the file accuracy template at least would still be due to how the chart is titled and subtitled. Prototyperspective (talk) 16:09, 24 September 2024 (UTC)[reply]
What the heck is "Reading comprehension with unanswerable questions"?? Is that like "Read Dostoevsky and tell me whether or not there is a purpose to human suffering?" Nosferattus (talk) 04:44, 26 September 2024 (UTC)[reply]
The contents are the equivalent of selfies, they do not meet any notability criteria, this is not facebook. What's interesting here is they were transferred from a Flickr account so not selfies as such.
Hi, I've created a category for this because this is a large set of images. This specific set seems important to me because depicts a girl in many activities, filling a gender gap in some of them (e.g. she is a maker, not many girls has this opportunity).
Also, if we're going to host such a large collection of images of this presumably non-public figure, it would be really nice to confirm that she is OK with this (via Fabrice), even if it is not strictly necessary legally. Otherwise, it just feels a bit... iffy from a privacy perspective. Two or three photos, fine, but 295? Nosferattus (talk) 04:36, 26 September 2024 (UTC)[reply]
Hmm, looks like Fabrice hasn't been active in the past 9 years. Does anyone else feel like there might be a privacy issue here? Aside from the huge number of photos, there's also lots of private information in the descriptions, like her age (14), birthday, names of her and her relatives. I'm not sure it violates any policies, but it definitely feels problematic. Nosferattus (talk) 05:06, 26 September 2024 (UTC)[reply]
They are already on his Flickr. Removing it here won't really change anything. From the context it's safe to assume he had consent to take the photos Trade (talk) 17:11, 26 September 2024 (UTC)[reply]
Dating categories of old newspapers with news from many dates and places
A letter to the Haitian people of 25 december 1799.
News from Coni (Italy) arriving on 27 december, but the events are of course much earlier. There is an 27 december reaction in Paris. I would suggest to ignore this.
This is totally tangential but how do things like that work with the calendar that was being used during the French Revolution? Is it just ignored or do you translate it into the normal calendar or something? --Adamant1 (talk) 15:04, 24 September 2024 (UTC)[reply]
Interesting. I have some letters from the French revolution and slightly before then in France that I'm planning on scanning and uploading at some point. Hopefully next month if I have the time. Unfortunately I don't speak the language though. Any chance you'd be interested in helping me date them and translate the basics so they can be categorized properly and whatnot? --Adamant1 (talk) 15:54, 24 September 2024 (UTC)[reply]
It helps if you know some French, but it is not stricly necessary. Taking the text with OCR or taking over de text manualy, you dont need to know French. There is a smal problem: the spelling checker works with modern French, but gives errors for words spelled the ancient way. And there is a French verb conjugation dat is no longer used. The original spelling has to be respected. There are very few real errors and these can be treated with a correction template (the original text included errors has to remain accessible). However is the text is badly printed, it is sometimes difficult to read the letters. You wil get the feel of it. Examples A/M: bâtimens/bâtiments, déja/déjà, habitans/habitants; extinct Verbs: faisoient, formoient, commandoit (in modern French: past tense: commandait). But dont worry: 99 percent of the work is taken over the text verbatim. Later the text can be corrected and verified.Smiley.toerist (talk) 22:28, 24 September 2024 (UTC)[reply]
How to make my file be selected as the media of the day on the main page?
Hello! I am one of those new users on Wikimedia Commons. I want that my file be selected as the media of the day on the main page. How do I do that? Please, help me. I'm pretty sure that the file I posted it is in the public domain and for the proof, there is it. — Preceding unsigned comment added by Heitor Gois (talk • contribs) 15:06, 24 September 2024 (UTC)[reply]
There's no French Wikipedia article. The few photos I've seen were not in use anywhere. He has a very limited number of hits on Google, mostly his own publications, videos. I found one interview--in a French regional newspaper. I'm willing to bet the majority have been uploaded to Commons to use as an image hosting site for whatever reason...wouldn't be my first choice! Bastique☎ appelez-moi!21:25, 24 September 2024 (UTC)[reply]
Yes, right. I deleted most book and album covers, for a start. Really too many portraits, and as these are not selfies, we need the photographer's permission. I also deleted the user page, and blocked him for a week. Yann (talk) 21:44, 24 September 2024 (UTC)[reply]
Mr. Boucheix does appear to be a singer with some published works - not that that's necessarily a difficult bar to meet nowadays - but notability by Wikipedia's standards seems unlikely to be met.
Certainly not. Images of text are rarely in scope on Commons, and these are no exception. If these were notable quotes, they'd belong on Wikiquote as text - but I seriously doubt that they are. The number of portraits seems entirely excessive as well.
Yes, there's definite copyright concerns here. The portrait photos like File:Bernard BOUCHEIX de REYVIALLES - Auvergne - mai 2024.jpg (of which there are a bunch) were clearly not taken by Mr. Boucheix himself, and the photographers aren't credited. The book covers and theater programs (which it looks like Yann just deleted) were clearly uncredited, potentially unlicensed derivative works as well.
@Gryllida I would definitely crop out the elements outside of the monitor. I don't know the relation between the main video and the CCTV video--but I'm not sure if cropping out the audio is necessary. Bastique☎ appelez-moi!00:00, 26 September 2024 (UTC)[reply]
I want to upload this image of Soviet chemist Tserevitinov, who died before 1947 and is clearly younger in the photo. I do not know anything about the author, but that is also the case with say Sergey Vavilov or Lenin, the former picture shot around the same time Tserevitinov died, and the author is unknown. What condition of the Russian public domain are they satisfying? Also can I use it to upload the image I proposed? Thanks, ExclusiveEditor (talk) 14:07, 25 September 2024 (UTC)[reply]
Thank you very much for asking here! At least the Vavilov image does give an original source. If the uploader had access to that source and could confirm that the image was published there anonymously, that would go a long way to establish its public domain status.
I think the issue with the image of Tserevitinov that you are proposing to upload is that we know absolutely nothing about its original publication.Felix QW (talk) 19:59, 25 September 2024 (UTC)[reply]
Just noticed that you mentioned you could rename the files as well. It's possible to rename the redirect without leaving a redirect behind, which functions almost the same as deleting it. ReneeWrites (talk) 16:35, 25 September 2024 (UTC)[reply]
September 26
User who creates useless categories
I found an user continue to create personal and useless categories even after warnings on the talk page. How should I deal with this? Should I report as vandalism? Bart Buchtfluß (talk) 03:06, 26 September 2024 (UTC)[reply]
@Adamant1: The problem is what Enhancing999 stated. Thanks for the comment.
@ReneeWrites: He certainly has a useful uploads, but he doesn't understand my advice on the talk page. If he continues this, I will report him to COM:AN/U. Thanks.
@Enhancing999: Certainly. Thanks. I warned once that "Category:Cross & Feather Architecture"(speedy deleted) is a personal and subjective theme and is not appropriate as category of Commons, though he created almost the same category, Category:Cross & Architecture again. He and I are both Japanese speakers, actually, but I couldn't understand what talking about. Perhaps he created Category:Cross & Architecture as a personal collection. All media in this category are attributed to him. Bart Buchtfluß (talk) 13:15, 26 September 2024 (UTC)[reply]
My guess looking at the category is that they were trying to create a category for images of crosses on buildings. As opposed to say ones at a gravesite or something. I could see where a category like that might be useful depending on the circumstances, but Category:Cross & Architecture clearly doesn't make sense and it seems like there's a broader consensus against similar "X subject and Y subject" type categories. So I don't know. Maybe it could be workable with the right name though. --Adamant1 (talk) 13:23, 26 September 2024 (UTC)[reply]
I was looking through Category:PD textlogo recently and there seems to be a lot of things that are licensed as "PD textlogo" that either cantain graphs at best or aren't logos to begin with at worst. To give an example, there's the various OneNote logos, which clearly contain graphics. there's also book covers, which clearly aren't logos even if made up of simple text. CD covers, which again aren't logos despite having simple text. despite having text. There's also weirdly some charts using the template. I think people get the point. It seems like the usage of "PD textlogo" is all over the place to the point of being essentially meaningless. So I'm wondering there should be more specific templates for simple works of art or things that contain text that aren't logos. Like a "PD-textlabel" for CD labels or a "PD-textchart" for simple charts that are mainly text. Maybe there's a better solution though. Anyone have any thoughts or ideas about how to deal with it? Adamant1 (talk) 13:18, 26 September 2024 (UTC)[reply]
It might be because the text hasn't been translated into other languages yet. It looks like the last update to other pages besides English was in May. That's the only thing I can think of though. --Adamant1 (talk) 16:04, 26 September 2024 (UTC)[reply]
Publishers info in newspapers
We have a name for the masthead on page one, but what is that paragraph on page two that contains info on the publisher called? I want to direct people to where the copyright symbol is/isn't in various newspapers. RAN (talk) 17:59, 26 September 2024 (UTC)[reply]
Maybe the credit line or word mark depending on the situation? My money is on it being the credit line. It's hard to say without an example though. --Adamant1 (talk) 18:31, 26 September 2024 (UTC)[reply]
Support ReneeWrites opinion about it. Although I think Jmabel makes some good points, but I don't see them as mutually exclusive or applicable in every situation. Just to give an example from Jmabel's comment, don't forget the multilingual aspect of this, I'd say it depends on the topic of the category and what level down it is. For instance if we're talking about shoes and the person is browsing through Category:Shoes to find images of them then I don't think it's necessary or helpful to have the word "shoes" translated into every single language possible just because this is a multilingual project or whatever. It's a pretty good bet that most users know what a shoe looks like and has heard the word in English before. So there's zero reason to translate it or to have a description, in English or any other language. "Shoes are things you wear on your feet." No really? We don't need that in English, let alone 10 other languages..svg/15px-Pictogram_voting_comment_(orange).svg.png)
Comment Generally agree except for the point 4. For example a link to a github repo may not be a reliable source at WP but still relevant and useful in a category about the software without a Wikidata infobox. Another problem is that several links in the Wikidata item don't show up in the infobox and something should be done about it there instead of adding a link also to official website (example: links to mediawiki.org in the "Multilingual sites"). Another caveat is that I don't know how Web search engine indexing works and that "No repeating of information that can be found in a parent category" is ambiguous – if you mean useful info that is not self-explanatory should be excluded in a category just because it's already in the parent category then I disagree (e.g. people may have gone directly to that cat from search results or a file instead of having seen the parent cat earlier). Prototyperspective (talk) 19:46, 29 August 2024 (UTC)
Weak oppose Maybe for type-written works it makes sense to only have a PDF, but for hand-written it's often really useful to have higher-resolution files and if they were combined into PDFs the PDFs could be quite large. A small example could be something like this where it's often useful to be able to zoom right in on a letter to better see the pen strokes etc. It's also more likely that people preparing PDFs will end up with trusting whatever their scanner software gives them and by doing so be throwing away information that we'd rather keep (e.g. postmarks on letters). I wonder if more could be done with the search system and structured data to make it easier to exclude individual scans? Sam Wilson 04:47, 8 September 2024 (UTC)
Oppose Strongly opposing. If such PDFs would be converted one (the person converting it) would have to make sure that each and every Wikisource page would work as before. If we have 300 pages in the PDF that makes 300 pages on WS to be changed. I am not sure about wether they are needed to be modified only on one place; this Wikisource techniques/syntaxes are quiet obscure to my though I am taking part in the project. So what would be achieved? Editing tenthousands of Wikisource pages to reduce the number of PDF files for several ten thousands whereas we are hosting 120 million files on Commons? Produces lot of server load for nothing. --Matthiasb (talk) 07:02, 17 September 2024 (UTC)
Weak support If a complete book scan of x-dozen up to some x-hundred single text pages gets uploaded, and is not in use for Wikisource (!), then I think that all the pages can be collated into a single PDF, which can then replace the single-page scans. Note that my opinion states "can", not "should". It depends on the intended use case and the interest that gets placed on a book. If all single-page-scans remain contained in their intended scan-category, I have no problem with them being loose, not bound. Also, I checked the first example in the OP again: yes, these are single-page scans, but only of the 37 illustrated pages from a 200-page book. For a PDF, we need to have all pages; while the ones in the category should have the text clipped away, to make the images usable as illustrations (Edit, upon rereading, this point was also made by Adamant1, so I support that opinion). On another hand, if PDF-conversion means OCR treatment is simpler, then I'll strongly support this. --Enyavar (talk) 13:45, 20 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)
Info: Now at Commons:Deletion requests/File:Sanija selfie.jpg—Alalch E. (talk) 14:34, 21 September 2024 (UTC)
Neutral I'm not sure this is the answer to dealing with the problems caused by AI images. I think another proposal for putting "AI generated" in file names of AI generated artwork would be a better solution. Since it's not so much where the images show up in search results, but that people often don't know the images are AI generated to begin with. People can still accidently get an AI generated image if they are pushed down in the search results. What we need is better ways to clearly identify and deal with AI generated artwork to begin with. I feel like it's mostly a curation issue at this point though. --Adamant1 (talk) 00:32, 20 September 2024 (UTC)
This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 12:18, 26 September 2024 (UTC) 
.jpg){kind=link}
![[2]](https://commons.wikimedia.org/wiki/File:Moumita_Debnath%27s_in_graffiti_at_Dhaka_University.jpg){kind=link}
![[3]](https://commons.wikimedia.org/wiki/File:Protest_against_Kolkata_rape-murder.jpg){kind=link}
.jpg){kind=link}
.png){kind=link}
.jpg){kind=link}
%27_(15968009014).jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
_Country_Grammar_by_Nelly_(CD_single)_(UK-2000).jpg){kind=link}
_showing_Israel%27s_1948_and_1967_borders.svg)
.svg)