Page MenuHomePhabricator

CirrusSearch: Add filter for exclusion of redirects or finding only them
Open, LowPublic

Description

This would at least be very useful for maintenance of typo fixes in file titles, maybe elsewhere, as well (in some kind the opposite of T171155 I guess).

Generally, when files are renamed (technically moved to the new name) they are not deleted under the old name, but a redirect will be created. So, if there is a typo fix, the wrong name will still be found with an according search. But if one frequently is searching for new files with the same mistake the redirects of the fixed files are interfering.

Examples from the wild:

On the other hand there may be cases when it could be useful to search only for redirects.

Event Timeline

Restricted Application added projects: TCB-Team, Discovery-Search. · View Herald TranscriptSep 11 2018, 10:00 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Speravir updated the task description. (Show Details)Sep 11 2018, 10:01 PM
debt triaged this task as Low priority.Sep 13 2018, 5:10 PM
debt moved this task from needs triage to This Quarter on the Discovery-Search board.
debt added a subscriber: debt.

This looks like we'd need to add options to the keywords to 'fix' this, we'd need to think about how to implement and come up with more use cases.

TJones added a subscriber: TJones.Sep 20 2018, 2:54 PM

Note: this is a possible duplicate of T90807: Option to exclude redirection pages from search results, which was declined.

Speravir added a comment.EditedSep 20 2018, 11:07 PM

Well, @debt wrote in this

[…] questionable on how useful this would be, declining this ticket. If there is more of a use case than what is in this ticket, please reopen and show examples / steps to reproduce

I hope I provided some use cases above. I did not reopen this one because on a search for possible older tickets this was not shown to me (I searched for redirect, the other one has redirection, maybe this matters).

Another note: In Help talk:CirrusSearch on MediaWiki (How to exclude redirects from search results?, started independently from this ticket) an anonymous user pointed to T64680.

[offtopic]

because on a search for possible older tickets this was not shown to me (I searched for redirect, the other one has redirection, maybe this matters).

See the docs: https://www.mediawiki.org/wiki/Phabricator/Help#Search_terms

stjn added a subscriber: stjn.Mar 30 2019, 11:53 AM

Similar small use case: I was trying to find articles with a specific set of symbols (intitle:/ - /) to see how frequent they are and all the results were the redirects, which was not helpful in a bit. Filter could’ve helped with it.

A valuable use case for title search would be looking at the number of titles matching certain patterns, to establish whether there's a consistent form in use for certain types of articles (cf. https://en.wikipedia.org/wiki/Wikipedia:CONSISTENCY). For example, comparing the parenthetical disambiguators "(video games)" vs. "(video gaming)". The inability to exclude redirects makes this impossible.

Also, FWIW, 2 of the 7 threads at https://www.mediawiki.org/wiki/API_talk:Search are complaints about the removal of srredirects, so it seems like this is not an uncommon pain point.

@Speravir, @stjn, @halfeatenscone—quick question for you about this feature. Do you have any thoughts on how it should be exposed? Would you want keywords like intitleonly: and inredirect: (exact names open for discussion) or a checkbox? If a checkbox, should the checkbox only exist on the "Advanced" tab to keep the UI simple for less sophisticated searchers?

It looks like T64680 took away a checkbox to enable redirects in results. I agree that general searchers would want redirect results, but I think it was overzealous because I can see why editors would want to exclude them in the examples above.

stjn added a comment.Aug 19 2019, 3:43 PM

I think it could be a keyword, preferably one that allows people both to exclude and include redirects from the search (inredirect:true / inredirect:false then?). As to UI, it can probably be included to AdvancedSearch in some way (and not included in older UI?), but I don’t have a strong opinion about it.

I think it could be a keyword, preferably one that allows people both to exclude and include redirects from the search (inredirect:true / inredirect:false then?).

Are the :true and :false required? They probably would have to be, otherwise if true were the default, then searching for "false" with inredirect:false could be ambiguous, or at least not very transparent. If they are required, then you just have longer keywords with a colon in the middle. I also dislike introducing an (actual or apparent) new feature that only works on one keyword. Someone somewhere will want to search on incategory:false:Dogs or something similar, and will be disappointed or confused or get poor results—or all three.

I prefer keywords over checkboxes, too—though it isn't up to me, but it is why I'm interested in trying to devise a good keyword formalism.

As to UI, it can probably be included to AdvancedSearch in some way (and not included in older UI?), but I don’t have a strong opinion about it.

Ahh, to be clear I did actually mean the Advanced tab in the old UI. I tend to forget about the AdvancedSearch UI because I have it disabled. It's also maintained by a different team, so once we have the core functionality working—whether as a keyword or flag of some sort—they will have to update AdvancedSearch to make us of it. My first thought is that a checkbox makes sense for them, but I'm not sure. It is kind of awkward to have a three-way toggle (title, redirect, both). Maybe both and title-only are good enough for most users. But we are maybe getting ahead of ourselves worrying about AdvancedSearch.

In terms of the API, there used to be a boolean srredirects parameter, which would include redirects if true. Restoring that seems fine to me. Though it looks like the default value for boolean parameters is always false (https://www.mediawiki.org/w/api.php?action=help&modules=main#main/datatypes), so maybe it would be preferable to keep the current default behaviour, and add a boolean param with opposite semantics (srnoredirects? srsuppressredirects?).

No strong opinion on the UI (checkbox vs. keyword, or both).

@halfeatenscone, thanks for the API point of view.

(I also have to say that while this is on our workboard, it is not very near the top at the moment. So, I appreciate the feedback, but it may be a while before anyone gets to work on it.)

Speravir added a subscriber: Deskana.EditedAug 30 2019, 12:08 AM

Do you have any thoughts on how it should be exposed? Would you want keywords like intitleonly: and inredirect: (exact names open for discussion)

From my point of view (no dev, no code insight) inredirect: seems to be semantically not quite right to me. intitleonly: could be too easily confused with the existing intitle:. I would instead favour something like redirects: with possible options show, i.e. true, (default behaviour) and hide, i.e. false, and, if technically possible or not too difficult to achieve, also only meaning show only redirects, hide every other result.

Addendum: Another idea would be to create a keyword showredirects: (perhaps with a short form like a simple redirs:) without options: default case with adding showredirects: or +showredirects: the same like one did not add this, but with -showredirects: or !showredirects: redirects would be hidden.

or a checkbox? If a checkbox, should the checkbox only exist on the "Advanced" tab to keep the UI simple for less sophisticated searchers?

No checkbox for default search, but one for the advanced search extension (or for three options a selection form).

It looks like T64680 took away a checkbox to enable redirects in results.

Thanks. This reminds me that I actually wanted to add a ping @Deskana .