It makes sense to emphasise the reason for the lack of results in this context. Highlighting the affected filters and providing a succinct message in the results area would help the user to (a) notice something went wrong, (b) understand what happened and (c) find the elements required to solve the issue.

For cases where more than one conflict occurs, while we can highlight all affected tags, we may want to describe only one at a time with an indication that more exist. For example:

The "New user" filter includes only registered users conflicting with the "Unregistered" filter. Two more conflicts found.

We should really be careful messages that use pieces of other messages inside them in the sentence, because in some languages they make no sense, or require gendered language, or require other adjustments.

If we want to be explicit in things that conflict, we should do what we did for Echo's cross-wiki and use a list at the end. Something like:

"Multiple conflicts found: "New user" / "Unregistered", "Foo" / "Bar"

Or something like that.

Using the names inside the string can result in a language and translation nightmare.

Per above, @Mooeypoo and I interpreted it differently. I interpreted that there would be a custom message for each conflict (though since Unregistered conflicts with all of User experience level, it may make more sense to represent it like that). Key just for example purposes.

userexplevel-conflict-unregistered: 'Filters in the "User experience level" group find only registered users, so the “Unregistered” filter is canceling their effect.'

There is more information about this at T149385: Approved interface text for RC page interface elements

@Mooeypoo @jmatazzoni said he's open to simplifying these conflict messages. Let's discuss.

I think simplifying them is the best approach, not only technically, but also for the user. There may be multiple conflicts, and declaring sentences with a full list of all the conflicts can be confusing.

I think your solution works, though it will mean we need to define each conflict with a message. The alternative is to have a base message that includes conflicts, but the downside is that it won't be as user-friendly (something like "This filter is currently in conflict with other selected filters: [list of filters in conflict]"

I think your solution is probably best.

Joe, Moriel, and I had a meeting about this, and agreed that all the messages should follow common schemes (hopefully just 1, but I need to check if the scheme requires one for filter->filter and one for filter->group).

There will be limited use of variables at the end, but not inline, so it shouldn't break any languages.

In T156427#3028185, @Mattflaschen-WMF wrote:

Joe, Moriel, and I had a meeting about this, and agreed that all the messages should follow common schemes (hopefully just 1, but I need to check if the scheme requires one for filter->filter and one for filter->group).

There will be limited use of variables at the end, but not inline, so it shouldn't break any languages.

I'm not sure I understand this. Would it be possible to have an example of how one of those messages would look like?

In T156427#3028445, @Pginer-WMF wrote:

I'm not sure I understand this. Would it be possible to have an example of how one of those messages would look like?

Yep:

The "Unregistered" filter is inactive because its effect is being canceled by the following Experience filters, which find only registered users: "Newcomer, Experienced"

The part in quotes at the end is what I meant by "limited use of variables" (it could be a single filter in Experience, or any set). That is the only place variables are planned to be allowed currently (the number of filters in quotes, here 2, is also passed for PLURAL support).

@jmatazzoni @Mooeypoo The only place I think there is an issue is the ORES filters when you mouseover "Logged actions". The issue is that Quality and Intent are separate groups, and we don't currently have a concept of a meta-group that would combine them. That would complicate things.

If we left it roughly as specified (but consistent with a unified scheme):

If you had “Likely have problems”, “May have problems”, "Very likely good faith", and “Logged actions” checked, it would not combine the filters from different groups (“Contribution quality” and “User intent”) into one message.

You would see one or both of these sentences (not sure how we’ll handle tooltips when there are multiple conflicts), but they can not be one sentence:

This filter is inactive because Quality and Intent predictions are not available for Logged actions, so this filter conflicts with the following filters: “Likely have problems, May have problems”
This filter is inactive because Quality and Intent predictions are not available for Logged actions, so this filter conflicts with the following filters: “Very likely good faith”

I think the simplest way to solve this is to separate the keys. So you would instead see one or both of:

This filter is inactive because Quality predictions are not available for Logged actions, so this filter conflicts with the following filters: “Likely have problems, May have problems”
This filter is inactive because Intent predictions are not available for Logged actions, so this filter conflicts with the following filters: “Very likely good faith”

