feat(ui): scope LiveSearch results to the page locale

[DavidPivert]

What does this PR do?

/_emdash/api/search and /_emdash/api/search/suggest both filter on a locale query parameter, but LiveSearch never sent one. On a site with translated content the dropdown returned every entry once per locale.

On my bilingual site (FR canonical, EN under /en/), searching endless from a French page returned:

en  posts  Endless Night: Maeta's dance turn with KAYTRANADA
fr  posts  Endless Night : le virage dance de Maeta avec KAYTRANADA
en  pages  About
fr  pages  À propos de Maeta et le site

Half the list is in the wrong language and duplicates the other half. Clicking the English result opens the French page, because the slug redirects to its translation.

This PR now implements option 2 from Discussion #2479, per @ascorbic's call (comment: "I'd go with 2, and highlight the changed behaviour in the changeset"). The first revision of this PR added an opt-in locale prop; it now defaults to the page's own locale instead.

Behaviour change

LiveSearch reads Astro.currentLocale — which Astro derives from the URL — and forwards it to whichever endpoint it is using. Results now match the language of the page the search runs on.

<!-- results in the page's own locale (new default) -->
<LiveSearch collections={["posts", "pages"]} />

<!-- a specific locale -->
<LiveSearch collections={["posts", "pages"]} locale="fr" />

<!-- every locale — the previous behaviour -->
<LiveSearch collections={["posts", "pages"]} locale={null} />

Who is affected:

• Sites with i18n configured that relied on cross-locale results will get fewer results than before. locale={null} restores the old behaviour. This is called out at the top of the changeset.
• Sites without i18n are unaffected: Astro.currentLocale is undefined there, so no locale parameter is sent and the search still spans everything.

The earlier revision of this PR documented locale={Astro.locals.locale}, which was wrong — that is a convention of my own theme's middleware, not an Astro API. @ascorbic caught it in the Discussion; the docs and the component's JSDoc now say Astro.currentLocale.

Discussion: #2479

Type of change

• Bug fix
• Feature (requires maintainer-approved Discussion)
• Refactor (no behavior change)
• Translation
• Documentation
• Performance improvement
• Tests
• Chore (dependencies, CI, tooling)

Checklist

• I have read CONTRIBUTING.md
• pnpm build then pnpm typecheck pass (0 errors)
• pnpm lint passes (oxlint --type-aware --deny-warnings, 0 warnings)
• pnpm test passes — full packages/core suite: 472 files, 5867 tests, 0 failures, plus pnpm test:repro (6 files, 29 tests)
• pnpm format has been run (oxfmt + prettier --check clean on the touched files)
• I have added/updated tests for my changes
• User-visible strings in the admin UI are wrapped for translation (not applicable — no admin UI strings)
• I have added a changeset
• New features link to an approved Discussion — #2479, where a maintainer picked the design implemented here (comment)

Note on the last box: when this PR was first opened, #2479 had no maintainer response and the box was left unticked with a note saying so. It is ticked now because @ascorbic has since responded twice and chosen this design — not because a link exists.

Tests

packages/core/tests/repro/live-search-locale.render.test.ts renders the component through AstroContainer and asserts the serialized config, covering three paths:

• no i18n configuration → no locale sent (single-language sites unchanged)
• explicit locale prop → forwarded
• locale={null} → no locale sent (cross-locale search)

What that test does not cover: the Astro.currentLocale default itself, since the test container has no i18n configuration to derive a locale from. That path is verified on a live bilingual site (FR canonical, EN under /en/), where / renders fr and /en/… renders en, including under i18n.routing: "manual".

AI-generated code disclosure

• This PR includes AI-generated code — model/tool: Claude Opus 5 (Claude Code)

Notes

The branch was rebased onto current main (it was 39 commits behind), hence the force-push. The option-2 change is a separate commit on top of the original one, so the diff between the two revisions stays readable.

[changeset-bot]

🦋 Changeset detected

Latest commit: 714b0f4

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 17 packages

Name	Type
emdash	Minor
@emdash-cms/cloudflare	Minor
@emdash-cms/sandbox-workerd	Patch
@emdash-cms/plugin-mcp-smoke	Major
@emdash-cms/fixture-perf-site	Patch
@emdash-cms/perf-demo-site	Patch
@emdash-cms/cache-demo-site	Patch
@emdash-cms/do-demo-site	Patch
@emdash-cms/do-solo-demo-site	Patch
@emdash-cms/admin	Minor
@emdash-cms/auth	Minor
@emdash-cms/blocks	Minor
@emdash-cms/gutenberg-to-portable-text	Minor
@emdash-cms/x402	Minor
create-emdash	Minor
@emdash-cms/auth-atproto	Patch
@emdash-cms/plugin-embeds	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@emdash-cms/admin

