I think "Edits made at Wikidata" are something different than Structured Data edits on Commons. Also as noted in this related wish, one can already ignore AC/DC & Depictor & DepictAssist edits (which based on my watched pages make up most SD edits which are ~redundant to file categories anyway) by clicking on Tagged edits at the bottom then selecting it then selecting Exclude selected and saving the watchlist settings as default.

In short, functionally it's already largely possible and it shouldn't be called "Edit made on Wikidata".

In T380021#10326714, @Prototyperspective wrote:

I think "Edits made at Wikidata" are something different than Structured Data edits on Commons. Also as noted in this related wish, one can already ignore AC/DC & Depictor & DepictAssist edits (which based on my watched pages make up most SD edits which are ~redundant to file categories anyway) by clicking on Tagged edits at the bottom then selecting it then selecting Exclude selected and saving the watchlist settings as default.

In short, functionally it's already largely possible and it shouldn't be called "Edit made on Wikidata".

Ah, the screenshot is of the current interface, and this entry is for the existing flag for edits made to corresponding Wikidata items. I haven't mocked anything up here that's new. I'll clarify that in the task description :)

We could use S to denote such edits.

Just spotted that Wikistories uses S, so we should use something else for this. Maybe SD or SDC if it's not too long.

Started a conversation about this at https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump%2FProposals#Flagging_and_filtering_of_structured_content_edits.

@Ifeatu_Nnaobi_WMDE - Were you able to learn anything on your end about making Wikibase changes to support this flag/filter?

It would also be helpful to then be able to filter Recent Changes and Watchlist based on this flag - hiding or limiting to structured data changes - this can be a followup task if it makes more sense.

Per this clarification on the wish, the wish submitter wants this functionality to also work in the older non-Javascript interface. This could also be a separate subtask if required.

In T380021#10645613, @Samwalton9-WMF wrote:

Started a conversation about this at https://commons.wikimedia.org/w/index.php?title=Commons%3AVillage_pump%2FProposals#Flagging_and_filtering_of_structured_content_edits.

@Ifeatu_Nnaobi_WMDE - Were you able to learn anything on your end about making Wikibase changes to support this flag/filter?

Hi Sam, we explored this ticket a little bit and agree that making changes in Wikibase would be the appropriate direction in terms of supporting a flag. The Wikidata Integrations would be happy to work on this, although we cannot do so until around Q3/Q4 2025. We see the value in the improvements this would provide and would love to support that as soon as we have the capacity.

@Ifeatu_Nnaobi_WMDE checking in - are you still able to build, or plan to support this task?

In T380021#10884330, @JWheeler-WMF wrote:

@Ifeatu_Nnaobi_WMDE checking in - are you still able to build, or plan to support this task?

hey, we would still love to work on it. A little bit delayed because we've had a long-term UX absences. I can update more in a few weeks time.

@Ifeatu_Nnaobi_WMDE wanted to check back in. Is this still a priority for WMDE?

In T380021#11032403, @JWheeler-WMF wrote:

@Ifeatu_Nnaobi_WMDE wanted to check back in. Is this still a priority for WMDE?

Hi, yes, we're still short on the UX front. So this is taking a while longer, but I will keep you updated. Apologies, we can't get to it sooner.

In ApiQueryRecentChanges, there is a "slot" parameter which does essentially what is requested, but it's inefficiently implemented, so I don't want to see that solution extended to RecentChanges highlighting.

I suggest adding a field to recentchanges called rc_slots_updated which is an integer bitfield, where each slot changed by the revision is reflected by setting the bit 1<<(slot_role_id-1). So for changes modifying the main slot, it will be 1, and for changes modifying the mediainfo slot, it will be 2, and for changes modifying both, it will be 3.

I think there are only two extensions in CodeSearch adding a slot role, so a 32 bit integer field will be sufficient.

If filtering is desired, we could add an index on the bitfield. When a small number of slot roles are defined, the bit AND operation can be mapped to a range.

Alternatively, a change tag could be used.