@egardner suggested we consider using Lunr, which is FOSS. Here's an example: https://www.getty.edu/publications/romanmosaics/

In T317792#8246399, @AnneT wrote:

@egardner suggested we consider using Lunr, which is FOSS. Here's an example: https://www.getty.edu/publications/romanmosaics/

If Algolia integration is free and straightforward, then that's probably a good solution. But in the past I've had good luck with Lunr for client-side search in these kinds of sites. Since the content is all static, we can generate a search index at build time (most likely a big JSON file) and then feed it into Lunr when the user triggers the search. You can even weight different fields (setting matches in titles to be worth more than matches in body text, etc) to tune the results.

Would be cool if we could actually use Typeahead with a different back-end for this purpose.

This code is in Ruby and specific to the Middleman site generator, but it would be pretty simple to do something similar in Node that loops through all the pages in the docs site and builds a data structure, then writes it to a file on disk in JSON format.

Change #1105038 had a related patch set uploaded (by Anne Tomasevich; author: Anne Tomasevich):

[design/codex@main] [proof of concept] Enable local search

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

Change #1105038 merged by jenkins-bot:

[design/codex@main] docs: Enable local search

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

@AnneT What's meant by the last AC "Document improvements to search UI"?

@Volker_E in the design sync, we agreed that @bmartinezcalvo would open a task to document future improvements to the VitePress search UI

El T317792#10417333, @AnneT escribió:

@Volker_E in the design sync, we agreed that @bmartinezcalvo would open a task to document future improvements to the VitePress search UI

This is the task for the design improvements T382574: Codex search: review styles. Thank you!