npm i https://pkg.pr.new/@emdash-cms/admin@2480

@emdash-cms/auth

npm i https://pkg.pr.new/@emdash-cms/auth@2480

@emdash-cms/auth-atproto

npm i https://pkg.pr.new/@emdash-cms/auth-atproto@2480

@emdash-cms/blocks

npm i https://pkg.pr.new/@emdash-cms/blocks@2480

@emdash-cms/cloudflare

npm i https://pkg.pr.new/@emdash-cms/cloudflare@2480

@emdash-cms/contentful-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/contentful-to-portable-text@2480

emdash

npm i https://pkg.pr.new/emdash@2480

create-emdash

npm i https://pkg.pr.new/create-emdash@2480

@emdash-cms/gutenberg-to-portable-text

npm i https://pkg.pr.new/@emdash-cms/gutenberg-to-portable-text@2480

@emdash-cms/plugin-cli

npm i https://pkg.pr.new/@emdash-cms/plugin-cli@2480

@emdash-cms/plugin-types

npm i https://pkg.pr.new/@emdash-cms/plugin-types@2480

@emdash-cms/registry-client

npm i https://pkg.pr.new/@emdash-cms/registry-client@2480

@emdash-cms/registry-lexicons

npm i https://pkg.pr.new/@emdash-cms/registry-lexicons@2480

@emdash-cms/registry-verification

npm i https://pkg.pr.new/@emdash-cms/registry-verification@2480

@emdash-cms/sandbox-workerd

npm i https://pkg.pr.new/@emdash-cms/sandbox-workerd@2480

@emdash-cms/x402

npm i https://pkg.pr.new/@emdash-cms/x402@2480

@emdash-cms/plugin-ai-moderation

npm i https://pkg.pr.new/@emdash-cms/plugin-ai-moderation@2480

@emdash-cms/plugin-atproto

npm i https://pkg.pr.new/@emdash-cms/plugin-atproto@2480

@emdash-cms/plugin-audit-log

npm i https://pkg.pr.new/@emdash-cms/plugin-audit-log@2480

@emdash-cms/plugin-color

npm i https://pkg.pr.new/@emdash-cms/plugin-color@2480

@emdash-cms/plugin-embeds

npm i https://pkg.pr.new/@emdash-cms/plugin-embeds@2480

@emdash-cms/plugin-field-kit

npm i https://pkg.pr.new/@emdash-cms/plugin-field-kit@2480

@emdash-cms/plugin-forms

npm i https://pkg.pr.new/@emdash-cms/plugin-forms@2480

@emdash-cms/plugin-webhook-notifier

npm i https://pkg.pr.new/@emdash-cms/plugin-webhook-notifier@2480

commit: 714b0f4

[emdashbot]

This PR solves a real, well-scoped problem: LiveSearch sends requests to search endpoints that already support locale, but the component had no way to supply it, so multilingual sites got duplicated cross-language results. The approach is sound and fits EmDash’s existing component pattern.

What I checked:

• The locale prop is optional, defaults to "", and is omitted from the query string when unset, preserving existing behavior.
• The prop is forwarded for both /api/search and /api/search/suggest via URLSearchParams.
• The server schemas and handlers already validate locale and filter by it, including resolving configured locale casing.
• The client-side Config interface and default config are updated consistently.
• Documentation and a minor changeset are included.
• No AGENTS.md violations: no SQL changes, no new auth/state/logged-out queries, no new hard-coded admin UI strings, no problematic comments.

The change is small and correct. The author correctly notes that the existing test harness only covers live-search-routing; plumbing this prop through to a query parameter is straightforward enough that the absence of a new custom-element fetch test is acceptable.

One thing I cannot verify statically: whether the linked Discussion (#2479) has maintainer approval. I’m assuming good faith on that since the PR includes it and ticks the checkbox.

[DavidPivert]

Good catch, and you were right to flag it — the answer is no, #2479 has no maintainer approval. I opened it myself an hour before this PR, and it currently has no comments or labels.

I've corrected the description: the checkbox is now unticked and there's a note explaining the situation. I ticked it originally because a Discussion was linked, which is not what the box asks. My mistake, and thanks for not letting it pass silently.

The order here is backwards relative to CONTRIBUTING.md. I wrote the change first because I hit the problem on a live bilingual site and needed it working, so the PR shows code that has been running in production rather than a proposal. If you'd rather keep the process strict, I'm happy to close this and reopen once #2479 is approved — the branch isn't going anywhere.