When searching for a template in VisualEditor, each keystroke triggers two API queries:

• It uses the "prefixsearch" API as a generator. This returns only the titles of the pages, not the description. Example: https://en.wikipedia.org/w/api.php?action=query&format=json&formatversion=2&prop=info%7Cpageprops&generator=prefixsearch&gpssearch=dogs&gpsnamespace=10&gpslimit=10&ppprop=disambiguation&redirects=true
• To get the description as well, the "templatedata" API is used. Example: https://en.wikipedia.org/w/api.php?action=templatedata&format=json&formatversion=2&titles=Template%3ADogs%7CTemplate%3ADogs%20series%7CTemplate%3ADogs%20on%20Acid&includeMissingTitles=1&lang=en

MediaWiki-extensions-TemplateWizard does effectively the same, but combines the two queries. Example: https://en.wikipedia.org/w/api.php?action=templatedata&format=json&generator=prefixsearch&gpssearch=dogs&gpsnamespace=10&redirects=true&includeMissingTitles=true&lang=en

Findings:

• The prefixsearch documentation mentions "profiles", but the more interesting ones (e.g. "fuzzy-subphrases") don't work on enwiki, for example.
• According to https://www.mediawiki.org/wiki/API:All_search_modules, the only alternative appears to be the "search" API.
• Compare the "prefixsearch" example above to this one: https://en.wikipedia.org/w/api.php?action=query&formatversion=2&generator=search&gsrsearch=intitle:dogs&gsrnamespace=10&gsrlimit=10. Looks good.
• One issue I see is that this finds subpages as well. I don't see an obvious way to exclude them, or at least lower their priority. However, this was the same before (example), so we don't make anything worse here.
• A possible hack to improve the subpage situation is to ask for 20 instead of 10 results, reorder them (move subpages to the end), and only display the first 10 results.
• It's possible to limit the search space to titles only with the intitle:… keyword. However, this isn't necessarily better. For example, searching for "pinscher" without intitle:… gives quite nice results. Much better as if it would be limited to the title. Usually, the internal ranking algorithm prefers matches in the title and moves them more to the top.
• It's possible to ask for a different sort order by e.g. adding …&gsrsort=incoming_links_desc to the URL. But this doesn't necessarily improve the result.
• There is no way to specifically search for the <templatedata> description field. The only way I can think of is something like insource:/"description":\s*"[^"]*dogs/. But this is slow, heavily capped because of this, and can't be used in production.
• Good news: It doesn't matter if the <templatedata> blob is on a subpage. CirrusSearch indexes the rendered HTML, not the wikitext. Example.

Open questions:

• How to exclude subpages? Can we introduce a new CirrusSearch feature to do this?
• Can we lower the priority of subpages? Is it worth tweaking CirrusSearch to do this by default?
• Can we teach CirrusSearch to prioritize the "description" from the TemplateData blob more, similar to headings and leading paragraphs?
• Is it possible to force CirrusSearch to list matches in titles first?
• …