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

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]

In T204089#4604462, @Speravir wrote:

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

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.

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.

In T204089#5422255, @stjn wrote:

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.)

In T204089#5421512, @TJones wrote:

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 .

BTW, another thing that makes the current state of affairs feel confusing and inconsistent is that the prefix: operator doesn't apply to redirects, only the actual title.

With all respect, I'm beginning to think the change to remove srredirects and always include redirects was a step backward. It seems like the change was made in response to the request of one user (T171155), but I can count at least 6 users who have since reported problems owing to the change:

• https://www.mediawiki.org/wiki/Topic:Ujc6zwhx1t17u01g
• https://www.mediawiki.org/wiki/API_talk:Search#Excluding_redirects
• T90807
• + 3 users participating in this ticket

Adding an optional flag to exclude redirects would be fabulous, but I do believe that returning to the previous behaviour (defaulting to not matching redirects for intitle) would be even better in terms of utility/intuitiveness for the average user.

How hard would this be to add? I can compare it to if you want to see all local files + all Commons files when searching for files at enwiki. To only find local files you write 'file: local:'. A similar solution would be perfect here, and very appreciated.

Yes, please add this feature. I need lots of redirects in my wiki but they’ll flood and bury the actual articles.

The current way this functions is also really inconsistent. intitle: search includes redirects without any possibility to exclude them, and insource: search excludes redirects without any possibility to include them (there I would argue redirects should be part of results by default). It is really sad that this is still an issue.

I deal with these searches a *lot* looking from Greek Letter Organizations as part of WikiProject:Fraternities and Sororities. the current use case is finding all redirects starting with a greek letter and including Redirects with possibilities