I can replicate this bug, and I think there are potentially two parts to this ticket we may want to address (described in developer notes)

I moved this back to needs analysis because I think we need to sort out whether the second AC bullet point I've listed, "If a substring matches the user's search input...", is actually necessary so we can know the scope of this task while estimating.

@ovasileva @alexhollender I noticed we display the "Category:" namespace when a user searches for categories to add, but not when they are viewing the categories that page is already a part of. Is this a bug? Should we even display the "Category" namespace when the user is searching for categories? See below for the Category "1961 births"

I am not familiar with this part of the UI or categories more generally. My thoughts:

from "Acceptance Criteria" section of the task description
If a substring matches the user's search input, that substring is bolded regardless if the substring is at the beginning or not.

As far as I can tell we don't do this with our main search, nor does it seem a feature on other popular search interfaces (just tried Google, YouTube, and Twitter). I wonder what the motivation or added value would be there? I can imagine someone typing in "Hockey" and the value of "Ice hockey" appearing, but that seems like a larger issue than the characters being bolded or not.

In T224819#5243941, @nray wrote:

I noticed we display the "Category:" namespace when a user searches for categories to add, but not when they are viewing the categories that page is already a part of. Is this a bug? Should we even display the "Category" namespace when the user is searching for categories?

Since the search box's placeholder text says "Search categories" I think it'd be fine to drop the "Category:" prefix from the search results.

Thinking about this some more:

from "Acceptance Criteria" section of the task description
If a substring matches the user's search input, that substring is bolded regardless if the substring is at the beginning or not.

I don't know if this would be possible unless we changed the way the search works. Currently if I type "Ak" into the search field I am only shown results that start with "Ak". Maybe I'm missing something, but I don't understand how the proposed idea would be possible given how search works currently.

In T224819#5246905, @alexhollender wrote:

Thinking about this some more:

from "Acceptance Criteria" section of the task description
If a substring matches the user's search input, that substring is bolded regardless if the substring is at the beginning or not.

I don't know if this would be possible unless we changed the way the search works. Currently if I type "Ak" into the search field I am only shown results that start with "Ak". Maybe I'm missing something, but I don't understand how the proposed idea would be possible given how search works currently.

Thanks for your feedback @alexhollender. Regarding that AC point - I was overly broad in the wording of that, but my intention was to focus on the fact that <strong> tags are only applied when a user literally types the the word "Category:" before they type the category they are searching for. (e.g. If you type Ak, results for "Ak" will come up but the <strong> tags (which should make the word bolded) won't be there unless the user types Category:Ak. I think that diminishes the value of that highlight feature and I wonder if we could just drop the word "Category" from appearing in the search results so that the highlight algorithm we have could remain the same.

I'm going to split that off into another ticket though as I have a feeling there's more discussion to be had there and the priority might be different than the first AC point.

I removed the second AC and moved it to its own task at https://phabricator.wikimedia.org/T225556