The same applies to the results area messages, only if we can show more than one message at a time. If we strictly show one at a time, the original message is probably fine.

In T156427#3031409, @Mattflaschen-WMF wrote:

The same applies to the results area messages, only if we can show more than one message at a time. If we strictly show one at a time, the original message is probably fine.

The latest version of the Results Area Messages don't include any filternames (see T149385). So if I understand Matt's issue properly, I don't think there is an issue. Here is the complete text .

No results displayed because the search criteria are in conflict
The “Logged actions” filter is in conflict with one or more Quality or Intent filters. Quality and Intent predictions are not available for Logged actions. (Tip: get more info by hovering over the filter tags above.)

Now, part of the reason I think this is fine is that the details are listed in the tag tooltips. That, I gather, is still a problem...

In T156427#3031396, @Mattflaschen-WMF wrote:

@jmatazzoni @Mooeypoo The only place I think there is an issue is the ORES filters when you mouseover "Logged actions". The issue is that Quality and Intent are separate groups, and we don't currently have a concept of a meta-group that would combine them.
I think the simplest way to solve this is to separate the keys. So you would instead see one or both of:

This filter is inactive because Quality predictions are not available for Logged actions, so this filter conflicts with the following filters: “Likely have problems, May have problems”
This filter is inactive because Intent predictions are not available for Logged actions, so this filter conflicts with the following filters: “Very likely good faith”

Thanks Matt. I don't love the double message shown above. Assuming you can't think of a way to solve this problem and go with the original (and I have to say, it feels like something your brilliant minds might just solve), then let me ask this? I assume you can detect that logged actions is conflicting with Quality or Intent, when it's one or the other. Can you detect when it's both Quality and Intent, and then show a special message for that? If so, what about a plan something like this:

1. If it's a Quality conflict, show a Quality-specific message, and list Quality filter(s).
2. If it's an Intent conflict, show a Intent-specific message, and list Intent filter(s).
3. If the conflict is with both, show a Both message, with NO FILTERS listed, like this:
   
   This filter is inactive because it is in conflict with selected Quality and Intent filters. Quality and Intent predictions are not available for logged actions. Please adjust your settings.

