Nit: I guess we can return early if filterInView?.operator === undefined and not part of the supported operators.

Additionally the createInterpolateElement is the same in both cases with just the active element(s) label, so we could have a single call based on single selection operators. And with that I'm wondering if we could use SINGLE_SELECTION_OPERATORS and ALL_OPERATORS instead of importing them one by one. I'm not sure though if SINGLE_SELECTION_OPERATORS is updated because here you have more like OPERATOR_BETWEEN.

Actually by looking at the removed code for between , OPERATOR_IN_THE_PAST etc, we had different handling, which was just removed.

Refactored at 4a94005

Not from this PR, but why would we need the key prop? I also couldn't find any usage for it.

Not in the original scope of this PR, but I refactored how operators are registered for simplicity at 4a94005

I wonder if all these labels should have a translators note to clarify where they are used and what the quantifiers ("any", "none", "all") refer to. From a quick look at GlotPress, I see the current translations for es_ES, which are grammatically inconsistent:

Addressed at f68740c

We call it "operator name", but it forms a verbal group in the string ("is any"). I found this slightly confusing, so I suspect translators will too.

For me this is a smell that we are doing too much with .display. I know that repetition is annoying, but this is probably better for translators:

{
	name: OPERATOR_IS_NONE,
	labels: {
		/* translators: DataViews operator name */
		name: __( 'Is none of' ),
		/* translators: DataViews filter label, e.g. "Author is none of:" */
		filterText: __( '%s is none of:' ),
	},
	selection: 'multi',
}

Don't take my naming choices literally, use your best intuition; the point is the separation of strings.

Sorry, I misread the code initially, so ignore a part of my feedback. But:

• We shouldn't resort to .toLowerCase, which porbably means making .display mandatory.
• It seems safer to move the interpolation into the .display string (%s is none of: instead of is none of). I even considered going further and moving the entire thing into the hands of translators: <Name>... </Value>, but maybe it's too much and more error-prone.

I extracted the operators to a separate utility that collocates the operator names and the text string it generates at c9d65ee

Instead of hard-coding the operator names here, I've made it filter agnostic. It works as before, but it now depends on how the filter works with the data (single value selection, multi value selection, or custom value).

For example, number can switch between the regular single value (number) to a custom format (between operator):

And dates can switch between the regular single value (date) to a custom format (in the past, over):