LiveSearch cannot scope results to a locale #2479
Replies: 1 comment 2 replies
|
I think this is useful, but the usage that you describe isn't correct. Did you test |
|
You're right, and the example in my post is wrong — thanks for catching it.
I re-tested with a probe page rendering both values, and (I removed my middleware's own So the example should read: <LiveSearch collections={["posts", "pages"]} locale={Astro.currentLocale} />The gap itself is unchanged though: Two possible shapes, happy to implement either:
I'd lean on (1) for safety, but (2) is the nicer default if you're fine with the behaviour change. Tell me which you prefer and I'll open the PR — the change is already written and covered locally (build, typecheck, lint, format, full |
|
I'd go with 2, and highlight the changed behaviour in the chnageset |
Uh oh!
There was an error while loading. Please reload this page.
The gap
/_emdash/api/searchand/_emdash/api/search/suggestboth accept alocalequery parameter and filter correctly on it.LiveSearchnever sends one, and exposes no prop that would let a theme provide it — its props areplaceholder,collections,minChars,debounce,limit,class/style/inputClass/resultsClass/resultClass,showSnippets,autofocus,suggestMode,expandOnFocus,searchPageandrouteMap.On a site with translated content, the dropdown therefore returns every entry once per locale. On my own bilingual site (FR canonical, EN under
/en/), a visitor searchingendlessfrom a French page gets:Half the list is in the wrong language, and it is a duplicate of the other half. Clicking the English result opens the French page, since the slug redirects to its translation.
Why a prop rather than automatic detection
The component could try to infer the locale from
<html lang>, but that guesses at what the integration already knows. Astro exposes the resolved locale onAstro.locals, and a theme may deliberately want a cross-locale search. An explicit, optional prop leaves both doors open.Proposal
Add an optional
localeprop, forwarded as thelocalequery parameter to whichever endpoint the component uses:Unset, behaviour is unchanged — results still span every locale, so existing sites are unaffected.
I have the change working and covered locally (build, typecheck, lint, format, full
coresuite) and can open the PR as soon as this is approved. I worked around it meanwhile by reimplementing the component in my own theme, which is exactly the kind of fork a one-line prop would avoid.All reactions