Commons:Village pump/Proposals/Archive/2025/03

Set a default language for SDC data

Whenever you try to add an Monolingual text statement to an image you have to scroll past 200+ languages just to get to English which is an awful, awful UI experience that only discourages people from adding monolingual text statements.--Trade (talk) 14:40, 15 March 2025 (UTC)

@Trade: I always get English offered right at the top. I wonder if there is a preference thing involved. Do you just get a simple linear list (I don't. I get some common languages at the top, then a breakdown by regions). FWIW I user Firefox on a PC. - Jmabel ! talk 16:48, 15 March 2025 (UTC)

My issue is with the breakdown by region. I dont feel that method is very user friendly Trade (talk) 17:47, 15 March 2025 (UTC)

You need to place babel boxes with the languages you speak on your user page to have these languages on the top. GPSLeo (talk) 16:56, 15 March 2025 (UTC)

It's not about being on top. I just dont want 200+ languages that i wil never use on Commons cluttering up the page for no reason

Doesnt matter anyways. My PC decided to logout while i was away from it so all my work in SDC is lost now since the browser closed Trade (talk) 17:20, 15 March 2025 (UTC)

I do have to wonder if having languages like "German" hidden at the very middle of the list while the top is filled with constructed languages that nobody on Commons even uses when editing. Like why? --Trade (talk) 17:40, 15 March 2025 (UTC)

As for last, having to find languages by their native spelling is extremely jarring. Like, every single category on Commons related to the German language uses the english spelling. And yet this specific part of Commons uses "Deutsch" which is nothing like how it's called on the rest of Commons. Idk it just makes me not wanna ever touch SDC when it's so jarring to the design and norms of the rest of Commons. Like, it cant decide whether it wants to be a part of Commons or it's own thing which just happens to be transcluded on media files.--Trade (talk) 17:52, 15 March 2025 (UTC)

The search for a language to add works with all languages for me. I can type in french, francais or französisch and always get the same result. GPSLeo (talk) 07:42, 18 March 2025 (UTC)

Flagging and filtering of structured content edits

Hi - my name's Sam and I'm the Product Manager for the Moderator Tools team. We're currently scoping some work based on the Task prioritization Community Wishlist focus area. There are two wishes in this focus area regarding identifying and filtering Structured Data content on Commons. The idea would be to flag edits which are structured data changes in venues like Special:RecentChanges and Special:Watchlist, so that you could filter for only these edits, or filter them out of those views. I wanted to get a wider pool of opinions on the value of making this change - would you find such a filter useful for any of your workflows? Is there anything we should be aware of if we were to implement these suggestions? Thanks in advance, Samwalton9 (WMF) (talk) 18:37, 17 March 2025 (UTC)

Please add the ablity to toggle bot and human edits separately (mainly due to multichillbot and schlurcherbot). All the Best -- Chuck ^Talk 20:58, 17 March 2025 (UTC)

Agree. I'd want to filter out bot edits to SDC, but not human edits to SDC.

It would be even better if I could specify exactly what users (bot or otherwise) were filtered. E.g. I'd really like to be able to filter out Emijrpbot but not DPLA bot. - Jmabel ! talk 01:00, 18 March 2025 (UTC)

Thanks for sharing - this makes sense. I think if this was, theoretically, added as a filter in RecentChanges, you would be able to filter both on this and bot/non-bot edits. I'll make sure I keep this in mind if we moved forward with this. Samwalton9 (WMF) (talk) 09:29, 18 March 2025 (UTC)

Filtering by specific human user might also be useful. For example, there was recently a decision to rename the category tree regarding humans and gender (i.e. "Female humans" > "Female people"). As a result large numbers of categories and files were moved by a particular human user. It so happened that I had some affected categories on my watchlist and consequently my warchlist was flooded with those moves. There's also a limit to how many new edits the watchlist can display — 255 I think? —, so that I was unable to see any edits on my watchlist other than the ones related to the mass moves. Nakonana (talk) 17:18, 18 March 2025 (UTC)

Yes please. There was also recent question about hiding SDC bot edits where my answer was that they can hided by adding CSS rule to hide rows with BotSDC-tag (see Commons_talk:Structured_data#Hide_SD_edits ). So request would be to be able to hide automated bot SDC edits (and if possible select which bots would be hided, mut even if filter would be for all bot SDC edits it would be great) --Zache (talk) 01:09, 18 March 2025 (UTC)

The tagged edits can already be hidden like every other tag in the regular watchlist settings. I think we should have three main tags for every edit "Wikitext edit", "SDC edit" and "Caption edit". The watchlist and recent changes should then allow free configuration on what to show based on the user type (bot, user, anon, (auto)patrolled) for every tag separately. GPSLeo (talk) 07:35, 18 March 2025 (UTC)

How do you get specific tags hidden in the standard watchlist? Keith D (talk) 20:04, 18 March 2025 (UTC)

There is a Tags button to the right of the Filter changes bar. It opens a menu to select tags and there is the option to exclude the selected tags.  $999$REAL 💬 ⬆   20:11, 18 March 2025 (UTC)

I do not get a Filter changes bar. Keith D (talk) 21:43, 18 March 2025 (UTC)

I use Vector legacy (2010) theme. I don't know if that changes anything. Here is what I see File:Tags filter in Wikimedia Commons watchlist 18 March 2025.png  $999$REAL 💬 ⬆   22:03, 18 March 2025 (UTC)

I use Monobook skin which does not appear to have these options. Keith D (talk) 22:37, 18 March 2025 (UTC)

I also use Monobook. Are you telling me that you don't see any options to filter at Special:Watchlist? —Justin (koavf)❤T☮C☺M☯ 22:54, 18 March 2025 (UTC)

Yes. Here is what I see. Keith D (talk) 23:28, 18 March 2025 (UTC)

I see a "Show" button there. Maybe it opens the filter menu  $999$REAL 💬 ⬆   23:34, 18 March 2025 (UTC)

The Show button just runs the selected query to give you the watchlist lines. Keith D (talk) 23:38, 18 March 2025 (UTC)

@Keith D The tags menu shows up when you click the search bar in monobook. All the Best -- Chuck ^Talk 00:08, 19 March 2025 (UTC)

Have not got a search bar, only search in left hand pane which takes you to Special:Search page, see screen shot Keith D (talk) 02:09, 19 March 2025 (UTC)

@Keith D It's likely that you have the "Use non-JavaScript interface" preference selected in the 'Recent changes' tab in Preferences. Samwalton9 (WMF) (talk) 14:29, 19 March 2025 (UTC)

The "Use non-JavaScript interface" preference is not selected in the 'Recent changes' tab but is in the 'Watchlist' tab. Keith D (talk) 17:42, 19 March 2025 (UTC)

Yes that works, but much prefer the existing one for general use. Which is the one this task was raised for rather than have to use tags, filters etc. Keith D (talk) 17:56, 19 March 2025 (UTC)

Add "publication titles" as an exception to "Category names"

I think, it has been at least a convention that categories of publications (including but not limited to books, magazines, pamphlets...) are given titles in their original names in the original writing scripts. But this is not explicitly mentioned in Commons:Categories#Category names, so it should be added.

Older discussion: Commons:Village pump/Proposals/Archive/2019/08#Category titles with scripts other than Latin. RoyZuo (talk) 10:40, 30 March 2025 (UTC)

It looks like at least subcats of Category:Magazines of China by name and Category:Magazines of Russia by name use Latin script and are mostly in English. So is that actually true? --Adamant1 (talk) 21:21, 30 March 2025 (UTC)

Phase out some categories for black and white photographs in favor of SDC data

A lot of the categories for black and white photographs are super pedantic and get in the way of people organizing images by date, subject, location or another criteria. They are also super pointless in a lot of instances because all photographs by a particular photographer or of a specific location and/or date are black and white to begin with. People also don't seem to know what a black and white image is. Like to give Category:Black and white postcards of Piran and it's parent category Category:Historical black and white photographs of Piran as examples, most or all of the photographs in them are in fact sepia. Either that or blue tinted. Neither of those are "black and white" though and it seems to be a pretty regularly occurring issue.

So my proposal is to up-merge a good portion of the more pedantic categories for black and white photographs where it clearly doesn't serve a meaningful purpose and use SDC data for what type of photograph it is instead. There's currently color (Q1075) and black-and-white (Q838368). As well as sepia (Q767608). All three of them can be used for labeling photographs as black and white or sepia. I don't think using categories is a good way to do it in most cases though.

But just to be clear, I'm not advocating for the whole sale emptying of categories containing black and white photographs. I'm proposing the slow transfer of the information about what type of photograph it is to SDC data in conjunction with phasing out the more pedantic, less useful categories once that happens. Although I'm not going to propose specific categories to get rid of right now because I'd like to at least establish a baseline level of acceptance for the general idea first. People can, and should, figure out what categories to phase out if or when this is approved though. Adamant1 (talk) 03:41, 8 March 2025 (UTC)

I mostly agree with the principle here, with one exception: I think it is no problem at all that "black and white photograph" is used as a synonym for "monochrome photography" and includes sepia prints, as long as we are consistent about that. Categories like this are already wildly overly split, and I'd hate to have a new set of "sepia this" and "sepia that" to sort through when I'm actually interested in the subject matter, not the medium.

My own inclination is that "black and white photographs" should just be a "tag" or a flat category, completely orthogonal to subject matter, but that fight seems long since lost. - Jmabel ! talk 04:44, 8 March 2025 (UTC)

I certainly agree with upmerging as much as possible. In the vast majority of cases, it's not useful to subdivide categories in that way. (This seems like one of these cases where SDC could be really useful - being able to filter any category or search results by basic parameters like B&W/color, image size, and license.) Pi.1415926535 (talk) 06:07, 8 March 2025 (UTC)

I support the overall direction here. Being able to search (thanks to SD) for "only B&W pictures of <subject>" would be more helpful than browsing overcrowded categories. More tags could indicate "sepia", "photograph", "line art" (is also B&W), "greyscale", "blueprint". "Category:Black and white portrait photographs of standing women at bust length" are not helpful, because it mixes too many and partly contradictory statements: "B&W", "portrait at bust length" and "standing woman". We probably have 10x as many images that also fit those criteria, but they are not yet categorized that way: For that reason, I suggest to keep the categories for now, and first populate the SD. --Enyavar (talk) 17:06, 1 April 2025 (UTC)

 Oppose For SD there is no category page. It also can't be used with petscan. @TheImaCow, you don't need to navigate +34,000 photos, you could use either

• its subcategories or
• the deepcategory (or incategory) search parameter along with a search term or petscan

to find what you're looking for. Prototyperspective (talk) 00:35, 14 March 2025 (UTC)

I've been told one can use petscan with SD queries but I have not done it myself. Maybe there are limitations I'm unaware of? Search is under "other sources" Jerimee (talk) 22:36, 1 April 2025 (UTC)

@User:Prototyperspective A structured data query can be used with petscan. Here is a link with the configuration: https://petscan.wmcloud.org/?project=wikimedia&language=commons&ns%5B6%5D=1&comb_union=1&search_max_results=2000&search_wiki=commonswiki&search_query=haswbstatement%3AP31%3DQ365552%20haswbstatement%3AP180%3DQ7246 See the other "sources tab." In the middle is search and the first field is my query. I've prepopulated it with instance of (P31) → line art (Q365552) and depicts (P180) → unicorn (Q7246). Click the "Do it!" button and you should get 46 results. Sharing this in hopes it might be helpful. Jerimee (talk) 03:18, 2 April 2025 (UTC)

Interesting, thanks. This is not accessible and should probably be made much easier where one has fields for instance of and depicts that one can enter things into with autocomplete. If the info on whether it's black-and-white is "phased out" then all the images that have it currently in the categories should have the SD set and accessing that subset should be made as easy and available from the same places from where one can see the subcategories. That could be a multiselect in the category page where one filter to select is for seeing the subset of black-and-white photos. (The other common filters would make use of categories, SD, or both.) Prototyperspective (talk) 13:30, 2 April 2025 (UTC)

That is not accessible and should probably be made much easier Absolutely! I may attempt to improve the documentation. I was only able to figure it out with support from other users and trial and error - I would not have been able to find that field on that tab by myself. Jerimee (talk) 18:38, 2 April 2025 (UTC)

Hmm… "super pedantic"?, seriously? -- Tuválkin ✉ ✇ 00:44, 14 March 2025 (UTC)

 Support the idea, I have no comments about the concrete implementation. Category:Black and white photographs contains +34,000 photos, which is useless for navigation, and it does not make sense to mirror our complete category tree to include "Black and white photographs of <existing category>". Note that there are also countless black&white photographs, which do not have that fact reflected by existing categorisation, so it might be possible to automatically find and tag such untagged b&w images ~TheImaCow (talk) 02:11, 11 March 2025 (UTC)

Many of those 34K images were categorized as black & white using a gadget like "Cat-a-lot". Maybe restricting those from dishing out pointless categories would be a better option. Alexpl (talk) 18:37, 13 March 2025 (UTC)

Are you seriously suggesting that editorial workflows you personally dislike should be made impractical by crippling existing tools? Could people who dislike SDC suggest the same?, (without being imeediately blocked?) -- Tuválkin ✉ ✇ 00:42, 14 March 2025 (UTC)

Move File:Flag of the Syrian revolution.svg to Flag of Syria.svg

al-Sharaa had just made this flag the permanent one. SpinnerLaserzthe2nd (talk) 17:26, 31 March 2025 (UTC)

I think the redirect from File:Flag of Syria.svg works better than a move, though we might now want to rename File:Flag of the Syrian revolution.svg as File:Flag of Syria (2025-) (or something similar) and have both File:Flag of Syria.svg and File:Flag of the Syrian revolution.svg redirect to that. FWIW, I would advocate an equivalent approach for any country: it is best that File:Flag of FOO be a redirect, so that everywhere that it simply refers to a geographic area and not a regime, a sister project can always know that if that country's flag changes, the image will be updated accordingly. Meanwhile, if you are referring to a regime, even the present one, or to the flag itself you can make sure that the image will not change in the future by using the more specific name. - Jmabel ! talk 22:50, 1 April 2025 (UTC)

@Jmabel: for reasons of grammar, "File:Flag of the Syria (2025-)" should read "File:Flag of Syria (2025-)".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:11, 2 April 2025 (UTC)

Typo, now fixed. Thanks, @Jeff G.. - Jmabel ! talk 19:19, 2 April 2025 (UTC)

I would be fine with Jmabel's proposed move. I'd wait a few more days to see if there is any more feedback on it (for or against) before I'd pull the trigger on the move. Abzeronow (talk) 19:39, 2 April 2025 (UTC)

I've moved the file to File:Flag of Syria (2025-).svg per discussion. Abzeronow (talk) 20:57, 4 April 2025 (UTC)

• Support. Also, File:Flag of the Syrian revolution (small stars).svg should also be moved. @Abzeronow, Jeff G., and Jmabel:

Panam2014 (talk) 01:29, 6 April 2025 (UTC)

File has been moved. Abzeronow (talk) 01:46, 6 April 2025 (UTC)

Consensus for "de minimis items should not be represented by depicts"

I wrote this in Special:Diff/1014791147/1014791524, but do we have consensus for it? I think so, but I could be wrong.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 21:06, 31 March 2025 (UTC)

In fact, a "depict" statement is diametrically opposed to COM:De minimis. If someone is plausibly claiming a depiction of something in a photograph, then this something cannot be De minimis, as the latter is based on a total insignificance of the something for the image. So, you either have a depiction of an object or an incidental, minimalistic inclusion of it, but not both at the same time. Regards, Grand-Duc (talk) 22:44, 31 March 2025 (UTC)

@Grand-Duc: Thanks. May I take that a "support" !vote?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 22:56, 31 March 2025 (UTC)

So many items have no depicts at all. Isn't some info better than none? Jerimee (talk) 23:08, 31 March 2025 (UTC)

•  Support The more depicts statements you use the less useful they are. Kind of like turning on a water hose. You don't want it on full blast just to water your flowers. --Adamant1 (talk) 23:38, 31 March 2025 (UTC)
•  Support as per Adamant and Grand-Duc, also as per my comment below. --Enyavar (talk) 16:42, 1 April 2025 (UTC)

  OK let's just ignore the guidelines? Commons:Structured data/Modeling/Depiction

  If we ignore the work of the people who are taking the lead on SDC, what hope do we have of people adhere to new proposals.

  Additionally, the more rules we create on how depicts is used the less useful those rules are. They will be hard to absorb.

  What problem does this proposal seek to address? Jerimee (talk) 23:54, 31 March 2025 (UTC)

  @Jerimee: See COM:ANU#User:Blessingedi76 (the beginning is linked in my OP).   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:02, 1 April 2025 (UTC)

  I'm not clear how that is relevant. They were adding awards? That is just a mistake right? Was the award actually pictured in the file, but in the background and easily overlooked and perhaps not dreadfully relevant?

  I guess I'll take another look but I feel foolish trying to guess. Jerimee (talk) 01:09, 1 April 2025 (UTC)

  where is the photograph in File:Marelle de livres, Hommage á Julio Cortázar (2014).jpg? As you know there thousands of files with this mistake; it is super common mistake to make. search depictions of photo Jerimee (talk) 01:17, 1 April 2025 (UTC)

  They added depicts to an award here File:Juryvorsitzende Svenja Plaspöhler auf dem der Großleinwand.jpg presumably because that file has main subject of some award. This kind of mistake is ubiquitous.

  Also what does it have to do with your proposal? This is not an instance where someone used depicts to refer to a trivial element actually depicted. They simply didn't know what property to use. Jerimee (talk) 01:27, 1 April 2025 (UTC)

  @Jerimee: In File:Marelle de livres, Hommage á Julio Cortázar (2014).jpg, there appear to be lots of books laid out, some of which have photos on their covers, which covers are at an oblique angle, but I would class all of those photos as de minimis.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 01:36, 1 April 2025 (UTC)

  OK good. Thanks. I think I agree with you proposal in theory, but not in practice at this time. It might create more confusion than clarity. But, to your point, if someone was to list things that are barely visible but technically present in a image, depicts (P180) isn't really appropriate for that. Jerimee (talk) 02:19, 1 April 2025 (UTC)

  The photographs on the ground are literally the subject tho Trade (talk) 06:32, 1 April 2025 (UTC)

  @Trade: According to the uploader, they are books, many of which look to have photos on the covers.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 09:26, 1 April 2025 (UTC)

  With that photo, I don't think that "depicts:humans" and "depicts:trees" are good depicts-statements, unless there is a possibility to also mark them as "background" (i.e. a contrary statement to "mark as prominent"). @Jerimee, in the guidelines I see nothing about marking non-prominent background features. Yes, File:VTA bus 0132 serving route 26 in downtown Campbell.jpg depicts a streetlamp and a cypress tree. These mostly obscured/cropped background objects should not be marked via SD. --Enyavar (talk) 16:42, 1 April 2025 (UTC)

  Lol I was ready to disagree but yeah looking at the photo, I had to look twice to even find the people. Good example; depicts:humans is probably unhelpful in this case. But I wouldn't want users, especially new users or users unfamiliar with SDC, to receive negative feedback for individual SDC contributions like youve described.. I guess I support the proposal, but have concerns over how it might be used or misconstrued. Thanks for the example. Jerimee (talk) 22:49, 1 April 2025 (UTC)

  The cypress trees takes up half the image. This is getting absurd Trade (talk) 02:10, 2 April 2025 (UTC)

  You mean in File:VTA_bus_0132_serving_route_26_in_downtown_Campbell.jpg? Yes, it would be entirely appropriate for that file to have depicts:tree - in fact I'll add cypress (Q14169641) presently.

  I think Enyavar meant File:Marelle de livres, Hommage á Julio Cortázar (2014).jpg when they mentioned that photo. In File:Marelle de livres, Hommage á Julio Cortázar (2014).jpg the trees are significantly less prominent. And the humans are only present as vague silhouettes in the background of the top left corner. Jerimee (talk) 02:33, 2 April 2025 (UTC)

  @Trade: Just to be clear, I'm not even sure which kind of tree that is, behind the VTA bus (now marked them with an annotation for the discussion's convenience). Instead of a cypress, it could also be some other evergreen. I'm not a botanist. / Jerimee is correct that I referenced the Marelle-photo in my first sentence.

  Other examples are busy photos (depicts:bananas; depicts black handbags); busy paintings (depicts: spoon; depicts: red trousers), and also any map (depicts: Tibet).

  There is a point where too granular SD-usage undermines the original point of SD, which was to make images searchable and accessible. --Enyavar (talk) 15:27, 2 April 2025 (UTC)

per recent discussion on my talk page, we currently have two project pages that contradict one another on this. Jerimee pointed me to Commons:Structured data/Modeling/Depiction which flat-out contradicts Commons:Depicts#What items not to add. I, for one, am firmly on the side of the latter, but I think the exchange on my page may be quite worth reading. - Jmabel ! talk 22:54, 1 April 2025 (UTC)

I skim-read the first link of yours and the talkpage exchange. @Jmabel, could you please clarify the "flat-out" contradiction you saw? I do not see much difference between Commons:Depicts#What items not to add and the section Commons:Structured data/Modeling/Depiction#Suggested best practices. The sentence there reading "The primary purpose of depicts (P180) statements on Commons is to identify, in a structured way, the items clearly visible in a media file." feels quite clear to me. Regards, Grand-Duc (talk) 00:55, 2 April 2025 (UTC)

Mostly the "parts of a bigger item" thing in Commons:Depicts#What items not to add. But I guess you are largely right, with only one example the guidance in Commons:Depicts is so vague it could be compatible with tagging every picture of a male adult human with man (Q8441) as well, and for that matter with putting room (Q180516) on every image that has nave (Q188714), restaurant kitchen (Q121039140), or bathroom (Q190771). Do we really want that? The one given example doesn't really explain why it stops at black hole (Q589), either. By the same logic, what about astronomical object (Q6999), or even Geraldine Somerville (Q235572)? I increasingly feel like we have no useful guidance at all. - Jmabel ! talk 19:33, 2 April 2025 (UTC)

Do we really want that? In short, yes. Somerville isn't visible though, so not Somerville. Jerimee (talk) 19:40, 2 April 2025 (UTC)

•  Comment How are you gonna avoid creating a chilling effect where Commons users refrains from using structured statements out of fear--Trade (talk) 02:15, 2 April 2025 (UTC)

"mark as prominent"

anything not the main subject, dont mark. anything else, mark. RoyZuo (talk) 13:17, 2 April 2025 (UTC)

The guides "Suggested best practices" and "Depicts" don't say anything about limits. That is true. But I don't think we should infer from these guides, that every detail in pictures needs to be tagged (see my examples above). In the millions of images that prominently depict specific streets/buildings, the road asphalt that regularly takes 25-50% of the images does not need to be tagged, regardless of its "prominence" in a picture. It can be tagged, of course, but I think our guides should be edited to discourage users from systematically tagging incidental generic items (road asphalt, trees, cars, humans) in images that are focused on other topics. Right now, when I search for "road asphalt"; I'm getting the results I want: mostly close-ups and asphalt-laying. If a user begins to systematically tag 80'000-8'000'000 images that incidentally depict roads and plazas, I'm less sure that the search will continue to be helpful.

On another note, refraining from tagging SD "out of fear"?? The worst that can happen is being reverted, is it not? While I think that tagging far-away background trees is counter-productive, those things are certainly done in good faith. Could SD be used for improper purposes, like pushing certain content for SEO? Probably, but this is not up to debate here. --Enyavar (talk) 16:30, 2 April 2025 (UTC)

anything not the main subject, dont mark [as prominent]. anything else, mark This is the answer. With regard to the appropriate specificity of P180 statements, these 10 words are sufficient most of the time. Simple and to the point. Jerimee (talk) 19:18, 2 April 2025 (UTC)

Thanks for this question Trade - this is also my major concern. And, as Jmabel pointed out above, the existing SDC documentation is somewhat ambiguous. Jerimee (talk) 18:51, 2 April 2025 (UTC)

 Support. depicts (P180) should be limited to subjects which are substantially present in, and relevant to, an image. It should not be used to tag every single perceptible entity in an image, and particularly not ones which are only barely visible, or whose presence is entirely incidental to the image. If we want to play "I Spy" and start tagging every object which is present at all within an image, that should be described with a different (new?) Wikidata property so as to not pollute results for P180. Omphalographer (talk) 18:46, 2 April 2025 (UTC)

As much as I don't want depicts (P180) to devolve into free tags, I think "what is relevant to an image" varies significantly from user to user. At the present moment, I think searches are more likely to suffer from insufficient results than they are from low relevance results. Jerimee (talk) 19:06, 2 April 2025 (UTC)

How exactly does this proposal stop people from tagging "what is relevant to an image"? They can still do that if this is approved, just not excessively and/or to an absurd degree. --Adamant1 (talk) 20:41, 2 April 2025 (UTC)

With regards to "relevant to an image" - what I'm trying to get at here is that some images, particularly photos of notable events or other dramatic occurrences, may incidentally contain entities which are entirely irrelevant to the action which is central to the image. For example, File:05 28 20 South Minneapolis (51177808789).jpg does not, in my opinion, meaningfully depict Chevrolet Tahoe (Q910928). Even though one such vehicle is clearly visible in the foreground, it's incidental to the photo in such a way that the photo isn't a usable depiction of it. Omphalographer (talk) 20:43, 2 April 2025 (UTC)

Um. I don't want to have check with Omphalographer each time I see a Tahoe to know if the Tahoe depicted is a meaningfully depicted Tahoe. An image can mean more than one thing. I appreciate the example. I wish I had a better reply. Jerimee (talk) 14:14, 3 April 2025 (UTC)

" depicts (P180) should be limited to subjects which are substantially present in" The fact that the "Prominence" tag exists means that objects that are not prominent are still meant to be tagged. Trade (talk) 04:31, 3 April 2025 (UTC)

"Mark as prominent" exists for all structured data properties. It's not unique to depicts (P180). Omphalographer (talk) 05:10, 3 April 2025 (UTC)

I would consider "Mark as prominent" for depicts to mean "This image could reasonably be used as a depiction of this subject."

Side note: at the time SDC was first being discussed, I had proposed a parallel "Mark as incidental." I still think that would have saved us a lot of grief, because if we'd done that at the outset, the obsessive inclusionists could do their thing, but we could have an easy mechanized way to keep this cruft out of searches. - Jmabel ! talk 18:01, 3 April 2025 (UTC)

When was SDC first discussed? Jerimee (talk) 19:08, 3 April 2025 (UTC)

• Roughly 2018. I think the very first discussions were in late 2017. - Jmabel ! talk 21:30, 3 April 2025 (UTC)

Just a idea that popped into my head: can't we have two statements, one being the current depict, reserved for the main motifs of the imagery? Another could be a contains for everything that is clearly identifiable (for instance, in the bus image above, the vehicle ID and the magnolia would be OK, but "contains: cypress" not, as it's only a pyramidal tree that could be also another kind). Regards, Grand-Duc (talk) 19:36, 3 April 2025 (UTC)

