As far as I can tell, this works as designed on Wikidata. Compare also the behavior on enwiki: https://en.wikipedia.org/?useskin=vector-2022
Since this might be (partially) a design issue, I'm adding the Codex tag as well.

I added screenshots to illustrate the problem.

Hey there. This is not an issue. The new bolding behavior is correct and works as intended/specified by the original designs of Vector 2022's TypeaheadSearch. Please see T255603: Design spec for new Vue.js search experience.

It might work as intended but this really really doesn't feel right. I think the design should be given some more thought tbh.

[Agh. Deleted that unintentionally. Adding again:]

This was given quite some thought: https://phabricator.wikimedia.org/T255603#6369734

I can reach out to Alex and ask if their team received any feedback from the community that contradicts his recommendation. And check if this pattern matches the search use case in Wikidata too (as he mentions, bolding might not be helpful in certain cases).

In any case, we would open a design ticket. This bug report should probably be closed because the Vector 2022 search behaves consistently and as intended.

Ah, the comment at T255603#6369734 does indeed illustrate the thought behind this well and I can see it working for a Wikipedia:

I guess the major difference is that on Wikipedia, the search is a strict match on the beginning of the page title. So the typed query are always the first characters of a result.

However, on Wikidata, that assumptions does not hold:

Here on Wikidata, the same typed query ("Vi") can appear anywhere in the Label of the Item or in an Alias.

Though I agree that this is not an implementation bug. It works as designed. I'll change the task to be a normal one for now. (We can still close it if that is still desired.)

Yes, changing the task to a regular one makes sense. Thanks, Michael!

And, agreed, it's worth exploring if the original solution specifically works for Wikidata's search, where, as you mention 1. the match can appear anywhere in the result, and 2. results are not presented in alphabetical order.

Search query highlighting behavior can be turned off via the highlightQuery prop, which is a boolean prop of both CdxTypeaheadSearch and the Vector search app. Currently, in Vector, highlightQuery is set to true or false based on the UI language and whether words can safely be split to highlight the search query in that language. To turn this off for Wikidata, some logic would need to be added there to also allow this to be configured via a config variable.

@AnneT Thanks so much for the valuable guidance :D

Change 926461 had a related patch set uploaded (by Noa wmde; author: Noa wmde):

[mediawiki/extensions/Wikibase@master] Add highlightQuery to the vector search client config

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

Change 926463 had a related patch set uploaded (by Noa wmde; author: Noa wmde):

[mediawiki/skins/Vector@master] Add highlightQuery as search client property

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

@AnneT Thanks for the hints!
We've tried to use Wikibase's Vector search client to override the attribute, however at this point it seems that the parallel Resource Loader config is the one Vector eventually adheres to, at least when tested locally with the implementation in the patches added to the task. Would you have an idea on how to circumvent that for Wikibase?

Hi @noarave! I think this will require a change in that Vector code that you linked, so that it first checks if highlightQuery is set in the VectorWvuiSearchOptions config variable. If so, it should respect that value, and if not, it can do what it currently does. Perhaps this should be captured in a separate task? cc @Jdlrobson

@Sarai-WMDE @Arian_Bozorg @Lydia_Pintscher Turning off the highlightQuery option results in the Label always being bold, but the Alias being shown in normal font. That is not what the AC states.

Is that also acceptable, or do you want us to spend more time looking into what needs to be done for the alias to be bold too?

From my side it's not amazing but acceptable and better than what we have yeah.

Also fine from my side, ideally we would have it all bold like it is in Vector Legacy

But all good from my end. @Sarai-WMDE this ok for you too?

In case it's fine with product in terms of effort, I'd say that we should look into making aliases bold too. The current solution is perpetuating the issue of applying different font weights to the searchable text. The assumption is that this could generate confusion ("is the matching pattern bold or regular?") and direct the users' attention to the non-matching text in some cases (like in the example that Michael shared), generating that "zigzag" effect.

That works from my end, thanks Sarai

@Arian_Bozorg and @Lydia_Pintscher. Correct me if I'm wrong, but I believe that our last decision here was to only apply a bold style to labels after all, since increasing the weight of aliases too seemed to involve more effort or coordination than expected/reasonable. While discussing this, we also pondered the possibility of customizing this in the future Scoped TypeaheadSearch component (although I'm unsure that's totally a good practice. I can consult the DST on this).

Yes, that's correct! I'll update the A/C

@Jdlrobson we need you to weigh in on a patch to this ticket, will you be available to take a look?

Change 926463 merged by jenkins-bot:

[mediawiki/skins/Vector@master] Allow overriding the search pattern highlighting for Wikibase

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

Change 926461 merged by jenkins-bot:

[mediawiki/extensions/Wikibase@master] Add a hook handler to override vector's default search highlighting

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