Admin content edit route should preserve locale for slug-based i18n entries

[WellDunDun]

Summary

In an i18n site, the Admin UI edit route can open the wrong locale variant when the URL identifier is a slug-like ID and another locale shares the same slug.

We hit this in an Astro/Cloudflare EmDash site with pages/about:

• English row: id: "about", slug: "about", locale: "en"
• Arabic row: id: "about-ar", slug: "about", locale: "ar", translationOf: "about"

Navigating directly to:

/_emdash/admin/content/pages/about

opened the Arabic row and made it difficult/impossible to select/edit the English row.

What appears to happen

The content list page is locale-aware and defaults to i18n.defaultLocale, but the content edit page does not validate/preserve a locale search param and calls:

fetchContent(collection, id)

which fetches:

/_emdash/api/content/pages/about

without ?locale=en.

Because EmDash permits duplicate slugs across locales, an unscoped slug lookup is ambiguous.

Expected behavior

When i18n is enabled, the Admin content edit route should pass the active locale through to content reads and writes, likely defaulting to manifest.i18n.defaultLocale when no explicit ?locale= is present.

Example:

/_emdash/api/content/pages/about?locale=en

Local workaround

We patched @emdash-cms/admin@0.14.0 locally to:

• accept locale in the edit route search params
• compute activeLocale = searchParams.locale ?? i18n.defaultLocale
• include locale in the single-content query key
• call fetchContent(collection, id, { locale: activeLocale })
• pass rawItem.locale ?? activeLocale to update/autosave calls

We also patched the API/runtime side so PUT requests with ?locale= use that locale when resolving slug-like IDs.

Version

Observed on EmDash 0.14.0 / @emdash-cms/admin@0.14.0.

[WellDunDun]

Additional confirmed repro path from downstream integration:

The content edit route can still lose locale even after direct edit links preserve/default a locale, because the Translations panel opens sibling entries by id without passing the sibling locale.

Observed on @emdash-cms/admin@0.14.0:

1. Open an i18n content entry, e.g. /_emdash/admin/content/pages/about?locale=en.
2. In the Translations panel, click Edit/Open on the Arabic sibling.
3. Admin navigates to the sibling id route without a locale search param, e.g. /_emdash/admin/content/pages/about-ar.
4. Subsequent reads/writes/publish can become ambiguous or appear to affect the wrong translation, especially when rows share slug values across locales.

Downstream patch that fixed this specific path:

onOpen: (tr) => navigate({
  to: "/content/$collection/$id",
  params: {
    collection,
    id: tr.id,
  },
  search: { locale: tr.locale },
})

Acceptance criteria for this issue should include translation panel navigation: opening any sibling translation should preserve the selected translation's locale in the edit route, not only the current list/edit entry path.

[emdashbot]

The investigation bot ran into a problem and could not complete.

A maintainer can re-trigger by removing and re-applying the bot:repro label.

_{Run: https://github.com/emdash-cms/emdash/actions/runs/26738464667}

[emdashbot]

The investigation bot reproduced this issue and pushed a candidate fix.

Root cause: Two locations, one missing-locale plumbing path:

1. Admin edit route (primary): packages/admin/src/router.tsx.

   • contentEditRoute.validateSearch (~lines 575–582) only accepts field; it ignores locale. The list route validates locale (line 281) and the new-content route does too (line 454), so ?locale=en is silently dropped here.
   • ContentEditPage (~line 605) calls fetchContent(collection, id) with queryKey: ["content", collection, id] — locale is not in the key and not forwarded. The shape it should mimic is right next door in the list route: activeLocale = i18n ? (localeParam ?? i18n.defaultLocale) : undefined (line 301), keyed at 312.
   • fetchContent in packages/admin/src/lib/api/content.ts:164 takes no locale option and GETs /_emdash/api/content/{collection}/{id} unscoped. updateContent and publish/unpublish/discard/schedule/delete helpers are equally unscoped, so a cache-only fix would still write to the wrong row.

2. PUT handler (secondary, same omission server-side): packages/core/src/astro/routes/api/content/[collection]/[id].ts:79. GET reads url.searchParams.get("locale") (line 25) and forwards it to handleContentGet; PUT calls emdash.handleContentGet(collection, id) without locale to resolve the row for ownership and resolvedId. Once the admin sends ?locale=en on writes, this resolver still ambiguously matches a shared slug.

End-to-end mechanism: opening /_emdash/admin/content/pages/about mounts ContentEditPage → fetchContent("pages","about") → GET /_emdash/api/content/pages/about (no locale) → slug 'about' matches both rows; resolver returns the Arabic row, UI renders it (AR badge, Arabic title). Translations panel's EN "Edit" sets ?locale=en but validateSearch strips it, so the Arabic row reloads — exactly what the repro screenshots and the API probe show (?locale=en correctly returns EN).

Fix applied: Server: PUT/DELETE/publish/unpublish/discard-draft/schedule/unschedule handlers now read ?locale= and pass it to handleContentGet for locale-aware slug resolution. Admin API client: added optional {locale} to fetchContent, updateContent, deleteContent, publishContent, unpublishContent, discardDraft, scheduleContent, unscheduleContent. Admin router: contentEditRoute validates locale, ContentEditPage computes activeLocale and forwards it through queries, mutations, autosave patches, and navigation. ContentList edit links and TranslationsPanel onOpen now carry locale. Added 7 unit tests in content-route-locale.test.ts that fail before and pass after. Fixed content-route-permissions.test.ts to supply url on mock context (required now that PUT reads searchParams). All 3555 core tests pass, typecheck clean, lint clean, formatted.

Try the fix (the preview release may take ~60s to publish after the bot pushes its branch -- if 404s, wait a moment and retry):

npm i https://pkg.pr.new/emdash@bot/fix-1242

Screenshots:

@WellDunDun could you try this and reply here with whether it resolves the issue? A simple "yes, fixed" or "no, still broken" is enough.

Fix branch: bot/fix-1242 · Artifacts branch: bot/artifacts-1242

_{Run: https://github.com/emdash-cms/emdash/actions/runs/26781384780}

[WellDunDun]

Yes, fixed. Thank you!