Technically it should be no problem to enable the deprecated rank from Wikibase on Commons. It would only need some UI changes. GPSLeo (talk) 19:43, 3 April 2025 (UTC)

I was thinking the same thing: preferred rank and deprecated rank seems like "out of the box" functionality that fits the bill. Just change the names to prominent and incidental. Jerimee (talk) 21:05, 3 April 2025 (UTC)

Just because it makes sense to carry deprecated statements on Wikidata doesnt mean it does on Commons Trade (talk) 11:45, 5 April 2025 (UTC)

I'm kind of interested in what people think of the depicts statements in The Last Supper (Q128910). Is anyone seriously looking at The Last Supper because of the pieces of bread on the table or care at all about them? To me it's like adding "depicts=bridge" to the Mona Lisa because there's a tiny bridge in the background. Nobody is searching for or looking at the Mona Lisa because of the bridge. --Adamant1 (talk) 23:42, 3 April 2025 (UTC)

Two things, A) somebody has definitely written a monogram about the bridge in Mona Lisa, B) there is a bridge in Mona Lisa?! Jerimee (talk) 06:28, 4 April 2025 (UTC)

Is it really that hard to believe someone might be curious about what the food on the table is supposed to be? Trade (talk) 11:46, 5 April 2025 (UTC)

Regarding The Last Supper (Q128910), A) someone has definitely written a monogram about the bread in The Last Supper, B) I'm pretty sure I've heard entire sermons about the bread at the The Last Supper, and even from multiple denominations of worship. Useful statements can be made. Jerimee (talk) 06:40, 4 April 2025 (UTC)