I think the problem is less about detection (we can detect if it's both, or one or the other) but more a matter of how to specify and then recall those messages. We are trying to come up with a sensible way extensions can define what message goes up in whatever case, so if we start having multiple conditions, we need to make sure they are consistent between filters and filter groups.

The problem here is that if we send three messages, we need to tell the code that it loads the third if both groups are conflicting, but that's not the case in other filters, which makes this unique to this specific group of filters, and is hard for the algorithm to generalize.

The code can tell what filters are in conflict with any active filter at any given moment (and by extension, it's cinflict groups) but how do we sort out which message it then picks to display, in a way that's general and allows extensions to define it properly, is the issue.

Matt, any ideas?

In T156427#3031693, @Mooeypoo wrote:

The problem here is that if we send three messages, we need to tell the code that it loads the third if both groups are conflicting, but that's not the case in other filters, which makes this unique to this specific group of filters, and is hard for the algorithm to generalize.

FWIW, I think it's very likely that there will be other use cases where we'll want to generalize the behavior of the two ORES filter groups. E.g., it's likely there are certain namespaces that aren't scored by ORES. So maybe making a "meta-group," as Matt called it, is worthwhile?

In T156427#3031750, @jmatazzoni wrote:

E.g., it's likely there are certain namespaces that aren't scored by ORES.

I think I thought that for some reason, but I believe it turned out not be the case. Also, it's not really an issue to record the same conflict for both ORES groups (as we're already doing with logged actions and the two ORES groups). It's doing it as a merged/meta-group where we need to discuss if it's worth the work.

In T156427#2981771, @Pginer-WMF wrote:

For cases where more than one conflict occurs, while we can highlight all affected tags, we may want to describe only one at a time with an indication that more exist. For example:

The "New user" filter includes only registered users conflicting with the "Unregistered" filter. Two more conflicts found.

Joe okay'ed the "more conflicts found" part during a meeting today, so I added it above. I think it may work better with the number of filter->filter conflicts, rather than the number of filter->group conflicts.

Change 340909 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Adopt conflict colors

https://gerrit.wikimedia.org/r/340909

Change 340909 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Adopt conflict colors

https://gerrit.wikimedia.org/r/340909

I moved all the Conflict Display State functionality and messaging to this task from T149391, renamed this task (as above) and rewrote the description.

Needs text to be shown, blocked by T159369.

In T156427#3072342, @Jdforrester-WMF wrote:

Needs text to be shown, blocked by T159369.

No, T159369: Send data structure and messages for filters used in unstructured UI is for the old UI. Conflict UI is only for the new UI, and the WIP (https://gerrit.wikimedia.org/r/#/c/337546/) already has the messages.

OK, I won't listen to @Catrope in future. :-)

@Mattflaschen-WMF So then it depends on T152754, right? Or at least on work that's happening in the same patch.

Yes

Change 342284 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Rework conflicts to be objects in filter or group context

https://gerrit.wikimedia.org/r/342284

Change 342284 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Rework conflicts to be objects in filter or group context

https://gerrit.wikimedia.org/r/342284

Change 343205 had a related patch set uploaded (by Mattflaschen):
[mediawiki/extensions/ORES] Add ORES conflicts and What's This?

https://gerrit.wikimedia.org/r/343205

Change 343205 merged by jenkins-bot:
[mediawiki/extensions/ORES] Add ORES conflicts and What's This?

https://gerrit.wikimedia.org/r/343205

I rewrote all the Conflict State Tooltips and Display Area Messages. I updated the main Approved Texts ticket, for QA purposes, but also created a new subtask for inserting the corrected texts: T160803.

Change 343423 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Implement conflict global result message

https://gerrit.wikimedia.org/r/343423

Change 343423 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Implement conflict global result message

https://gerrit.wikimedia.org/r/343423

The system us showing the No-Effect (redundant filter) message when the filter is not selected, but the highlight is. See screenshot below. In the screenshot, I think the Active Filter Display Area is correct, EXCEPT that the error message should not show (unless the "Likely" filter were selected). I.e., "The filter has no effect" because...it is not selected.

Whoops -- I thought I fixed that. I'll take another look, the item should display its description in this case, not the conflict.

Change 343452 had a related patch set uploaded (by Mooeypoo):
[mediawiki/core] RCFilters UI: Followup Ic97c7c6aae7: Only add state message if item is selected

https://gerrit.wikimedia.org/r/343452

Change 343452 merged by jenkins-bot:
[mediawiki/core] RCFilters UI: Followup Ic97c7c6aae7: Only add state message if item is selected

https://gerrit.wikimedia.org/r/343452

Change 342294 had a related patch set uploaded (by Mattflaschen; owner: Catrope):
[mediawiki/extensions/Wikibase] Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/342294

Change 342294 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@master] Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/342294

Change 344268 had a related patch set uploaded (by Mattflaschen; owner: Catrope):
[mediawiki/extensions/Wikibase@wmf/1.29.0-wmf.17] Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/344268

Checked in betalabs the following conflicting states currently fully implemented (with the tooltips and the Result Area messages)

The following state specified as conflicting in T160803: Implement corrected Conflict State tooltips and Results Area messages is not marked as a conflicting state:

Change 344268 abandoned by Catrope:
Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/344268

Change 344268 restored by Catrope:
Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/344268

Change 344268 merged by jenkins-bot:
[mediawiki/extensions/Wikibase@wmf/1.29.0-wmf.17] Port Wikidata filter to new RCFilters system

https://gerrit.wikimedia.org/r/344268

Re-checked the states listed in the table above - all tooltips and conflicts are in place except for 'Wikidata edits' and 'Non-minor' conflicting state (see my comment https://phabricator.wikimedia.org/T160803#3135677).

QA Recommendation: Resolve

The remaining conflict: Wikidata and Non-minor may be added later.