This is a feature request, not a bug. The Search Platform team currently doesn't have any front end folks helping us out right now, so even though this can be done, it won't be something we will take on.

This ranked #12 on the 2022 Community Wishlist Survey, and it seems like the simplest thing, less than one day of work.

In T215716#7716703, @tstarling wrote:

it seems like the simplest thing, less than one day of work.

No kidding... it took me all of 15 minutes to write a proof of concept patch. The only apparent downside is that it restores the "Search" tab to Special:Preferences, which was removed in T54817.

I note that this request was previously declined in 2016: T71774: User preference for number of search results displayed. In doing so, @Deskana gave two reasons:

• There was a vaguely expressed performance concern ("there are potential performance implications of serving users more results, particularly if lots of users start to use the feature"). Given the popularity of the Wishlist proposal, I think we would need a more specific explanation than this if performance remains a roadblock here.
• A generic argument was made about the complexity of adding preferences. When it comes to this task, I don't buy this argument at all:
  • This preference is trivial from a functionality point of view, and its effects are hardly complex.
  • The complexity really lies in changing the number of search results displayed, and that code already exists.
  • There is clearly a lot of community demand for this preference, so the complexity (if there is any at all) is worth the cost.

Change 763637 had a related patch set uploaded (by TTO; author: TTO):

[mediawiki/core@master] Allow the user to set a default number of search results

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

The only apparent downside is that it restores the "Search" tab to Special:Preferences, which was removed in T54817.

Is there a way to move this to another tab? Having one tab with only one option is weird plus having many tabs is bad UX.

If the search platform team is okay with this patch and the above issue is addressed, I'll +2 it.

In T215716#7724472, @Ladsgroup wrote:

Is there a way to move this to another tab? Having one tab with only one option is weird plus having many tabs is bad UX.

The other tabs available in core MediaWiki are: "General", "Appearance" (already with too many options), "Editing", "Recent changes" and "Watchlist". I don't see that it neatly belongs on any of those tabs.

I should note that MediaWiki already displays a "Search" tab containing a single checkbox if $wgSearchMatchRedirectPreference is set to true (it's false by default). What's more, Wikimedia wikis have a "Search" tab that contains search completion and advanced search options. So I'm not sure if it is a big deal to add this.

I see, it's good then.

Thanks for helping out with this! Is there a way to see what the proposed change looks like (as per the comment above on many tabs being bad UX)? I'd like to take a look with @Sneha , and then a Search engineer can review the patch.

In T215716#7724555, @MPhamWMF wrote:

Is there a way to see what the proposed change looks like (as per the comment above on many tabs being bad UX)?

As TTO said in their second comment, there is already a search tab on Wikimedia wikis. So the Wikipedia preferences page will go from this:

to this

A few comments:

• Since we have multiple search interfaces (SpecialSearch, AdvancedSearch, MediaSearch), it is a bit confusing on which of those interfaces are impacted by this setting
• Machine Learning Ranking will not learn from searches with more than 20 results. This probably isn't a concerned since the expectation is that only a small percentage of users will change their default.

In T215716#7726070, @Gehel wrote:

• Since we have multiple search interfaces (SpecialSearch, AdvancedSearch, MediaSearch), it is a bit confusing on which of those interfaces are impacted by this setting

If AdvancedSearch refers to https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/AdvancedSearch, that looks like it just adds some fields to the existing Special:Search form. If that's all it is, it would automatically honour the new option.

As for Special:MediaSearch, a "default number of results" isn't very meaningful as far as I can tell.

My bad, SpecialSearch and AdvancedSearch are the same and would work in the same way. MediaSearch at the moment auto loads more results, but I would argue this is accidental and might change in the future.

None of those points are blocking adding a new preference, just things to keep in mind.

Thanks again for working on this! There seem to be no expected issues on the UI/UX side (text copy looks fine as well), or the performance side, so this patch is ready to move ahead with code review and merging.

In T215716#7757991, @MPhamWMF wrote:

this patch is ready to move ahead with code review and merging.

I'm a bit out of the loop - I'm not sure who to add as a reviewer. Is there someone on your team? Perhaps @tstarling himself?

In T215716#7758977, @TTO wrote:

In T215716#7757991, @MPhamWMF wrote:

this patch is ready to move ahead with code review and merging.

I'm a bit out of the loop - I'm not sure who to add as a reviewer. Is there someone on your team? Perhaps @tstarling himself?

@TTO , sorry for the lack of detail in the last comment. This ticket is on the Search team's current work board, so an engineer from my team will pick it up when it's next in the queue for them. No need to add a reviewer on your end.

Change 763637 merged by jenkins-bot:

[mediawiki/core@master] Allow the user to set a default number of search results

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

I have added it to Tech News 2022/11 with this wording:

You can now set how many search results to show by default in [[LINK|your Preferences]]. [1]

If that needs any corrections, please edit it (or tell me) within the next ~24 hours, after which it will be frozen for translations. Thanks!

@Quiddity I'm so sorry, I only just saw this - the change isn't deployed yet, so the message should have read "You will soon be able ...". Would it be possible to pull the message from this week's Tech News? By next edition, the code should be deployed so it will be able to be reused as is in the next edition.

@TTO Arg, my fault. Thanks for catching that, and for migrating+rewriting the item. (I'd tested at beta cluster and saw it worked, hence it was going to be on the deployment train, but then the logic circuit in my brain skipped a step...)

Patch has been deployed with the train, functionality is live on the wikis and it works as expected in a quick test.