Weirdly, the bread in at the Last Supper may be significant on at least two counts.

1. The origin of Christian Communion would be that bread.
2. There is a widespread theory that the Last Supper would have been a seder; if it was, the bread as depicted by Leonardo would be wrong, since it would have to have been matzoh.

That said, the relevant "depicts" is already present in the Wikidata item. Are we really saying we should repeat all of the depicts values in a Wikidata item for a painting when we show a reproduction of that painting? - Jmabel ! talk 18:45, 4 April 2025 (UTC)

I wondered that too - though if File:Supper depicts Q123 should Q123 depict bread? I guess I think the depict statements should like autosync or something? I don't know. (Thanks for Last Supper facts btw.) Jerimee (talk) 18:56, 4 April 2025 (UTC)

Change colour of

the arrows in Turn 0.svg Turn 180.svg Turn 270.svg Turn 90.svg to something that works well on both white background and black background.

I dont know what's good. 0099FF might be a bright blue that might work? RoyZuo (talk) 19:46, 6 March 2025 (UTC)

I recommend you upload your own versions under new names. The Squirrel Conspiracy (talk) 04:02, 8 March 2025 (UTC)

Template:Rotate#Example. RoyZuo (talk) 08:57, 1 April 2025 (UTC)

Instead of changing colours, I came up with these svg, with a clearer subject (🌹) than the sunset image (which is kinda symmetrical).

Extended content

90 degrees <svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="150" y="50" transform="rotate(90, 150, 50)">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">90°</text> <line x1="70" y1="50" x2="129" y2="50" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg> 180 degrees <svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">180°</text> <text x="150" y="150" transform="rotate(180, 150, 150)">🌹</text> <line x1="70" y1="50" x2="152" y2="50" stroke="blue" stroke-width="5"/> <line x1="150" y1="50" x2="150" y2="129" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg> 270 degrees <svg width="200" height="200" xmlns="http://www.w3.org/2000/svg"> <style> text { font: bold 32px sans-serif; dominant-baseline: middle; text-anchor: middle; } marker#arrowhead { fill: yellow; stroke: blue; stroke-width: 1; } </style> <defs> <marker id="arrowhead" markerWidth="4" markerHeight="4" refX="4" refY="2" orient="auto"> <polygon points="0 0, 4 2, 0 4" /> </marker> </defs> <text x="50" y="50">🌹</text> <text x="50" y="150" transform="rotate(270, 50, 150)">🌹</text> <text x="100" y="100" fill="white" stroke="black" stroke-width="2px">270°</text> <line x1="50" y1="70" x2="50" y2="129" stroke="blue" stroke-width="5" marker-end="url(#arrowhead)" /> </svg>

RoyZuo (talk) 17:04, 25 April 2025 (UTC)